# A private AI layer for SAP PI/PO: interface Q and A and failed-message triage > Source: https://netray.co/erp-help/private-ai-layer-sap-pi-po-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer On PI/PO the valuable AI uses are not business-data questions but integration operations: finding which interface does what, explaining mappings, and triaging failed messages. Index the Enterprise Services Repository and Integration Directory exports and message logs, serve an open-weight model on your own GPUs, and keep payloads out unless a use case needs them. Message restarts stay behind human approval. ## Kind advanced ## System sap ## Erp SAP PI/PO (Process Integration and Orchestration) ## Module Integration / Private AI ## Query how to use AI with SAP PI/PO interfaces on-premise ## Alternate Queries - SAP PO AI message monitoring - SAP PI PO interface documentation LLM - SAP PI/PO failed messages AI triage on-prem - SAP PO mapping explain with local LLM ## Applies To SAP Process Integration and Process Orchestration 7.5 (single-stack Java, AEX, and dual-stack ABAP+Java where still running). Behaviour for older 7.31 and 7.4 systems differs. ## Steps ### Build the layer around PI/PO **Items:** Decide the use cases: interface catalogue Q and A, mapping and error explanation, failed-message triage, and change-impact questions ('what breaks if we change field X?'). Exclude payload content unless you have a specific reason. Export the design-time and configuration objects as XML through the supported tooling: Enterprise Services Repository (data types, message types, mappings, operation mappings) and Integration Directory (communication channels, receiver determinations, interface determinations). Parse them into an interface graph. Collect message monitoring metadata through the documented monitoring interfaces and the message log: interface, sender and receiver, status, error category, timestamps, and error text. Avoid copying payloads; if needed, mask sensitive fields first. Build the retrieval index over the interface graph, mapping documentation (including message mapping and XSLT or Java mapping descriptions), runbooks, past incident tickets and adapter documentation. Expose read tools (find_interface, explain_error, list_failed_messages, downstream_dependencies) in a tool server, and serve the model locally. Add approval-gated actions: resend or restart of specific failed messages, through the monitoring functions, only after a named person approves and with the message ID logged. Audit every question and tool call, and run the pilot with the integration team first. ## Sections ### Where the integration metadata lives **Body:** PI/PO splits into design time, configuration time and runtime. The Enterprise Services Repository holds data types, message types, service interfaces and mappings. The Integration Directory holds scenario configuration: communication channels with adapter settings, receiver and interface determination, and agreements. At runtime, the Advanced Adapter Engine processes messages, and message logs and statuses are visible in the monitoring tools; on dual-stack systems the ABAP side adds its own message monitor and IDoc handling. All of this can be extracted without touching the runtime database directly. Repository and directory objects can be exported as XML through the integration builder tooling, and monitoring data is available through the documented monitoring functions and web services of the version you run. Confirm the exact monitoring API set on your support package level before building. Because configuration is XML, it parses well, and an interface graph (sender to receiver, mapping used, channel type) can be built reliably. Mappings are the richest content. Graphical message mappings, XSLT and Java mappings are all describable once parsed. A model can explain what a mapping does, but should be told plainly which fields it saw, and should never be asked to 'guess' what unreadable compiled code does. **Code:** -- Reporting store table you create for failed-message triage (your schema, not SAP's) CREATE TABLE po_message_event ( message_id VARCHAR(64), interface_name VARCHAR(120), sender VARCHAR(60), receiver VARCHAR(60), status VARCHAR(20), error_category VARCHAR(60), error_text TEXT, event_ts TIMESTAMP ); ### Reference architecture **Body:** The layer is smaller than an ERP layer because the data is mostly metadata. A parser turns repository and directory exports into a graph database or relational tables. A collector pulls message status and error text into a reporting store on a schedule. A retrieval index covers documentation, runbooks and past tickets. A tool server exposes read actions. The model, served on local GPUs, turns these into answers such as 'this interface failed with a mapping exception on field X; the same pattern occurred in tickets 123 and 456; here is the runbook step'. Payloads deserve a policy. Messages routinely carry personal data, pricing, part numbers and in defence contexts controlled technical data. Default to excluding payloads from the index entirely, store only metadata and error text, and where payload fields are needed for diagnosis, extract named fields with masking. If payload analysis is needed on sensitive flows, run it only inside the enclave and keep retention short. For air-gapped PI/PO, everything runs inside the same zone. The collector only needs network access to the PI/PO monitoring endpoints and the tool server to the stores. **Code:** PI/PO ESR + Integration Directory --XML export--> parser --> interface graph / tables PI/PO message monitoring --collector--> reporting store (metadata + error text, no payload by default) Runbooks + tickets + adapter docs --> retrieval index Integration engineer -> chat UI -> orchestrator -> vLLM (local GPUs) -> tool server Approved restart -> monitoring function with message ID -> audit log ### Permissions, write-back and sizing **Body:** PI/PO roles are Java user management roles for monitoring, configuration and administration. Mirror them as tool entitlements: the support analyst may list failed messages but not export mappings; the integration architect may see configuration. Interfaces carrying restricted data can be flagged in the graph, and tool code can filter by flag. The assistant should never show channel credentials; exclude secure store contents from every export. Write-back means restarts and resends. These change business flow and can duplicate postings if the target is not idempotent, so require approval by a named person and check the interface's duplicate handling first. Do not let the assistant change configuration objects; changes to the Integration Directory go through your normal transport process. As ranges: the user base is the integration team and support analysts, tens of people, so a 14B to 32B model on one GPU is usually enough. The index is small. Phases: first, interface Q and A over exported metadata; second, triage suggestions on failed messages; third, approved resends. ### Honest limits and the roadmap question **Body:** PI/PO 7.5 has a finite maintenance window, and SAP positions SAP Integration Suite as the successor; check SAP's current maintenance statement for your version. A private AI layer on the exported interface graph is useful for a migration too: it can list interfaces, adapter types and mapping complexity, which feeds the migration estimate. Do not claim it converts mappings automatically; it can draft, but a person must test. Other limits: compiled Java mappings and custom adapter modules are opaque unless source is available; classification of error text depends on consistent logging; and the SAP monitoring tools themselves (alert rules, message monitoring filters, auto-restart policies) are enough for many teams. The AI layer pays off where the interface landscape is large, undocumented and held in a few heads. ## Pitfalls - Indexing message payloads without masking, creating a second copy of personal or controlled data. - Allowing the assistant to resend messages without checking duplicate handling in the target. - Exporting configuration with credentials or secure store references into the index. - Asking the model to explain compiled Java mappings it cannot see. - Relying on a monitoring API that differs between support package levels without testing. - Treating the interface graph as current when it was exported months ago and transports have since changed it. ## Ai Angle Netray builds this kind of layer as a custom build: parse the PI/PO exports into an interface graph, index runbooks and tickets, and give the integration team a local assistant that cites the interface, mapping and channel behind each answer. It complements, and does not replace, SAP's own monitoring and alerting. ## Faq ### What is the best first use of AI on PI/PO? **Answer:** Interface documentation Q and A and failed-message triage over metadata and error text. Both are low risk, need no payloads, and save time for the few people who know the landscape. Mapping explanations and migration inventories are strong second steps. ### Should message payloads go into the AI index? **Answer:** By default no. Payloads often hold personal or controlled data. Index metadata, status and error text, and extract specific fields with masking only when a diagnosis needs them, inside the secured zone with short retention. ### Can the assistant restart failed messages? **Answer:** Only as an approval-gated action through the supported monitoring functions, with the message ID logged and a check that the target handles duplicates. Never let it change configuration; use your normal change and transport process for that. ### Does this help us move to SAP Integration Suite? **Answer:** It can. A parsed inventory of interfaces, adapters, mappings and volumes is the base of any migration estimate, and an assistant can answer questions about it. Conversion of mappings still needs tooling and testing by people; treat AI output as a draft. ## Search terms SAP PI/PO AI, SAP PO message monitoring AI, SAP PO interface documentation, SAP PI PO failed messages triage, SAP Integration Suite migration inventory, SAP PO mapping explain, private AI SAP PO, SAP PI/PO 7.5 on-premise AI --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json