When SAP sits at the centre of a company's operations, every external channel — website, mobile app, field team — must see the same data and the same rules. I have built the integration layer for enterprise e-commerce projects running on SAP ABAP API endpoints, bringing product, stock, price and order flows into a single structure for web and mobile channels. I treat the API contract and the consuming application as one piece of work.
SAP integration keeps the data held in the ERP accurate and current on the website, mobile app, marketplaces and field systems. The goal is not merely to move data: an order should be entered once, stock and prices should stay consistent across channels, and accounting and customer records should reflect the same reality.
This is not solved by writing a copy script between two systems. Which side owns the data, in what order a record is created, what happens on an error, and how work is processed while the ERP is under maintenance all have to be designed up front.
How the service is exposed on the SAP side shapes the project. The right method depends on data volume, whether the flow must be synchronous or asynchronous, and the customer's SAP version:
If a custom ABAP service is required on the SAP side, I handle it as a separate scope item. In most projects the service is written by the customer's SAP team or implementation partner, while I deliver the API contract, the integration layer and the consuming side. Writing that boundary down at the start prevents delays later.
The rollout starts in a test environment with a realistic data set: product, price, stock and order scenarios, plus boundary and failure cases tested separately. Then comes a controlled pilot, a short parallel run and a rollback plan. After go-live the error queue and synchronisation lag are monitored for the first days; handover includes documentation and a monitoring dashboard.
Writing ABAP services, SAP-side configuration, authorisations and transport management are normally the responsibility of the customer's SAP team or implementation partner. My side covers the data model and API contract, the integration layer, web and mobile consumption, error handling and monitoring. A clear boundary speeds the project up; where needed, we settle the service contract together with the SAP team in the same meeting.
A one-way sync of a single entity takes about a week; a two-way scope covering orders, stock and accounts takes two to three weeks. If a new service must be exposed on the SAP side, the timeline also depends on that team's schedule.
I have worked on projects that consume API endpoints exposed in ABAP on the SAP side, and I design the contract. Extensive custom ABAP development is usually carried out with the customer's SAP team or implementation partner; I deliver the API contract, the integration layer and the client side.
ECC and S/4HANA can expose the same data in different ways: BAPI/RFC, OData or IDoc. The connection method is decided after reviewing the current version, the service inventory and the authorisation model.
The integration queues incoming changes, processes them in order when the connection returns, and retries. No orders or stock updates are lost, and the backlog is visible on a monitoring screen.
One owner is defined per data type. For example, product, price and stock are owned by SAP, while product descriptions and images may be managed on the web side. Writing the conflict rules up front removes guesswork during operations.
Yes. I first review the available API, database or export options, then plan the data mapping and integration layer. On a ready-made platform some points may need a plugin or custom development; those are stated separately in the proposal.
