Control Custom Actions Based on Business Conditions
Warning: This page contains code snippets and require the reader to have good understanding about the model-view-controller (MVC) architecture in SAPUI5.
In the previous blog I had explained how you can add a custom action in SAP Operational Process Intelligence using the SAPUI5 extension concepts.
You would have noticed that the custom action is enabled for all the business scenarios in your system. You might want to enable this action only for a particular business scenario or you want to enable the action only if the order is in ‘Critical’ state (either overdue or running late) or you might want to enable the action for all the orders coming from your premium customers irrespective of the order status. You can follow these steps to enable/disable the custom footer actions based on business conditions.
Use case A: Conditions based on business scenario
You might want to enable/disable the custom actions based on business scenario. For example, you have both ‘Order to Cash’ and ‘Procure to Pay’ business scenarios in your system and you want to show the ‘Release Sales Order’ action only for the Order to Cash scenario.
Step A.1: Identify the scenario definition ID
Every business scenario will have a unique ID called as scenario definition ID. This ID is generated when you create a NEW business scenario and will never change over the period for that scenario. There are multiple ways to find this ID for your scenario, but the easiest way it to login to SAP OPInt in your browser and visit the particular scenario in question. When you are in the scenario overview page, observe the URL to find the scenario definition ID which starts with SCN.
Step A.2: Edit the CustomActionButtons.fragment.js
Open the CustomActionButtons.fragment.js file and you should have the following implementation. This is where you have defined the custom action.
Bind the visibility property for the button UI element as marked in the following image. We access the SAP OPInt’s JSON model “scenarioDefinition” to read the attribute scenarioDefinitionId (line 20).
Note that the scenario definition ID is hardcoded (below, line 22) for simplicity but you can persist this information in a DB table and query it to set the visibility for a set of scenario.
Use case B: Conditions based on Instance Status
You might want to enable/disable the custom actions based on the status of the instance (order) status as shown in SAP OPInt – Critical / At Risk / On Track.
Step B.1: Edit the CustomActionButtons.fragment.js
Bind the visibility property for the button as marked in the following image. We access the JSON model “scenarioInstance” to read the attribute SC_STATUS under contextDataFoundation (line 20).
Possible values for the attribute SC_STATUS = CRITICAL, AT_RISK, ON_TRACK
If you want to set the visibility of the button based on the current phase then you can use the attribute scenarioInstance>/phases/currentPhaseName.
Use case C: Conditions Based on Context
You might want to enable/disable the custom actions based on the context of the instance (order) as available in SAP OPInt. Refer to the business scenario or the context calculation (in HANA Studio) to know the list of attributes available for your scenario since the context varies from scenario to scenario.
In my example, I have an attribute called SEGMENT which holds the value for segment which the customer belongs to. I want to show the ticket for all orders which are created for Premium customers.
Step C.1: Edit the CustomActionButtons.fragment.js
Bind the visibility property for the button as marked in the following image. We access the JSON model “information” to read the attribute SEGMENT under contextDataFoundation (line 20).
Note: There are chances that the process context could change as the backend process change. The attribute used here could be either renamed or removed. In that case, you might have to adjust it here as well.
Use case D: Conditions Based on Authorization
You might want to enable/disable the custom actions based on the authorization for the user. For example, only a user with the role of a manager should be able to view and perform the custom action.
How will it work – We will create a dummy table and give the privilege to access this table to the manager role. Then we will create a XSJS service to query this table. Any user who is able to successfully query the table via the XSJS service will have the action available for him/her.
Step D.1: Create a dummy table: You can either create a dummy table or use an existing table for which only ‘manager’ will have the privilege.
Step D.2: Assign the privilege to the manager role
Assign the Object Privilege to perform SELECT on the table to the manager role.
Step D.3: Create a XSJS service to query this table: Create file under (in this example) the package /my/opi/workspace/server/xsjs/ and call it as getAuthForCurrentUser.xsjs
In the XSJS file, we would be performing a simple SELECT on the dummy table created earlier. If it was successful then we will return a response status OK (success). If the select resulted in an exception then we return a response status FORBIDDEN (not authorized).
Step D.4: Consume the authorization service in CustomActionButtons.fragment.js
In the fragment.js, call the XSJS service and set the visibility of the action based on the result of the service. Note that we have explicitly set the ID for the action button in line 11, which we later try to access in line 24 & 27.