共用方式為


為 Microsoft Azure 解決方案撰寫接聽程式

 

發行︰ 2016年11月

適用於: Dynamics CRM 2015

本主題描述如何撰寫接聽程式,可讀取和處理張貼至 Microsoft Azure 服務匯流排 的 Microsoft Dynamics CRM 2015 訊息。 先決條件是,您應該熟悉的如何撰寫 Microsoft Azure 服務匯流排 接聽程式,然後嘗試了解 Microsoft Dynamics 365 接聽程式的特性。 如需詳細資訊,請參閱 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. 移除訊息緩衝區相關的類別和方法來更新接聽程式碼,然後將其取代成 QueueClientReceive。 務必使用所要的讀取模式RetrieveAndDeletePeekLock。 如需從佇列中讀取訊息的詳細資訊,請參閱佇列、主題和訂閱

  4. 建立接聽程式應用程式。

只要佇列端點使用訊息緩衝區所使用相同的解決方案路徑,就不需要 Microsoft Dynamics 365 設定變更。

撰寫單向、雙向或 REST 接聽程式

除了前述佇列接聽程式外,您可以為 Microsoft Dynamics 365 支援的其他三個服務匯流排合約撰寫接聽程式:單向、雙向,以及 REST。 單向接聽程式可以讀取及處理張貼至服務匯流排的訊息。 雙向接聽程式執行相同操作,但也會將部分資訊字串返回 Dynamics 365。REST 接聽程式與雙向接聽程式相同,不過它適用於 REST 端點。 請注意,這些接聽程式必須主動地在服務端點接聽,才能讀取透過服務匯流排傳送的訊息。 如果在 Microsoft Dynamics 365 嘗試張貼訊息給服務匯流排時,該接聽程式未進行接聽,不會傳送訊息。

撰寫接聽程式是建構在稱為 ABC 的基礎上:位址、繫結與合約。 下列資訊識別單向接聽程式的 ABC。

在端點註冊接聽程式後,當訊息由 Microsoft Dynamics 365 張貼至服務匯流排時,會叫用接聽程式的 Execute 方法。Execute 方法不會從方法呼叫中傳回任何資料。 如需詳細資訊,請參閱單向接聽程式範例範例:單向接聽程式

雙向接聽程式編碼方式類似於單向接聽程式。 雙向接聽程式的 ABC 如下:

若是此雙向合約,Execute 方法會從方法呼叫傳回字串。 如需詳細資訊,請參閱雙向接聽程式範例範例:雙向接聽程式

REST 接聽程式編碼方式類似於雙向接聽程式。REST 接聽程式的 ABC 如下:

若是 REST 合約,Execute 方法從方法呼叫傳回字串。 如需相關資訊,請參閱 REST 接聽程式範例範例:REST 接聽程式。 請注意,在 REST 接聽程式範例,WebServiceHost 已具現化,而不是在雙向範例中的 ServiceHost

注意

搭配使用內建 (ServiceBusPlugin) 外掛程式與雙向或 REST 接聽程式時,外掛程式不使用從接聽程式傳回的任何字串資料。 不過,自訂 Azure 感知外掛程式可以利用此資訊。

當您執行接聽程式範例時,提示您輸入的簽發者秘密是 Microsoft Azure 服務匯流排 管理金鑰。 WS2007 同盟 HTTP 繫結使用「Token」模式與 WS-Trust 1.3 合約。

篩選訊息

從 Microsoft Dynamics CRM 2015 和 CRM Online 傳送的每個代理訊息 Properties 屬性,都會新增額外資訊的屬性包。 此屬性包 (可用於持續性佇列及主題合約端點) 包含下列資訊。

  • 組織 Url

  • 呼叫使用者識別碼

  • 啟始使用者識別碼

  • 實體邏輯名稱

  • 要求名稱

此資訊可識別 Microsoft Dynamics 365 正在處理而導致服務匯流排訊息張貼的組織、使用者、實體及訊息要求。 您的接聽程式碼可以選擇根據此資訊來處理收到的訊息。其他資訊:範例:執行多個請求

另請參閱

Microsoft Dynamics CRM 2015 Azure 擴充功能
撰寫自訂的 Azure 感知外掛程式
範例:持續性佇列接聽程式
範例:單向接聽程式
範例:雙向接聽程式
範例:REST 接聽程式
透過 Azure 服務匯流排傳送 Microsoft Dynamics CRM 2015 資料

© 2017 Microsoft. 著作權所有,並保留一切權利。 著作權