Routing

Routing is accomplished in the system by looking for a routing control element. A routing control element in the dictionary is a <document>name</document> section, in which the name of the element (its value) is by default the root tag of the document to which it applies. This can be overridden by an explicit condition instruction, which always takes the form of a child as follows:

<if>
     <cond>conditional expression</cond>
</if>

If the conditional expression is omitted, the default is _isroot(document name).

A search follows the routing algorithm, testing the condition for truth. The first routing element that evaluates to 'true' is selected.

There are two routing algorithms in use, called precedence 1 and precedence 2. In general, we use precedence 1.

The order of search for precedence 1 (the default) is:

  1. Look in the current listener definition for an appropriate <document> element. Take the item we need from the document if found.
  2. Look in global documents for an appropriate <document> element. Take the item we need from the document if found. In iSM, v1 global documents are not definable. The run time router considers any that have been stored by the iSM console or a package to be valid routes.
  3. Look in the current listener for what we need. This is the default route.
  4. If all fails, ignore the optional operation or set an error if it is a required operation (agent or process flow).

Once a route is located, it is the source of the operation. That is, routes do not inherit. So if a route is selected and it does not have the desired component element, the run time does not look elsewhere.

This search takes place several times during the processing, so that as an incoming message's root element name changes, alternate routes might be selected. We refer to this as dynamic routing.

If the selected <document> carries the type='fixed' attribute, once selected it remains the route for the remainder of the handling of the current message. This adds performance by avoiding the frequent route evaluation but limits the flexibility. On the other hand, most documents do not change routing so fixed routing can be a good choice.

The actual task elements, for example, the process flow to run, are taken from the selected routing location. Each can contain a condition (<if > tag) which if evaluated to true causes the element to be selected. If no such conditional element is present, the default is true and the element is selected.

As an optimization, the transform nodes (for example, in_xmlg, in_xslt) can be aggregated under the optional in_transforms element. This is also true of out_xxx transformations. It is not necessary to aggregate, and if the aggregation element is omitted it is created automatically when the document route is loaded. Thus, old routes can work with no change.

Some best practices advice is:

  1. Define routes in the order you want them examined in each section. The search continues until it gets a true condition. Therefore, unless you want a specific dynamic order, defining them in order of probability is best.
  2. Make the tests as simple as possible. For example, _isroot('x') executes slightly faster than _root()='x' or xpath(/*/name()), although the difference is very slight. If you want to use an OR such as _root('x') or _root('y'), specify the most likely first. This avoids having to evaluate the second term. Similarly, if AND is used, specify the least likely term first to avoid unneeded evaluation of the subsequent term.
  3. Use comments liberally.

iWay Software