D Interface Sequencing

This appendix discusses how the Oracle SOA Suite for healthcare integration achieves end-to-end First In First Out (FIFO) processing of messages by using Interface Sequencing.

The appendix contains the following sections:

• Section D.1, "Introduction"

• Section D.2, "Configuration Considerations for Interface Sequencing"

D.1 Introduction

Oracle SOA Suite for healthcare integration message processing involves the following broad-level steps:

1. The Oracle Healthcare inbound component receives the message from an endpoint and delivers an equivalent XML message to a SOA composite.

2. The composite performs any required transformations, determines the target endpoints for the message, and routes the same/transformed message to the Oracle Healthcare engine.

3. The Oracle Healthcare outbound component then delivers the message to the target endpoints.

Oracle SOA Suite for healthcare integration enables you to perform FIFO processing of messages by using the following approaches:

• Component Sequencing

• Interface Sequencing

Component Sequencing

This approach achieves FIFO by maintaining the sequence of the messages across the boundaries of all the three components: the Oracle Healthcare inbound component, the composite, the Oracle Healthcare outbound component.

Please see https://stbeehive.oracle.com/content/dav/st/Oracle%20SOA%20Suite%20for%20healthcare%20integration/Public%20Documents/Oracle%20SOA%20for%20Healthcare%20-%20Sequencing%20Guide.docx for more details about Component Sequencing.

Interface Sequencing

This approach achieves FIFO across endpoints, by correlating the messages across the layers and enforcing sequencing at the point of delivery to the target endpoint

For example, when an inbound Oracle Healthcare endpoint receives 20 messages in order, it time-stamps each message on entry to the system and sends them to the engine for processing in a sequential manner. The engine processes the messages in the sequence and sends the messages to the outbound endpoint for delivery based on the time stamp. This means that the message that arrives at the inbound endpoint is delivered first from the outbound endpoint.

If for some reason, a message with an earlier time stamp gets stuck due to longer time in processing or gets errored out, the other messages with later time stamps do get processed, but are queued in sequence at the outbound endpoint. Those messages do not get delivered out of the outbound endpoint till the time the message with the earlier time stamp (that has got stuck) is processed successfully, and is delivered out of the outbound endpoint. If the message has got errored out, you can try resubmitting the it or you can delete the message from the Sequenced Endpoint Dashboard so that the processed messages waiting in the queue can be delivered.

Note:

In the case of inbound messages, the Pause/Resume button is disabled for endpoints with end-to-end Interface Sequencing.

This approach reduces the number of sequencing checkpoints, provides a single point of sequence management, and improves performance and scalability of the system.

Note:

In the case of inbound, if the Application message is created successfully, and some failure happens thereafter, the XML payload is persisted for resubmission, which means that the Application message resubmit option is enabled. If the Application message is not created, then you have to resubmit the message from the Wire.

In the case of outbound, if the transformation from XML to native format is successful, then the XML payload is not persisted. However, if the transformation from XML to native has failed, then the XML payload is persisted for further resubmission.

D.2 Configuration Considerations for Interface Sequencing

To enable Interface Sequencing in Oracle SOA Suite for healthcare integration, you need to perform some configurations at the endpoint level as well as at the composite level.

D.2.1 Configuring Interface Sequencing at the Endpoint Level

You can configure Interface Sequencing of messages at the endpoint level by selecting the Interface Sequencing check box in the transport protocol configuration.

To configure Interface Sequencing:

1. In the Oracle SOA Suite for healthcare integration console, open the endpoint for which you want to configure Interface Sequencing.

2. Click the Transport Details button to display the Transport Protocol Parameters dialog box.

3. Click the Advanced tab.

4. Select a Sequencing Mode.

5. Select the Interface Sequencing check box.

6. Click OK, and then click Apply on the endpoint page.

Figure D-1 displays the Transport Protocol Parameters dialog box where you configure Interface Sequencing.

Figure D-1 Interface Sequencing

Description of "Figure D-1 Interface Sequencing "

This configuration only affects the inbound messages that are received on an endpoint. The endpoint to which the messages are delivered need not be configured for Interface Sequencing.

Once you configure Interface Sequencing at the endpoint level, messages received at this endpoint would be marked for Interface Sequencing, and Interface-Sequencing-specific headers would be delivered to the Internal Delivery Channel and the composite.

Note:

Interface Sequencing does not guarantee the order on how the messages are processed in the composite. This approach only ensures that the messages are delivered to the remote endpoint in a sequential manner.

D.2.2 Configuring Interface Sequencing at the Composite Level

To achieve the correlation (inbound message with outbound) composites handling Interface Sequencing messages are required to process and populate the following additional headers:

• To establish correlation across the transport and engine layers, you need to copy the INTERFACE_SEQUENCE_ID (or hc.interfaceSequenceId in case of fabric) header from the inbound message to the outbound message(s) headers.

• In the case of a fan-out (broadcast), where one inbound message is delivered to multiple endpoints, the composite should populate the INTERFACE_GROUP_COUNT header in each of the outbound message involved in the fan-out.

  For example, if a message is to be enqueued to two endpoints, both the enqueued messages should have the header INTERFACE_GROUP_COUNT (or hc.interfaceGroupCount in case of fabric) value set to 2.

• When fan out messages are intended for the same outbound endpoint, you need to use the JMS only property, INTERFACE_GROUP_POSITION to maintain the order among the multiple interface outbound messages intended for the same target endpoint. The messages are delivered based on the position value specified. However, in case of in-memory integration on the outbound side, the order in which the message arrives in Oracle Healthcare is used for message delivery.

• In case the composite is required to filter certain messages, a notification needs to be sent to the sequencing framework to indicate that the message has been skipped.

  This can be achieved by sending a signal to the Oracle Healthcare adapter or the JMS queue with the INTERFACE_SEQUENCE_DISCARD_ID (or hc.interfaceSequenceDiscardId in case of fabric) header set to the value of INTERFACE_SEQUENCE_ID header in the original message.

D.2.3 Understanding Sequenced Message States

Oracle Healthcare provides you the feature to view the states of the interface sequenced messages by using the Dashboard. Figure D-2 displays the sequence state of the message.

Figure D-2 Sequenced Message State

Description of "Figure D-2 Sequenced Message State"

The following sequence states are visible on the Dashboard:

• Routing

• Outbound_Processing

D.2.3.1 Routing

A message with the Routing sequence state in the Dashboard indicates that the message has been delivered to the backend. In this case, the row for the inbound message in the B2B_SEQUENCE_MANAGER table displays the value as ROUTING. The message delivered to the backend has a new header:

• hc.interfaceSequenceId in the case of fabric

• INTERFACE_SEQUENCE_ID in the case of JMS

D.2.3.2 Outbound_Processing

A message with the Outbound_Processing sequence state in the Dashboard indicates that the message has been received from the backend and is currently in outbound processing. In this case, after a message has been delivered to the backend, the message is evaluated if it has the INTERFACE_SEQUENCE_ID header, to determine if it is an Interface Sequenced message. Then, if the message has a header, the INTERFACE_GROUP_COUNT header is subsequently read to identify a possible fan-out case and the message sequence state is marked as Outbound_Processing.

D.2.4 Resubmitting or Discarding Interface Sequenced Messages

You can resubmit or discard interface sequenced messages in case of any error:

• In case of any error in the inbound message processing, you can see that the message has failed in the dashboard. You can then resubmit the message from the Wire.

• In case of any error in the outbound processing, you can just resubmit the Application Message because the payload is persisted.

• You can also discard the outbound message (displayed in the Dashboard) only after all the messages to the target are available. You can also discard the inbound message from the source on the inbound endpoint dashboard. This, in turn, discards any outbound messages to the target for the same sequence. The error message generated contains information of all the discarded messages.