Why was it a good decision to connect a self-developed application to SAP?
When developing a self-developed application, sooner or later the question arises: how long should the system remain independent, and when is it worth connecting an enterprise backend system? This is especially interesting when the application is not only a technical demo, but also models some kind of business process.
My project started as a smart home management application. The goal was to create a system in which users, installations and later smart devices can be managed on a unified interface. The application is also functional locally: it has its own data storage, its own validations and its own operational logic. This is important, because an external application should not depend entirely on whether another system is currently available.
At the same time, after a certain point, the main question was no longer whether the application was able to save data. Rather, it was how these data could also become meaningful in an enterprise environment. This is where SAP came into the picture.
SAP is not simply a database
A bad integration decision starts when we look at SAP only as a large central database. This is a convenient thought, but in an enterprise environment it is a dangerous oversimplification.
The value of SAP does not simply lie in the fact that it stores data. It lies much more in the fact that it provides business objects, rules, authorizations, controlled processes and unified data models. If an external application only “sends something into SAP”, but does not think through the system boundaries, the integration can quickly become difficult to understand.
Therefore, in the project, the goal was not to move the entire application into SAP. The application continues to remain its own operational unit. SAP’s role became to receive and represent the important business data in a controlled way.
Local operation and SAP mirror
The essence of the chosen architectural pattern is: local operational store + SAP-side business mirror. This means that the application manages the data required for its daily operation in its own database. Examples include creating a user, selecting an installation, or managing states within the application.
In parallel with this, certain data that are important from a business perspective also appear on the SAP side. For example, when a user is created or registers a smart device, the application is able to forward this to the SAP system through an OData service, and any business-relevant change is also updated in SAP.
This is not full data mirroring, and it is not blind data copying either. The essence of the mirror strategy is that only what has business meaning there should be transferred to SAP.
This was a good decision from several perspectives:
- the application remains testable and usable even without SAP;
- the SAP integration can be enabled gradually;
- errors can be isolated more easily;
- sensitive or application-specific data are not transferred unnecessarily;
- a business-relevant data footprint is still created in SAP.
The latter is especially important. In an enterprise system, the goal is not for every technical detail to appear everywhere. The goal is for the right data to be present in the right system, with the right responsibility.
Why RAP/OData?
For the SAP-side integration, I chose a RAP/OData-based approach. The external application does not directly modify SAP tables, but accesses a published service, which is much healthier from an architectural perspective. Behind the service, separate layers on the SAP side handle the data model, the business behavior and the published API.
This approach is beneficial because the external application does not need to know the internal technical details of SAP. It is enough for it to know which endpoint it can call, what data it needs to send, and what response it can expect.
In other words: the integration is not a table-level connection, but an interface between two systems.
Why was this a good decision from the application’s perspective?
The SAP integration was not only a technical extension, but also an architectural step forward. A locally functioning smart home application can be useful on its own. But if the same application is able to communicate with an enterprise system in a controlled way, then it gets much closer to a real enterprise environment.
The project is therefore not only about “there is an app that saves data”. Rather, it is about the application being able to distinguish between its own operational data and business data that are relevant from an enterprise perspective.
This distinction is very important as a developer. In an enterprise integration, the strongest solution is not the one that sends every piece of data everywhere. Rather, it is the one that precisely defines:
- which system is responsible for what;
- what data can be transferred;
- what operation is allowed;
- what happens in case of an error;
- how the process remains secure and testable.
That is why connecting the project to SAP was a good decision: it did not replace the application’s own operation, but added an enterprise integration dimension to it.
Outlook
The current approach is not only applicable to users. The same pattern can later be extended to installations, devices, or even automation events.
This is what gives the solution its real strength: it is not a one-time integration trick, but a reusable pattern. If the system boundaries are clear, then connecting new business objects no longer starts from zero.
Lesson learned
Modern SAP integration is not simple data transfer. It is much more conscious system boundary design. An external application does not have to move all of its operation into SAP in order to be SAP-integrated. In many cases, it is a stronger solution if the application remains locally stable, while the important business data also appear on the SAP side.
In this project, the RAP/OData-based integration made exactly this possible: SAP did not appear as a backend database, but as a system publishing business services.
In the next part of the series, I will show how this is built on the SAP side: how an SAP table becomes an OData V4 endpoint accessible by an external system through a RAP object chain.
