この記事では、米国に拠点を置く架空の顧客である Contoso が、ヨーロッパに拠点を置く別の会社を最近買収し、2 つの企業間で CRM と ERP システムの処理中であるシナリオについて説明します。 この統合の一環として、完全に統合できるようになるまで、Dynamics 365 Dataverse エンティティの一部を同期しておく必要があります。 Conotso 独自の基幹業務 (LOB) アプリは、両方のシステムのデータを使用し、データが同期を待機しているとき、またはないときに要求を受け入れることができるようにする必要があります。 次のガイドでは、Power Platform インスタンス間の最終的な一貫性を実現する方法を示します。
アーキテクチャ
GUID または代替キーに基づいて常にアップサートするプラグイン/フロー
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
このソリューションは、プラグインのライフサイクル内で、いくつかのプラグイン ステップで構築できます。 作成するエンティティが必須のときは、PreValidation ステップを使用してください。 PreValidation は、データベース トランザクションが開始される前に行われます。 フィールドが必須の場合、これが推奨されるオプションです。 ただし、シナリオによっては、PreCreate プラグイン ステップで十分です。
- 米国のインスタンスは、ロジック アプリを介して新しいアカウントをヨーロッパのインスタンスに同期しようとします。 ダウンタイムまたはアップグレードにより、ヨーロッパのインスタンスに到達できません。
- Contoso LOB アプリは、米国のインスタンスからメイン アカウント エンティティを読み取ります。 ヨーロッパのインスタンスにレプリケートされなかったアカウント エンティティを参照する API 呼び出しを送信しようとしています。 現状では、API 呼び出しは失敗します。同期が機能していないことが原因で、レコードが存在しないためです。
- ただし、PreValidation/PreCreate プラグインは、最初に、指定されたエンティティ GUID と指定された参照データに基づいて upsert を実行します。 既に存在する場合は、何も変更されません。 存在しない場合は、ほとんどのフィールドが空白の新しいアカウントが作成されます。
- 指定された ID のアカウントがシステムに存在するので、API 呼び出しは成功します。 プラグインは操作をインターセプトし、欠落レコードを適切に処理しました。 LOB アプリケーションからのレポートが正常に生成されます。
注意
Microsoft では、カスタム コードにサーキット ブレーカー パターンを導入して、いずれかのインスタンスを参照するときにプラットフォームの停止に対処するために、このソリューションの一部としてバックオフして再試行することをお勧めします。 サーキット ブレーカーの使用の詳細については、「サーキット ブレーカー パターン」を参照してください。
代替
上記のシナリオでは、レプリケーション方法としてカスタムのロジック アプリを使用します。 ただし、Dataverse インスタンス間でデータをレプリケートする方法は複数あります。これには、次のものが含まれますが、それらに限定されません。
- Logic Apps
- Azure Functions の関数アプリ
- Azure Data Factory
- Azure Synapse Analytics
- Power Automate
シナリオの詳細
組織では、2 つ以上の Power Platform インスタンスの同期を維持しなければならない場合があります。具体的には、通常は Dataverse エンティティのサブセットです。 この要件は、組織が地理的な分離のために新しいインスタンスを意図的に追加したが、すべての地域で共通のデータセットを必要とするときに発生することがあります。 または、Power Platform の統合が完了する前に、2 つの組織が合併したときに発生することもあります。
同期プロセスが設計どおりに機能するときは、両方のインスタンスから使用する基幹業務アプリケーションに問題は生じません。 ただし、同期メカニズムは決してエラープルーフではありません。障害や予期しない問題が発生する場合がよくあります。 その場合、両方のインスタンスのデータを使用する基幹業務アプリケーションは、不完全なデータを処理するように構築する必要があります。
Contoso の新しいヨーロッパ子会社を Contoso のビジネス構造に統合するには、アカウントと連絡先を Power Platform のインスタンス間で同期する必要があります。 このシナリオでは、Power Platform の米国のインスタンスは、カスタム ロジック アプリを介して参照データの毎日のバッチをヨーロッパのインスタンスに同期します。 Contoso の独自の LOB アプリは、ユーザーが作成した問題のチケットに関するレポートを生成します。 このタスクを実行するために、LOB アプリは両方の Dataverse インスタンスからユーザー データを読み取って、関連するデータ、米国のインスタンスのプライマリ参照キー、ヨーロッパのインスタンスのチケット データをプルします。 ダウンタイム、メンテナンス、または別の通信の問題が原因で同期プロセスが完了していない場合、要求で、ヨーロッパのインスタンスにエンティティがないためにエラーが発生します。
考えられるユース ケース
このパターンは次の状況で役に立ちます。
- 参照データを送信するシステムがダウンしている。
- データの同期に時間がかかる、またはプロセスが遅延している。
- 作成されるエンティティの作成に関するロジックが消費システムにない。
このアプローチを使用する状況
このアプローチは次のシナリオで使用します。
- 特定のキーのレコードが必ず存在する必要があり、そのレコードにハイドレートされていない部分があってもかまわない。
- データがまだ同期されていなくても、作成を受け入れる必要がある。
このパターンは、次のシナリオでは適していない可能性があります。
- レコードの作成時にロジックが適用される。 データはハイドレートされないため、使用可能な特定のプロパティに依存することは安全ではありません。
使用例
以下の例では、考えられる体験と同期の遅延の結果を示しています。
例 1 - 停止や一時的なエラーが発生していない成功パス
このアーキテクチャの Visio ファイルをダウンロードします。
- 米国のインスタンスは、ロジック アプリを介して新しいアカウントをヨーロッパのインスタンスに同期します。 一時的な障害や停止が発生していないため、すべてが機能しています。
- Contoso LOB アプリは 米国のインスタンスからメイン アカウント エンティティを読み取り、ヨーロッパのインスタンスにレプリケートされたアカウント エンティティを参照する API 呼び出しを送信しようとしています。 これは、すべてが動作していて、停止や一時的な障害が発生していないため機能します。 LOB アプリケーションからのレポートが正常に生成されます。
例 2 - 同期がダウンまたは遅延している失敗パス
このアーキテクチャの Visio ファイルをダウンロードします。
- 米国のインスタンスは、ロジック アプリを介して新しいアカウントをヨーロッパのインスタンスに同期しようとします。 ダウンタイム、メンテナンス、またはその他の通信の問題により、ヨーロッパのインスタンスに到達できません。
- Contoso LOB アプリは 米国のインスタンスからメイン アカウント エンティティを読み取って、ヨーロッパのインスタンスにレプリケートされなかったアカウント エンティティを参照する API 呼び出しを送信しようとしています。 特定の ID のアカウントがヨーロッパのインスタンスに作成されてなく、レポートが生成されないため、API 呼び出しは失敗します。
考慮事項
まだハイドレートされていないエンティティに対するビジネス ロジックの影響を考慮してください。 エンティティがまだ完全にハイドレートおよび同期されていないシナリオを考慮してください。 プロパティの一部は null になります。そのため、このアプローチを使用する場合は、データに関する決定を考慮に入れておく必要があります。
次のステップ
関連リソース
関連アーキテクチャ
Web 開発のガイダンス: