次の方法で共有

財務と運用アプリと、サード パーティ サービス間の統合

  • [アーティクル]

この記事は、設計者と開発者が統合シナリオを実装する際に意思決定を適切に行えるようにすることを目的としています。

この記事では、統合パターン、統合シナリオ、統合ソリューション、およびベスト プラクティスについて説明します。 ただし、すべての統合パターンを使用または設定する方法に関する技術詳細は含まれません。 また、サンプル統合コードも含まれていません。

メモ

パターンを選択にあたってガイダンスを示し、シナリオについて説明する際には、データのボリューム番号について言及されます。 これらの番号は、パターンを測定するためだけに使用する必要があり、ハードシステムの限界を意味するものではありません。 絶対数は、運用環境ではさまざまな要因によって変わってきます。コンフィギュレーションはこのシナリオにおけるただ1つの側面に過ぎません。

次のテーブルに、使用可能な統合パターンを示します。

パターン ドキュメント
Power Platform 統合 Microsoft Power Platform と財務と運用アプリの統合
OData データ プロトコル (OData) を開く
バッチ データ API 定期統合
データ管理パッケージ REST API
カスタム サービス カスタム サービスの開発
外部 Web サービスの消費 外部 Web サービスの消費
Excel 統合 Office 統合の概要

メモ

オンプレミス配置の場合、唯一サポートされる API は データ管理パッケージ REST API です。 これは、7.2、platform update 12 ビルド 7.0.4709.41184 で現在利用可能です。

同期および非同期の統合パターン

処理は、同期または非同期にすることができます。 多くの場合、使用すべき処理タイプは、選択した統合パターンによって決まります。

同期パターンは、ブロック要求と応答パターンであり、呼び出し先が実行を終了して応答を返すまで呼び出し元がブロックされます。 非同期パターンは非ブロック パターンで、呼び出し元が要求を送信して応答を待たずに続行します。

次のテーブルに、使用可能な受信統合パターンを示します。

パターン タイミング バッチ
OData 同期 無
バッチ データ API 非同期 有

同期と非同期パターンを比較する前に、すべての REST および SOAP 統合アプリケーション プログラミング インターフェイス (API) を同期または非同期で呼び出すことができるので注意が必要です。

次の例は、このポイントを示しています。 オープン データ プロトコル (OData) が統合のために使用される場合、呼び出し元がブロックされるとは限りません。 通話の仕方によっては、呼び出し元がブロックされない場合があります。

パターン 同期式のプログラミング パラダイム 非同期式のプログラミング パラダイム
OData DbResourceContextSaveChanges DbResourceContextSaveChangesAsync
カスタム サービス httpRequestGetResponse httpRequestBeginGetResponse
SOAP UserSessionServiceGetUserSessionInfo UserSessionServiceGetUserSessionInfoAsync
バッチ データ API ImportFromPackage BeginInvoke

これらの API が呼び出されると、すぐにビジネス ロジックが実行されるため、OData とカスタム サービスの両方は同期統合パターンです。 次にいくつか例を挙げます。

  • OData を使用して製品レコードを挿入すると、レコードはすぐに OData 呼び出しの一部として挿入されます。
  • 手持ちの在庫を検索するためにカスタム サービスを使用すると、ビジネス ロジックが JSON/SOAP 呼び出しの一部としてすぐに実行され、在庫総額がすぐに返されます。

これらの API が呼び出されると、バッチ モードでデータがインポートまたはエクスポートされるため、バッチ データ API は非同期統合パターンと見なされます。 たとえば、ImportFromPackage API への呼び出しは、同期することができます。 ただし、API は、特定のデータ パッケージのみをインポートするバッチ ジョブをスケジュールします。 スケジューリング ジョブはすぐに戻され、後でバッチ ジョブで処理されます。 したがって、バッチ データ API は非同期として分類されます。

バッチ データ API は大量のデータのインポートとエクスポートを処理するために設計されています。 大量である条件を正確に定義することは困難です。 回答は、エンティティによって、およびインポートまたはエクスポート中に実行されるビジネス ロジックの量によって異なります。 ただし、経験則を次に示します: 容量が数十万レコード以上の場合は、統合のバッチ データ API を使用する必要があります。

一般に、統合パターンを選択しようとしている場合、次の質問を検討することをお勧めします。

  • 統合をリアルタイムで行う必要がある業務要件がありますか。
  • ピーク時のデータ量の要件は何ですか ?
  • 頻度はどのくらいですか ?

エラー処理

同期パターンを使用するときは、呼び出し元に成功または失敗の応答が返されます。 たとえば、OData 呼び出しが販売注文を挿入するために使用される場合、販売注文明細行に存在しない製品への無効な参照があると、呼び出し元が受信する応答には、エラー メッセージが含まれます。 呼び出し元は、応答内のエラーを処理します。

非同期パターンを使用するときは、呼び出し元には、スケジューリング呼び出しが成功したかどうかを示す応答がすぐ表示されます。 呼び出し元は、応答内のエラーを処理します。 スケジューリングが完了したら、データのインポートまたはエクスポートのステータスは、呼び出し元にプッシュされません。 呼び出し元は、対応するインポートまたはエクスポート処理の結果をポーリングし、それに応じてエラーを処理する必要があります。

OData 統合を使用する一般的なシナリオとパターン

OData 統合を使用する典型的なシナリオを次に示します。

メモ

Power BI レポートの OData の使用はお勧めしません。 このような状況ではエンティティ格納を使用することをお勧めします。

製品情報の作成および更新

あるメーカーでは、その製品をオンプレミスでホストされているサード パーティ製アプリケーションを使用して、定義および構成します。 この製造元は、運用情報をオンプレミス アプリケーションから財務と運用に移行する必要があります。 製品が定義されるとき、またはオンプレミス アプリケーションで変更されるとき、ユーザーは、同じ変更をリアルタイムに確認できます。

意思決定 情報
リアルタイムな日付が必要ですか。 有効
ピーク データ量 時間当たり 1,000 レコード*
頻度 アドホック

場合によっては、新しいまたは変更された生産コンフィギュレーションが短時間に多く発生します。

このシナリオは、OData サービス エンドポイントを使用して、財務と運用で製品情報を作成および更新することによって最適に実装されます。

財務と運用で:

  • 統合に必要なすべてのエンティティを決定します。
  • OData サービス エンドポイントが同じエンティティのセットに対して使用可能であることを確認します。

サード パーティ製アプリケーション:

  • 製品情報がサード パーティ製アプリケーションで作成または変更されるときは、同じ変更を加えるために財務と運用への OData 呼び出しが行われます。

客注文のステータスを読み取る

会社は、顧客が注文の状況を確認できる自己ホストの顧客ポータルを持っています。 注文ステータス情報は、アプリケーションで管理されます。

意思決定 情報
リアルタイムな日付が必要ですか。 はい
ピーク データ量 時間当たり 5,000 レコード
頻度 アドホック

このシナリオは、OData サービス エンドポイントを使用して、注文ステータス情報を読み取ることによって最適に実装されます。

財務と運用で:

  • 注文のステータス情報を読むために必要なエンティティを決定します。
  • OData サービス エンドポイントがエンティティに対して使用可能であることを確認します。

顧客のポータル サイトで、次の操作を行います。

  • 顧客は注文のステータスをチェックするとき、対応する注文を読み取ってそのステータスを取得するために、財務と運用にリアルタイムの OData 呼び出しを行います。

BOM の承認

会社は、オンプレミスでホストされている製品ライフサイクル管理 (PLM) システムを使用しています。 PLM システムには、承認のためにアプリケーションに完成した部品表 (BOM) 情報を送信するワークフローがあります。

意思決定 情報
リアルタイムな日付が必要ですか。 有
ピーク データ量 時間当たり 1,000 レコード
頻度 アドホック

このシナリオは、OData アクションを使用して実装できます。

財務と運用で:

  • 統合に必要なエンティティを決定する
  • OData サービス エンドポイントがエンティティに対して使用可能であることを確認します。
  • エンティティで、必要なビジネス ロジックを実行するアクションを作成します。

PLM ソリューション:

  • PLM システムで、BOM を承認する OData アクションを呼び出します。

メモ

このタイプの OData アクションは BOMBillOfMaterialsHeaderEntity::approve で見つけることができます。

カスタム サービスを使用する一般的なシナリオとパターン

カスタム サービスを使用する典型的なシナリオを次に示します。

手持在庫の検索

エネルギー会社にはヒーターのインストール ジョブをスケジュールするフィールド作業者がいます。 この会社はバック オフィスとサード パーティのサービスとしてのソフトウェア (SaaS) のためにアプリケーションを使用して予定をスケジューリングします。 現場作業員が予定をスケジュールするときは、ジョブに使用できるインストール パーツがあることを確認するために、引当可能在庫数を検索する必要があります。

意思決定 情報
リアルタイムな日付が必要ですか。 有
ピーク データ量 時間当たり 1,000 レコード
頻度 アドホック

このシナリオは、カスタム サービスを使用して実装できます。

財務と運用で:

  • 特定のアイテムの現物手持在庫を計算するカスタム サービスを作成します。

スケジューリング アプリケーション:

  • 選択した品目の在庫情報を取得するために、SOAP または REST を通じてカスタム サービス エンドポイントへのリアルタイムな呼び出しを行います。

メモ

このタイプのカスタム サービスの例は、Retail Real Time Services が実装された RetailTransactionServiceInventory::inventoryLookup で見つけることができます。

また、inventorySiteOnHand エンティティを使用して同じ結果を得ることができます。 場合によっては、複数のメソッドを使用して同じデータとビジネス ロジックを公開でき、すべてのメソッドが同じように有効になり効果を持ちます。 この場合、特定のシナリオを最適に機能して、開発者が最も使いやすいメソッドを選択します。

バッチ データ統合を使用する一般的なシナリオとパターン

バッチ データ API を使用する典型的なシナリオを次に示します。

大量の販売注文のインポート

会社は、オンプレミスを実行するフロント エンド システムから大量の販売注文を受信します。 これらの注文は、定期的に処理、管理するためにアプリケーションに送信する必要があります。

意思決定 情報
リアルタイムな日付が必要ですか。 無
ピーク データ量 時間当たり 200,000 レコード
頻度 5 分間隔で 1 回

このシナリオは、バッチ データ API を使用すると最もよく実装されます。

財務と運用で:

  • 統合に必要なすべてのエンティティを決定します。
  • エンティティに対してデータ管理が有効であることを確認します。

オンプレミスシステム:

  • REST バッチ データ API を使用して、ファイルをエクスポートします。

大量の発注書をエクスポート

会社は、財務と運用で大量の発注書を生成し、オンプレミス在庫管理システムを使用して製品を入庫します。 発注書は、財務と運用からオンプレミス インベントリ システムに移動する必要があります。

意思決定 情報
リアルタイムな日付が必要ですか。 無
ピーク データ量 時間当たり 300,000 レコード
頻度 1 時間あたり 1 回

このシナリオは、バッチ データ API を使用すると最もよく実装されます。

財務と運用で:

  • 統合に必要なすべてのエンティティを決定します。
  • エンティティに対してデータ管理が有効であることを確認します。
  • 差分プッシュする必要がある場合は、エンティティの変更履歴を有効にできるかを確認します。

オンプレミス在庫システム:

  • REST バッチ データ API を使用して、財務と運用からファイルをエクスポートし、在庫システムにインポートします。

外部の Web サービスを呼び出す一般的なシナリオとパターン

通常、アプリケーションはオンプレミスまたは別の SaaS プロバイダーによってホストされている外部 Web サービスを呼び出します。 この場合、アプリケーションは統合クライアントとして機能します。 統合クライアントを作成するときは、他のアプリケーションの統合クライアントを作成するときと同じベスト プラクティスおよびガイドラインのセットに従ってください。 単純な例として、 外部 Web サービスの使用 を参照してください。

重要

セキュリティ要件のため、運用およびサンドボックス環境では、トランスポート層セキュリティ (TLS) 1.2 以降を使用するセキュリティ保護された通信のみがサポートされます。 つまり、アプリケーションが呼び出すターゲットの Web サービス エンドポイントは、TLS 1.2 以降をサポートする必要があります。 ターゲット サービス エンドポイントがこの要件を満たしていない場合、呼び出しは失敗します。 例外エラー メッセージは、次のメッセージのようになります。

転送接続からデータを読み取ることができません: 既存の接続がリモート ホストによって強制的に切断されました。

TLS 1.2 またはそれ以降のバージョンを使用することが原因で対象サービスを変更できない場合は、次の図に示すように、ブローカー サービスを導入して 2 ホップ コールを行うことでこの問題を回避できます。

TLS の要件。