The Outbox Pattern: Both Writes or Neither

The Outbox Pattern: Both Writes or Neither

Your company feeds a webshop: every order registered in Business Central must be announced to the shop. Calling the shop inside the business transaction is a trap — an external call cannot be rolled back. Writing the announcement in a second transaction is the other trap — a crash between the two leaves an order the shop never hears about, or a message about an order that does not exist. The classic answer is the transactional outbox: persist the business row and its outgoing message in one atomic transaction, then let a dispatcher deliver pending messages and mark each one dispatched so that no crash, at any point, can lose a message or deliver it twice.

The starter ships four finished objects. Do not rename them, their fields, or the OnSendMessage event — the grading tests bind to every name below character for character.

The objects you get

• Table "Webshop Order" — primary key "Order No." (Code[20]); fields "Customer No." (Code[20]), Amount (Decimal).
• Table "Order Outbox Entry" — primary key "Entry No." (Integer); fields "Order No." (Code[20]), "Customer No." (Code[20]), Amount (Decimal), Status (enum "Order Outbox Status", defaults to Pending).
• Enum "Order Outbox Status" — values Pending, Dispatched.
• Codeunit "Order Outbox Mgt." — already declares the integration event OnSendMessage(var OrderOutboxEntry: Record "Order Outbox Entry"). This event IS the transport: the grading mock subscribes to it and plays the webshop. Keep its declaration exactly as shipped.

Requirements

Implement the two procedures of "Order Outbox Mgt.":

procedure RegisterOrder(OrderNo: Code[20]; CustomerNo: Code[20]; Amount: Decimal)
procedure DispatchMessages()