|
Siebel Business Rules Administration Guide > Creating and Deploying Rules >
Creating Rule Modules
This topic includes basic instruction on creating rules and rule modules. This topic is not intended as primary documentation for this instruction. For detailed information about creating rule modules, see the Haley documentation that is included in HaleyAuthority through the Help menu. For examples of creating rule statements and rule modules, see:
Once Siebel objects are imported, you can create rule modules to implement business logic. A rule module is a group of rules statements that you want to apply to imported objects. HaleyAuthority allows you to define rules as English statements that:
- Identify business outcomes and specify actions to take.
- Compose if-then-else constructs via definitions of rules statements:
- if conditions. The conclusion that is associated with a set of if conditions is true if at least one of the if statements is true (or).
- only if conditions. The conclusion that is associated with a set of only if conditions is true if all of the only if statements are true (and).
- unless conditions. The conclusion that is associated with a set of unless conditions is false if at least one of the unless statements is true (not).
- In the case of more than one of the condition types being applied to the same conclusion, the order of precedence is unless, then only if, then if.
To create a rule module, you need to do the following tasks:
- Add the rule module.
- Add statements to the rule module.
- You may add submodules to a rule module and statements to the submodules, in order to provide more organization for your rules.
To add modules and submodules
- In HaleyAuthority, navigate to the Modules and Statements View. If the Modules and Statements tab is not available, choose View > Tabs > Modules and Statements.
- Select Modules and Statements in the explorer, then choose Object > Add a module.
- Enter a name for the module.
CAUTION: Do not include any special characters in the module name, such as * (asterisk), ? (question mark), / (slash), ! (exclamation), @ (at), or quotes. Also, the entire module name cannot be a Windows reserved word, although you may have a reserved word as a substring in the name. For example, Incoming SRs is acceptable, but Com alone is not acceptable.
- To add a submodule to a module, select the module and choose Object > Add a submodule. Name the submodule.
You can add more modules and submodules as needed. To add a statement to a module or submodule
- In the Modules and Statements view, select the module or submodule, then choose Object >Add a statement.
- In the Edit statement dialog, type in a statement. Alternatively, you can pick from the Words list at any time to enter allowed words at any place in the sentence. The Words list provides the only words that can be understood by HaleyAuthority at the current place in the statement.
Use double quotes to differentiate a string value (such as my dog) from words that are critical to the structure of the sentence. Any string value can be used in a place where a string value is allowed structurally.
- Edit the syntax until the entire statement is bold and the not understood message changes to understood, then click OK. Alternatively, you can click OK, and return later to correct the statement.
NOTE: A rule module that contains a draft statement (a statement that is not understood by HaleyAuthority) cannot be deployed.
Writing Rules that Involve Parent and Child Business Components
When you write rules, you must keep in mind the intent of your rules and the context in which they are executed. Possible errors that can occur include:
- An intended business process is enforced sometimes, but not all the time, because a rule is not executed in all applicable contexts.
- One or more rules create a logical paradox; that is, one or more rules incorrectly prevent the satisfaction of the conditions for a rule, thus preventing it from executing at appropriate times.
- A rule module may execute in more contexts than intended, such as for all contexts of a business component instead of in a restricted context.
For example, the Expense item business component is a child business component of the Expense business component. Your business processes require that certain conditions be true of expense items before their parent expense is valid. The following rules are examples of rules that need improvement:
Table 4. Rules Needing Improvement
|
|
|
if an expense has any expense item which does not have a description then invalidate the expense with "All expense items should have a description."
is called in a PreWriteRecord runtime event on the Expense business component. |
The rule prevents an expense record from being written if it has an expense item with no description, but it does not prevent an expense item from having no description. A user may create an expense item without a description, then never return to the parent expense item on which the rule is called. |
Write the rule on a PreWriteRecord event for the expense item business component, instead of on the expense business component. Then every expense item will be required to have a description. |
if an expense has no expense item then invalidate the expense with "This expense does not have any line items."
is called in a PreWriteRecord runtime event on the Expense business component. |
This rule disallows saving an expense record unless it has an expense item. However, you cannot add an expense item to an expense while the focus is the Expense business component. You add an expense item to an existing expense in the Line Items applet, whose business component is Expense Item. Thus you can never add an expense item to an expense, because you cannot create an expense without an expense item. |
This is not an issue because an expense report has a zero total if it has no contributing expense items. Instead of a hard invalidation, you can instead provide a reminder to the user to add expense items, such as adding the following rule to a WriteRecord event on the expense business component: if an expense has no expense item then raise an error as "Remember to add expense items to this expense report."
|
Typically, the best practice is to attach a rule to the business component to which the rule most directly applies, and to appropriately restrict the context in which the rule should apply. Many business components can be imported in either of two ways:
- As the primary business component of the business object that you are importing
- As a child business component within the business object that you are importing
Independent of which way you import a business component, any rule written on the business component executes in all contexts, not just when the business component is playing one or the other of the parent or child roles. For example, a rule defined on the Action business component, imported as a child business component within the Opportunity business object, also executes in the Activity screen where Action is the primary business component. To see an example of choosing the appropriate business component on which to write rules, see Scenario for Using Rules to Validate Data at Runtime. Using Some Standard Rule Constructs
This topic illustrates common errors and standard rule constructs for some common scenarios. In some of these examples, a rule statement may be syntactically correct, but semantically incorrect. That is, HaleyAuthority may indicate that a rule statement is understood, but the rule statement may not function as you intend it to.
- Setting a field value. You intend a rule to set a value in the First Name field for a contact. HaleyAuthority understands the following rule statement:
set the first name of the contact to "Ricardo"
However, the field is not set by the rule because the correct semantic form for setting a field value is to quote the field's name, capitalize the field name as it is in the Siebel repository, and to not precede the field name with an article. The correct statement is:
set "First Name" of the contact to "Ricardo"
- Evaluating currency fields. You intend a rule to raise an error if the amount on an expense item exceeds $200. HaleyAuthority understands the following rule statement:
if an expense item has an amount that is more than 700 in "USD" then raise an error as "This expense item exceeds the maximum limit."
However, currency field comparisons, like the comparison with the Amount currency field here requires all three of the following components in the comparison amount: number of units, currency type, and the exchange date on which to compare. The correct statement is:
if an expense item has an amount that is more than 700 in "USD" on an exchange date today then raise an error as "This expense item exceeds the maximum limit."
- Evaluating a multi-value field. You intend a rule to raise an error if an opportunity has a revenue of more than $10,000. An opportunity can have more than one revenue. The following statement seems to be reasonable, but is not understood by HaleyAuthority:
if an opportunity has a revenue that is more than 10000 in "USD" on an exchange date today then raise an error as "Revenue is more than $10000."
For this example, you imported the Opportunity business component and its Revenue field. The Revenue field is of type currency and is a multi-value field. When you import a multi-value field, the Object Importer also seamlessly imports the business component on which the multi-value link is based (Revenue business component) and the target field on that business component (Revenue field on the Revenue business component).
The rule is not understood because it is comparing the Revenue business component against an amount, which is an invalid comparison. HaleyAuthority understands the statement up to the comparison, as indicated by bold and non-bolded text.
The following statement correctly compares the Revenue field of the Revenue business component against the amount:
if an opportunity has a revenue and the revenue's revenue is more than 10000 in "USD" on an exchange date today then raise an error as "Revenue is more than $10000."
For information on the HaleyAuthority concepts that are created automatically when you import a multi-value field, see How the Multi-Value Revenue Field is Imported, which is a topic within the example presented as Scenario for Using Rules to Provide Dynamic Navigation in a Siebel Task.
Writing Rules Using Language Independent Code (LIC)
By default you write rule statements that use language specific values. Alternatively, you can write rule statements that reference Siebel string values that are language independent. Consider the following statement: if an account's name contains "ABC Company" then set "Account Status" of the account to "MOST_PRECIOUS"
If you set your implementation to interpret LIC, then the Siebel string value MOST_PRECIOUS is interpreted depending on the language that is implemented in your Siebel implementation. For English-American, it is translated to gold. If your implementation is not set to interpret LIC, then the literal MOST_PRECIOUS is written to the Account Status field, independent of the language you are implementing. NOTE: HaleyAuthority only supports rules authoring in English. However, actions performed in your Siebel application can leverage LIC.
To set your implementation to interpret LIC when executing rules
- In the cfg file for the application, for example uagent.cfg for Siebel Call Center, set the following parameter:
BizRuleUseLIC = TRUE
- For the Developer client or Mobile Web Client, create the following section:
[BizRule]
BizRuleUseLIC = TRUE
|
