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 and, in the other direction, places request and error messages on the MFG/PRO application's Request (input) queue. This is discussed in detail inQAD MFG/PRO application interface below.
As part of its external integration suite (and separate from the WebSphere Adapter for QAD MFG/PRO), QAD provides an interface that enables data transfer between native MFG/PRO applications and WebSphere MQ queues.
Figure 2. QAD MFG/PRO external interface architecture
As shown in Figure 2, the 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 or acknowledgments from an MFG/PRO application to a WebSphere-connected application. The output queue is for request messages or confirmations conveyed by the connector and bound for an MFG/PRO application. The input and output queues define the interface boundary between an MFG/PRO application and the connector for QAD MFG/PRO.
The data formats handled by the connector correspond to the native format(s) supported by MFG/PRO applications. As shown in Figure 3, these native data formats depend on the direction of the data flow:
Figure 3. QAD MFG/PRO data formats
QAD also supports a proprietary XML format known as Qdoc. The payload in a Qdoc is wrapped in a standard, QAD-specific, message envelope that conforms to the SOAP 1.2 syntax. The envelope root element contains a header and a body element. For further information, see QAD's Qdoc Specification.
As shown in Figure 4, the connector's MFG/PRO data handler has a mapping engine that converts triplet messages to Qdoc. An XML data handler component then converts the Qdoc into a BO. In the other direction, the XML data handler component converts a BO into a Qdoc document. Then a mapping engine converts the Qdoc content into a message encoded in CIM (or triplet) format that is then passed on to the QAD MFG/PRO application. The MFG/PRO application requirements determine which format--CIM or triplet--to use when encoding messages from the connector.
Figure 4. The connector's MFG/PRO data handler
For request processing, the connector features an SQL Query Dispatcher that can query MFG/PRO databases for logical expression evaluation. If updated data is available in the MFG/PRO database, the corresponding fields in a CIM template can be enabled. This conditional CIM mapping is discussed in detail in Conditional CIM mapping. This section provides an overview of the application-communication method for this special processing.
Figure 5. The connector's SQL Query Dispatcher communication channel
Upon startup, the dispatcher launches a JRE to run a Java RMI server class that can intercept query requests from the connector, which, as shown in Figure 5, acts as the RMI client. The connector-as-RMI-client attempts to connect to the RMI Server upon initialization, logging an error message if the RMI server is not operational or times out. The RMI server name and request timeout values are configurable as connector properties.
The dispatcher will communicate with the RMI Server through the latter's standard input and output. The RMI server sends requests to the dispatcher in the form of SQL query strings through the standard output, then waits for a response on its standard input. You can configure the SQL Query Dispatcher to run on the same system as the connector, or on a remote system. If on the same system, the connector starts, re-starts and shuts down the dispatcher. You control the dispatcher via a command line, which is specified as a connector configuration property. The connector attempts to start the dispatcher upon initialization; failure to start the dispatcher results in an connector initialization failure. The connector handles connection errors to the RMI server by first trying to re-connect to the RMI server and, failing this, by attempting to restart the dispatcher. Upon termination, the connector shuts down the dispatcher by sending a STOP request string.
If the connector and SQL Query Dispatcher are running on separate systems, the dispatcher is started and stopped independently of the connector. The dispatcher must be running when the connector starts up. The connector handles connection errors to the server by attempting to re-connect for a configurable number of times before quitting. The RMI server times out on waiting for a reply from the dispatcher by a value that is communicated from the client (connector) through the interface. The SQL Query Dispatcher generates, compiles and runs a script based on the content of the request. Database connection drops and invalid SQL statements prompt the dispatcher to log errors.
Figure 6 illustrates a message request communication. When the doVerbFor() method receives a WebSphere business integration system business object from a collaboration, the connector passes the business object to the data handler. The data handler converts the business object into a Qdoc document. The data handler maps the Qdoc document into a CIM- or triplet-formatted message, depending on the data format requirements of the target MFG/PRO application. The connector then issues it as a message to a queue. There, the application's MQ layer makes the appropriate calls to open a queue session and route the message.
Figure 6. Application-connector communication method: Message request
During Qdoc-to-CIM processing, an SQL Query Dispatcher may query MFG/PRO databases for to check for updated records by evaluating a logical expression. The querying is performed via an RMI server connection. When the query evaluates to true, fields in the CIM template are enabled.
You configure the Dispatcher using connector-specific configuration properties (see Connector-specific properties). You start and stop the SQL Query Dispatcher using a start-up script (see Startup). For a detailed description of the conditional logic involved in querying and updating Qdocs, see Conditional CIM mapping.
Figure 7 illustrates the event delivery direction. The pollForEvents() method retrieves the next message in triplet format from the input queue. The message is staged in the in-progress queue where it remains until processing is complete. The message is passed to the MFG/PRO data handler. 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 integration business system business object.
The connector then determines whether the business object is subscribed to by a collaboration. If so, the gotApplEvents() method delivers the business object to the integration broker for further processing, and the message is removed from the in-progress queue.
Figure 7. Application-connector communication method: Event delivery