Introduction
Recently I started migrating my projects from the deprecated iRPA service towards the SAP Build Process Automation, the successor of iRPA. One of the parts I had to migrate, were the Business Rules. Whilst the Business Rules were already familiar, I was happy to notice that the Decision rules took away some pain points I found within the Business Rules Capability.
Maintaining the rules
For us, there was one big thing missing when migrating to the Decision Rules. In our case, we gave the Business Expert Users at the customers a training in how to change the business rules themselves. Adding a new supplier in the business rules, changing a rule with an approver list,… It was easy to give access to some users in order to maintain the business rules tables.
Admitted, they mostly forgot to deploy or release in the beginning, but after a few changes they knew how to handle it!
And then there came the switch to decision rules. Embedded in your SAP Build Process Automation project. No separate application anymore to maintain them. And we don’t want our business expert users being able to change the automation projects. So we came with a solution: creating a separate decision rules project and giving the right users access to it.
Accessing rules with an API
Thankfully, we have an API to retrieve the decision rules outcome. Which can be found here: https://api.sap.com/api/SPA_Decision/overview
This is the same API as we used to invoke the Business Rules before, so it seemed an easy migration. Find the new ID, fill in the right Revision and it should be migrated in an easy way.
A Separate Decision Rules Project and migrating the rules
To start with, I created a separate project, specifically meant for the decision rules.
To easily move the already existing data in our business rules project, I exported the business rule and exported the same decision rule. Then I copy pasted the business rules data into the decision rules excel. And imported it straight away.
After creating and importing the necessary Decision Rules, release and deploy the whole project.
The main difference here is that you release and deploy the whole project at once, instead of rule by rule in the former Business Rules. (What an ease!)
After deploying, we saw that the status changed from Draft to Revised Content and that we were able to retrieve the ID and .. the version.
This is something I did not expect. When using the API’s from Business Rules, I knew that it was best practice to always use the same revision and change the version. That way the payload stayed the same without having to change the version you needed. We don’t want a version hardcoded in our payload, do we?
But when using the Decision Rules, you only have the possibility to use the version instead of the revision.
Conclusion
As a workaround, I had to create a version in the environment variables. This way the version has only to be adjusted in the main automation that starts several workflows at once.
Overall, I’m really positive about migrating to the decision rules.
But hopefully it will soon be possible to invoke the API with the most recent version. This is a real pain when using the API’s combined with decision rules.
If you want to know more about the differences between Business Rules and Decision Rules, I suggest you read this informative blog: https://blogs.sap.com/2023/06/26/business-rules-vs-decisions/
All API’s regarding SAP Build Process Automation can be found here: https://api.sap.com/package/SAPProcessAutomation/all
Want to know more about my journey in migrating everything from iRPA and Workflow to SAP Build Process Automation? Follow me!
Questions, thoughts or comments? I’d love to hear them. Let’s get in touch!
Recently I started migrating my projects from the deprecated iRPA service towards the SAP Build Process Automation, the successor of iRPA. One of the parts I had to migrate, were the Business Rules. Whilst the Business Rules were already familiar, I was happy to notice that the Decision rules took away some pain points I found within the Business Rules Capability.
Maintaining the rules
For us, there was one big thing missing when migrating to the Decision Rules. In our case, we gave the Business Expert Users at the customers a training in how to change the business rules themselves. Adding a new supplier in the business rules, changing a rule with an approver list,… It was easy to give access to some users in order to maintain the business rules tables.
Admitted, they mostly forgot to deploy or release in the beginning, but after a few changes they knew how to handle it!
And then there came the switch to decision rules. Embedded in your SAP Build Process Automation project. No separate application anymore to maintain them. And we don’t want our business expert users being able to change the automation projects. So we came with a solution: creating a separate decision rules project and giving the right users access to it.
Accessing rules with an API
Thankfully, we have an API to retrieve the decision rules outcome. Which can be found here: https://api.sap.com/api/SPA_Decision/overview
This is the same API as we used to invoke the Business Rules before, so it seemed an easy migration. Find the new ID, fill in the right Revision and it should be migrated in an easy way.
A Separate Decision Rules Project and migrating the rules
To start with, I created a separate project, specifically meant for the decision rules.
To easily move the already existing data in our business rules project, I exported the business rule and exported the same decision rule. Then I copy pasted the business rules data into the decision rules excel. And imported it straight away.
- First export the business rule
- Do the same for the new Decision rules:
- Open both Excel files.
Left: new Decision rules ; right: old Business Rules.
- Copy paste al the data from the one file to the other one.
- Import the updated decision rules excel
Importing the Excel
After creating and importing the necessary Decision Rules, release and deploy the whole project.
The main difference here is that you release and deploy the whole project at once, instead of rule by rule in the former Business Rules. (What an ease!)
After deploying, we saw that the status changed from Draft to Revised Content and that we were able to retrieve the ID and .. the version.
This is something I did not expect. When using the API’s from Business Rules, I knew that it was best practice to always use the same revision and change the version. That way the payload stayed the same without having to change the version you needed. We don’t want a version hardcoded in our payload, do we?
But when using the Decision Rules, you only have the possibility to use the version instead of the revision.
Conclusion
As a workaround, I had to create a version in the environment variables. This way the version has only to be adjusted in the main automation that starts several workflows at once.
Overall, I’m really positive about migrating to the decision rules.
But hopefully it will soon be possible to invoke the API with the most recent version. This is a real pain when using the API’s combined with decision rules.
If you want to know more about the differences between Business Rules and Decision Rules, I suggest you read this informative blog: https://blogs.sap.com/2023/06/26/business-rules-vs-decisions/
All API’s regarding SAP Build Process Automation can be found here: https://api.sap.com/package/SAPProcessAutomation/all
Want to know more about my journey in migrating everything from iRPA and Workflow to SAP Build Process Automation? Follow me!
Questions, thoughts or comments? I’d love to hear them. Let’s get in touch!
- SAP Managed Tags:
1 Comment
