{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":50933,"path":"source-to-pay-operations/supplyon-error-handling.md","title":"SupplyOn error handling and retry","bundle":null,"doc_type":null,"release":"australia","body":"\n# SupplyOn error handling and retry\n\nError handling in the SupplyOn integration uses a layered model that includes transport-level HTTP retry, status and message updates, integration error tasks, and retrigger paths.\n\nError handling is layered: a transport-level HTTP retry at the connection, then the S2P integration framework paradigm, rather than a custom retry loop.\n\n-   **Transport-level HTTP retry** Both aliases reference the out-of-box Default HTTP Retry Policy, which every Flow Designer REST step using the alias honors automatically. A qualifying failed call is retried up to three times at a fixed 10-second interval before the failure reaches flow logic. The retry conditions are idempotency-aware.\n-   **Set status and message** On failure, the flow sets the staging record integration status to 40 \\(Failed\\) and populates the message field. The status write is a direct field write, which still fires the framework business rule.\n-   **Error task creation** The framework async business rule Handle status change fires on status 40 and creates an integration error task \\(`sn_shop_erp_error_task`, subtype purchase\\_order\\) assigned to the buyer. On a successful update that carries a non-empty erp\\_number, the same rule closes active error tasks. Inbound \\(confirmation pull\\) errors create an unassigned, group-routed error task instead.\n-   **Retrigger paths** Re-clicking Create PO resubmits the order \\(closes error tasks, re-runs dispatch, and changes Draft to New, which re-fires the outbound trigger\\). Run job re-runs the confirmation pull.\n-   **Late callback recovery** The send subflow waits up to 24 hours for the callback. On timeout, the row is marked 40. The SON-TXN correlation token is preserved in the message, so a late callback can still reconcile the row from 40 to 30.\n-   **Confirmation pull retry**. Because the pull re-runs on schedule with an overlapping look-back window and a high-water mark, a transient failure recovers on the next scheduled run.\n\n|HTTP method|Retry conditions|\n|-----------|----------------|\n|GET \\(confirmation pull\\)|HTTP 408 \\(request timeout\\), 429 \\(too many requests\\), or a connect-timeout exception.|\n|POST, PUT, DELETE \\(outbound POST\\)|Connect-timeout exception only. Not retried on 408, 429, or 5xx, to avoid double-submitting an order.|\n\n**Note:** A SupplyOn-returned 4xx or 5xx on the POST is not retried at the transport layer. It passes directly to the Failed handling \\(status 40\\). A transient connectivity blip is handled transparently.\n\n"}}