Overview
When using Bizagi's SAP connector, you may configure a customized treatment for the different errors that may occur during invocation of SAP BAPIs.
Errors that may occur when invoking SAP BAPIs can be classified into 2 categories:
1. System exceptions.
These happen when Bizagi will not initially reach SAP, namely when there's any connectivity issue.
For example, when no connection is available to SAP at a given moment or when access is not granted through the configured SAP user and password.
2. BAPI exceptions.
BAPI exceptions are those explicitly programmed ABAP exceptions in each SAP BAPI.
These mainly represent each of the different functional errors a BAPI may come across before actually executing.
An example is the "table without data" exception thrown by SAP.
In the below image, take the RFC_READ_TABLE function module as an example in SAP, which already predefines 6 different BAPI exceptions:
Configuring error handling when integrating Bizagi with SAP is simply done as the last step when setting an BAPI invocation through the SAP connector:
For more information about the SAP connector's features to integrate Bizagi with SAP, refer to SAP connector.
Error handling
By default, Bizagi uses a Throw Exception action, which will throw back the exception if it encounters either a System exception or a BAPI exception.
This allows an administrator to review the logged exception and retry the operation (e.g, when setting invocation of BAPIs in asynchronous tasks).
This works in the same fashion as the error handling configuration done for any asynchronous tasks, be it an integration with SAP or an invocation of an external web service. For more information about the error handling usual options, refer to Interfaces error handling.
However, for each of the BAPI exceptions defined in that particular function module in SAP, you may the possibility to take a different action and set a different treatment to handle that error in your process.
The possible actions are:
•Throw Exception: The default setting which will not allow the process workflow to complete this task until the operation is successful.
For each BAPI exception set to throw the exception, you may customize the Message shown for it.
•Take a different workflow path: The customizable setting that gives your process the flexibility of taking different paths according to the type of exception.
For this setting, you will need to have previously considered different paths in your modeled process, by attaching events to that task:
Since you may have more than one attached event for your exceptional scenarios, you may then configure different rerouted actions.
Notice that in this example, we defined 2 attached error events: one which is redirected to the Review request and status task (the transition being labeled as Functional error), and another one which is redirected to the Escalate Sub-Process (the transition being labeled as SAP system exception).
When configuring the integration to take a different workflow path, you will be presented with the name of the available transitions the task may consider:
Important
Whenever you invoke a SAP BAPI, note that the BAPI may not successfully execute and still do not throw an exception.
There are scenarios in which a BAPI will not execute as expected and return a message in its output structures as if it were a successful invocation.
In the example below, note that when invoking the BAPI_FLBOOKING_CREATEFROMDATA BAPI to book a flight, we may get a response having either a "FLIGHT table is locked", or a "FLIGHT is not available, as it's date is set in the past" message in the RETURN structure.
Though the book wasn't really booked, in this scenario you will need to handle such type of responses as there were no BAPI exceptions actually thrown by SAP.
Last Updated 2/19/2024 10:58:25 AM