この参照アーキテクチャでは、Power Platform でPower Automateとデータフローを使用して、2 つの Dataverse 環境間でマスター データを同期する方法を示します。 これは、1 つの環境が権限のあるソースとして機能し、別の環境がデータを受信する 1 対 1 の同期パターンを示しています。
ヒント
この記事では、1 つの Dataverse 環境でマスター データを維持し、別の環境に同期する方法を示すシナリオの例と一般化されたアーキテクチャ例を示します。 アーキテクチャの例は、さまざまなシナリオや業界に合わせて変更できます。
アーキテクチャ ダイアグラム
Workflow
次の手順では、アーキテクチャ図の例に示すワークフローについて説明します。
Power Automate によるイベント駆動型同期
プライマリ Dataverse 環境での CRUD (作成、読み取り、更新、削除) 操作は、Power Automate フローをトリガーします。
イベント ドリブン同期では、次の 2 段階のフロー チェーンが使用されます。
- クラウド フローは、発行されたエンドポイントに HTTP POST を送信します。
- サブスクライバー クラウド フローは Webhook によってトリガーされ、ペイロードが処理され、セカンダリ Dataverse 環境でほぼリアルタイムで更新が適用されます。
エンドポイントはアプリケーション ライフサイクル管理 (ALM) 用にパラメーター化され、セキュリティ グループはアクセスを管理します。
データフローによる一括同期
セカンダリ Dataverse 環境には、データフローが含まれています。
各データフローは、データ ソースとしてプライマリ Dataverse 環境に接続します。
データフローは、固定スケジュール (夜間や別のデータフローが正常に実行された後など) またはオンデマンド (初期セットアップなど) で実行されます。
アップサートは、重複を回避するために代替キーを使用して実行されます。 このメソッドは、既存のデータを更新し、一致するものがない場合に新しいレコードを挿入します。
状態フィールドは、専用の "同期状態" 列を使用して管理されます。 Power Automate フローでは、実際の状態フィールドが適宜更新されます。 このフローはデータフローの後に実行され、データフローはプライマリ Dataverse 環境で行の状態を変更したり、削除された (存在しない) レコードを削除したりできないために必要です。
エラー処理と調整
セカンダリ環境の夜間データフローは、見逃されたまたは失敗したイベントドリブン更新を修正します。
データ品質の問題 (キーが見つからないなど) には、手動による介入が必要になる場合があります。
Components
Microsoft Dataverse: 2 つの環境要件をサポートします。
Power Platform のデータフロー: 初期データの作成や同期などの一括操作に最適です。 セカンダリ環境で構成されたスケジュールされた同期には、一括抽出、変換、読み込み (ETL) を使用します。
Power Automate クラウド フロー: 高速でレコード固有の更新を提供し、データフローの制限を補正します。 クラウド フローは、別のデータフローが正常に完了したときにデータフローをトリガーできます (たとえば、あるテーブルに別のテーブルへのルックアップ フィールドが含まれており、その参照先レコードがセカンダリ Dataverse 環境に既に存在している必要がある場合など)、データフローが失敗したときにエラー メッセージを送信し、レコードの状態を更新し、レコードを削除します。
セキュリティ グループ と サービス アカウント: アクセスの管理と所有権を提供します。
シナリオの詳細
このアーキテクチャは、1 対 1 のリレーションシップ (別の単一の環境にリンクされた 1 つのマスター データ管理 (MDM) 環境) 向けに設計されています。 1 つのマスター環境を他の複数の環境と同期する必要があるシナリオでは、よりスケーラブルなソリューションまたは分散ソリューションが必要です。
ビジネスの課題
このソリューションは、2 つの異なる Dataverse 環境間で複数のテーブルを同期する課題に対処します。 プライマリ環境は権限のあるソースとして機能しますが、セカンダリ環境にはマスター データを設定して更新する必要がある既存のテーブルが含まれています。
セカンダリ システムのテーブルが既に存在し、行レベルのセキュリティが必要な場合、仮想テーブルを使用することはできません。
ユースケースの例
レジャーとホスピタリティの組織は、専用の Dataverse 環境で、ホテルや部屋の在庫などの主要なマスター データを管理します。 プライマリ環境には、マスター データ管理チームが専用に使用し、正確かつ最新の運用情報を維持するためのモデル駆動型アプリが含まれています。
同じ組織内の別の部門が、いくつかの財務および調整プロセスを担当します。 これらのプロセスを合理化するために、部門は分離された Dataverse 環境で独自のモデル駆動型アプリを構築したいと考えています。 ただし、そのアプリケーションでは、ホテルや部屋の詳細などの基本的なマスター データに引き続きアクセスする必要があります。
財務チームは、厳密な行レベルのセキュリティによって管理される部門固有の属性でレコードを強化する必要があるため、チームは仮想テーブルを拒否しました。
プライマリ MDM 環境内に金融アプリを埋め込むのも選択肢ではありません。 財務作成者または管理者に MDM 環境へのアクセスを許可すると、コネクタ、ソリューション、API のアクセス許可、および MDM 開発チームに制限される必要がある機密データが公開されます。
これらの要件により、組織はこの記事で説明する同期アーキテクチャを採用しました。
作成された値
このアーキテクチャは、仮想テーブルがオプションではない場合に、2 つの Dataverse 環境間でマスター データを同期するための堅牢で保守可能なソリューションを提供します。 セカンダリ環境で既存のテーブルを直接設定および更新することで、データの一貫性と運用の信頼性が確保されます。
このアプローチでは、データフローやPower Automateなどの Power Platform コンポーネントのみを使用するため、デプロイが簡単で、管理が簡単で、不要な複雑さが回避されるソリューションになります。
アーキテクチャは 1 対 1 の環境リレーションシップに合わせて調整されているため、オーバーヘッドを最小限に抑え、透明性を最大化します。 大規模なマルチ環境管理なしで、簡単で信頼できるマスター データ同期を必要とする組織に最適です。
考慮事項
これらの考慮事項は、ワークロードの品質を向上させる一連の基本原則である Power Platform Well-Architected の柱を実行します。 詳細については、Microsoft Power Platform Well-Architected を参照してください。
Reliability
夜間のデータフローにより、一貫性が確保されます。
イベント ドリブン フローでは、高速な更新が提供されます。
手動監視では、データ品質の問題が検出されます。
セキュリティ
アクセス制御用のサービス アカウントとセキュリティ グループ。 データフローを使用する場合、サービス プリンシパルを所有者として割り当てることはできません。
ALM 互換性のためのパラメーター化された HTTP エンドポイント。
不要な手動作業を回避するための分離ソリューションのデータフロー。 専用ソリューションでデータフローを分離する特定の理由があります。デプロイのたびに、データフロー接続を手動で再確立する必要があります。 データフローを変更した場合にのみデプロイする別のソリューションにデータフローを配置することで、メイン ソリューションの他のコンポーネントをデプロイするときに不要な手動作業を回避できます。
オペレーショナル エクセレンス
データフローの自動スケジューリングとオーケストレーション。
失敗した同期の監視とアラート。
パフォーマンス効率
一括操作用に最適化されたデータフロー。
イベント ドリブンのPower Automate フローにより、重要なレコード レベルの更新の待機時間が最小限に抑えられます。 イベント ドリブン フローを設計するときは、アクションボリュームとコンカレンシーがサービスの制限Power Automate範囲内に留まるようにします。 頻繁な CRUD アクティビティは、特にフローが 1 日に数万のアクションを実行するシナリオで、スロットリングを引き起こす可能性があります。 ビジネスクリティカルまたは高スループットの統合については、適切なPower Automateライセンスを適用してスループット制限を引き上げ、予期しないスロットリングを回避します。 このアプローチにより、エスカレーション リスクが軽減され、予測可能なパフォーマンスが保証されます。
エクスペリエンスの最適化
最小限の手動介入が必要です。
一括同期とイベント ドリブン同期を明確に分離します。
Contributors
Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。
作者代表: