C Synchronous Request/Reply over MLLP

This appendix provides information about synchronous request and reply over MLLP.

This appendix includes the following topics:

• Overview of Synchronous Request/Reply

• End to End Message Flow

C.1 Overview of Synchronous Request/Reply

Request/reply communication is a synchronous invocation where a response message is expected once the request message is sent. In general, this is a blocking call. This feature allows implementation of a request/reply message flow where a message is sent from Endpoint A to Endpoint B via the composite and the Endpoint B sends back an ACK back to Endpoint A via the same composite or another composite. Endpoint A would not receive the next ORM message until the ACK is sent back to Endpoint A.

The sync request reply feature is limited to one App invoking an inbound endpoint at any one time, that is, there are no concurrent invocations.

C.2 End to End Message Flow

This topic contains an example of the end to end message flow for synchronous request/reply.

App A ---ORM--> SSHI -> composite -> SSHI ---ORM--> App B
App A <--ACK--- SSHI <- composite <- SSHI <--ACK--- App B

Essentially, SOA Suite for healthcare Integration (SSHI) needs to read the ORM from the TCP socket and write the ACK back to the same socket. The difference in this use case is that the ACK is coming from App B. This use case can be solved by turning off Functional Acknowledgement handled automatically. Let the composite handles it. In turn the composite receives the ACK from App B. This use case does not require the composite to have synchronous request/reply setting.

Starting on the top left side:

App A ---ORM--> SSHI -> composite

SSHI receives the ORM, translates it to ORM xml, passes it to the composite with DOCTYPE_NAME, DOCTYPE_REVISION, TO_ENDPOINT/TO_PARTY, FROM_ENDPOINT/FROM_PARTY, MSG_ID information along with others. See http://docs.oracle.com/cd/E28280_01/user.1111/e10229/app_interface.htm#CACBHDJE for a list of these.

In this case, let's say FROM_ENDPOINT=EndpointAppA and MSG_ID=1234. In the composite, it uses this information or the ORM content to transform and route to App B. In doing so, composite will set TO_ENDPOINT=EndpointAppB and MSG_ID=1234__EndpointAppB (append with the original MSG_ID with __EndpointAppB in this example, this will be used for correlation as you can see later) in addition to other parameters in order to send to App B. This completes the top section.

Continuing with the lower right side:

composite <- SSHI <--ACK--- App B

The ACK comes in and it correlates to ORM and this ACK will be passed to the composite because Functional Ack handled automatically is set to No. The ACK will have set FROM_ENDPOINT=EndpointAppB, INREPLY_MSG_ID=1234__EndpointAppB. In the composite, it will have logic to strip away the post fix to get the original message id. It also has either a business rule to match EndpointAppB with EndpointAppA, or it can query the b2b_instancemessage view to find out the original EndpointAppA base on the original message id 1234.

For the finalApp A <--ACK--- SSHI <- composite segment, TO_ENDPOINT=EndpointAppA and INREPLY_MSG_ID=1234 and other relevant parameters. In this last segment the ACK will correlate back to the original ORM without using any information in the ACK.