AssetSolve engineering. www.assetsolve.com The reported run used local reference fixtures on November 3, 2026. The SAP BTP mapping below is a design to validate in an authorized tenant.
A timeout is a poor instruction to retry a business transaction. The receiver might have committed the change before the response disappeared. That leaves the caller with a question about the outcome. An automatic retry can turn that uncertainty into a duplicate.
This becomes important when an AI assistant can propose maintenance work, prepare a purchasing action or help resolve a finance exception. The assistant needs a way to retain the question until the receiving system can answer it. A convincing explanation in the chat window cannot settle a missing business result.
The test that exposes the problem
We ran nine existing tests against a local execution controller and state store. Seven used a temporary control-file adapter and deterministic workers. Two used a temporary SQLite store. A process guard blocked network and subprocess operations and recorded zero attempts. All nine cases passed in 0.339 seconds.
The timeout case made one fixture write, then raised an exception before returning its receipt. The controller retained an unknown outcome. On the next scheduler pass, the write count stayed at one. Read-only reconciliation recovered the receipt and verification moved the case to its accepted state. A separate cancellation case confirmed that resuming after a write did not repeat it.
The other tests checked missing authority, unaccepted evidence, a changed worker proposal, a mismatched target, accepted dependent steps and intent reuse. Reusing an identical action returned the existing intent. A changed action or payload was rejected. Separate target environments had distinct intents. The accepted path wrote two dependent local records and verified each through a separate read-back.
These tests establish controller behavior under the selected fixtures. They leave real ERP commit behavior, API permissions, posting rules, network failure modes and Joule execution for tenant testing.
A small action contract
Before dispatch, record the target environment, business object, operation, approved input revision and stable request identity. Retain who or what authorized that exact action and the time window in which it remains valid. At execution, recheck the target and authorization. If a material input has changed, obtain a decision on the changed request.
After dispatch, keep three outcomes distinct. A confirmed result has an authoritative reference and verified state. A definite rejection has evidence that the action was refused. An unknown outcome means the receiver may have acted and the caller cannot yet prove the result. Recovery begins with a lookup using the stable business reference or another receiver-supported correlation method.
For an unresolved outcome, give the operator the original request, last known state and evidence needed to investigate. A compensating action should have its own identity and authorization. Retain the original result so that a later reviewer can reconstruct what happened.
How this maps to SAP BTP
Start with the released API for the required SAP business operation and edition. Check the receiving API’s duplicate-handling contract and the available outcome lookup. Build that check into the interface design before adding retry logic.
SAP Cloud Integration has an Idempotent Process Call step. Its documentation also describes the timeout limitation when a receiving application does not acknowledge processing. A middleware duplicate check alone cannot settle whether a business write committed. The proposed workflow therefore keeps a durable action record outside the model and uses authoritative read-back to resolve uncertain outcomes. SAP Idempotent Process Call documentation, SAP receiver duplicate-handling considerations
An SAP Build Process Automation action can expose selected API operations through configured destinations. Limit the action to the operation the workflow needs. Review authentication, application routing and applicable CSRF handling for that path. The destination solves part of connectivity. The SAP backend still needs to enforce the intended business authority. SAP Build action setup, SAP Build API security prerequisites
Where a tenant supports the required Joule skill or agent extension, let it invoke that same narrow business action. Keep the approval, recovery and reconciliation contract consistent across the web application and conversational entry point. Confirm the Joule edition, entitlement and supported integration in the chosen landscape.
The next acceptance run
Use an authorized test environment and force a lost response after the receiver’s commit. Confirm the resulting business document using the supported read API or monitor. Replay the request, change its payload, cancel after dispatch and attempt the action under a restricted role. Check both permitted completion and safe denial.
For each case, retain the approved request, technical response, authoritative document and reconciliation decision. Track duplicate business effects and unresolved outcome age alongside completion time. The outcome of the test should tell an operator what to do when the next timeout happens.
