# How to Add a Private AI Layer to JD Edwards EnterpriseOne On-Prem

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

## Short answer

Use the AIS Server as the front door: its data service reads tables under the calling user's JDE security, and Orchestrator wraps approved write actions. Add a read replica for heavy analytical questions, a local retrieval index over media objects, and an open-weight model on your own GPUs. Keep Security Workbench as the single source of truth for who can see what.

## Kind

advanced

## System

jd-edwards

## Erp

JD Edwards EnterpriseOne (on-prem)

## Module

Private AI layer / AIS and Orchestrator

## Query

how to add AI to JD Edwards EnterpriseOne on-prem

## Alternate Queries

- JD Edwards AIS REST API AI integration
- JDE EnterpriseOne LLM without cloud
- JD Edwards Orchestrator chatbot on-premises

## Applies To

JD Edwards EnterpriseOne 9.2 with a current Tools Release (AIS Server and Orchestrator Studio); database on Oracle, SQL Server or DB2 for i. Older 9.1 estates can use direct database reads only

## Steps

### Build order for a JDE private AI layer

**Items:**

- Deploy or reuse an AIS Server and confirm the Tools Release supports the Orchestrator and data service features you need. Place it on the internal network only.
- Create a service JDE user and role pair for the tool server with minimal Application Security, and decide whether end-user calls use the user's own AIS token (preferred) or a proxy identity with a mapped role.
- Build the tool server (MCP or REST) with parameterised read tools. Implement them against the AIS data service for small lookups and against a read-only replica for large analytical queries.
- Define write actions as Orchestrator orchestrations with explicit inputs, called only after a human approves a drafted payload.
- Index media object attachments and linked documents in a local vector store, carrying business unit and document type as the access label.
- Serve the model with vLLM or Ollama on local GPUs; keep the model host off the internet for the air-gapped option.
- Log every question and tool call with the JDE user ID, and review the log with the JDE security administrator monthly.

## Sections

### Data access paths in EnterpriseOne

**Body:**

EnterpriseOne keeps business data in tables such as F0101 (Address Book), F4101 and F4102 (Item Master and Branch), F4211 (Sales Order Detail), F4311 (Purchase Order Detail), F4111 (Item Ledger), F3111 and F3411 (Work Order and Parts List/MRP), and F0911 (Account Ledger). Column names carry a table prefix, for example SDDOCO in F4211, while the Data Dictionary alias is DOCO. Dates are stored in a century-year-day Julian format, and quantities and amounts are often integers with implied decimals, which a naive SQL tool will misread. The tool server needs a thin translation layer for both.

The official integration layer is the AIS Server, which exposes REST services under paths such as /jderest/v2/tokenrequest, /jderest/v2/dataservice, /jderest/v2/formservice and the Orchestrator endpoints. The data service can browse a table or business view and returns JSON; the form service drives real applications and therefore honours the same application and row security as a user at the keyboard. Orchestrator Studio lets a JDE developer publish a controlled orchestration that can call forms, business functions and messages as a REST service.

**Code:**

POST https://ais.example.local/jderest/v2/dataservice
Content-Type: application/json
{
  "token": "<AIS token for the end user>",
  "targetName": "F4211",
  "targetType": "table",
  "dataServiceType": "BROWSE",
  "maxPageSize": "50",
  "returnControlIDs": "F4211.DOCO|F4211.LITM|F4211.UORG|F4211.DRQJ",
  "query": { "autoFind": true,
    "condition": [ { "controlId": "F4211.MCU", "operator": "EQUAL",
                     "value": [ { "content": "30", "specialValueId": "LITERAL" } ] } ] }
}

-- Replica query for heavy analytics (SQL Server/Oracle syntax varies)
-- Julian date: CYYDDD, so 2026-10-21 is 126294
SELECT SDLITM, SUM(SDUORG) AS ordered
FROM   F4211
WHERE  SDMCU = '         30'      -- business unit is right-justified, padded
  AND  SDDRQJ >= 126294
GROUP  BY SDLITM

### Reference architecture

**Body:**

The tool server sits between the model and EnterpriseOne. For quick lookups it calls AIS with the user's token, so the JDE security kernel decides what comes back. For large scans (open orders by customer across years) it queries a replica built with native database replication such as Oracle Data Guard, SQL Server Always On readable secondaries or DB2 replication. The retrieval index holds text from media objects (stored through the Media Object tables such as F00165 and file queues) and any shared-drive documents; each chunk carries the business unit and document type.

The model runs on local GPUs. Prompt assembly, tool selection and answer rendering happen in the tool server, so the model host never holds JDE credentials. An audit store records the user, the tool, parameters and row counts. In an air-gapped deployment AIS, the tool server and the model all live inside the same network zone, with weights and images moved in through a controlled transfer.

### Mirroring JDE security

**Body:**

Security Workbench is where EnterpriseOne defines application, action, row, column, processing-option, exit and external-call security by user and role. AIS calls made with the end user's token run through the same checks. Direct replica queries do not, so the tool server must reproduce row security by translating the user's Security Workbench row rules (for example by business unit or document type) into WHERE clauses, or restrict replica tools to data where no row security applies.

Two practical rules help. Prefer AIS for anything where a user's identity matters. Use the replica only for aggregates that a role could already see in a standard report, and verify them against the same user's view in the real application during acceptance testing. If a rule cannot be mirrored with confidence, leave that table out of the assistant.

### Sizing, rollout and honest limits

**Body:**

A site with 200 to 1,000 JDE users typically runs the assistant on one or two GPUs for a 30B to 70B-class model, with a second node for availability. Phase 1 is five to ten read tools (stock status, open orders, PO status, work order status, customer or supplier lookups) in 6 to 10 weeks. Phase 2 drafts documents such as a PO change request. Phase 3 calls approved Orchestrations, always showing the exact payload to the approver.

Limits: the data service returns paged JSON, so very large result sets belong on the replica; Julian dates, implied decimals and padded business unit values cause subtle wrong answers unless handled in the tool layer; Orchestrator and AIS features depend on your Tools Release; and if your need is a smarter dashboard, One View Reporting or a UDO may be enough without any model.

## Pitfalls

- Reading F-tables from the replica with a shared account and no row security, then showing the result to users whose JDE role could not open it.
- Ignoring Julian dates and implied decimals, which yields confidently wrong date filters and unit quantities.
- Letting the model write free-form SQL. Expose named tools with typed parameters.
- Calling Orchestrations with a broad service role. Use narrow roles per orchestration and require approval.
- Overloading the AIS Server with large browse calls; push big scans to the replica and cache stable reference data.

## Ai Angle

ERPray uses the AIS data service for user-scoped lookups and a replica for large scans, handles Julian dates and implied decimals in its JDE connector, and shows the query behind every answer. Write actions are drafted for approval and executed only through orchestrations your JDE team has published.

## Faq

### Is the AIS Server required to add AI to JD Edwards?

**Answer:** Not strictly, since read-only database access works, but AIS is the cleanest way to honour user security and to call approved write actions. Without it you must rebuild row and application security in your own tool layer, which is harder to prove correct.

### Can the model call Orchestrator directly?

**Answer:** It should not. The tool server should call named orchestrations with validated inputs after a person approves the payload. This keeps the model from composing arbitrary actions and gives you an audit trail tied to a JDE user.

### Does this work with DB2 for i or SQL Server back ends?

**Answer:** Yes. The AIS path is database independent. For replica reads, the SQL dialect, padding and date conversion differ by engine, so the tool server needs an adapter per database.

### What about JD Edwards World?

**Answer:** World has no AIS Server, so its pattern is different: direct DB2 for i access and RPG or batch interfaces. See the separate JD Edwards World on IBM i architecture page.

## Search terms

add AI to JD Edwards EnterpriseOne, JD Edwards AIS REST API, JDE Orchestrator AI integration, JD Edwards LLM on-premises, EnterpriseOne private AI, JDE F4211 query AI assistant, JD Edwards Security Workbench AI, JDE air-gapped AI, JD Edwards chatbot on-prem

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