Feb 10

Migrating Java CAPS 5/6 Assets to Oracle SOA Suite – HL7 JCD to Document Callout Migration

By Czapski Michael Java CAPS, Oracle, Oracle SOA Suite for healthcare integration, Sun No Comments »

This article leverages discoveries from the 2+ year old article “Migrating Java CAPS 5/6 Assets to Oracle SOA Suite 11g – HL7 JCD to Spring Component Migration”, at https://blogs.czapski.id.au/2010/10/migrating-java-caps-56-assets-to-oracle-soa-suite-11g-hl7-jcd-to-spring-component-migration,  and presents a different method of reusing “HL7 Transformer JCD” code in a SOA or OSB solution. This method uses SOA Suite for healthcare integration, slightly modified Java code for a “HL7 Transformer JCD” and WebLogic JMS. The Java CAPS part of the discussion is substantially the same, except the JCD code is wrapped in a SOA Suite for healthcare integration Callout, rather than being converted to a Spring Component embedded in a SOA Campsite. The “HL7 Adapter” part of the article is different in that SOA Suite for healthcare integration is used instead of the SOA Suite B2B HL7 functionality.
This article is of potential interest to these Sun/SeeBeyond customers who have an investment in moderate and large Java Collaboration Definition-based transformation and mapping rules, and who are looking for ways to reuse as much as possible of the Java code involved, when migrating to the Oracle SOA Suite or the Oracle Service Bus. The example developed in this article comes from the healthcare domain and uses the HL7 OTDs (Object Type Definitions). This is a deliberate choice because all but the most trivial HL7 transformations will involve hundreds of lines of Java code, therefore are a good candidates for migration. The adapter part of the HL7 solution is provided by the SOA Suite for healthcare integration. This makes the method domain-specific.
Discussion in this article addresses a subset of technologies available in the Java CAPS and in the SOA Suite for healthcare integration. Specifically, the Java Collaboration Definitions supported in Java CAPS 5.x and in Java CAPS 6/Repository, and the SOA Suite for healthcare integration (part of the SOA Suite 11g R1 PS5).
There is no discussion pertaining to JBI-based technologies or Java CAPS BPEL-based technologies. There is no discussion about other ways in which Java logic can be deployed as part of an Oracle SOA Suite solution.
The HL7 eWay and JCD based Java CAPS solution will be ported to the Oracle SOA Suite for healthcare integration and Java-based environment. HL7 Adapters will be replaced with the HL7 endpoints provided by the Oracle SOA Suite for healthcare integration infrastructure. What minimal routing is used will be provided by the Mediator component via JMS Queues. Transformation logic will be ported to the Java POJO (Plain Old Java Object) and will be embedded in the endpoint as a document callout.
This article walks through the process of “extracting” JCD source and related archives from Java CAPS, developing a stand-alone Java application which uses the JCD source, encapsulating JCD source in a SOA Suite for healthcare integration callout and finally reproducing Java CAPS HL7 solution functionality in an equivalent SOA Suite for healthcare integration solution.
The complete article is available at https://blogs.czapski.id.au/wp-content/uploads/2013/02/09_HL7JCD2DocumentCalloutMigration_v1.0.1.pdf.

Data files used in this article series are available at:

ADT_A01_output_1.hl7 – https://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_output_1.zip – this file contains a single ADT A01 transaction

Tagged with: • • • • • • • • • • • • • • • • • • • • • • •
Feb 03

SOA Suite for healthcare integration Series – HL7 v2 solution using JMS “the Java CAPS way”

By Czapski Michael Java CAPS, Oracle SOA Suite for healthcare integration 1 Comment »

This article may be of interest to these who would like to use the “SOA Suite for healthcare integration” HL7 v2 delimited message handling functionality in solutions similarly to how Oracle Java CAPS HL7 eWay-based solutions were built, perhaps as endpoints in a “Service Bus”-based infrastructure, or to these who would like to use the HL7 messaging handing functionality in OSB environments. In essence, for these unfamiliar with the Java CAPS pattern of use, there were the “Inbound HL7 eWay” and the “Outbound HL7 eWay” patterns. An inbound HL7 v2 Adapter (eWay) would receive a HL7 message, perform all (minimal) validation and acknowledgement processing and store the incoming message in a persistent JMS Queue for some downstream component to process the message as necessary. An Outbound HL7 v2 Adapter (eWay) would read a HL7 message from a JMS Queue (where it was deposited by some upstream component) and send it out to the external system, performing any HL7 ACK processing that might have been required.
In the prior articles in this series we used direct integration between the HL7 v2 endpoints and SOA Suite Composites which provided processing logic. While in my articles JMS is used implicitly as an internal mechanism (via B2B_IN_QUEUE and B2B_OUT_QUEUE JMS queues) the SOA Suite composite did not explicitly use JMS adapters.
It is possible to configure SOA Suite for healthcare integration endpoints in such a way that messages the inbound endpoint receives will be deposited in a particular JMS destination (queue or topic other than the B2B_IN_QUEUE) associated with the endpoint, and messages to be sent by an outbound endpoint will originate in a specific JMS destination (queue or topic other than the B2B_OUT_QUEUE). This will allow such endpoints to be used in Oracle Service Bus-based or other ESB-based solutions as services with JMS interfaces.
In this article we will develop and exercise an inbound-to-JMS and JMS-to-outbound HL7 v2 delimited message processing solutions to demonstrate this capability.

The complete article is available at https://blogs.czapski.id.au/wp-content/uploads/2013/02/SOASuiteHCI_ch15_Inbound_HL7v2Delimited_The_JavaCAPS_Way_v0.1.0.pdf.

Data files used in this article series are available at:

ADT_A01_broken_1.hl7 – https://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_broken_1.zip – this file contains a single ADT A01 transaction, in which the EVN segment’s name is rbroken, making the message invalid. This message is used in the article “SOA Suite for healthcare integration Series – Exception Handling – Processing Endpoint Errors” for testing exception handling
ADT_A01_output_1.hl7 – https://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_output_1.zip – this file contains a single ADT A01 transaction
ADT_A03_output_1.hl7 – https://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A03_output_1.zip – this file contains a single ADT A03 transaction
ADT_A01_output_5099.hl7 – https://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_output_5099.zip – this file 5099 ADT A01 transactions, separated by \r\r\n, or Carriage Return, Carriage Return and New Line
QRY_A19.hl7 – https://blogs.czapski.id.au/wp-content/uploads/2013/01/QRY_A19.zip – this file contains a sample A19 query message

Tagged with: • • • • • • • • • • • • • • • •
Dec 13

Using Rhapsody 4.01 with GlassFish v2.x-bundled Message Queue JMS and “com.sun.jndi.fscontext.RefFSContextFactory”

By Czapski Michael Miscellaneous No Comments »

Recently I had an occasion to work on an integration project which required the Rhapsody 4.01-based integration solution to receive messages from a JMS Topic hosted by the Sun Java System Message Queue bundled with the Oracle/Sun GlassFish v2.x JMS . Product documentation and Internet searches did not offer assistance in terms of how the Rhapsody JMS Adapter needs to be configured to support this. While there are a number of articles which discuss the topic of configuring JMS Client to interact with GlassFish-hosted SJSMQ JMS Server, none of the solutions described in these articles worked for me. A degree of experimentation and creative adaptation resulted in a working configuration. This article discusses this solution for the benefit of these who will be faced with this problem and for my own benefit if I need to do this again in the future.

In this article I deal with JMS client access to the JMS destinations using the “com.sun.jndi.fscontext.RefFSContextFactory”, to which references can be found on the Internet but which is not documented as well as I would have liked when I had a need to use this method.

Here I use Windows conventions for directory and file paths. For Unix, adjust as required. I assume that you have a GlassFish 2.x installation, perhaps as part of a Sun/Oracle Java CAPS SOA infrastructure or as part of the Oracle Healthcare Master Person Index infrastructure. I also assume that you need to create a Rhapsody integration solution using GlassFish environment-hosted JMS topics and/or queues. This last may or may not be your motivation. Except for the Rhapsody bits, the method should hold for any JMS client, but I have not tried this method in any other client deployment. Perhaps someday I will.

The article is available at https://blogs.czapski.id.au/wp-content/uploads/2011/12/Rhapsody_4.01_and_GlassFish-bundledJMS_v1.0.0.pdf

Tagged with: • • • • •
Dec 11

Using Rhapsody 4.01 with WebLogic JMS for 10.3

By Czapski Michael Miscellaneous, Oracle No Comments »

Recently I had an occasion to work on an integration project which required the Rhapsody 4.01-based integration solution to receive messages from a WebLogic-based JMS Topic. Product documentation and Internet searches did not offer assistance in terms of how the Rhapsody JMS Adapter needs to be configured to support this. While there are a number of articles which discuss the topic of configuring JMS Client to interact with WebLogic JMS Server, none of the solutions described in these articles worked for me. A degree of experimentation and creative adaptation resulted in a working configuration. This article discusses this solution for the benefit of these who will be faced with this problem and for my own benefit if I need to do this again in the future.

The article can be found at https://blogs.czapski.id.au/wp-content/uploads/2011/12/Rhapsody_4.01_and_WebLogicJMS_10.3_v1.0.0.pdf

Tagged with: • • • •
May 28

Oracle SOA Suite 11g B2B HL7 v2 Inbound to WebLogic JMS Queue

By Czapski Michael Oracle 4 Comments »

I notice that people used to the eGate/Java CAPS way of doing things, when looking at migrating to the SOA Suite for HL7 messaging, are trying to reproduce the pattern “HL7v2Adapter?JMS Queue”. This is not necessary when using SOA Suite but can be done if one insists. This article walks through the process of implementing this pattern using Oracle SOA Suite 11g R1 PS3.

The process will follow these steps:
1. Obtain and configure the QBrowser tool for JMS browsing
2. Obtain and configure the HL7 Sender tool
3. Create two WebLogic JMS Queues to be used in the solution
4. Create and deploy a HL7 v2 Inbound Trading Partnership Agreement
5. Submit HL7 v2 messages and inspect them in the corresponding JMS Queue
6. Repeat steps 4 and 5 for another inbound stream

The cmplete article, which can be found at https://blogs.czapski.id.au/wp-content/uploads/2011/05/SOASuite_HL7v2_Inbound_to_JMS.pdf, will demonstrate that Oracle SOA Suite B2B HL7 infrastructure can be configured to receive message streams over multiple inbound MLLP channels and deliver each stream to a distinct JMS destination, much as eGate and Java CAPS solutions used to do.

Tagged with: • • • • • •
May 28

Using QBrowser v2 with WebLogic JMS for 10.3

By Czapski Michael Oracle No Comments »

WebLogic Server does not include a convenient tool to browse JMS destinations. Freely downloadable QBrowser version 2 tool, with some configuration, can be used to provide easy to use functionality to work with WebLogic JMS destinations. This article discusses how QBrowsers should be configured to work with the JMS destinations managed through the WebLogic Server 11g (10.3), which was the current version at the time this article was written.

The complete article is available at https://blogs.czapski.id.au/wp-content/uploads/2011/05/QBrowser_for_WebLogicJMS_10.3.pdf

Tagged with: • • •
Jan 26

Recording of a dmonstration of the “GlassFish ESB v2.2 Field Notes – Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions”

By Michael Czapski Sun No Comments »

In the blog entry “GlassFish ESB v2.2 Field Notes – Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions”, at https://blogs.czapski.id.au/?p=13, I present the GlassFish ESB v2.2-based load balanced, highly available, horizontally scalable solution for HL7 v2.x delimited messaging, using both the HL7 Binding Components, Web Services and JMS in request/reply mode. The one and a half hour recording of me discussing and demonstrating this solution is available as a Flash Movie (SWF), “GFESB_LB_HA_Demo_Session SWF ” at https://blogs.czapski.id.au/wp-content/uploads/2010/03/GFESB_LB_HA_Demo_Session_SWF.swf (62.7Mb download)

Tagged with: • • • • • • • • • • • • • • • •
Jan 05

GlassFish ESB v2.2 Field Notes – Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions

By Michael Czapski Sun 4 Comments »

It seems frequently assumed that architecting and deploying Highly Available (HA) solutions requires Application Server and/or Operating System clustering. When it comes to SOA and Integration solutions this is not necessarily a correct assumption. Load Balanced (LB) and Highly Available HA) SOA and Integration solutions may not require that degree of complexity and sophistication. Frequently, protocol, binding component, JBI and architectural application design properties can be exploited to design highly available solutions. Testing LB and HA solutions requires infrastructure consisting of multiple hosts and the ability to “crash” hosts at will. With virtualization technologies available now it is far easier to use multiple virtual machines then to use physical machines. It is also easier and potentially less destructive to “crash” virtual machines then it is to do so with physical machines.

In this Note a heterogeneous, non-clustered collection of hosts will be used to implement and exercise three load balanced, highly available GlassFish ESB-based solutions. The environment consists of a number of independent “machines”, which are not a part of an Operating System Cluster. Each “machine” hosts a GlassFish Application Server. Application Servers are independent of one another and are not clustered. This is to demonstrate that load balanced, highly available, horizontally scalable solutions, based on the GlassFish ESB software alone, can be designed and implemented.

The specific class of solutions to which this discussion applies is the class of solutions which:
1.    are exposed as request/reply services

a.    HL7 messaging with explicit Application Acknowledgment
or
b.    Request/Reply Web Services
or
c.    JMS in Request/Reply mode

2.    implement business logic as short lived processes
3.    are

a.    atomic
or
b.    are idempotent
or
c.    tolerant of duplicate messages

Classes of solutions with characteristics different from these named above require different approaches to high availability and horizontal scalability, and are not discussed here.

In this Note only high availability and scalability of receiver solutions is addressed. This aspect is the focus because a failure to process a message by a receiver may result in message loss –generally a bad thing.

Paradoxical as it may sound; senders are special cases of receivers. Just as a receiver is triggered by arrival of a message so too is a sender. Making sure that the sender trigger message does not get lost is much the same as making sure the message a receiver receives does not get lost. This means that the same considerations apply to senders and to receivers.

This note discusses an exercise involving an example load balanced, highly available, horizontally scalable healthcare environment, processing HL7 v2 messages. Discussion includes customization of generic GlassFish ESB v2.2 VMware Virtual Appliances for a specific Load Balancing and High Availability exercise and deploying ready-made GlassFish ESB solutions. The exercise for HL7 BC-based, Web Service-based and JMS-based highly available, load balanced, and horizontally scalable receivers, processing HL7 v2.3.1 messages, will be conducted and discussed.

At the end of the Note we will have three GlassFish ESB VMware Appliances with GlassFish ESB v2.2 Runtime infrastructure, ready to use for further GlassFish ESB Load Balancing and High Availability exercises.

The reader will be convinced, one hopes, that for the applicable class of GlassFish ESB-based solutions, load balancing and dynamic failover without message loss work. For that class of solutions this provides for high availability and horizontal scalability without resorting to Application Server or Operating System clustering.

The complete Note is available as 03_Conducting_HL7_LB_and_HA_Exercise_v1.0.0.1.pdf at https://blogs.czapski.id.au/wp-content/uploads/2010/03/03_Conducting_HL7_LB_and_HA_Exercise_v1.0.0.1.pdf

Tagged with: • • • • • • • • • • • • • • • •
Jun 30

Quick Note 003 for JBI-based JMS Publisher and Subscriber example for Leonard Barkley

By Michael Czapski Sun 1 Comment »

This Quick Note discusses a simple solution to the use case provided by Leonard Barkley. The question goes like this:

“I dont have any idea how to implement BPEL process but the BPEL deployed as a subscriber of a topic. usually I implement the BPEL process and deployed it as web service.”

We produce a simple GlassFish ESB v2.1-based solution which reads a file, sends its content to a JMS Topic and another simple GlassFish ESB v2.1-based solution which subscribes to the same JMS Topic, receives the message and writes it to a file. Both solutions will use BPEL to implement the simple logic, though it is possible to implement both solutions without BPEL, so we have File BC -> BPEL SE -> JMS BC -> JMS Provider (Topic) -> JMS BC -> BPEL SE -> File BC.

Here is the note: QuickNote003_forLeonardBarkley.pdf

Hire is an archive with the project group containing all the projects developed in the Note: JMSTopicSampleProjGrp.zip

As Leonard Barkley pointed out to me, having implemented the sample, the Note is incorrect on Pages 23 and 24. The JMSSubscriber_JMSIn WSDL should use the Receive type, not Send type as the docuent states. The solution still works, it appears, but the configuration as documented is confusing. Thanks Leonard.

Tagged with: • • • • • • • • • • • • • • • •
Jul 16

Java CAPS 6, Using JCA, Note 2, Batch Inbound, through Batch Local File to JMS

By Michael Czapski Sun 5 Comments »

Java CAPS 6 has the 5.x compatibility infrastructure which allows one to import 5.x projects right into Java CAPS 6, build, deploy and run without changes. One can also develop repository-based projects in Java CAPS 6 – that’s the 5.x-style projects. This is the old way of developing Java CAPS solutions – still good and valid.

If one were to decide to not use the old way there is the JBI infrastructure, which allows development of solutions that use BPEL Service Engine, XSLT Service Engine, IEP Service Engine, Java EE Service Engine, etc., and a variety of Binding Components. The implication is that business logic is implemented in BPEL 2.0, which is used to orchestrate other services and resources, including interaction with external systems through Binding Components. This is the new way of developing Java CAPS solutions – 100% compatible with the Open Source OpenESB project since it uses the OpenESB project-developed container and components.

Someone might ask “so what happened to eGate?”. “eGate” meaning Java Collaboration Definition-like logic components, eWays and the JMS messaging backbone.

While the facility seems underadvertised/downplayed, Java CAPS 6 provides a number of 5.1 eWay-based JCA Adapters and a moderately easy means of developing JCA Message-Driven Beans that can use these adapters to implement JCD-like logic components and, effectively, eGate-like solutions that do not use BPEL or the JBI infrastructure.

This Note discusses and illustrates the implementation of a JCD-like integration solution that retrieves a file from the local file system and writes its content to a JMS destination. This requirement I have seen and heard of being implemented in 5.x many times by many customers.

The JCA Message-Driven Bean, the piece of JCD-like Java logic, will be triggered by a Batch Inbound Adapter (what one would have called the Batch Inbound eWay in 5.1), will read the content of the file using the Batch Local File Adapter (eWay) and will write the payload as a string to a JMS destination. The batch Inbound Adapter will be configured to use a regular expression to match the name of the file. Once it finds the file it will rename the file by prepending the GUID to the name and will pass the new name, the original name and the directory path to the Java code. This is exactly what the 5.1 Batch Inbound does. The JCA MDB will use the new name, the original name and the directory path to dynamically configure the Batch Local File Adapter to retrieve the file content and rename the file (post transfer) to the original name with some string appended to indicate that the file was processed. This, too, is exactly what one would do in a 5.1 JCD in the same circumstance. Once the payload is available the JCA MDB will use the JMS OTD to send it, as a TextMessage, to a JMS Queue. Again, this is something that a 5.x JCD would do.

In effect, this Note describes and illustrates the process of re-creating a 5.x Java Collaboration Definition using Java CAPS 6, but instead of using the repository-based approach it is using JCA MDBs and JCA Adapters.

Complete text of the Note is in 02JCA-BInboundThroughBLFToJMS.pdf

Tagged with: • • • • • • • • • • • • • •
Previous Entries
preload preload preload