
SAP Build Process Automation has introduced the "Wait for an API Call" step, that pauses a process instance and waits for some system – any system – to call a specific API to resume the process instance.
NOTE: The step was scheduled to be introduced this week and next to all the SAP BTP landscapes, but there are no guarantees, and the release could be delayed.
I believe the idea behind this is a scenario where, from your process, you call an external system that must execute some task before the rest of the process resumes.
For example:
P.S.: This is the idea behind our new SAP Build CodeJam.
Simply click the + sign to add a step, and go to Controls and Events area.
Then select the Wait for an API Call step.
You then give the trigger a name.
That's all you need to do.
If you want the API call that resumes the process to include additional data, you can define "input" parameters. The UI is the same as when specifying Process Inputs.
When calling the API for resuming the process instance, you must provide an API key with the proper permissions.
Go to the Control Tower, enter your environment, and select API Keys.
Click Add API Key.
When calling the API, you must send the API key under a header called irpa-api-key.
Once you deploy the process to an environment, a separate trigger is created in that environment for that step -- in the same way an API trigger is created to trigger a new process instance.
Go into your environment, then to the Triggers tab. You'll see a trigger for your wait step.
Select the trigger and click View.
This will show you API details that are slightly different than the API details for the standard process API trigger.
The URL:
The payloads are also different.
That API can only be used if the specified process instance is actually waiting for that specific API call.
Remember to send your API key under the irpa-api-key header.
You will need to send the process instance ID to the 3rd-party system that will resume the process instance, so they can include it in the request body of the API.
One way to do this is to create a custom variable to hold the instance ID.
Add Script Task to get the instance ID from the info object and put it in the custom variable.
A kind of quirky behavior occurs when you delete a "Wait" trigger and then redeploy – AND you have process instances still running from the previous version of your process.
👉If you delete the "Wait" trigger, what happens to those process instances?
Well, no worries.
The old processes will continue to run and the old "Wait" trigger can still be used. It will continue to appear in the Control Tower.
When the last process that uses that trigger is completed, that "Wait" trigger will disappear from the Control Tower.
I have not re-created all the potential errors, but so far have figured out when the following status codes are returned when calling the "Wait" API.
This is just based on a few minutes testing, so it may not be 100% accurate. And there may be cases when the API returns other status codes. If you experience any, please let us all know.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
9 | |
7 | |
7 | |
7 | |
6 | |
6 | |
6 | |
6 | |
5 | |
5 |