はじめに
midPoint by OpenStandia Advent Calendar 2024 の6日目は、5日目で説明しきれなかった下記の1つ目について、補足します。次は組織のインポートについて紹介する予告をしていましたが、組織インポートにおいてもこれは関係してくる話なので、先にこちらの補足記事を書くことにしました。
- 源泉削除に対する同期処理
- マルチバリュー項目に対するマッピング処理
5日目で構築したDocker Composeを利用した環境が前提となります。
源泉削除に対する同期処理
5日目の記事で紹介したように、源泉CSVファイル側で行を削除しても、その内容をmidPointに反映することができていませんでした。これは、「Import Task（インポートタスク）」 という種類のタスクを使用しているためです。同期用のタスクとしては他に、「Reconciliation Task（リコンシリエーションタスク）」 と 「Live Synchronization Task（Live同期タスク）」 があり、それらであれば削除に対する同期処理も可能です。昨日の環境にタスクを追加して、動作を確認してみます。
この3つの同期タスクの違いについては、The Bookの「Synchronization」の章 などで語られています。インポートはその名のとおり、リソースからのインポート用です。なので削除は検知しません。リコンシリエーションはその英単語の意味である「和解」や「調和」が示すように、midPointとリソース間のデータの整合性を解消します。そのため、リソース側の削除も検知します。Live同期は特殊で、リアルタイムな同期を目的としています。差分情報だけmidPointに渡して処理するものであり、その差分として削除情報も渡せるようになっています（ただし、コネクターとリソース側が対応している必要があります）。
リコンシリエーションタスク
リコンシリエーションタスクの作成
昨日の記事で紹介したタスクの作成とはまた別の導線からの作成方法を紹介します。リソースの詳細画面を開き、「定義されたタスク」メニューを開きます。この画面では、このリソースに関連するタスクの一覧を参照・追加などが可能です。すでに昨日、インポートタスクを作成済みですので、それが表示されています。
ここで
アイコンをクリックすると、タスク作成のダイアログがポップアップ表示します。「Reconciliation task」を選択します。
そうするとタスク作成のウィザード画面に遷移しますので、必要な設定を行います。まず、基本設定です。「名前」はタスク全体でユニークである必要があるので、被らないように任意の名前を設定すればよいです。「次へ：リソース・オブジェクト」ボタンをクリックして先に進みます。
-
名前：
HR recon users
リソース・オブジェクトの設定画面が表示されるので、以下を追加設定して「次へ：スケジュール」ボタンをクリックします。今回はタスクの一覧画面から作成を開始しているため、手動で設定する箇所が少し増えています。
-
種類：
アカウント -
用途：
default -
オブジェクトクラス：
AccountObjectClass
リコンシリエーションタスクの場合、「スケジュール」の設定画面が次に表示されます。定期的な実行を時間間隔設定かCronライク書式設定のどちらかで設定可能です。今回は定期実行させないため、未設定のまま「次へ：ディストリビューション」をクリックします。
ディストリビューションの設定画面が表示されます。インポートタスクと同様にワーカースレッド数を設定して、「設定を保存」ボタンをクリックします。
-
ワーカー・スレッド：
1
リソースの編集画面に戻ってきます。今作成したタスクが増えていることを確認できます。
リコンシリエーションタスクの実行
削除同期のパターンを試してみます。CSVファイルから適当な行（例：1001のユーザー）を削除しておきます。
リソースの「定義されたタスク」に表示されている「HR recon users」をクリックして、リコンシリエーションタスクの詳細画面を開きます。
「再開する」ボタンをクリックしてタスクを実行します。
しばらく待つと自動リフレッシュされ、「終了」状態になります。
ユーザー一覧を確認すると、1001のユーザーが消えていることを確認できます。
midPointが記録する監査ログからも確認しておきます。画面左メニューの「監査ログビューザー」をクリックします。
監査ログビューアーより、1001のユーザーが削除されたことを確認できます。
Live同期タスク
Live同期タスクも同様に削除を同期することができます。ただし、3日目の記事の脚注で少し触れていましたが、Live同期は、コネクター側（とリソース側も必要に応じて）が差分抽出に対応している必要があります。CSVコネクターは対応しているため、試すことができます。
CSVコネクターの差分抽出の実装としては、CSVファイルの同ディレクトリに、前回Live同期タスクを実行した際にタイムスタンプ付きのファイル名でコピーを作成しておいて、それと現在のCSVファイルを比較して差分抽出を行っています。
Live同期タスクの作成
リコンシリエーションタスクと同じような流れでLive同期タスクを作成します。「Live synchronization task」を選択します。
-
名前：
HR live-sync users
以下を追加設定して「次へ：スケジュール」ボタンをクリックします。
-
種類：
アカウント -
用途：
default -
オブジェクトクラス：
AccountObjectClass
Live同期タスクもリコンシリエーションタスクと同じで、スケジュール設定の画面が表示されます。ここも同様に、今回は未設定のまま「次へ：ディストリビューション」ボタンをクリックします。
同様に最後にワーカースレッド数を設定して、「設定を保存」ボタンをクリックします。
-
ワーカー・スレッド：
1
リソースの編集画面に戻ってきます。今作成したタスクが増えていることを確認できます。
Live同期タスクの実行
削除同期のパターンを試してみます。ですがその前に、先にタスクの再開を実施しておきます。作成したLive同期タスクの詳細画面を開き、「再開する」ボタンをクリックしてタスクを実行します。そうすると、ステータスのところに「1733384756775」のような値が設定されていることが分かります。これは「同期トークン」というもので、このLive同期タスクの最終実行日時（Unixタイムスタンプのミリ秒）を表しています。
また、hrディレクトリ配下をみると、この同期トークン付きのファイルが増えていることを確認できます。次にLive同期タスクを実行すると、この同期トークン付きのファイルと比較して差分を検知するわけです。
-rw-r-----@ 1 user staff 495B Dec 5 16:45 users.csv
-rw-r----- 1 user staff 495B Dec 5 16:45 users.csv.sync.1733384756775
同期トークンが設定された状態で、CSVファイル（hr/users.csv）から適当な行（例：1002のユーザー）を削除します。
その後、Live同期タスクの詳細画面より「今すぐ実行」ボタンをクリックしてタスクを実行します。
しばらく待つと自動リフレッシュされ、「終了」状態になります。そして同期トークンが更新されたことも確認できます。
ユーザー一覧を確認すると、1002のユーザーが消えていることを確認できます。
同様に監査ログでも確認しておきます。Live同期タスクにより1002が削除されていることを確認できます。
また、hrディレクトリ配下をみると、新しい同期トークン付きのファイルが増えていることを確認できます。古い同期トークン付きのファイルも残っていますが、CSVコネクターの仕様として、デフォルトでこの同期トークン付きファイルを最大10個残すようになっています。
-rw-r-----@ 1 user staff 495 Dec 5 16:56 users.csv
-rw-r-----@ 1 user staff 551 Dec 5 16:45 users.csv.sync.1733384756775
-rw-r----- 1 user staff 495 Dec 5 16:56 users.csv.sync.1733385377951
まとめ
6日目は、5日目で説明しきれなかった 「源泉削除に対する同期処理」 について、補足解説を行いました。インポートタスクでは源泉データの削除について同期することができませんでしたが、他の種類の同期タスクを利用することで、削除同期ができることを紹介しました。
ただし、実際の現場では、HRシステムからCSVで渡される源泉データの形式が複数のパターンに分かれることがあります。例えば次のような場合です。
- パターン1：全量データが渡される
- パターン2：差分データが渡される（HRシステムや中間の配布システムで差分が計算される）
さらに、削除（退職）を表現する方法としては以下のような違いも想定されます。
- パターンA：削除を行削除で表現する
- パターンB：退職ステータスの更新で表現する
もし削除（退職）が行削除で表現されない場合、インポートタスクで十分対応できる可能性があります。仕様上、リコンシリエーションタスクはインポートタスクに比べて処理が重いため、要件を満たすのであれば、より軽量なインポートタスクを選択するのが望ましいでしょう。
次回はもう1点の 「マルチバリュー項目に対するマッピング処理」 について補足解説を行う予定です。お楽しみに！