Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert
This is the third blog of my blog series on Business Rules Consumption Patterns. In earlier blogs, you saw Pattern 1 - which explains how business rules can be used directly and indirectly in your custom application (which can be deployed on-premise or on-cloud).

Pattern 2 – Decisions in Workflow, Integration and IoT

In Pattern 2, you will see how business rules can be used to abstract the decision logic in process orchestration scenarios. Here I will show you how to consume rules in workflow, cloud integration services and internet of things using different extension use cases. Let us start with scenario1.

Usage Scenario #1
Exposing decision logic as business rules from SAP Cloud Platform Workflow

There is a strong need to separate workflow and rules such that the business users or non-technical users can easily modify the rules without changing the process flow or code. Rule independence is the key here. It gives agility (time-to-market after updating business rules), business empowerment (separating business logic with application logic) and readability and maintainability (easier to read the code and solve complex problems). Business rules can be used inside workflow to extract the decision logic or making branching decision or control the access restrictions of the workflow step etc. So, while the workflow is all about HOW, WHEN and BY WHOM; business rules focusses on WHY of the process flow.

SAP Cloud Platform Workflow and Business Rules work harmoniously to provide an unmatched support to automate workflow. SAP Cloud Platform Workflow is a service that is available in Neo environment and can be accessed via trial or factory accounts in all SAP data-centres across the globe. For more information on modelling workflow and other interesting aspects, please follow the blog community tagged as SAP Cloud Platform Workflow.

Business rules service can be accessed in Workflow using a Service Task. The workflow engine invokes the RESTful rule service with host and credentials information maintained in the destination configured at SAP Cloud Platform.


… then shall we begin with the exercise? Ok!


  • Assumption is that you know how to configure and model the workflow. If not, then follow the blogs from muralidaran.shanmugham2 and christian.loos to know more on it.

For this blog, I have taken an example of a rule with name DetermineEquipments. This rule is written to find out the list of equipment that can be assigned to a newly hired employee, of a company, based on his job characteristics like job-title, organisation, role etc.

The rule in question is already modelled and deployed in SAP Cloud Platform. Let me show you the glimpses of the rule artefacts as the screenshots.


To call the rule service from the workflow, all you need to know is the (a) project name, (b) rule service name and (c) input & output data objects. In this example, these are as follows:

  • Project Name: OnBoarding

  • Rule service Name: DetermineEquipment

  • Input Data Object: Employee

  • Output Data Object: EquipmentInfo


As mentioned above, SAP Cloud Platform Business Rule can be called from workflow using Service task. To configure a service task all you need to do is:




  1. Define a destination as shown


Note: The destination URL is for the bpmrulesruntime destination. The authentication mechanism is BasicAuthentication. User mentioned must have Business Rules Runtime--> RuleSuperUser role assigned to it.  (For more information on how to assign the roles refer the official documentation)


  1. From the palette objects in the workflow editor, drag-and-drop a Script Task in the process where you want the rules to be called.

In this script task, you will construct the payload for the rule execution.


If your workflow context attributes are already SAME as the rules input data-object attributes then all you need to do is add __type__ (see line number 5) and set it back to the context. For Example, as shown below


  1. Next, drag-and-drop a Service Task after the script task and configure properties with the rule execution details.


Note: Path in the configuration is the public API used to invoke the rule for Neo environment.


The beauty is that you can pass on the exact workflow context or a subset of the workflow context as the input payload for the rule invocation. All you need to ensure is that the attributes of the input data object defined in the rules are EXACT match as available in the workflow context.

The result of the rule invocation is returned based on the output data object (defined in the rule) and can be appended in the workflow context via Response Variable as shown in the screenshot above

With these 3 simple steps, your business rule is integrated with the workflow. You can now deploy the workflow and test it from Monitor Workflow app. You will see the execution traces or any failures during rule invocation in the Execution Log of the Monitor Workflow app.


Sample Reference Application
You can also download the content from GitHub. All the instructions to setup and use the scenario are available in the README file of GitHub project




  1.  Define destination

If you have run the Booster, then the destination BUSINESS_RULES will be already created and you can use this destination to configure service task in workflow.


If not then you can either run the Booster, or create this destination manually. The URL, Client ID and Client Secret and token service URL you will get from service key of business rules instance (read more from here how to get these configuration parameters)


2.  Configure Script Task in Workflow

Before you configure service task to call the business rules, you have transform or construct the payload for rules input. For that, drag-and-drop a Script Task from the palette in the process where you want the rules to be called.

There is difference in payload in Neo and cloud foundry (refer API documentation).

note: There are two types of rule invocation: Working-set and Versioned. If you are creating or modifying the rules from Business Rules editor --> Manage Projects then you are in working-set, and if you have deployed the rules from the working-set then you have use working-set based APIs. If you have created the version, and deploying the rule from Business Rules editor --> Manage Projects --> History then you have to use versioned APIs

The input payload need to have to be chosen as per the API definition depending upon which API (working-ser or versioned) you wish to call. In this example, I am calling a versioned API from workflow, so the payload prepared using script task will be like:

var empJob = $.context.empData.d.results[0].empInfo.jobInfoNav.results[0];
var empData = $.context.empData.d.results[0];

/************ Prepare Input Payload to Execute Rules ****************/
var employee = {};
employee.countryOfCompany = "USA";
employee.isFullTimeEmployee = empJob.isFulltimeEmployee; =;
employee.jobTitle = empJob.jobTitle;

var Vocabulary = [{
"Employee": employee
var rulesPayload = {
"RuleServiceId": "6bbd196d50c14b918d04c181e78d3a5b",
"RuleServiceVersion": "000001000000000000",
"Vocabulary": Vocabulary
$.context.rulesPayload = rulesPayload;​



3. Configure Service Task in Workflow

Next, drag-and-drop a Service Task after the script task and configure properties with the rule execution details.


With this you complete the integration of business rules with workflow. Now you can deploy the workflow and test the execution logs.

Sample Reference Application
You can quickly setup and run the scenario using the Starter Scenario Tutorial


Related Blogs
SAP Cloud Platform Business Rules – Extensions and Consumption Patterns
Use SAP Cloud Platform Business Rules in your custom application
Embed Business Rules SAPUI5 control in your custom applications