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.
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
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.
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.
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.
Figure 5 illustrates a message request communication.
Figure 5. Application-connector
communication method: Request processing
Figure 6 illustrates the event delivery direction.
Figure
6. Application-connector communication method: Event
delivery