A few months ago I wrote a blog post about SAP Build Process Automation and the failure for handling the Business Rules service - from a SAP BTP perspective. At the time it was difficult to work through the tooling as it was very different to the previous service. What I can say is that we are actively using the Decisions functionality (as part of SAP BPA) in our current projects and it not only offers all of the functionality Business rules used to offer but it is also faster. So, overall I am happy that Decisions now cover most of what was there previously but I still stand by my view of it being a completely separate service, with it's own licensing arrangements to offer customers better flexibility. That is, they do not have to buy SAP Build Process Automation if they only want to use Decisions. Forcing customers into the whole SAP BPA suite I don't agree with and it may actually stop customers from enabling it. Anyway, let me go through my analysis and compare Business Rules vs Decisions.
Business Rules
Let's do a quick recap. This service was originally part of Neo but was then morphed into the SAP Workflow Management service. At one point in time customers use to have to create an MTA app to enable it - this was definitely not great. Eventually though a Booster was created and it allowed customers and partners to get started on Business rules much faster.
Figure:1 Workflow Management instance that includes Business Rules
Several applications were delivered as part of the Workflow Management service, one of which was the Manage Business rules application. This was the UI to maintain the business rules.
Figure:2 Manage Business Rules application
To maintain Business rules there were a fair number of artifacts including:
- Project
- Data Objects (structures / tables)
- Rules
- Rulesets
- Rule Services
Each of these items were connected and had to be maintained in a specific sequence. Once all items were activated there was a single Deploy step however once this was carried out there was no way to see which version had in fact been deployed. With this in mind let's go through the positives and negatives of this Business Rules service.
Positives:
- User friendly interface - could be easily maintained by savvy business users.
- Can include Business Rules on Launchpads as a separate tile.
- Relatively quick to set up and maintain
- Easy to use API's
Negatives:
- Multiple activations required - this made it difficult for customers to support and maintain
- No activate ALL function - so migrations were messy
- Cannot see Deployment version
- No change log
- Cannot see change dates or deployment dates
- No visual representation on the artefact relationships
Overall, offering decoupled business logic to applications is a massive plus and provides ultimate flexibility to applications built on SAP's Business Technology Platform and this service offered that. But the negatives were pretty major. The biggest issue was the support and maintenance especially if new rules were implemented in the existing project. When the project was migrated ALL objects had to be re-activated. This was time consuming, cumbersome - poor user experience overall. I still think it is a shame more updates to this service were not carried out but I guess SAP had a longer term goal of migrating it to SAP BPA so understand.
Let's now cover Decisions.
Decisions
This is a new function within the new SAP Build Process Automation (SAP BPA) service.
Figure:3 SAP Build Process Automation instance
To create decisions you need to go through the Automations UI and on the launch page it is not really clear how you go about creating a project for Decisions only. I have provided this feedback to SAP as this may be a barrier for customers. There should be an ability to create a project just for Decisions and it should be clear on the initial launch page.
Figure:4 Creating an Automation initial page
To maintain Decisions there are less artifacts including:
- Project (Process Automation type)
- Data Types
- Decisions
The maintenance is much easier with less artifacts to worry about. There is also a nice visual representation of the decisions that is easier for users to follow.
Figure:5 Decisions UI
There is also a much simpler deploy process and you can now determine which version is deployed and when previous versions were deployed as well. Here are the positives and negatives of Decisions.
Positives:
- Decisions can be set up faster than Business Rules - less artifacts!
- Less artifacts involved and multiple activations NOT required
- Can release and deploy different versions
- Can Undeploy a version
- Can maintain notes against each release
- Simple deployment method (Save, Release, Deploy)
- Better User experience (less steps) especially with the Visual UI representation
- Easy to use API's - these are different API's!
Limitations:
- New tooling and takes a bit getting used to
- No tile available atm to integrate into Launchpads
- Cannot see running history (and dates) of deployments - can only view 1 at a time
I also want to call out other functionalities I feel are implemented better in Decisions than Business rules.
- As far as the new tooling is concerned there is a major difference when you want to retrieve a table of records. Previously in Business Rules you defined a Table and when this was the result set it meant retrieval of ALL MATCHING records. With the new tooling you simply select the [List] checkbox and this automatically sets the decision to ALL MATCH. In recent updates I also believe users now have the choice to set this, whereas before it was set automatically. This is what it looks like. You can see that this parameter has the List checkbox active meaning multiple records will be returned.
Figure:6 Output parameter List option (to set to ALL MATCH)
- The import and output options are pretty much the same as they were and similar formats for the files.
- Seeing the information around Decision deployment is really good - who created and who modified and the date it was modified are nice additions.
Figure:7 Decisions deployment information
- The overall UI is easier to navigate and follow and good to see both Data types and Decisions are all in the one place. Previously you had to navigate back and forth from Data Types (or open multiple browser windows) to Decisions to other artefacts - a bit annoying and poor UX leading to longer support and maintenance times. Now when you click on the Data types or Decisions they are loaded as tabs in the UI so you can quickly navigate to what you want to look at. Really handy.
Figure:8 Decisions artifacts - you can see Data types and Decisions on one page
You can see here the tabs view making it faster and easier to navigate to different artifacts without multiple browser sessions.
Figure:9 Decisions artifacts tabular view
- Retrieving the ID's that need to be used in the API call are a bit difficult to find. In Business Rules you had to include the ID field using the Settings cog to be able to retrieve the Rule service ID. In Decisions, you use the 3 dots icon in the top right hand corner of the Decisions UI and then click [View Details].
Figure:10 Decision ID for the API call
Figure:11 Decisions ID and Version
At the moment the Version is required in the API call but in future releases I believe this is being removed.
So overall I must say that I believe the new Decisions sub-service is better than the previous Business Rules service (as part of Workflow Management). The next items I need to work through include migration of existing Business Rules projects to Decisions as I have not tried this as yet. I did run an internal Dev session a few weeks ago on Decisions and the team were really excited by the new UI and the ease with which they can now include Decisions into app development.
A big thankyou to archana.shukla and the extended team for being patient and spending the time to go through the new Decisions functions. Really appreciate it.
Look out for a future blog post on how Decisions can be used to build an application with the ultimate flexibility. 🙂
Thanks for reading, feel free to leave a comment about your experiences!
- SAP Managed Tags:
8 Comments
