IBM MQ Subscriber
The Subscriber activity listens on a topic or an administratively defined subscription and starts a process that provides the contents of the message.
The subscriber can poll a topic based on interval and timeout values, or it can wait indefinitely. Regardless of which mode it is in, when messages arrive they are each processed immediately with no intervening interval time. When polling is enabled, messages published to the subscribed topic are not lost during the interval when the subscriber is not actively listening because the subscriber exists for the duration and is not created and destroyed across intervals. However, this does not necessarily apply during error recovery or lost connection scenarios.
If neither of these fields is provided but an existing durable subscription is specified, the activity subscribes to the durable subscription.
The queue manager inserts the forward slash (/) as necessary to compose a well formed topic string.
While the listener is active, a temporary dynamic subscription is created (in the queue manager) so that all messages appropriate for the topic are routed there. This subscription ceases to exist when the listener is stopped, or in error recovery. To avoid missing messages destined for the topic, you can enable the Durable Subscription option to have the subscription persisted indefinitely in the queue manager using the name provided. Durable subscriptions accumulate messages even when there are no listeners, much like a queue would.
- A message arrives after a Subscriber activity is stopped. In this scenario, the message is rolled back.
- There are two subscribers in the same queue after you start a new subscriber. Normally this is not an issue, because when a new message arrives, the first subscriber exits. However, if the subscriber is using a durable subscription, only one thread can use this destination at a time, and the second subscriber fails to connect. It continues to attempt to connect and issue warning messages periodically. Until a message arrives, it terminates the first subscriber, after that, the second started subscriber connects and processes the message.
There is another general scenario, which affects all process starters. If the Subscriber activity receives a number of messages and creates processes for them, but those processes are either running or waiting to run without adding checkpoints and the engine is shut down, those messages are lost. If it is imperative that messages are never lost, you can select the Require Client Confirmation checkbox in the General tab to ensure their integrity.
General
The General tab of the Subscriber activity contains the following fields:
Advanced
The Advanced tab of the Subscriber activity contains the following fields:
Conversations
You can use the Conversations tab of the Subscriber activity to initiate or join a conversation.
Conversations receive messages after the creation of a process instance, which is initiated or joined by an activity. This activity can be used to initiate a conversation. Click the Add New Conversation icon to initiate a conversation. For more details regarding conversations, see TIBCO ActiveMatrix BusinessWorks Application Development.
Output
The following table lists the output items for the Subscriber activity:
Fault
The Fault tab lists exceptions that occur in the Subscriber 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 | If the message originates as an IBM MQ API exception, then that exception's completion code is here. |
mqReasonCode | String | If the message originates as an IBM MQ API exception, then that exception's reason code is here. |
mqErrorCode | String | If the message originates as an IBM MQ API exception, then that exception's error code is here. |