SAP Builders Blog Posts
Learn from peers about their low-code journey and write your own blog posts to share your thoughts and experiences as you become an SAP Builder.
cancel
Showing results for 
Search instead for 
Did you mean: 
Jerome
Advisor
Advisor
190

Introduction

With SAP Build Process Automation  you can create different artefacts to implement your business processes. Among them are:

  • Forms-based workflows (also known as processes)
  • Automations (for repetitive tasks)
  • Decisions (used as business rules in a process)
  • Captured applications (to be automated by bot)
  • Actions (to encapsulate APIs in processes)

Now you can mix automations and processes so a bot will have some role to play in the execution of a process. We have different scenarios:

  1. A process triggers another sub-process
    • In that case, the sub-process must reach its end before we resume the execution of the parent process
  2. A process triggers an automation
    • To resume the execution of the process, the automation must end first. It is a synchronous execution.
  3. An automation triggers another automation
    • If the child automation is a new job, it is totally independent from the parent automation. So the parent automation will just request the execution of a new job and continues its flow. The execution of the child automation will occur later on.
    • If the child automation is not a new job, then it is considered as a sub-automation and it must complete before the execution of the parent automation resumes.
  4. An automation triggers a process
    • As for a new job, the automation will trigger the execution of a process. But because of the long running definition of a process, where human can interact, it is not possible for the bot to wait the process to be complete. In that case, we will have to find another way to implement this ‘waiting action’.

Waiting actions

As explained in the introduction, it is generally not recommended to wait for the execution of a process within an automation. In this article, I’ll focus on the implementation of a waiting mechanism in a process.

Definition of the use case

Let’s imagine we have a business process. In this process, we are using Action artefacts to perform some API calls to external systems. As of now, in order to call actions in a loop, we need to use an automation.

Let’s say we have another bunch of actions to execute, but in order to execute them, we have to wait for the completion of the first batch of actions. So we have another automation, that should be trigger only when the subprocesses triggered in the first automations are completed.

To sum up, we have the following:

Jerome_0-1720467056076.png

And we need to find a way to implement the Wait step, since the existing Wait tools cannot determine when the instances of Process A will be finished.

Tools

To implement this wait mechanism, we will need the following:

  • Action to get the status of subprocesses (available here)
  • Decision to check the status of all subprocesses (see documentation)
  • Business key in the subprocesses (see documentation for definition of business key)

Implementation

First thing, you need to create an Action project, using the API available here. You can keep all the attributes from the action, or you can also remove some of them. But the most important one, that you need to keep, is the following:

Jerome_1-1720467056388.png

You might also need to remove the Max Length of the responseArray.definitionId attribute in the Output tab:

Jerome_2-1720467056379.png

Note : you would need to use a Destination to be able to use that action in a process. In my case, the destination is configured like below:

Jerome_3-1720467056095.png

where the URL is https://spa-api-gateway-bpi-eu-prod.cfapps.eu10.hana.ondemand.com/public/workflow/rest

Check the service key you created from the SAP Build Process Automation instance to know what URL you should use.

 

Once the action project is released and published to the library, let’s focus on the business project.

From the Lobby, let’s create a Business Process project. Here, you can add a Form trigger, or an API trigger, depending on your needs. Let’s add an automation, which will be designed to trigger the subprocess A. Ex:

Jerome_4-1720467056412.png

In order to be able to determine that all subprocesses A from one specific instance of the parent process are completed, let’s add the Process Instance Id of the parent process as input parameter of the subprocess A (and of the automation as well). In the main process, we get the following:

Jerome_5-1720467056402.png

And in the subprocess, let’s map that input to the Business Key:

Jerome_6-1720467056351.png

Jerome_7-1720467056369.png

By doing so, we make sure that all subprocesses created in a specific instance of the parent process will have the same business key. As a reminder, we created an Action project, where we could pass a value for the Business Key parameter. So we need to add it in the main business process, after the execution of the automation.

Jerome_8-1720467056403.png

At this point, we have the status of all the instances of subprocess A, triggered in Automation 1. Now we need to determine what to do next. We have 3 possibilities:

  1. All the subprocesses are COMPLETED, and we can proceed further in the execution of the main process
  2. There is at least one error in the execution of the subprocess, and we need to stop the execution of the main process
  3. There is still (at least) one instance RUNNING, and we need to wait until all the subprocesses are either completed or failed.

That’s where we use a Decision. For that, let’s create a DataType with an attribute ‘status’ as a string. It will be used as input parameter of the Decision:

Jerome_9-1720467056413.png

For the rule, we can create a Text rule:

Jerome_10-1720467056410.png

Where each aggregate function COUNT is configured like below:

1Jerome_11-1720467056352.png
2Jerome_12-1720467056393.png
3 Jerome_13-1720467056411.png

Now the Decision is set up, let’s map the input data:

Jerome_14-1720467056409.png

We create a list of objects, taking the status and the id from the response of the action artefact. And in the decision, we check the value of each ‘status’ attribute.

At this point, we do have a way to determine the global status of the main flow. Let’s just add some conditions in the process to manage the different steps (warn user of error, wait, or proceed further):

Jerome_15-1720467056399.png

Where the conditions are defined like below:

Jerome_16-1720467056389.pngand:

Jerome_17-1720467056403.png

 

Conclusion

This is a way to make sure the waiting action happen in the process, to avoid a long running automation. You can of course adapt this structure, by configuring the waiting time between each check of all subprocess’ status, or by modifying the Decision so it suits your needs.