Workflow Reliability Lab
Try repeatable demonstrations of repeated payment messages, failed transfers and cancellations. Inspect the model’s event log using synthetic data.
How to use this resourceA message arrives twice. What happens next?
Run three small simulations of a connected order workflow. Inspect the event log and the result, then repeat the same test.
An owned teaching model with synthetic data. It calls no payment, accounting or delivery services. Results describe this model, not a live client system or a performance benchmark.
Model result
Repeated payment message
- A verified payment event arrives for DEMO-1042. The model records the event and creates one fulfilment record.
- The same event arrives again. Its existing identifier is recognised; the second message creates no additional record.
Two deliveries of the same message, one fulfilment record. In production, signature verification, durable storage, concurrent events and recovery still need implementation and testing.
Transfer fails, then retries
- The payment event is accepted. The first simulated transfer fails before the receiving system commits a record.
- The transfer remains pending. A retry uses the same operation identifier; the simulated receiver creates one record.
- The acknowledgement returns and the pending operation is marked complete.
One failed attempt, one successful retry, one fulfilment record. If a real receiver commits but its acknowledgement is lost, its state must be checked before retrying.
Cancellation before a delayed message
- A cancellation is recorded for DEMO-1042 before any fulfilment record is created.
- A delayed payment event arrives. The model checks the order’s current cancellation state and holds it for review.
No fulfilment record is created; the order needs review. This model does not issue a refund or decide the commercial outcome. Those require the agreed business rules and authorised actions.
This lab demonstrates three decisions in a connected order workflow. All records are synthetic, every run starts from the same state, and the model makes no network calls. The event log explains why a record is created, held or ignored.
The method
The model holds one synthetic order, a set of received event identifiers and a list of transfer operations. A repeated event identifier is ignored. A failed transfer remains pending for a retry. A cancelled order is checked before creating a fulfilment record.
You can inspect the executable reference model. The browser tool and the automated checks use this same model. The results below are model outputs, rather than measurements from a client’s production system.
Repeated payment message
Input: deliver the same synthetic payment event twice. Expected result: one fulfilment record. The model recognises the event identifier on its second arrival. A production implementation also needs verified incoming messages, durable records and safe handling of concurrent arrivals.
Transfer fails, then retries
Input: fail the first transfer before the simulated receiver commits anything, then retry with the same operation identifier. Expected result: one fulfilment record and a completed operation. This example deliberately separates a known failure from an uncertain outcome.
If a real service commits a record but its acknowledgement never reaches you, a retry could duplicate work. Check the receiver’s state or use its supported idempotency mechanism before repeating the action. The right recovery depends on the receiving service and the business rules.
Cancellation before a delayed payment message
Input: mark the synthetic order cancelled, then deliver a delayed payment message. Expected result: no fulfilment record and a review flag. The current order state takes priority over an older message.
The model does not issue a refund, cancel a real delivery or choose a commercial outcome. Those actions require the agreed policy, authorised staff and the actual service state.
What this model leaves out
It does not test a provider’s API, signatures, credentials, database transactions, network races, load, refunds, accounting rules or access controls. Its in-memory state disappears on reset. It is a teaching aid for discussing an implementation, not a production integration library.
How this relates to our work
The public MTE Xpress and BigBore cases describe delivered connections and management tools. This lab is an independent Cloudfusion demonstration. It does not disclose a client incident or claim that a client system behaves exactly like this model.
Use the Systems Connection Planner to map your own handover, or explore our integration and automation service to discuss a scoped implementation.