Introduction:
In this Blog, I would like to explain how
Exceptions can be handled in your processes using Process Visibility actions, based on conditions.
The triggering of processes can be enabled based on visibility insights, to receive notifications and react to critical situations.
This Blog aims to provide information about the configuration steps to leverage the insight to action workflows to notify administrators and/or business users when certain conditions arise in a business process.
Process flow – Setup and Configuration:
Subscribe to SAP Build Process Automation as documented here.
Configure SAP Build Process Automation Destination as described in the Prerequisites section towards the end of this Blog.
Use case:
The Sales Order Management scenario is used to illustrate this Blog. Based on sales order data received as input, the approval process is optimised and happens manually or automatically. In case the process fails, some actors can be notified, as Administrator or Business Expert, via a trigger capability in Process Visibility.
See below, a collapsed view of the process model:
Process Model
So, in this Sales Order Management Project, we have an Order Processing Demo process (as shown above). The project for Sales Order Management contains several artifacts including a process, an automation and a visibility scenario. The process model Order Processing Demo has a Form trigger. The user will enter a SalesOrderID and submit. An automation is then executed to extract the Sales Order details (sales order amount, etc.) from an excel document based on the SalesOrderID. Manual or automatic approval is evaluated into a condition and recipients receive a notification.
There is also a Process Visibility scenario to notify Administrators or Business Users when a State (i.e. abruptly ended), a Status (i.e. critical) or SubStatus (i.e. failed) is reached. There are standard States, Status and SubStatus and it is also possible to create custom ones. It is possible to define a System trigger (automatic trigger) or User action trigger (manual trigger) in the Process Visibility scenario and configure the workflow or process that will be started if the condition is met (i.e. Process SubStatus equals failed).
Please see the help documentation for more details.
In our use case, we have modelled a Visibility scenario with an action (Trigger type: System) to trigger a workflow (NotifyProcessAdministrators) on failed or suspended instances.
Let’s get into the configuration details..
So, within the Visibility scenario, firstly appropriate attribute needs to be created. This is required, as the context needs to be passed, when the workflow from Process Visibility is to be triggered. Within the context, two values are passed.
SubStatus – This is a default Attribute from Process Visibility, to provide insights on a process state.
Details about the SubStatus are available in the ‘Status’ tab.
Status
workflowInstanceID – This is a Calculated Attribute that needs to be created. In this case, please note that the Name needs to be the same as used in the workflow start payload.
This information will be used (for example), in the Task title sent to the administrator.
Attribute_1
Attribute_2
As a next step, a destination with configuration OAuth2ClientCredentials would be required to start an instance of the workflow. See Prerequisites section for destination configuration. This destination will be used later in the configuration. It is meant to initiate the workflow.
To demo the feature, we are using an existing workflow model, available at SAP Business Accelerator Hub. This workflow can be consumed from Process Visibility scenario with minimal configuration. It is triggered when the Process Status changes to any of the defined/custom statuses configured in the scenario. In our case, as our actions include ‘suspended’/’failed’, a workflow should be triggered when these conditions are met.
Below, an overview of the model opened within SAP Business Application Studio. When the SubStatus condition is reached and evaluated, the recipient will receive a user task to process.
Note: A group within SAP BTP for Process Admin / Process Operator needs to be available in the SAP BTP Cockpit and configured with users. If the group is not available as task recipient, then assign the task manually from the monitoring application.
Workflow Model
Then, select the ‘Actions’ tab to create an action. You can either trigger a workflow or a process. We are calling a Workflow in our case with the below configuration.
Actions
‘Conditions’ section would be shown once action is created. You will have the option to create certain conditions to Indicate when the Workflow will be triggered. Here, we have defined the conditions (Process Failed / Process Suspended).
Select the relevant trigger type: in our case ‘System’
Select the Environment variable that was created in the project.
Workflow definition: You can select a workflow or a process. Here we select a workflow as we have already deployed this model in our tenant.
Start context: Pass the name of the calculated attribute “workflowInstanceId” that was created in the earlier step.
Add Conditions using ‘Status’ and ‘SubStatus’ attributes.
‘Save’ and ‘activate’ your Visibility Scenario.
At runtime, on SubStatus change, Process Visibility will trigger the System action and will start the workflow. A workflow task will be available in the inbox of the recipient group.
During the workflow execution at runtime, if an unforeseen situation occurs, Process Visibility will start the workflow definition “NotifyProcessAdministrators” to notify the recipients, that the process requires attention. In our scenario, the recipients will receive a task with details about the instance and the latest error message. The workflow model is fully customisable.
My Inbox
The instances of the notifications workflows are visible in SAP Build Monitoring section.
Logs
The context data of the instance is also visible and contains information about the failed process. The administrator can navigate to the failed instance to analyse the logs in detail and take necessary steps for resolution of the issue.
Context
Note: Ensure that you regenerate the scenario data in the Monitoring section (Path: Monitoring –> Visibility Scenarios –> <Your_Visibility_Scenario> –> Processing Information –> Clear Processed Data. Once the data is cleared, click on ‘Process Data’
Prerequisites:
HTTP destination is required in the BTP subaccount where SAP Build Process Automation is subscribed. Create a destination with the name “sap_process_automation_service” and with the following configuration, if it doesn’t exist already. Please refer to this documentation to understand how HTTP destination is created.
Destination1
Destination with the Authentication: OAuth2ClientCredentials needs to be configured to start an instance of the workflow. More configuration details of the destination be found here.
Recap:
Trigger Process -> Needs no destination. This is only available in SAP Build Process Automation and not in Workflow Management.
Trigger Workflow -> Is offered both in SAP Build Process Automation and Workflow Management.
For Workflow Management, please refer to this document on how the destination should be created.
For SAP Build Process Automation, please refer this documentation.
Should you have any questions, you can comment below or post a question to our SAP Build Process Automation forum. Check out our SAP Road Map Explorer to know more about upcoming features.
Until the next blog post, stay tuned!
Introduction:In this Blog, I would like to explain how Exceptions can be handled in your processes using Process Visibility actions, based on conditions. The triggering of processes can be enabled based on visibility insights, to receive notifications and react to critical situations. This Blog aims to provide information about the configuration steps to leverage the insight to action workflows to notify administrators and/or business users when certain conditions arise in a business process. Process flow – Setup and Configuration:Subscribe to SAP Build Process Automation as documented here. Configure SAP Build Process Automation Destination as described in the Prerequisites section towards the end of this Blog. Use case:The Sales Order Management scenario is used to illustrate this Blog. Based on sales order data received as input, the approval process is optimised and happens manually or automatically. In case the process fails, some actors can be notified, as Administrator or Business Expert, via a trigger capability in Process Visibility. See below, a collapsed view of the process model: Process ModelSo, in this Sales Order Management Project, we have an Order Processing Demo process (as shown above). The project for Sales Order Management contains several artifacts including a process, an automation and a visibility scenario. The process model Order Processing Demo has a Form trigger. The user will enter a SalesOrderID and submit. An automation is then executed to extract the Sales Order details (sales order amount, etc.) from an excel document based on the SalesOrderID. Manual or automatic approval is evaluated into a condition and recipients receive a notification. There is also a Process Visibility scenario to notify Administrators or Business Users when a State (i.e. abruptly ended), a Status (i.e. critical) or SubStatus (i.e. failed) is reached. There are standard States, Status and SubStatus and it is also possible to create custom ones. It is possible to define a System trigger (automatic trigger) or User action trigger (manual trigger) in the Process Visibility scenario and configure the workflow or process that will be started if the condition is met (i.e. Process SubStatus equals failed). Please see the help documentation for more details. In our use case, we have modelled a Visibility scenario with an action (Trigger type: System) to trigger a workflow (NotifyProcessAdministrators) on failed or suspended instances. Let’s get into the configuration details.. So, within the Visibility scenario, firstly appropriate attribute needs to be created. This is required, as the context needs to be passed, when the workflow from Process Visibility is to be triggered. Within the context, two values are passed. SubStatus – This is a default Attribute from Process Visibility, to provide insights on a process state. Details about the SubStatus are available in the ‘Status’ tab. StatusworkflowInstanceID – This is a Calculated Attribute that needs to be created. In this case, please note that the Name needs to be the same as used in the workflow start payload. This information will be used (for example), in the Task title sent to the administrator. Attribute_1 Attribute_2As a next step, a destination with configuration OAuth2ClientCredentials would be required to start an instance of the workflow. See Prerequisites section for destination configuration. This destination will be used later in the configuration. It is meant to initiate the workflow. To demo the feature, we are using an existing workflow model, available at SAP Business Accelerator Hub. This workflow can be consumed from Process Visibility scenario with minimal configuration. It is triggered when the Process Status changes to any of the defined/custom statuses configured in the scenario. In our case, as our actions include ‘suspended’/’failed’, a workflow should be triggered when these conditions are met. Below, an overview of the model opened within SAP Business Application Studio. When the SubStatus condition is reached and evaluated, the recipient will receive a user task to process. Note: A group within SAP BTP for Process Admin / Process Operator needs to be available in the SAP BTP Cockpit and configured with users. If the group is not available as task recipient, then assign the task manually from the monitoring application. Workflow Model Then, select the ‘Actions’ tab to create an action. You can either trigger a workflow or a process. We are calling a Workflow in our case with the below configuration. Actions ‘Conditions’ section would be shown once action is created. You will have the option to create certain conditions to Indicate when the Workflow will be triggered. Here, we have defined the conditions (Process Failed / Process Suspended). Select the relevant trigger type: in our case ‘System’ Select the Environment variable that was created in the project. Workflow definition: You can select a workflow or a process. Here we select a workflow as we have already deployed this model in our tenant. Start context: Pass the name of the calculated attribute “workflowInstanceId” that was created in the earlier step.Add Conditions using ‘Status’ and ‘SubStatus’ attributes.’Save’ and ‘activate’ your Visibility Scenario. At runtime, on SubStatus change, Process Visibility will trigger the System action and will start the workflow. A workflow task will be available in the inbox of the recipient group. During the workflow execution at runtime, if an unforeseen situation occurs, Process Visibility will start the workflow definition “NotifyProcessAdministrators” to notify the recipients, that the process requires attention. In our scenario, the recipients will receive a task with details about the instance and the latest error message. The workflow model is fully customisable. My Inbox The instances of the notifications workflows are visible in SAP Build Monitoring section. Logs The context data of the instance is also visible and contains information about the failed process. The administrator can navigate to the failed instance to analyse the logs in detail and take necessary steps for resolution of the issue. ContextNote: Ensure that you regenerate the scenario data in the Monitoring section (Path: Monitoring –> Visibility Scenarios –> <Your_Visibility_Scenario> –> Processing Information –> Clear Processed Data. Once the data is cleared, click on ‘Process Data’ Prerequisites:HTTP destination is required in the BTP subaccount where SAP Build Process Automation is subscribed. Create a destination with the name “sap_process_automation_service” and with the following configuration, if it doesn’t exist already. Please refer to this documentation to understand how HTTP destination is created. Destination1 Destination with the Authentication: OAuth2ClientCredentials needs to be configured to start an instance of the workflow. More configuration details of the destination be found here. Destination2Recap:Trigger Process -> Needs no destination. This is only available in SAP Build Process Automation and not in Workflow Management. Trigger Workflow -> Is offered both in SAP Build Process Automation and Workflow Management. For Workflow Management, please refer to this document on how the destination should be created. For SAP Build Process Automation, please refer this documentation. Should you have any questions, you can comment below or post a question to our SAP Build Process Automation forum. Check out our SAP Road Map Explorer to know more about upcoming features.Until the next blog post, stay tuned! Read More Technology Blogs by SAP articles
#SAP
#SAPTechnologyblog
+ There are no comments
Add yours