MQ Poll Queue activity

Use the MQ Poll Queue activity periodically checks the MQ Queue for messages based on a specified retry interval during runtime.

Note: You must have created an endpoint for the MQ activity before configuring the activity.
The Configure task has three sections:
  • Queue and Message details - where you specify properties for queue and message details.
  • Delivery  rules - where you specify how you want messages delivered.
  • Retry options - where you specify how long to wait between retries and the number of time to retry before failing.

After completing the Configure tasks, Mapping outputs for the activity.

Note: The maximum message size is 100 MBytes.

Queue and Message details

Specify Queue and Message details for the fields in the following table. Required fields are marked with an asterisk.
Field Description
Queue Name * Specifies the name of the queue which is polled for messages.
Payload Data Type Specifies the datatype of the message payload, either binary or string.
Schema Fragment for MQRFH2 Header Specifies if an MQRFH2 header is included in the message. If the message is an XML message and includes a MQRFH2 header, select this check box and click [...]. In the Browse For Schema Type Element dialog box find the XML Schema that defines the header, select the NameValueData element in that XML Schema, and click OK. The schema fragment is the NameValueData element and all its child elements.
Note: The XML Schema that defines the header must first be created and loaded into the project before you can select it. For more information see Defining and loading an XML schema for a MQRFH2 header.

Delivery  rules

Field Description
Poll for changes Specifies how often the Integration Appliance should poll the queue for changes. For more information, see Polling Interval Behavior.
Where messages have Unique ID's Specifies if the messages on the queue have unique IDs.
Deliver Messages The options available here depend on whether the Unique ID's checkbox is selected. If selected, all three options are available. If not, only At Least Once is displayed.
  • At least once - Specifies that the message is delivered at least once but can be delivered more than once. Connection or Integration Appliance failures can result in messages being retrieved and processed more than once. This delivery option is typically used when the receiving system can detect or tolerate duplicate messages.
  • At most once - Specifies the message is delivered only once or not at all. Connection or Integration Appliance failures can result in messages being missed. This delivery option is typically used when the receiving system cannot tolerate duplicate messages but can tolerate lost messages.
  • Exactly once - Specifies the message is delivered once and only once. Connection or Integration Appliance failures do not affect delivery with this option. The Integration Appliance uses MQ message IDs to ensure that every message is retrieved and processed exactly once.
    Note: If you select the Exactly Once option, you must enable persistence. For more information, see Enabling Persistence.

Retry options

Configure the retry options of the MQ Poll Queue activity, as defined in the following table:

Retry Options Description
1) Wait __ second(s) between each retry. The number of seconds that the Integration Appliance waits before attempting to retrieve messages from MQ Server, again.
2) Try to connect __ times before failing. Specifies the maximum number of times the Integration Appliance attempts to retrieve messages from the MQ Server before failing.

If an orchestration that starts with an MQ Poll Queue activity is deployed and the Integration Appliance cannot connect to the specified MQ server or cannot retrieve messages from queue, the Integration Appliance logs the errors as warnings in the system log until the retry count value is reached. When the retry count is reached, the Integration Appliance logs an error in the system log, resets the current retry count to zero, and continues to attempt to establish a connection to the MQ server.

For example, you set the retry count to 3. The first, second, and third errors appear in the system log as warnings. The Integration Appliance logs the fourth error as an error and resets the current retry count to zero. Therefore, the fifth connection error generates a warning in the system log. The Integration Appliance continues to attempt to retrieve messages from the queue.

Mapping outputs

You are not required to map output parameters for this activity. However, if you do map any of these parameters, note the following points:
Parameters:
  • payload and mqmdheader parameters are obtained from the message that is received from the queue.
  • rfh2header is obtained if the schema for the RFH2 Header is specified in the Configure task.



Feedback | Notices


Timestamp icon Last updated: Wednesday, 15 June 2016


http://pic.dhe.ibm.com/infocenter/wci/v7r0m0/topic/com.ibm.wci.doc/MQ_Poll_Message_Activity.html