Configuring Routing Rules

Routing is one of the most powerful functions of the ILLiad system. By using routing rules, you can change default ILLiad processes by having the system automatically skip or add steps to the basic ILL process.

Each time the status of an item is changed by the ILLiad client, the system runs a query to cycle through any rules that exist in the Routing table and determine if any active routing rules should be applied to that item.

Turning on Routing

Routing must first be turned on before the system will apply any of the routing rules to transactions during processing. This is done in the ILLiad Customization Manager. To turn on routing, open the ILLiad Customization Manager and navigate to System | Routing. Select the RoutingOn key, set the value to Yes, and click Save.

Creating Routing Rules

You can create routing rules in the ILLiad Customization Manager under System | Routing | Routing.

1. Click New Record.

2. Fill out the following values:

   RuleNo	Type in the number you want to be assigned with the routing rule. Each routing rule must have a unique ID.
   RuleActive	Type Yes if you want this rule to be active. Type No if you want the rule to be inactive.
   ProcessType	This specifies the Process Type (Borrowing, Lending or Doc Del) to which a given rule will apply.
   TransactionStatus	This specifies the Transaction Status to which the rule will apply. This value may be any legitimate ILLiad status, including any Custom Queues.
   MatchString	The query string for the routing rule. See further explanation below.
   NewProcessType	This specifies the new Process Type (Borrowing, Lending or Doc Del) to which the transaction will be routed. It is possible to route transactions back and forth between Borrowing and Doc Del. Lending transactions cannot change RequestType.
   NewTransactionStatus	The Transaction Status to which the request will be routed to. This value may be any legitimate ILLiad status, including any Custom Queues.
   RuleDescription	Text that describes what the rule is intended to do.

3. Click Save.

General Guidelines for Creating Routing Rules

• Routing Rules should be created so that no two routing rules apply to the same transaction at the same time. This means that the ProcessType, TransactionStatus, and MatchString values, taken collectively, should be unique for each rule in the table.
• Routing Rules should be created so that they are unique to your process tracking. In other words, the same rule should not apply to the same transaction multiple times during the course of standard processing. Routing Rules should be created to be unique to a specific step of your process. Routing rules are processed in the order of the RuleNo. Only the first matching rule is processed. Any others will be skipped.
• Routing Rules should only reference the Users, Transactions, and/or LenderAddresses tables.

The Match String

The Match value in a routing rule is arguably the most important piece of the Routing entry. Each time the status of a transaction is changed by ILLiad, the system also runs a query to cycle through any active Routing Rules and determine if any should be applied to that transaction.

The Match String is where you may set the conditions that distinguish one routing rule from another. These conditions, coupled with the other conditions specified in a routing rule, determine which transactions are impacted by the rule and which are not.

This query string should only reference the Users and Transactions, or LenderAddresses tables unless a compound routing rule is used.

 Guidelines for the Match String:

• Each item or course table value name in the match string must be preceded by a (u.) for the Users table, a (t.) for the Transactions table, or an (l.) for the Lender Addresses table.
• Only single quotation marks ('), not double quotation marks (") may be used in the match string.
• There cannot be any extra characters or spaces in the match string.

• If you are using OR clauses in your match string, it's a good practice to surround them with parentheses.

  • For example:

    (t.Location like '%alpha%' or t.Location like '%beta%')

    (t.CallNumber like ‘%gamma%’ or t.CallNumber like ‘%omega%')

See examples for demonstrations on how to correctly write and format the match string. If a match string is not formatted correctly, the routing rule will not work.

Null Value

NULL has no value, and so cannot be compared using the scalar value operators. In other words, no value can ever be equal to (or not equal to) NULL because NULL has no value. Hence, SQL has special IS NULL and IS NOT NULL predicates for dealing with NULL. Note that this behavior is the default (ANSI) behavior.