Details about the Route subflow for the Record Distribution to WebSphere MQ: one-way pattern.
The behavior of the Route subflow depends on the value of the Routing pattern parameter:
If No routing is selected, a single MQOutput node is created and configured with the values of the Output queue manager and Output queue pattern parameters. The routing flow is a subflow that includes a Passthrough node. Both default and route terminals are included so that this subflow is consistent with all other types of routing subflow, but the single route terminal only is used.
A group of four parameters that define a route:
For each route that is defined, an Output terminal for the Route subflow and an MQOutput node are created and connected.
The Route subflow contains a Route node that is configured with a filter that routes to the first Output terminal for which the condition KeyLocation = Key Value is fulfilled. If a message element does not match any of the routes, this situation is recorded in a variable in the broker environment tree and the message is passed to the Default terminal.
If the XPATH expression defining a Key location includes a namespace qualifier, the tag defining the namespace must be added to the Namespace table.
You might see a warning on the Route node that is similar to the following message: Filter table: Filter pattern: The element_name schema element was not found in the Key location = Key value XPath. This warning does not cause any problems when you deploy and run your pattern instance.
You can specify a number of different routes by selecting Specify routes.
If this value is selected, routes are determined by using values from the message data to look up the queue manager and queue from a database routing table. The routing table is not accessed directly, but is read and cached in memory for greater efficiency.
If this value is selected a single Output terminal is created for the Route subflow. The Output terminal is connected to a single MQOutput node that is configured to take a list of destinations that have been placed in the broker environment tree by the lookup.
The Route subflow checks whether the cache requires refreshing, by checking if the value of the CacheQueueTable.valid shared row variable is set to NULL. The variable is set to NULL when the flow starts, and when Cache refresh is enabled and a refresh message has been sent to Refresh queue. Refresh messages set the value to NULL.
If the cache requires refreshing, the ROUTING_TABLE table of the data source, which is specified in the Routing data source pattern parameter, is searched to find all of the rows that match the routing context for this flow. The routing context is defined by the Routing data context pattern parameter, and the rows in which the ROUTING_CONTEXT field matches this parameter are read into an in-memory cache, which is done atomically to prevent lookups while the cache is in an inconsistent state.
The structure of the cached data is:
VARIABLE1, VARIABLE2, QUEUE_MANAGER, QUEUE_NAME
The lookup is performed by extracting one, or two, key values from the message element by using ESQL expressions that are defined as pattern parameters. The lookup is defined by using a statement in the following form:
SET KEY = <pattern parameter>
If a single key is specified to select a row, or rows, from the routing data, use the following WHERE clause for selection:
WHERE S.VARIABLE1 = KEY1
If a second key is specified, use the following WHERE clause for selection:
WHERE S.VARIABLE1 = KEY1 and S.VARIABLE2 = KEY2
This selection sets the queue manager and queue into the list of destinations that is used by the MQOutput node. Multiple rows can be returned, and the destination data includes all the selected destinations. If a match is not found, a routing error occurs and the message is passed to the Failure terminal of the Route subflow.