Application-connector communication

For event processing, the connector makes use of IBM's WebSphere MQ messaging layer, which is an 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, and it also makes possible guaranteed event delivery. The connector polls the event (output) queues of MFG/PRO applications to retrieve events.

In the other direction, the connector makes use of QAD's QXtend SOAP/HTTP interface to place requests.

QAD MFG/PRO application interface

As part of its external integration suite (and separate from the adapter for QAD MFG/PRO), QAD provides an interface that enables data transfer between native MFG/PRO applications and the adapter for QAD. For the purposes of the connector, this interface has two channels: one for event processing and one for request processing.

Figure 2. QAD MFG/PRO external interface architecture

Event processing interface

As shown in Figure 2, the event processing QAD interface-- whose QAD component name is QqMomAdapter-- is known as the Q/LinQ MQSeries MOM (message-oriented middleware) interface. The MQSeries component that this interface implements is based on a prior, but compatible, version of the WebSphere MQ messaging layer.

The Q/LinQ MQSeries MOM interface:

The input queue is used for processing events from an MFG/PRO application to a WebSphere-connected application. The connector does not deploy a ReplyTo queue.

Request processing interface

For request processing, the connector makes use of QAD's QXtend integration framework. The QXtend framework is a J2EE applicatio that runs on an application server. It has a web services interface that accepts requests in SOAP-XML 1.2 format.

When TLOs are delivered to the connector from the broker, the connector extracts the request BO and converts it to an XML format with a SOAP envelope. The connector then issues a synchronous request to QXtend using the SOAP-HTTP protocol. Upon receiving a response, the connector converts it back to a business object, puts this response BO into the TLO, and sends the TLO to the broker.

Data formats

The data formats handled by the connector correspond to the native format(s) supported by MFG/PRO applications. Figure 3, shows the data formats for event processing.

Figure 3. QAD MFG/PRO data formats--event processing

Event processing formats Event messages from the QAD MFG/PRO eB2 application are published either in triplet format or QDoc format (both QAD proprietary). The triplet format consists of a single ASCII text string made up of a serialized set of tagged field values. The QDoc format is XML-based. (For further information on triplet and QDoc formats, see QAD documentation.) The connector converts messages in either format into business objects and then delivers these to the broker.

Figure 4. QAD MFG/PRO data formats--request processing

Request processing formats The connector receives a TLO from the broker. The TLO contains request, response, and fault business objects as children. The connector converts the request object into a QDoc message. QDoc is a proprietary XML format. The payload in a QDoc is wrapped into QAD-specific message envelope that conforms to the SOAP 1.2 syntax. The envelope root element contains a header and a body element. The structure of the header is common to all QDoc documents. The QDoc request message is sent to the QXtend web services module via SOAP/HTTP protocol. When the MFG/PRO eB2 application returns a response message, the connector converts it to a response business object. The TLO is then returned to the broker. For further information on QDoc format, see QAD's QDoc Specification. For further information on the TLO and business object structure, see Creating or modifying business objects.

For information on how the connector's data handler processes messages and business objects, see QAD MFG/PRO data handler.

Message request

Figure 5 illustrates a message request communication.

Figure 5. Application-connector communication method: Request processing

  1. The integration broker sends a TLO that contains a request business object to the connector.
  2. The connector's data handler converts the request BO to a SOAP-XML message in QDoc format.
  3. The connector sends the QDoc request message to the QXtend web services interface via SOAP/HTTP.
  4. QXtend sends the request to QAD MFG/PRO eB2 application and waits for the response. QXtend generates a response SOAP-XML message in QDoc format.
  5. QXtend sends the response message to the connector.
  6. The connector's data handler converts the message to a response business object and places it in the TLO originally received from the broker.
  7. The connector returns the TLO to the broker.

Event delivery

Figure 6 illustrates the event delivery direction.

Figure 6. Application-connector communication method: Event delivery

  1. Data in QAD MFG/PRO eB2 changes.
  2. The Q/LinQ MQSeries MOM interface generates an event message and places it on an MQ queue.
  3. The connector'spollForEvents() method retrieves the next message from the input queue.
  4. The message is staged in the in-progress queue where it remains until processing is complete. The message is passed to the QAD MFG/PRO data handler. The data handler determines whether the message in in triplet or QDoc format. If the message is in triplet format, the data handler invokes the triplet-to-XML mapping engine, which maps the triplet message to a QDoc document. The data handler then converts the QDoc document into a WebSphere business object. Otherwise, if the message is in QDoc format, the data handler skips the triplet-to-XML mapping step and converts the QDoc into a business object.
  5. The connector'sgotApplEvents() method delivers the business object to the integration broker for further processing, and the message is removed from the in-progress queue.

Copyright IBM Corp. 1997, 2004