GSEM Architecture Overview

GSEMApi application is REST based API(web) which will work on HTTPs protocol. The GSEM Architecture has 2 parts viz. client (either Requester (or) Provider) and server (includes GSEMApi and GSEM Backend). All the communications happen through GSEMApi which is an interface based on RESTful Web Services. This is represented in the below diagram:

The CHS must implement two logics in parallel:

  • The receiving logic that receives messages from the GSEM Backend through GSEMApi to the CHS.

  • The sending logic which is triggered by the CHS to send a message to GSEMApi will be passed to GSEM Backend.

    • A sample code framework is provided in the API Specifications tab for each logic and can be reused as a starting point for the development.

Sending message

The CHS uses 2 APIs to send a transaction. These are :

  • GET gsem (to get the Configuration information)

  • POST message (to post a transaction)

If the configuration information is known already, then there is no need to call GET gsem.

The input parameters vary depending on different transaction types. The GSEM Backend validates the transaction and returns acknowledgement data to the CHS. This data returns the processed results to the Requester.

The CHS has to check whether the transaction was successful and take appropriate actions.

Receiving message

Pull Mechanism

Receiving messages is accomplished by polling the GSEM Backend at regular intervals using the GET message request. If there is no waiting transaction, the GSEM Backend returns a specific result indicating there are no pending transactions. If there are pending transactions, it returns the first one (first in first out queue): the next transaction in the waiting queue will remain in stand-by till the current transaction is completed and acknowledged.

Once the transaction is received, the CHS must acknowledge the transaction. This is achieved by executing the PATCH message request.

A recommendation is to process all messages that are waiting in the GSEM Backend and then wait for some minutes before looking for new transactions. The waiting time is usually set between 30 seconds and 1 minute and can be adjusted to optimize the overall throughput. The diagram below illustrates a possible waiting loop.

Push Mechanism

Receiving messages is accomplished by HPE GSEM sending (PUSHing) messages to the client’s exposed Web service end point URL as they arrive on a First In First Out (FIFO) basis. Once the client receives a message, the CHS must respond back with standard HTTP acknowledgement . If positive acknowledgment is received by the GSEM Push service, the next message in the FIFO queue will be sent to the client. If acknowledgement fails or is not received in the timeout interval, the same message will be sent again on the next Push cycle.