選定主要資料來源

訂明各類紀錄由哪個系統管理,以及哪些系統接收副本。搬移欄位前先對應客戶、產品及訂單識別碼。若兩邊都可修改同一值,應訂明衝突規則,避免最後收到的資料直接覆寫紀錄。

處理收到兩次的訂單通知

網店傳送訂單至會計系統,但確認回覆遺失,同一事件再次到達。固定外部識別碼及處理結果紀錄,讓接收方區分重試與新銷售。

處理收到兩次的訂單通知
傳入事件處理規則
新訂單識別碼驗證必填欄位,建立一次並儲存對應
已知識別碼,相同版本回傳已記錄結果,不再建立發票
已知識別碼,較新更正按明確調整規則處理,歷史保留兩版本
事件身分示例 · 使用固定識別碼,而非客戶姓名
{
  "event_id": "evt_order_1042_v2",
  "order_id": "order_1042",
  "version": 2,
  "type": "order.updated"
}

考慮重試及延遲事件

連接可能在操作成功後、收到確認前失敗。使用識別碼及處理紀錄避免重複訂單或分錄,並考慮事件次序錯亂時如何判斷最新狀態。連接器應顯示失敗項目,而非無聲丟棄。

把對帳變成日常操作

讓員工比較系統間的重要數量或金額並追查不一致,與營運負責人確認重試、更正及升級處理。試驗應包括失敗及歷史資料匯入,而不只是一個為示範準備的成功例子。

進行前先確認

  • 記錄各項共用資料的識別碼及主要來源。
  • 測試重複、延遲及失敗事件。
  • 讓例外項目有可見清單及負責人。

付諸實行