Por mariogarcia The problem: a purchase order that never arrived on time
An orchestration in JD Edwards was built to load a purchase order from a CSV file. Nothing unusual about the requirement: read the file, build the header and detail rows, call P4310, done. The problem showed up only with real data — a purchase order with 999 lines.
Every time someone ran it, the same thing happened: the caller gave up waiting and reported a timeout. Except the purchase order had actually been created. Correctly. Every single time. The orchestration wasn’t broken — the way it answered was.
Why the timeout isn’t really a bug
A synchronous HTTP call makes a promise: you ask, you wait, you get an answer in a reasonable time. That promise works fine for a lookup, a single-record update, a quick validation. It breaks down the moment the underlying work takes minutes instead of milliseconds — and building a purchase order line by line, 999 times, running business function validation on each one, is exactly that kind of work.
The instinct is usually to “make it faster”: trim validations, batch the inserts, tune the SQL. Sometimes that helps. But it treats the symptom. The actual mismatch is architectural: a long-running process is being asked to behave like a short one, because that’s the only mode most orchestrations are ever built in.
What Fire and Forget actually does
JD Edwards Orchestrator has an async execution mode that solves exactly this mismatch, and it’s used far less than it should be: Fire and Forget.
Instead of holding the HTTP connection open until every step finishes, the orchestration responds immediately with an HTTP 202 and an empty JSON body. The caller gets an answer in milliseconds — not “here’s your result,” but “I’ve started, and I’m not going to make you wait for the rest.”
The heavy work — reading the CSV, building each purchase order line, validating it through P4310 — keeps running in the background, completely detached from that original HTTP request. Nobody is polling a stuck connection anymore.
The case: 999 lines, one CSV, one recurring timeout
Back to the original case. Switching the orchestration to Fire and Forget didn’t make it process the 999 lines any faster — it still takes roughly the same time to validate and create that many order lines. What changed is who’s affected by that duration.
Before: the buyer submits the CSV, watches a loading indicator, and eventually sees an error — even though, underneath, JDE finished the job just fine. After: the buyer submits the CSV, gets an instant acknowledgment that the job has started, and goes back to whatever else they were doing.
Building the part that actually tells you it’s done
Fire and Forget only solves half the problem on its own. An HTTP 202 tells you the process started — it says nothing about whether it finished, or whether it finished successfully. You have to build that second half yourself.
The recommendation here is firm: if you’re working with Fire and Forget, always close the process with a final notification that reports whether something failed, or confirms the process has finished. It’s the only way to be certain the work actually got done — without that final notification, the 202 only confirms it started, never that it finished successfully.
In practice, that final notification usually rests on a small set of building blocks:
- A second orchestration or a scheduled check that looks for the purchase order once processing should be done, and confirms it exists with the expected number of lines.
- A notification — email, JDE message center, whatever your users actually check — that fires once that confirmation happens.
- An error path: if the check doesn’t find what it expects, the notification says so explicitly, instead of leaving the buyer to assume everything is fine because nothing complained.
None of this is exotic. It’s the same notification and monitoring tooling already available in Orchestrator, just pointed at a different question: not “did the call succeed,” but “did the work actually finish.”
When to use it — and when not to
Fire and Forget is the right fit for exactly one kind of problem: work whose duration you can’t bound tightly, where the caller doesn’t need the result in the same request cycle. Bulk loads from a file, iterations over large data sets, anything triggered by a batch of user input rather than a single record.
It’s the wrong fit for anything the caller needs an immediate decision on — a price check before confirming a sale, a validation that blocks the next screen. Making those async just moves the waiting somewhere else and adds complexity nobody asked for.
Spotting the need for it before it becomes an incident
The purchase order case only became visible because someone hit it with a large enough file. The warning signs usually show up earlier, if you know where to look: orchestrations whose average run time creeps up as data volume grows, integrations where the caller is a script with its own timeout you don’t control, or any process where “the record was created but the caller reported an error” comes up in a support ticket. Any of those is worth checking whether the orchestration is being asked to do batch-sized work inside a request-sized time budget.
A note on idempotency
One thing Fire and Forget does not solve for you: if a caller times out, doesn’t get a 202, and simply retries the same file, you can end up with the same purchase order created twice. That risk exists with or without async mode — but async mode removes the caller’s main reason to retry blindly (the illusion that nothing happened), so it’s a natural moment to also add a check for “has this exact request already run” before creating anything. It’s a small addition, and it closes a gap that’s easy to miss until it shows up as a duplicate PO in production.
The real lesson
The purchase order wasn’t the problem. Treating a multi-minute process as if it belonged in a single HTTP request was. Fire and Forget doesn’t make anything faster — it makes the orchestration honest about how long it actually takes, and moves the “are we done yet” question to where it belongs: a separate, deliberate check, instead of a connection quietly timing out.
If you have an orchestration that times out under real volume, it’s worth asking whether it needs to be faster — or whether it just needs to stop pretending to be instant.