Rules Engine

A rules engine executes one or more business rules in a runtime production environment. It allows you to define, execute, and maintain these business rules separately from the application code. You can then use these business rules in any program to facilitate operational decisions at runtime. For example, you might use business rules in the Collection module to decide the collection strategy or in the Banking module to derive charges codes or price items for the transaction.

A rules engine allows you to classify these rules using the rule type. It also allows you to define the relationship between two or more rules and set the priority for each rule. When a calling program invokes these rules using the rule type, all effective rules with the specified rule type are executed, starting with the rule having highest priority. For example, a rule with the priority 10 will be executed before a rule with the priority 20.

Each rule contains one or more criteria. Depending on whether the criteria is satisfied, the system either executes the next criteria or indicates whether the rule is true or false. The rules engine allows you to define what should happen when the rule is true or false. In both the cases, you can enforce the system to either:

  • Execute any dependent rule

  • Execute a rule with the same rule type having lower priority

  • Return the output parameters and their values to the calling program

You can define a criteria for a rule only using the input parameters that are defined for the rule type. Also, when the rule is true, you can only return the output parameters that are defined for the rule type to the calling programs. Therefore, in case you want to use any field in the rule, you have to associate it with the rule type as an input or output parameter.

A rules engine also allows you to execute preprocessing and postprocessing algorithms. A preprocessing algorithm is triggered before executing any criteria in the rule. It pre-processes the input parameters and then returns processed values against which the criteria is validated. A postprocessing algorithm is triggered after executing all criteria in the rule. It post-processes the output parameters and returns the updated values to the calling programs or dependent rules.

Oracle Revenue Management and Billing provides you with the Rule Check utility. It allows you to validate whether rules defined with a specific rule type get executed as expected. On validating, it indicates the sequence in which the rules were executed, the total execution time, and displays the output parameters of the rule that was successfully executed.

Normally, in the Transaction Feed Management feature, the transaction legs are created using the output parameters of the rule where the criteria returns Rule Is True and the rule true action is set to Success. Oracle Revenue Management and Billing also enables you to accumulate the output parameters of all rules where the criteria returns Rule Is True irrespective of whether the rule true action is set to Next Dependent, Next Rule by Priority, or Success. This accumulation process continues until a rule is executed where the criteria returns Rule Is True and the rule true action is set to Success. Once the output parameters are accumulated, the transactions legs are created using these accumulated output parameters. You can enable the rule output accumulation feature for the Transaction Feed Management module by setting the Rule Output Accumulation option type in the C1_​FM feature configuration to true.

There might be situations when duplicate transaction legs are created through the rule output accumulation process. The system enables you to indicate whether duplicate transaction legs must be created during the transaction aggregation cycle through the rule output accumulation process. If the Remove Duplicates from Accumulated Rule Output option type in C1_​FM feature configuration is set to true, the system does not create duplicate transaction legs during the transaction aggregation cycle.

Note: The transaction legs with the same account ID, price item, variance parameter or price item parameters, and processing date are considered as duplicate transaction legs.

Related Topics

For more information on... See...
Rule Type screen Rule Type (Used for Searching)
Rule Type screen Rule Type (Used for Viewing)
Rule screen Rule
View Rule screen Rule
Rule Check screen Rule Check

Parent Topic: Oracle Revenue Management and Billing Generic Business Processes