適用対象:
- Microsoft Cloud for Sustainability
- Microsoft Cloud for Financial Services
- Microsoft Cloud for Healthcare
- Microsoft Cloud for Retail
業界データ モデルは、それぞれの Microsoft インダストリー クラウドの基盤として機能します。 データ エステートの成熟度によっては、ソリューションを他のシステムと統合する必要があります。
Microsoft インダストリー クラウド ソリューションと外部システム間の実装を成功させるには、適切な統合パターンを選択することが重要です。 この記事では、統合に関連する統合パターン、ツール、テクノロジー、および意思決定の際に考慮すべき要素を紹介します。
統合のニーズ
サード パーティ システムは、別々のプロセスや異なるビジネス ロジックを持つ可能性があります。 サード パーティ システムが同じ業界クラウド Common Data Model (CMD) を使用している場合、データ転送、同期、データ変換のためのプログラミングが不要になります。
次のシナリオでデータ統合パターンを使用します。
- 単一の継続的な管理プロセスの中心部分ではないプライマリ データまたはトランザクション データ。 データは、1 つのシステム内のプロセスと Microsoft Industry Cloud の間で同期されます。
- 計算に必要な場合、データはシステム間で共有または交換されます。
- データはシステム間で共有または交換されるため、一方のシステムでのアクションは他方のシステムにも反映されます。
- 詳細レベルのデータを含むシステムからの集約データは、より高いレベルのデータ表現を含むシステムに交換されます。
適切な統合パターンを選択する方法
統合開発には多くの技術的オプションが利用可能ですが、それぞれに独自の長所と短所があります。 統合拡張機能に適したパターンを特定するには、以下の要素を考慮し、それぞれの選択肢を比較検討します:
| 決定係数 | 説明 |
|---|---|
| データ型と | 統合されるデータの種類と形式とは？ |
| データの不安定性 | 低ボラティリティ/緩やかな変化から、高ボラティリティ/急速な変化まで。 |
| データ量 | 少量データから大容量データまで。 |
| データの可用性 | ソースからターゲットまで、いつデータの準備を完了したいですか? リアルタイムで必要なのでしょうか、それとも 1 日の終わりにすべてのデータを収集し、スケジュールされたバッチでターゲットに送信するだけでよいのでしょうか？ |
| サービスの保護とスロットリング | 制限を適用することで、すべてのユーザーに一貫した可用性とパフォーマンスを確実に提供します。 これらの制限は、通常のユーザーには影響せず、特別なリクエストを行うクライアントだけに影響します。 オンライン サービスによくあるパターンとして、リクエストが多すぎる場合にエラーコードを出すようにすべきです。 |
| 必要なデータ変換のレベル | ソース データをターゲットに変換または集計するための要件。 |
| トリガーとトリガー アクション | ソースからターゲットへのデータ送信をトリガーするアクションは何ですか? データがターゲットに到着した後に自動化すべき具体的なアクションは何ですか? |
| エラー処理 | インターフェイスの問題を検出するために何らかの監視をおこなう。 |
| スケーラビリティ | 現在、短期、長期的に予想される取引量の処理です。 |
| 記録システム | 記録システムまたは情報の所有者はどのシステムかを考慮します。 |
| データ フローの方向 | ターゲット システムはそれをプルする必要がありますか、それともソース システムがプッシュする必要がありますか? |
これらの要因に基づいて、統合パターンを特定し、実装に適したツールやテクノロジーを選択することができます。
統合パターン
このセクションでは、Dataverse との統合中に使用できる次の統合パターンについて説明します。
- リアルタイム/同期統合
- ほぼリアルタイム/同期統合
- バッチ統合
- プレゼンテーション レイヤー統合
各パターンには固有の構造が示されており、1 つまたは複数のパターンを使用することで実現できます。 後続のセクションでは、これらのパターンが特定のテクノロジーでどのように実現されるかについての洞察と、それらを適用するための考慮事項および適切なシナリオについて説明します。
リアルタイム/同期統合
ソース システムが、送信するデータに対して即時または最小限の遅延応答を必要とするシナリオでは、リアルタイム統合が不可欠です。 この要件は、ビジネス ユース ケースでソース システムと宛先システムの両方が常に同期を維持し、2 つのエンティティ間の中断のないデータの一貫性を確保する必要がある場合に重要になります。 同期統合は、宛先システムが進行中のプロセスをシームレスに進めるために即時応答を必要とし、後続のアクションをタイムリーに実行できるようにする必要がある場合に不可欠になります。
この形式の統合は、多くの場合、同期統合と同義です。 次の図は、同期統合の一般的なパターンを示しています。このパターンでは、アプリケーション A がアプリケーションBへのリクエストを開始し、即座に応答を受信して、タイムリーで応答性の高いデータ交換が保証されます。
前述したテクノロジーの選択肢の一部は、トランザクション プロセスを容易にする中継器として機能する仲介システムを組み込むように拡張できます。 このリレー オプションは、ソース アプリケーションとターゲット アプリケーションに代わってリクエストと応答の通信を管理することで、ソース アプリケーションとターゲット アプリケーションを効果的に分離します。
これらの同期データ統合パターンは、業界クラウド ソリューションで利用可能なさまざまなテクノロジーを使用して実装できます。 次の表は、いつ使用するかに関するベスト プラクティス パターンを示しています。
| テクノロジー オプション | データの方向 | パーパス | 使用時 |
|---|---|---|---|
| Dataverse Web API | 外部から Dataverse へのデータのプル/プッシュ | OData v4 実装は、標準のインターフェイス セットを使用して CRUD 操作を提供し、幅広い技術 対象者 にオープンなインターフェイスを提供します。 | 主に、個別の CRUD 操作が必要な場合のトランザクション アプリの統合に使用されます。 任意のカスタム統合にも使用できますが、特に大量のデータの場合、スロットル、並列処理、再試行ロジックに関連する複雑さが伴います。 |
| Microsoft Industry Cloud によって公開された API | 外部から Dataverse へのデータのプル/プッシュ | Microsoft Industry Cloud によって作成されたカスタム API は、Azure の使用状況に関連する排出量データへのアクセスなどの特別な操作をサポートします。 | Microsoft Industry Cloud によって公開された API 独自のカスタム API を作成する前に、これらのカスタム API の使用を優先してください。 |
| カスタム Dataverse API | 外部から Dataverse へのデータのプル/プッシュ | Dataverse で独自の API を作成します。 | 1 つ以上の操作を 1 つの操作に統合する場合、新しいタイプの トリガー イベント を公開する必要があります。 |
| 仮想テーブル | Dataverse から外部へのデータのプル/プッシュ | 外部データ ソースに接続し、それらを Dataverse エンティティとして扱います。 | 参照データの取得と少量の CRUD シナリオ。 |
| コネクタ | 双方向 | マイクロソフトのサービスと外部システム、アプリケーション、データ ソースとの間のシームレスなデータ交換を可能にします。 | マイクロソフトの公開済みコネクタ は、マイクロソフトのサービス同士やファーストパーティ アプリケーションとの接続など、一般的に使用される統合用です。 検証済みの公開コネクタ は、サードパーティ アプリケーションとの特殊な統合に採用されており、互換性と信頼性が保証されています。 カスタム コネクタ は、マイクロソフトまたはパートナーのコネクタでは顧客のビジネス ニーズを解決できない場合に使用できます。 |
ほぼリアルタイム/同期統合
非同期統合は、ビジネス プロセスまたはアクションにおいてリアルタイムの応答が直ちに必要ないシナリオで推奨されます。 通常、アプリケーションとシステム間で大量のメッセージ通信がある場合に使用されます。 非同期統合パターンにより、システム間の通信がプロセスをブロックしたり遅くしたりすることがなくなり、各システムが独立して非同期で動作できるようになります。 非同期統合を実装する最も一般的な方法としては、 メッセージ キュー、公開の購読、バッチ統合などがあります。 要件に応じて、これらの統合を個別に使用することも、組み合わせて使用することもできます。 これらは、総称してイベント駆動型アーキテクチャ (EDA) と呼ばれることがよくあります。
次のメッセージ キュー パターンでは、送信者はイベント駆動型フレームワークを採用し、コンシューマーはイベントへのバインディングを直接作成します。 メッセージが送信されると、受信者は直接通知を受け、イベント メッセージに含まれるデータを受け取ります。
次のパブリッシュ/サブスクライブ パターンでは、パブリッシャーは標準化されたパブリッシュ形式でメッセージを生成し、それを 1 人以上のサブスクライバーを持つことができる専用のパブリッシュ/サブスクライブ チャネルに送信します。 各サブスクライバは特定のチャネルまたは トピック にサブスクライブされ、必要に応じてパブリッシュされたメッセージ (イベント) を受信して処理できるようになります。 複数のサブスクライバーが個別にメッセージ (イベント) を受信して処理できるため、パブリッシュ/サブスクライブ パターンは 1 対多の通信シナリオに選択されます。
これらの非同期データ統合パターンは、さまざまなオプションを使用して実装できます。次の表に、利用可能なオプションと、それらをいつ使用するかに関するベスト プラクティスを示します。
| テクノロジー オプション | イベント駆動型または公開サブスクライバー | パーパス | 考慮事項 | 使用する場合 |
|---|---|---|---|---|
| Power Automate | 両方 | ローコード オートメーションのニーズ。 | Power Automate および、スロットルなどの各コネクタの制限。 | Dataverse トリガー フローを使う、またはスケジュールに従って Power Automate フローを実行する場合に使用します。 |
| Logic Apps ベースのカスタム コネクタ | イベント駆動型 | ソリューション用の データ コネクタを構築して、外部ソリューションから直接データを取り込みます。 | 本番環境に移行する前に、プライバシー、セキュリティ、および コンプライアンスのレビューを行う必要があります。 | ネイティブ コネクタが存在しない ISV 統合シナリオの使用。 |
| Logic Apps および Azure Service Bus | 公開 - 購読 | パブリッシャーによってサービス バスおよびロジック アプリへのメッセージを受信すると、そのメッセージが消費されてサブスクライバー アプリケーションに送信されます。 | Logic Apps の構成と実行の制限 に注意します。 | Logic Apps コネクタのネイティブ トリガーや、複数のサブスクライバー シナリオのカスタム統合に使用します。 |
| Azure Functions、Azure App Service の Web Apps 機能、および Azure Service Bus | 公開 - 購読 | メッセージ キューを使用して、アプリケーションとコンシューマー サービスのインスタンス間の通信チャネルを実装します。 | メッセージの順序とその他の設計上の考慮事項を検討します。 | ローコード オプションでは統合を開発できない、大量かつ不安定なシナリオ (Power Automate または Logic Apps)。 |
| サービス エンドポイント | 両方 | コンテキスト情報をキュー、トピック、Webhook、またはイベント ハブに送信します。 | 長時間実行されるトランザクションには適していません。 | Dataverse コンテキストをターゲットに直接送信することで統合要件がほぼ満たされており、メッセージの順序が重要ではない場合。 |
バッチ統合
バッチ処理とは、チャットやオーバーヘッドを制限するために、一連のメッセージまたはレコードをバッチで収集および転送する方法です。 バッチ処理は、一定期間データを収集し、それを一括して処理します。 このアプローチは、大量のデータを扱う場合、または処理に大量のリソースが必要な場合に役立ちます。 このパターンは、分析目的でマスター データをレプリカ ストレージに複製することも対象としています。
| テクノロジー オプション | データの方向 | パーパス | 考慮事項 | 使用する場合 |
|---|---|---|---|---|
| Azure Data Factory | 両方向 | Dataverse から受信したデータ、または Dataverse に取り込む前にデータを変換するデータ フローを作成します | Data Factory サービスの制限 | 複雑な多段階の変換を伴う大量の取り込みまたはデータのエクスポートのシナリオ。 |
| Power Automate | N/A | マイクロソフトのワークフローとタスクを自動化する | 限られたスケーラビリティと長い処理時間 | 反復的なタスクを自動化し、イベントに基づいてアクションをトリガーし、大規模なコード開発を行わずにアプリケーションを統合する必要がある場合は、Power Automate を使用します。 |
| Power Query データフロー | 外部システムから Dataverse へ | データを Dataverse 環境に取り込み、変換し、ロードできるデータ準備ツール。 | 制限 | ターゲットが Dataverse であり、既存のコネクタが適合しない基本シナリオ、 Power BI のその他の特定のシナリオ。 |
| Azure Synapse パイプライン | 両方向 | Dataverse から受信したデータ、または Dataverse に取り込む前にデータを変換する パイプラインを作成する | N/A | 分析とデータ ウェアハウスのシナリオ。 |
| Azure Synapse Link for Dataverse | Dataverse から Azure Synapse Analytics、または Azure Data Lake Storage v2 (ADLS) | Dataverse データから Azure Synapse Analytics または ADLS v2 へ複製し、データ上で分析、ビジネス インテリジェンス、機械学習、カスタム レポートのシナリオを実行できるようにします。 | サポートされていないテーブル。 | データ分析およびカスタム レポート。 また、データ エクスポートの中間段階としても。 |
| Azure Logic Apps | N/A | 強力な統合機能を備えたワークフローを作成します。 | 複雑なバッチ操作には、大規模な構成とオーケストレーションが必要になる場合があります。 特殊なバッチ処理シナリオには最適化されていません。 | Azure Logic Apps は、ビジネス プロセスのオーケストレーションやサービスの統合に適しています。 |
| SQL Server Integration Services | 両方向 | サードパーティーのコネクタを使用して、Dataverse との間でデータをプルおよびプッシュします。 | PaaS ソリューションではないため、スケーリング、メモリ使用量、パフォーマンス、コストを評価する必要があります。 | クラウド抽出、変換、ロード (ETL) ツールの制限はオプションではない場合があります。 |
プレゼンテーション レイヤー統合
プレゼンテーションまたは User Interface Integration は、システムの最上位レベルにあり、ユーザーが見て対話するものです。 特定のユースケースでは、異なるシステムやデータソースからの情報を組み合わせ、単一の User Interface Integration で表示することにより、このレベルで統合を行う必要があります。 モデル駆動型アプリケーションはその構成要素であり、データ駆動型のインタラクションを可能にし、統合環境内でのシームレスなナビゲーションを促進することで、包括的なユーザー エクスペリエンスに貢献します。 プレゼンテーション統合は、既存のビジネスロジックやアプリケーション構造を維持しながら、データ集約やユーザー インターフェイスのカスタマイズ、ユーザー エクスペリエンスの向上を容易に実現したい場合に必要となります。 逆に、統合やメンテナンスの複雑さ、統合システム間の大きな相互依存性、潜在的なパフォーマンスへの影響、データの一貫性に関する考慮事項など、固有の制約もあります。
- データ集計を有効にしています
- ユーザー インターフェイスのカスタマイズ
- 拡張されたユーザー エクスペリエンス
逆に、次のような固有の制約があります。
- 統合とメンテナンスの複雑さ
- 統合システム間の重要な相互依存性
- パフォーマンスへの潜在的な影響
- データの一貫性に関する考慮事項
| テクノロジー オプション | パーパス | 考慮事項 | 使用する場合 |
|---|---|---|---|
| ファーストパーティーのネイティブ UI 統合 | Microsoft Bing マップ、Microsoft Teams、その他のファースト パーティ製ネイティブUI統合の使用。 | ほとんどの場合カスタマイズ不可。 | ネイティブ UI 統合でサポートされる特定のシナリオ。 |
| カスタム ページ | キャンバス アプリをモデル駆動型アプリに埋め込む | 既知の制限 | ローコード統合アプローチを採用し、キャンバス アプリが使いやすさに適している場合に推奨されます。 |
| Power Apps component framework (PCF) | 応答性の高いデザインを維持しながら、エンドユーザーを表示または対話するための再利用可能なカスタム コントロール。 | Power Apps コンポーネント制限のフレームワーク。 | キャンバス アプリがない場合に、カスタム UI をモデル駆動型アプリ内で開発する必要がある場合に適した方法です。 |
| Power BI タイル | モデル駆動型アプリ フォームの Power BI タイルの表示。 | Power BI ライセンス、Power BI データの承認。 | モデル駆動型アプリ内の Power BI タイルの表示 |
| Power BI embedded ダッシュボード | モデル駆動型アプリ内の Power BI embedded ダッシュボード。 | Power BI ライセンス、Power BI データの承認。 | Power BI でホストされている分析の表示。 |
| HTML iFrame として埋め込む | 他のシステム UI をモデル駆動型アプリに埋め込む。 | シングルサインオン (SSO)、Cross-Origin Resource Sharing (CORS) 構成、レスポンシブ デザイン。 | 利用可能なサービスがない複雑な UI シナリオ。 |
| カスタム Web リソース | モデル駆動型アプリ内でカスタム UI レイアウトを作成する。 | カスタム UI のアクセシビリティと応答性の高いデザインを評価します。 | 他の UI 統合がオプションではないシナリオ。 |
統合パターンの概要
ソフトウェア統合の世界では、異なるシステム間でデータを交換するために利用できるさまざまなパターンやメカニズムが存在します。 各パターンには独自の長所と短所があり、適切なパターンを選択すると、統合システムのパフォーマンスと効率に大きな影響を与える可能性があります。
以下の表は、これらの統合パターンをまとめたものです: リアルタイムまたは同期統合、非同期統合、バッチ統合、プレゼンテーション層統合。 各パターンのメカニズム、トリガー、長所、短所、ユースケースを調査して、システムの統合アプローチを選択する際に情報に基づいた意思決定を行うことができます。
| 統合パターン | メカニズム | トリガー | 長所 | デメリット | 使用する場合 |
|---|---|---|---|---|---|
| リアルタイムまたは同期 | データは同期的に交換され、ポイントツーポイント統合またはリレーを使用してアクションを呼び出します。 | ユーザー アクションまたはシステム イベント。 | 高速なリクエストとレスポンスの往復。 リアルタイムの値と情報。 | 一般に、プロセスがスタックして密結合統合が作成されるリスクがあるため、使用するベスト プラクティスではありません。 一時的なエラーによる波及効果のリスク。 待機時間が重要視されます。 | リアルタイム情報が重要な場合に使用します。 |
| 非同期 | データは、定期的なスケジュールに従って、またはメッセージング パターンを使用したトリクル フィードとして、無人で交換または取り込まれます。 | 一定期間にスケジュールされるか、ソース システムによって発行される新しいメッセージによってトリガーされます。 | システムの疎結合により、ソリューションが堅牢になります。 時間とリソースに応じた負荷分散。 リアルタイムに非常に近い可能性があります。 迅速なエラー処理。 | システム全体にわたる変更に対する応答と可視性の遅延。 | 低または中程度のデータ量でのほぼリアルタイムのデータ同期のニーズ。 |
| バッチ処理 | バッチ処理とは、チャットやオーバーヘッドを制限するために、一連のメッセージまたはレコードをバッチで収集および転送する方法です。 | スケジュールされた、または手動トリガー。 | メッセージング サービスやその他の非同期統合パターンでの使用に最適です。 個々のパッケージが減り、メッセージ トラフィックが減ります。 | データの鮮度が低くなります。 メッセージの到着時にビジネス ロジックが実行される場合、受信システムの負荷が影響を受ける可能性があります。 | 一連のメッセージまたはレコードをバッチ形式で収集および転送することが可能な、大量または変動性の高いシナリオ、データ レプリケーション シナリオ。 |
| プレゼンテーション レイヤー | あるシステムからの情報は、別のシステムの UI にシームレスに統合されます。 | N/A | データは元のシステムに残るため、データ同期の複雑さを取り除きます。 特定の業界では、規制要件によるデータ常駐に関連する予期せぬエラーを排除します。 | シングル サインオン、クロスオリジン リソースの共有、認可の整合性を満たすために、より複雑になります。 | ソース システムとターゲット システム間でデータを同期することなく、ソース システムや UI を直接表示することで要件を満たす場合。 |