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 27

Java CAPS 6, JCA, Note 7 – Batch Inbound-Triggered JCA (Non)Transacitonality

By Michael Czapski Sun No Comments »

In Note 6 we explored the transactional behavior of a JCA MDB invoked by a JMS Adapter and orchestrating an Oracle JCA Adapter (a transactional end point) and a Batch Local File JCA Adapter (a non-transactional end point). In this Note let’s explore the issue of transactionality of a JCA Message-Driven Bean invoked by a non-transactional end point.

Let’s take the example from the “Java CAPS Basics: Implementing Common EAI Patterns Companion CD” book, ISBN: 0-13-713071-6, Chapter 11 “Scalability and Resilience”, Section 11.2 “Exception Handling”, subsection 11.2.1 “Exceptions in Java Collaborations”, 11.2.1.2 “Other Java Collaborations”. The book from which this section comes is available on the Companion CD. Let’s re-work this example using Java CAPS 6 JCA Adapters.

The example illustrates exception processing behaviour involving a Batch Inbound Adapter-triggered JCA Message-Driven Bean.
The Batch Inbound Adapter is designed to poll a directory for a file. When it finds a file that matches the name, or the name pattern, it immediately renames the fie by prepending a GUID to the original name then triggers the MDB and passes to it the original name of the file, the current name of the file and the directory in which the file was found. This behavior prevents other possible file pollers from getting hold of the file and gives the first comer exclusive access to the file. The MDB is designed to take the name of the file as given and rename the file to the original name with the suffix “~.in” appended, to indicate the file was read and processed. To do this the MDB will use the Batch Local File JCA Adapter’s capability to post-process the file by renaming or deleting it. To explore the transactional behavior the MDB will explicitly throw an exception after it renames the file.
The complete Note is available in 07BatcyhInboundTriggeredJCANonTransacionality.pdf.

Tagged with: • • • • • • • • • • • • • •
Jul 27

Java CAPS 6, JCA, Note 6, JMS-Triggered JCA with Oracle and Batch Local File – Exploration of transactionality

By Michael Czapski Sun 9 Comments »

Rather then inventing an example to discuss and illustrate the use of the Oracle JCA Adapter let’s build a solutions that uses the Oracle JCA Adapter and shows additional Java CAPS 6 facilities of interest.

Let’s take the example from the “Java CAPS Basics: Implementing Common EAI Patterns Companion CD” book, ISBN: 0-13-713071-6, Chapter 11 “Scalability and Resilience”, Section 11.2 “Exception Handling”, subsection 11.2.1 “Exceptions in Java Collaborations”, 11.2.1.1 “JMS-Triggered Java Collaborations”. The book from which this section comes is available on the Companion CD. Let’s re-work this example using Java CAPS 6 JCA Adapters.

This example illustrates exception handling involving a JMS-triggered JCA Message-Driven Bean.
The MDB is designed to receive a JMS message, update a field in a database table row with the value of the text message, write the text message, together with the timestamp, to a file and finish.

The complete Note is provided in 06JMSTriggeredJCAwithOracle.pdf

Update: Thanks to Dao Tien Tran for pointing out a typo on page 5. I corrected the typo and uploaded the corrected document.  Change is marked in color and with a change bar.

Tagged with: • • • • • • • • • • •
Jul 24

Java CAPS 6, JCA, Note 4 – Streaming FTP Inbound

By Michael Czapski Sun No Comments »

As at now there does not seem to be a way to stream FTP payloads to the local file system, or stream local files to FTP servers in the JBI environment. This kind of functionality may or may not appear in the OpenESB project, perhaps in conjunctions with the FTP BC or the File BC or both. In the meantime, a Java CAPS 6 developer can use the JCA Adapters-based solution to stream payloads of arbitrary size between FTP servers and local file systems in either direction.

This Note walks through the implementation of a Batch FTP JCA solution, which is triggered by a JMS Message, and performs a streaming FTP transfer of an arbitrarily large payload between a remote FTP server and the local file system. This Note re-implements the inbound part of the “Java CAPS 5.1 and Java CAPS 6 – Streaming Large FTP Transfers” Note available at http://blogs.sun.com/javacapsfieldtech/entry/streaming_large_ftp_transfers_with.
It should be easy enough to re-implement the outbound part of that Note using the material in this Note.

The complete Note is available in 04JCAStreamingFTPIn.pdf.

Tagged with: • • • • • • • • • • • • •
Jul 23

Java CAPS 6, Scheduler for JCA and JBI Projects, Note

By Michael Czapski Sun 2 Comments »

Java CAPS 5.x used to have a Scheduler eWay. Java CAPS 6 also has the Scheduler eWay but only on the Repository-based side. At this point in time there is no Scheduler JCA Adapter or a Scheduler Binding Component. Why would one be bothered by that? One would be bothered because there are business requirements that call for scheduling of activities. The one that comes to mind immediately is polling an FTP server for a file which to transfer. For polling the local file system there is the Batch Inbound JCA, which was used in solutions discussed in JCA Notes 2 and 3. For Batch FTP JCA there is no such thing.
Rather then ignoring the issue of lack of the Scheduler JCA Adapter I determined to see what can be done to provide this functionality for non-Repository-based Java CAPS 6 solutions.
When asked, one of my colleagues in the US suggested that EJB Timers are the way to go and provided the links to the material. I looked at what was discussed, threw up my hand in the air and exclaimed. I will not quote what I said. In short, EJB Timers may be all very well for a competent Java EE developer but not for a regular Integration, or SOA, developer. EJB Timers are, in my view, way too complex to implement and do not offer sufficient advantage over a Scheduler eWay to make it worth while to spend the time developing a solution that uses them.
The next thing I looked at was the open source Quarz scheduler, which also turned up to require more effort then I considered worth while for the Notes.
I felt that the simplest thing to do will be to use an external scheduler, a native one, provided by the OS. For Windows, on which I develop for the Notes, there is the “Scheduled Tasks” scheduler. For Unix there are Cron facilities. Both are well know and typically good enough in terms of timer resolution and scheduling flexibility. Above all else, using one does not require me to write scheduler code myself, merely write the code that triggers my solution when the scheduled event fires.
So, this Note walks through implementation of a Scheduler solution, which can be used to trigger a Batch FTP JCA solution or any other JCA-based or JBI-based solution that has to be triggered to some schedule.

Document 00Scheduler.pdf contains the entire Note.

Tagged with: • • • • • • • • • •
Jul 17

Java CAPS 6, Using JCA and JBI, Note 3, Batch Inbound, through Batch Local File to BPEL 2.0

By Michael Czapski Sun 17 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 mixed Java CAPS 5.x-like integration solution that retrieves a file from the local file system using JCA Adapters and passes its content to a BPEL 2.0 process executing in the JBI container. This requirement I have seen and heard of being implemented in 5.x many times by many customers.

Most of the material in the first 16 pages of this Note is the same as in Note 2.

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 send the payload as a string to a BPEL 2.0 Business Process, which will be triggered by this message and will execute in the JBI container. 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 OneWay WSDL interface and the JBI NMR to send it, as a String, to a BPEL 2.0 process. Both the JCA MDB and the BPEL process will be a part of the same JBI Composite Application and will communicate with one another using the Normalized Message Router (NMR).

The entire Note is available in 03JCA-BInboundThroughBLFToBPEL2.0.pdf

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: • • • • • • • • • • • • • •
Jul 11

Java CAPS 6, Using JCA, Note 1, JCA-based JMS Consumer

By Michael Czapski Sun 5 Comments »

In addition to doing it the hard way, which is something a developer could always do and frequently did, Java CAPS 6 gives a developer 4 ways in which to receive messages from a JMS Destination. Two of these will be familiar to the Java CAPS 5.x developer and involve a JMS-triggered JCD and a JMS-triggered eInsight BP. Of the two additional ways in Java CAPS 6, one involves the use of the JBI infrastructure through the JMS Binding Component (JMS BC) and one involves the use of the just introduced evolution of the 5.x eWays variously referred to as Global RARs or Java 1.5 EE JCA adapters.

This discussion revolves around the JCA adapter use and points out, appearances notwithstanding, how easy it will be for a JCD developer to develop JCD-equivalent ‘collaborations’ using JCA adapters in Java CAPS 6.

Note that OpenESB does not provide this functionality and that this functionality has nothing whatever to do with the JBI.

Credits go to Frank Kieviet and others who proposed and oversaw the evolution of the eWays into JCAs and Dao Tien Tran whose JCA tutorial helped me get started.

Here is the document that discusses the topic: 05JCA-basedJMSConsummer.pdf

Tagged with: • • • • • • • • •
preload preload preload