SAP integration patterns: how to choose the route out of the system

Almost every SAP integration question arrives in the same shape: a system outside SAP needs data that lives inside it, or needs to write something back. There is no single answer, because SAP exposes at least six routes, each built in a different decade for a different load profile. This article sets out those routes and the questions that decide between them: error handling, idempotence, field ownership and upgrades.

The questions that decide the SAP integration route

An interface specified as "the warehouse system needs delivery data from SAP" is not yet specified. Five properties decide the route, all answerable before a tool is chosen.

• Latency tolerance. Within seconds, within minutes, or once a day. This answer alone removes half the options.
• Volume and shape. Documents per hour or millions of rows, a steady trickle or a burst concentrated after a period close.
• Direction and transactional weight. A read is easy to retry. A posting that creates a financial document is not.
• Who owns the ABAP side. Whether your team can deploy ABAP, and whether a hosting agreement allows it, decides whether custom function modules are on the table at all.
• Upgrade exposure. How much of the interface is standard SAP surface and how much is code somebody wrote. That ratio is the maintenance cost for the next decade.

In DNA Solutions engagements, the landscapes we inventory typically run four of these routes at once. The defect is having no register of which interface uses which route and why.

IDoc: the asynchronous SAP integration route for documents

The Intermediate Document format predates most of what surrounds it and still moves the bulk of document traffic in large landscapes. An IDoc is a control record plus typed segments, routed through partner profiles, with a message type per business object: orders, invoices, deliveries, material movements.

Its strength is structural. Every IDoc is persisted individually, carries its own status, and can be inspected, corrected and reprocessed one unit at a time. When a finance team asks what happened to an invoice three weeks ago, the answer exists as a record rather than a log line.

The costs are equally concrete. Latency is governed by the partner profile: collected processing means minutes to hours, immediate processing consumes a work process per document. Custom segments on a standard message type are the most common source of upgrade work, because they are your code inside SAP's structure.

Choose IDoc when the unit of exchange is a business document and replay must be possible per document.

BAPI and RFC: synchronous calls into business logic

A BAPI is a remote-enabled function module exposing a business operation, called over RFC. The reason to use one is that it executes SAP's own validation and posting logic, so the resulting document is consistent with what a user would have created through a transaction. Writing into tables directly bypasses that logic and produces documents that look correct until a downstream process disagrees.

A BAPI posting requires an explicit commit. A caller that issues the BAPI and dies before committing has posted nothing, which is the safe failure. The dangerous case is the reverse: the commit succeeded and the response was lost in transit, so the caller retries and posts a second document. On a network that times out, that is not an edge case.

Synchronous coupling also transfers SAP's availability window to the caller. A long-running BAPI holds a dialog work process and is subject to the system runtime limit, so an interface that works with ten records in test can fail with a thousand.

Custom Z function modules are quick to write, which is why landscapes accumulate dozens of them, each an interface contract nobody registered and no upgrade guarantee covers.

OData and SAP Gateway: REST access for external clients

Gateway services expose SAP data as OData over HTTP, defined in current systems by annotated CDS views. The advantages are practical: standard HTTP semantics, a metadata document describing the service, filtering and paging in the query, token-based authentication, and compatibility with an existing API management layer.

The limits sit in the database underneath. An OData service over a wide view on a large table is a query, and whether a filter is pushed down or evaluated after retrieval depends on how that view is built. Paging discipline is not optional. OData suits interactive reads and app-facing traffic, and is a poor route for bulk extraction, where it competes with the users for the same resources.

SAP Integration Suite: mapping, adapters and credentials

Cloud Integration, successor to the on-premise Process Integration and Process Orchestration stack, gives four things that are tedious to rebuild: an adapter set covering IDoc, RFC, OData, SOAP, file transfer, JDBC and message brokers, a mapping tool, a monitored message log with retry and dead-letter handling, and one place for credentials and certificates. Reaching on-premise systems from the tenant runs through the Cloud Connector, its own infrastructure with its own availability.

Middleware is a cost question. It earns its licence when the mapping is non-trivial, when several consumers need the same payload in different shapes, or when one operational view across interfaces is worth paying for. It does not earn it for a single high-volume feed better replicated directly.

One failure mode afflicts every central integration layer: transformation rules and business logic accumulate inside the tenant, and replacing that layer later means re-implementing rules that exist nowhere else. We covered that pattern generically in our article on enterprise integration patterns. The SAP version is a mapping step that became the place where a business rule lives.

SAP's published schedule ends mainstream maintenance for the NetWeaver-based Business Suite 7 stack in 2027, with extended maintenance offered to 2030. Interfaces on that stack have a dated horizon.

Replication and change data capture for analytics

Analytics workloads do not want documents, they want tables, and none of the routes above is built for that. The options are landscape replication, operational data provisioning extractors, replication flows in the data products SAP now ships, and third-party change data capture reading the log of the underlying database. That last option carries a contractual caveat: reading SAP tables outside supported interfaces raises a support and licensing question, best answered before an architecture depends on it.

Three SAP-specific traps break naive replication.

• A deletion in SAP is usually a status change. A cancelled document often remains as a row with a changed status rather than disappearing. A pipeline watching for removed rows never sees the cancellation and keeps reporting revenue that no longer exists.
• Amount and quantity fields are not self-describing. A currency amount needs its currency key and the decimal handling that goes with it, a quantity needs its unit of measure. Replicating the numeric column alone produces figures wrong by a factor of a hundred in specific currencies.
• Cluster and pool structures do not map to a flat target. Some older tables store several logical fields in one physical column, and a generic extractor copies the container without the contents being readable.

The mechanics of streaming changes out of a source database, initial snapshots, schema evolution and delivery semantics, are covered in our article on change data capture. Applied to SAP, the added work is almost entirely semantic.

Event-driven SAP integration with a message broker

Current SAP systems can publish business events to a message broker. This is the right route when several consumers need to know that something changed without any of them being coupled to the producer.

One design property drives everything downstream: these events are notifications. They carry the key of the object and the nature of the change, rarely the full payload. Consumers that need detail call back, usually over OData, so a burst of events becomes a burst of reads against the same system. Sizing that callback path is part of adopting events, and the step most often skipped.

Error handling and replay in SAP integration

Each route fails differently, and those differences account for most of the ongoing operating effort.

• IDoc holds the failed document with a status, in a monitor, with a defined reprocessing transaction. Recovery is a known procedure.
• RFC and BAPI put recovery on the caller. Queued and transactional variants exist and change the guarantees, so choosing between them is a design decision, not a default.
• OData fails as an HTTP status. The consumer owns retry, backoff and whatever record it keeps of what it already sent.
• Middleware gives a dead-letter queue and a manual retry, provided someone is looking at it.
• Streams give offsets, so replay is straightforward, and the consumer has to expect the same message more than once.

Four questions belong in writing for every interface: where a failed message sits, who sees it sitting there, how long it can sit before the business notices, and what the replay procedure is. Where no owner is named for the error queue, the work falls to whoever happens to notice, which is usually the business rather than the integration team.

Idempotence and duplicate message handling

Every route above will deliver the same message twice at some point, through a timeout, a replay or a restart. The design goal is that a duplicate is harmless.

The tools are unglamorous and effective. Put a business key in the payload and check it before posting. Use the external reference field most SAP documents carry, and reject a second document bearing a reference already present. For OData writes, use an ETag with a conditional update. Partition streams by business key so two updates to the same object cannot be applied out of order, because ordering is the other half of the problem and easier to get wrong silently.

Master data mapping and field ownership

Field-level mapping consumes more of the schedule than the transport choice does. Material numbers stored with leading zeros through a conversion exit, units of measure that differ between the internal and the ISO code, currencies with a different number of decimals, and the business partner model replacing the older split between customer and vendor. Each of these is straightforward to handle once identified, and each is routinely found during integration testing rather than during design.

Underneath the mapping sits the question that outlives it: which system authors a given field, and which merely holds a copy. An interface that writes a field SAP also maintains creates a conflict no transformation logic resolves, and it surfaces as two systems disagreeing about a customer address when an invoice is issued. That is a governance decision, and it belongs in a master data management strategy that names an owner per domain before interfaces start writing.

Batch windows and upgrades in SAP integration projects

The first constraint is contention. Period close, planning runs and month-end reporting occupy the same work processes and database as your interfaces. A replication job scheduled without reference to the functional calendar finds out during the quarter that matters most.

The second is upgrade exposure. Standard interfaces come with SAP compatibility commitments. Custom function modules, IDoc extensions, user exits and direct table reads do not, so each becomes a regression test item at every upgrade and release change. Counting them is uncomfortable and useful, and it is usually the argument that justifies replacing the oldest interfaces during a legacy modernization programme rather than after it.

Talk through your SAP integration

DNA Solutions helps European enterprises scope SAP integration from an inventory rather than a target architecture: one line per interface, with its route, latency requirement, volume, error queue, named owner and upgrade exposure, a table that usually shows the two or three interfaces carrying most of the operational risk. From there our enterprise system integration engagements work per interface: choosing the route on the five properties above, deciding idempotence and replay before the first load test, and writing down who owns each field, with the systems in production throughout. Talk to us.