Why agentic SAP platforms miss half your integrations

The new wave of agentic AI for SAP is impressive. Ask one to map your integration landscape and it will return a clean, navigable diagram in minutes — what gets called, what receives, what flows through. Beautiful work.

The diagram is wrong by approximately half.

Not because the platform is bad. Because the source it reads from — SAP’s configuration tables — only tells half the story. The other half lives in custom code, and most platforms never look there. When SAP’s July 2026 patch lands and starts technically blocking unauthorized ODP-RFC calls, the programs that fail are not the ones in your platform’s diagram. They are the ones in your Z-code that the platform never read.

This is a problem now, not for architectural-purity reasons. It is a problem because of three regulatory cuts hitting in 2026:

• SAP API Policy v4/2026 Section 1.2 — bifurcates Published vs Non-Published APIs and prohibits third-party access to internal ones. The burden of proof is on you, the customer, to demonstrate that every integration endpoint qualifies as Published.
• July 2026 ODP-RFC block (SAP Note 3255746) — technically terminates unauthorized ODP-RFC calls for SAP-to-non-SAP scenarios.
• Section 2.2.2 — prohibits agentic AI from sequencing SAP API calls outside SAP-endorsed pathways; mandates the Agent2Agent (A2A) protocol.

Each of these asks a question that cannot be answered from configuration tables alone. They ask what your code actually does — and the answer is hiding in your Z-programs.

What every platform sees

The configuration view of SAP integrations is well-trodden ground. Any platform with read access to your system can walk it:

A well-built platform reads these tables, joins them, normalizes them, and produces a graph. This is the inventory most “AI for SAP” tools return when you ask “show me my integrations.” It is accurate as far as it goes.

It goes about halfway.

What every platform misses

Here is a pattern from a real ABAP program in a real customer system. The names have been changed; the structure has not:

" In Z_FI_REPORT_DAILY
DATA: lv_dest TYPE rfcdest VALUE 'BCK_PROD_FI'.

CALL FUNCTION 'Z_GET_AR_BALANCES'
  DESTINATION lv_dest
  EXPORTING
    iv_company_code = '1000'
  TABLES
    et_balances = lt_balances.

This is an integration. It calls a function module on a remote system. It crosses the boundary. It carries data. If BCK_PROD_FI is a non-SAP system, this is a third-party integration under SAP API Policy. If the target function module is Non-Published, this integration is now prohibited.

But: this integration does not appear in SM59 if the destination is built at runtime, dispatched via a string variable, or fetched from a customer Z-table. And even when it does appear in SM59, the platform reading SM59 does not know which Z-program calls which destination — that linkage exists only in source code.

Here is another pattern:

" In Z_INV_SYNC_TO_BLOB
DATA(lo_http) = cl_http_client=>create_by_url(
  url = 'https://api.warehouse-x.com/v2/inventory'
).

lo_http->request->set_method( if_http_request=>co_request_method_post ).
lo_http->request->set_cdata( <fs_payload> ).
lo_http->send( ).

This is an integration. It posts SAP data to a third-party REST endpoint. It is invisible to SM59, WE20, SOAMANAGER, SICF — every configuration surface above. It exists only here, in a custom ABAP program, with a hardcoded URL.

And one more — the one that bites hardest:

" In Z_GL_EXTRACT_NIGHTLY
OPEN DATASET '/usr/share/sap/integration/gl_extract.csv'
  FOR OUTPUT IN TEXT MODE ENCODING DEFAULT.

LOOP AT lt_gl INTO ls_gl.
  TRANSFER ls_gl TO '/usr/share/sap/integration/gl_extract.csv'.
ENDLOOP.

CLOSE DATASET '/usr/share/sap/integration/gl_extract.csv'.

This is an integration. A flat file lands in a directory that some downstream pipeline picks up. It is one of the most common, least documented, hardest-to-discover integrations in any SAP estate older than five years. It does not exist in any configuration table. It exists only here.

The pattern is not exotic. Every SAP shop has dozens — sometimes hundreds — of these, accumulated over fifteen, twenty, thirty years of running mission-critical workloads on the same instance. They are real, they are in production, and they are not in your platform’s diagram.

Why this matters in 2026

Each of the regulatory cuts coming this year asks a question your configuration cannot answer.

v4/2026 Section 1.2 — Published vs Non-Published. You must prove that every third-party integration consumes a Published API. Half your integrations do not go through SM59 at all; they live in CALL FUNCTION ... DESTINATION and cl_http_client instances scattered across Z-programs. You cannot prove what you cannot see.

ODP-RFC July 2026 block. SAP will deploy a security patch that blocks unauthorized ODP-RFC calls. Most platforms will tell you what is registered in RSA1. They will not tell you which custom programs invoke ODP-RFC function modules from inside Z-code — and those calls will fail on day one. The list of Z-programs that need refactoring before July is a source-level question.

Section 2.2.2 — Agentic AI prohibition. SAP prohibits AI from sequencing SAP API calls outside endorsed pathways. The compliant path is the Agent2Agent (A2A) protocol. To know which of your existing integrations already sequence APIs in ways v4/2026 will challenge, you need to read the orchestration logic — and orchestration logic is code, not configuration.

Digital Access amplification. An AI agent creating documents at machine speed compounds Digital Access fees on every billable creation event. The question “which programs create documents that count as billable events?” is a source-level question — BAPI_*_CREATE, IDoc inbound handlers, custom document-creation flows — not a configuration query.

The agentic-AI-for-SAP wave promises to map, modernize, and operate your landscape. The wave is mostly real. But if the inventory feeding the AI is half-complete, every downstream decision — migration scoping, modernization roadmap, audit defense — inherits the gap.

What complete coverage looks like

Complete integration coverage requires fusing two sources of truth:

1. The configuration view — SM59, WE20, SOAMANAGER, SICF, FILE, SPTH — read, normalized, and joined into a graph.
2. The custom-code view — ABAP source parsed for every CALL FUNCTION, every cl_http_client=>create_*, every OPEN DATASET ... FOR OUTPUT, every TRANSFER — and every one of them tied to its caller, its target, and the business object flowing through.

When you fuse those two views into a single graph, every integration becomes a triple:

(sender) — [mechanism] — (receiver) — carrying a business object.

Now you can answer the regulatory questions:

• Which triples include a Non-Published API? — v4/2026 risk: High
• Which triples include ODP-RFC mechanisms? — July 2026: Critical
• Which triples are invoked from AI-sequenced code paths? — Section 2.2.2: Review
• Which triples create billable documents? — Digital Access: Modeled

You can defend the inventory under audit because every edge in the graph traces back to source-level evidence — a transaction code, an IDoc partner profile, or a specific line of ABAP. There is no ambiguity. There is no “we think most of them are covered.”

This is what an audit-defensible integration map actually looks like. Anything less is the half a platform sees.

A note on what to ask your AI-for-SAP vendor

If you are evaluating an agentic SAP platform, ask three questions:

1. “Do you parse ABAP source, or only read configuration tables?” If the answer is configuration-only, you will not see the integrations buried in Z-code.
2. “Which ABAP patterns do you detect?” A credible vendor names them. CALL FUNCTION ... DESTINATION. cl_http_client=>create_*. OPEN DATASET ... FOR OUTPUT. TRANSFER. If the answer is vague, the depth is vague.
3. “Can you show me a Z-program that invokes an ODP-RFC function module, traced from source to its SAP API Policy v4/2026 classification?” If a vendor cannot demonstrate this end-to-end, they cannot give you an audit-defensible v4/2026 inventory. They can give you a configuration-level summary — which is half of what you need.

Most vendors will not answer these questions cleanly. That tells you what you need to know.