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:
Oracle SOA Suite for healthcare integration message processing involves certain broad-level steps.
The Oracle Healthcare inbound component receives the message from an endpoint and delivers an equivalent XML message to a SOA composite.
The composite performs any required transformations, determines the target endpoints for the message, and routes the same/transformed message to the Oracle Healthcare engine.
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:
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.
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.
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.
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.
To enable Interface Sequencing in Oracle SOA Suite for healthcare integration, you must perform some configurations at the endpoint level as well as at the composite 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:
Figure D-1 displays the Transport Protocol Parameters dialog box where you configure Interface Sequencing.
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.
After 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.
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.
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 must copy the
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
hc.interfaceGroupCount in case of fabric) value set to
When fan out messages are intended for the same outbound endpoint, you must 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 must 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
hc.interfaceSequenceDiscardId in case of fabric) header set to the value of
INTERFACE_SEQUENCE_ID header in the original message.
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
The following sequence states are visible on the Dashboard:
A message with the
Routing sequence state in the Dashboard indicates that the message has been delivered to the back end. 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 back end has a new header:
hc.interfaceSequenceId in the case of fabric
INTERFACE_SEQUENCE_ID in the case of JMS
A message with the
Outbound_Processing sequence state in the Dashboard indicates that the message has been received from the back end and is currently in outbound processing. In this case, after a message has been delivered to the back end, 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
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.