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
Read the complete article series here Part 1 and Part 2 and Part 3
SOA & BPM Partner Community
For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.
Blog 
Twitter 
LinkedIn ![image[7][2][2][2]](https://paascommunity.com/wp-content/uploads/2013/04/image7222.png?w=20&h=20 "image[7][2][2][2]")
Facebook ![clip_image002[8][4][2][2][2]](https://paascommunity.com/wp-content/uploads/2013/04/clip_image00284222.jpg?w=26&h=23 "clip_image002[8][4][2][2][2]")
Wiki
Technorati Tags:
SOA Healthcare,
Bruno Neves Alves,
SOA Suite 12.1.1,
Monitoring,
workload,
SOA Community,
Oracle SOA,
Oracle BPM,
OPN,
Jürgen Kress,
SOA Suite 12c
Introduction
PaaS Community Blog 