A typical implementation of the connector requires the creation of at least one outbound queue for delivering messages to Peer-to-Peer Agent, and at least three inbound queues that the connector will poll for business data events, MDNs, and notifications:
This is the queue in which Peer-to-Peer Agent will place messages that contain data documents received from the trading partner that Peer-to-Peer Agent represents. The connector polls this queue to detect new messages, calls a data handler to convert the documents to business objects, and publishes the business objects as events to subscribing collaborations.
For implementations in which Peer-to-Peer Agent is sending documents to you from multiple trading partners, you can set up multiple inbound queues, designating a different queue for the documents received from each trading partner. To do so, you must configure Peer-to-Peer Agent to deliver messages to multiple queues, and you must configure the connector to poll multiple queues. You can also use a single queue to receive documents from multiple trading partners. The Peer-to-Peer Agent agent passes information regarding the trading partner in the MQ RHF2 header of the messages it sends to the adapter. To access this information in your business object, ensure that you have defined a dynamic MO in your BO and that it defines the attribute. JMSProperties. For more information, see Configuring connector meta-objects.
This is the queue in which the connector places data document messages that are to be sent to Peer-to-Peer Agent and the trading partner that it represents. When the connector receives an appropriate business object from a collaboration or other process flow out of the integration broker, the connector calls a data handler to convert the business object to a data document, and places a message containing that document in this queue. Peer-to-Peer Agent polls the queue to discover new messages containing documents to be sent to the trading partner it represents.
Or, you can also use a single queue and retrieve the trading partner information passed in the marked header by the Peer-to-Peer Agent.
For implementations in which Peer-to-Peer Agent is sending your documents to multiple trading partners, you can set up multiple queues, designating a different queue for each trading partner. To do so, you must configure the connector to put messages in multiple queues, and you must configure Peer-to-Peer Agent to poll multiple queues. You can also have the Peer-to-Peer Agent poll a single queue for messages to different trading partners. In this case, you must be sure that you pass the trading partner information through the JMSProperties attribute of your dynamic MO, as define in your BO. The information specified in the JMSPropertiesattribute will be mapped to the MQ RHF2 header where the Peer-to-Peer Agent will use it when routing the document. For more information, see Configuring connector meta-objects.
This is the queue in which Peer-to-Peer Agent places any MDNs received from the trading partners that it represents. A single MDN queue can receive MDNs from multiple trading partners. The connector polls this queue to detect new MDNs, calls the MDN data handler to convert the MDNs to business objects, and publishes the business objects as events to subscribing collaborations.
The queue in which Peer-to-Peer Agent places any notifications that it generates. The connector polls this queue to detect messages containing new notifications, calls the notification data handler to convert the notifications to business objects, and publishes the business objects as events to subscribing collaborations.
The queue manager used for communication between the connector and Peer-to-Peer Agent. The default name for this queue is isoft.queue.manager.
In addition to creating the queues, you must also configure the connector to use the queues that you create. See Configure connector propertiesfor information about the properties that configure the connector to use the queues.
To configure queues for use with the connector:
queue://<queue manager name>/<actual queue>
The URI for a queue begins with the sequence queue:// followed by:
For example, the following URI connects to queue IN on queue manager crossworlds.queue.manager and causes all messages to be sent as WebSphere MQ messages with priority 5.
queue://isoft.queue.manager/ISOFT.IN?targetClient=1&priority=5
The table below shows property names for queue URIs.
Property name | Description | Values |
---|---|---|
expiry | Lifetime of the message in milliseconds. | 0 = unlimited. positive integers = timeout (in ms). |
priority | Priority of the message. | 0-9, where 1 is the highest priority. A value of -1 means that the property should be determined by the configuration of the queue. A value of -2 specifies that the connector can use its own default value. |
persistence | Whether the message should be 'hardened' to disk. | 1 = non-persistent 2 = persistent A value of -1 means that the property should be determined by the configuration of the queue. A value of -2 specifies that the connector can use its own default value. |
CCSID | Character set encoding of the outbound message. | Integers - valid values listed in base WebSphere MQ documentation. This value should match that of the CCSID connector-specific configuration property; see CCSID |
For more information about URIs, see the WebSphere MQ programming guide.