Microsoft Azure ソリューション用リスナーの記述

  • [アーティクル]

 

公開日: 2016年11月

対象: Dynamics CRM 2015

このトピックでは、Microsoft Dynamics CRM 2015にポストされた Microsoft Azure サービス バス メッセージを読み取りおよび処理できるリスナーの記述方法について説明します。Microsoft Dynamics 365 リスナーの仕様を学習する前に、前提要件として、Microsoft Azure サービス バス リスナーの記述方法を知る必要があります。 詳細については、「Azure サービス バス ドキュメント」および「サンプル コード」を参照してください。

このトピックの内容

キュー リスナーの記述

一方向、二方向、または REST リスナーの記述

メッセージのフィルター処理

キュー リスナーの記述

メッセージ キューは、サービス バス エンドポイントで受信されるメッセージのリポジトリです。キュー リスナーは、それらのキュー メッセージを読み取って処理するアプリケーションです。 サービス バス メッセージはキューに格納されるため、リスナーはキュー内で受信されるメッセージをアクティブにリッスンする必要はありません。 キュー リスナーは、メッセージがキュー内に到達した後に開始されても、それらのメッセージを処理できます。 次のセクションで説明するその他の種類のリスナーは、アクティブにリッスンしていないとメッセージを読み取れません。 これらのメッセージは、Microsoft Dynamics 365 またはその他のソースから送信されます。 キュー リスナーを記述する際には、各メッセージ ヘッダー アクションをチェックして、メッセージが Microsoft Dynamics 365 からのものであるかどうかを確認することが重要です。

ReceiveAndDelete モードの Receive を使用して破壊的メッセージ読み取りを行うと、メッセージは読み取られキューから削除されます。または、PeekLock モードを使用して非破壊的メッセージ読み取りを行うと、メッセージは読み取られますがきニューにそのまま残ります。 この SDK で提供されている永続キュー リスナーのサンプル コードは、破壊的読み取りを実行します。 キューからメッセージを読むことについての詳細は、「キューからのメッセージの受信方法」を参照してください。

トピックはキューに似ていますが、公開/サブスクライブ モデルを実装します。 一つ以上リスナーがトピックをサブスクライブし、キューからメッセージを受信することができます。詳細:キュー、トピック、およびサブスクリプション

重要

永久キューとトピックはサポートされますが、メッセージ バッファーのキューはサポートされません。 この契約を使用するには、Azure SDK バージョン 1.7 または 1.8 を使用して、リスナー アプリケーションを記述する必要があります。

マルチシステム ソフトウェアの設計でキューおよびトピックを使用すると、システムのデカップリングが生じます。 リスナー アプリケーションを使用できないようにすると、Microsoft Dynamics 365 からメッセージは引き続きの配信され、オンラインに戻るとリスナー アプリケーションはキュー メッセージを引き続き処理することができます。詳細:キュー、トピックおよびサブスクリプション。

メッセージ バッファー リスナーを更新して永続キューを使用する

次の示す手順は、メッセージ バッファーからメッセージを取得するリスナー アプリケーションを永続キューからメッセージを取得するリスナー アプリケーションに更新する一般的な手順です。

  1. Microsoft Azure ポータルで、メッセージ バッファーに使用したで同じパス内のキューを同じソリューションで作成します。

  2. 開発マシンに Microsoft Azure SDK バージョン 1.7 または 1.8 をインストールします。

  3. クラスおよびメソッドに関連するコード メッセージ バッファーを削除してリスナー コードを更新し、それを QueueClient および Receive で置き換えます。 目的の読込みモード: RetrieveAndDelete または PeekLock を使用してください。 キューからメッセージを読むとることについての詳細は、「キュー、トピックおよびサブスクリプション」を参照してください。

  4. リスナー アプリケーションを作成します。

キュー エンドポイントがメッセージ バッファーが使用してした同じソリューション パスを使用する限り、Microsoft Dynamics 365 設定の変更は必要ではありません。

一方向、二方向、または REST リスナーの記述

先に説明したキュー リスナーに加えて、Microsoft Dynamics 365 でサポートされているその他 3 つのサービス バス コントラクト用のリスナー、一方向、二方向、および REST リスナーを記述できます。 一方向リスナーは、サービス バスにポストされたメッセージを読み取って処理できます。 二方向リスナーは、同じことをできますが、いくつかの情報の文字列を Dynamics 365 に返します。REST リスナーは、REST エンドポイントを使用して機能する点を除いて二方向リスナーと同じです。 これらのリスナーは、サービス バス経由で送信されたメッセージを読み取るために、サービス エンドポイントをアクティブにリッスンする必要があります。Microsoft Dynamics 365 が Message をサービス バスへ投稿しようとしたときにリスナーがリッスンしていなかった場合、Message は送信されません。

リスナーの記述は、ABC (アドレス、バインディング、コントラクト) と呼ばれる要素によって構造化されます。 次の情報は、一方向リスナーの ABC を示しています。

リスナーがエンドポイントに登録された後、Microsoft Dynamics 365 によってメッセージがサービス バスにポストされると、リスナーの Execute メソッドが呼び出されます。Execute メソッドは、メソッド呼び出しからデータを返すことはしません。 詳細については、一方向リスナー サンプル、「サンプル: 一方向リスナー」を参照してください。

二方向リスナーは、一方向リスナーと同様の方法でコーディングされます。 二方向リスナーの ABC は次のとおりです。

この二方向コントラクトの場合、実行 メソッドはメソッド呼び出しの結果として文字列を返します。 詳細については、二方向リスナー サンプル、「サンプル: 二方向リスナー」を参照してください。

REST リスナーは、二方向リスナーと同様の方法でコーディングされます。REST リスナーの基礎は次のとおりです。

REST 契約の場合、Execute メソッドはメソッド呼び出しの結果として文字列を返します。 詳細については、REST リスナーのサンプル (「サンプル: REST リスナー」) を参照してください。 二方向リスナーのサンプルでは ServiceHost がインスタンス化されますが、REST リスナーのサンプルでは、WebServiceHost がインスタンス化されます。

注意

二方向または REST リスナーで標準のプラグイン (ServiceBusPlugin) を使用する場合、プラグインはリスナーから返される文字列データを使用しません。 ただし、カスタム Azure 対応のプラグインではこの情報を使用できます。

リスナー サンプルを実行する場合、要求される発行者シークレットは、Microsoft Azure サービス バスの管理キーです。 WS2007 Federation HTTP バインディングでは、「トークン」と WS-Trust 1.3 プロトコルが使用されます。

メッセージのフィルター処理

Microsoft Dynamics CRM 2015とCRM Onlineから送信された仲介メッセージ Propertiesプロパティごとに追加された追加情報のプロパティ バッグがあります。 プロパティ バッグには、永続キューおよびのトピック コントラクト エンドポイントと共に次の情報が含まれています。

  • 組織 Url

  • 呼び出し元ユーザー ID

  • 呼び出し元のユーザー ID

  • エンティティの論理名

  • 要求名前

この情報は、Microsoft Dynamics 365 で処理されサービス バス メッセージがポストされる、組織、ユーザー、エンティティ、メッセージ要求を識別します。 リスナー コードは、この情報によって受信されるメッセージを処理することもできます。詳細:サンプル: 複数の要求を実行する

関連項目

Microsoft Dynamics CRM 2015 の Azure 拡張機能
Azure 対応のカスタム プラグインの記述
サンプル: 永続キュー リスナー
サンプル: 一方向リスナー
サンプル: 二方向リスナー
サンプル: REST リスナー
Azure サービス バスを介した Microsoft Dynamics CRM 2015 データの送信

© 2017 Microsoft. All rights reserved. 著作権