Wednesday Oct 06, 2010

Migrating Java CAPS 5/6 Assets to Oracle SOA Suite 11g - HL7 JCD to Spring Component Migration

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. 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 migrating to the SOA Suite Spring Component as means of preserving the code and the effort invested in developing it. This does not make the method domain-specific. On the contrary, the method is applicable to all other domains where JCDs with significant transformation and mapping rules content are used.

Discussion in this article addresses a subset of technologies available in the Java CAPS and in the SOA Suite. Specifically, the Java Collaboration Definitions supported in Java CAPS 5.x and in Java CAPS 6/Repository, and the Spring Component supported in the SOA Suite 11g R1 PS2. Both use the Java programming language and related runtime environment to implement processing logic.  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 a Oracle SOA Suite solution.

The HL7 eWay and JCD based Java CAPS solution will be ported to the Oracle SOA Suite 11g B2B and Mediator-based environment. HL7 Adapters will be replaced with the Oracle “Healthcare Adapters”, provided by the SOA Suite B2B HL7 support infrastructure. Routing will be provided by the Mediator component and transformation logic will be ported to the Spring Component.

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 Spring component and finally reproducing Java CAPS HL7 solution functionality in an equivalent SOA Suite solution.

The complete article is available through the original blog at http://blogs.czapski.id.au/2010/10/migrating-java-caps-56-assets-to-oracle-soa-suite-11g-hl7-jcd-to-spring-component-migration

Sunday Apr 25, 2010

Exercising a Resilient Java CAPS 6 HL7 v2 Repository Solution

From time to time prospective clients ask for a proof that Java CAPS will not loose HL7 messages in the event of machine or network failure.

In this Note a heterogeneous, non-clustered collection of hosts will be used to implement and exercise Java CAPS 6/Repository HL7 v2 based solutions. The environment consists of two independent “machines”, which are not a part of an Operating System Cluster. Each “machine” hosts a GlassFish Application Server, which is the Java CAPS 6 runtime. Application Servers are independent of one another and are not clustered. This is to demonstrate that HL7 processing components, and solutions based on these components and other standard components in the Java CAPS infrastructure, can be designed and implemented in such a way that message loss in the event of typical failure and disruption scenarios is avoided.

This note discusses an exercise involving an example healthcare environment processing HL7 v2 messages. Discussion includes customization of a generic Java CAPS 6.2 VMware Virtual Appliance for a specific HL7 exercise and deploying ready-made Java CAPS 6/Repository-based solutions. The exercise for HL7 eWay and HL7 Inbound and Outbound projects, processing HL7 v2.3.1 messages, will be conducted and discussed.

The reader will be convinced that a resilient Java CAPS solution can be configured and that it will process messages in the face of typical failure and disruption scenarios without message loss or duplication.

Note that this article is not introductory in nature. It assumes that the reader has a fairly good working knowledge of the Java CAPS 5 or Java CAPS 6/Repository product and a good working knowledge of related areas, such as HL7 messaging, virtualisation and suchlike. These matters are not explained in this article.

The original article is available as a blog entry "Exercising a Resilient Java CAPS 6 HL7 v2 Repository Solution" at http://blogs.czapski.id.au/2010/04/exercising-a-resilient-java-caps-6-hl7-v2-repository-solution

Saturday Apr 24, 2010

Installing Java CAPS 6.2 Runtime on the Basic JeOS Appliance for HL7 Resilience Testing

From time to time prospective clients ask for a proof that Java CAPS will not loose HL7 messages in the event of machine or network failure.

This note walks through the process of installing a Java CAPS 6.2 runtime on the Base OpenSolaris-based VMware Virtual Appliance, discussed in the Blog Entry “GlassFish ESB v2.x Field Notes - Preparing Basic JeOS Appliance for GlassFish ESB LB and HA Testing” at http://blogs.czapski.id.au/?p=15.

At the end of the Note we will have a Java CAPS 6.2 VMware Appliance with Java CAPS 6.2 Runtime infrastructure, ready to use for reliability testing, or any other purpose for which a Java CAPS 6.2 runtime appliance might be appropriate.

The blog article is at my personal blog site - "Installing Java CAPS 6.2 Runtime on the Basic JeOS Appliance for HL7 Resilience Testing".

Wednesday Jan 13, 2010

GlassFish ESB v2.2 - Processing Explicit HL7 v2 Accept Acknowledgements

The HL7 v2 standard mandates the use of acknowledgments to ensure message delivery, critical in Healthcare. There are the “Original Mode” acknowledgements and “Enhanced Mode” acknowledgements. Within the enhanced mode acknowledgements there are “Accept Acknowledgements” and “Application Acknowledgements”.

This Note walks through development of two BPEL Module-based solutions that cooperate in generating and processing Enhanced Accept Acknowledgements using HL7 v2.3.1 messages. This discussion should apply to any v2.x, greater then v2.2, where the Enhanced Mode acknowledgements were introduced. In addition, the solutions are used to illustrate receiving HL7 BC ACK generation, when receiving an invalid HL7 message.

The blog article and the related material are available at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-2-processing-explicit-hl7-v2-accept-acknowledgements

Thursday Jul 30, 2009

Java CAPS 5 / 6, OpenESB, GlassFish ESB - Handling SOAP Headers in BPEL

Every now and then there arises a need to carry out-of-band information alongside the business payload but without disturbing or modifying it. Message Envelope Pattern is the Enterprise Integration Pattern label that is typically applied to solutions that address this issue. How the issue is addressed in practice varies depending on the technology in use. For JMS, for example, JMS Message Properties could be used to carry out-of-band information while the payload would be carried as the JMS payload. Web Services, typically using SOAP over HTTP, can address this requirement through the SOAP Header Extension Mechanism, whereby custom headers can be added to the SOAP Header while the payload is carried in the SOAP Body.

This document discusses construction of a WSDL that supports custom SOAP Header element and BPEL processes that are used to set and get custom header values in JBI and in eInsight. This mechanism is known to work in Java CAPS 5.x, Java CAPS 6 Classic and OpenESB / GlassFish ESB.

It is assumed that the reader is sufficiently familiar with the GlassFish ESB / OpenESB BPEL Service Engine and the SOAP/HTTP Binding Component, and / or Java CAPS Classic eInsight Business Process Manager and eDesigner IDE to be able to build projects without a step-by-step pictorial document.

The document is available here: 01_Handling_SOAP_Headers_in_BPEL_.pdf
The companion archive, containing WSDLs and projects, is available here: 01_Handling_SOAP_Headers_in_BPEL.zip

Friday Jul 24, 2009

Java CAPS 6 Update 1 Repository, Re-Implementing WS-Security 1.0 (2004) with JAX-RPC and JWSDP 2.0 (Java CAPS 6 Update)

This document discusses how to implement support for WS-Security 1.0 (2004) in Java CAPS 6 Repository projects without resorting to SOAP Message Handlers. This is an update to my 3 year old Java CAPS 5.1 document on this topic, "Java CAPS 5.1, Implementing WS-Security 1.0 (2004) with JAX-RPC". In this "release" Access Manager support for Username Token Profile has been removed. Feel free to add it if you need such support.

Java CAPS 6 Update 1 supports a mechanism for hooking SOAP envelope handlers into the Java CAPS Web Services framework so what I did and described in this document can now be done differently – perhaps better. I had a look at how to implement SOAP Message Handlers and it looked like work so I did not go there.

This material is provided on “all care but no responsibility” basis. Sun Java CAPS Support will not support this and neither will I. JAX-RPC from JWSDP 2.0, which is at the heart of the implementation, is deprecated and has long since been replaced by WSIT/JAX-WS/Tango.

Here is the document: Implementing_WS-Security_1.3_for_JavaCAPS6U1Repository.pdf
Here is the companion archive with all the required material: WSSecSampleProject_1.3_JCAPS6U1.zip

The WSSecurity.jar contains both the binary classes and the Java sources.

Thursday May 07, 2009

Getting Hundreds of Files using Batch Local File eWay in Java CAPS 6

Occasionally one needs to pick up and process a large number of files, on the order of hundreds or thousands. With the Batch Inbound eWay/JCA Adapter it is not possible to pick up more then one file per poll. The Batch Local File, if triggered by some event other then an appearance of a file in a directory, perhaps a Scheduler trigger of a manual trigger, with correctly designed logic can process many files in a single invocation.

The document, ProcessingHundredsOfFileWithBatchAdapter.pdf, discusses how Batch Local File-based solution can be constructed to effectively process hundreds of files in a single pass.

Saturday Mar 14, 2009

Use Subversion with GlassFishESB, OpenESB or Java CAPS 6 for version control

Java CAPS 5.x came with its own, built-in version control system, which many people liked and many despised. Java CAPS 6 Repository still has that version control system. Unlike the repository-based components standard NetBeans components, EJBs, and the JBI-based components, developed through the OpenESB Project and supported, for a fee, in the GlassFishESB product, must use an external version control system, if they are to be placed under version control.

This note discusses how a Subversion VCS can be installed on a Windows platform and used to provide version control for non-Repository components in Java CAPS 6 product and for projects in the GlassFishESB product and OpenESB project.

Clearly, non-Windows platforms can be similarly configured to support Subversion.

This Note, http://mediacast.sun.com/users/Michael.Czapski-Sun/media/Subversion_with_OpenESB_GlassFishESB_or_JavaCAPS6/details, is a step-by-step guide to getting Subversion installed and configured to work with NetBeans 6.1. It is not a tutorial on version control.

Sunday Mar 01, 2009

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


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

The article and referenced materials are available at http://blogs.czapski.id.au/2009/02/java-caps-quick-note-002-jca-transform-hl7-delimited-to-custom-xml

Saturday Feb 28, 2009

Java CAPS Quick Note 001 - Split file into multiple files

This Quick Note discusses a solution to the use case provided by Richard Kuiter.

An input file contains the following records:

H100000000000014099120ASN00507  
L1140991200000008261850826185738
L1140991200000008261850826185738
L1140991200000008261850826185738
L1140991200000008261850826185738
L1140991200000008261850826185738
L1140991200000008261850826185738
H100000000000014099126ASN00531  
L1140991260000008262690826269662
L1140991260000008262690826269662
L1140991260000008262690826269662
L1140991260000008262690826269662
L1140991260000008262690826269662

It is required that each block of records starting with the H1 (header) record and containing all the following L1 (line) records, be written to a different file.

The solution involves the use of:
1.    Batch Inbound eWay to locate the input file and provide its name and location to a Java Collaboration Definition
2.    Batch Local File eWay to provide an Input Stream to the Batch Record eWay
3.    Batch Record eWay to break up the input stream into records delimited by carriage return+new line
4.    Batch Local File eWay to write each block of records to a file with a distinct name

Brief steps to implement this solution are given in the full Quick Note at http://mediacast.sun.com/users/Michael.Czapski-Sun/media/QuickNote_001/details. The collaboration code will work in Java CAPS 5 and 6 Repository.

Saturday Feb 14, 2009

Java CAPS 6 Update 1 - Invoking MTOM Web Service using Java CAPS Classic Web Service Client

If we overlook the fact that using web services to transfer large payloads is a very stupid idea, we will be faced with the need to implement the optimisation mechanisms to make transfer of large payloads using web services a little less inefficient from the stand point of the size of the over-the-wire data to be transferred. The standardised, supported mechanism for this is the Message Transmission Optimisation Method (MTOM), http://en.wikipedia.org/wiki/MTOM. Java CAPS Repository-based Web Services don’t offer a convenient mechanism to provide MTOM support.

This note walks through the implementation of a Java CAPS Repository-based, eInsight-based web service consumer and the implementation of the EJB-based Web Service Wrapper Consumer for this service, which provides support for MTOM. The Note discusses how to exercise the wrapper service using the NetBeans web services testing facilities, how to trigger the Java CAPS Repository-based web service invoker and how to observe on-the-wire message exchanges. The invoker implementations discussed in this Note will invoke the web service providers discussed in an earlier Note, “Java CAPS - Exposing MTOM-capable Java CAPS Classic Web Service”, http://blogs.sun.com/javacapsfieldtech/entry/java_caps_exposing_mtom_capable.

The note is available at http://mediacast.sun.com/users/Michael.Czapski-Sun/media/Invoking_MTOM-WS_using_Java_CAPS_Classic.pdf/details

Friday Feb 13, 2009

Java CAPS - Exposing MTOM-capable Java CAPS Classic Web Service

If we overlook the fact that using web services to transfer large payloads is a very stupid idea, we will be faced with the need to implement the optimisation mechanisms to make transfer of large payloads using web services a little less inefficient from the stand point of the size of the over-the-wire data to be transferred.

The standardised, supported mechanism for this is the Message Transmission Optimisation Method (MTOM), http://en.wikipedia.org/wiki/MTOM. Java CAPS Repository-based Web Services don’t offer a convenient mechanism to provide MTOM support.

This note walks through the implementation of a Java CAPS Repository-based, eInsight-based web service and the implementation of the EJB-based Web Service Wrapper for this service, which provides support for MTOM. The Note discusses how to exercise the services using the NetBeans web services testing facilities and how to observe on-the-wire message exchanges.


The note is available at http://mediacast.sun.com/users/Michael.Czapski-Sun/media/Exposing_MTOM-capable_Java_CAPS_Classic_Web_Service.pdf/details

Thursday Jan 01, 2009

HL7 Processor Demonstration - Java CAPS 6/JBI and OpenESB

This Note walks the reader through development of a Java
CAPS 6/JBI-based / OpenESB-based solution that addresses a Healthcare-related
business problem. The Note elaborates on the healthcare background necessary to
get a notion of what is being done and why, and provides detailed steps
required to implement and exercise the solution to the business problem.



Updated note, where GlassFsish ESB v2.1 is used instead of Java CAPS 6, is available at http://blogs.czapski.id.au/2009/09/hl7-processor-demonstration-glassfish-esb-v2-1



We will use the HL7 Binding Component, the File Binding
Component, the JMS Binding Component, the SOAP/HTTP Binding Component, the BPEL
2.0 Service Engine, the JavaEE Service Engine, the HL7 Encoder and EJB-based
Web Services in a JBI-based solution.


In the process we will create XML Schema Documents (XSDs),
Web Services Description Language Documents (WSDLs), a BPEL 2.0 Business
Process, an EJB-based “Implementation First” web service, an EJB- and
WSDL-based “Interface First” web service, a bunch of Composite Applications,
BPLE 2.0 mapping, BPEL 2.0-based Web Service orchestration, on-the-fly
conversion of HL7 version 2.3.1 delimited messages to their XML equivalents. We
will get a pretty good exposure to what OpenESB and Java CAPS 6/JBI components
look like, how they work and how they can be used to create real business
solutions. Above all, we will develop and test a solution that is more
sophisticated then the customary “Hello World” examples but not so complex as
to take too long to build and become too hard to comprehend by a novice user.


The particular business problem and the particular solution
came about because once upon a time there was intent to build a series of
related OpenESB projects – HL7 Processor, MDM Processor and IEP Processor -
that would:



  • receive HL7 v2.x delimited messages

  • convert HL7 v2.x messages to their equivalent XML format

  • split message stream into ADT A01s, ADT A03s and other

  • convert A01s to an abbreviated Custom Patient XML format

  • convert A03s to an abbreviated Custom Discharge format

  • send Custom Patients to a JMS Queue for processing by a MDM solution

  • send Custom Discharges to a JMS Queue for processing by an IEM solution

  • have the MDM process Custom Patients into a Master Patient Index

  • have the IEP process Custom Discharges to flag excessive length of stay


The MDM Processor and the IEP Processor made it to the Sun CEC
2008 as demonstrations, with associated Tutorials by Tom Barrett, and
demonstration recordings by me. The HL7 Processor did not make it. With the
appearance of Java CAPS 6 Update 1 more JBI components made it into the
officially supported Sun product. While the HL7 BC and the HL7 Encoder did not
make it into this Update they will, eventually. Both components are already
available from the OpenESB site and can be installed into the Java CAPS 6
Update 1 installation as unsupported components. This is what we will do for
this Note.


The article with the complete note and referenced links is available at http://blogs.czapski.id.au/2009/01/hl7-processor-demonstration-java-caps-6jbi-and-openesb


For these interested in processing HL7 using GlassFish ESB v2.1 there is a blog entry, "GlassFish ESB v2.1, MySQL v5.1 - Make HL7 v2.3.1 Delimited Messages from Custom Delimited Records with HL7 Encoder and HL7 BC", at , which discusses, amongst other things, how to create a custom HL7 v2 ADT A04 XSD and a "match any" XSD.

Friday Dec 19, 2008

GlassFish ESB, Java CAPS 6 and OpenESB Illustrated Solution Development Screencasts

Following the CEC 2008 Conference in Las Vegas, where the Java CAPS Stream saw a bunch of presentations and demonstrations, I am happy to offer screencasts of the three demonstration sessions I recorded for the event.


The GlassFish ESB screencast is the ScreenCast of the CEC 2008 GlassFish ESB Essentials Lab
demonstration. This is a
recording of the demonstration described in detail by Tom Barrett in
the GlassFish ESB Tutorial and Lab document. The screencast is an extended version of what the CEC audience got to see. In this screencast I use the OpenESB distribution to discuss, design and implement an abbreviated Supply Chain solution
. I use the File BC, the SOAP/HTTP BC, BPEL 2.0 SE, the Customn Ecoder, the XSD Editor, the WSDL Editor, BPEL correlations, BPEL Pick wit Timer, CASA Editor and a bunch of other OpenESB/GlassFish ESB featiures and facilities. Watching the screencast will give you a pretty good idea what the tooling looks like, how easy it is ti use it, how a theoretical requriement can be turned into a practical design and how that design can be implemented and exercised using the tooling and infrastructure you can get free of charge and use as much as you might desire.


Data for the following two screencasts/demonstrations is produced by the solution discussed in the next blog entry, which ought to precede these two.



The Java CAPS 6/Mural Master data Management screencast is the ScreenCast of the CEC 2008 Java CAPS Essentials Master Data Management (MDM) Lab demonstration. This is a recording of the demonstration described in detail by Tom Barrett in the Java CAPS Essentials MDM Tutorial and Lab document. In the screencast I discuss what the Master Data Management (MDM) is, how a Healthcare enterprise might leverage it to improve its business and how the OpenESB or Java CAPS 6 can be used to implement MDM. I use OpenESB to design a Master Patient Index Data Model, implement it with the tool, generate Data Model-based Master Index Data Management Web Application, build an integration solution to feed the MDM solution with transactional data form Hospital Information Systems and build a broadcast processor solution that can be used to send master patient index updates to downstream systems which have a need to be kept in synch with the enterprise view of the patient. One will get a very good idea of what the core Master Data Management is about, how easy it is to create the MDM Application and related integration components using the OpenESB/Java CAPS 6 tooling, and how the business of maintaining master patient index looks and works like.



 The Java CAPS 6 / Intelligent Event Processor screencast is the ScreenCast of the CEC 2008 Java
CAPS Essentials IEP Lab demonstration. This is a recording of the demonstration described in
detail by Tom Barrett in the Java CAPS Essentials IEP Tutorial and Lab
document.The screencast is what the CEC audience got to see. In this screencast I demonstrate how an Intelligent Event Processing (IEP) solution is built and exercised. The solution addresses a Helathcare business problem - it calculates an Average Length of Stay for each patient in a sliding time window, based on data from an ADT A03 HL7 Discharge message, works out which patients' Length of Stay exceeds average for the patients in the window by 1.5 times, and passes records related to these patients
on while discarding 'normal' records.


The AVIs were recorded with Camtasis Studio. You may need a Camtasia Player to playe them on Windows. You could also try getting a Camtasis codec for your platform/player from the Camtasia site.


I had audio quality problems when directly playing the recordings through Mozilla, which used the Quicktime plugin. The best thing to do is to download the recordings and try different players until one works for you.;


This article, with links to the material, is available at http://blogs.czapski.id.au/2008/12/glassfish-esb-java-caps-6-and-openesb-illustrated-solution-development-screencasts



Monday Dec 08, 2008

Java CAPS 6, GlassFish ESB, Java Message Queue 4.1, Obtaining and using Java MQ Monitoring Metrics

Every now and then someone has a need/desire to collect and process performance and usage metrics of JMS destinations and the messaging system.  Knowing that there is a buildup of messages in a particular destination over time might indicate that a downstream component is failing or the downstream external system is not available. This, in turn, may enable operational staff in the enterprise to intervene before things get out of hand. In more sophisticated solutions, knowing that a buildup of messages occurs may enable the solution to automatically bring on line additional resources, perhaps by starting additional copies of appropriate components or starting additional machines which host consumers that will take up the load.

The Java Message Queue implementation (hereafter Java MQ) has monitoring metrics collection built in and provides a convenient way of programmatic access to these metrics.

Java CAPS 5.1, Java CAPS 6, GlassFish ESB (commercially supported subset of OpenESB) and OpenESB all provide support for the Java MQ as the messaging infrastructure so solutions can be built to take advantage of this functionality.

This Note presents example projects, built using Java CAPS 6 Classic components and an example built using the Java CAPS 6/GlassFish ESB JMS JCA Adapter, which receive and “process” Java MQ metrics. How you can take advantage of this capability in your enterprise solutions is up to you and your creativity.

About

In this Blog I post abstracts of articles / writeups / notes on various aspects of Java CAPS and SOA Suite including solutions, discussions and screencasts. The links to the referenced material are included in the bodies of the abstracts.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today