Why your Business Central job queue needs idempotent external effects when integrating external systems.
Job queue entries that call external APIs risk duplicating actions when AL transactions roll back after an external call succeeds. Use the outbox row's SystemId as a stable idempotency key that the external system enforces to prevent duplicate exports, payments, or shipments on retry.
post Stefano Demiliani
Key points
- AL transaction rollback does not undo external API calls, creating a gap between database state and real-world side effects.
- The anti-pattern is calling external APIs before updating local records; if the local update fails, the row retries and sends the same request again.
- External systems must deduplicate requests using a stable idempotency key (like the outbox row’s SystemId) that exists before the API call.
- Delete operations require treating certain response codes (like 404) as success and deleting the local row only after the external call confirms completion.
- Idempotency must be enforced by the external API itself; a local flag set after the call rolls back with everything else on failure.
AL objects mentioned
As named in the post. A name that matches one object page by exact type and name links to it; the others stay as named.
- table “Queued Export Bad”
- codeunit “Queued Export Worker Bad”
- table “Queued Export Good”
- codeunit “Queued Export Worker Good”
Not found in BC28-30: table “Queued Export Bad”, codeunit “Queued Export Worker Bad”, table “Queued Export Good”, codeunit “Queued Export Worker Good”.
Context
- Features: job queue retry, HTTP client, idempotency key, transaction rollback, outbox table, SystemId, external system integration
Source: Stefano Demiliani, community blog. Summary, key points and quotes are derived (CONTENT-NOTICE.md); read the original for the full text.