What you will learn
Section titled “What you will learn”Plan duplicate handling and recovery before automation.
Prerequisites: IFS Cloud essentials. The runbook needs an authorized development environment and one controlled integration message. Estimated reading time excludes practice.
Step-by-step: diagnose and recover one failed message
Section titled “Step-by-step: diagnose and recover one failed message”Use this runbook with one development message and an approved read/status operation. A production retry can create business effects, so establish the last confirmed state before sending anything again.
1. Freeze the evidence and stop uncontrolled retries
Section titled “1. Freeze the evidence and stop uncontrolled retries”Pause only the affected sender/consumer where your operational procedure permits it. Save a sanitized record containing the stable message ID, business reference, UTC submission time, endpoint/operation, caller identity label, HTTP status, response/error, and application-message or workflow ID.
Keep the original input unchanged. Record each correction as a new attempt linked to the original business request; do not overwrite the only copy of the failing payload.
2. Locate the last confirmed boundary
Section titled “2. Locate the last confirmed boundary”Trace the request in order: sender validation, token acquisition, gateway receipt, route/transformer, IFS business execution, and acknowledgement. For IFS Connect, open Application Messages and inspect the message, selected route, transformer result, and error. For a direct projection call, use its response and approved request logs.
Write one statement such as “IFS accepted message X, but the transformer rejected the date field.” That identifies a different recovery stage from “the business record exists, but the HTTP response was lost.”
3. Classify the failure before retrying
Section titled “3. Classify the failure before retrying”| Evidence | Recovery |
|---|---|
| Invalid JSON/schema/business key | Correct the data and validate a new attempt |
| 401 | Fix/renew the intended identity credential |
| 403 | Review the exact required grant/scope; do not retry unchanged |
| 429 | Respect the provider’s retry contract and Retry-After where supplied |
| 5xx before confirmed execution | Bounded retry only if operation contract makes replay safe |
| Timeout/disconnection after submission | Treat outcome as unknown and reconcile first |
| Acknowledgement received but archive/move failed | Repair the sender bookkeeping, not the IFS business write |
Do not infer “nothing happened” from the absence of a response.
4. Reconcile by the business request key
Section titled “4. Reconcile by the business request key”Use the supported lookup/status endpoint to search for the original external reference. Check both an in-progress message and the final business object where the contract is asynchronous. Compare key fields and quantities, not merely the existence of a similarly named record.
If exactly the intended result exists, mark the sender’s attempt reconciled and save its IFS key. If the result is absent and the contract proves no in-flight work remains, authorize one retry. If the result is ambiguous or multiple candidates exist, place it in a manual-review state.
5. Prove duplicate prevention with a controlled fixture
Section titled “5. Prove duplicate prevention with a controlled fixture”Send the same lab message twice with the same stable request ID. Verify that the second attempt returns/references the original result or produces an explicit duplicate response. Two records are a failed acceptance test.
A separate “check then create” sequence is not atomic under concurrent requests. Require a receiver-side unique key, atomic claim, or a supported idempotent operation before enabling concurrent workers. A made-up Idempotency-Key header has no effect unless the receiver implements it.
6. Resume gradually and document closure
Section titled “6. Resume gradually and document closure”After fixing the cause, replay one reviewed message and inspect its business result. Then resume a small batch with monitoring, bounded attempts, and an escalation destination for exhausted retries.
Update the acceptance matrix with actual observed results, including malformed input, permission denial, duplicate, and timeout/reconciliation cases. Remove lab data through supported business actions and retire temporary diagnostics after the agreed retention period.
For a concrete sender with a local replay guard, work through the middleware lab. It illustrates the state transitions, while a production system still needs durable shared coordination.
The concept
Section titled “The concept”An integration needs more than a successful request. Define how the sender identifies work, how the receiver handles duplicates, and how the operator discovers failures. These are design questions; the correct implementation depends on the selected IFS API and business operation.
A worked scenario
Section titled “A worked scenario”A handover is sent, but the caller times out before receiving a response. The caller cannot conclude whether the receiver committed it. Sending the same operation again can create a duplicate unless the contract provides an appropriate way to recognize repeated work.
Work through it
Section titled “Work through it”- Choose a correlation identifier for tracing the same operation across systems.
- Document which failures may be retried and which need correction.
- Establish a supported duplicate-detection or reconciliation strategy.
- Define an operator queue or report for unresolved work and a responsible owner.
Try it yourself
Section titled “Try it yourself”Write a recovery decision for a request that times out after sending data.
See a suggested answer
Mark the outcome as unknown. Reconcile using a supported business identifier or operation status before retrying a non-idempotent action. Use bounded retries only where the contract makes them safe. Keep credentials out of diagnostic records.
Check your understanding
Section titled “Check your understanding”Retrying every error indefinitely. A validation failure normally needs corrected input; a permission failure needs an access investigation.
Expected result: a written answer that explains your decision and identifies what still needs confirmation in the actual environment.
Cleanup: none; this exercise changes no IFS data.
Sources and review status
Section titled “Sources and review status”IFS Cloud 26R1 documentation. Source consulted 2026-09-23. The scenario and exercise are original fictional examples. This concept draft has not been reviewed by an IFS specialist or executed in an IFS environment.
Apply this lesson in the handover-reference project.
Diagnose one failing boundary at a time
Section titled “Diagnose one failing boundary at a time”Capture a redacted request record containing environment, UTC time, correlation ID, operation, caller identity label, response status, and the last confirmed business state. Do not start by increasing every timeout or replaying a whole failed batch.
Check DNS/TLS and reachability first when no HTTP response exists. With a response, distinguish identity failure, permission/business scope, schema mapping, and business validation. For Connect routes, follow routing selection, transformation output, message processing, and the final business result separately. HTTP acceptance and queued delivery are intermediate evidence.
Compare one working fictional fixture with one failing fixture, changing a single relevant input at a time. Check null versus missing, decimal/date formats, encoding, and zero/one/many records. After a timeout, reconcile by the stable request key before retrying writes.
Use request tracing to reconstruct the operation, XSLT tests to isolate mapping, and monitoring to identify patterns across runs. The acceptance matrix records expected results separately from observed evidence.