共用方式為

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

  • 發行項

 

發行︰ 2017年1月

適用於： Dynamics 365 (online)、Dynamics 365 (on-premises)、Dynamics CRM 2016、Dynamics CRM Online

本主題描述如何撰寫 Microsoft Azure 解決方案接聽應用程式，可讀取和處理張貼至 Microsoft Azure 服務匯流排 的 Microsoft Dynamics 365 訊息。 先決條件是，您應該熟悉的如何撰寫 Microsoft Azure 服務匯流排 接聽程式，然後嘗試了解 Microsoft Dynamics 365 接聽程式的特性。 如需詳細資訊，請參閱 Azure 服務匯流排文件。

本主題內容

撰寫佇列接聽程式

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

篩選訊息

以多種資料格式讀取資料內容

撰寫佇列接聽程式

訊息「佇列」為出現在服務匯流排端點之訊息的儲存庫。 「佇列接聽程式」是讀取和處理這些已佇列訊息的應用程式。 因為服務匯流排訊息是儲存在佇列中，接聽程式不需要主動地接聽，佇列中即可收到訊息。 佇列接聽程式可在訊息抵達佇列之後啟動，而且仍然會處理這些訊息。 在下一節討論的接聽程式其他類型必須主動地接聽，否則會遺失讀取訊息的機會。 這些訊息可以是源自 Microsoft Dynamics 365 或源自特定其他來源。 .

重要

當撰寫佇列接聽程式時，檢查每個訊息標頭動作，判斷訊息是否源自 Microsoft Dynamics 365。 如需如何執行的資訊，請參閱篩選訊息。

您可以在 ReceiveAndDelete 模式下使用 Receive 執行破壞性訊息讀取，也就是讀取訊息並從佇列中移除，或使用 PeekLock 模式執行非破壞性讀取，也就是讀取訊息但仍然位於佇列中。 此 SDK 所提供的持續性佇列接聽程式範例程式碼會執行破壞性讀取。 如需從佇列中讀取訊息的詳細資訊，請參閱如何從佇列接收訊息。

「主題」類似佇列，但實作發行/訂閱模型。 一個或多個接聽程式可以訂閱主題並從其佇列接收訊息。其他資訊：佇列、主題和訂閱

重要

若要使用這些佇列或主題合約，必須使用 Azure SDK 版本 1.7 或更新版本撰寫接聽應用程式。

使用多系統軟體設計中的佇列及主題會造成系統解除耦合。 如果接聽程式應用程式變得無法使用，從 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 365 和 Dynamics 365 (線上) 傳送的每個代理訊息 Properties 屬性，都會新增額外資訊的屬性包。 此屬性包 (可用於佇列、中繼及主題合約端點) 包含下列資訊：

  • 組織 URI

  • 呼叫使用者識別碼

  • 啟始使用者識別碼

  • 實體邏輯名稱

  • 要求名稱

此資訊可識別 Microsoft Dynamics 365 正在處理而導致服務匯流排訊息張貼的組織、使用者、實體及訊息要求。 這些屬性可用，就表示訊息是傳送自 Microsoft Dynamics 365。 您的接聽程式碼可決定如何根據這些值處理訊息。

以多種資料格式讀取資料內容

來自目前 Microsoft Dynamics 365 作業的資料內容會傳遞至您的 Azure 解決方案接聽應用程式的服務匯流排訊息的本文中。 在舊版中，僅支援 .NET 二進位格式。 對於跨平台 (非 .NET) 互通性，您現在可以指定三種資料格式之一用於訊息本文：.NET 二進位、JSON 或 XML。 此格式是在 ServiceEndpoint 實體的 MessageFormat 屬性中指定。

注意

CRM Online 2016 更新 1 和 CRM 2016 Service Pack 1 (內部部署) 已經引進此功能。

當收到訊息時，您的接聽應用程式可以根據訊息的內容類型讀取訊息本文中的資料內容。 以下是如何執行的範例程式碼。

var receivedMessage = inboundQueueClient.Receive(TimeSpan.MaxValue);

if (receivedMessage.ContentType = "application/msbin1")
{
    RemoteExecutionContext context = receivedMessage.GetBody<RemoteExecutionContext>();
}
else if (receivedMessage.ContentType = "application/json")
{
    //string jsonBody = new StreamReader(receivedMessage.GetBody<Stream>(), Encoding.UTF8).ReadToEnd();
    RemoteExecutionContext contextFromJSON = receivedMessage.GetBody<RemoteExecutionContext>(
        new DataContractJsonSerializer(typeof(RemoteExecutionContext)));
}
else if (receivedMessage.ContentType = "application/xml")
{
    //string xmlBody = new StreamReader(receivedMessage.GetBody<Stream>(), Encoding.UTF8).ReadToEnd();
    RemoteExecutionContext contextFromXML = receivedMessage.GetBody<RemoteExecutionContext>(
        new DataContractSerializer(typeof(RemoteExecutionContext)));
}

另請參閱

Microsoft Dynamics 365 Azure 擴充功能
撰寫自訂的 Azure 感知外掛程式
範例：持續性佇列接聽程式
範例：單向接聽程式
範例：雙向接聽程式
範例：REST 接聽程式
在 Azure 解決方案中使用 Dynamics 365 資料
在 Azure 事件中心解決方案中使用 Dynamics 365 事件資料

Microsoft Dynamics 365

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