AdvancedSAP ECC 6.0Integration / Private AI

How to add AI to SAP ECC 6.0 on-prem without moving data to a cloud

Question
how to add AI to SAP ECC 6.0 on-prem

Also searched as

  • SAP ECC AI integration without cloud
  • run a local LLM on SAP ECC data
  • SAP ECC private AI assistant architecture
  • SAP ECC 6.0 chatbot on-premise RFC BAPI

Short answer

You add AI to SAP ECC 6.0 by leaving ECC where it is and building a read-only layer beside it: RFC-enabled function modules and BAPIs for live lookups, an SLT or database replica for bulk analytics, a retrieval index over documents, and an open-weight model served on your own GPUs. SAP's authorization objects are enforced in the tool layer so users only see what they could see in the GUI. Writes go back only through BAPIs after human approval.

Applies to: SAP ECC 6.0 (any enhancement package) on Oracle, SQL Server, DB2, MaxDB, ASE or HANA (Suite on HANA). Gateway-based steps need SAP NetWeaver Gateway (embedded from NetWeaver 7.40, add-on before that).

Build the private AI layer on SAP ECC 6.0

  1. 1Inventory the interfaces you already have: NetWeaver release and enhancement package, whether SAP Gateway is active (transaction /IWFND/MAINT_SERVICE), whether SLT is licensed and installed, and which RFC destinations and technical users exist (SM59, SU01).
  2. 2Choose the read path per question type. Live single-document lookups go through BAPIs or a small custom RFC-enabled function module. Bulk and analytical questions go to a replica fed by SLT or by your existing database replication, limited to the tables you approve.
  3. 3Create a dedicated technical user for the AI layer with only S_RFC for the function groups it needs plus display-level authorizations. Prefer per-user identity (SNC with SSO, or trusted RFC) for any live call so the SAP check runs as the real person.
  4. 4Load the approved tables into a reporting store (PostgreSQL or a column store on your own servers) with a column allow-list. Leave out HR infotypes, bank details and anything your data classification marks restricted.
  5. 5Build the retrieval index over attachments and documents: Generic Object Services attachments, ArchiveLink or content-server documents, DMS document info records (table DRAW), plus SOPs and drawings from file shares. Store the owning object key (plant, company code, purchasing org) with every chunk.
  6. 6Run a tool server (an MCP server or a plain internal API) that exposes named, parameterised read actions such as get_po_status or open_po_lines. The model never receives a database connection or free-form SQL against production.
  7. 7Serve an open-weight model with vLLM or Ollama on local GPUs, log every question, tool call and returned row to an append-only audit store, and start with a pilot group before opening it to all users.

The supported ways to read ECC data

ECC sits on an ABAP application server with the data in a relational database, but the supported path to that data is not a direct database login. SAP's licence terms and its own notes restrict direct reads of application tables from third-party tools, so confirm your contract before you point a reporting tool at production tables. The sanctioned options are RFC (including BAPIs and custom RFC-enabled function modules), IDocs and ALE for event-style outbound data, OData services through SAP Gateway, and replication through SLT.

For lookups, BAPIs return business objects with their authorization checks applied inside the ABAP code. BAPI_PO_GETDETAIL1 returns a purchase order header and items, and similar read BAPIs exist for sales orders, materials and vendors. Check the exact parameters in SE37 on your release before coding against them. For bulk data, the core MM tables are EKKO and EKPO (purchasing header and item), EKET (schedule lines), EKBE (history), MARA, MARC and MARD for materials, and VBAK and VBAP for sales. Note that the client field MANDT must be in every query.

RFC_READ_TABLE is tempting but a poor foundation: it is not a released interface, it truncates wide rows, and it can expose any table the calling user is allowed to read through S_TABU_DIS. Write a small purpose-built function module per question family instead, and have its authority checks live in ABAP next to the data.

-- Replica query: open PO schedule lines (illustrative, run on the SLT target, not on production)
SELECT h.EBELN, h.LIFNR, p.EBELP, p.MATNR, p.WERKS,
       s.EINDT AS delivery_date, (s.MENGE - s.WEMNG) AS open_qty
FROM   EKKO h
JOIN   EKPO p ON p.MANDT = h.MANDT AND p.EBELN = h.EBELN
JOIN   EKET s ON s.MANDT = p.MANDT AND s.EBELN = p.EBELN AND s.EBELP = p.EBELP
WHERE  h.MANDT = '100' AND p.LOEKZ = ' ' AND s.MENGE > s.WEMNG
ORDER  BY s.EINDT;
# Live read through a BAPI with the pyrfc library (verify parameter names in SE37)
from pyrfc import Connection
conn = Connection(ashost='ecc-app01', sysnr='00', client='100', user='ZAI_READ', passwd=get_secret('zai'))
res = conn.call('BAPI_PO_GETDETAIL1', PURCHASEORDER='4500001234')
items = [(i['PO_ITEM'], i['MATERIAL'], i['QUANTITY']) for i in res['POITEM']]

Reference architecture: everything stays on your network

The layer has six parts. A reporting copy of the approved tables, fed by SLT or log-based change data capture, so analytical questions never touch the production database. A retrieval index (vectors plus keyword search) over documents, with the owning plant or company code stored as filterable metadata. A tool server exposing approved read actions. An open-weight model served by vLLM or Ollama on your GPUs. An identity layer that maps the person asking to their SAP user. And an append-only audit log.

A typical request goes: user asks 'which open POs for plant 1000 are late?'; the orchestrator picks the open_po_lines tool; the tool queries the replica with the plant filter derived from the user's authorizations; the rows come back to the model, which writes the answer and cites PO and item numbers. Nothing leaves the data centre. For an air-gapped site, load model weights, container images and Python wheels through a one-way transfer, and run the replica and index inside the same enclave.

Keep the model out of the SQL business. It chooses among named tools with typed parameters; the tool code builds the query. That makes every answer reproducible and lets security review a finite list of actions rather than an open-ended text-to-SQL surface.

ECC (ABAP app + DB)
  |-- SLT / CDC --> reporting store (approved tables only)
  |-- RFC/BAPI (per-user, SNC) --> tool server (MCP / internal API)
Documents (GOS, ArchiveLink, DMS, shares) --> parser --> retrieval index (+ plant/company metadata)
User --> chat UI --> orchestrator --> vLLM (local GPUs) --> tool server --> answer + cited keys
Every step --> audit log (who, what question, which tool, which rows)

Permissions: the assistant must not out-see the user

ECC authorizations are role based (PFCG) and checked in ABAP with AUTHORITY-CHECK against authorization objects. For purchasing, M_BEST_WRK limits by plant, M_BEST_EKG by purchasing group and M_BEST_BSA by document type. Finance uses F_BKPF_BUK for company code, and sales uses V_VBAK_VKO for sales organization. S_TABU_DIS and S_TABU_NAM govern generic table display, and S_RFC governs which function groups an RFC caller may run.

There are two workable patterns. Per-user: the tool server calls BAPIs as the real user through SNC or trusted RFC, so SAP itself does the check. This is the most faithful but slower and needs identity plumbing. Mirrored: you export the effective authorization values per user (SUIM reports, or a function module that returns them) into the AI layer and apply them as mandatory filters on replica queries and on retrieval metadata. This is faster but must be refreshed whenever roles change, so schedule it and treat staleness as a defect.

Write-back is the narrow case. The assistant may draft a purchase requisition and place it in an approval queue; on approval a service user calls a BAPI such as BAPI_PR_CREATE followed by BAPI_TRANSACTION_COMMIT. See the BAPI commit page below for why the commit matters. Never give the model a direct update path to tables.

Sizing, rollout and honest limits

As ranges: a pilot for 50 to 150 named users with a 7B to 32B parameter open-weight model typically fits one to two data-centre GPUs; a plant-wide rollout for several hundred users with a 70B-class model is usually two to four GPUs with a spare. The retrieval index for 100,000 documents is commonly tens of gigabytes. Use the sizing calculator linked below with your own question volumes rather than these ranges.

Roll out in three phases. Phase one is read-only questions over the replica and documents with a pilot group. Phase two adds drafted outputs (emails to vendors, requisition drafts, exception summaries) that a human sends. Phase three adds approved actions through BAPIs with an approval step and an audit trail. Do not skip to phase three.

Limits to state plainly. ECC mainstream maintenance is scheduled to end in 2027 (SAP offers extended maintenance at a premium into 2030), so this layer is often built to survive an S/4HANA move: keep tool contracts stable and swap the data access underneath. Custom Z tables and heavy user exits need mapping by someone who knows your system. Cluster and pool tables are awkward to replicate and read directly. Finance line items in BSEG are a cluster table in ECC, so use the secondary index tables or standard reports for them. And if your question is simply 'show me a standard report faster', a well-built ALV variant or SAP's own search may be enough.

Try it here, free

SAP ECC AI Assistant Sizing and Value Calculator

Open full tool

Estimate peak concurrent requests, GPUs, tokens per day, index size, hours saved and payback for a private AI assistant on SAP ECC 6.0.

Common pitfalls

  • !Pointing a text-to-SQL tool at production with a broad database user, which bypasses ABAP authority checks and may breach your SAP licence terms.
  • !Using RFC_READ_TABLE as the integration, then discovering wide tables truncate and the technical user can read tables it should not.
  • !Forgetting MANDT in joins, which silently mixes clients on shared databases.
  • !Indexing documents without the owning plant or company code, so a retrieval hit can leak a document the user could not open in SAP.
  • !Letting authorization mirrors go stale after a role change; the assistant then answers from yesterday's permissions.
  • !Building the layer so tightly around ECC table names that the S/4HANA move forces a rewrite.

How an ERP-grounded AI assistant handles this

ERPray connects to ECC through the read paths above, shows the query or BAPI call behind every answer, and respects the SAP user's roles. For a team that wants a private pilot, the quickest scope is a handful of read tools (open POs, stock by plant, delivery status) over a replica plus the SOP and drawing library, served from a local model. Write-back stays behind approval and BAPIs.

See ERPray

Frequently asked questions

Can an LLM read SAP ECC tables directly?

Technically yes, but it is the wrong design. Direct table reads skip ABAP authorization checks and can conflict with SAP licence terms on third-party database access. Use BAPIs, custom RFC function modules, Gateway services, or a replica fed by SLT, and expose them as named tools the model can call.

Do I need SAP BTP or Joule to do this?

No. The pattern here uses RFC, BAPIs, SLT and open-weight models on your hardware. Joule and BTP are SAP's cloud-oriented route and their availability for ECC differs by release, so check SAP's current statements. Many on-prem plants prefer the self-hosted route for data residency reasons.

How do I stop the assistant showing data a user cannot see in SAP?

Either call BAPIs as the real user through SNC or trusted RFC so SAP checks authorization, or mirror each user's effective authorization values (plant, company code, sales organization) and apply them as mandatory filters on queries and retrieval. Refresh the mirror on a schedule and log every request.

Is this still worth building if we will move to S/4HANA in two years?

Often yes, if you keep the tool contracts and prompts stable and treat the data access layer as replaceable. The retrieval index, model serving, identity and audit parts carry over unchanged. Expect to rewrite the table-level queries and BAPIs against S/4HANA APIs and CDS views.

Related

How-to

How to Use BAPI_TRANSACTION_COMMIT Correctly

SAP's BAPI programming model separates business logic from the database commit on purpose, so a caller must explicitly call BAPI_TRANSACTION_COMMIT after a successful BAPI - usually with WAIT = 'X' - or the created object never actually persists. Skipping this step, or forgetting WAIT, is the most common reason a BAPI 'runs fine' but nothing gets saved.

How-to

SAP SE16N vs SQVI: Table Browser vs Ad Hoc Query

SE16N is a single-table browser: fast filtering, formatted display, and export from one table at a time, with an optional edit function for authorized users. SQVI (Quick Viewer) builds ad hoc queries that join multiple tables without writing ABAP, and can be saved as a reusable report. Use SE16N for a quick look at one table; use SQVI when you need data joined across two or more tables.

Error fix

SAP IDoc Status 51: Application Document Not Posted

Status 51 tells you the IDoc reached the application layer and failed to post, but the status text itself is not the error - the real cause sits in the status record's long text or the linked application log. Fix the underlying data or configuration, then reprocess the IDoc through BD87 rather than editing the status.

CIO briefing

SAP ECC 2027: what mid-size manufacturers should actually do

SAP's mainstream maintenance for ECC 6.0 ends in 2027, with extended maintenance available at additional cost typically through around 2030 depending on the specific agreement. Mid-size manufacturers have three real options: migrate to S/4HANA (on-prem or cloud) before 2027, pay for extended maintenance to buy 2-3 more years, or move off SAP entirely. With limited internal SAP resourcing, most mid-size manufacturers should already be past discovery and into a scoped S/4HANA conversion plan by now, or actively budgeting for extended maintenance as a deliberate bridge, not a default.

Error fix

SAP M7 021: Deficit of SL Stock Quantity

M7 021 fires during a goods issue, delivery, or confirmation when SAP checks the unrestricted-use (SL) stock for the exact plant, storage location and batch combination and finds less than what you are trying to post out. Fix the entry (batch, storage location, quantity) first; only enable negative stock or downgrade the message to a warning if the business genuinely needs to post ahead of a receipt.

Error fix

SAP Short Dump TIME_OUT: Maximum Runtime Exceeded

A TIME_OUT runtime error means a dialog (or RFC) work process ran longer than the maximum allowed runtime, controlled by profile parameter rdisp/max_wprun_time (600 seconds by default). The fix is almost always to move the long-running work to background processing or tune the underlying program, not to raise the timeout.

AI for ERP

Get AI Value From SAP ECC Now, and Use It to De-Risk the Move to S/4HANA

SAP ECC 6.0 mainstream maintenance ends in 2027. Add AI value on ECC now, using its existing BAPIs and IDocs, and use it to de-risk the S/4HANA migration.

AI for ERP

AI for SAP S/4HANA, Running On-Prem or in Your Private Cloud

Run AI on SAP S/4HANA without sending ERP data to a public API. On-prem and private-cloud architecture, CDS views, OData, and honest deployment trade-offs.

Stuck on SAP ECC 6.0?

Talk to engineers who work inside SAP ECC 6.0 every week, and who build private AI that answers these questions from your own ERP data.

Talk to an ERP engineerBrowse ERP Help
All ERP Help articles

Keep exploring

Free tools

ERP fixes and how-tos

Runs with your ERP

AI on your ERP

Integrations

TermsSAP BAPI (Business Application Programming Interface)