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 a request is changed by the ILLiad Client, the system runs a query to cycle through any rules that exist in the Routing table in the ILLiad Customization Manager and determine if any active routing rules should be applied to that request.
Enabling 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
- Navigate to System | Routing
- Select the RoutingOn key
- Set the value to Yes
- Click Save
Creating Routing Rules
You can create routing rules in the ILLiad Customization Manager under System | Routing | Routing:
If you have a Shared Server setup, it is important to exercise caution when creating routing rules to ensure that the rule is applied only to the desired site/s. For example, if you want a particular routing rule to apply solely to your main site, ILL, and not to your shared server sites, ABC and XYZ, you must specify this in the routing rule by adding NVTGC = 'ILL' as a condition in the rule's match string.
- Click New Record.
-
Fill out the following values:
RuleNo Type in the number you want to have assigned to the routing rule. Each routing rule must have a unique ID.
Configuring Routing Rule Priority
Routing rules in ILLiad are processed in the order specified by the RuleNo value. When the status of a request changes, ILLiad will evaluate the rules configured in the Routing table to determine if any routing rules are a match for that request, beginning with the rule that has the lowest RuleNo value. The first rule that matches the request will be used for processing, and any remaining rules in the Routing table will be skipped.
RuleActive Enter Yes to activate this rule, or No to keep the rule inactive. ProcessType Enter the Process Type (Borrowing, Lending, or Doc Del) to which the given rule will apply. TransactionStatus Enter 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 in Creating Match Strings. NewProcessType Enter 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 the Borrowing and Doc Del Process Types. Lending transactions cannot change Process Type.NewTransactionStatus Enter the new Transaction Status to which the request will be routed. This value may be any legitimate ILLiad status, including any Custom Queues. RuleDescription Enter text that describes what the rule is intended to do. - Click Save.
General Guidelines for Creating Routing Rules
- Routing rules should be created so that no two routing rules can 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 can only reference fields in the Users, Transactions, and LenderAddresses database tables.
For a complete list of the fields in each database table, see ILLiad Database Tables.
Creating Match Strings
The match string value in a routing rule is arguably the most important piece of the routing rule 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 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.
Guidelines for the Match String:
-
Each ILLiad field value name used 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 LenderAddresses table.
Note: Routing rules with Borrowing and Doc Del ProcessTypes can only use the Transactions (t.) and Users (u.) tables. Routing rules with the Lending ProcessType can only use the Transactions (t.) and LenderAddresses (l.) tables. - Only single quotation marks ('), not double quotation marks ("), should be used in the match string.
- Special formatting is required within the match string if performing a mathematical comparison on an ILLiad field holding a potentially non-numeric value. For additional guidance, see Using Potentially Non-Numeric ILLiad Field Values in Match String Comparisons.
- 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%')
-
Using Potentially Non-Numeric ILLiad Field Values in Match String Comparisons
When creating routing rules, it is important to consider the data type of the ILLiad field(s) used in match string comparisons. Certain ILLiad fields are configured in the database to hold both numeric and non-numeric values. If your routing rule match string attempts to use a mathematical operator (e.g., greater than (>), less than (<), etc.) to compare the value in one of these fields to a numeric value, ILLiad will throw an error when attempting to process the routing rule against any requests containing a non-numeric value in the field.
For example, the LoanDate field in the Transactions database table is a nvarchar(30) field, which means that it can store both numeric and non-numeric values up to 30 characters in length. If a routing rule match string is configured to perform a mathematical comparison using the LoanDate field (e.g., t.LoanDate > 2020), an error will occur when ILLiad uses the rule to process a request with a non-numeric value (e.g., December 2020) in the field.
Formatting the Match String to Handle Non-Numeric Field Values in Comparisons
To avoid these errors, the match string should be rewritten using the TRY_CAST SQL function to first check that the data in the specified ILLiad field is a numeric value that can be used in the mathematical comparison. For example, the routing rule match string condition t.LoanDate > 2020 in the example above should be rewritten as follows:
TRY_CAST(t.LoanDate AS INT) > 2020The TRY_CAST function will first check to ensure the data in the LoanDate field is an integer value that can be used in the comparison. If the data in the LoanDate field is non-numeric and cannot be converted to an integer for the comparison, it will not cause an error but will simply exclude that request from being considered a match for the routing rule.
Null Values
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.