How rules are evaluated

Routing rules of a policy are evaluated using a standard algorithm. The order of the rules on the list determines the order in which the system evaluates them against a request. When the conditions of a rule match those of the request, no further evaluations are performed.

For example, suppose the repeater server policy has three rules for determining the repeater to use for indirect staging to target servers. The routing policy lists the rules in the following order: New York, NYC Office 1, and NYC Office 2. When a BLPackage is deployed, the system evaluates the request against each routing rule, in the order listed. If the conditions of the first rule on the list (New York) match the request, the other rules are not evaluated.

If a job does not match any of the defined routing rules, it is handled by any job server that is available (the default behavior).


You can view and change the order of routing rules. See Changing the order of rule evaluation.

If a rule assigns a server and the server is not running, the job or connection fails. For example:

  • If a job execution rule assigns an Application Server to execute a job and that Application Server is down, the job fails. It is not reassigned.
  • If a routing rule has multiple SOCKS proxy servers associated with it, the Application Server chooses one proxy server to use for routing to the target server. However, if that proxy server is not running, the connection to the target server fails. The connection does not fail over to another proxy server associated with the rule. For job execution rules, when a routing rule assigns an Application Server to execute a Batch Job, that Application Server executes all of the Child Jobs as well.
Was this page helpful? Yes No Submitting... Thank you