Configuring Subprocesses in SAP Build Process Automation

[thomas_volmering]

Modularising your Process Automations

As I have highlighted in my recent blog Introducing Subprocesses as Referenced Subflows in SAP Build Process Automation, you can easily modularize your process automation projects, create and reuse a set of common process activities in a subflow, and leverage them in one or across multiple master processes without duplicating efforts.

Today, I will describe how you can easily configure subprocesses as embedded and referenced subflows and dramatically simplify process models, thus increasing the understandability and clarity of your flows.

Configuration Ingredients of a Subprocess

In order to leverage subprocesses, you should consider:

• Subprocess Input to pass variables to the activities of the subprocess from the main process


• Subprocess Output to pass variables from the subprocess to the main process


• Configuration settings to build embedded or referenced subprocess with an API Trigger

To learn more about how to leverage and configure subprocesses, let me use again the example of departmental requisition processing with different approval logic for different material and organisations. Imagine you want to build a comprehensive process that:

• Requires a 2-step approval for all hardware (Manager and IT Services) in Organisation 0002


• Allows an accelerated approval logic for any requests in Organisation 0001 <2.000€ and the Cost Center Owner approval is all that is needed


• Demands an advanced approval logic for all hardware requirements >=2.000€ with a multi-step approval logic.


• Requires as a standard in Organisation 0001, a Cost Center Budget Officer reviews all requests before a business rule automatically shall evaluate and provide the decision logic for the above business requirements.

Stage 1: The Main Process with 2 Subprocesses

Fig1: The Main Process with a form as a process trigger, a conditional branch to separate 0001 and 0002 requests, the Cost Center Budget Officer Review task, a condition to separate between advanced and accelerated processing.

 

Fig2: Summary of the condition "If Purchasing Organisation is equal 0002" = If branch

Fig3: Data flow from the Start form (Process Trigger) to the Review task of the Cost Center Budget Officer (BO)

Fig4: The above data type definition is leveraged for the business rules as well as the Subprocess Input und Output definition.

Fig5: After defining the Input and Output variable definition on the canvas of the subprocess (here Accelerated Processing), the Input mapping from the Main Process has to be done, exactly as you would do it with any other activity or skill (as, e.g., action).

Fig6: The Advanced Processing subprocess uses a simplified data type definition to demonstrate that you can use different variable definitions for the data flow in different subprocesses. Notice also, that for other more expensive developer hardware, the process here uses an existing workflow as a subprocess that has been defined before as a standard workflow in SAP Business Application Studio (SBAS) and the BPMN-based workflow editor. This helps customers to leverage existing workflow definitions and supports the migration and transformation strategy towards SAP Build.

Stage 2: Creating an additional Subprocess

Let me now further modularise the pretty complex main process, as (a) the main process still features directly approval process logic for Organisation 0002 and hence some steps that are duplicates, e.g. the action to create a Purchase Requisition in SAP S/4HANA and the business validation form and email-notifications.



Fig8: I create a new subprocess for 0002 2-step approvals and delete all unnecessary process steps that can be omitted.

Fig9: Above the Updated Main Process - updated with a new subprocess 0002 Two-step approval in which I built all necessary steps that have been before in the main process. Much more understandable!

Fig10: Notice that, when leveraging the subprocess in an embedded configuration, you only need to define the Input / Output and perform the necessary mapping steps. No trigger is needed for this process configuration.

Fig11: The Advanced Processing subprocess has been configured with an API Trigger in addition (which is optional in case you want to us it as a referenced subprocess, being able to invoke it for instance independently from an application or from another process.

Fig12: You can configure subprocesses to "run on behalf of", hence selecting the process participant from a preceding step in the main process. This configuration helps you as well to securely interact with a business application / system using the permission of the process participant.

Subprocesses at Runtime

Fig13: Let us trigger the process now with the form to create a request.

Fig14: I created multiple line-items to order a couple of MacBooks and selected Organisation 0001. The Cost Center Budget Officer is asked to review the request to check if this is in budget.

Fig15: As the request is above 2.000€, the Manager needs to approve after the positive budget review (Advanced Processing subprocess).

Fig16: The next request is below 2.000€ in Organisation 0001. So I expect the Accelerated Subprocess to be triggered.

Fig17: The 3rd request is above 2.000€ but in Organisation 0002, so I expect the subprocess "0002 Two-step approval"  to be triggered.

Fig18: Notice the different tasks that have been created from the 3 subprocesses out of the main process.

Fig19: In the monitoring dashboard, you can check the execution of Main and Subprocesses as well as the data flow.

Fig20: From here, you can drill down into the subprocess monitoring and see every step that is executed.

Conclusion

Subprocesses as referenced subflows are a powerful addition to our process automation platform, providing users with the ability to create and reuse a common set of process automation steps (workflows, forms and approval tasks, bot automations, business rules) across multiple processes. With Subprocesses, you can streamline your process automations, reduce the risk of errors, and simplify maintenance. In upcoming blogs, we will explain how to configure process visibility for subprocesses and how we plan to enable for-each and par-for-each loops, send back and exceptions.

For an update on regular release updates, please have a look at What’s New for SAP Build Process Automation.

We hope you enjoy using this new feature and look forward to your feedback.

Disclaimer:

Please note that the example that I use above is a simple demonstration example, covering a departmental pre-approval of requisitions before Orders are created in SAP S/4HANA. It is not intended to re-build any as-is business application functionality.