Application-connector communication

The connector makes use of IBM's WebSphere MQ implementation of the Java Message Service (JMS). The JMS is an open-standard API for accessing enterprise-messaging systems. It is designed to allow business applications to asynchronously send and receive business data and events.

Message request

Figure 2 illustrates a message request communication. When the doVerbFor() method receives a WebSphere business integration system business object from an Integration Broker, the connector passes the business object to the data handler. The data handler converts the business object into XML and the connector issues it as a message to a queue. There, the JMS layer makes the appropriate calls to open a queue session and routes the message.

For each interface you want to support SAP XI requires definitions of a separate inbound JMS adapter instance bound to separate queues. For example, if you want to support request processing for MATMAS and ORDERS IDocs, you need to configure two separate instances of Inbound JMS adapters in SAP XI. The same instance of the WebSphere adapter for SAP Exchange Infrastructure, can handle multiple request messages and can post to different queues.

Figure 2. Application-connector communication method: Message request

Event delivery

Figure 3 illustrates the event delivery direction. When SAP XI Outbound JMS Adapter posts a message to the Input.Queue of the WebSphere adapter for SAP XI, the pollForEvents() method retrieves the next applicable message from the input queue. The message is staged in the in-progress queue where it remains until processing is complete. Using either the static or dynamic metaobjects, the connector verifies that the message type (i.e., XML) is supported. The connector then passes the message to the configured data handler, which converts the message into a WebSphere business integration business system business object. The verb that is set reflects the conversion properties established for the message type. The connector then delivers the business object to InterChange Broker, and the message is removed from the in-progress queue.

Figure 3. Application-connector communication method: Event delivery

Guaranteed event delivery

The guaranteed-event-delivery feature enables the connector framework to ensure that events are never lost and never sent twice between the connector's event store, the JMS event store, and the destination's JMS queue. To become JMS-enabled, you must configure the connector DeliveryTransport standard property to JMS. Thus configured, the connector uses the JMS transport and all subsequent communication between the connector and the integration broker occurs through this transport. The JMS transport ensures that the messages are eventually delivered to their destination. Its role is to ensure that once a transactional queue session starts, the messages are cached there until a commit is issued; if a failure occurs or a rollback is issued, the messages are discarded.

Note:
Without use of the guaranteed-event-delivery feature, a small window of possible failure exists between the time that the connector publishes an event (when the connector calls the gotApplEvent() method within its pollForEvents() method) and the time it updates the event store by deleting the event record (or perhaps updating it with an "event posted" status). If a failure occurs in this window, the event has been sent but its event record remains in the event store with an "in progress" status. When the connector restarts, it finds this event record still in the event store and sends it, resulting in the event being sent twice.

You can configure the guaranteed-event-delivery feature for a JMS-enabled connector with, or without, a JMS event store. To configure the connector for guaranteed event delivery, see instructions in the Connector Development Guide for Java.

If the connector framework cannot deliver the business object to the ICS integration broker, then the object is placed on a FaultQueue (instead of UnsubscribedQueue and ErrorQueue) and generates a status indicator and a description of the problem. FaultQueue messages are written in MQRFH2 format.

Copyright IBM Corp. 1997, 2003