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: • • • • • • • • • • • • • • • •
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 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: • • • • • • • • •
May 14

Java CAPS 5.1, Implementing WS-Security 1.0 (2004) with JAX-RPC

By Michael Czapski Sun 2 Comments »

A couple of years ago I worked out how to supplement WS-Security infrastructure in Java CAPS 5.1.1 with additional services that WS-Security 1.0 (2004) supports, namely SOAP Message Security, X.509 Certificate Token Profile and Timestamp Token Profile. Together these provide Java CAPS solutions with XML Digital Signatures, XML Encryption, Sun Access Manager-mediated Username-based authentication and Timestamp support.

The attached document is 1 and a half years old. It makes statements about Username Token support in Java CAPS 5.1.1 being broken. Java CAPS 5.1.3 supports Username Token just fine so these statements are no longer true. Java CAPS 5.1.3 U2 adds a mechanism for hooking SOAP envelope handlers into the Java CAPS Web Services framework so what I did and described in the document can now be done differently – perhaps better and more transparently. I have not tried.

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

“JCAPS with JWSDP 2.0, Implementing WS-Security_1.1_JCAPS5.1.1.pdf” – discussion paper

Supporting materials are over 40Mb so I can’t post them to the blog. If anyone is interested says so.

Well, someone said so. The archive, WSSecSampleProject_1.2_JCAPS5.1.1.zip, is posted. Please understand that this is “all care and no responsibility” material. I don’t have the time to spend working through issues with individual people. It all worked at the time I put it together and on occasions since. It ought to work for you as well 🙂

Tagged with: • • • •
Jan 11

Java CAPS 5.1.3 – Sun SeeBeyond IS – Logging to additonal destinations

By Michael Czapski Sun No Comments »

By default, the Sun SeeBeyond Integration Server domain uses a single log to log all events, whether arising out of execution of the Integration Server or arising out of execution of Java CAPS solutions deployed to it. This log is named server.log and is kept in the <JavaVACPInstallRoot>/logicalhost/is/domains/<domainroot>/logs directory.

This note discusses how the Integration Server can be configured to deliver all or selected events to an additional log handler and how XML-formatted event information can be obtained. This note also presents some ideas on multiple logging destinations and notification.

Here is the Note itself: Java CAPS 51 – logging to additional destinations.pdf

Warning

The writing of this note, and the underlying development and configuration work, were prompted by repeated questions about logging in Java CAPS, in particular how it could be made to behave like it used to in the non-J2EE versions of the SeeBeyond EAI products. For these readers who are still waiting for the answer they like – there will be no such answer coming. It is not possible to configure logging for ‘your interface’ separately from logging for all other ‘interfaces’ since there is no notion of ‘your interface’ as a separate component in Java CAPS. There is no way to collect logging information pertaining to a specific project or deployment in such a way that all relevant information is collected, no information is lost and no information on unrelated components is included.

Tagged with: • • • •
Dec 26

Java CAPS 5.1.3 – Sun SeeBeyond IS – Note 1 – Logging management with isadmin

By Michael Czapski Sun No Comments »

In Java CAPS 5.1 the Sun SeeBeyond Integration Server is a modified version of the Sun Application Server 8.0 Platform Edition. As such a number of things that can be done with that application server can be done with the Sun SeeBeyond Integration Server. Most notably, it can be managed at runtime using the isadmin tool much the same way as the Sun Application Server 8.0 PE can be managed using the asadmin tool.

This note discusses how the isadmin tool can be used to manage runtime logging of the Sun SeeBeyond Integration Server. This note applies to the Sun SeeBeyond Integration Server included in Java CAPS 5.1.

Tagged with: • • • •
Nov 25

Java CAPS 5.1.3 Correlation Example 2 – ELS Static Counted

By Michael Czapski Sun No Comments »

This example implements a part of the ELS functionality dealing with linking a number of related messages, a counted correlation pattern, or an aggregator pattern.

Unlike the simple implementation from Example 1, this implementation will correlate a varying number of messages, statically set at design time. Thus the same implementation can be used to correlate 2, 3, 10 or 30 messages, by modifying the value of a single business process attribute. By obtaining the value of the business process attribute, which controls the message count, from the environment or the initial message, one will change the static implementation into a dynamic counted correlation solution.

CorrelationExample_02_StaticCounted.pdf discusses the example and addresses key points in its implementation.

CountedStatic.zip is a Java CAPS 5.1.3 project export that implements the correlation in this example.

Tagged with: • • • • • •
Nov 24

Java CAPS 5.1.3 Correlation Example 1 – ELS Counted Messages

By Michael Czapski Sun 4 Comments »

Correlations are probably the single least understood area of eInsight functionality. The example discussed in the attached document implements one of the “Event Linking and Sequencing” patterns, present in e*Gate 4.5 and eGate SRE, that is alleged to have been lost in ICAN and Java CAPS. In as much as implementing ELS in eInsight 5.1 using correlation requires some development, rather then just configuration, one could argue that it was lost. In as much as implementing ELS in eInsight 5.1 is possible and relatively simple, one could also argue the opposite.

The example discussed in the document, and illustrated with the Java CAPS 5.1.3 project export, implements a part of the ELS functionality dealing with linking a specific number of related messages, a counted correlation pattern, or an aggregator pattern.

CorrelationExamples_01_SimpleCountedTwo.doc – writeup

CountedSimple.zip – Java CAPS 5.1.3 Project Export

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