Workflow

Workerは一定の間隔で変更を確認し、送信元ごとに処理します。管理画面で設定を変えた場合は次の処理から使われるため、実行中に接続先が切り替わることはありません。

1. 01変更に気づく

   業務DBのTriggerが、変更されたレコードをQueueへ知らせます。

2. 02同じ変更をまとめる

   Workerが新しい通知を取り出し、同じレコードの通知をひとつにまとめます。

3. 03いまの値を確認する

   通知された時点の値ではなく、業務DBにある現在の値を読み直します。

4. 04同期先を決める

   どこで起きた変更かを確認し、同期ルールとマッピングを選びます。

5. 05競合がないか確かめる

   前回の値と両システムの現在値を比べ、変換後の値も確認します。

6. 06同期先へ反映する

   同じ変更を二重に書かないよう確認してから反映し、処理結果を保存します。

1回分の処理がすべて片づいたときだけ、読み取り位置（Checkpoint）を進めます。途中で一時的なエラーが起きた場合は位置を変えず、次の処理で同じ場所からやり直します。

Queueに入るのは、「このレコードが変わった」という知らせです。古い変更をひとつずつ再現するのではなく、Workerが処理する時点の値を読み直します。

削除された場合

前回の同期後に同期先のレコードが変更されていた場合は、勝手に削除せず競合として扱います。削除は一部の項目だけに適用できないため、レコードを削除するか残すかを判断します。

SyncCoordinatorが得意なのは、複数システムの「現在の状態」を揃えることです。承認、在庫移動、仕訳のように途中の操作にも意味があるデータは、イベントを省略しない別の連携方式が適しています。

前回保存した値から両方のシステムが同じ項目を変更し、結果が違っている場合に競合と判断します。片方だけが変わっている場合は、そのまま自動で反映します。

管理画面で解決する流れ

1. 違いを確認送られてきた値と、同期先にある現在の値を並べて確認します。
2. 残す値を選ぶ項目ごとに、どちらの値を使うか、または手入力するかを選びます。
3. 解決を依頼管理画面から直接書き込まず、管理DBに解決要求を保存します。
4. 安全を確認して反映Workerが同期先をもう一度確認し、変わっていなければ反映します。

画面を開いてから反映するまでに同期先の値が変わっていた場合は、上書きしません。最新の値を表示して、もう一度選び直せる状態に戻します。

Workerは、どこまで読んだか、どの変更を処理中かをDBに保存します。停止やエラーが起きても、完了済みの変更を二重に反映せず、残っている処理から続けます。

Heldの扱い：競合によるHeldは管理画面から解決できます。値変換や列の検証でHeldになったデータを、管理画面から手動で再実行する機能は現在ありません。

一時停止した場合

一時停止中はQueueも読み取り位置も動かしません。再開すると、停止中に残った通知から現在の値を読み直し、古い状態を順番に再生せず最新状態へ追いつきます。停止前に始まっていた処理は、そのまま完了する場合があります。

一時停止は「あとで続きから再開する」ための運用操作です。システムや同期ルールの無効化は、同期対象から外すための設定であり、同じ意味ではありません。

通知先が一時的に止まっていても、データ同期は続けたい。そのため、Workerは通知をすぐ送るのではなく、まず管理DBに保存し、別の処理でWebhookへ届けます。

Webhookへの送信に失敗しても、同期処理は止まりません。1分、5分、30分、2時間、6時間、12時間と間隔を空け、初回を含めて最大7回送ります。それでも届かなければ通知をFailedにします。同じ通知が届いた場合は、受信側でEvent IDを使って見分けられます。

ふだんの運用では、どこまで同期できているか、エラーや要対応が残っていないかを管理画面で確認します。Webhookの設定と送信履歴も同じ画面から管理できます。