Why is it not enough for the endpoint to work on the SAP side?
In the previous part, I showed how a RAP/OData V4 service is built on the SAP side. We went through the complete object chain that leads from the physical table, through the CDS view, behavior layer, projection, service definition, and service binding, to an endpoint that can be accessed by an external system.
However, this is only one half of the integration.
Just because a service works on the SAP side does not necessarily mean that it can also be used reliably, securely, and correctly from a business perspective by an external application. The other side is at least equally important: how the client behaves, what data it sends, how it handles authentication, how it works with the CSRF token, how it maintains the session, and what it does if the SAP-side write operation fails.
During the SAP integration of my own smart home management application, this was one of the most important lessons: publishing the endpoint is not the end of the project, but rather the point where the responsibility of the external application truly begins.
A working GET request does not yet mean complete integration
During development, it is easy to develop a false sense of security. If the metadata page of the OData service is accessible, the GET request works, and the data is visible in SAP Gateway Client, it may initially seem that the integration is complete. In reality, at this point we have only proven that the SAP-side service is accessible.
An external application is in a completely different situation. It does not need to send a one-time test request; instead, it must integrate SAP communication into a real application flow. For example, when a user, an installation, or a smart device is created, the application must decide when to send data to SAP, in what format to send it, and how to handle a situation where the SAP response is not successful.
This is why it is important to distinguish between two statements.
The first: the endpoint works on the SAP side.
The second: the external application integrates reliably with the SAP service.
The two are not the same.
The external client does more than just send HTTP requests
In the case of a RAP/OData service, the external client has more responsibilities than we might initially think.
- It must communicate with the SAP system using authentication
- For modifying operations, it must handle the CSRF token
- It must preserve the cookies associated with the session
- It must send exactly the payload expected by the SAP-side service
- In addition, it must also ensure that sensitive or application-specific data is not transferred unnecessarily to SAP
For this reason, it is not ideal to have raw HTTP calls scattered across different parts of the application. A cleaner solution is to place SAP communication in a dedicated integration layer. This way, the business logic of the application is not mixed with the details of exactly which header, token, cookie, or endpoint is required for the SAP call.
This layer does not only provide technical convenience. It also creates a system boundary.
CSRF token and session handling
One of the most important technical lessons was CSRF token and session/cookie handling.
A read-only GET request is generally simpler. A POST, PATCH, PUT, or DELETE request, however, modifies data, so due to SAP-side protection, a CSRF token may also be required.
The typical flow can be described simply as follows: the client first requests the token, SAP returns it in the response, and then the client sends the same token back with the modifying request. The critical part is that the cookies associated with the session must also be preserved. If the token is available but the session is lost, the modifying request may still fail.
Therefore, if a POST request works from SAP Gateway Client but not from a C# client, the problem is not necessarily on the SAP side. It may be that the external client is not carrying forward the same technical context.
Another common source of errors is the data format used when sending data.
An external client should not send what is most convenient for itself, but rather what the published OData service expects. This is particularly important when the C# application and SAP represent certain values differently.
For example, in a C# model, a true or false value may be natural. On the SAP side, however, a logical state may technically be represented as a character-based value, where the true value is “X” and the false value is an empty value. If the client sends this in the wrong format, the request may fail, or incorrect data may be created.
The same applies to identifiers, dates, decimal values, units of measurement, and mandatory fields.
This is why a mapping layer is necessary. The application’s internal model and the payload sent to SAP should not be treated as the same concept. The purpose of the mapping layer is to translate the application’s data into the contract expected by the SAP service.
Security boundaries: what do we not send?
The quality of an integration is not demonstrated only by what data it is capable of transferring. It is at least equally important to define what it does not transfer. In the project, a fundamental principle was that the SAP mirror must not become an uncontrolled data dump. Only data that has business relevance on the SAP side should be transferred.
- Plain-text passwords must not be sent to SAP
- Application-specific tokens must not be sent to SAP
- Session information must not be sent to SAP
- Unnecessary debug data must not be sent to SAP
The same applies to logging. During debugging, it may be tempting to log every header, payload, and response, but this creates a security risk. A good integration log helps identify the problem without containing secrets.
Feature flag and best-effort mirror
During the development phase, it was very helpful that the SAP mirror operated as a feature that could be switched on or off.If the switch is disabled, the application works only locally. If it is enabled, the important business data is also forwarded to SAP. This enables safer development because not every local test automatically creates data on the SAP side.
This also fits the architecture presented in the first part: SAP does not take over the entire operation of the application, but instead appears alongside it as a business integration point.
This is also where the concept of a best-effort mirror comes into play. If the local save operation succeeds but the SAP-side write temporarily fails, it is not always necessary to stop the entire application flow. Naturally, this depends on a business decision. If the SAP-side write is a critical requirement, the process must not continue. However, if the mirror is an additional business representation, it can be handled as a separate failure.
The key point is that an SAP error must not be swallowed. It must be made visible, logged, and a retry mechanism must be provided for it later.
Read-after-write: do not blindly assume that it succeeded
A successful HTTP response is a good sign, but during the development phase it is not always enough.
If the application creates something on the SAP side, it is worth verifying afterward through a read operation that the data has actually appeared. This is the read-after-write verification.
This is particularly useful because it does not only show that the request was technically executed, but also whether the SAP-side state matches what we expected.
This can reveal issues such as incorrect field mapping, an invalid boolean representation, a missing identifier, or an incorrect relationship between the user, installation, and device much earlier.
Lessons learned
The first part of the series focused on the architectural decision: why it makes sense to treat SAP not as a database, but as a system that publishes business services.
The second part presented the SAP-side object chain: how the RAP/OData V4 endpoint is built.
The most important lesson of the third part is that publishing the endpoint is only half of the integration. The other half is the responsibility of the external client.
An external application must know how to communicate securely, what data it may send, what data it must not send, how to handle tokens and sessions, how to separate local operation from the SAP mirror process, and how to prove that the data has actually appeared on the SAP side.
Together, these three parts lead to the same conclusion: modern SAP integration is not simply about transferring data, but about consciously designing system boundaries.
In this project, the RAP/OData-based approach proved to be a good decision because it allowed the custom-developed application to preserve its independent operation while connecting to an SAP system in a controlled and business-relevant way.
The next part will show how to test the endpoint from the SAP side, thereby verifying that the SAP-side service is working correctly.
