SAP Build Process Automation is the new service in SAP Business Technology Platform which combines the capabilities of SAP Workflow Management and SAP Intelligent Robotic Process Automation. This means, you can now model and manage your workflows, business rules, RPA Bots, and visibility scenarios from one design studio without the need to do any data transformations and additional governance.
Business rules have seen multiple transformations since it was first launched in SAP Business Technology Platform. These transformations were necessary to bring the needed advancement to how the business rules were developed, managed, and consumed. With changing market demands and user personas, it became more-and-more evident that SAP must enhance the user experience and simplify the overall usage of business rules across different line of businesses.
Decision is the new enhanced capability of Business Rules in SAP Build Process Automation. It helps in automating complex business policies to increase the overall efficiency of decision-making processes and applications. These decision logics can be extracted from process and applications, into a separate artefact. This decision artefact can be used to manage all your business rules independently of these processes and applications, from single tool - with integrated lifecycle and governance.
Through this introductory blog, I will help you learn and understand (a) how you can model, manage, and consume business rules, (b) what are the benefits of the new Decision capability, and (c) how is it different from old business rules from SAP Workflow Management.
Decision capability in SAP Build Process Automation provides a no-code design editor to model and manage business policies. It has significantly simplified the way to develop and manage business rules such that both business users and citizen developers can collaborate in their day-to-day decision-making operations to manage these business rules. The new interface is intuitive, with simple design options to easily automate decisions, without the need to writing code.
Decision artefact has these 3 main components:
A decision will need one or more input data types and exactly one output data type. Data type is the structures that is created in the business project. It could be a simple flat structure or structure-with-multiple levels.
Data type in SAP Build Process Automation is created with simple types like Number, String, Date, Timestamp etc. Once created, the same data type can be used by any artefact inside the same project. For example, a Sales Order data type can be used in process or automation or decision like in approval forms to show sales order data or in automation to extract excel entries and store in this data type or in decision to determine approvers based on the sales order data type. Data type is therefore reusable and introduces common data model scheme across different process management artefacts.
» Note: you can create different data types for input and output or keep them same. You can also use array or list type of data types as input and output. List is used as input when you want to pass multiple values to the rules or when you want to collect and return output as a List. For example: You want to loop through all the items of the sales order to determines the approver based on the total item value or you want to get validation outcomes of the sales order.
» Note: Input or Output Data type can be selected from the already created data types in the business project or you can have data types created within the decision by selecting the basic data types like String, Number etc.
This is where the actual logic of the business policies is designed. There are two types of rules modelling supported in Decision (a) Text and (b) Decision table.
Text rule is meant for writing simple logic like If Sales Order Amount is <= 0 then sales order has validation issues. It is to capture simple decision logic without too many complex combinations.
Decision table on other hand is like spreadsheet-based rules where you write rules in column and row format. Here you can write large number of rules in a compact format which is easier to view and manage. If columns are the conditions that are evaluated and Then columns contains the output that will be given after the rule is executed. Each row represents a rule.
Decision table have further execution options like First Match (to find single matching result in the decision table) and All Match (to find multiple matching results). This is property for rules engine to run through the entire rows of decision table or stop execution as-soon-as the first matching result is found.
Decision Table can also be exported as Microsoft Excel and imported back. This functionality is frequently used by the business users who are comfortable with Microsoft tools to make changes to the business rules like adding more rules or updating any existing rule with changed condition or result. The changed excel-sheet can then be imported directly into the decision table.
Besides, there are multiple features available while modelling business rules like orchestration of decisions, reusable rules that can be used as formula or function, local variables which are created and consumed inside decisions only. (we will cover them in detail in subsequent blogs)
Modelling business rules requires an understanding of the rule expression language. It provides guidelines to use functions and operators while defining rules. The rule expressions must be strictly designed as per these guidelines; else it results in the validation errors. Decision provides a in-place suggestions for beginners where it guides you with options to write the expressions, and free-flow writing for experts.
It is always good to get an overview of an entire decision artefact. Decision Diagram provides the same. The digram nicely shows the inputs and output of the decision, and list of rules that are executed. Clicking on the decision diagram entities takes you directly to the respective editors. Each component of the diagram has the validation status where red means it has validation errors. The diagram gets updated as soon as you change the decision.
There could be use cases where you want to call or consume the business rules from external SAP or non-SAP applications, and this can be done using PUBLIC RESTFUL API. These API are published in SAP Business Accelerator Hub with configuration details, authentication methods, and API documentation.
» You can also test the decision from here. All you need is to define the SAP BTP account where you want to run the rule, provide the input structure and upon clicking Test – you will get the output.
There have been numerous viewpoints shared in SAP Community since we released Decision in SAP Build Process Automation. With this blog I would like to break some of the myths around business rules in workflow management compared to Decision in SAP Build Process Automation and bring your attention to some of the key differences.
Myth: Business rules is not supported in SAP Build Process Automation
Fact: This is completely wrong! We have decision in SAP Build Process Automation which has similar capabilities of business rules in workflow management. The runtime of decision is still the same. All we have enhanced is the modelling experience through a no-code editor in SAP Build Process Automation.
Myth: Decision can be used only in process in SAP Build Process Automation
Fact: This is not true. Decision can be built and consumed independently without the need to create the process. This is still the same as in old and retired workflow management service, but what we have significantly improved is the consumption of decision inside the process. You can now add a decision inside the process model, without any coding or additional steps, without the need to worry about input payload alignment and output mappings.
Myth: Decision comes with lessor features and functionality.
Fact: No. Elevating the entire user experience took us sometime to deliver some features and functionality; but now you can model all your rules as in the past with much better user interface and intuitive design options. The new editor will significantly increase your productivity with decision modelling and bring in the needed agility to modify the business rules.
Now coming to real differentiators and enhancements as compared to business rules in workflow management:
⇒ Simplified Design
⇒ Improved Governance
⇒ Enhanced Usability
⇒ Transport Management
⇒ Easier Consumption
⇒ Pre-packaged template content
Business rules have seen multiple transformations since it was first launched in SAP Business Technology Platform. These transformations were necessary to bring the needed advancement to how the business rules were developed, managed, and consumed. With changing market demands and user personas, it became more-and-more evident that SAP must enhance the user experience and simplify the overall usage of business rules across different line of businesses.
Decision is the new enhanced capability of Business Rules in SAP Build Process Automation. It helps in automating complex business policies to increase the overall efficiency of decision-making processes and applications. These decision logics can be extracted from process and applications, into a separate artefact. This decision artefact can be used to manage all your business rules independently of these processes and applications, from single tool - with integrated lifecycle and governance.
Through this introductory blog, I will help you learn and understand (a) how you can model, manage, and consume business rules, (b) what are the benefits of the new Decision capability, and (c) how is it different from old business rules from SAP Workflow Management.
Introduction
Decision capability in SAP Build Process Automation provides a no-code design editor to model and manage business policies. It has significantly simplified the way to develop and manage business rules such that both business users and citizen developers can collaborate in their day-to-day decision-making operations to manage these business rules. The new interface is intuitive, with simple design options to easily automate decisions, without the need to writing code.
Decision artefact has these 3 main components:
- Input and Output data type
- Business Rules
- Decision Consumption API / API Triggers
Input and Output Data Types
A decision will need one or more input data types and exactly one output data type. Data type is the structures that is created in the business project. It could be a simple flat structure or structure-with-multiple levels.
Data type in SAP Build Process Automation is created with simple types like Number, String, Date, Timestamp etc. Once created, the same data type can be used by any artefact inside the same project. For example, a Sales Order data type can be used in process or automation or decision like in approval forms to show sales order data or in automation to extract excel entries and store in this data type or in decision to determine approvers based on the sales order data type. Data type is therefore reusable and introduces common data model scheme across different process management artefacts.
 |  |
» Note: you can create different data types for input and output or keep them same. You can also use array or list type of data types as input and output. List is used as input when you want to pass multiple values to the rules or when you want to collect and return output as a List. For example: You want to loop through all the items of the sales order to determines the approver based on the total item value or you want to get validation outcomes of the sales order.
» Note: Input or Output Data type can be selected from the already created data types in the business project or you can have data types created within the decision by selecting the basic data types like String, Number etc.
Decisions aka Business Rules
This is where the actual logic of the business policies is designed. There are two types of rules modelling supported in Decision (a) Text and (b) Decision table.
Text rule is meant for writing simple logic like If Sales Order Amount is <= 0 then sales order has validation issues. It is to capture simple decision logic without too many complex combinations.
Decision table on other hand is like spreadsheet-based rules where you write rules in column and row format. Here you can write large number of rules in a compact format which is easier to view and manage. If columns are the conditions that are evaluated and Then columns contains the output that will be given after the rule is executed. Each row represents a rule.
Decision table have further execution options like First Match (to find single matching result in the decision table) and All Match (to find multiple matching results). This is property for rules engine to run through the entire rows of decision table or stop execution as-soon-as the first matching result is found.
Decision Table can also be exported as Microsoft Excel and imported back. This functionality is frequently used by the business users who are comfortable with Microsoft tools to make changes to the business rules like adding more rules or updating any existing rule with changed condition or result. The changed excel-sheet can then be imported directly into the decision table.
Besides, there are multiple features available while modelling business rules like orchestration of decisions, reusable rules that can be used as formula or function, local variables which are created and consumed inside decisions only. (we will cover them in detail in subsequent blogs)
Rule Expression Language
Modelling business rules requires an understanding of the rule expression language. It provides guidelines to use functions and operators while defining rules. The rule expressions must be strictly designed as per these guidelines; else it results in the validation errors. Decision provides a in-place suggestions for beginners where it guides you with options to write the expressions, and free-flow writing for experts.
Decision Diagram
It is always good to get an overview of an entire decision artefact. Decision Diagram provides the same. The digram nicely shows the inputs and output of the decision, and list of rules that are executed. Clicking on the decision diagram entities takes you directly to the respective editors. Each component of the diagram has the validation status where red means it has validation errors. The diagram gets updated as soon as you change the decision.
Decision Consumption API
There could be use cases where you want to call or consume the business rules from external SAP or non-SAP applications, and this can be done using PUBLIC RESTFUL API. These API are published in SAP Business Accelerator Hub with configuration details, authentication methods, and API documentation.
» You can also test the decision from here. All you need is to define the SAP BTP account where you want to run the rule, provide the input structure and upon clicking Test – you will get the output.
Business Rules in Workflow Management vs Decision in SAP Build Process Automation
There have been numerous viewpoints shared in SAP Community since we released Decision in SAP Build Process Automation. With this blog I would like to break some of the myths around business rules in workflow management compared to Decision in SAP Build Process Automation and bring your attention to some of the key differences.
Myth: Business rules is not supported in SAP Build Process Automation
Fact: This is completely wrong! We have decision in SAP Build Process Automation which has similar capabilities of business rules in workflow management. The runtime of decision is still the same. All we have enhanced is the modelling experience through a no-code editor in SAP Build Process Automation.
Myth: Decision can be used only in process in SAP Build Process Automation
Fact: This is not true. Decision can be built and consumed independently without the need to create the process. This is still the same as in old and retired workflow management service, but what we have significantly improved is the consumption of decision inside the process. You can now add a decision inside the process model, without any coding or additional steps, without the need to worry about input payload alignment and output mappings.
Myth: Decision comes with lessor features and functionality.
Fact: No. Elevating the entire user experience took us sometime to deliver some features and functionality; but now you can model all your rules as in the past with much better user interface and intuitive design options. The new editor will significantly increase your productivity with decision modelling and bring in the needed agility to modify the business rules.
Now coming to real differentiators and enhancements as compared to business rules in workflow management:
⇒ Simplified Design
In SAP Build Process Automation, we let you focus on building rules than creating different other rule models like ruleset, rule services etc. In workflow management based business rules, you must create business rules project, data types, rule services, ruleset and rules before you can design them. Now, all you need is create a Decision and we create everything else in the background for you. This saves time and increases productivity.
⇒ Improved Governance
You can now:
- view all released and deployed version content.
- revert to any deployed version.
- Undeploy business project which undeploys the decision as well.
- create and invoke as many versions as possible with no limitations.
- control the access of the business project (containing decisions) with view-only and edit options to individual users or groups of people.
- copy the business project to create multiple copies wherever needed.
⇒ Enhanced Usability
We took the feedback and suggestions to improve the experience while modelling decision. First, we have simplified the rule models that a user needs to create, and then we have improved editor interactions with decision diagram, managing input and output parameters, creating & aligning rules for orchestration flow, value help, new rule dialog etc.
⇒ Transport Management
Decision can now be transported from one system to another using transport management service in SAP BTP. With this there no need to export and import the project for continuous deliveries.
⇒ Easier Consumption
With only one runtime API and single SAP Build Process Automation service instance, we have eased the consumption of decision via API. All you need is create a build process automation service instance, get the credentials, and call the /rule-services API endpoint. This will automatically invoke the latest deployed version. If you want to use the Decision in the process, then you have an integrated experience where you can directly add a decision step into the process and configure the input parameters.
⇒ Pre-packaged template content
Decision based pre-packaged content can be discovered from SAP Build Store. There is no need to create the decisions from scratch. You can discover the right content and directly import the pre-packaged content with one click from embedded store in SAP Build Process Automation design studio. This accelerates the overall application development.
§ Key Takeaways §
- Business rules is not discontinued. It is available as Decision with more enhanced user experience in no-code environment and better lifecycle and governance features.
- User experience is elevated with new design time. Decision runtime is same with better performance, more security options and robustness.
- Decision can be seamlessly used within the process, or integrated with any applications – be it SAP/non-SAP, cloud/on-premises.
- SAP Managed Tags:
22 Comments
