This appendix describes how to implement Oracle SOA Suite for healthcare integration applications when using the Minimal Lower Layer Protocol (MLLP) in a high availability environment.
This appendix contains the following topics:
F.1 Introduction to Healthcare Integration High Availability
These properties enable high availability for healthcare integration projects and specify time out and heartbeat intervals for the servers in the cluster.
All features currently supported for MLLP in Oracle SOA Suite for healthcare integration are also supported in a high availability environment, including message sequencing.
This SOA Suite feature is part of Oracle Integration Continuous Availability. Please refer to the Oracle Fusion Middleware Licensing Information User Manual for more details on Oracle SOA Suite for Middleware Options.
F.1.1 High Availability Processing
In a clustered environment, the first healthcare integration instance to start up and initialize is the instance that handles MLLP traffic. When the instance handling MLLP traffic fails, an inactive instance in the cluster becomes active and takes over the responsibility of handling MLLP traffic within the configured timeout period. All in-flight messages from the failed instance are recovered since message processing is transactional for healthcare integration. This ensures that no messages are lost during failover.
If the instance that fails becomes completely disabled, the second and now active instance continues to pick up messages from and send messages to an outbound distributed queue created specifically for high availability processing. If the initial instance becomes available again, the second instance continues to handle MLLP traffic.
F.1.2 Front-End Failover
A load balancer is used as a failover device in case the active node in the cluster fails. This is required for inbound MLLP traffic when Oracle SOA Suite for healthcare integration is implemented in a clustered environment. The endpoints and external systems use the IP address of the load balancer as the destination connection. This means that all the connections are established in one active node, and message processing is performed across all nodes in the cluster. The load balancer can be configured to distribute the messages evenly among the healthcare integration instances, but only the designated active instance will establish connections. Using cookie-based or active-persistent connections in the load balancer might cause unexpected behavior in the MLLP server. Oracle recommends defaulting to non-persistent connections and verifying the load balancer documentation for persistence settings to eliminate connection losses. Please refer to the load balancer documentation for instructions about how to uniformly farm out the incoming connections across the SOA cluster to the TCP ports (part of Endpoints) configured in the Oracle SOA Suite for heathcare integration user interface.
F.1.3 Notion of Active
The "Active" server is the only server in the cluster that can send or receive messages from an endpoint using MLLP. However, the message processing is done by all servers in the cluster. For example, in the outbound case, messages are prepared to be sent by all the servers in the cluster, but the actual sending is restricted to only the active server. It is the same in the inbound case.
F.1.4 Unit of Order (UOO)
This is an Oracle Weblogic server feature for JMS queues. In the default configuration, all messages belonging to the same UOO are "tied" to a specific server. UOO is used to sequence messages within JMS in the Oracle Weblogic server. So, if UOO is being used, the JMS queue to which the UOO is "tied" has to be active to receive messages. In the event of a server failure, the JMS messages can be recovered using the "Whole Server" migration.
In an HA environment when external JMS queues are used, a "Whole Server" migration must be configured.
F.1.5 External Dependencies
Oracle SOA Suite for healthcare integration relies on the following components:
Oracle SOA database for messages and message state persistence
Metadata Services (MDS) repository for instance metadata
Load balancer for high availability support
F.1.6 Additional Resources
F.2 Enabling MLLP High Availability in Oracle SOA Suite for Healthcare Integration
To enable Oracle SOA Suite for healthcare integration, you must define certain B2B properties in Oracle Enterprise Manager.
These properties enable high availability for healthcare integration and define time out and ping intervals for the servers.
To enable MLLP high availability for healthcare integration
- Log on to Oracle Enterprise Manager.
The URL is http://hostname:port/em
where hostname is the name of the computer on which WebLogic Server is running and port is the port number on which WebLogic Server is listening.
- In the left navigation panel, expand the SOA node and select soa-infra.
- Click the SOA Infrastructure menu, point to SOA Administration and then select B2B Server Properties.
Figure F-1 SOA Infrastructure Menu on Enterprise Manager
Description of "Figure F-1 SOA Infrastructure Menu on Enterprise Manager"
- On the B2B Server Properties page, click More B2B Configuration Properties.
The System MBean Browser page appears.
- Click the Operations tab and then click addProperty.
Figure F-2 System MBean Browser Operations Page
Description of "Figure F-2 System MBean Browser Operations Page"
- In the Value column of the Parameters table, enter b2b.HAInstance in the key row and enter true in the value row.
Figure F-3 Adding the b2b.HAInstance Property
Description of "Figure F-3 Adding the b2b.HAInstance Property"
- Click Invoke.
The new property is saved.
- Using the previous steps, create a new property named b2b.MLLP_HA_Mode and set the value to true.
- You can define the following optional properties. If these are not defined, the default values are used.
The length of time in minutes before the next active instance takes over responsibility for MLLP traffic after the original instance fails. The default value is 2 minutes; 2 is also the minimum value allowed.
The time interval in minutes between pings to determine whether the servers are alive. The default interval is 1 minute; 1 is also the minimum value allowed.
The number of MLLP dispatcher threads to use in high availability mode. This is only used for non-sequenced messages, and is used in conjunction with a JMS resource.
The length of time (in milliseconds) after which an MLLP dispatcher thread will sleep after message processing.
The length in time in (minutes) that a message is in ACQUIRED state during failover after which it resumes processing.
The length in time in minutes before a message in the ACQUIRED state is polled again.
In the case of an inbound MLLP HA, if the server crashes after wire message has been committed to the database but before the event gets enqueued to Event Queue, it is perpetually stuck in the Sequence Manager table and is not processed. This blocks the inbound message flow in the sequencing case.
b2b.SingleTransactionAtInboundto true only in the case of MLLP HA to enable the JMS and database commit to take place in a single transaction. It is suitable only for the MLLP case where only one inbound message is received at a time. For example, when messages come in sequentially instead of in parallel for a single endpoint.
- When you are done adding properties, click Return.
- After you define high availability properties, you can view them on the Attributes tab. To view the properties, click the Attributes tab and then click Properties. Expand the Element nodes in the Value table to see the property names and values.
Figure F-4 High Availability Properties in Enterprise Manager
Description of "Figure F-4 High Availability Properties in Enterprise Manager"