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

Friday Jun 25, 2010

Oracle SOA Suite 11g HL7 Outbound Example

In this article I develop and exercise a simple Oracle SOA Suite 11g B2B infrastructure-based HL7 v2 Sender (outbound) project for an ADT A01 message and use Message tracker to view messages.

This article complements previous articles in the series, Oracle SOA Suite 11g HL7 Inbound Example and Oracle SOA Suite 11g HL7 Inbound Example – Functional ACK Addendum.

The original article is available at http://blogs.czapski.id.au/2010/06/oracle-soa-suite-11g-hl7-outbound-example

Wednesday Jun 23, 2010

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

This article is a follow on to the “Oracle SOA Suite 11g HL7 Inbound Example”, at http://blogs.czapski.id.au/2010/06/oracle-soa-suite-11g-hl7-inbound-example. In that article the B2B infrastructure was configured to return the “immediate ack” as soon as it received each message. The ACK was always a positive ACK, regardless of whether the message was valid or not and whether it was successfully processed.

In this article I expand on the previous post by adding the Functional ACK, an explicit ACK message, which is returned after a message is parsed and validated, if validation is required. This means that rather than always returning an ACK the receiver will return a NAK if the message is invalid.

The original article is available at http://blogs.czapski.id.au/2010/06/oracle-soa-suite-11g-hl7-inbound-example-functional-ack-addendum

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

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

Monday Jul 06, 2009

GlassFish ESB v2.1, MySQL v5.1 - Creating a Patient Service Web Service Provider

In some views SOA is represented as a series of 4 layers: Presentation Layer (SOA 1), Business Process Layer (SOA 2), Business Service Layer (SOA 3) and Technical Layer (SOA 4). Typically each layer higher up in the hierarchy consumes services exposed by the layer under it. So the Presentation Layer would consume services provided by the Business Process or Business Service Layers. Service interfaces are described using Web Services Description Language (WSDL), sheltering service consumers from details of service implementation. Web Services are seen as the technical means to implement the decoupled functional layers in a SOA development. Decoupling allows implementations of business functionality at different layers to be swapped in and out without disturbing other layers in the stack.

In this document I will implement a multi-operation Web Service that will allow patient information to be upserted into a database table and will return all patient details for a patient whose Facility+Local ID are specified in the request. This service will be used to populate the patient table and to implement patient lookup portlets, discussed in other writeups in this series. This is a basic Patient Service that hides the specifics of interaction with the patient data store form applications that need to interact with it, by providing a defined interface and web service-based implementation. Thus the data store may change but the service consumers need not. We use the Database BC with select, insert and update operations and Database BC with SQL File-based parameterized SQL prepared statement. We handle null value insertion on missing data. We also use the SOAP/HTTP BC and the BPEL SE.
The business idea is that patients are looked after in various healthcare facilities. Information about patients is stored in a relational database. This information must be inserted, for new patients, and updated, for existing patients, as required. Frequently applications need to search for a patient and display details to human operators. To shelter application developers from the details of the data store the upsert functionality and patient details lookup functionality will be made available as a multi-operation web service.

Walkthrough Document: 02_PatientSvc_GFESBv21.pdf
Companion Archive: 02_PatientSvc_companion_archive.zip

Saturday Jun 27, 2009

Healthcare Facility Mashup Portlet with Google Map - GlassFish v 2.1, Web Space 10, Web Service and REST Service

The Portlet developed in the previous blog gives plain facility details. A richer Portlet could use the facility address to show the facility location on a Map.

Here I will walk through development of a Visual Web JSF Mashup Portlet, which will use a Web Service as a data provider to get facility details and a Google Maps REST Service to get the Google map displaying facility location. I use the NetBeans 6.5.1 IDE, part of the GlassFish ESB v2.1 installation, the Portal Pack 3.0.1 NetBeans Plugin and the JSF Portal Bridge provided by the Web Space Server 10. The Portlet will use JSF components provided by Project Woodstock. The Google Map service is integrated into NetBeans IDE. Technologies will be introduced in a practical manner.

It took me some effort to work out how to add a Google Map to a Portlet so I though I will share the experience.

This is not a tutorial on JavaServer Faces, Visual Web JSF, Project Woodstock, Portlet development or Google Maps usage.

Here is the document: 01_FacilityService_WebSpacePortletWithGoogleMap.pdf

Here is an archive containing all the projects developed in this and the last 3 blog entries: 01_FacilityService_all_project.zip

As provided, the ui_facility table has a bunch of addresses which are fairly silly and will never get a proper map. This MySQL script has a bunch of SQL update statements to replace these addresses with real addresses that are mappable.

Wednesday Jun 24, 2009

NetBeans 6.5.1, GlassFish v 2.1, Web Space Server 10 - Creating a Healthcare Facility JSR286-compliant Portlet

In some views SOA is represented as a series of 4 layers: Presentation Layer (SOA 1), Business Process Layer (SOA 2), Business Service Layer (SOA 3) and Technical Layer (SOA 4). Typically each layer higher up in the hierarchy consumes services exposed by the layer under it. So the Presentation Layer would consume services provided by the Business Process or Business Service Layers. Service interfaces are described using Web Services Description Language (WSDL), sheltering service consumers from details of service implementation. Web Services are seen as the technical means to implement the decoupled functional layers in a SOA development. Decoupling allows implementations of business functionality at different layers to be swapped in and out without disturbing other layers in the stack. The SOA 1, Presentation Layer, is often implemented as JSR-168-compliant or JSR-286-complaint Portlets, exposed through a standards-based Portal.

The business idea is that patients are looked after in various healthcare facilities. Applications need to allow selection of a facility and to access facility details for display to human operators. A relational holds details of facilities which are a part of the healthcare enterprise. Facility list and details are available through a web service. This web service will be used to construct the JSR-286-comliant Portlet that provides a user view into the facilities and facility details. This Portlet will be deployed to the Sun FOSS Web Space Server 10 Portal.

Previous documents in this series, “GlassFish ESB v 2.1   Creating a Healthcare Facility Web Service Provider”, at http://blogs.sun.com/javacapsfieldtech/entry/glassfish_esb_v_2_1 and “NetBeans 6.5.1 and GlassFish v 2.1 - Creating a Healthcare Facility Visual Web Application”, http://blogs.sun.com/javacapsfieldtech/entry/netbeans_6_5_1_and, walked the reader through the process of implementing a GlassFish ESB v2.1-based web service which returns facility list and facility details, and a Visual Web JSF Web Application which used that Web Service to display facility list and details.
In this document I will walk through the process of developing a JSR-286-compliant Visual Web JSF Portlet, deployed to the Sun Web Space Server 10 Portal, which will use the Web Service as a data provider. We will use the NetBeans 6.5.1 IDE, which comes as part of the GlassFish ESB v2.1 installation, the Portal Pack 3.0.1 NetBeans Plugin and the JSF Portal Bridge infrastructure provided by the Web Space Server 10. The Portlet will be implemented as a Visual Web JavaServer Faces Portlet using JSF components provided by Project Woodstock. The Portlet will introduce the technology in a practical manner and show how a web service can be used as a data provider, decoupling the web application from the data stores and specifics of data provision.

Note that this document is not a tutorial on JavaServer Faces, Visual Web JSF, Project Woodstock components or Portlet development. Note also that all the components and technologies used are either distributed as part of the NetBeans 6.5, as part of the GalssFish ESB v2.1, as part of the Web Space Server 10 or are readily pluggable into the NetBeans IDE. All are free and open source.

Here is teh document: 01_FacilityService_WebSpacePortlet.pdf

Tuesday Jun 23, 2009

NetBeans 6.5.1 and GlassFish v 2.1 - Creating a Healthcare Facility Visual Web Application

In some views SOA is represented as a series of 4 layers: Presentation Layer (SOA 1), Business Process Layer (SOA 2), Business Service Layer (SOA 3) and Technical Layer (SOA 4). Typically each layer higher up in the hierarchy consumes services exposed by the layer under it. So the Presentation Layer would consume services provided by the Business Process or Business Service Layers. Service interfaces are described using Web Services Description Language (WSDL), sheltering service consumers from details of service implementation. Web Services are seen as the technical means to implement the decoupled functional layers in a SOA development. Decoupling allows implementations of business functionality at different layers to be swapped in and out without disturbing other layers in the stack.

The business idea is that patients are looked after in various healthcare facilities. Frequently applications need to allow selection of a facility and to access facility details for display to human operators. A relational database is used to hold the details of facilities which are a part of the healthcare enterprise. To shelter application developers from the details of the data store facility list and details are made available as a multi-operation web service. This web service will be used to construct the web application that provides a user view into the facilities and facility details.

The previous document in this series, “GlassFish ESB v 2.1   Creating a Healthcare Facility Web Service Provider”, at http://blogs.sun.com/javacapsfieldtech/entry/glassfish_esb_v_2_1, walked the reader through the process of implementing a GlassFish ESB v2.1-based, multi-operation web service which returns facility list and facility details. In this document I will walk through the process of developing a Visual Web Application which will use the Web Service as a data provider. We will use the NetBeans 6.5.1 IDE, which comes as part of the GlassFish ESB v2.1 installation. The application will be implemented as a Visual Web JavaServer Faces Application using JSF component provided by Project Woodstock. This application will introduce the technology in a practical manner and show how a multi-operation web service can be used as a data provider, decoupling the web application from the data stores and specifics of data provision.

Note that this document is not a tutorial on JavaServer Faces, Visual Web JSF, Project Woodstock components or Web Application development. Note also that all the components and technologies used are either distributed as part of the NetBeans 6.5, as part of the GalssFish ESB v2.1 or are readily pluggable into the NetBeans IDE. All are free and open source.

It is assumed that a GlassFish ESB v2.1-based infrastructure, supplemented by the Sun WebSpace Server 10 Portal functionality and a MySQL RDBMS instance, are available for development and deployment of the web application discussed in this paper. It is further assumed that the web service, developed using instructions in “GlassFish ESB v 2.1 - Creating a Healthcare Facility Web Service Provider”, at http://blogs.sun.com/javacapsfieldtech/entry/glassfish_esb_v_2_1, is available and deployed to the infrastructure. The instructions necessary to install this infrastructure are discussed in the blog entry “Adding Sun WebSpace Server 10 Portal Server functionality to the GlassFish ESB v2.1 Installation” at http://blogs.sun.com/javacapsfieldtech/entry/adding_sun_webspace_server_10, supplemented by the material in blog entry “Making Web Space Server And Web Services Play Nicely In A Single Instance Of The Glassfish Application Server”, at http://blogs.sun.com/javacapsfieldtech/entry/making_web_space_server_and.

Here is the document - 01_FacilityService_WebApplication.pdf

Monday Jun 22, 2009

GlassFish ESB v 2.1 - Creating a Healthcare Facility Web Service Provider

In some views SOA is represented as a series of 4 layers: Presentation Layer (SOA 1), Business Process Layer (SOA 2), Business Service Layer (SOA 3) and Technical Layer (SOA 4). Typically each layer higher up in the hierarchy consumes services exposed by the layer under it. So the Presentation Layer would consume services provided by the Business Process or Business Service Layers. Service interfaces are described using Web Services Description Language (WSDL), sheltering service consumers from details of service implementation. Web Services are seen as the technical means to implement the decoupled functional layers in a SOA development. Decoupling allows implementations of business functionality at different layers to be swapped in and out without disturbing other layers in the stack.
In this document I will walk through the process of developing a SOA Composite Application, exposed as a Web Service, which will make available simple business functionality using a multi-operation service. We will use the GalssFish ESB v2.1 infrastructure. The service will use the SOAP/HTTP Binding Component, the Database Binding Component and the BPEL 2.0 Service Engine. This simple service will introduce the components and discuss how a multi-operation web service can be constructed using the GalssFish ESB.
The business idea is that patients are looked after in various healthcare facilities. Frequently applications need to allow selection of a facility and to access facility details for display to human operators. A relational database is used to hold the details of facilities which are a part of the healthcare enterprise. To shelter application developers from the details of the data store facility list and details will be made available as a multi-operation web service. This web service will be used elsewhere to construct a portlet that can be used in an enterprise portal.

The document is available as 01_FacilityService_GFESBv21.pdf

Late breaking news: The MySQL JDBC Driver, which I used in the example, mysql-connector-java-5.1.7-bin.jar, and which is distributed with the GlassFish ESB v2.1, causes connection pool exhaustion and other issues with the example. If you experience these issues pleases download the latest MySQL JDBC Driver, mysql-connector-java-5.1.7-bin.jar as at now, from http://dev.mysql.com/downloads/connector/j/5.1.html and replace the original in domains/domain1/lib/ext.


Thursday Jun 12, 2008

Java CAPS 6/JBI Note 2 - Basic File-to-File projects with multi-record files

This document is intended to help you get over the initial hurdles of exploring Java CAPS 6/JBI and OpenESB. It walks through the process of creation, deployment and execution of a simple File-to-File integration solution, and a simple File to BPEL Process to File solution, with detailed step-by-step illustrations. Both solutions use inbound files with multiple records. The focus is the practice of using JBI components not the theory of JBI. This document addresses the integration solution developers, not developers of Service Engines or Binding Components. The projects use JBI components only, that’s why they are just as good for OpenESB exploration as they are for Java CAPS 6/JBI exploration. JBI (Java Business Integration) is not discussed to any great extent. JBI artifact names are used in discussion but not elaborated upon. Explanations are provided where necessary to foster understanding of the mechanics of developing integration solutions using JBI technologies in OpenESB and Java CAPS 6/JBI. Java CAPS 6 and OpenESB are two of a number of toolkits that implement the JBI specification (JSR 208). When I use an expression like “In JBI …” I actually mean “In JBI as implemented in Java CAPS 6 and OpenESB …”. The same things may well be implemented differently in other JBI toolkits. Java CAPS 6 “Revenue Release” is used and shown in illustrations. OpenESB can be used instead however the appearance of components shown in illustrations may vary somewhat.


02File2FileMultiRec.pdf contains the complete solutin writeup.

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 2015
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