Connectors consist of an application-specific component and the connector framework. The application-specific component contains code tailored to a particular application. The connector framework, whose code is common to all connectors, acts as an intermediary between the integration broker and the application-specific component. The connector framework provides the following services between the integration broker and the application-specific component:
The connector for WebSphere MQ Workflow bridges collaborations and WebSphere MQ Workflow nodes by performing exchanges of data structures and controlling related processes. Although the connector is an external application, it functions much like an internal "node" in an WebSphere MQ Workflow system. Like a node, the connector performs a process-oriented function.
WebSphere MQ Workflow nodes are configured to issue requests to the connector on a designated queue. The connector polls and retrieves an WebSphere MQ Workflow request message from such a queue. Using Document Object Model (DOM) parsers and the XML data handler, the connector extracts and converts the data to a business object appropriate to the request and to the corresponding collaboration. In the opposite direction, the connector receives business object requests from collaborations, converts them into MQ Workflow process requests, and issues them to the XML input queue of MQ Workflow. In addition, the connector can directly bind with the MQ Workflow server to provide greater control over MQ Workflow processes.
You configure the connector to use the XML message API of the MQ Workflow system. The XML API of the MQ Workflow system is for asynchronous and synchronous processing of message requests. You create a User-defined Program Execution Server (UPES)--an IBM MQ Workflow program used to trigger workflow actions--that allows MQ Workflow nodes to communicate with the connector as if it were another node. Using the XML API, the connector responds to messages that request business objects from collaborations and conveys messages that request actions in MQ Workflow.
All XML messages exchanged with MQ Workflow conform to a single Document Type Definition (DTD), WfMessage. The Document Object Model Parser (DOM) parser extracts the Workflow data structure from the WfMessage that the connector then uses to create a container object to hold the data structure.
During polling, the connector knows which top-level object to create by identifying the data structure contained in the WfMessage. Specifically, the name of the data structure appended to the <boprefix> configuration property determines which top-level object is created. The first (non metadata related) child object in this top-level object is populated with the data structure. The verb assigned to the parent container object is based on the ProgramParameters field in the WfMessage. The parent container object is posted to InterChange Server.