AdvancedInfor XA / MAPICS on IBM iDB2 for i data access / AI architecture

How to Add AI to MAPICS and Infor XA on IBM i Without Leaving Your Network

Question
how to add AI to MAPICS XA on IBM i

Also searched as

  • Infor XA AI integration on-prem
  • MAPICS IBM i ChatGPT alternative
  • AS/400 ERP AI assistant DB2 for i
  • private LLM for IBM i ERP

Short answer

MAPICS and Infor XA keep their data in DB2 for i, which is readable over standard SQL through ODBC or JDBC. Capture changes from journals, copy them to a reporting database on x86, run the model on a separate GPU server, and the Power system stays untouched. Writes still go through the application's own programs.

Applies to: MAPICS XA and Infor XA on IBM i 7.3 or later. Exact file names and modules vary by release, so use your own data dictionary.

Reference build for a private AI layer on IBM i

  1. 1Inventory the XA libraries and the files behind the questions people ask (items, customer orders, purchase orders, MRP, work orders). Use the Infor XA data dictionary documentation and QSYS2.SYSTABLES to confirm names and descriptions.
  2. 2Decide the data path: read the IBM i directly with a read-only user over JDBC for low volume, or replicate to a reporting database on x86 for heavier use. Replication is the safer default.
  3. 3For replication, use journaling on the key files and a change-capture tool, or a scheduled extract, to feed a PostgreSQL or SQL Server reporting copy.
  4. 4Create a dedicated IBM i user profile with object authority limited to the files you approve, and use SQL GRANT or row and column access control for finer limits.
  5. 5Build views over the reporting copy with business names and fixed filters, and index related documents (drawings, POs, quality records) with the XA item or order number as metadata.
  6. 6Expose approved read actions through an MCP or REST tool server. Do not allow free-form SQL against base files.
  7. 7Serve an open-weight model with vLLM or Ollama on an x86 GPU server. The IBM i is not asked to run inference.
  8. 8Log every question and tool call, and review the log with the IBM i security administrator.

How XA data is reached on IBM i

XA business data lives in physical files in libraries on DB2 for i, and DB2 for i exposes them to SQL. Tools such as IBM i Access ODBC and the JTOpen JDBC driver connect from x86 servers, and the QSYS2 catalog views list tables, columns and text descriptions so you can discover what a library holds. File names in XA are short and release specific, so do not assume names from other ERPs.

The application's behaviour sits in RPG and CL programs. Reading files bypasses that logic, which is acceptable for questions but not for updates: posting an order or receipt directly into a file skips validation and corrupts planning data. Writes should call the application's own interfaces.

Infor offers integration options for XA depending on release and licence, such as ION connectors; check what your contract covers.

-- Discover tables and their text in a library (DB2 for i catalog)
SELECT table_schema, table_name, table_text
FROM qsys2.systables
WHERE table_schema = 'XALIB'
ORDER BY table_name;

-- JTOpen JDBC URL (read-only user)
-- jdbc:as400://ibmi-host;libraries=XALIB;naming=sql;access=read only

Change capture, replica and model placement

Journaling is the natural change-capture mechanism on IBM i. If the key files are journaled, receivers record every insert, update and delete, and the QSYS2.DISPLAY_JOURNAL table function lets a reader consume those entries. A capture job applies them to a reporting database on x86, keeping the production partition free of analytical load.

Put the vector index, tool server and GPU model host on the x86 side, in the same network zone as the replica. Power hardware then sees only a modest stream of journal reads.

For an air-gapped plant, the whole chain stays inside the enclave and model files arrive on controlled media.

Permissions and write-back

IBM i security is object based. A user profile needs authority to each file, and adopted authority in programs can grant more access than the profile alone. Build the AI service profile with the least authority that serves the approved views, and map each person's XA role to the assistant session so tool calls filter by what that person may see.

DB2 for i row and column access control, available in current releases, can mask cost fields or restrict by site on the source, and the replica should carry the same labels.

Write-back is the sensitive step. Create drafts first, then submit through the application's supported programs or ION flows with a named approver, never by writing to files.

Sizing, rollout and limits

User counts for XA sites are often a few hundred named users with a minority active daily. The load is light for one or two GPUs; the extra effort goes into mapping files and descriptions.

Phase 1: read-only questions over items, orders, MRP and stock. Phase 2: drafts and summaries. Phase 3: approved actions through supported routes.

Limits: terse file and field names need a curated glossary before a model can use them well; customisations require mapping; and if the real goal is a screen refresh or a migration to a newer platform, an assistant will not replace that. It does let people ask questions today without waiting for a migration.

Try it here, free

MAPICS and Infor XA AI Assistant Sizing and Value Calculator

Open full tool

Estimate GPU count, token volume, index size, hours saved and payback for a private on-prem AI assistant on MAPICS and Infor XA.

Common pitfalls

  • !Letting the model query base files directly instead of curated views with a glossary of terse XA field names.
  • !Running analytical SQL on the production partition and slowing batch jobs.
  • !Relying on a service profile with broad authority or adopted authority paths.
  • !Writing straight into files, which bypasses RPG business logic.
  • !Forgetting that the replica must carry the same site or role limits as the source.
  • !Leaving journaling off on files you need for change capture.

How an ERP-grounded AI assistant handles this

ERPray can read the replica and answer questions such as which purchase orders are late for a critical item, showing the SQL and respecting mapped roles. Netray builds the journal-based feed, retrieval index and local model serving, while your IBM i administrators and XA consultants own authority and data meaning.

See ERPray

Frequently asked questions

Can we add AI to MAPICS or Infor XA without moving to the cloud?

Yes. DB2 for i is queryable over SQL, so a replica, retrieval index and open-weight model can run on x86 servers inside your network. The IBM i continues to run the ERP and is not asked to host the model.

Does the model run on the IBM i?

No. Inference runs on a separate x86 GPU server. The IBM i supplies data through JDBC reads or a journal-fed replica, which keeps ERP performance predictable.

How do we stop the assistant from corrupting data?

Keep it read-only first. Later, any change goes through the application's supported programs or integration flows as a draft a person approves, never by writing to the files directly.

What if our file names are cryptic?

That is common in XA. Build a glossary from the data dictionary and file descriptions, wrap tables in views with readable names, and let the tool layer, not the model, decide which tables to touch.

Related

Advanced

How to Add AI to Macola ERP On-Prem Without Sending Data to a Cloud

Macola 10 runs on SQL Server, so the safest pattern is a read-only reporting copy of the Macola company database, a small set of approved views, a retrieval index over attached documents, and an open-weight model served on a local GPU. Writes stay out of the first phases and, when added, go through Macola's supported import or SDK routes with a person approving each one.

Advanced

Made2Manage AI Integration Without Cloud: A Private On-Prem Architecture

Made2Manage stores jobs, sales orders, purchasing and inventory in SQL Server tables that a reporting copy can expose through approved views. Pair that with a retrieval index over job travelers and quality documents and an open-weight model on a local GPU, and users can ask about jobs, shortages and orders without any data leaving the plant.

Advanced

AI for abas ERP and proALPHA On-Prem: A Private, GDPR-Conscious Architecture

abas ERP and proALPHA are typically run on a company's own servers in the DACH region, so a private AI layer fits: read through each product's documented interfaces or a database reporting copy, index documents locally, and serve a German-capable open-weight model on your own GPU. Data does not need to leave your premises.

How-to

Infor XA Net.Link: what it is, how it is configured and common issues

Net.Link is the web access layer associated with Infor XA (formerly MAPICS XA) that exposes XA functions through a browser, running on an IBM i web application server. It depends on the IBM i version, the web server profile and Java runtime, so most problems after changes trace to those components. Details vary by XA release, so confirm against your installation guide.

How-to

Infor XA REST API: expose XA through IBM i Integrated Web Services or ION

Infor XA has no single built-in REST API. Practical routes are IBM i Integrated Web Services (IWS), which turns RPG or SQL routines into REST endpoints on the same machine, and Infor ION where your environment supports it. For reads, SQL-backed services are straightforward. For writes, call XA's own programs so business rules run.

How-to

Infor XA costing: cost types, roll-up and standard cost setup

Product costing in Infor XA builds an item's cost from its material, labor, and overhead using the bill of material and routing. Standard cost is the frozen planning cost used to value inventory and measure variance, while other cost sets are used for current or simulated views. A cost roll-up calculates costs from the lowest BOM level upward. Exact program names and options vary by release.

AI for ERP

AI for Infor XA on IBM i: On-Prem, No Replatforming Required

Add AI to Infor XA on IBM i (AS/400) without a migration project. Read DB2 for i directly, ground answers in live XA data, keep everything on-prem.

AI for ERP

AI Agents for ERP, Running On-Prem

A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.

Stuck on Infor XA / MAPICS on IBM i?

Talk to engineers who work inside Infor XA / MAPICS on IBM i 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

Guides

AI on your ERP

Integrations

Software