# Private AI layer for SAP S/4HANA on-premise: released APIs, CDS and a local model

> Source: https://netray.co/erp-help/private-ai-layer-sap-s4hana-on-prem-architecture
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

For S/4HANA on-premise, build the AI layer on released OData APIs and CDS views rather than raw tables, replicate analytical data to a store you control, index documents separately, and serve an open-weight model on local GPUs. CDS access control and PFCG roles carry the user's permissions into answers. Writes use released APIs after human approval, which keeps the core clean and upgrade-safe.

## Kind

advanced

## System

sap

## Erp

SAP S/4HANA (on-premise and private cloud edition)

## Module

Integration / Private AI

## Query

SAP S/4HANA on-premise AI integration without cloud

## Alternate Queries

- how to add a private LLM to S/4HANA on-premise
- S/4HANA CDS views AI assistant architecture
- S/4HANA private cloud edition local LLM
- SAP S/4HANA OData API AI agent

## Applies To

SAP S/4HANA on-premise (1909 onward in practice) and S/4HANA Cloud, private edition. Public cloud editions restrict custom code and network paths and are out of scope here.

## Steps

### Wire a private AI layer into S/4HANA

**Items:**

List the released APIs for your scope in SAP Business Accelerator Hub and your own system's service catalog (/IWFND/MAINT_SERVICE), for example the purchase order, sales order, material document and business partner APIs. Prefer these over table reads.

For analytical questions, identify the CDS views you are allowed to extract. Use the I_ interface (VDM) views and extraction-enabled views, and check released status in the ABAP Development Tools API state view.

Choose the data movement: ODP-based extraction or SLT replication into a reporting store you control, or live OData calls through the Gateway hub for small result sets. Do not read tables like ACDOCA or MATDOC from outside on a high-frequency schedule against production.

Create a communication user and communication arrangement in the system for the AI layer, scoped to the communication scenarios it needs. Use per-user propagation where answers must reflect the asker's own access.

Build the retrieval index over attachments (Attachment Service and GOS), DMS documents, and external SOPs and drawings. Carry company code, plant and sales organization as chunk metadata.

Expose approved read actions through an MCP or internal tool server, and serve the model with vLLM on your GPUs. The model chooses tools; the tools build OData requests.

Add an approval queue for drafts and write-backs, log every call, and pilot read-only first.

## Sections

### Data access paths on S/4HANA

**Body:**

S/4HANA changed the data model. Financial postings land in the universal journal table ACDOCA, material movements in MATDOC, and customers and vendors are modelled through the business partner (BUT000 and related tables). Compatibility views keep old table names readable for old code, but they are not a stable contract for new integrations. SAP's direction is the virtual data model: CDS views, with released ones carrying a stability guarantee, exposed as OData services, and wrapped by released APIs such as the purchase order and sales order services.

Use the layers in this order. First, released OData APIs for transactional reads and approved writes. Second, extraction-enabled CDS views through ODP or SLT for bulk analytics. Third, only if neither covers it, a custom CDS view with its own access control, built in the system by your ABAP team. Direct SQL against the HANA schema is the last resort and in many contracts and RISE-style private cloud setups it is not available at all, so design as if it were not.

**Code:**

# Read recent purchase orders through a released OData service (verify service path and fields on your release)
GET /sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV/A_PurchaseOrder
    ?$filter=PurchaseOrderDate ge datetime'2026-09-01T00:00:00'
    &$select=PurchaseOrder,Supplier,PurchasingOrganization,PurchaseOrderDate
    &$top=100
Accept: application/json

-- Replica query on extracted universal journal data (column names illustrative, check your extraction view)
SELECT RBUKRS, GJAHR, RACCT, RCNTR, SUM(HSL) AS amount_local
FROM   acdoca_replica
WHERE  RLDNR = '0L' AND GJAHR = '2026' AND RBUKRS = '1000'
GROUP  BY RBUKRS, GJAHR, RACCT, RCNTR;

### Reference architecture and the private cloud edition

**Body:**

The components match any private AI layer: a reporting store fed by ODP or SLT, a retrieval index, a tool server wrapping OData calls, a locally served open-weight model, an identity layer and an audit log. What differs on S/4HANA is that the contract is the API. If your tool server only calls released services and extraction views, the same layer survives upgrades and conversions, because SAP keeps those interfaces stable.

On S/4HANA Cloud, private edition, SAP or a hosting partner runs the landscape. You usually get API access over a private network path but not database access and not arbitrary add-ons on the application server. Plan the network route between your GPU cluster and the hosted system early, and agree what data may be replicated out. If policy forbids any replication to your premises, the AI layer must run in the same sovereign zone as the system, or use live API calls only.

For an air-gapped plant running S/4HANA on-premise, everything above runs inside the enclave: model weights, container images, and the retrieval index are imported through a controlled transfer, and no component needs outbound internet.

**Code:**

S/4HANA --(released OData / CDS via Gateway)--> tool server --> orchestrator --> vLLM (local GPUs)
S/4HANA --(ODP / SLT)--> reporting store (approved views only)
Attachments + DMS + SOPs --> parser --> retrieval index (company code / plant metadata)
Identity: SSO user mapped to SAP user; communication user for background sync
Audit: append-only log of question, tool, parameters, row keys returned

### Permissions and write-back

**Body:**

S/4HANA authorizations still run through PFCG roles and authorization objects, and for CDS views the equivalent is the access control definition (DCL) attached to the view, which restricts rows by the user's authorization values. A view without access control, or called by a user with broad technical rights, returns everything. Insist that every CDS view in your tool contract has a DCL, and test with a restricted user.

For per-user fidelity, propagate the asker's identity to the API call (OAuth with SAML bearer assertion or principal propagation through your gateway). For mirrored filters, export authorization values and apply them in the replica and index. Business partner and organizational filters (company code, purchasing organization, plant) are the usual dimensions.

Write-back goes through released APIs only: for example creating a purchase requisition or posting a confirmation via the corresponding service, after a human approves the drafted payload in a separate screen. Keep idempotency keys and store the exact payload in the audit log. Never write to ACDOCA or MATDOC or any table directly; the HANA core relies on posting logic for consistency.

### Sizing, rollout and limits

**Body:**

As ranges: 100 to 300 named users on a 30B to 70B open-weight model are commonly served from two to four data-centre GPUs, with the reporting store and index on ordinary servers. ACDOCA volumes can be very large, so extract aggregates and recent periods rather than every line, unless a use case demands line items.

Phases: read-only questions through released APIs and the replica; then drafts (supplier emails, exception summaries, requisition drafts); then approved actions through APIs. Measure answer accuracy against a fixed question set before each phase.

Limits. SAP's own AI (Joule and embedded intelligent scenarios) is built for SAP-managed cloud and may be enough if you are already there and your data policy allows it; this architecture is for teams that must keep data and inference on their premises. Free-text business questions that depend on heavy custom Z logic will need that logic exposed as an API first. Public cloud editions are a different problem. And note that some APIs paginate or limit page size, so design the tool code to page and aggregate rather than request everything.

## Pitfalls

- Reading ACDOCA or MATDOC directly on a schedule from an external tool, hurting performance and ignoring access control.
- Building on compatibility views or non-released CDS views, then breaking at the next upgrade.
- Exposing a custom CDS view without a DCL, which returns data regardless of the user's authorizations.
- Assuming private cloud edition gives database access; it generally does not.
- Pulling every journal line into the index instead of aggregates, inflating storage and latency.
- Letting the model construct OData filters from free text instead of typed tool parameters.

## Ai Angle

ERPray calls S/4HANA through released OData services and approved views, shows the request behind each answer, and keeps the model on your hardware. A sensible first scope is three or four read tools plus a document index, then drafting. Write actions stay behind approval and released APIs, so the core stays clean through upgrades.

## Faq

### Should I use CDS views or OData APIs for AI access?

**Answer:** Use released OData APIs for transactional reads and approved writes, and released CDS views through ODP or SLT for bulk analytics. Both are stable contracts SAP maintains across upgrades. Custom CDS views are fine when they carry their own access control. Avoid raw table reads and non-released objects.

### Can we run the LLM on our own GPUs if S/4HANA is in a private cloud edition?

**Answer:** Usually yes, if you establish a private network path and agree what data may leave the hosted zone. The model can run on your GPUs and call released APIs over that path. Replication of large datasets out of the hosted environment needs a policy decision first.

### Does Joule make this unnecessary?

**Answer:** Not for everyone. Joule fits teams on SAP-managed cloud services that accept SAP's data handling. If you need inference and data to stay on your premises, need non-SAP sources in the same answer, or run air-gapped, a self-hosted layer is the practical option.

### How do we keep row-level security?

**Answer:** Give every CDS view an access control definition, propagate the user's identity on API calls, or mirror authorization values into the replica and retrieval filters. Test with restricted users and fail closed: if a user's filters cannot be determined, return nothing.

## Search terms

S/4HANA on-premise AI, S/4HANA private LLM, S/4HANA CDS views AI, S/4HANA OData API agent, SAP S/4HANA air-gapped AI, S/4HANA private cloud edition LLM, S/4HANA ODP extraction AI, SAP Joule alternative on-premise

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json