JDE Orchestrator API Concurrency Sizing Calculator
When an Orchestration is called by a scanner, portal or integration platform, the number of requests in flight decides whether the AIS tier keeps up. Little's law makes that arithmetic simple.
Your numbers
Measured end to end at the AIS server, not the browser.
Ratio of busiest minute rate to the hourly average.
Your results
Planning model. Downstream limits such as the enterprise server and database can cap throughput before threads do.
Threads needed vs response time
Sweeps Average response time from 100 to 3000, holding your other inputs fixed.
Integration load review
Optional: a short review of your JDE API load assumptions.
Optional. The tool and every export work without this. No spam.
How to use it
Take peak calls per hour from the calling system's logs and average response time from AIS or orchestrator logging. Pick a burst factor from the busiest minute. The result shows threads and JVMs required. Try response times of one second versus three to see how slow downstream steps multiply the need.
Little's law
Concurrent requests equal arrival rate times average time in the system. At 6,000 calls per hour and 800 milliseconds, the average is about 1.3 concurrent requests, but a burst of three times that needs about four. Threads are then divided by utilization so the pool is not saturated.
- Slow orchestrations hold threads longer.
- Use the 95th percentile when SLAs are strict.
- Retries from callers inflate the real arrival rate.
Practical notes
The sweep shows how latency, not volume, often drives capacity. Before adding hardware, look at what the slowest orchestration step is waiting on, such as a form call or a UBE, and whether it can be made asynchronous.
Frequently Asked Questions
Does a burst factor matter?
Yes. Averages hide peaks, and queues form in the busiest minute. Measure the ratio of your peak minute to the hourly average and enter that.
What is a safe thread utilization?
Many teams target 50 to 70 percent so latency stays stable when load varies. The right level depends on your tolerance for queuing.
Should I size on the average response time?
Averages hide the slow tail. For strict response commitments, use a higher percentile response time.
Does this include the enterprise server?
No. It sizes the AIS web tier threads only. Calls still run logic on the enterprise server and database, which need their own check.
Netray can help design and load-test integration patterns around JDE Orchestrator.
Related Tools
JDE HTML Web Server JVM Sizing Calculator
First-pass sizing of JDE web server JVM count from logged-in users, memory per session and heap, with an N+1 spare.
OracleJDE UBE Batch Window Calculator
Model UBE elapsed time against your batch window as you add parallel queue slots, including a contention penalty for each extra slot.
ERP Migration & SelectionJDE Cutover Data Load Time Calculator
Build the cutover weekend timeline: load hours from row counts and streams, plus index rebuild, validation and a contingency buffer.
OracleJDE Package Build and Deployment Request Template
A change request document for JDE package builds and deployments with objects, targets, approvals, back-out and verification steps.
More Oracle tools
See all- JD Edwards Document Types Reference (OP, SO, OV, PV)
- JD Edwards UBE Job Scheduling Worksheet
- JD Edwards Table Reference (F4211, F4311, F0101, F4101, F4102)
- JD Edwards Tools Release Upgrade Checklist
- JD Edwards Orchestrator Design Template
- JD Edwards Security Workbench Worksheet
- JD Edwards Environment Refresh Runbook Template
- JD Edwards UBE Runtime Log Worksheet
- JD Edwards Next Numbers Capacity Worksheet