I am the developer between your SAP team and the web, cloud and AI world: I build the OData services and CDS views myself and connect whatever needs to work with them – an application, a portal or a language model. As a freelancer, remote across Europe and on-site in North Rhine-Westphalia.
In many companies the important data sits in SAP, while the applications people use every day stand next to it: a customer portal, an internal business application, a mobile app, a reporting service. In between you find spreadsheet exports, nightly file drops and manual re-keying. That is exactly the gap I close – with interfaces that are documented, monitored and maintainable.
My focus is the integration side. I read and write SAP data through OData and REST services, model the CDS views for them myself, and know ABAP well enough to read existing coding, implement smaller enhancements and talk to your SAP developers as an equal. On top of that comes the side I have worked on for more than ten years: Java, .NET, TypeScript, PHP, Python, microservices, cloud and deployment.
For a while now the most common question has been: can our AI reach the SAP data as well? That is exactly where my two focus areas meet. Connecting a language model to SAP takes both – someone who builds the view on the data inside the SAP system, and someone who knows how an LLM handles it without bypassing authorisations or letting data flow out uncontrolled.
With compliu, my own platform for compliance and IT security in SAP landscapes, I work on precisely these topics every day: reading SAP events, processing them and moving them into modern systems. What I learn there about data models, interfaces and operations flows straight into client projects – you can read more at compliu.de.
Four building blocks around interfaces and data flows – individually or as one end-to-end connection.
The use case I am asked about most at the moment: an assistant that answers questions about orders, master data or documents from SAP. I build the CDS view or OData service as a clean foundation for it – rather than dumping raw tables into a vector database – and connect the model through tool calls or MCP. What matters is that the asking user's authorisations still apply, so nobody sees data through AI that they could not see in SAP.
Connecting your applications to SAP through OData services or an API in front of them: sensible filtering and paging, authentication sorted out, error and retry logic defined. The result is an interface that stays predictable under load and during maintenance windows.
Views that expose exactly what your application needs, instead of pushing raw tables over the wire. I model CDS views together with the SAP team, define how they are exposed as a service and check which fields should leave the system at all, both functionally and in data protection terms.
I read ABAP coding, work my way into existing programs and enhancements, and implement manageable changes myself – object-oriented, using the ABAP Development Tools in Eclipse. For larger ABAP development your SAP team stays in the lead; I deliver interfaces and support.
Between SAP and the target system there is usually more than one call: mapping, validation, buffering, restart after failures. I build that layer as its own service – with message queues, idempotency, monitoring and a log that shows which record got stuck where.
Situations where an integration developer alongside the SAP team makes the difference.
People ask in plain language about orders, deliveries or master data instead of clicking through transactions. The answer comes from a defined view on the SAP system, cites its source and shows only what the person asking is allowed to see anyway.
Customers, partners or staff need to see and edit master data, orders or documents without getting SAP access. The application is built as a modern web interface while SAP stays the system of record – connected through one lean, documented interface.
Field service, technicians or warehouse staff work on the move and need SAP data even where the network is weak. I build the app including an offline buffer and the synchronisation that writes changes back reliably and traceably.
Reports, dashboards or handovers to a data warehouse that are produced by hand today become an automated data flow: a CDS view as the source, a defined schedule, a log for every run and an alert when one does not happen.
A shop, CRM, time tracking or industry system needs to exchange data with SAP. I clarify the business rules, build the mapping and make sure duplicate or delayed messages cannot do damage.
SAP projects rarely fail on technology. They fail on unclear responsibilities between the SAP team and application development. Hence this sequence.
Together with your business users and your SAP team we define which objects and fields are actually needed, in which direction they flow and how current they must be. That decides both effort and architecture.
We check what services already exist and add only what is missing – a CDS view, an OData service or an API in front of it. Authorisations, technical users and a test system are settled here, not shortly before go-live.
Implementing the integration layer with tests against the SAP test system, error handling, restart points and monitoring. After that you can see whether a run happened – instead of hearing about it from the business.
Deployment through CI/CD, a documented interface specification and a handover to your team. I stay available for further development and maintenance if you want that.
What is used depends on your SAP release, the services already in place and the target system.
Describe briefly which data should move out of or into SAP and which system depends on it. I will come back with an honest assessment of how to get there.