Chapter 58. Creating guided rule templates
Chapter 58. Creating guided rule templates You can use guided rule templates to define rule structures with placeholder values (template keys) that correspond to actual values defined in a data table. Guided rule templates are an efficient alternative to defining sets of many guided rules individually that use the same structure. Procedure In Business Central, go to Menu Design Projects and click the project name. Click Add Asset Guided Rule Template . Enter an informative Guided Rule Template name and select the appropriate Package . The package that you specify must be the same package where the required data objects have been assigned or will be assigned. Click Ok to create the rule template. The new guided rule template is now listed in the Guided Rule Templates panel of the Project Explorer . Click the Data Objects tab and confirm that all data objects required for your rules are listed. If not, click New item to import data objects from other packages, or create data objects within your package. After all data objects are in place, return to the Model tab and use the buttons on the right side of the window to add and define the WHEN (condition) and THEN (action) sections of the rule template, based on the available data objects. For the field values that vary per rule, use template keys in the format USDkey in the rule designer or in the format @{key} in free form DRL (if used). Figure 58.1. Sample guided rule template Note on template keys Template keys are fundamental in guided rule templates. Template keys are what enable field values in the templates to be interchanged with actual values that you define in the corresponding data table to generate different rules from the same template. You can use other value types, such as Literal or Formula , for values that are part of the rule structure of all rules based on that template. However, for any values that differ among the rules, use the Template key field type with a specified key. Without template keys in a guided rule template, the corresponding data table is not generated in the template designer and the template essentially functions as an individual guided rule. The WHEN part of the rule template is the condition that must be met to execute an action. For example, if a telecommunications company charges customers based on the services they subscribe to (Internet, phone, and TV), then one of the WHEN conditions would be internetService | equal to | USDhasInternetService . The template key USDhasInternetService is interchanged with an actual Boolean value ( true or false ) defined in the data table for the template. The THEN part of the rule template is the action to be performed when the conditional part of the rule has been met. For example, if a customer subscribes to only Internet service, a THEN action for RecurringPayment with a template key USDamount would set the actual monthly amount to the integer value defined for Internet service charges in the data table. After you define all components of the rule, click Save in the guided rule templates designer to save your work. 58.1. Adding WHEN conditions in guided rule templates The WHEN part of the rule contains the conditions that must be met to execute an action. For example, if a telecommunications company charges customers based on the services they subscribe to (Internet, phone, and TV), then one of the WHEN conditions would be internetService | equal to | USDhasInternetService . The template key USDhasInternetService is interchanged with an actual Boolean value ( true or false ) defined in the data table for the template. Prerequisites All data objects required for your rules have been created or imported and are listed in the Data Objects tab of the guided rule templates designer. Procedure In the guided rule templates designer, click the plus icon ( ) on the right side of the WHEN section. The Add a condition to the rule window with the available condition elements opens. Figure 58.2. Add a condition to the rule The list includes the data objects from the Data Objects tab of the guided rule templates designer, any DSL objects defined for the package, and the following standard options: The following does not exist: Use this to specify facts and constraints that must not exist. The following exists: Use this to specify facts and constraints that must exist. This option is triggered on only the first match, not subsequent matches. Any of the following are true: Use this to list any facts or constraints that must be true. From: Use this to define a From conditional element for the rule. From Accumulate: Use this to define an Accumulate conditional element for the rule. From Collect: Use this to define a Collect conditional element for the rule. From Entry Point: Use this to define an Entry Point for the pattern. Free form DRL: Use this to insert a free-form DRL field where you can define condition elements freely, without the guided rules designer. For template keys in free form DRL, use the format @{key} . Choose a condition element (for example, Customer ) and click Ok . Click the condition element in the guided rule templates designer and use the Modify constraints for Customer window to add a restriction on a field, apply multiple field constraints, add a new formula style expression, apply an expression editor, or set a variable name. Figure 58.3. Modify a condition Note A variable name enables you to identify a fact or field in other constructs within the guided rule. For example, you could set the variable of Customer to c and then reference c in a separate Applicant constraint that specifies that the Customer is the Applicant . c : Customer() Applicant( this == c ) After you select a constraint, the window closes automatically. Choose an operator for the restriction (for example, equal to ) from the drop-down menu to the added restriction. Click the edit icon ( ) to define the field value. Select Template key and add a template key in the format USDkey if this value varies among the rules that are based on this template. This allows the field value to be interchanged with actual values that you define in the corresponding data table to generate different rules from the same template. For field values that do not vary among the rules and are part of the rule template, you can use any other value type. To apply multiple field constraints, click the condition and in the Modify constraints for Customer window, select All of(And) or Any of(Or) from the Multiple field constraint drop-down menu. Figure 58.4. Add multiple field constraints Click the constraint in the guided rule templates designer and further define the field values. After you define all condition elements, click Save in the guided rule templates designer to save your work. 58.2. Adding THEN actions in guided rule templates The THEN part of the rule template is the action to be performed when the conditional part of the rule has been met. For example, if a customer subscribes to only Internet service, a THEN action for RecurringPayment with a template key USDamount would set the actual monthly amount to the integer value defined for Internet service charges in the data table. Prerequisites All data objects required for your rules have been created or imported and are listed in the Data Objects tab of the guided rule templates designer. Procedure In the guided rule templates designer, click the plus icon ( ) on the right side of the THEN section. The Add a new action window with the available action elements opens. Figure 58.5. Add a new action to the rule The list includes insertion and modification options based on the data objects in the Data Objects tab of the guided rule templates designer, and on any DSL objects defined for the package: Insert fact: Use this to insert a fact and define resulting fields and values for the fact. Logically Insert fact: Use this to insert a fact logically into the decision engine and define resulting fields and values for the fact. The decision engine is responsible for logical decisions on insertions and retractions of facts. After regular or stated insertions, facts have to be retracted explicitly. After logical insertions, facts are automatically retracted when the conditions that originally asserted the facts are no longer true. Add free form DRL: Use this to insert a free-form DRL field where you can define condition elements freely, without the guided rules designer. For template keys in free form DRL, use the format @{key} . Choose an action element (for example, Logically Insert fact RecurringPayment ) and click Ok . Click the action element in the guided rule templates designer and use the Add a field window to select a field. Figure 58.6. Add a field After you select a field, the window closes automatically. Click the edit icon ( ) to define the field value. Select Template key and add a template key in the format USDkey if this value varies among the rules that are based on this template. This allows the field value to be interchanged with actual values that you define in the corresponding data table to generate different rules from the same template. For field values that do not vary among the rules and are part of the rule template, you can use any other value type. After you define all action elements, click Save in the guided rule templates designer to save your work. 58.3. Defining enumerations for drop-down lists in rule assets Enumeration definitions in Business Central determine the possible values of fields for conditions or actions in guided rules, guided rule templates, and guided decision tables. An enumeration definition contains a fact.field mapping to a list of supported values that are displayed as a drop-down list in the relevant field of a rule asset. When a user selects a field that is based on the same fact and field as the enumeration definition, the drop-down list of defined values is displayed. You can define enumerations in Business Central or in the DRL source for your Red Hat Process Automation Manager project. Procedure In Business Central, go to Menu Design Projects and click the project name. Click Add Asset Enumeration . Enter an informative Enumeration name and select the appropriate Package . The package that you specify must be the same package where the required data objects and relevant rule assets have been assigned or will be assigned. Click Ok to create the enumeration. The new enumeration is now listed in the Enumeration Definitions panel of the Project Explorer . In the Model tab of the enumerations designer, click Add enum and define the following values for the enumeration: Fact : Specify an existing data object within the same package of your project with which you want to associate this enumeration. Open the Data Objects panel in the Project Explorer to view the available data objects, or create the relevant data object as a new asset if needed. Field : Specify an existing field identifier that you defined as part of the data object that you selected for the Fact . Open the Data Objects panel in the Project Explorer to select the relevant data object and view the list of available Identifier options. You can create the relevant identifier for the data object if needed. Context : Specify a list of values in the format ['string1','string2','string3'] or [integer1,integer2,integer3] that you want to map to the Fact and Field definitions. These values will be displayed as a drop-down list for the relevant field of the rule asset. For example, the following enumeration defines the drop-down values for applicant credit rating in a loan application decision service: Figure 58.7. Example enumeration for applicant credit rating in Business Central Example enumeration for applicant credit rating in the DRL source In this example, for any guided rule, guided rule template, or guided decision table that is in the same package of the project and that uses the Applicant data object and the creditRating field, the configured values are available as drop-down options: Figure 58.8. Example enumeration drop-down options in a guided rule or guided rule template Figure 58.9. Example enumeration drop-down options in a guided decision table 58.3.1. Advanced enumeration options for rule assets For advanced use cases with enumeration definitions in your Red Hat Process Automation Manager project, consider the following extended options for defining enumerations: Mapping between DRL values and values in Business Central If you want the enumeration values to appear differently or more completely in the Business Central interface than they appear in the DRL source, use a mapping in the format 'fact.field' : ['sourceValue1=UIValue1','sourceValue2=UIValue2', ... ] for your enumeration definition values. For example, in the following enumeration definition for loan status, the options A or D are used in the DRL file but the options Approved or Declined are displayed in Business Central: Enumeration value dependencies If you want the selected value in one drop-down list to determine the available options in a subsequent drop-down list, use the format 'fact.fieldB[fieldA=value1]' : ['value2', 'value3', ... ] for your enumeration definition. For example, in the following enumeration definition for insurance policies, the policyType field accepts the values Home or Car . The type of policy that the user selects determines the policy coverage field options that are then available: Note Enumeration dependencies are not applied across rule conditions and actions. For example, in this insurance policy use case, the selected policy in the rule condition does not determine the available coverage options in the rule actions, if applicable. External data sources in enumerations If you want to retrieve a list of enumeration values from an external data source instead of defining the values directly in the enumeration definition, on the class path of your project, add a helper class that returns a java.util.List list of strings. In the enumeration definition, instead of specifying a list of values, identify the helper class that you configured to retrieve the values externally. For example, in the following enumeration definition for loan applicant region, instead of defining applicant regions explicitly in the format 'Applicant.region' : ['country1', 'country2', ... ] , the enumeration uses a helper class that returns the list of values defined externally: In this example, a DataHelper class contains a getListOfRegions() method that returns a list of strings. The enumerations are loaded in the drop-down list for the relevant field in the rule asset. You can also load dependent enumeration definitions dynamically from a helper class by identifying the dependent field as usual and enclosing the call to the helper class within quotation marks: If you want to load all enumeration data entirely from an external data source, such as a relational database, you can implement a Java class that returns a Map<String, List<String>> map. The key of the map is the fact.field mapping and the value is a java.util.List<String> list of values. For example, the following Java class defines loan applicant regions for the related enumeration: public class SampleDataSource { public Map<String, List<String>> loadData() { Map data = new HashMap(); List d = new ArrayList(); d.add("AU"); d.add("DE"); d.add("ES"); d.add("UK"); d.add("US"); ... data.put("Applicant.region", d); return data; } } The following enumeration definition correlates to this example Java class. The enumeration contains no references to fact or field names because they are defined in the Java class: The = operator enables Business Central to load all enumeration data from the helper class. The helper methods are statically evaluated when the enumeration definition is requested for use in an editor. Note Defining an enumeration without a fact and field definition is currently not supported in Business Central. To define the enumeration for the associated Java class in this way, use the DRL source in your Red Hat Process Automation Manager project. 58.4. Adding other rule options You can also use the rule designer to add metadata within a rule, define additional rule attributes (such as salience and no-loop ), and freeze areas of the rule to restrict modifications to conditions or actions. Procedure In the rule designer, click (show options... ) under the THEN section. Click the plus icon ( ) on the right side of the window to add options. Select an option to be added to the rule: Metadata: Enter a metadata label and click the plus icon ( ). Then enter any needed data in the field provided in the rule designer. Attribute: Select from the list of rule attributes. Then further define the value in the field or option displayed in the rule designer. Freeze areas for editing: Select Conditions or Actions to restrict the area from being modified in the rule designer. Figure 58.10. Rule options Click Save in the rule designer to save your work. 58.4.1. Rule attributes Rule attributes are additional specifications that you can add to business rules to modify rule behavior. The following table lists the names and supported values of the attributes that you can assign to rules: Table 58.1. Rule attributes Attribute Value salience An integer defining the priority of the rule. Rules with a higher salience value are given higher priority when ordered in the activation queue. Example: salience 10 enabled A Boolean value. When the option is selected, the rule is enabled. When the option is not selected, the rule is disabled. Example: enabled true date-effective A string containing a date and time definition. The rule can be activated only if the current date and time is after a date-effective attribute. Example: date-effective "4-Sep-2018" date-expires A string containing a date and time definition. The rule cannot be activated if the current date and time is after the date-expires attribute. Example: date-expires "4-Oct-2018" no-loop A Boolean value. When the option is selected, the rule cannot be reactivated (looped) if a consequence of the rule re-triggers a previously met condition. When the condition is not selected, the rule can be looped in these circumstances. Example: no-loop true agenda-group A string identifying an agenda group to which you want to assign the rule. Agenda groups allow you to partition the agenda to provide more execution control over groups of rules. Only rules in an agenda group that has acquired a focus are able to be activated. Example: agenda-group "GroupName" activation-group A string identifying an activation (or XOR) group to which you want to assign the rule. In activation groups, only one rule can be activated. The first rule to fire will cancel all pending activations of all rules in the activation group. Example: activation-group "GroupName" duration A long integer value defining the duration of time in milliseconds after which the rule can be activated, if the rule conditions are still met. Example: duration 10000 timer A string identifying either int (interval) or cron timer definitions for scheduling the rule. Example: timer ( cron:* 0/15 * * * ? ) (every 15 minutes) calendar A Quartz calendar definition for scheduling the rule. Example: calendars "* * 0-7,18-23 ? * *" (exclude non-business hours) auto-focus A Boolean value, applicable only to rules within agenda groups. When the option is selected, the time the rule is activated, a focus is automatically given to the agenda group to which the rule is assigned. Example: auto-focus true lock-on-active A Boolean value, applicable only to rules within rule flow groups or agenda groups. When the option is selected, the time the ruleflow group for the rule becomes active or the agenda group for the rule receives a focus, the rule cannot be activated again until the ruleflow group is no longer active or the agenda group loses the focus. This is a stronger version of the no-loop attribute, because the activation of a matching rule is discarded regardless of the origin of the update (not only by the rule itself). This attribute is ideal for calculation rules where you have a number of rules that modify a fact and you do not want any rule re-matching and firing again. Example: lock-on-active true ruleflow-group A string identifying a rule flow group. In rule flow groups, rules can fire only when the group is activated by the associated rule flow. Example: ruleflow-group "GroupName" dialect A string identifying either JAVA or MVEL as the language to be used for code expressions in the rule. By default, the rule uses the dialect specified at the package level. Any dialect specified here overrides the package dialect setting for the rule. Example: dialect "JAVA" Note When you use Red Hat Process Automation Manager without the executable model, the dialect "JAVA" rule consequences support only Java 5 syntax. For more information about executable models, see Packaging and deploying an Red Hat Process Automation Manager project .
c : Customer() Applicant( this == c ) 'Applicant.creditRating' : ['AA', 'OK', 'Sub prime'] 'Loan.status' : ['A=Approved','D=Declined'] 'Insurance.policyType' : ['Home', 'Car'] 'Insurance.coverage[policyType=Home]' : ['property', 'liability'] 'Insurance.coverage[policyType=Car]' : ['collision', 'fullCoverage'] 'Applicant.region' : (new com.mycompany.DataHelper()).getListOfRegions() 'Applicant.region[countryCode]' : '(new com.mycompany.DataHelper()).getListOfRegions("@{countryCode}")' public class SampleDataSource { public Map<String, List<String>> loadData() { Map data = new HashMap(); List d = new ArrayList(); d.add("AU"); d.add("DE"); d.add("ES"); d.add("UK"); d.add("US"); data.put("Applicant.region", d); return data; } } =(new SampleDataSource()).loadData()