SAP AI Integration: OData, BAPI/RFC and Read Replicas, Compared

SAP is not a closed system as far as integration is concerned — it publishes several interfaces specifically for external systems to read and write against it, and an AI layer is, from SAP's perspective, just another external system calling those interfaces. The three that cover the realistic set of integration needs are OData services, BAPI and RFC function calls, and read replicas for cases where direct access to production is restricted. What all three share is that the AI layer sits outside SAP entirely: SAP remains the system of record, nothing is migrated, and the integration survives an SAP version upgrade because it was never built against SAP's internals in the first place.

The path that does not belong on this list is screen-scraping the SAP GUI — automating against pixel positions and screen text rather than a published interface. It is sometimes reached for when no API appears to cover a need, but it produces an integration with no contract to rely on: the next transport, patch or cosmetic redesign can silently break it, and there is no SAP-side commitment that the screen will stay where it was.

SAP's OData services expose business objects — sales orders, material master records, financial documents — through a standard, REST-style interface with predictable query semantics: filtering, expansion of related entities, and both read and write operations depending on how the service is configured. For an AI layer, this is usually the first thing to check, because it requires no custom development on the SAP side if a service already exists for the object in question, and it behaves like any other REST API the rest of the integration is likely already calling.

Where OData earns its place as the default is maintainability: a service SAP publishes and versions is a contract the AI layer can rely on across upgrades, in a way a hand-built workaround cannot be.

Not every transactional action has an OData service in front of it. BAPIs (Business Application Programming Interfaces) and RFC (Remote Function Call) modules are SAP's older but still fully supported mechanism for invoking transactional logic directly — posting a goods movement, creating a purchase requisition, triggering a workflow step — and they remain the right tool where the specific action needed has no corresponding OData service, which is common for less standard or more industry-specific SAP configurations.

These are typically reached through a middleware layer or an SAP connector library rather than called raw, since BAPI/RFC calls use SAP's own remote-call protocol rather than plain HTTP. That middleware layer is exactly where an AI agent's tool-calling logic sits: the agent calls a well-defined function, and the function handles the SAP-specific plumbing underneath it.

Some SAP environments — particularly larger or more tightly governed ones — restrict direct API or RFC access to the production system for good reason: an AI workload with a query pattern the SAP team has not reviewed is a real risk to a system the rest of the business depends on. In those cases, a read replica, refreshed on a defined interval, gives the AI layer a data source it can query freely without touching production load or requiring sign-off on every new query pattern.

The tradeoff is real and worth being explicit about with stakeholders: a replica is reporting-grade, not transactional. It fits retrieval, natural-language querying and dashboard use cases well — the same pattern behind the white paper on chatting with data over Odoo ERP — but it is the wrong foundation for a workflow that needs to write back to SAP in real time. Where both read and write are needed, a replica typically pairs with OData or BAPI/RFC for the write path rather than replacing it.

The throughline across all three supported paths is that none of them requires custom ABAP running inside SAP itself. That matters beyond elegance: custom ABAP is code your SAP partner has to test against every future upgrade, patch and transport, and it is code that sits inside the system your ERP vendor is contractually responsible for supporting. An integration built entirely against OData, BAPI/RFC and read replicas is, from SAP's point of view, indistinguishable from any other external consumer of its published interfaces — which is precisely why it keeps working when SAP itself changes underneath it.

This is the same argument that runs through AI system integration more broadly: connect to what an enterprise already runs rather than building inside it or replacing it, so the integration is additive rather than a dependency the core system now has to carry.