選定主要資料來源
訂明各類紀錄由哪個系統管理,以及哪些系統接收副本。搬移欄位前先對應客戶、產品及訂單識別碼。若兩邊都可修改同一值,應訂明衝突規則,避免最後收到的資料直接覆寫紀錄。
處理收到兩次的訂單通知
網店傳送訂單至會計系統,但確認回覆遺失,同一事件再次到達。固定外部識別碼及處理結果紀錄,讓接收方區分重試與新銷售。
| 傳入事件 | 處理規則 |
|---|---|
| 新訂單識別碼 | 驗證必填欄位,建立一次並儲存對應 |
| 已知識別碼,相同版本 | 回傳已記錄結果,不再建立發票 |
| 已知識別碼,較新更正 | 按明確調整規則處理,歷史保留兩版本 |
{
"event_id": "evt_order_1042_v2",
"order_id": "order_1042",
"version": 2,
"type": "order.updated"
}考慮重試及延遲事件
連接可能在操作成功後、收到確認前失敗。使用識別碼及處理紀錄避免重複訂單或分錄,並考慮事件次序錯亂時如何判斷最新狀態。連接器應顯示失敗項目,而非無聲丟棄。
把對帳變成日常操作
讓員工比較系統間的重要數量或金額並追查不一致,與營運負責人確認重試、更正及升級處理。試驗應包括失敗及歷史資料匯入,而不只是一個為示範準備的成功例子。
進行前先確認
- 記錄各項共用資料的識別碼及主要來源。
- 測試重複、延遲及失敗事件。
- 讓例外項目有可見清單及負責人。



