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.

[Manjunath]

Hi thomas.volmering Thanks for the blog. One of my customers has multi-level approval scenarios, where we need a loop. I understand that the iterative flow logic is available in Q2 2023. But, I think, we can use a sub-process approach for achieving multi-level approval scenarios (not just 2 level of approvals as mentioned in this blog) without the need for iterative flow logic. Can you please confirm?

Thanks, manju

[thomas_volmering]

Hi Manjunath,

yes, multi-level approval logic can be implemented with or without embedded or referenced subflows. You can simply add conditions, additional steps and adjust the receiver determination rule (decision table). Using subprocesses helps to modularise comprehensive process automations and simplify the overall main process model. Iterative flow logic is more about loops (for-each and par-for-each) and send back to requester. We are working on that. In doubt, you can as well build a complex workflow with the Workflow Editor in SBAS, deploy it to SBPA and include it as a subprocess in the SBPA process as described in this blog.

Regards,

Thomas

[Fidudjan31]

Hi Thomas.

Thanks for this sharing this example.

We are currentyl evaluation the worflow solution as we consider it could bring a lot of value w/o reinventing our information system.

However I am strugling on one blocking point to build our futures workflows in a context of EDA.

We want to build some workflows that would allow interaction with users but as well some with "events" that take place on the backend.

However, the only place we can catch a trigger seems to be the beginning of the process.

Thus I tought I could use sub process with another event to trigger the next steps. Unfortunately, using a sub process disable this second event. Thus I can not condition the sub process to the two events, main process reached the sub process AND one event is raised.

Is there any way to master such a combined starting condition or simply to get a sort of "Event" listener that I could use instead for non human actions ?

 

on the top of this, a standard connector from advanced envent mesh to SAP Build Process Automation would be nice 🙂

Thanks.

 

 

[adrian-ngo]

Hi Thomas,

Thank you for these nice blogs! 

Is it possible to use an API trigger to start a workflow-B instance as a child instance (referenced subflow) of a workflow-A instance? To be more precise, I have written my thoughts here:
https://community.sap.com/t5/technology-blogs-by-sap/start-your-business-process-through-an-api-trig...

Best regards
Adrian