Adapter architecture

The adapter is meta-data-driven. The adapter uses an MQ implementation of the JavaTM Message Service (JMS), an API for accessing enterprise-messaging systems.

The adapter uses WebSphere MQ queues to enable asynchronous data exchange from WebSphere Commerce to ICS and from ICS to WebSphere Commerce. Data is sent between the queues for WebSphere Commerce and the ICS in the form of XML messages. An XML data handler is used to convert the data into business objects that can be processed by ICS collaboration objects.

For information about using the adapter in synchronous exchanges, see Synchronous request and reply interactions.

Asynchronous messages from WebSphere Commerce to integration broker

When an order is placed in WebSphere Commerce, an OrderCreate message is generated in XML format and is placed in the WebSphere MQ output queue as shown in the following figure. (In this illustration, it is assumed that WebSphere Commerce and the integration broker are installed on different machines using different queue managers, making it necessary to have a remote queue definition for output from WebSphere Commerce, connecting to an input queue that is local to the integration broker. When WebSphere Commerce and the integration broker are installed on the same machine, a single queue can function as both the output queue from WebSphere Commerce and input queue for the integration broker.)

Figure 1. Adapter architecture


To detect data events in WebSphere Commerce, the adapter polls the WebSphere Commerce output queues for new XML messages. When it discovers a new message, the adapter passes it to an input queue, calls a data handler to convert the message to a business object that is specific to the structure of data originating from WebSphere Commerce, and then passes the business object to the connector in ICS. The connector invokes maps to generate a generic business object from the WebSphere Commerce-specific business object, and then delivers the generic business object to one or more collaboration objects. After the collaboration objects have processed the business object, the generic business object is mapped to an application-specific business object, which is delivered to an adapter (such as a WebSphere Business Integration adapter for SAP) that has been configured for a back-end application.

Asynchronous messages to WebSphere Commerce from ICS

In the opposite direction, the adapter for WebSphere Commerce receives business objects from collaborations, converts them into XML-format messages using the data handler, and then delivers the messages to the WebSphere Commerce WebSphere MQ queue.

Synchronous request and reply interactions

Synchronous request and reply interactions require additions to or customization of the WebSphere Commerce application, as described in the following topics.

Requests from WebSphere Commerce to InterChange server

With the addition of the WebSphere Commerce Enhancement Pack, available at

http://www-3.ibm.com/software/webservers/commerce/epacks/v54/, you can use the adapter to set up a synchronous message flow for request and reply interactions from the WebSphere Commerce messaging system to InterChange Server or other external systems. For information about this approach, see the integration documentation for WebSphere Commerce 5.4 and the IBM WebSphere business integration system.

Requests from InterChange server to WebSphere Commerce

Note:
This approach requires a customization of the commands that are executed in WebSphere Commerce when a business object comes from ICS. The commands should retrieve the ReplyTo queue from the message, and place a reply on the queue within the ResponseTimeout interval. For information about creating and customizing commands in WebSphere Commerce, refer to the Programmer's Guide for WebSphere Commerce, V. 5.4.

Without using WebSphere Commerce Enhancement Pack, you can set up a simulated synchronous exchange between WebSphere Commerce and ICS, using ReplyTo queues.

See Synchronous delivery, later in this guide, for more information related to this approach.

Event notification

Notification of data events that have occurred in the WebSphere Commerce application is accomplished through the polling mechanism of the adapter. The adapter can poll multiple input queues, polling each in a round-robin manner and retrieving a specified number of messages from each queue. For each message retrieved during polling, the adapter adds a dynamic child meta-object (if specified in the business object). The child meta-object values can direct the adapter to populate attributes with the format of the message as well as with the name of the input queue from which the message was retrieved.

When a message is retrieved from an input queue, the connector looks up the business object name associated with that input queue and with the FORMAT field contained in the message header. The message body, along with a new instance of the appropriate business object, is then passed to the data handler. If a business object name that is associated with the input queue and format is not found, the message body alone is passed to the data handler. If a business object is successfully populated with message content, the connector checks to see if it is subscribed, and then delivers it to InterChange Server using the gotApplEvents() method.

Business objects and WebSphere MQ message header

The type of business object and verb used in processing a message is based on the FORMAT field contained in the WebSphere MQ message header. The adapter uses meta-object entries to determine business object name and verb. You construct a meta-object to store the business object name and verb to associate with the WebSphere MQ message header FORMAT field text.

You can optionally construct a dynamic meta-object that is added as a child to the business object passed to the adapter. The child meta-object values override those specified in the static meta-object that is specified for the adapter as a whole. If the child meta-object is not defined or does not define a required conversion property, the adapter, by default, examines the static meta-object for the value. You can specify one or more dynamic child meta-objects instead of, or to supplement, a single static adapter meta-object.

Copyright IBM Corp. 1997, 2004