The ACME Business Configuration

The following describes the business configuration of the ACME sample tenant, including the business rules. Once you study and understand the behavior of the ACME business rules, you will be able to make changes to the rules and then submit new tasks to the system so you can observe the impact of your new rules. When you make a change to a rule you will need to redeploy the rule package.

The general functionality of the business rules configured for the ACME sample is the following:

<tabber>

Package-level (Global) Rules=

Package-Level (Global) Rules

A rule that is configured at the rule package level is also known as a Global Rule. Such a rule is evaluated for every iWD task, regardless of the eventual classification of that task (that is, regardless of what department and process the task is pegged to). For the ACME sample configuration, there are two types Global Rules configured. A rule to set an Archive Destination for all tasks Two rules to assign tasks to the correct Process based on Capture Point, and some other criteria Archive Destination rule

This rule will set an Archive Destination of Delete for all tasks. This is configured as a Classification rule, which means it will run once during the lifecycle of a task, unless the task is Restarted at some point in its lifecycle. This rule (as with all rules in the ACME sample) is set to be active starting on January 1, 2010, with no fixed end date.

This Global Rule is an example of a Linear Rule, which is a simple rule expression where each condition and action is represented as a separate row. In this example, there are no rule conditions; there is only a single rule action. Thus, this rule action will be evaluated as true for all tasks, since there are no rule conditions that are checked by the rule engine.

This rule specifies that all tasks, when they meet the archiving criteria described in the IWDBP business process, will be deleted. These criteria are that the task has met its specific expiration date (which is set in a different set of business rules) and is either Canceled, Completed, or Rejected. At that point, it will be deleted from the Interaction Server database.

Process Assignment Rules

These rules use the Capture Point as one of the criteria to determine the Process to which tasks should be assigned, along with some additional criterion that depends on the Capture Point.

In iWD 8.0, it was possible to create Classification rules at the Capture Point level. In iWD 8.1 , where the Genesys Rules System is used, Capture Point rules do not exist. Thus, in order to simulate Capture Point rules, you create Global Rules that use the Capture Point is rule condition.

The first rule is for the tasks coming through the Web Service Capture Point, and the second rule is configured for the tasks coming through the XML File Capture Point. Of course only one of these rules will be evaluated per task, depending on how the task was submitted. Both these rules are Classification rules, which means they will be evaluated once.

Web Service Capture Point Rule

The rule evaluated for tasks coming through the Web Service Capture Point simply assigns each task to an iWD process, based on the ID of the Web form, on the ACME sample Web site. This rule is in a Decision Table format. This Decision Table has a single rule condition (Webform ID is) and a single rule action (Assign iWD process). Since each Web form only has a single, unique ID, there is no chance that multiple rows in this Decision Table will be evaluated as true.

Webform ID is a custom attribute of the iWD tasks. That is, it is not a core or extended attribute that is common to all tasks, such as Product, Priority, etc. Because this rule uses a custom attribute, the rule condition must be coming from the ACME Rules Template. This is a template that is provided as part of the ACME configuration that includes both rule conditions and actions specific to the ACME examples. It is used to supplement the rule conditions and actions that are included in the iWD Standard Rules Template.

Looking at the ACME Rules Template, we can see the rule condition that evaluates a parameter called webformid.

We can see that the Language Expression of the rule condition defines the text that the business user will see when he adds this rule condition to a business rule. The part of the Language Expression that appears in quotes and brackets –{webformid}– defines what parameter is used in that rule condition. In order to understand the behavior of that parameter that will be seen by the business user, we need to look at the parameters of the ACME Rules Template.

On this screen we can see that webformid is a parameter of type Select Enumeration, which means that in the UI where the user constructs business rules, the user will be provided a drop-down list with a pre-defined (enumerated) set of items from which to select. The enumeration corresponding to the webformid parameter is also called webformid. For parameters of this type, the rule template developer must name-value pairs where the label is what the business user will see when constructing the business rule, and the name is the actual value of the piece of attached data that the rule engine will evaluate during runtime.

Returning to the rule condition itself, we can see that the Rule Language Mapping defines how the rule engine should evaluate a rule containing this condition, during runtime. For each task, the rule engine will receive a data object called $data, which is a set of key-value pairs from the interaction/task itself. These key-value pairs are coming from the attached data of the interaction/task. When the rule engine receives this $data object, and it is evaluating a business rule with the rule condition Webform ID is “{webformid}”, it knows that it must evaluate whether the value configured in the instantiation of the rule is equal to the actual value of the webformid key, in the $data object of the interaction/task. In other words, when the business user constructed the business rule, he selected an actual value for webformid, in each row of the Decision Table. The rule engine will look at this actual value and compare it with the value of the webformid attached data key and see if they two are equal. If so, then the rule will evaluate as true; if not, the rule will evaluate as false.

XML File Capture Point Rule

The rule evaluated for tasks coming through the XML File Capture Point assigns each task to an iWD process, based on the Request Type. The Request Type is a custom attribute of each task, which can be found by looking at the actual sample XML files. For example, in the Complaint.xml file, you can see the Request_Type attribute specifies the Request Type as Product Issue. This attribute is within the section of the file, which is where all custom attributes are specified.

<data>
<Request_Type>Product Issue</Request_Type>
<firstName>Jeff</firstName>
<lastName>Thompson</lastName>
<addressLine1>39 Rhonda Lane</addressLine1>
<city>Fredericton</city>
<state>NB</state>
<country>Canada</country>

<contactNumber>5065551212</contactNumber>
<email>jeff@gmail.ca</email>
</data>

This rule uses a rule condition that evaluates the value of a custom attribute, similar to the use of webformid in the previous rule. In this case, the custom attribute is Request_Type. You can take a look at the ACME Rules Template to see how that rule condition is constructed. It is very similar to the webformid rule condition in the previous section.

|-| Department Rules=

For the ACME sample, almost all business rules are configured at the Department level. This includes:

• Setting an expiration date for all tasks in the department, for archiving purposes
• Setting initial values for all tasks in the department, such as priority, business value, and due date
• Setting a time for the first reprioritization of the tasks in the department
• Setting a new priority for the tasks in the department, at the defined reprioritization interval
• Special reprioritization rule for tasks in the department that are overdue

Financial Department Rules

Based on the description above, you can see that the rules configured at the Financial Department level have fairly self-explanatory names.

We can drill down into each of these rules to see what they do. Remember that for any of the rule conditions or actions you see in these rules, you can review the rule template(s) to better understand what type of data the business rule engine is evaluating when it encounters a rule that includes this condition or action. Some of the conditions and actions will be sourced from the Standard Rules Template, and some will be sourced from the ACME Rules Template. The Standard Rules Template can be found in the Modules & Components section of iWD Manager, under the System tenant.

DT-54: Fin. Dep. / Set task expiration date for archiving

This is a classification rule, which means it runs once, during the classification phase of the task lifecycle. The only circumstances under which the rule will be re-evaluated is if a task is restarted (either through the Global Task List or via a capture adapter).

DT-67: Fin. Dep. / Set initial values for tasks This is also a classification rule. As you can see, it sets initial values for business value and priority. It also sets a due date for each task. There is a separate row in the decision table for each of the processes under the Financial Department.

DT-72: Fin. Dep. / Set initial reprioritization time This is a prioritization rule, which means it will be re-evaluated whenever prioritization rules are called from a routing strategy. However, the rule condition Is first prioritization that is used in this decision table means that the rule will only evaluate to true the first time that prioritization rules are executed. For that reason, it could have been configured as a classification rule instead of a prioritization rule.

This rule condition checks for the presence of an iWD task attribute (key-value pair) called IWD_reprioritzeDateTime. If this attribute is not present yet in the interaction's attached data, then this condition will be evaluated as true. The only purpose for this rule is to set an initial time that the task should be reprioritized. The rule action Reprioritize after sets the value of IWD_reprioritizeDateTime, which determines the next time that a queued task should be submitted to the Prioritization routing strategy, when prioritization rules will be executed.

DT-78: Fin. Dep. / Reprioritization for tasks not overdue This rule defines the dynamic reprioritization of tasks that are not overdue. Each row in the decision table defines the set of conditions (Due Time is in—as an offset from the current time—and Business value is) that need to evaluate as true in order for the task's priority to be increased. In addition to increasing the priority of the task, the rules also set the next reprioritization time. This may or may not be the same as the initial reprioritization interval that was set in DT-72.

The presence of the rule condition Is reprioritization ensures that these dynamic reprioritization rules only evaluate as true when we intend to increase the priority of a task. In other words, we want to avoid a situation where an initial priority is given to a task, and then the task priority is immediately increased. Instead, we want to set an initial reprioritization time (for example, 10 minutes), at which point we would start to increase the priority above its initial value. And then we'd continue to increase the priority at specified time intervals, depending on various conditions.

DT-81: Fin. Dep. / Reprioritization for overdue tasks This rule serves the same purpose as DT-78, except it checks whether the task is overdue. Depending on business value, the priority of the task will be increased appropriately, and this will continue to happen every minute, until the task is distributed, completed, or canceled.

Sales Department Rules

The rules for tasks that are assigned to the Sales Department are very similar to those configured for the Financial Department. The main difference is that the initial task values are set differently depending on whether or not we know what the Request Type is for a given task. Also, if the task is pegged to the Order process, there are specific values we want to set, so there is a unique rule for that. That particular rule uses a rule condition that is only relevant for orders, which is why it requires its own rule (DT-51), rather than just being included in DT-34.

We can drill down into each of these rules to see what they do. DT-30: Sales Dep. / Set expiration dates for archiving

This rule achieves the same purpose as DT-54 under the Financial Department. DT-34: Sales Dep. / Set initial values for tasks where only process is given This rule serves the same purpose as DT-67 under the Financial Department, but it only covers a few of the processes under the Sales Department. If a task belongs to processes that are not covered in this decision table, none of the actions in this rule will be taken.

DT-47: Sales Dep. / Set initial values for tasks where process and request type is given This rule is similar to DT-34 above, except it adds an extra condition, which checks for the task's Request Type. Note that for the Complaint process, it is possible that this rule may override the values described in DT-34 for the task's due date, business value, and priority. If a task is assigned to the Complaint process and the Request Type is NOT Product Issue, Billing Issue, Customer Service Issue, or Other, then the values for due date, business value, and priority would be set by DT-34. But if the Request Type is one of these described in DT-47, then those attributes will be take the values from this decision table. This is an example that shows why the order of the rules is relevant.

DT-51: Sales Dep. / Set initial values for order process tasks This rule sets initial values for the same task attributes as DT-34 and DT-47, but only for tasks that are assigned to the Order process. In this case, we are interested in the value of the Order, in order to determine its priority, business value, and due date.

You will note that the Order Total is rule condition has values that overlap from one row to the next. For example, the value 1000.00 is used in both DTR-48 and DTR-49. To understand how this rule will behave when it's evaluated, we need to take a look at the Order Total is rule condition in the ACME Rules Template. We can see that the rule condition with the Language Expression

Order Total is "{orderTotal_1}" to "{orderTotal_2}" 

has this Rule Language Mapping:

eval( ((double){orderTotal_1}) <= getDoubleValue("Order_Total", $data) && ((double){orderTotal_2}) > getDoubleValue("Order_Total", $data) );

Here we can see that this condition is checking for inclusiveness on the lower boundary of the order total expression, but it's not inclusive on the upper boundary. We can also see that in the rules themselves, the rule Name is useful to indicate this behavior to the business user.

DT-58: Sales Dep. / Set initial reprioritization time for tasks not overdue This rule is functionally equivalent to DT-78 under the Financial Department.

DT-62: Sales Dep. / Reprioritization for tasks not overdue This rule is functionally equivalent to DT-81 under the Financial Department.

|-| Process Rules=

For the ACME sample, almost all business rules are configured at the Department level. There is only one process that has a rule configured, which is the Order process, under the Sales Department. In an actual deployment of iWD it may be more common to have process-level rules rather than department-level rules, but this depends on the policies of the enterprise and whether the policies are normally common across all processes in a department, or whether you need to drill down to the process level to determine the appropriate rules to evaluate.

Order Process Rule

RULE-68: Normalize order product / set productType task attribute based on Captured attribute Product Name 1 We can see by looking at this rule that it's a simple linear rule with only one rule action, and no parameters.

Therefore, the only way to understand how this rule will behave when evaluated is to look at the ACME Rules Template. In this case, the rule action with the Language Expression Normalize Order Product has the following Rule Language Mapping:

setStringValue("IWD_ext_productType", getStringValue("Product Name 1", $data), $data);

All this rule condition will accomplish is to set the value of the task attribute IWD_ext_productType to a single value. The Order Form on the ACME web site allows the user to order multiple products, and for each product ordered, the user can select a product from the Product drop-down list. The possible product names are just Product 1, Product 2, and Product 3. If the user submits an order, for example, that includes Product 2 and Product 3, the Normalize Order Product rule action will set the value of the task attribute IWD_ext_productType to Product 2, which is the first product to appear in the order.