Integrating Curam applications with legacy systems using WebSphere Message Broker

Part of the IBM Smarter Planet initiative, Curam Social Enterprise Management software provides enterprise solutions for workforce services and social security. This article shows you how to integrate Curam with external insurance company and government agency systems using WebSphere Message Broker V8.

Share:

Jayanta Ranjan Das (jayrdas2@in.ibm.com), Integration Architect, IBM

Photo of Jayanta Ranjan DasJayanta Ranjan Das is an Integration Architect and IBM certified IT architect with 13 years of IT industry experience. He has worked as a Solution Architect, SOA Architect, Integration Architect, and Application Architect. You can contact Jayanta at jayrdas2@in.ibm.com.



02 October 2013

Introduction

Curam, the leading provider of solutions for social program management, is now part of the IBM Smarter Planet initiative. The IBM Social Industry Model is a comprehensive business framework for social organizations that identifies processes and analytical models to describe an organization's role within a country's social system. It also provides a reference architecture to help externalize processes and implement solutions that integrate Curam with legacy systems.

Social enterprise software like Curam must work with many external systems in fields such as Health Care, Housing, Criminal Justice, Labor, and Insurance. its features include a single point of entry for access to multiple programs; the ability to adapt quickly to changing programs, policies, and procedures; and easy connection to other systems via MQ/JMS queues and Curam Connectors. For facade and process-class operations with a stereotype of qconnector, the Curam generator produces code that converts the operation parameter into an MQ/JMS message, places the message on a queue, and optionally waits for a message in response, which is then converted back into a Curam structure.

Figure 1
Figure 1

Business case and solution architecture

A Curam system can be integrated in various ways, including web services, flat files, and MQ queues. The Health Insurance Portability and Accountability Act (HIPAA) defines policies, procedures, and guidelines to maintain the privacy and security of individually identifiable health information and eligibility criteria. It includes several programs to control fraud and abuse within the healthcare system. HIPAA defines standardized transactions with three-digit numerical identifiers. For example, 270, 271, and 834 transactions are related to healthcare eligibility and benefits. For example, in a 270 transaction, a provider submits a secure electronic request to determine the eligibility and benefit information for a particular patient. After receiving a 270 inquiry, the health authority responds with a 271 transaction, which includes the client eligibility status and benefit information from the patient's health plan.

Figure 2. Solution architecture
Solution architecture

This article shows you how to integrate Curam with legacy systems using WebSphere Message Broker V8 to check health care eligibility -- a 270 transaction. This kind of transaction is typically sent by healthcare providers such as hospitals, to insurance companies or government programs such as Medicare or Medicaid, or to other organizations that have individual health insurance information. The 270 transaction is used for inquiries about what services are covered for particular patients as well as for general information on coverage and benefits. For example, a 270 transaction might be used to inquire about wheelchair rental, diagnostic lab services, or physical therapy services. The 270 document typically includes:

  • Name and information for the sender of the inquiry (the information receiver)
  • Name and information for the recipient of the inquiry (the information source)
  • Medical plan details
  • Eligibility and benefits information

Design details

Figure 3
Figure 3

The system explained in the article facilitates real-time and messaging interfaces between the above solution and the external system with which it communicates. Capabilities within Curam, WebSphere Message Broker, and WebSphere MQ are used as part of this architecture. Connectors for WebSphere MQ, web services, SQL rules engine, and Curam Enterprise Framework Technology Services enable open, standard- based interoperability and integration.

Most social enterprises implementing a Curam system have a range of in-house systems developed over many years and using a variety of technologies and platforms. Rather than redeveloping these systems, which in many cases are highly functional and stable, it is much more cost-effective to have new systems interface with them using the Curam MQ/JMS Connector and Web Services Connector.

MQ/JMS Connector

The Curam MQ/JMS Connector enables a Curam application to connect to other systems by means of MQ/JMS queues. For Curam-modeled operations marked with the appropriate MQ/JMS Connector, connections are not created directly, but are built using a connection factory. Factory objects are stored in a JNDI namespace, insulating the application from provider-specific information. The fields in the parameter structure are scanned using Java reflection, and each is converted into a fixed-length string based on its datatype.

Web Services Connector

Web services have emerged as the enabling technology of choice for SOA, and have become very popular with social enterprises looking to wrap legacy functionality for reuse in enterprise systems. Curam applications can act as both as providers and consumers of web services. Curam developers can specify external web service definitions for use in Curam applications, as well as expose Curam functionality as web services.

MQ Connector operations

The Curam system generator produces code that converts operation parameters into an MQ message. Curam connectors enable a Curam application to connect to other systems using MQ queues. The Process/Facade class contains operations with a stereotype of <<qconnector>>, which puts the message on a queue, and optionally waits for a message in response, which is then converted back into a Curam structure.

In the above scenario, when a Curam system registers a new person, it checks their eligibility for a benefit by putting a message in the queue. This message contains details of the sender (name and contact information), name of the recipient, details of the health plan subscriber, information on benefit eligibility, and so on. The message will be read and transformed by WebSphere Message Broker according to the legacy system format. After transformation, WebSphere Message Broker will write the message to a flat file and FTP it to the legacy system for further action.

The sections below show how to use Rational Software Architect to import files, then Curam for modelling, then WebSphere Application Server for configuration, and finally, WebSphere Message Broker to create a message flow.

Setting up the environment in Rational Software Architect and modeling in Curam

  1. In the Rational Software Architect development environment, import the .project files located in the Curam CDEJ and webclient folders into the EJBServer folder.
  2. After the projects are imported, there will be a number of classpath variable errors. To resolve them, select Windows => Preferences => Java => Build path => Classpath variables, and then set the classpath.
  3. Go to the Rational Software Architect Modeling View. In the workspace, click the EJBServer folder, then go to the custom folder, right-click, and open the required file. Figure 4 shows the ParticipantRegistration file:
    Figure 4
    Figure 4
  4. Right-click on the class to add an operation from the list. Add the qconnector method to the class. Curam will use this operation to put the message in the MQ/JMS queue:
    Figure 5
    Figure 5
  5. The qconnector method is added to class, as shown in Figure 6:
    Figure 6
    Figure 6
  6. Once done with the modeling, use this method in the class and put the logic inside the method. Then build the application using build server and build database commands:
    Figure 7
    Figure 7
    Figure 8
    Figure 8

Configuring WebSphere Application Server to create a queue connection factory

To transfer the message from the Curam application to WebSphere Message Broker, configure the queue setting in WebSphere Application Server, which will be used to transfer messages to WebSphere Message Broker.

  1. In the left navigation pane of the admin console, expand Resources => JMS:
    Figure 9
    Figure 9
  2. Click on Queue connection factories and fill in the application server settings.
  3. Configure the queue manager and queue name, which is called by a Curam operation via JNDI.

Designing a message flow using WebSphere Message Broker

This section shows you how to use WebSphere Message Broker to design a message flow to consume the Curam message, transform it, and transfer it to an external system:

Figure 10
Figure 10
  1. Enter the project name as CuramIntegrationProject and click Finish:
    Figure 11
    Figure 11
  2. Right-click on CuramIntegrationProject and create a message flow:
    Figure 12
    Figure 12
    Figure 13
    Figure 13

The sample message flow below uses the MQInput node to receive messages from Curam. It provides the message in a Curam flat-file format. After receiving the message at the 270CuramInput node, WebSphere Message Broker checks the transaction type in a Compute node called RouteMessage. Based on the transaction type, the message flow routes the message to a 270Label or 834Label node. For transaction type 270, a 270MessageGeneration node retrieves the field details from the message tree and uses a Java utility to transform the message to the format needed by the legacy system. After the message is transformed to the legacy system format, it is sent to a 270FileGeneration node. This node generates a flat file, which is FTP'd to the legacy system to check the benefit eligibility of the person.

  1. Create a message flow as shown below:
    Figure 14. Sample Message Flow
    Figure 14
  2. After creating the message flow, set the node properties for the 270CuramInput node (an MQInput node), and provide the queue name as 270.IN. Also, connect the catch and failure options to MQOutput nodes:
    Figure 15
    Figure 15
  3. Provide the message domain and message name, as shown in Fig 15:
    Figure 16
    Figure 16
  4. Create the message model, which will be used by the MQInput node to get the data from Curam. The sample message structure has 18 fields that need to be created. To create the message Model, right-click on Current lib and select New => Message model:
    Figure 17
    Figure 17
  5. Select Other text or binary and then click Next:
    Figure 18
    Figure 18
  6. Click Create a DFDL schema using this wizard:
    Figure 19
    Figure 19
  7. Provide the DFDL schema file name and Message name:
    Figure 20
    Figure 20
  8. Provide the data format parameters: End of record character, Body fields, Field separator, and so on, and then click Finish:
    Figure 21
    Figure 21
  9. The window below opens, showing the structure created. Enter the Field names and Data type:
    Figure 22
    Figure 22
  10. Create the message body by entering the field details. The message contains 18 fields:
    Figure 23
    Figure 23
  11. The message structure is created. Use the code below to check the transaction type in the Compute node RouteMessage:
    CREATE COMPUTE MODULE Flow270_Compute
       CREATE FUNCTION Main() RETURNS BOOLEAN
          BEGIN
          IF InputRoot.DFDL.Curam270.body.TransactionType = '270' THEN
             SET OutputLocalEnvironment.Destination.RouterList.DestinationData[1].labelName = '270';
                ELSE
             SET OutputLocalEnvironment.Destination.RouterList.DestinationData[1].labelName = '834';
          6END IF;
       RETURN TRUE;
       END;

This article has shown you how to implement a 270 transaction. Based on transaction type, a message is routed to the correct Label node -- 270 or 834. After the message reaches the 270MessageGeneration node (a JavaCompute node), it reads the incoming message and transforms it into the message format required by the legacy system, by calling the Java utility EDITemplateGeneratorCall. This Java project needs to be imported in the workspace and should look like this:

Figure 24
Figure 24

Here is the format required by the legacy system:

ST*270*604493536*005010X279A1~
BHT*0022*13*604493536*604493536*604493536~
HL*1**20*1~
NM1*PR*2*604493536*****PI*77027~
HL*2*1*21*1~
NM1*1P*2*NOTRECEIVED*****604493536*604493536~
HL*3*2*22*0~
TRN*1*604493536*604493536~
NM1*IL*1*604493536*604493536****MI*604493536~
DTP*291*D8*null604493536~
EQ*30~
SE*12*604493536~
  1. After transforming the message required by the legacy system, it is forwarded to the FileOutput node, where it is written to a flat file and transferred to the legacy system via FTP. In the FileOutput node, set the properties, configure the basic setup, and specify the Directory and File name:
    Figure 25
    Figure 25
  2. The file will be created in the directory defined above: C:/Jayanta/developerworks/Curam/DCF:
    Figure 26
    Figure 26
  3. Specify the FTP configuration:
    Figure 27
    Figure 27
  4. After configuring the properties, create the BAR file and deploy it in WebSphere Message Broker to test the message flow.

Conclusion

This article has shown you how to use Curam integration functionality to create queues, message flows, and message structures (DFDL), using the Compute node and JavaCompute node to enrich messages and the FileOutput node to create flat files for transfer using FTP.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=947128
ArticleTitle=Integrating Curam applications with legacy systems using WebSphere Message Broker
publish-date=10022013