Dealer portals, field sales apps, customer self-service screens… most applications that sit in front of the ERP talk to SAP through SAP OData services. Building that integration with a PHP framework like Laravel is not hard; building it so it runs trouble-free in production for years is.
What is OData and why use it?
OData is a REST-based protocol that defines standard rules for querying: filtering, sorting, field selection and paging. SAP Gateway and S/4HANA expose business objects (sales order, customer, material) as OData services. That means data can be read and written without touching the database directly, with SAP's business rules and authorisation checks in force.
Reading: ask for little
- Field selection: request only the fields you need; extra fields make responses bigger and slower.
- Filtering: filter on the server, not in the app; pulling thousands of records to filter in PHP is slow and risky.
- Paging: fetch large lists in pages.
- Caching: cache data that rarely changes (material lists, payment terms) for short periods.
Writing: security and consistency
For change requests, SAP OData services usually require fetching a CSRF token first and then sending the POST, PATCH or DELETE in the same session. Wrapping this flow in a single service class with Laravel's HTTP client shields the rest of the application from SAP details.
- Authentication: prefer OAuth or certificate-based methods over a technical user where possible; credentials only in server environment variables.
- Authorisation: the integration user's SAP authorisations are limited to the objects needed; segregation of duties applies to integration users too.
- Validation: data is validated in the app before it goes to SAP, and SAP error messages are passed to the user in plain language.
Robustness: queues, retries, idempotency
- Queues: operations such as order creation run as queued jobs, not inside the user request. If SAP is briefly unavailable, the user does not wait.
- Retries: transient errors are retried a few times with increasing back-off; permanent errors (such as validation) are not retried.
- Idempotency: sending the same order twice must not create two orders in SAP. A unique reference generated by the app (for example an external order number) is stored in SAP and checked before sending.
- Logging: every request and response is logged with personal data masked; it is the most valuable information for troubleshooting.
Performance
In ERP-integrated apps, slowness usually comes from network round trips. Using batch requests, keeping parallel calls limited and rendering parts of the screen without waiting for SAP noticeably improve the user experience. For general web performance principles, see the web performance article.
Testing
A mock layer for SAP services makes development and automated tests independent of SAP test system availability. But final validation must always happen in a real SAP test system, with the real document and accounting flow.
A good integration is invisible: users only notice their work got faster. Combining ERP knowledge with software expertise is the key to that invisibility.
