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 Jun 27, 2010

Oracle SOA Suite 11g HL7 Inbound Example - Back End-constructed Functional ACK Addendum

This article is a follow on to the “Oracle SOA Suite 11g HL7 Inbound Example – Functional ACK Addendum” article and the “Oracle SOA Suite 11g HL7 Inbound – Customized HL7 Message Structure and Data Validation” article. In these articles the B2B infrastructure was configured to return the “Functional ACK” when it validated each message. The ACK was a positive or a negative ACK depending on whether the message passed validation. The ACK was generated by the B2B Layer before the message was passed on to the SOA Layer.

In this article I expand on the previous posts by configuring the B2B Layer to pass the message to the SOA Layer and pass the Functional ACK, generated by the SOA Layer on to the requester. To process a message and produce the ACK we will build and deploy a new SOA Composite.

The original article, Oracle SOA Suite 11g HL7 Inbound Example – Back End-constructed Functional ACK Addendum, is to be found at http://blogs.czapski.id.au/2010/06/oracle-soa-suite-11g-hl7-inbound-example-back-end-constructed-functional-ack-addendum

Saturday Jun 26, 2010

Oracle SOA Suite 11g HL7 Inbound - Customized HL7 Message Structure and Data Validation

Messages we used in previous articles dealing with HL7 Inbound (Oracle SOA Suite 11g HL7 Inbound Example – Functional ACK Addendum, Oracle SOA Suite 11g HL7 Inbound Example) were not strictly speaking valid according to the default HL7 V2 ADT A01 message specification produced by the Oracle B2b Document Editor. Both the message structure was not quite right and the data was not quite right. To allow such messages in, we disabled Validation property in the B2B Trading Partnership Agreement.

In this article we will alalyze the data and  create a customized HL7 v2 ADT A01 structure which will allow us to successfully validate incoming messages. We will then modify the document definition and Partnership Agreements to use this custom structure and validate messages as they come in.

The customization discussed in this article only scratches the surface of what is possible with the Oracle B2B Document Editor.

The original article is available at http://blogs.czapski.id.au/2010/06/oracle-soa-suite-11g-hl7-inbound-customized-hl7-message-structure-and-data-validation

Saturday Jun 19, 2010

Oracle SOA Suite 11g HL7 Inbound Example

As Sun Microsystems, and SeeBeyond before it, Oracle provides support for integration of systems which use HL7 v2.x messaging. Unlike Sun, and SeeBeyond before it, Oracle treats HL7 messaging as Business to Business exchanges (B2B) and uses the B2B part of the Oracle SOA Suite to accomplish the task [1].

In this article I develop and exercise a simple Oracle SOA Suite 11g B2B infrastructure-based HL7 v2 Receiver project for an ADT A01 message and use Message tracker to view messages, message states and messaging performance.

The original article can be found at http://blogs.czapski.id.au/2010/06/oracle-soa-suite-11g-hl7-inbound-example

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 27, 2010

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

In the blog entry "GlassFish ESB v2.2 Field Notes - Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions" 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 " through the blog article Recording of a dmonstration of the “GlassFish ESB v2.2 Field Notes – Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions” at http://blogs.czapski.id.au/2010/01/recording-of-a-dmonstration-of-the-glassfish-esb-v2-2-field-notes-exercising-load-balanced-highly-available-horizontally-scalable-hl7-v2-processing-solutions

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

Sunday Jan 10, 2010

GlassFish ESB v2.2 Notes - HL7 v2 Handling - Notable improvements in BPEL Mapper

GlassFish ESB v2.2 was released in late December/early January 2010. This release brings a number of design-time improvements in handling HL7 v2 messages. Some of these have been on my and other people’s wish lists for years.

HL7 v2 structure nodes use full names, rather then acronyms like MSH.1.
In BPEL, mapping can be performed at message, segment, component, subcomponent and field level.

These improvements are noteworthy enough to warrant a note, to be found at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-2-notes-hl7-v2-handling-notable-improvements-in-bpel-mapper

Saturday Jan 09, 2010

GlassFish ESB v2.2 Field Notes - Ephemeral, JVM-global, POJO-based Sequence Number Generator for BPEL

When working on the HA solutions discussed in my HA blog ebntry I realized that it will be difficult to work out whether messages are delivered in order, as was required, and whether any are missing. I got over the issue by ensuring that my test data was prepared in such a way that messages in each test file had increasing, contiguous sequence numbers embedded in the message. For HL7 v2, which is the messaging standard with which I dealt, I used MSH-10, Message Control ID field. I wrote processed messages and acknowledgments to files whose names embedded MSH-10 Message Control Id, with the sequence number, so breaks in sequence and out of order messages could be readily detected.

With multiple message files containing between 1 and 50,000 messages, adding a sequence number to each message by hand was clearly out of the question.

I put the GlassFish ESB to use. I constructed a file-to-file BPEL module project to read each test file and to prepend a sequence number to each message’s MSH-10 field. The only snag was how to get a sequence number that would start at 0 and increase by 1 for each message, such that each BPEL process instance would get the next sequence, and that messages would be written to the output file in order.

This note discusses how I went about accomplishing the task.

The original article is available as GlassFish ESB v2.2 Field Notes – Ephemeral, JVM-global, POJO-based Sequence Number Generator for BPEL at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-2-field-notes-ephemeral-jvm-global-pojo-based-sequence-number-generator-for-bpel

Tuesday Jan 05, 2010

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

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 article is available at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-2-field-notes-exercising-load-balanced-highly-available-horizontally-scalable-hl7-v2-processing-solutions

Thursday Sep 17, 2009

GlassFish ESB v2.1 - Excessive length of Stay Healthcare IEP Demonstration

As a healthcare enterprise looks after patients, information is gathered about various events that take place. Information about notable events, Admissions and Discharges, for example, is recorded in Hospital Information Systems or Patient Administration Systems. These systems typically broadcast event information in a form of HL7 messages for use by other enterprise systems, for example laboratory or diagnostic imaging. A stream of HL7 messages can be intercepted and processed to derive all sorts of interesting information.

The solution developed in this walkthrough deals with Excessive Length of Stay. Length of stay is defined as the period between patient’s admission to and discharge from the hospital. Statistical average expected length of stay is typically available for different kinds of patients presenting with different kinds of conditions. A significant variation from the average length of stay for specific patients may indicate complications, treatment errors, infections and other kinds of issues that the hospital needs to investigate. Notification of such incidents may help the hospital in addressing these issues and prevent future occurrences.

In this solution the Intelligent Event Processor is used to calculate the continuously updated average length of stay over a period of time and use it to compare against each event’s length of stay. It passes, to the downstream component, all events where the length of stay exceeds the average by 1 ½ times and ignores all others.

In the initial iteration, the solution reads a stream of discharge messages, containing admission date, discharge date, length of stay, and a bunch of other fields from a file and passes them to the IEP process. The IEP process keeps the window on the last 10 seconds worth of records and continuously calculates the average length of stay over all records in that window. As records are added to and removed from the window the average is recalculated. As each record is seen its length of stay is compared to the average length of stay of all records in the window at the time. If the length of stay in the current record is less then or equal to 1 ½ times the average at the same time the record is discarded. If the average is greater the record is ejected to the output and ultimately written to a file of exception records.

In a subsequent iteration the solution is modified to accept messages from a JMS Queue. This modification allows the solution to use the stream of discharge messages produced by the HL7 Processor solution, discussed in “HL7 Processor Demonstration - GlassFish ESB v2.1”.

In a further modification the solution is configured to send notification messages to another JMS Queue. Notification messages are processed by a different solution and sent to an email recipient.

The article and referenced materials are available at http://blogs.czapski.id.au/2009/09/glassfish-esb-v2-1-excessive-length-of-stay-healthcare-iep-demonstration

Saturday Aug 01, 2009

Patient Lookup Portlet with a Google Map, Route and Directions

In this walkthrough I will add a Google Map showing a Route between patient’s home address location and the location of patient's facility of record, as well as directions to follow along this route, to the Visual Web JSF Portlet developed in “Patient Lookup Visual Web JSF Portlet with a nicer looking Google Map”.

The walkthrough document is here: 02_PatienLookup_VWJSFPortletGooRoute.pdf

The comnpanion archive with NetBeans project artifacts is here: PatientLookupGooRouteVWJSFP.zip

Friday Jul 31, 2009

Patient Lookup Visual Web JSF Portlet with a nicer looking Google Map

The previous blog, walked through development and deployment of the Patient Lookup Portlet with a basic Google Map centered at the location identified by patient address, if any. It was a fairly basic Google Map, as Google maps go. In this document I will add a better looking Google Map to the Patient Lookup Portlet, explicitly using Google Maps APIs to construct the map.

The walkthrough is here: 02_PatienLookup_VWJSFPortletGooMapFancy.pdf

The companion archive, containing the NetBeans project, is here: PatientLookupGooMapBetterVWJSFP.zip

Wednesday Jul 22, 2009

GlassFish v 2.1, Web Space Server 10 - Patient Lookup Visual Web JSF Portlet with a basic Google Map

The business idea behind the functionality developed in this walkthrough is that patients are looked after in various healthcare facilities. Healthcare workers need to lookup patient details such as their identifier, gender, birth date or address. A relational database holds patient details as well as other information of relevance such as descriptions of various coded values. Patient details are available through a web service. Facility list and details, used to narrow down the search for patients to a specific facility, are available through a web service. These web services will be used to construct the Portlet that will allow patient search and a display of patient details with display a Google Map, centered at patient’s address, if one is available and is valid for the purpose of mapping. This Portlet will be deployed to the Sun FOSS Web Space Server 10 Portal.

The previous blog entry walked through development and deployment of the basic Patient Lookup Portlet. In this document I add a basic Google Map to the Patient Lookup Portlet.

Other blog entries in this series walked the reader through the process of implementing GlassFish ESB v2.1-based web services which return facility list and facility details as well as patient details.

Note that this walkthrough builds on the Patient Lookup Portlet, built previously, but deals exclusively with Visual Web JSF portlet-related technologies, Java Script and Google Maps API.

The walkthrough document is here: 02_PatienLookup_VWJSFPortletGooMapBasic.pdf

The project archive is here: PatientLookupGooMapBasicVWJSFP_companion_archive.zip
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