SAP

Connectivity Before Code: What the Landscape Has to Allow

Most SAP integration work stalls before the first line of code, and it stalls on access rather than design. The recurring version is an interface coded against a service that turns out never to have been activated in that system, or pointed at a client whose data does not match what the business described. Connectivity testing against the actual target system, early and before the build is scheduled, is what separates a two-day setup problem from one that consumes the first sprint.

• A network route from wherever the code runs to the SAP application server. Ports follow the instance number: the dispatcher on 32NN, the gateway on 33NN, the message server on 36NN, and the ICM on 80NN for HTTP and 443NN for HTTPS. A firewall rule normally has to be requested for each one actually used.
• The service switched on. For OData that means the ICF node under /sap/opu/odata activated in SICF and the service registered on the Gateway side. A 403 on a URL that otherwise looks correct is more often an inactive node than a rejected user.
• The right client. One host serves several clients, the data differs between them, and an interface pointed at the wrong client returns plausible results that are simply from somewhere else.
• Authorizations at the object the interface actually touches, not just the ability to log on. S_RFC governs which function groups an RFC caller may invoke, S_SERVICE which services may be started, and the underlying data still carries its own authorization objects on top of that.
• A technical user rather than a person's dialog account, created as a system or communications user type so it cannot be used for interactive logon and does not stop working when that person changes roles or leaves.
• SAProuter, where it fronts the landscape, listens on 3299 and needs an entry in its route permission table for the calling address. A connection that hangs rather than being refused usually points at the route table, not the port.
• A decision on transport security: SNC for RFC connections or TLS for HTTP. Either one requires certificate or key material installed on both ends before anything connects, which is a lead-time item rather than a configuration switch.

What SAP Does With a Call That Runs Too Long

SAP does not fail a slow call cleanly, which is why a large share of integration incidents get blamed on the network. Requests are handled by work processes, and work processes are a finite pool shared with the people using SAP interactively. When a call exceeds what that pool allows, the caller sees a dropped connection or a truncated response while the useful evidence stays inside SAP.

• The dialog work process runtime limit, rdisp/max_wp_run_time, terminates a dialog step that runs past it. The default in many systems is 600 seconds. Inside SAP this produces a TIME_OUT short dump; outside it produces a connection that simply ends.
• The ICM has its own timeout, set per port through PROCTIMEOUT on the icm/server_port_n parameter, and it is frequently shorter than the work process limit.
• Reverse proxies, load balancers and API gateways in front of SAP each add a timeout, and the shortest one in the chain governs. This is why an identical call can succeed from inside the landscape and fail from outside it.
• Enqueue locks. A write held open by a long transaction blocks other writers on the same object, and the second caller either waits or fails depending on how it was written.
• Work process exhaustion. Parallel interface calls compete with interactive users for the same pool, so an integration that behaves well in isolation can degrade the system when it is scheduled during business hours.
• The diagnostic that separates these: ST22 for short dumps, SM21 for the system log, SM50 or SM66 for what the work processes were doing, and /IWFND/ERROR_LOG for Gateway-side OData failures. If none of them show anything at the timestamp in question, the call never reached SAP and the fault is in front of it.

Detecting What Changed Since the Last Run

The expensive part of most SAP interfaces is not the first load. It is knowing what changed since the last one, and deletes are the case designs miss most often, because a row that is gone produces nothing to notice.

Two defects recur in delta designs. The first is using a last-changed timestamp as a watermark with a strict greater-than comparison, which silently drops records written in the same second as the previous high-water mark; the remedy is a deliberate overlap on every run, combined with writes keyed on the document number so that reprocessing the overlap is harmless. The second is treating a document as unchanged because its header timestamp did not move, when the change was actually on an item or a linked table carrying its own timestamp. Beyond those, the mechanisms available for detecting change differ mainly in what they cost the source system and in what they cannot see at all.

• Change documents, in CDHDR and CDPOS, record field-level before and after values for objects configured to log them. Coverage is per object and per field, so the first question is whether the field you care about is logged at all.
• Change pointers, written to BDCP2 and activated per message type, are the mechanism behind standard master data distribution by IDoc. They are dependable for what they are configured for and blind to everything else.
• Header date and time fields are the cheapest option and the weakest. They carry no deletes, their granularity is often one second, and the time zone they are recorded in is worth establishing before the first run rather than after.
• Event-driven notification, where a posting raises an output or a message the interface consumes, gives near-immediate deltas and makes the interface dependent on configuration that someone else can change without telling you.
• Database log based replication captures everything, deletes included, at the cost of binding the interface to the physical table layout rather than to a released interface.

Volume, Paging, and Where Per-Record Calls Belong

Sizing an interface means settling how much comes back in one response, how many responses make up one run, and what happens when a run is interrupted halfway. The defaults rarely suit: SAP Gateway applies a server-side page size regardless of what the client asks for, and a client that ignores paging will either truncate silently or ask for everything and time out.

Per-record calls are the correct shape for interactive lookups, where somebody is waiting on a single document and the only latency that matters is the one in front of them. They become the failure mode when the same pattern is reused for bulk reads and writes, because the fixed cost of each call, authentication, session setup and work process allocation, is then paid thousands of times over for work that a single extract would have done once.

• $top and $skip page an OData collection, but deep paging gets more expensive the further in it goes, since the server generally still has to produce and discard the skipped rows. A filter on a keyed field beats a large $skip.
• $select limits which fields come back. On a wide table that is the single largest reduction available, and specifying it costs nothing.
• Counting is a separate operation. $inlinecount in OData v2, $count in v4, forces a full count of the matching set, so requesting it on every page turns one expensive operation into many.
• $batch reduces HTTP round trips by grouping requests into one request body, but the server still processes them in order. It saves network time, not SAP work. The change set inside a batch is the part that is atomic.
• Retry safety has to be designed in rather than added later: an external reference generated by the caller and written onto the document, or a query on that reference before any retry, is what makes a retry safe to attempt.
• Large extracts belong in a background work process rather than a dialog one, which is also what puts them outside the dialog runtime limit described above.

What to Settle Before the Design Is Fixed

One question belongs before the technical design rather than after it. SAP's digital access model prices documents created in SAP by systems outside it, counted by document type rather than by named user, which means an integration that posts documents can carry a licensing consequence unrelated to how well it is built. What counts and what it costs is a question for your SAP account team, and the answer occasionally changes which system should own the posting.

The other question is whether the interface needs to be built at all. An existing route turns up more often than it gets looked for, and these are the places to look.

• What SAP already publishes as a standard interface for the object in question. Released OData services, standard IDoc message types and released BAPIs carry a compatibility commitment across releases that a custom function module written against tables does not.
• What connector the other system's vendor already ships. CRM, ecommerce and warehouse products frequently have an SAP adapter that somebody else has already maintained through several SAP releases.
• What integration platform the organization is already licensed for. Middleware that is paid for, monitored and staffed is worth more than a new direct link written for a single requirement.
• An existing copy: if a warehouse or reporting store already loads the tables involved on a schedule, a new reporting requirement can often read from there and never open a connection to SAP.
• Whether a person is already doing this by hand, and how often. Automating a monthly export replaces ten minutes of work with an interface that needs monitoring, error handling and an owner for as long as it exists.