When it comes to SAP S/4HANA integrations, customers are increasingly adopting web service API-based integration options instead of traditional iDocs. This is a natural progression, as more and more systems in the integration landscape are either cloud-native or migrating to the cloud. Traditional on-premise systems are being replaced by cloud-based solutions due to their scalability and flexibility.

In greenfield SAP S/4HANA implementations, it’s common to see the backend SAP system using either SOAP or OData APIs for integrations instead of iDocs. However, there is a significant difference in how messages are monitored and reprocessed in iDoc-based interfaces compared to those using SOAP and OData APIs.

The key differences between iDocs and SOAP/OData APIs in SAP S/4HANA lie in their communication patterns and technical behavior.

Key Differences Between iDocs and OData/SOAP APIs in SAP S4 HANA

Asynchronous iDocs vs Synchronous API

iDocs are asynchronous in nature, while OData APIs are synchronous. SOAP services can operate in either asynchronous or synchronous mode, depending on how they are configured.

Another important distinction is that iDocs are stateful, whereas web APIs like OData and SOAP are stateless. In simpler terms, OData APIs require an external request to be triggered, and there is always a request-response interaction. On the other hand, iDocs do not require an external trigger, SAP can push data out asynchronously without waiting for a request.

Interface Message Persistence in SAP S4 HANA

A major difference is in message persistence. iDoc messages are stored in the SAP system in database tables such as EDIDC, EDID4 and other EDIC tables, regardless of whether they result in success or failure. This means both successful and failed iDocs are persisted and can be monitored and analyzed at any time, as long as they are not archived. SAP customers can configure how long iDocs remain in the system, providing flexibility in message retention.

In contrast, for OData calls, only error messages are logged. Successful API calls are not persisted in the standard SAP system. For example, if a sales order is created in SAP S/4HANA using an OData API, only failed calls will appear in the error logs; successful messages are not visible in standard monitoring tools. To the best of my knowledge, there is no standard option to enable monitoring of successful OData calls in SAP S/4HANA.

However, for SOAP API calls, both successful and error messages are available in SAP S4 HANA, and you can monitor the messages using the transaction SRT_MONI.

Monitoring of OData/SOAP APIs vs iDocs in SAP S4 HANA

Due to the way messages are persisted, monitoring iDocs is straightforward. You can use transactions such as WE02 and WE05 to monitor iDocs easily. In many organizations, iDoc messages are retained for several months before older records are archived and removed from the system. As a result, monitoring iDoc-based interfaces in SAP is generally not a concern.

However, when it comes to OData APIs, the situation is different. Unfortunately, you can only see messages that end in error. If an OData call fails, it is logged and can be viewed in standard transactions /IWFND/ERROR_LOG, /IWFND/TRACES.

But what if you want to check successful OData API calls? At the moment, this is not supported by standard SAP S4 HANA tools. There is no built-in way to trace successful OData API calls using standard monitoring transactions.

Only the erroneous OData calls are logged in SAP S4 HANA. You can see the error code, HTTP response code, time stamp, error description and other details related to the message in this transaction.

Select an OData message to drill down to further detail.

If you need to monitor successful API calls, one option is to leverage the Application Interface Framework (AIF). By building an AIF interface on top of the OData service, you can add logging and monitoring capabilities for both successful and failed calls but this requires custom development.

SOAP APIs you have the option of monitoring message directly in SAP S4 HANA using transaction SRT_MONI.

Here you can find the information such as processing statuses, interface or the SOAP API name, messages ID, and the timestamp of the SOAP messages processed. Notice, unlike the OData messages, both successful and error messages are available in SRT_MONI.

Automatic Message Reprocessing Limitations for OData API Based Interfaces

There are scenarios where an interface message fails due to an issue within the SAP S/4HANA system. For example, missing master data, incomplete configuration, document locked by another user at the time of message processing (locking issue), or other application-level errors relevant to SAP. In such cases, we are accustomed to fixing the root cause in SAP and then reprocessing the message directly within the SAP S4 HANA system.

However, due to the stateless and synchronous nature of OData services, it is not possible to simply reprocess failed OData messages automatically within SAP itself.

In iDoc-based scenarios, it is common to have scheduled background jobs that regularly scan for failed iDocs and automatically reprocess them. This kind of built-in, automated recovery mechanism is a standard feature of iDoc handling.

Unfortunately, this option does not exist for OData services. There is no native way to automatically reprocess failed OData messages via a background job in SAP periodically. Instead, you have to rely on other methods, which we will discuss later in the article.

However, for SOAP API based messages, you can reprocess messages using a batch job directly in SAP S4 HANA.

Workarounds for Monitoring Limitations in SAP S/4HANA

There are a few ways to overcome the message monitoring limitations in SAP S/4HANA, especially when it comes to tracing successful messages for OData and SOAP APIs.

Leverage SAP Application Interface Framework (AIF)

The first option is to leverage SAP Application Interface Framework (AIF) in S/4HANA. You can build an AIF interface for each API-based integration to log and monitor both successful and failed messages. However, this approach requires custom development. That said, it’s a good option when business users need visibility into interface processing from within SAP.

Monitoring capabilities of SAP Integration Suite

Another approach is to use the monitoring capabilities of SAP Integration Suite. In most SAP S/4HANA landscapes, a middleware is involved for managing integrations, and SAP Integration Suite (SAP IS) is often the preferred platform. You can use the message monitoring features of SAP Integration Suite (or any other middleware in use) to trace and log both successful and failed messages. You can also choose to store message payloads for high-priority interfaces.

Access the SAP Integration Suite message monitor and you can find an overview of all the interfaces.

Here you can find the request and reply payloads of the OData call.

Leverage SAP Cloud ALM (CALM)

Additionally, you can also leverage SAP Cloud ALM (CALM) for end-to-end interface monitoring, regardless of the technology used. CALM provides centralized monitoring and traceability across different systems. However, it’s important to note that message payloads are not logged in CALM. Only certain metadata and trace parameters are available for analysis.

How to Handle Message Reprocessing Requirements for OData and SOAP

When it comes to overcoming message reprocessing challenges in SAP S/4HANA, let’s look at the available options.

SOAP API Message Reprocessing

The easiest scenario to handle is with SOAP APIs. For both inbound and outbound interfaces; that is, messages coming into SAP as well as those going out, and for both asynchronous and synchronous SOAP APIs, you can reprocess messages directly in SAP using a standard program.

Even if the error originates in SAP Integration Suite, the SOAP error log still captures the message details in SAP S/4HANA. These logs are accessible via transaction SRT_MONI, which allows you to view and reprocess failed messages.

Because of this logging, it is also possible to automate the reprocessing of failed SOAP messages periodically within SAP via a batch job.

How to Reproceses OData APIs for Inbound Interfaces?

Let’s consider a scenario where the interface is inbound, and we are using an OData API to post data into SAP S/4HANA. In this case, messages are sent from an externally connected system, which acts as the message sender.

Since OData follows a request-reply pattern, the sender system must use the appropriate method, such as POST or PATCH to call the OData service and send the request along with the payload. SAP processes the request and returns a response, which includes the status of the message (success or failure), error codes in case of failure, and, if successful, the business document number (e.g., sales order number).

However, if there is an error on the SAP side, for example, due to missing configuration or master data, the failure is still communicated in the response. Because OData is stateless and synchronous, SAP S4 HANA independently reprocessing the erroneous message does not make sense, and reprocessing must be triggered from the sender system.

Alternatively, you can also implement a queue-based approach in SAP Integration Suite using JMS queues, allowing you to reprocess failed messages directly from the Integration Suite once the issue in SAP has been resolved.

Even though the root cause of the failure lies in SAP, there is no standard way to reprocess the message within SAP once the issue is resolved. The only option is to resend the request from the sender system or SAP Integration Suite.

Manually Reprocess Erronous OData Messages in SAP S4 HANA

However, there is an option to manually reprocess OData calls on the SAP S/4HANA side. You can use the “Replay” option in transaction IWFND/ERROR_LOG.

Note: The payload of the request can be edited, meaning the user can modify the data without any restrictions. This approach is not suitable for a production landscape, as users would be able to post data without proper control mechanisms.

Additionally, the response from the OData call will not reach SAP Integration Suite or the connected system, which can disrupt end-to-end integration scenarios.

Moreover, the view itself is quite technical, and you need to manually define the JSON message structure. This option may be appropriate for support users, system administrators, or specially authorized users for exceptional cases.

I hope this gave you a clear overview of how monitoring and automatic error reprocessing for SAP OData and SOAP APIs differ from iDoc-based interfaces. Due to the nature of API-based integrations, it’s important to design your interfaces thoughtfully, keeping these limitations and capabilities in mind.

If you’d like to learn SAP integration step by step, join my SAP Integration Suite course for Beginners, and start building real-world integration skills today.