ABAP is the language of the business logic that runs inside SAP. My area is the edge where that logic is exposed to the outside world: data mapping, error handling and testing across ABAP API endpoints, RFC/BAPI and OData services. I have built the integration layer for enterprise e-commerce projects running on SAP ABAP API endpoints, treating the contract and the consuming side as one piece of work. Where custom ABAP development is required, I separate the scope with the SAP team and make the contract explicit.
ABAP is the language in which SAP's business rules, checks and data access are written. An external website or mobile app does not read SAP data directly; it talks through a function, service or IDoc exposed on the SAP side. Those endpoints are usually written in ABAP: function modules and BAPIs, class-based services, OData services or IDoc outputs.
My side is to make the contract of those endpoints explicit and to consume them correctly: which field maps to which type, what a given error means, what happens if a record is sent twice, and how work accumulates while the system is under maintenance. Rather than writing all of the ABAP code, I own the end-to-end correctness of the integration.
The part of integration that produces the most defects is field mapping. A date, amount, unit or code table behaves differently in SAP than in the external system. The contract defines these explicitly:
Once the contract is written, the SAP team and the integration developer work from the same document; instead of "it worked on my side" there is a measurable acceptance criterion.
The most dangerous situation in SAP integration is not noticing that an operation failed. Every call therefore has its return messages parsed, with error, warning and success handled separately. Records are sent with a unique key, a failing record waits in a queue and is retried, and permanent failures land in an operator-visible queue instead of disappearing silently. Every transfer is logged, so the question "what was sent, and when" can be answered later.
Testing is not only the happy path. These scenarios are exercised separately: an invalid code value, a missing required field, the same record sent twice, an authorisation error on the SAP side, and a dropped connection. The test environment uses a realistic data set. Go-live follows a controlled pilot, a short parallel run and a rollback plan; the error queue and lag are monitored in the first days.
Extensive custom ABAP development is usually done by the customer's SAP team or implementation partner. I deliver the API contract, the integration layer, web and mobile consumption, error handling and tests; the projects I have delivered included API endpoints exposed in ABAP on the SAP side. Where needed, I settle the service definition together with the SAP team and write down the test calls and acceptance criteria.
On the integration side I consume ABAP services and design their contracts. Extensive custom ABAP development is usually carried out with the customer's SAP team or implementation partner; the projects I delivered included API endpoints exposed in ABAP on the SAP side.
OData/REST is usually more practical for web and mobile channels; RFC/BAPI comes forward when direct access to existing business functions is needed. The decision depends on data volume, synchronous requirements, authorisation and the SAP version.
Messages in the return table are parsed, with error and warning states separated from success. The record is kept in a queue, retried, and a permanent failure becomes visible to an operator. A call that looks successful while carrying an error is one of the most common traps.
The IDoc status is tracked after dispatch and failed records are reprocessed. The integration side logs the source record key for every IDoc, so lost or duplicate transfers can be detected.
Not advisable. Validating service behaviour without a test client or sandbox means experimenting on live data. If no test environment exists, it should be set up first, or work should run on a safe copy.
Yes. The existing endpoint is assessed from its documentation, sample requests and responses, and a test call; missing fields or error behaviour are clarified. If necessary, the service contract is updated with the SAP team.
