Context
Almost every SAP landscape runs the same routine: the business department needs data in a system, and development writes a script for it. The next data object brings the next script, every change brings a ticket. The load itself is rarely hard. What costs time is that it is built from scratch every time.
That is exactly the pattern we wanted out of the way: one screen where source and target are chosen, with the load running behind it without any code of its own.
Why the SAP BTP
The target systems are SAP systems, and the users work in the SAP world. A platform outside it would have had to build login, certificates and network access for every connection. On the BTP all of that is already there:
- Destinations. Every connection to a source or target system is registered once as a destination. The platform manages authentication methods, tokens and certificates, and the code only knows the name of the connection. For most systems, authentication was settled before a single line was written.
- Cloud Connector. On-premise systems behind the firewall become reachable through the Cloud Connector, without the customer opening any ports.
- Identity Service. Login and user management come from the SAP Cloud Identity Service, often already connected to the customer’s company login.
- Subaccounts. Every customer gets their own subaccount. Tenant separation is therefore a property of the platform, not a concept in our code.
How we solved it
At the core sits a generic mapping instead of one script per entity. The application reads the structure of the target, places the fields of the source next to it, and the business department assigns them. What used to be development work is configuration now.
We started with flat files into SAP BW, S/4HANA and AWS. The second step was the connection via REST and OData, so data can come straight out of a system and does not have to be exported as a file first. Since then, source and target can be combined freely: file into BW, S/4HANA into AWS, a REST service into S/4HANA, all through the same mapping. A connected system is not tied to one role: the same S/4HANA can be the source in one run and the target in the next.
The business department starts a load by hand right away or schedules it, for example nightly or at the turn of the month. Both go through the same run, only the trigger differs.
| Component | Technology | Decision |
|---|---|---|
| Frontend | SAPUI5 | One screen for source, target and mapping, not a wizard with ten steps |
| Backend | SAP CAP | Mapping, schedule, runs and log in one place, independent of source and target |
| Connectivity | Destinations, REST, OData | Sources are registered as destinations, never hard-wired in the code |
The whole thing is delivered as SaaS: a customer subscribes and gets their subaccount, their login and their destinations. That takes days, not weeks, because none of it is built per project.
Learnings
- The mapping is the product. Everything else, upload, log, permissions, is standard. The time belongs in the assignment logic and its error messages.
- The platform carries more than you believe at the start. Login, connections and tenant separation were not built by us, they were configured. That kept our own code small.
- Errors have to be readable for the business department. As soon as non-developers load data, a log is not enough. The app has to say which row did not arrive and why.