エンタープライズ ソリューションでは、Dataverse でデータの変更が発生したときにメッセージを確実に配信する必要があります。 この参照アーキテクチャでは、Dataverse でトランザクション 送信トレイ パターンを実装し、メッセージ損失のリスクを軽減し、統合システムの同期を維持する方法を示します。
Tip
この記事では、Dataverse から信頼性の高いイベント配信を実装する方法を示すシナリオ例と一般化されたアーキテクチャ例を示します。 アーキテクチャの例は、さまざまなシナリオや業界に合わせて変更できます。
アーキテクチャ ダイアグラム
Workflow
次の手順では、アーキテクチャ図の例に示されているワークフローについて説明します。
- Dataverse で、連絡先レコードの作成や更新などのデータ操作が行われます。 この操作により、データベース トランザクションが作成されます。
- Dataverse 同期プラグインは、このイベントに応答してトリガーされ、同じトランザクションの一部として Dataverse 内の送信トレイ テーブルにレコードを作成します。
- プラグインが正常に実行されると、トランザクションは outbox レコードと元のレコード (連絡先など) の両方の変更をコミットします。
- プラグインの実行が失敗した場合、元のデータ イベントはロールバックされ、Dataverse はレコードの変更をコミットしません。
- 非同期プラグインは、Dataverse の送信トレイ テーブルにレコードが作成された場合に応答してトリガーされ、メッセージをAzure Service Busキューまたはトピックに書き込みます。
- メッセージ コンシューマーは、メッセージを受信して処理し、ターゲット システムにプッシュします。
Components
Dataverse は、データ イベントが発生し、送信トレイ テーブルが存在する基幹トランザクション システムです。 プラグインを使用してメッセージ ブローカーに非同期的にメッセージを送信します。
Azure Service Busは、受信側システムで処理するためのメッセージを Dataverse から受信する信頼性の高いエンタープライズ ブローカーです。
- キューは、メッセージの受信者が 1 人しかいない場合に最適です。
- トピック は、多くのサブスクライバーが同じメッセージを処理する場合や、メッセージを選択的に処理するためにフィルター条件が必要な場合に最適です。
Azure Monitorは、クラウドとオンプレミスのソリューションから監視データを収集、分析し、それに対応するための包括的な監視ソリューションです。 キューまたはトピック、または配信不能キュー内のメッセージ数を監視するには、Azure Service Busに組み込みのメトリックを使用します。
Azure アプリケーション Insights は、アプリケーション パフォーマンスの監視に使用され、Dataverse プラグインに対して有効にすることで、トレース ログを Application Insights ワークスペースに送信できます。
代替オプション:
- Azure Logic Apps: メッセージのオーケストレーションと配信をトリガーするタイミングをより正確に制御したい場合に、送信トレイ テーブルからメッセージ ブローカーにメッセージを配信するための、実用的なローコードの代替手段です (マイクロバッチ処理など)。
- Azure Functions: より高いボリュームと断続的な障害時の再試行を処理するための最大の柔軟性とスケーラビリティを提供する、コード優先の代替手段です。
シナリオの詳細
エンタープライズ ソリューションでは、多くの場合、メッセージを介して重要なデータを他のシステムと交換する必要があります。 システム間の整合性を確保するには、データ操作とメッセージ配信を 1 つのアトミック操作として処理してください。 ただし、ほとんどのトランザクション システムとメッセージ ブローカーは、分散トランザクションをほとんどサポートしないか、避けたい密結合を導入します。 分散トランザクションがないと、トランザクションのコミット後にブローカーにメッセージを送信するときにエラーが発生する可能性があるため、信頼性の保証はありません。
トランザクショナル アウトボックス パターンは、ビジネス データを更新する同じローカル データベース トランザクション内でメッセージを作成することで、この課題を解決します。 別のプロセスで、アウトボックス テーブルからメッセージ ブローカーにメッセージを配信できます。 断続的なプロセスの失敗は問題ではありません。 送信トレイ テーブルにはメッセージが格納されるため、メッセージは失われず、プロセスは成功するまで再試行されます。
Dataverse は、重要な送信統合シナリオにこのパターンを実装できるトランザクション データ ストレージを備えた、高機能で拡張可能なローコード データ プラットフォームです。
Considerations
これらの考慮事項は、ワークロードの品質を向上させる一連の基本原則である Power Platform Well-Architected の柱を実行します。 詳細については、Microsoft Power Platform Well-Architected を参照してください。
Reliability
このパターンにより、トランザクションの一貫性を確保することで、信頼性が大幅に向上し、少なくとも 1 回の配信が保証され、最終的な整合性が保証されます。 メッセージ ブローカーに依存することで、ソース システムとターゲット システム間のデータ フローを制御することでダウンストリーム システムが圧倒されないように保護し、ダウンストリーム システムの可用性の問題から保護します。
メッセージの順序付けが必要な場合は、キューまたはサブスクリプションでAzure Service Busセッションを有効にします。 プロデューサーは、Dataverse レコードや集約 ID などの一貫性のある SessionId を関連メッセージに割り当てて、そのセッション内で順番に処理されるようにする必要があります。 このパターンは少なくとも 1 回の配信を提供し、重複するメッセージが発生する可能性があるため、べき等処理になるようにコンシューマーを設計してください。 欠落しているイベントまたはシーケンス外のイベントを検出することが重要な場合、メッセージにはアプリケーション レベルのシーケンス番号を含めることができます。 順序付けの保証は、グローバルではなくセッション内で適用されます。ソリューションでは、再試行と配信不能メッセージがそのセッションの後続の処理にどのように影響するかを定義する必要があります。
セキュリティ
Azure サービスを使用することで、Dataverse は Power Platform マネージド ID 機能を使用して、Azureマネージド ID を介してメッセージ ブローカー (Azure Service Bus) に対して認証を行うことができます。 この方法により、機密性の高い資格情報を格納するリスクと、シークレットのローテーション時に発生するダウンタイムが排除されます。
パフォーマンス効率
Azure Service Busなどのメッセージ ブローカーを使用すると、負荷を平準化して、高負荷時にダウンストリーム アプリケーションが圧倒されないようにすることができます。
ボリュームが非常に大きくなる場合は、非同期 Dataverse プラグインではなく Azure 関数を使用して Azure Service Bus にメッセージを送信することを検討してください。 この方法では、大量のレコードをバッチで処理し、一時的なエラーに対処するための最大のスケーラビリティと柔軟性が提供されます。
Contributors
Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。
主な執筆者:
- Chris Piasecki、ソリューション アーキテクト