Subscribers

Subscriber message routing

Using the Message Routing feature you can define one or more routing rules for messages within a subscriber. By setting routing rules, you can define the actions that must be taken after a message is received.

A routing rule consists of two parts: an expression that specifies when the rule is applicable, and an action that must be completed. These processes can do any processing, including extraction of the message and integration with systems or a notification action. For example, a routing rule can initiate a business process that sends an alert notification to an administrator whenever a customer feedback message arrives in the mailbox.

Upon receiving a message, webMethods Integration evaluates each routing rule. When the rule criteria match, the application initiates the business processes (starts target) that is configured in the rule. If none of the rules satisfy the criteria, the application initiates the business process that is specified in Default invocation.

The subscriber evaluates the routing rules in the same order in which the rules appear in the editor. It is possible that a message might satisfy more than one routing rule. However, the subscriber runs only the workflow or flow service that is associated with the first satisfied routing rule and ignores the remaining routing rules. Therefore, the order in which you list routing rules on the editor is important.

For example, to process a purchase order, you might create services that:

1. Adds a customer record to a database.
2. Adds a customer order.
3. Bills the customer.

The service that adds a customer order can run successfully if the new customer record is added to the database. Likewise, the service that bills the customer can run successfully if the order is added. You can make sure that the services run in the necessary order by creating a subscriber that contains one routing rule for each expected message.

Subscriber behavior with message routing

Subscriber message processing

Subscriber error management

A subscriber acknowledges the message when an error occurs by default. However, subscribers can be configured to retry messages depending on the type of the errors encountered. You can set a subscriber's behavior for managing errors from the Subscriber settings dialog box.

Transient errors

Transient errors occur because of a temporary situation that might be resolved quickly, for example, the inaccessibility of a resource due to network failure or an inability to connect to a database, or whenever the started flow service calls the throwExceptionForRetry service causing it to fail with transient error. As the condition that caused the Subscriber to fail is temporary, it is possible for the Subscriber to start flow service successfully if it waits and then re-runs. Hence, you can configure the retry mechanism.

When a Subscriber fails because of a transient error, the system does the following actions:

1. Verifies whether the retry limit is reached.
   • Yes - Verifies whether the subscriber is configured to suspend on error:
     • Yes - Suspends the subscriber temporarily and recovers the message. This indicates that the required resources are not ready to process the message and makes the message available for processing later.
       Note: The subscriber remains in a suspended state until one of the conditions that are specified in the Subscriber State section is met. After the subscriber is enabled, the messaging provider redelivers the same message, and the subscriber processes the message.
     • No - Acknowledges the message and the flow service invocation is marked as failed. In this scenario, if you have configured the subscriber to suspend on a unrecoverable error, then the subscriber suspends
   • No - Retries to process the message at configured retry intervals.

Fatal errors

Fatal error occurs because of an exceptional situation that cannot be resolved. As the subscriber cannot resolve the condition that caused the operation to fail, the subscriber aborts the operation with a failure exception.

When a Subscriber fails because of a fatal error, the system does the following actions.

1. Verifies whether the subscriber is configured to suspend on error.

   • Yes - Suspends the subscriber temporarily and sends an acknowledgment.
   • No - Sends an acknowledgment for the message.

In both the scenarios, the message processing ends with an error. The subscriber is ready to process the next message.

External messaging subscribers

External messaging providers are third-party or self-hosted messaging systems that can be integrated with your webMethods environment to send or receive messages. These are particularly useful when you want to connect your integrations to systems outside of the IBM® ecosystem.

The functioning of an external messaging provider is the same as that of the internal messaging provider. The only difference is that the external messaging provider is managed by your organization and not by IBM. As it is external to webMethods Integration, you need to create a JMS Account to connect to the external provider.

Enable and Disable JMS Accounts

You can either enable or disable the accounts from the Connectors page. For more information on how to enable and disable JMS accounts, see Enabling invalid/disabled accounts and Disabling accounts.

If you disabled the JMS account, then all subscribers that use this account are suspended. For more information, see Managing subscriber states. Also, any flow services or workflows that use a disabled account to publish messages fails.