About the TwineBall Example EIS Adapter sample

This sample is provided to demonstrate how the WebSphere Adapter nodes work. The sample uses the TwineBall Adapters, which have a self contained Enterprise Information System (EIS). In this sample, an existing system inserts data into the EIS by using WebSphere MQ queues to synchronize the two systems.

The TwineBall Adapter

The TwineBall Example EIS Adapter contains a set of XML schemas and an internal Cloudscape database, allowing it to be mapped using the Enterprise Metadata Discovery (EMD) tool. The TwineBall Adapter can therefore be used in the same way as a production ready EIS, without the requirement for installation, configuration, or setup. The TwineBall EIS contains only one top level Business Object (BO): a Customer object. A Customer has the following structure:

• First Name
• Last Name
• Address
  • City
  • Zip/Postal code

The sample message flow

The message flow that is used in this sample uses the TwineBallRequest node to call the EIS.

The sample shows how an existing system, which stores customer information in simple C style data structures, can be integrated to an EIS to synchronize the two systems. Responses that are generated by the TwineBall EIS can be sent to a queue defined in the header of the incoming message.

The following diagram shows the TwineBall sample message flow:

The TwineBall sample message flow performs the following actions:

1. An input message in Custom Wire Format (CWF) is put onto the CREATE queue. The input message contains all the required information to create a Customer Object.
2. A Mapping node is used to convert the message to the Data Object domain, so that the message can be understood by the TwineBall EIS.
3. The newly constructed Data Object is then forwarded to the TwineBallRequest node, which has a default method of CREATE.
4. The response to the CREATE operation is collected from the TwineBallRequest node and is mapped back into the CWF format.
5. This CWF message is then forwarded to the ReplyToQueue, which was set in the original CWF message header.

The returned value is the primary key of the new Customer object followed by a 4 byte integer. The integer is set to 1 in the case of success, or a null primary key followed by a 4 byte integer set to 0, in the case of failure.

Running the example involves:

• Deploying the BAR file, containing the TwineBall adapter and the message flow
• Putting data to a WebSphere MQ queue, to initate the flow
• Looking at the data, which is output to a WebSphere MQ queue

The sample provides:

• The existing system to EIS message flow
• The message set, representing the Customer structures and the existing CWF messages
• The TwineBall adapter
• Input data for the flow

Back to sample home