Saturday May 28, 2011

Using QBrowser v2 with WebLogic JMS for 10.3

WebLogic Server does not include a convenient tool to browse JMS destinations. Freely downloadable QBrowser version 2 tool, with some configuration, can be used to provide easy to use functionality to work with WebLogic JMS destinations. This article discusses how QBrowsers should be configured to work with the JMS destinations managed through the WebLogic Server 11g (10.3), which was the current version at the time this article was written.

The original article is available at http://blogs.czapski.id.au/2011/05/using-qbrowser-v2-with-weblogic-jms-for-10-3

Oracle SOA Suite 11g B2B HL7 v2 Inbound to WebLogic JMS Queue

I notice that people used to the eGate/Java CAPS way of doing things, when looking at migrating to the SOA Suite for HL7 messaging, are trying to reproduce the pattern "HL7v2AdapterJMS Queue". This is not necessary when using SOA Suite but can be done if one insists. This article walks through the process of implementing this pattern using Oracle SOA Suite 11g R1 PS3.

The process will follow these steps:
1. Obtain and configure the QBrowser tool for JMS browsing
2. Obtain and configure the HL7 Sender tool
3. Create two WebLogic JMS Queues to be used in the solution
4. Create and deploy a HL7 v2 Inbound Trading Partnership Agreement
5. Submit HL7 v2 messages and inspect them in the corresponding JMS Queue
6. Repeat steps 4 and 5 for another inbound stream

The original article, which can be found at http://blogs.czapski.id.au/2011/05/oracle-soa-suite-11g-b2b-hl7-v2-inbound-to-weblogic-jms-queue, demonstrates that Oracle SOA Suite B2B HL7 infrastructure can be configured to receive message streams over multiple inbound MLLP channels and deliver each stream to a distinct JMS destination, much as eGate and Java CAPS solutions used to do.

Saturday Oct 23, 2010

Healthcare Enterprise – IT Architecture Building Blocks - Canonical Message Model for a HL7 Enterprise

In any but the simplest of HL7 messaging environments there will be multiple sources and multiple destinations of HL7 messages. It is very unlikely that all, or even a majority of these, will use exactly the same HL7 message structures in terms of versions, optional/mandatory segments, extension Z segments, and so on. A sensible approach to dealing with these kinds of issues, and a key component of the HL7 Enterprise Architecture, is the so called Canonical (or Common) Message Model (CMM). The CMM works hand-in-glove with the enterprise architecture in which transformation to/from the CMM is performed at the edges of the integration domain. This article discusses major considerations and works through the mechanics of deriving a Canonical Message Model for a fictitious Healthcare Enterprise and implementing it using the Oracle SOA Suite 11g HL7 tooling as an example. The article will also discuss and illustrate a mechanism for injecting arbitrary metadata into the canonical message, generated by the B2B Document Editor, in such a way that it is ignored by the Edge-dwelling B2B infrastructure but is significant to the SOA infrastructure.

The original article is available at: http://blogs.czapski.id.au/2010/10/healthcare-enterprise-%e2%80%93-it-architecture-building-blocks-canonical-message-model-for-a-hl7-enterprise

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