SAP knowledge and SAP access are two different requests
A new application has to talk to SAP. If that is the sentence you have been handed, the instinct is to assume it means hiring an SAP developer. Before you go there, separate two things that get bundled together. One is SAP knowledge, meaning someone who understands how your particular landscape is configured. The other is SAP access, meaning credentials, an authorization role, an interface that is switched on, and permission to use it.
An integration that only reads data out of SAP and hands it to another system can often be built by developers who have never worked in SAP, provided the SAP side exposes a documented interface and somebody internally owns the access request. What you cannot substitute for is a person who can answer questions about your configuration.
So the first decision is not which technology to use. It is whether the work sits inside SAP or outside it. Anything that changes configuration, custom ABAP, or master data structure needs an SAP-side owner. Anything that consumes a published interface does not.
The phrase covers several different jobs, and they are not equally hard. Reading is easier than writing, because a read that fails leaves nothing behind. A write that fails halfway leaves a document somebody has to clean up. Keeping two systems in agreement over time is harder than either, because you have to settle in advance what happens when they hold different values for the same field, and that is a question for the business owner, not the developer.
It helps to name which of these you are actually being asked for:
- Reading reference or master data such as customers, vendors, materials or cost centers into another application.
- Pulling transactional data out on a schedule for reporting or analytics.
- Posting documents in: sales orders, purchase requisitions, goods movements, journal entries.
- Keeping two systems in agreement over time, which is a continuous obligation and not a one-off transfer.
- Triggering a process in SAP from an outside event, or the reverse.
Which interface should you ask for?
Ask your SAP administrator which interfaces are already active before you design anything, because activating a new one is its own approval process and it can sit on your critical path.
Ask which release and deployment model you are integrating with in the same conversation, because that decides what is even on the table. On ECC and on-premise S/4HANA, the options below are technically present, subject to authorization. On the cloud editions of S/4HANA, integration is expected to go through the APIs SAP releases for the purpose, and the lower-level routes are restricted or unavailable depending on the edition.
Direct reads against the underlying database, and automation driven against the SAP GUI, sometimes get proposed when access has not been granted. Treat either proposal as a signal that the access conversation has not happened yet. Both sit outside the interfaces SAP supports for the purpose, which leaves you exposed to changes underneath them at support pack or upgrade time, and on the cloud editions they may not be available to you at all.
The options worth asking about:
- OData services. HTTP and JSON, familiar to any web developer, exposed through SAP Gateway on on-premise systems and as released APIs on the cloud editions. A sensible default when the service you need already exists.
- SOAP web services. Verbose but generally well documented, and worth asking about in landscapes that predate the OData services.
- RFC and BAPI calls. Function-level access reached through a connector library or middleware. Closer to the internals, so it needs more SAP-side review.
- IDoc. Document-based asynchronous exchange, designed for documents such as orders, invoices and shipping notices.
- CDS views and extraction interfaces for analytics-shaped reads.
- Middleware or an integration platform between the two sides, which centralizes credentials, retries and mapping.
- Scheduled file exchange, which is unfashionable and can still be the right answer for a nightly batch.
The approvals that decide your timeline
The list below is not development work, and every item on it can hold development up. Start these requests before you start designing, because the answers change the design. If the security owner will not grant write authorizations to an external service, your integration becomes a read plus a human approval step, and it is better to learn that at the start than after the build.
- A technical user carrying only the authorizations the integration needs.
- An authorization role reviewed by whoever owns SAP security.
- A non-production client to build and test against, with data that resembles production closely enough to be useful.
- A network path and certificates between your application and the SAP system.
- A transport route, if anything has to be created or activated on the SAP side.
- A named SAP-side contact who is available to answer configuration questions while the build runs.
What an outside team can build, and where they will need help
A team without SAP background can own the non-SAP half completely: the calling service, authentication handling, field mapping, validation, retry and backoff, queuing, error surfaces, logging, and the interface your own staff will use. They can read interface documentation, build against a sandbox and write the tests.
They will need answers to questions only your landscape can settle. Which company code and plant apply. Whether a material number arrives padded with leading zeros on one interface and not another. Which custom fields were added to a standard structure. What the enhancement in that function module actually does. These are facts about your configuration, not gaps in skill, and a named SAP contact is what turns them into answers.
That contact is the dependency worth securing first. Building without SAP developers is a reasonable plan when the interface is documented, the access is granted, and someone on the SAP side can be asked. Take away that last condition and the same plan gets much harder to hold to, whatever interface you pick.
Designing for the next SAP change
Upgrades, support packages and release moves all change things underneath an integration. If you want yours to stay repairable when that happens, aim for failures that are loud, payloads you can inspect, and retries that are safe. In practice that means:
- Keep field mapping in configuration you can read, not scattered through code.
- Make writes idempotent, with a business key you can check before posting again.
- Log the request and the response for every posting, with sensitive fields masked.
- Route interface failures somewhere a person will actually see them.
- Version your side of the contract and retest against the sandbox after support packages and upgrades.
- Document what each field means in business terms, not only its technical name.
Sizing the work before you staff it
Not every exchange needs a built integration and a team to keep it running. If the data is needed once a day for a report, a scheduled extract into your reporting layer may be all that is required. If a packaged connector already exists for the system on the other side, evaluate it before writing your own. If the exchange is occasional and low volume, a controlled manual step with a proper audit trail can be the right answer until the volume argues otherwise.
The case for building is strongest when the exchange is frequent, when the error handling matters, and when the manual alternative carries its own risk of mistakes that nobody notices until later. Those same conditions decide how much engineering has to sit around the integration once it is live.
Related service: Our SAP platform page lists the SAP capabilities Software Mile works with, and is the place to start if you want to talk through the access question above.
Related service: SAP platform work.