Integrating with SAP
SAP systems sit at the centre of many large and mid-sized businesses. Modern initiatives — online stores, customer and supplier portals, mobile apps for field staff, analytics platforms — all need SAP data, and they need it without compromising SAP’s stability or security.
We build the bridge between SAP and modern applications using SAP’s supported interfaces, so new experiences can move fast while the core system remains clean.
Problems we solve
- Web shop orders entered manually into SAP
- Field staff unable to access SAP data on mobile
- Customer and supplier portals that need live SAP information
- Analytics teams struggling to extract SAP data
- Integrations that broke during SAP upgrades
What’s included
API-based integration
OData, REST and BAPI/RFC interfaces with secure access.
Middleware
SAP Integration Suite, MuleSoft, Boomi or Azure Integration Services.
eCommerce & portals
Orders, prices, availability and invoices exposed to web apps.
Mobile apps
Field and warehouse apps reading and writing SAP data.
Data extraction
SAP data into warehouses and BI tools.
SAP Business One
Service Layer and DI API integrations for SMB setups.
Clean core, flexible edges
SAP’s own guidance for S/4HANA encourages a “clean core”: keeping customisations out of the central system and building extensions and integrations on the side using published APIs. This makes upgrades safer and faster. Our integrations follow the same principle — new functionality lives in separate applications that communicate with SAP through stable interfaces.
Security and performance
- Technical users with least-privilege authorisations
- Encrypted connections and secure credential storage
- Batching and caching to avoid loading SAP during peaks
- Monitoring and alerting on every interface
- Documentation for your SAP basis and security teams
SAP integration options
| Option | When used |
|---|---|
| OData and REST APIs | Modern S/4HANA integrations |
| BAPIs and RFCs | Older ECC systems and specific functions |
| IDocs | Document exchange such as orders and invoices |
| SAP Integration Suite | Central integration on SAP BTP |
| Third-party iPaaS | Organisations standardised on another platform |
Working with SAP teams
SAP landscapes are usually governed by an internal team or partner. We agree interfaces, authorisation and transport processes with them, test in the quality system before production and document every interface. This keeps integrations aligned with SAP change management.
Checklist before starting
- SAP version and modules confirmed (ECC or S/4HANA)
- Available APIs and authorisations identified
- Data owners and master data rules agreed
- Test system access arranged
- Error handling and monitoring responsibilities defined
Common integration scenarios
- E-commerce orders into SAP sales orders, with stock and pricing back to the store
- CRM accounts and opportunities synchronised with SAP customers and quotes
- Warehouse and logistics systems exchanging deliveries and goods movements
- Supplier portals feeding purchase orders and invoices
- Data extracted to a warehouse or lake for analytics and AI
- Custom web and mobile apps using SAP data through secure APIs
For older ECC systems facing the move to S/4HANA, we design integrations that can be migrated with minimal change, often by placing an API layer between SAP and other systems so consumers are not tied to SAP internals.
Questions to answer before you start
SAP integrations need agreement across several teams:
- Which system initiates each data exchange?
- What are the expected volumes and response times?
- Which middleware, if any, is already standard in the organisation?
- How are changes transported and approved?
ECC or S/4HANA: what changes for integration
Many organisations are partway through a move from SAP ECC to S/4HANA, and integration work has to respect that journey. An interface built today against ECC tables or custom function modules may need rework when the system is converted, while an interface built against released APIs and business events is far more likely to survive the transition. Where we can, we design integrations around the target state rather than the current one.
| Topic | SAP ECC | SAP S/4HANA |
|---|---|---|
| Preferred interfaces | IDocs, BAPIs, RFCs, custom ABAP services | Released OData and SOAP APIs, business events, plus IDocs where still supported |
| Extension approach | Modifications and custom code common | Clean core: side-by-side extensions on SAP BTP or outside SAP |
| Data model | Many tables per business object | Simplified data model (for example, the Universal Journal in finance) |
| Discovery of APIs | Mostly tribal knowledge and documentation | SAP Business Accelerator Hub lists published APIs |
General guidance; the right interface depends on your release, licences and SAP partner’s recommendations.
If a conversion is planned within a few years, we flag every interface that relies on ECC-specific objects and agree whether to build it twice or wait for the new release.
Middleware choices and when each fits
SAP integrations rarely connect point to point. A middleware layer handles mapping, retries, monitoring and security, and keeps SAP insulated from changes in the systems around it.
| Option | Good fit when | Watch out for |
|---|---|---|
| SAP Integration Suite (BTP) | SAP is the centre of your landscape and you want prebuilt SAP content | Licensing model and the skills to operate it |
| Azure Integration Services / AWS services | Your wider platform runs on that cloud | Building SAP-specific mappings yourself |
| iPaaS (MuleSoft, Boomi and similar) | Many non-SAP systems already run through it | Per-connection or per-message costs at volume |
| Custom integration service | Few, well-defined flows with specific logic | Owning monitoring, retries and alerting yourself |
We recommend the option that matches your existing platform and team rather than introducing yet another tool.
A typical SAP integration project
-
Interface inventory1–2 weeks
List every flow, its direction, volume, frequency, owner and the SAP objects involved.
-
Design with the SAP team1–3 weeks
Agree interfaces, field mappings, error handling and authorisations with your SAP functional and Basis teams or partner.
-
Build and unit test3–8 weeks
Implement mappings and services in the chosen middleware, with automated tests against sample payloads.
-
Integrated testing2–4 weeks
Run end-to-end scenarios in SAP quality systems, including failures, duplicates and large volumes.
-
Cutover and hypercare1–3 weeks
Go live with monitoring dashboards, alerting and a runbook for support teams.
Durations are typical ranges for a handful of interfaces; large programmes run several such cycles in parallel.
Error handling that support teams can live with
The most common complaint about SAP interfaces is not that they fail, but that nobody notices until a customer or the finance team does. We design failure handling as carefully as the happy path:
- Every message carries a correlation ID traceable from source system to SAP document number
- Business errors (for example, a blocked customer) are separated from technical errors (timeouts)
- Failed messages are parked for review and can be corrected and replayed without developer help
- Idempotent processing so a resent message never creates a duplicate order or posting
- Alerts go to the people who can fix the problem, with enough context to act
- Daily reconciliation reports compare counts and totals between systems
Measuring a successful integration
- Manual re-keying removed — staff no longer copy data between screens
- Latency — data arrives within the time the business agreed, whether seconds or overnight
- Error rate and time to resolve — fewer failures, and failures resolved by business users without tickets
- Reconciliation — totals match between SAP and connected systems
- Change effort — adding a field or a new partner takes days, not months
SAP integration often sits alongside ERP integration, enterprise integration and API development.
Related services
Part of ERP development. See also ERP integration and enterprise integration.
This page is part of ERP Development Services — see the full overview for related services, approach and pricing.