Response handling for asynchronous operations

Draft comment:
This topic only applies to CP4BA, and is located in the BAW repository. Last updated on 2025-03-13 12:15

Draft comment:
This page applies to the CP4BA KC and the source file resides in the BAW repository

In the OpenAPI definition of an asynchronous automation service operation, the REST operation does not provide the outputs, but responds with HTTP status code 202 to indicate that the operation request was accepted for processing.

To receive the outputs of the asynchronous operation once it is completed, you provide a callback URL with the operation request as specified in the OpenAPI definition. The implementation of the asynchronous operation uses this callback URL to provide the result. If you need to correlate the results to the request, you can add an ID to your callback URL. To know how to specify the callback URL parameter and the callback operation, refer to the OpenAPI definition.

The URL is then used to send the result of the operation. The callback URL you provided should just accept the outputs, and should not block the workflow runtime during callback. If the processing of outputs takes time, it should be deferred to an asynchronous handling on the client side.

In case the callback invocation results in an error, for example because of temporary network or server issues, the workflow runtime waits for a certain amount of seconds before invoking the callback again. The default waiting time is 60 seconds. You can configure that value by adding the callback-retry-interval configuration property to your 100Custom.xml file. To know how configuration properties are updated in the 100Custom.xml file, see Customizing Business Automation Workflow properties. The callback-retry-interval element is nested into the rest-services element. The following xml snippet shows the correct location:

<common>
    <rest-services>
        <callback-retry-interval>60</callback-retry-interval>
    </rest-services>
</common>

Besides the retry interval, you can also configure the number of retries, whose default value is 5, in the 100Custom.xml file by adding the callback-maximum-retries configuration property. This callback-maximum-retries element is nested into the rest-services element. The following xml snippet shows the correct location:

<common>
    <rest-services>
        <callback-maximum-retries>5</callback-maximum-retries>
    </rest-services>
</common>

If the workflow runtime cannot successfully invoke the callback URL, the result of the long-running workflow automation service operation cannot be delivered. An error message in the log file reports each failed attempt to deliver the result. In case the workflow runtime is shut down during the retry, the result of the long-running workflow automation service operation cannot be delivered either, and the error message is logged.