Sequencing Rules Execution by Decision Orchestration in SAP Cloud Platform Business Rules

SAP Cloud Platform Business Rules enables you to define and orchestrate critical decisions and business policies in easy-to-use web-based tool. As the outcome of the business rules is used to implement dynamic decisions at runtime, it becomes important on how the outcome is evaluated. One of the most common use case during rule evaluation is rule chaining – which means consuming the output of the previous rule in next rule evaluation be it expression modelling in conditions or defining actions of the rule.

Decision Orchestration in business rules now supports sequencing of rule to evaluate the final output. Using this feature, you can define the order of execution in the context of making decisions. Decision Orchestration can be achieved in 2 ways: (a) you can use the output of one rule, as input or output to next rule and (b) you can create rule with reusable expression or formula and then call this rule while modelling other rules. This simplifies the rules modelling especially in cases where reusability is the key.

If you have such requirements in your project, then you are at the right place. In this blog I will explain in detail what are different ways of rule orchestration and how to build and use them in SAP Cloud Platform Business Rules.

» Important Note: This feature is supported only for cloud-based rules (which means rules deployed to SAP Cloud Platform) and ABAP-based rules (which mean rules deployed to S/4HANA)

Enabling Orchestration

• In Ruleset, you will now see a new policy called “Orchestration” and if you add the rules to the ruleset under this policy then the order in which you add the rule will be the order of execution. For example, in below screenshot Additional Discount Rules will be executed first, followed by Discount Rules for Voucher Code and finally Global Promotion Rules
• You can change the order of the rules through up and down arrows while configuring rules in ruleset

Modelling Orchestration Rules

• If you are defining rules under Orchestration policy, then you can consume the output data object in evaluation for further rules.

Let me explain you with an example.

Consider the below rule Additional Discount Rule. In this rule, the output of this rule is collected in a data object called Seasonal Discount

Now let us consider another rule Global Promotion Rules, which is added after Additional Discount Rule in the ruleset.

things to note:

• Output from the previous rule can be used for both condition evaluation and in action expression. For Example: Seasonal Discount in this case

• As per the known limitation, currently you can only add rulesets with only either aggregation or orchestration policy. You cannot have mixed rulesets assigned to same rule-service. Deployment will fail.

• There is also a new concept of intermediate variables with decision orchestration. For example: In above scenario, Seasonal Discount is not the final output instead it is used to store the execution results for the previous rules. You may choose to include the Seasonal Discount as final rule output by declaring them as vocabulary of the rule service and if not then you need to declare them as vocabulary of the rulesets.

In simple terms, vocabulary in rule service is available while executing or invoking rules while the vocabulary defined in the rulesets are intermediate and will be used during evaluation of the rules but not needed as input or the output of the rule service.

• You will notice a new label called Priority in the ruleset. This is useful when you have multiple rulesets of Orchestration policy added to the same rule-service. As the order of execution is important in orchestration scenario, it is therefore important to decide which ruleset to execute first than other rulesets when one rule-service is associated with multiple rulesets.
  • Priority is used to determine the order. You can give any number from 1- 99
  • Lesser the priority – higher is the execution order.
    • For Example: If you have two rulesets. One with priority 50 and other with priority 30. Then ruleset with 30 priority will be executed first.
  • If the two ruleset have same priority then the order is random in each execution.
  • By default the priority is set to 50
  • For Aggregation policy, the priority does not have any relevance.

Understanding Orchestration Execution

1. The result of the last rule execution prevails and would determine the final output.
   • In the above example, the final output is only Discount data object and not Seasonal Discount. In Orchestration policy, only the output returned from the last rule execution will determine the final output. Results of the previous rules will be treated as intermediate.
   • you can also define rules with different output data objects. Only the data object associated as output with last rule will be returned as the result.

2. Order of the rule matters the most when you are consuming the output in the rule chaining. Output might differ if you change the execution order. Also, the rule execution might fail if the order is defined wrongly and one or more values used in condition or action expressions are not yet evaluated.

3. There is no change in the execution API for orchestration rules. What will change is the output. In Aggregation policy, if you are executing two rules then output of both the rules are returned as an array but in Orchestration, only the output of the final rule is returned.

That completes the first part of using decision orchestration capabilities in sequencing rules. You learnt how you can model rulesets with orchestration policy, how to sequence the rule by consuming the output of previous rules in condition and/or action expressions, how to smartly design the rule with intermediate variables and finally how to read the output after execution the rules using APIs.

In the next part, I will show how you can model formula or reusable rules.