変更要約: PL-400 第5章を新規作成し参考書を完結（ドメイン: 統合開発）。Dataverse イベントの発行と消費（IServiceEndpointNotificationService・Plug-in Registration Tool での webhook 登録・Azure Service Bus キュー/トピック・Azure Event Hub・リスニング選択肢の使い分け）、Dataverse とのデータ同期（変更追跡 change tracking の差分取得・代替キー alternate keys・UpsertRequest メッセージ）。
5.2Dataverse とのデータ同期
変更追跡（change tracking）による差分取得、代替キー（alternate keys）、UpsertRequest メッセージによる同期を理解します。
外部システムと Dataverse を 効率よく整合 させるには、差分の取得と確実な突合が要ります。
5.2.1変更追跡（change tracking）
変更追跡（change tracking） を有効にすると、前回同期以降に変更された行（差分・delta）だけを効率的に取得できます。毎回全件を取得する必要がなくなり、大規模データの同期が現実的になります。テーブルごとに有効化し、同期処理は前回のトークンを保持して差分を取得します。
5.2.2代替キーと UpsertRequest
外部システムは Dataverse の GUID 主キーを知らないことが多いため、代替キー（alternate keys） を定義し 外部システムのキー（例: 注文番号）でレコードを一意に特定 できるようにします。同期では UpsertRequest メッセージ を使い、キーで存在すれば更新・なければ作成 を 1 操作で行います。これにより「先に Retrieve して分岐」する処理を不要にし、競合や往復を減らせます。
決め手：「前回以降の差分だけ効率取得」＝変更追跡(change tracking)。「外部システムのキーでレコードを特定」＝代替キー(alternate keys)。「存在すれば更新・なければ作成を1操作」＝UpsertRequest。全件取得や先にRetrieveして分岐より効率的。
混同に注意：
①change tracking(差分)と全件取得を取り違えない。
②代替キー(外部キーで特定)とGUID主キーを区別。
③UpsertRequest(存在判定込み1操作)とCreateRequest/UpdateRequest(個別)の使い分け。
④change trackingはテーブルごとに有効化が必要。
5.2.3この節のまとめ
- 変更追跡で前回以降の差分(delta)だけ効率取得(全件取得を避ける)
- 代替キーで外部システムのキーによりレコードを一意特定
- UpsertRequestで存在すれば更新-なければ作成を1操作
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 大規模な Dataverse テーブルを外部と同期する際、毎回全件を取得せず前回以降に変更された行だけを効率的に取得したい。最適なのはどれですか？
Q2. 外部システムが Dataverse の GUID を知らないため、注文番号などの外部キーでレコードを一意に特定したい。最適なのはどれですか？
Q3. レコードが存在すれば更新、なければ作成、という同期を 1 回の操作で行いたい。最適なメッセージはどれですか？
Q4. 変更追跡（change tracking）を使う際に正しい前提はどれですか？
Q5. UpsertRequest と CreateRequest/UpdateRequest の違いとして正しいのはどれですか？