IBM MQ RequestReply
The RequestReply activity performs the combined operations of putting a request message into a queue, and then listening on the indicated response queue for the reply.
Because the RequestReply activity depends on the request being committed to the request queue, this activity does not participate in local transaction semantics. This also means that this activity does not share a connection resource with activities in a local transaction because it can unexpectedly commit resources under the control of the local transaction.
General
The General tab of the RequestReply activity contains the following fields:
Field | Module Property? | Description |
---|---|---|
Name | N | The name to be displayed as the label for the activity in the process. |
Connection | Y | The connection resource which associates this activity with the queue manager that has access to the desired queue. |
Destination | Y | The name of the queue into which the message is placed. If the queue is to be created dynamically, enter the name of the dynamic queue. The name must follow the MQSeries rules for dynamic queue names.
If the queue name has been dynamically mapped using the input schema's destination field, this field is not required. |
Message Content Type | N | Select the type of message content:
|
Message Body Fields | Y | Provide the schema to be used in the Input tab, and at run time to encode the contents of this message. |
Reply To Destination | Y | Specify a reply queue on which the RequestReply activity performs a get immediately after sending a request. The activity waits for the number of milliseconds specified in the
waitinterval element of the input schema.
The queue name which is placed into the message header's Reply To Destination field. If this queue is dynamic, it is created before the put is performed, and the name of the temporary queue is set in the request message. |
Dynamic ReplyToDestination | N | A flag that enables the creation of a dynamic queue.
When selected, the Dynamic ReplyToDest Model field is enabled, and the reply queue is dynamically created based on the model in the Dynamic ReplyToDest Model field. If a dynamic reply queue is specified, it is created during the put operation so that it is available to the responding application. |
Dynamic ReplyToDest Model | Y | Specify the model after which the reply queue is to be patterned.
This field is enabled only when the Dynamic ReplyToDestination checkbox is selected. |
Fail If Quiescing | N | Select this checkbox to cause the activity to fail if the queue manager attempts to quiesce during the operation. This prevents the queue manager quiesce from being delayed by this activity. |
Application Properties | N | Select the Application Properties resource to be included as part of this message. Application properties are similar to regular message header fields except that the name and type of these fields can be determined by a predefined schema.
To use application properties, create a generic XML schema composed of a node with simple elements inside it and map it to this field. See the IBM MQ
documentation for property types supported by the level of client you have installed.
|
CICS Bridge Header | N | When enabled causes the input and output schemas to include the CICS bridge header: MQCIH. By mapping fields onto this header in accordance with the IBM CICS bridge for IBM MQ, it is possible to invoke CICS programs and run transactions which display screens. See the IBM Knowledge Center resources at https://www.ibm.com/support/knowledgecenter/SSGMCP_4.2.0/com.ibm.cics.ts.wmq.bridge.doc/topics/zc12190_.html for more information on how to interact with the CICS bridge. The specific fields related to the MQCIH header are not described in the input and output schemas section. See the relevant IBM documentation for this. |
IMS Bridge Header | N | When enabled causes the input and output schemas to include IMS bridge header: MQIIH. By mapping fields onto this header in accordance with the IBM MQ bridge for IMS, it is possible to invoke IMS programs and transactions. See the IBM Knowledge Center resources at https://www.ibm.com/support/knowledgecenter/SSFKSG_9.0.0/com.ibm.mq.pro.doc/q004310_.htm for more information on how to interact with the IMS bridge. The specific fields to the MQIIH header are not described in the input and output schemas section. See the relevant IBM documentation for this. |
Logger Name | Y | Loggers are configured in an XML file used at run time. The runtime logger configuration is specified by the -Dlogback.configurationFile parameter of either the deployed application instance or of the debugger instance. After the logger is configured, it can be named here to cause informational messages to be written there. See the TIBCO ActiveMatrix BusinessWorks documentation for more details about how to configure loggers. |
Advanced
The Advanced tab of the RequestReply activity contains the following fields:
Input
Activity Pooling
The Activity Pooling tab allows the activity to pool all the MQ resources associated with the request reply activity at the process level.
The Activity Pooling tab contains the following fields:
Field | Global Variable | Description |
---|---|---|
Pool Activity | N | Select the
Pool Activity checkbox to activate pooling for the client objects used by this activity. Selecting this option causes pooling to be done at a higher level than merely pooling the connection. All destinations used by the activity are kept open and the connection resource specified are not pooled in the usual way even if that resource has pooling enabled. This option is used when the server to which you are connected experiences very high latency such that opening, closing, and pooling of connections cause unacceptable performance degradation.
The primary consideration for choosing pooling parameters is the number of available connections to the queue manager. Choose values that do not create unnecessary resource consumption in the queue manager, and leave available connections for other applications (including other pooled connections and activities, remember that the application might be deployed on multiple engine instances). |
Pool Max | Y | Determines the maximum number of connections in the pool. When this limit is reached, subsequent activities fail with the following message:
"Activity Pool is exhausted: [Timeout waiting for idle object] Either enlarge the pool, allow it to grow, or increase the blocking time." |
Pool Max Idle | Y | Determines the maximum number of idle connections in the pool. When the number of unused connections reaches this number, the idle connections are disconnected and closed, freeing resources on the server. Amounts over the Max Connections value are ignored. |
Exhausted Action | N | Select one of the following options:
● FAIL - The activity fails immediately after the pool is exhausted. ● BLOCK - The activity waits for the "Pool Wait" interval before failing. If an MQ client is available before the timeout, the activity acquires it. ● GROW - The pool grows past its maximum parameters. |
Pool Wait | Y | If exhausted action is set to "BLOCK", the pool waits for the "Pool Wait" interval for an activity to become available before failing. |
The following table lists the input items for the RequestReply activity:
Output
Fault
The Fault tab lists exceptions that occur in the RequestReply activity:
Error Schema Element | Data Type | Description |
---|---|---|
msg | String | The TIBCO ActiveMatrix BusinessWorks Plug-in for IBM MQ error message. |
msgCode | String | The TIBCO ActiveMatrix BusinessWorks Plug-in for IBM MQ error code. |
mqCompCode | String | This is the original MQException's completion code, if it is an MQException that triggers the fault. |
mqReasonCode | String | This is the original MQException's reason code, if it is an MQException that triggers the fault. |
mqErrorCode | String | If the message originates as an IBM MQ API exception, then that exception's error code is here. |
The elements listed below occur only for the MqReqReply error schema.
Error Schema Element | Data Type | Description |
---|---|---|
mqReqReplyCorrId | Byte Array | If the message originates as an IBM MQ API exception, then that exception's request reply correlation id is here. |
mqReqReplyMsgId | Byte Array | If the message originates as an IBM MQ API exception, then that exception's request reply message id is here. |