Routing, callouts, and error handling
Domain 5 - Routing, callouts, and error handling
This domain tests conditional routing, outbound calls, and fault handling. The exam wants you to keep failures visible, avoid duplicate side effects, and return useful responses.
Core rules
- Use Switch for conditional branches inside an orchestration. Give every Switch a default or otherwise handle unmatched cases. Basic Routing can route by content when the flow is simple.
- A callout is an outbound request to an external service. Use an Invoke when the response must be mapped into the flow; use the Callout activity where the style supports a notification or callback pattern. Set timeouts and consider idempotency.
- Fault handling can be local to a Scope or global to the integration. A fault handler can log, transform an error response, notify, or rethrow. Rethrow when the caller or monitoring must see the failure.
- Distinguish business faults (for example, a rejected order) from technical faults (timeout, 401, schema error). Return business faults deliberately; let technical faults surface unless you can recover.
- Retries help with transient errors but can duplicate non-idempotent calls. Use a retry policy only when the operation is safe to repeat, or add a correlation key.
Worked example
A REST trigger invokes an ERP service. If ERP returns 404, create the record instead. If ERP returns 500, retry once, then route to a global fault handler that returns HTTP 502 and logs the correlation ID. Do not catch the 500 and return 200, because the caller would believe the order succeeded.
Traps
A fault handler that swallows an error hides failed instances. A Scope fault handler does not cover errors outside its scope. Retrying a payment or order creation can create duplicates. A Switch without a default can leave a message unrouted.