SAP and Laravel Integration: Patterns That Work

How to integrate SAP with a Laravel application: RFC and BAPI calls, OData services, IDocs and staging tables, and when to use each.

Many companies run SAP for finance and core operations and build custom applications around it for sales, service or field work. The value of those applications depends on how well they exchange data with SAP. These are the integration patterns I have used between SAP and Laravel, and how I choose between them.

Pattern 1: RFC and BAPI calls

A BAPI is a standard, remotely callable SAP function, for example to create a sales order. From PHP you can call RFC-enabled functions with the sapnwrfc extension, which wraps the SAP NetWeaver RFC SDK. This is the most direct route and it uses SAP's own business logic and validation.

Use it for synchronous actions where the user needs SAP's answer now, such as a credit check or creating a document and getting its number back.

Pattern 2: OData and REST services

SAP Gateway exposes data as OData services over HTTP. For a web developer this feels familiar: a URL, JSON and standard HTTP verbs. Laravel's HTTP client is all you need on the PHP side. Custom ABAP REST handlers are also an option when OData does not fit the shape of the data.

$response = Http::withBasicAuth($user, $password)
    ->acceptJson()
    ->get($baseUrl.'/sap/opu/odata/sap/ZSALES_SRV/Customers', [
        '$filter' => "Region eq 'DHK'",
        '$top' => 100,
    ]);

Pattern 3: IDocs for asynchronous documents

IDocs are SAP's format for exchanging business documents asynchronously. They suit high-volume flows where a delay is acceptable, such as posting the day's invoices or receiving material master updates. SAP keeps a status for every IDoc, which makes failures visible and reprocessable.

Pattern 4: Staging tables and scheduled jobs

The simplest pattern is still common: one side writes rows to a staging table and a scheduled job on the other side reads them. It is easy to build and to inspect. Its weakness is delay and the temptation to skip validation, so keep a status and an error column on every row.

How I choose

• The user is waiting for SAP's answer: RFC/BAPI or OData.
• High volume and a delay is fine: IDoc or a staging table.
• The custom app is the only writer of that data: let SAP read it, do not copy it both ways.

Rules that apply to every pattern

• One system owns each piece of data. Everyone else reads.
• Log every exchange with the payload, the response and a reference, so it can be replayed.
• Make every write idempotent. Networks retry, and a retried sales order must not become two.
• Call SAP from a queued job where possible, so a slow SAP response does not freeze the web app.

For the queueing side, see Laravel queues for business automation. If you are deciding how much to build outside SAP in the first place, read custom ERP vs SAP.