How to add an AI chatbot to JD Edwards World
Short answer
Build a chat front end that answers from your World data and documents, not from the model's memory. It queries read-only DB2 for i views and a document index, respects each user's role, shows its sources, and can run entirely on-prem with an open-weight model.
World users navigate by menu numbers, function keys and green-screen inquiries that few new hires know. A chatbot lowers that barrier: 'what's the on-hand for 4410-B at the Dayton branch' becomes a sentence instead of three screens. Customers and suppliers may want the same thing through a portal.
A good chatbot here is mostly retrieval and discipline. It must answer from live data, say when it does not know, and never reveal something the asker is not allowed to see. The language model is the smaller part of the work.
Below is a build outline covering internal users first, then external portals.
What teams use it for
Internal 'ask the ERP' assistant
Planners, buyers and customer service ask about stock, orders and POs in plain English with answers citing the underlying records.
New-hire navigation help
Explain which World menu or inquiry to use for a task, drawing on your internal procedures document rather than guessing.
Customer order status portal
An external chat that returns the customer's own order status and tracking, scoped to their address book number.
Supplier self-service
Suppliers confirm PO dates or ask what is open for them, with changes routed to a buyer for approval.
Policy and SOP Q&A
Search quality procedures, receiving instructions and approval limits stored as documents and answer with the source paragraph.
JD Edwards World (IBM i) integration surface
- DB2 for i read access through ODBC or JDBC to a views library, giving the chatbot structured answers from item, order, PO and inventory tables.
- The IFS and file shares where SOPs, certificates and drawings live, for a document retrieval index (vector or hybrid search).
- World user and security definitions: user profiles, menu and file security, and address book relationships, used to decide what each chat user may see.
- IWS or a custom REST layer if you prefer to call existing inquiry programs rather than SQL.
- Single sign-on from your directory (for example Entra ID or LDAP) at the chat front end, mapped to a World user or role.
How it works
- 1
Decide audience and scope
Start with internal staff. External portals need stricter scoping and legal review, so treat them as a second phase.
- 2
Build structured tools
Create views and typed functions for the top questions. The bot routes a question to a function rather than writing arbitrary SQL.
- 3
Index documents
Chunk SOPs and manuals, store embeddings in a local vector store, and keep metadata for permissions and revision.
- 4
Orchestrate
A router decides between data tools, document search or a polite refusal. Answers include the source record or paragraph.
- 5
Enforce identity
Authenticate with SSO and apply the user's company, branch and customer filters inside every query.
- 6
Choose the front end
A web widget in your intranet, a Teams bot, or a portal page. Keep conversations and feedback stored for improvement.
Example flows
Customer service lookup
Trigger: Agent types 'status of PO 77120 for Acme'
- Router picks the order status tool and passes the parsed number and customer.
- Tool returns lines, quantities, promised dates and receipts.
- Bot replies with a short summary and links the record.
Result: The agent answers the caller in seconds without hunting through screens.
Receiving SOP question
Trigger: Dock worker asks how to handle a short shipment
- Bot searches the receiving procedure index.
- It quotes the relevant steps and the revision date.
- It offers to open a discrepancy note for the buyer.
Result: Consistent handling that follows the current procedure, with the source shown.
Keeping data on-prem
Everything can run inside your network: the chat front end, the tool service, a local vector database and an open-weight model on a GPU server served with vLLM or Ollama. The IBM i is only queried through the views library. No prompt, document chunk or conversation leaves the plant. For sites with multiple plants, deploy one model server and route by branch. Keep an internal mirror for model files and libraries when the environment is air-gapped. If response speed matters, a smaller model for routing and a larger one for drafting can share the same hardware.
Security checklist
- Authenticate through SSO and apply per-user data filters in the query layer, never only in the prompt.
- External users see only rows tied to their own customer or supplier number.
- Refuse and log out-of-scope requests such as other customers' prices.
- Redact sensitive fields (cost, margin, payroll) from tools unless the role permits them.
- Retain chat logs under a documented policy and restrict who can read them.
Ways to get it done
Generic chatbot platform with a custom connector
Effort: Weeks, plus connector and security review.
You want a quick internal pilot and data can use a cloud service.
Build on an open-source stack in-house
Effort: Two to three months for a robust internal assistant.
You have developers and want full control and on-prem operation.
Partner delivery with Netray
Effort: Pilot with a limited set of questions, then expand.
You want a World-aware assistant, private model and role scoping built and supported.
Pitfalls
- !Letting the model answer from memory when a lookup fails. Force 'I could not find it' instead.
- !Not mapping chat users to World roles, so everyone sees everything.
- !Indexing outdated SOPs without revision control, so the bot quotes superseded steps.
- !Skipping a feedback button; you will not learn which answers fail.
- !Underestimating the shared-service load on production DB2 for i from many chat users.
Frequently asked questions
Can a chatbot work with a green-screen system like World?
Yes, because it does not use the screens. It reads DB2 for i data through views or calls existing programs through a service. Users get a modern interface while World continues to run as the system of record.
Will the chatbot make things up?
Any language model can, which is why the design retrieves facts from tools and documents and shows sources. Add refusal rules for missing data and review a sample of chats weekly. Do not rely on the model's own memory for ERP facts.
Can customers use it?
Yes, with strict scoping to their own records, authentication and legal review of what you display. Begin with internal staff to prove accuracy, then open a limited external scope such as order status only.
Does it need a GPU?
For an on-prem open-weight model, yes, a GPU server sized to your concurrent users. Small models can run on modest cards for a pilot. If cloud is acceptable for non-sensitive content, you can start with a hosted model and move later.
How long until it is useful?
A narrow pilot on the five most common questions can be useful in weeks. Breadth is the slow part, since each new question type needs a tested view or document source. Grow it from real usage logs.
More for JD Edwards World (IBM i)
Want AI chatbot working on your JD Edwards World (IBM i)?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment