Skip to Content

I was recently working with a customer where they were looking to use SAP Cloud Platform Business Rules service. They have several Sales Organizations and wanted to maintain complex pricing rules for each of them. The expectation was to provide access to the business users within each Sales Organization who would be responsible for maintaining their pricing rules. Another requirement was to ensure that business users do not enter a pricing value below a given threshold. There needs to be some sort of validation of these rules which are being maintained by the users. In this blog, I am going to share my experience as to how we dealt with these requirements.

I am assuming you are familiar with the Business Rules service on SAP Cloud Platform. If you have not yet used it, I would highly recommend giving it a try. Archana has posted a blog “SAP Cloud Platform Business Rules – Try it Yourself” to help you get started with the trial instance. I have also posted a blog showing all the steps required to author the rules using Business Rules service – “Overview of Business Rules in Cloud Platform”. For this blog, I am going to reuse the same objects.

Here is the initial screen of Business Rules service. You would maintain the projects here and within each project maintain the rules.

In the screenshot above, you can see that I have created two projects for the similar purpose, but suffixed the Sales Organizations in the end of the project name. Using this approach, business users belonging to Sales Organization 1040 would go into the project “CreditLimit_1040” and maintain the rules and likewise business users belonging to Sales Organization 1060 would use the project “CreditLimit_1060”.

Below is the decision table which has been maintained for Sales Organization 1040.

Similarly, I have maintained the decision table which is applicable for Sales Organization 1060.

Once the rules have been maintained, you need to provide access to business users to maintain them. It is not recommended to provide access to the whole Business Rules services. Firstly, it has got lot of additional information (which is not relevant to them), it might seem too technical and most importantly all the users will get to see all the projects. As of today, there is no provision within the Business Rules service to provide role access at granular level. Hence, users could accidentally access other projects and update them too. The recommendation is to build a Fiori App which could be used by the users to maintain the rules. There is a new SAPUI5 control called the “Rule Builder” which can be used to achieve this. Check out the SAPUI5 SDK documentation for  more information.

There is also SAP help page which describes how to use this control to build a Fiori App to author business rules.

This year at SAP TechED, there was a session “CPL164 – An Application Developer’s Guide to SAP Cloud Platform Business Rules – Hands-on” which also focused on this topic. I am reusing the code obtained from this session and building on top of it. The template along with the source code snippets has just been made available in GitHub.

I have placed my HTML5 application too in GitHub. You can import it into SAP WebIDE and deploy it to your trial account too.

There are few things to note in this application. When you open the neo-app.json file, you will notice references to “bpmrulesrepository” and “bpmrulesruntime” destinations which would have been automatically created in the SAP Cloud Platform account when the Business Rules service was activated. The application will make API calls to fetch and update the rules using these destinations.

In the XML view, you will notice the Rule Builder control which will be used to embed the decision table which we saw earlier in the Business Rules service.

The controller file is where majority of the logic resides. On the right hand-side, in the Outline section, you can see all the related functions which have been implemented to support working with the Rule Builder control. Also, notice at the top, I have highlighted the section, where the controller obtains the Project ID, Rule ID etc, from the application start-up parameters. This is required because I am going to reuse this HTML5 application to render different decision tables maintained in the Business Rules service.

How do we find the Project ID, Rule ID? When you navigate to the Business Rules project, you will be able to see few tabs. The Rules tab is where the decision table is maintained. When you open the rules, you will notice the URL in the below format.

https://bpmruleseditor-<your-account>trial.dispatcher.hanatrial.ondemand.com/index.html#//Projects(<projectID>,000001)/Rules(<ruleID>,<ruleVersion>,DT)/view/RuleDetails

Similarly, when you navigate to the RuleService tab, the URL would be in the below format.

https://bpmruleseditor-<your-account>trial.dispatcher.hanatrial.ondemand.com/index.html#//Projects(<projectID>,000001)/RuleServices(<ruleService>,000001)/view/RuleServiceDetails

You would need to make a note of these four ID’s

  • projectID
  • ruleID
  • ruleVersion
  • ruleService

The next steps is to deploy the HTML5 app to your account and create a Fiori Launchpad site using the Portal service. Again, I am assuming you know how to create a Fiori Launchpad site and configure HTML5 apps as a tile. If you don’t know, there are plenty of blogs available on this topic to help you out. There is an openSAP course “Building Portal Sites on SAP Cloud Platform” which  can help you get familiar with setting up a Fiori Launchpad on SAP Cloud Platform.

Using the Fiori Configuration Cockpit, I have configured two apps. Both these apps refer to the same HTML5 application which I have deployed earlier. Two main differences are – These apps are assigned to different catalog/groups/roles and has got different set of navigational parameters.

In the Navigational parameters, I have hard-coded the values for the four parameters which I had made a note of earlier.  These parameters would be passed to the application during runtime.

This is how my Fiori Launchpad would look like. Depending on the user who is logging in, it will pick up their assigned roles and show only the relevant tiles. If I logon as a business user belonging to Sales Organization 1060, I would only get access to a tile which will enable me to maintain the rules which are associated with the Business Rules project “CreditLimit_1060”.

When I click on the tile, it would launch the custom application which would embed the decision table associated with the relevant Business Rules project. In the below example, the decision table which is displayed belongs to the Sales Organization 1060.

As a business user, I have the option to click on “Edit” button to begin modifying the rules. There is also a table setting options which you can explore.

The Table settings provides the values which have been initially configured for this decision table. I can change these values and apply the changes from here.

In the below example, I have modified the Limit value of the last row to 55,000 and clicked on the “Deploy” button. This will trigger an update and apply the changes to the rules repository.

When I navigate back to the Business Rules service, I should be able to see the updated values in the decision table.

When using the Fiori App to manage rules, it is also possible to add validations to any particular cell. These validations can be triggered just before deploying the rules to the repository. As you can see, this approach of creating a Fiori app gives a much better user experience for the business users and also enables corporate validations to be applied on those rules.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. DJ Adams

    Thanks Murali, this is a nice next step in putting the puzzle pieces together for Business Rules on SCP. There are a lot of moving parts and interconnections … understanding these parts and interconnections is essential to be able to build out process workflows supported by this new rule engine.

     

    I think it’s also a good example of a slight departure from the “standard” Fiori apps we’ve seen so far, in that we’re predominantly consuming SAP-supplied service APIs that are not necessarily OData. That alone is reason enough to watch this space carefully.

     

    Cheers!

    dj

    (0) 

Leave a Reply