Comparison of EDI and APIs – Handling of Content Errors

When data is exchanged between business partners, errors also occur with regards to content. It is sufficient that a target system simply does not interpret plausible data correctly. With EDI as batch-driven file exchange, error handling typically takes place on the target system, whereas with coupling using APIs, the calling system only receives an error message back and is responsible for error handling itself.

A closer look at Content errors

ERP systems exchange data both with other internal systems and with external business partners. Data is usually transferred using the classic transfer method in an asynchronous way and using a file format such as IDocs. Due to the asynchronous nature of the transfer method, content errors must be handled on the target system. For example, SAP users can correct content errors in the inbound SAP IDoc themselves and then process the IDocs manually.

By changing the transfer method between ERP and B2B-System from being file-based such as SAP IDoc to synchronous API, a direct reaction in real time becomes possible. However, this means that the error messages are just bounced back:

Instead of simply accepting an IDoc with incorrect content and then handling the errors itself, the ERP system rejects the incorrect content directly via the API and returns an error message to the calling B2B/EDI system where the error handling needs to be performed.

The following table compares the classic transfer method for a SAP S/4HANA system using SAP IDoc and the coupling using the APIs of the SAP API Business Hub:

Example Comparison between SAP IDocs and APIs of the SAP API Business Hub

API Call Procedure

The target system (service provider) grants the calling system (service consumer) access to the available APIs. The service consumer then requests the service from the service provider using the corresponding API and receives a synchronous error message from the service provider in the event of a content error. The service request is now closed for the service provider and the service consumer (the calling system) has to take care of further error handling.

The main difference in the conversion from SAP IDocs to APIs – or in other words from asynchronous calls to synchronous service requests – is that in the latter case the error handling is carried out by the service consumer – and thus outside the SAP ERP system in the example shown. This means that all tools, interception routines and user interfaces for error handling are located – depending on the API access path – either directly on the calling system or on the intermediate integration platform or the B2B/EDI system.

For calling systems, the change of an existing asynchronous call using a file format to synchronous service requests by API therefore means a considerable effort. In addition to the purely technical change, organizational aspects must also be taken into account. For example, the lines of business involved in the calling organization must be involved and error handling needs to be discussed with them.

For B2B/EDI solutions, which further down the road will connect SAP S/4HANA systems via the APIs of the SAP API Business Hub instead of SAP IDocs as before, this is not only a technical change but also an organizational one. For the lines of business involved, at least the corresponding tool changes during manual error handling.

With SEEBURGER BIS as the platform for API integration and API management, error handling on API paths can be unified while keeping the complexity of dynamic API environments under control – saving time and money. Of course, SEEBURGER supports all API interfaces for SAP S/4HANA (and SAP in the ‘classic version’).