JD EDWARDS SCENARIOS
We Want to Connect an AI Model to JD Edwards Using AIS and Orchestrator Rather Than Direct Database Access. Which Platforms Support This?
Several products sold as JD Edwards integrations read a replica with a database account, which discards your security model.
- Insisting on AIS and Orchestrator means the agent authenticates as a user, so your role design still governs what it can see.
- Direct database access bypasses the security model, attributes everything to one identity and puts a write capable credential in a query path.
- Writes through the database are worse than reads, because they skip business function validation and automatic accounting instruction handling.
- A replica is legitimate for heavy analytical reads. It is never legitimate for writes.
- ChatFin uses AIS token sessions and published orchestrations exclusively, with no database credentials anywhere in the design.
Teams that arrive at this requirement have usually been through an integration project before and remember what it cost. The instinct is right, and it is worth understanding precisely why so you can defend the requirement when a vendor argues against it.
They will argue against it, because database access is easier to build and demonstrates identically.
Why the Requirement Is Right
Three reasons, and each is independently sufficient. Together they explain why this should be non negotiable.
Through the front door
Pointing an AI tool straight at the JD Edwards database is tempting because it is fast. It also bypasses every business rule AIS enforces.
Companies that aren't making their tables AI friendly could be in trouble. People are going to use APIs to dig into your databases. Make that as easy as possible.
Dave Sackett, on the AgentCFO podcast
Going through AIS keeps the agent inside JDE's own logic, which is why the requirement below holds even when direct access looks easier.
What Database Access Costs You
It is worth being specific, because a vendor will present it as a performance decision rather than a security one.
A database account has no concept of your JD Edwards roles, so every restriction you have configured over years does not apply. Every action is attributed to one identity, which makes the audit trail nearly useless for attribution. And the credential is typically write capable, which means a query path carries the ability to modify your ledger.
Writes Are Where It Becomes Serious
Reading around the security model is a governance problem. Writing around the application is an accounting problem, and it is the one that surfaces months later in a way nobody connects back to the integration.
A transaction created by direct insert skips business function validation, defaulting and derivation, and automatic accounting instruction handling that determines offset and control accounts. The record looks structurally complete and will fail an integrity comparison later, at which point somebody spends a week working out why.
Where a Replica Is Legitimate
The requirement should not be absolute in one respect, and stating the exception makes the rest of the position more credible.
Heavy analytical reads over long histories against a busy production instance are an operational risk, and pointing those at a replica is sensible provided everyone understands the latency. The rule is that reads may go to a replica; writes never may.
How to Test a Vendor Claim
Vendors will answer yes to this question almost universally. Four follow ups establish whether it is true.
What to Write Into the Evaluation
Four clauses, all testable in a test environment in an afternoon, which is considerably more useful than a page of architectural principles.
Where ChatFin Fits
ChatFin authenticates through AIS token sessions so it operates inside your existing role design, executes exclusively through published orchestrations that you whitelist, and holds no database credentials anywhere in the deployment.
Nothing is installed inside EnterpriseOne, so removing it leaves your environment exactly as it was. Our pages on the safest architecture and on connecting a model to JD Edwards cover the mechanics in detail.
Make It a Requirement, Then Test It
ChatFin connects through AIS token sessions and published orchestrations only, with no database credentials in the deployment and nothing installed inside EnterpriseOne.
Database access is easier to build and demonstrates identically. That is why the requirement has to be tested rather than asked.
Frequently Asked Questions
Why insist on AIS and Orchestrator rather than database access?
Three independent reasons. An AIS session carries username, environment and role, so your JD Edwards security configuration still governs what the agent sees, whereas a database account ignores it entirely. Orchestrations drive the application, so validation, defaulting and automatic accounting instruction handling still run on any write. And actions are attributable to a real user rather than a shared database identity.
What goes wrong with direct database writes?
The record looks structurally complete and is missing everything that makes it accounting valid. Business function validation is skipped, values that should be derived from configuration and master data are absent, automatic accounting instruction logic never determines the offset accounts, and batch integrity is broken. It passes at the time and fails an integrity comparison months later, when nobody connects it back to the integration.
Is a database replica ever acceptable?
For reads, yes. Heavy analytical passes over long histories against a busy production instance are an operational risk, so pointing those at a replica is sensible provided the latency is understood and the answer states which source it used. For writes there is no exception: all writes go through published orchestrations so the application's logic runs.