Integrate Oracle SOA Healthcare and Oracle SOA Suite back-end composites across segregated domains (Part 1 of 3)

When implementing a composite with JDeveloper, one of the available adapters - since early versions of the 11g release of Oracle SOA Suite - is the Healthcare Adapter. This adapter allows to connect, both as exposed service (inbound) and as reference (outbound), to an Oracle SOA Suite for Healthcare Integration (SSHI) installation enabling document trading with other applications in the healthcare ecosystem.

The SSHI is mostly used for  HL7 documents exchange between back-end healthcare solutions and its satellite applications. However, in some other cases, SSHI is even implemented as a hub for document exchange, connecting heterogeneous healthcare applications.

The Healthcare adapter comes in two integration type flavors:

• Default - in memory integration;
• JMS - integration based on AQ or JMS queues.

The first one, based in memory, allows the SSHI application to integrate with the composites through the Healthcare Adapter using the JVM memory - what makes the integration quite efficient and fast - however, with one limitation: both SSHI and the SOA composites have to be deployed in the same domain.

Now, one of the best practices that should be taken in consideration when architecturing a large scale integration platform with SSHI and SOA Suite is to deploy the SSHI and the SOA back-end composite application in separated domains, favoring:

• Tuning and configuration - domain configuration isolation is key to reach the sweet spot in such implementation. The domain where the composites are being deployed will likely demand different configuration compared with the SSHI dedicated one. This segregation will allow to apply different tuning strategies to one another.

• Database partitioning - The fact that the SSHI and back-end composite application are persisting into separated SOA_INFRA schemas promotes separated database grow management strategies. This empowers an adequate data partitioning and purging strategies for each of the domains.

As explained, for an in memory integration, both domains needs to rely over the same JVM, therefore, separating the domains will presuppose two separated JVMs leaving the Default options as unusable.

This article demonstrates how the JMS integration can be implemented between SSHI and the back-end application available from two separated domains.

For questions of demonstrability it will follow a simplistic SSHI as a hub implementation. Because of that, the article additionally covers all the necessary steps to implement the integration scenario between two healthcare MLLP endpoints through a composite back-end.

Ingredients

• 2 separated SOA Suite domains with cross domain authentication active
• 1 inbound Weblogic JMS queue and connection factory
• 1 outbound Weblogic JMS  queue and connection factory
• 1 composite with two Healthcare Adapters, one as exposed service and another one as reference
• 1 SSHI MLLP inbound endpoint
• 1 SSHI MLLP outbound endpoint
• 1 "Send to Internal" Internal Delivery Channel
• 1 "Receive from Internal" Internal Delivery Channel

• Oracle JDeveloper 12c
• Oracle Document Editor 12c
• HAPI HL7 MLLP Testing Console

Method

Domains

Obviously the creation of the Oracle SOA Suite domains is the starting point - two domains should be then provided in separated DB schemas.

To facilitate understanding, let's consider:

• SSHI - Domain A (Domain created with the Option Healthcare active)
• SOA - Domain B (This domains can be provisioned with the Healthcare option inactive)

As important note, both domains should have the same user and password in order to activate the cross domain trust. To activate the cross domain authentication perform the following in both domains:

 When enabling it, provide the same credentials on “Security Interoperability Mode” on both domains. After setting it keep in mind that domain restart is required.

JMS Artifacts

Now it is time to provision the first artifacts requested for the implementation: the JMS Queues. The location where these queues will rely will impact the way the configuration is performed. This article describes the scenario where the JMS queues and connection factories are created into the SOA Domain - the Domain B.

Albeit assuming that typically both domains are configured in high availability with the implementation of clusters, this articles doesn't cover any high availability and reliability set up and deployment architecture. Based on that, the article orientation and options will be heading to a single server domain architecture. The reader should then reckon that the JMS artifacts should then be created and configure bearing the deployment architecture in place.

For performance and configurability reasons, a separated and new persistence store, JMS server and JMS module should be created prior to the JMS Queues configuration. The same for any JmsAdapter connection pool configured.

Create the Persistence Store

Log in into the Weblogic Admin Console of the Domain B (SOA Domain) and navigate to Services/Messaging/Persistent Stores

Create new Persistent Store, give it a name and click OK:

Create the JMS Server

Navigate to JMS Servers on the Domain Structure

Create a new JMS Server, giving it a name and selecting the previously created Persistent Store

Now, target the new JMS Server to the correspondent SOA Managed Servers

Create the JMS Module

Everything is set and ready to create a new dedicated modules where to drop the queues and connection factories. A new JMS Modules can be created navigating to JMS Modules at the Domain Structure tree.

Give the Module a name and press next

Target the JMS Module to the correspondent SOA Managed Servers

Finally, click on Finish to create the JMS Module

Create the JMS Subdeployment 

Select the newly created JMS Module

Select the Subdeployment tab and create a new one

Give the Subdeployment a meaningful name and press Next

Target the Subdeployment to the created SSHIJMSServer

After pressing Finish, the Subdeployment should appear in the Module Subdeployment list

Create the Connection Factories

Select the created module and click New to create new resources

Select the Connection Factory option and introduce the Name and the JNDI name for the connection factory. For inbound, the suggested names are: SSHIInboundCF and jms/hc/SSHIInboundCF

When moving to the next screen, before click on Finishing, select first the cluster or the managed servers that will targeted by the connection factory

Perform the same steps to create the outbound connection factory, introducing as name and JNDI name: SSHIInboundCF and jms/hc/SSHIOutboundCF

Create the JMS Queue

Navigate to the Module and create a new Queue resource

Introduce a name and JNDI name, for instance , SSHIInboundQueue and jms/hc/SSHIInboundQueue

After clicking Next, select the created Subdeployment and leave the Target list options default values.

Finalize the queue creation pressing Finish

Perform the same steps for the orubound queue creation, providing SSHIOutboundQueue as queue name and jms/hc/SSHIOutboundQueue as JNDI name

After performing all the above steps you should have all the necessary to be able to to configure and use the healthcare delivery channels with the JMS resources as depicted by the picture bellow.

SOA JMS Adapter

After creation of the JMS resources it is now time to configure the connection pools of the JMS Adapter of the Domain B to use the configured connection factories and queues.

Navigate to Deployments at Domain Structure tree and search and select the JMSAdapter. 

Create the connection pool for the inbound JMS connection factory, selecting new 

Navigate to the Configuration and Outbound Connection Pools tab 

Create a new Outbound Connection Pool under the existent group

Lets create first for the inbound connection. Place as name the eis/wls/SSHI_HL7_IN

 It is time to save a deployment plan with the changes made. For that, create a new configuration plan as JMSPlan.xml

After creation Finish a new configuration plan file will be created.

Now, it is time to create a new connection pool for the outbound connection, repeat the steps above mentioned changing the following for the JNDI name of the new connection

On the end, both connections should be made available on the list as depicted in the image bellow

Now, it is time to introduce the details of the previously created JMS connection factories. For that select first the connection eis/wls/SSHI_HL7_IN and introdcude at the connectionFactoryLocation value the JNDI: jms/hc/SSHIInboundCF (press enter before you save)

Do the same for the eis/wls/SSHI_HL7_IN, this time adding as the value, the JNDI Name: jms/hc/SSHIOutboundCF (press enter before you save)

Finalizing, it is time to update the JmsAdapter deployment to load the latest changes to the JMSAdapter.xml configuration file. For that, select the JmsAdapter from the Deployments list and select Update.

Accept the Redeploy option as default, pressing the Finish will redeploy the JmsAdapter with the new configurations.

Since SOA and HC will be working in different domains it is necessary to activate the Cross Domain Security option as bellow:

 If it is not enabled, then please enable it and provide the same credentials on “Security Interoperability Mode” on both domains. After setting it keep in mind that domain restart is required.

The configuration of the SSHI Healthcare, construction of an demonstration composite acting as back-end and testing of the case are explored in the second and third part of this article.