Skip Headers
Oracle® Fusion Middleware Healthcare Integration User's Guide for Oracle SOA Suite
11g Release 1 (11.1.1.6.0)

Part Number E23486-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

D Implementing MLLP with High Availability

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:

D.1 Introduction to Healthcare Integration High Availability

High availability for Oracle SOA Suite for healthcare integration is handled through the high availability features of WebLogic Server, Oracle database, and Oracle SOA Suite. You can configure Oracle SOA Suite for healthcare integration for high availability by adding Oracle B2B properties in Oracle Enterprise Manager. These properties enable high availability for healthcare integration projects and specify timeout 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.

D.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.

D.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. An alternative to using a load balancer is to use the WebLogic cluster IP address.

D.1.3 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

D.1.4 Additional Resources

For more information about configuring Oracle SOA Suite for high availability, see the following:

D.2 Enabling MLLP High Availability in Oracle SOA Suite for Healthcare Integration

To enable Oracle SOA Suite for healthcare integration, you need to define certain B2B properties in Oracle Enterprise Manager. These properties enable high availability for healthcare integration and define timeout and ping intervals for the servers.

To enable MLLP high availability for healthcare integration

  1. 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.

  2. In the left navigation panel, expand the SOA node and select soa-infra.

  3. Click the SOA Infrastructure menu, point to SOA Administration and then select B2B Server Properties.

    Figure D-1 SOA Infrastructure Menu on Enterprise Manager

    Description of Figure D-1 follows
    Description of "Figure D-1 SOA Infrastructure Menu on Enterprise Manager"

  4. On the B2B Server Properties page, click More B2B Configuration Properties.

    The System MBean Browser page appears.

  5. Click the Operations tab and then click addProperty.

    Figure D-2 System MBean Browser Operations Page

    Description of Figure D-2 follows
    Description of "Figure D-2 System MBean Browser Operations Page"

  6. In the Value column of the Parameters table, enter b2b.HAInstance in the key row and enter true in the value row.

    Figure D-3 Adding the b2b.HAInstance Property

    Description of Figure D-3 follows
    Description of "Figure D-3 Adding the b2b.HAInstance Property"

  7. Click Invoke.

    The new property is saved.

  8. Using the above steps, create a new property named b2b.MLLP_HA_Mode and set the value to true.

  9. You can define the following optional properties. If these are not defined, the default values are used.

    Property Description

    b2b.HAMaxElapsedTimeout

    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.

    b2b.HAHeartBeatPing

    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.

    b2b.transportDispatcherThreadCount

    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.

    b2b.transportDispatcherThreadSleepTime

    The length of time (in milliseconds) after which an MLLP dispatcher thread will sleep after message processing.

    b2b.MaxTimeinAcquiredState

    The length in time in (minutes) that a message is in ACQUIRED state during failover after which it resumes processing.

    b2b.AcquiredStatePollingInterval

    The length in time in minutes before a message in the ACQUIRED state is polled again.

    b2b.SingleTransactionAtInbound

    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.

    Set the b2b.SingleTransactionAtInbound to 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.


  10. When you are done adding properties, click Return.

  11. 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 D-4 High Availability Properties in Enterprise Manager

    Description of Figure D-4 follows
    Description of "Figure D-4 High Availability Properties in Enterprise Manager"