Feb 28

Java CAPS Quick Note 002 – JCA Transform HL7 Delimited to Custom XML

By Michael Czapski Sun 8 Comments »

This Quick Note discusses a solution to the use case provided by Marcus Davies.

I am trying to read HL7 from JMS (preferably stcms) and populate an outbound XML data structure (different to the XML generated by the decoder).
I have been thinking of doing one of the following […]:
1.    Use a Concrete JMS WS using the HL7 encoders to unmarshal the HL7 and use JAXB to populate the outbound XML.  Unfortunately this does not appear to connect to the stcms queue as I can not see any receivers
2.    Use a JCA MDB to read from the stcms JMS queue – this works but I don’t think I can use the HL7 encoder like this
3.    Use and MDB to read from JMS, manually unmarshal the HL7 and use JAXB to populate the data structure
Ideally I would like to use the HL7 encoders.  Do you think the first approach should work?

Number 1 will not work as at end of February 2009 because the JMS BC does not properly decode the HL7 delimited message. This is a know issue. I don’t know what the status of this is. The only BCs that know how to deal with HL7 delimited, that I know of, are the File BC and the HL7 BC.

Number 2 should work. I did not personally try it. You can invoke an encoder library from Java. Have a look at http://wiki.open-esb.java.net/Wiki.jsp?page=UseEncodersInJavaSE.

Number 3 should work but it will be very laborious.

I have a Number 4, which uses a HL7 OTD and a custom XSD-based OTD in a JCA EJB. You may or may not like it but it’s the best thing to do if you can not use BPEL 2.0 to do the mapping and you don’t want to build a repository-based solution (which would be the best for your case anyway).

The solution involves the use of:
1.    HL7 2.3.1 OTD Library (Java CAPS 6 Repository)
2.    JMS JCA to trigger a MDB with a HL7 Delimited message
3.    JMS JCA to write result message out
4.    JCA MDB to do the processing
5.    OTDImporter to provide HL7 2.3.1 OTD and custom XSD-based OTD to the EJB for “convenient” mapping

Brief steps to implement this solution are given in Quick Note 002 at QuickNote002_For_Marcus_Davies.pdf. Archive containing project exports and sample data is provided at QuickNote002.zip. The code will work in Java CAPS 6 Update 1.

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: • • • • • • • • • • • • • •
preload preload preload