Automating JD Edwards via AIS REST,
Without Custom Code
AIS drives EnterpriseOne the way a user does. That is why a write cannot skip a business rule, and why it costs latency.
- AIS drives EnterpriseOne through forms rather than reading tables, so every validation runs and a write cannot skip a business rule.
- Reading JD Edwards tables directly means reproducing decades of business logic yourself, including the parts nobody documented.
- Without custom code has a precise meaning on JDE: nothing enters the Object Management Workbench, and removing the integration changes nothing inside the ERP.
- Orchestrator is where the safety lives. An agent limited to published orchestrations has least privilege expressed as capability rather than as an instruction.
- AIS is a server with a thread pool and a session limit, usually sized for a few mobile users rather than for continuous agent reads.
The JD Edwards AIS server is usually described as a REST API, which undersells it. AIS executes form requests against EnterpriseOne the way a user does and returns JSON, so every validation, default and security rule still applies to anything an agent writes.
That is the argument against the database route in one sentence. ChatFin reaches JD Edwards through AIS and published Orchestrator services only, installs nothing in the Object Management Workbench, and can be removed without changing anything inside the ERP.
AIS is a translation layer, not a database gateway
The Application Interface Services server is often described as JD Edwards' REST API, which undersells what it does and misleads people about what it costs. AIS drives the EnterpriseOne application the way a user does, through forms, and returns the result as JSON.
| What AIS does | What that gives you | What it means in practice |
|---|---|---|
| Executes form requests | Every validation runs | A write cannot skip a business rule |
| Returns JSON | No table knowledge needed | You work in business terms |
| Honours the user's role | Row and column security applies | Test as the real user |
| Runs on its own server | Load is isolated from the database | It has to be sized |
| Survives upgrades | No custom objects introduced | This is the whole point |
The second row is why the direct database route keeps being proposed and keeps being wrong. Reading JD Edwards tables means reproducing decades of business logic yourself, including the parts nobody documented. ChatFin goes through AIS and Orchestrator so the logic stays where it was written.
ChatFin reaches JD Edwards through AIS and Orchestrator, never the database, so every EnterpriseOne validation still runs on a write.
What without custom code means
The phrase gets used loosely. On JD Edwards it has a precise meaning, and it is the difference between an upgrade you can take and one you have to plan around.
That last point is the one worth testing a vendor on. If removing the integration requires a code change inside JD Edwards, it was never outside it.
Nothing ChatFin installs enters the Object Management Workbench. Removing it changes nothing inside EnterpriseOne.
What no code covers
Vendors use that phrase to mean different things: some avoid custom objects, some avoid deployment entirely, some just move the code somewhere you cannot see it.
What it looks like and how you build it can be very different, but to me the goal is are you helping the business achieve its strategic goals, helping them maximize their use of resources, primarily being cash.
Paul Barnhurst, on the AgentCFO podcast
Ask what happens when your process needs a rule the tool does not have. The answer tells you which definition you are buying.
Orchestrator is where the safety lives
AIS gets you in. Orchestrator is what makes the connection governable, and it is routinely skipped by integrations that go straight to form requests.
A named, versioned unit of work
An orchestration is a thing you can review, approve and roll back. A raw form request is a call somebody made once with parameters nobody kept.
The capability is the limit
An agent can only invoke the orchestrations you published. That is least privilege expressed as capability rather than as an instruction in a prompt.
Inputs are declared
Which means a malformed or hostile input fails at the boundary rather than deep inside a form request.
It logs on the JDE side
So the audit trail exists in EnterpriseOne, where an auditor already looks, rather than only in a vendor's console.
ChatFin ships prebuilt orchestrations for the finance operations it performs and will not issue an arbitrary form request. If a capability is needed and no orchestration exists, that is a conversation, not a runtime decision.
The one thing teams underestimate
AIS is a server. It has a JVM, a thread pool and a session limit, and an agent that reads continuously behaves differently from a handful of mobile users, which is what most AIS instances were sized for.
| Symptom | Cause | Fix |
|---|---|---|
| Intermittent timeouts | Thread pool exhausted | Size for concurrent agent reads |
| Sessions climbing | Sessions not released | Reuse the session, close it deliberately |
| Slow at period end | Competing with batch | Schedule reads around the batch window |
| Fine in test, slow live | Test had no other users | Load test against real concurrency |
None of this is difficult and all of it is discovered late. ChatFin reuses sessions, backs off under pressure, and reports AIS response times alongside its own, so a slowdown is attributed.
ChatFin reports AIS server response time alongside its own, so a slowdown is attributed to the right layer.
Where this underperforms
Three.
More on JD Edwards
The pillar
AI agents for JD Edwards
Related
JD Edwards payables · The JD Edwards close
Questions JD Edwards teams ask
Why not read the JD Edwards database directly?
Because the business logic is not in the tables. Reading them means reproducing decades of EnterpriseOne behaviour yourself, including undocumented parts, and a write that bypasses the application skips every validation the ERP would have applied. AIS keeps that logic where it was written.
What does without custom code mean precisely?
Nothing checked out in the Object Management Workbench, no changes to existing forms or business functions, and no table triggers. Orchestrations are configuration you own and migrate with standard tooling. The test is simple: if removing the integration requires a code change inside JDE, it was never outside it.
Why does Orchestrator matter more than AIS?
AIS gets you in, Orchestrator makes it governable. An orchestration is a named, versioned unit of work you can review and roll back, inputs are declared so bad input fails at the boundary, and it logs inside EnterpriseOne where an auditor already looks.
What do teams underestimate about AIS?
Sizing. AIS is a server with a JVM, a thread pool and a session limit, and most instances were sized for a handful of mobile users rather than continuous agent reads. Timeouts and climbing session counts are the usual symptoms, and they appear live rather than in test.
Through AIS and Orchestrator, never the database.
ChatFin executes published orchestrations only. It will not issue an arbitrary form request, which is what makes the capability list the security boundary.
It installs nothing in the Object Management Workbench, reuses AIS sessions, backs off under load, and reports AIS response time alongside its own.
Confirm AIS is enabled, then publish one read orchestration.
Book a demoAll images are served from the Pexels content network. No third party product screenshots, vendor logos or licensed media are used on this page.
Start with one read orchestration.
Confirm AIS is enabled and sized, publish a single read orchestration, and we will prove the whole path with ChatFin against your own JD Edwards instance.