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

This is the second part of the article covering an end-to-end example of a cross domain inter-operationality between an Oracle SOA for Healthcare Integration (SSHI) and SOA Back-End domain. This part delivers a step by step guide to implement the required Oracle SOA for Healthcare Integration (SSHI) configuration.

Please have in mind that the SSHI configuration is held on the SSHI Domain - Domain A.

Healthcare Configuration (SSHI)

An Healthcare integration with SSHI consists in:

• Creation of HL7 Documents
• Creation of endpoints, establishing the inbound and outbound MLLP channels
• Creation of Internal Delivery Channels using the created JMS at the Part 1 of this article

Create the HL7 Document

In the Part 3 of this article a SSHI repository will be delivered containing the configuration here described, however, this part also covers the creation of documents in the Oracle Document Editor to address the overall end to end process of SSHI configuration.

This part is optional if you plan to use either the Oracle HL7 Libraries or the repository provided in the Part 3 of this article.

With Oracle Document Editor you can create and use document definitions that will be used by the SSHI to create new documents to be exchange between endpoints. For this exercise, lets create an HL7, ADT 03 on version 2.6

Create new document

Select the protocol HL7, version 2.6 and ADT A03 as document type

No changes will be introduced to the standard, so, export the definition as ecs and xsd to be loaded by the SHHI when creating a new SSHI document

Export the xsd as Oracle 2.0

As this is a sample implementation, select all default options and save the definition. On the end, you will have a ecs and xsd file.

Now, at the SSHI console, lets use this artifacts to create a new document. When at the healthcare console, navigate to Designer, select configuration and, if not existent yet, create the HL7 Protocol, version 2.6 and new document type ADT_A03 - all options as default.

It is time to create a new document definition with the name as ADT_A03_def, import the xsd and ecs created by the document editor and leave all other parameters as default

Note: You will also note that for the construction of the outbound endpoint a Ack message will be requested. In case of need, replicate the same steps above for an Ack message for version 2.6.

Create the Internal Delivery Channels

In order to use the created JMS queues for interface type between domains it is required to create Internal Delivery Channels, both for inbound and outbound.

For that, switch to the Administration tab in the Designer. In there you will find two folders:

Send to Internal - Send messages from SSHI to Back-end Composite though the inbound JMS Queue

Receive from Internal - Send messages from SSHI to Back-end Composite though the outbound JMS Queue

Starting by the Send to Internal:

Create a new JMS Internal Delivery Channel and fill:

Name -  IC_SSHI_INBOUND

Destination name (the inbound queue name) - jms/hc/SSHIInboundQueue

Connection Factory (the connection factory name) - jms/hc/SSHIInboundCF

Click OK. Back to the Internal Channel landing page select Transport Details.Switch to Advance tab and provide:

Destination Provider: java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soa1-host:soa-port (replace this value by the hostname and SOA Port for the SOA Domain)

Note: In case of communicating with a clustered SOA Domain, provide all SOA managed servers hosts separated by "," e.g. java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soa1-host:soa-port,soa2-host:soa-port

User Name: SOA Domain User (e.g. weblogic)

Password: SOA Domain User password

*Confirm Password must be also filled and corresponding to Password

Sequencing: Deactivated (More information about sequencing options may be found at the official SSHI Oracle documentation)

Now, the Receiving from Internal

Create a new Internal Delivery Channel and set Transport Protocol as JMS and fill:

Name -  IC_SSHI_OUTBOUND

Destination name (the inbound queue name) - jms/hc/SSHIOutboundQueue

Connection Factory (the connection factory name) - jms/hc/SSHIOutboundCF

Click OK. Back to the Internal Channel landing page select Transport Details.Switch to Advance tab and provide:

Destination Provider: java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soa1-host:soa-port (replace this value by the hostname and SOA Port for the SOA Domain)

Note: In case of communicating with a clustered SOA Domain, provide all SOA managed servers hosts separated by "," e.g. java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soa1-host:soa-port,soa2-host:soa-port

User Name: SOA Domain User (e.g. weblogic)

Password: SOA Domain User password

Confirm Password must be also filled and corresponding to Password

Sequencing: Deactivated (More information about sequencing options may be found at the official SSHI Oracle documentation) 

Having the documents and internal delivery channel created is time to create the two sample endpoints, one for inbound, another for the outbound.

Create the Endpoints

Lets start by creating the inbound MLLP endpoint.

From the Endpoints folder, right click and select Create

Introduce the following details:

Name: SSHI_INBOUND_MLLP

Transport Protocol: MLLP10

Connection Mode: Server (will receive messages)

Hostname: localhost or the host name of the SSHI Domain (Domain A)

Port Name: 6565

After clicking OK, the endpoint is created, however its necessary to change some configurations. For that, select the Transport Details options

Change to Advance Tab

Activate the Interface Sequencing (this is optional and depends on which type of sequencing to implement, even if sequencing should be active at all. SSHI sequencing options will be addressed by in future posts)

Immediate ACK should be set to Default and HL7 ACK set to None. All other values left as default.

Its now necessary to define which documents can be handled by the endpoint. Since it is an inbound endpoint, the created ADT_A03 document will be accepted by the endpoint.

For that, while with the endpoint screen open, select the ADT_A03 document from the Document tree and drag and drop it in the Documents to Receive area of the Endpoint screen.

Important step is to be sure that the IC_SSHI_INBOUND Internal Delivery Channel is configured as value for the Internal Channel options dropbox.

Tick the option Enabled and save the endpoint. The inbound should be now active and reachable.

Now, create an outbound endpoint

This time as client, since it will connect to a external MLLP Server

Name: SSHI_OUTBOUND_MLLP

Transport Protocol: MLLP10

Connection Mode: Client (will send messages to an MLLP Server)

Hostname: hostname of the MLLP Server

Port Name: Port of the MLLP Server

After clicking OK, the endpoint is created, however it is necessary to change some configurations. For that, select the Transport Details options

 Change to Advance Tab

This time the interface sequencing should be deactivated since for this case the interface sequencing will be established at the inbound endpoint level.

It is now time to define which documents can be handled by the endpoint. Since it is an outbound endpoint, the created ADT_A03 document will be sent by the endpoint.

For that, while with the endpoint screen open, select the ADT_A03 document from the Document tree and drag and drop it in the Document to Send area of the Endpoint screen.

Being an Outbound endpoint, it needs to be configured to accept HL7 acknowledge documents back from the HAPI MLLP server. 

Due to that, an Ack document should be added to the Receiving documents list of the endpoint. This time not necessary to map to any Internal Delivery Channel since the Ack message will be discarded.

Be sure that both are with translation option active, tick the option Enabled and save the endpoint. The inbound should be now active and ready to send HL7 documents.

All the configuration on the SSHI (Domain A) are now complete. It is time to address the back-end composite application to be deployed and used from SOA Domain (Domain B) on the third and last part of this article.

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.

New Oracle Fusion Middleware 12c (12.2.1.0.0) Released!!

The version 12.2.1 is officially and finally out!

Check what's new:

Oracle B2B

• Moving B2B Agreement from a Test to a Production Environment - Test to production (T2P) process is now simpler with the use of configuration plans to change the endpoints
• Enabling AS4–Based Message Exchange - Applicability Statement 4 (AS4) standard is now supported!
• Message Flow Throttling - Oracle B2B can pause, or throttle, the endpoint to publish messages
• Securing Messages with PGP - Oracle B2B and Healthcare support message level security using PGP 

Oracle SSHI (Soa Suite for Healthcare Integration)

• Cloning Endpoints - As possible with B2B agreements, its now possible to clone SSHI endpoints
• Synchronous Request/Reply over MLLP - Request/reply communication between two MLLP endpoints is not facilitated by the introduction of the sync communication feature at the endpoint configuration  
• Message Flow Throttling - same as B2B
• Securing Messages with PGP - Same as B2B

Oracle SOA Suite (BPEL, Mediator, Business Rules and Human Workflow)

• Support for patching running composite instances - Enabling the patching of running instances of a composite and recover faulted instances after patching
• Support for In-Memory SOA Using In-Memory SOA - Improve System Performance executing short living processes only in memory
• Support for debugging XSLT maps and support for conditional debugging - Enables debuging of XSLT maps using the SOA Debugger and using breakpoints
• Support for End-to-End JSON and JavaScript - Binding and reference of REST are made easy with the full support ot JSON and the introduciton of Java Script activity in BPEL processes

Oracle Service Bus

• Service Bus now supports REST natively end-to end - Native REST proxy services, business services, and pipelines are new in this release.
• A JavaScript pipeline action has been added to simplify manipulation of JSON and XML payloads. 
• The REST Branching, a new pipeline branch used with untyped Native REST services, has been added.
• A web-based XSLT mapper has been added to the Service Bus console. 
• The Service Bus debugger in JDeveloper has been enhanced to support conditional and exception breakpoints. 
• The HTTP tansport has been enhanced with support for compressed payloads. 
• The SFTP transport has been enhanced with FIPS (Federal Information Processing Standards) compliance support. 
• The EJB transport has been enhanced to leverage the JAX-WS stack to perform Java to XML bindings. 
• The MQ transport has been enhanced with Multi-Instance Queue Manager support.

And much much more... Stay tuned for more details!