My colleagues published a content package "Sample Sales Order Approval Extension with flexible workflow" on API Business Hub which offers an outcome driven extension workflow and combines a custom flexible workflow scenario and a SAP BTP Workflow to approve Sales Orders.
From a use case perspective, you could think of including process participants from outside into the SAP S/4HANA Process. Or you include centrally managed services from SAP BTP like a Rules Service into your SAP S/4HANA workflow project. Or you like to leverage ML services for recommendations like the newly offered Workflow Intelligence capability. And maybe others. I implemented in the scenario for content package the use case with process participants from outside to show the possibilities.
In line with side-by-side extensibility recommendation flexible workflow offers an activity type "extension step". The sample package is a possibility to quick start development on an own implementation or evaluate the extensibility possibilities in your workflow projects. Therefore, the implementation is simple and has some limitations. I will give an short overview and add some points in addition to the official documentation.
The solution architecture gives an overview on the connection between Sales Order Creation in SAP S/4HANA and SAP BTP workflow over the flexible workflow capability of SAP Business Workflow. There is a configuration of decision reasons, which needs to be customized. Here we want to start a Flexible Workflow which is the internal approval solution. After setting an internal approval reason a BAdI checks after saving the Sales Order if an approval is necessary. In the BAdI we define when a start event should be thrown and check if a workflow is defined in the Manage Workflow Application for our scenario. If the business process expert defined an extension step with a workflow definition from the connected BTP subaccount during runtime the flexible workflow starts the workflow with a standardize payload. In the extension workflow we derive the complete header data over an API for the Sales Order in approval. After preparation the Rule Payload a Rules Service is called to determine the approvers. If that is not successful a User Decision Task will be created for an Administrator to define the agents manually. In case the decision table in the rule has an approver for the Sales Order the Approval Task is created. The Approval UI is a form which my colleagues developed for a Manage Sales Order Package.
To combine SAP S/4HANA and SAP BTP you need an account with the activated services and setup described in the setup guide. For productive use you need respective licenses for S/4HANA and SAP Workflow Management (or CPEA). You can import the package in the Workflow Management Launchpad using the flexibility cockpit or download the source code and add it to your SAP Business Application Studio (SBAS) Project.
You can find a more detailed blog on how to develop and test an extension flexible workflow scenario and a BTP workflow published here.
As of today, the extension step is only available for custom workflow scenarios. As scenario developer you include an extension activity and with that activate the side-by-side extension (For classic Business Workflows is also a standard task TS77408500 available).
As this is an outcome driven extension, we must define the possible outcomes.
During configuration of the flexible workflows in Manage Workflow a process expert defines the rules for which sales orders an extension workflow should be triggered and which workflow definition on the connected BTP subaccount is called.
The exception handling needs to be implemented in the callback Method of the runtime class (IF_SWF_FLEX_IFS_RUN_APPL_STEP~AFTER_COMPLETION_CALLBACK) e.g., if you offer a rework step.
The workflow definition is defined in SBAS.
The Agent determination is done by a business rules service with a decision table to identify the responsible agent.
As Task-UI we use a form with Sales Order Header and Item data.
In general, the extension workflow definition is simple. Agent determination via a custom decision table with input from Sales Order Header Data. One level approval. If your use case needs more, you can enhance the workflow in SBAS.
As of today, there is a limitation regarding decision notes. Recommendation here is to derive the email address from the requester over an Integration Flow (there is some almost similar integration content, you could look at) and send comments via an additional email task to the requester.
Extension step as of today are not in the SAP S/4HANA MyInbox Workflow Log only in classical Workflow Log and in the Flexible Workflow Instance Component.
We didn´t cover the rework process in SAP S/4 HANA as well no deadline definitions nor deadline actions (Short preview: with 2202 scenario specific deadline actions will be available). If you check the standard scenario, there is a rework step available. If you configure your workflow like shown in the following screenshot, it will trigger the rework task directly in case of outcome "REWORK_REQUESTED". If you have more than one step approval and only want to start the actual step again, you need to configure the action "repeat step".
The exchanged workflow context/container for start payload and callback is simple:
If you need more context, please read two sentences further.
We work on improvements to overcome that limitations (especially for decision notes and more context information from the beginning) in upcoming releases.
One hint, integration scenarios are also possible for SAP Business Workflow (and flexible workflows) via the standard task TS77408500. With this task you can transfer structures and objects into the start payload of the BTP workflow for more context driven scenarios. Until now unfortunately there is no blog and sample package for a context driven scenario available. Stay tuned!
As always this was teamwork, so finally, thanks to all contributors and special thanks to my team, the product owners, and the tech team responsible for the extension step.
From a use case perspective, you could think of including process participants from outside into the SAP S/4HANA Process. Or you include centrally managed services from SAP BTP like a Rules Service into your SAP S/4HANA workflow project. Or you like to leverage ML services for recommendations like the newly offered Workflow Intelligence capability. And maybe others. I implemented in the scenario for content package the use case with process participants from outside to show the possibilities.
In line with side-by-side extensibility recommendation flexible workflow offers an activity type "extension step". The sample package is a possibility to quick start development on an own implementation or evaluate the extensibility possibilities in your workflow projects. Therefore, the implementation is simple and has some limitations. I will give an short overview and add some points in addition to the official documentation.
Workflow @ SAP
Solution Architecture
The solution architecture gives an overview on the connection between Sales Order Creation in SAP S/4HANA and SAP BTP workflow over the flexible workflow capability of SAP Business Workflow. There is a configuration of decision reasons, which needs to be customized. Here we want to start a Flexible Workflow which is the internal approval solution. After setting an internal approval reason a BAdI checks after saving the Sales Order if an approval is necessary. In the BAdI we define when a start event should be thrown and check if a workflow is defined in the Manage Workflow Application for our scenario. If the business process expert defined an extension step with a workflow definition from the connected BTP subaccount during runtime the flexible workflow starts the workflow with a standardize payload. In the extension workflow we derive the complete header data over an API for the Sales Order in approval. After preparation the Rule Payload a Rules Service is called to determine the approvers. If that is not successful a User Decision Task will be created for an Administrator to define the agents manually. In case the decision table in the rule has an approver for the Sales Order the Approval Task is created. The Approval UI is a form which my colleagues developed for a Manage Sales Order Package.
Solution Diagram
Setup and license perspective
To combine SAP S/4HANA and SAP BTP you need an account with the activated services and setup described in the setup guide. For productive use you need respective licenses for S/4HANA and SAP Workflow Management (or CPEA). You can import the package in the Workflow Management Launchpad using the flexibility cockpit or download the source code and add it to your SAP Business Application Studio (SBAS) Project.
Some technical background
You can find a more detailed blog on how to develop and test an extension flexible workflow scenario and a BTP workflow published here.
SAP S/4HANA artifacts
As of today, the extension step is only available for custom workflow scenarios. As scenario developer you include an extension activity and with that activate the side-by-side extension (For classic Business Workflows is also a standard task TS77408500 available).
Create extension activity in SWDD_SCENARIO
As this is an outcome driven extension, we must define the possible outcomes.
Define outcomes
During configuration of the flexible workflows in Manage Workflow a process expert defines the rules for which sales orders an extension workflow should be triggered and which workflow definition on the connected BTP subaccount is called.
Manage Workflow App - Add extension step
The exception handling needs to be implemented in the callback Method of the runtime class (IF_SWF_FLEX_IFS_RUN_APPL_STEP~AFTER_COMPLETION_CALLBACK) e.g., if you offer a rework step.
SAP BTP artifacts
The workflow definition is defined in SBAS.
Extension Workflow Definition
The Agent determination is done by a business rules service with a decision table to identify the responsible agent.
Agent determination via decision table
As Task-UI we use a form with Sales Order Header and Item data.
My Inbox
Known Limitations
In general, the extension workflow definition is simple. Agent determination via a custom decision table with input from Sales Order Header Data. One level approval. If your use case needs more, you can enhance the workflow in SBAS.
As of today, there is a limitation regarding decision notes. Recommendation here is to derive the email address from the requester over an Integration Flow (there is some almost similar integration content, you could look at) and send comments via an additional email task to the requester.
Extension step as of today are not in the SAP S/4HANA MyInbox Workflow Log only in classical Workflow Log and in the Flexible Workflow Instance Component.
We didn´t cover the rework process in SAP S/4 HANA as well no deadline definitions nor deadline actions (Short preview: with 2202 scenario specific deadline actions will be available). If you check the standard scenario, there is a rework step available. If you configure your workflow like shown in the following screenshot, it will trigger the rework task directly in case of outcome "REWORK_REQUESTED". If you have more than one step approval and only want to start the actual step again, you need to configure the action "repeat step".
Configure Rework
The exchanged workflow context/container for start payload and callback is simple:
If you need more context, please read two sentences further.
We work on improvements to overcome that limitations (especially for decision notes and more context information from the beginning) in upcoming releases.
Finally
One hint, integration scenarios are also possible for SAP Business Workflow (and flexible workflows) via the standard task TS77408500. With this task you can transfer structures and objects into the start payload of the BTP workflow for more context driven scenarios. Until now unfortunately there is no blog and sample package for a context driven scenario available. Stay tuned!
As always this was teamwork, so finally, thanks to all contributors and special thanks to my team, the product owners, and the tech team responsible for the extension step.
- SAP Managed Tags:
