为 Windows Azure 解决方案编写监听应用程序

 

发布日期: 2017年1月

适用于: Dynamics 365 (online),Dynamics 365 (on-premises),Dynamics CRM 2016,Dynamics CRM Online

本主题介绍如何编写可读取和处理发布到 Microsoft Azure 服务总线 的 Microsoft Dynamics 365 消息的 Microsoft Azure 解决方案监听程序。 作为一个先决条件,在尝试了解 Microsoft Dynamics 365 监听程序的细节之前,应该熟悉如何编写 Microsoft Azure 服务总线 监听程序。 有关详细信息,请参阅 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 是指:地址 (Address)、绑定 (Binding) 和合同 (Contract)。 以下信息标识单向监听程序的 ABC。

向终结点注册监听程序后,Microsoft Dynamics 365 每次将消息发布到服务总线时,都会调用该监听程序的 Execute 方法。Execute 方法不会从方法调用中返回任何数据。 有关详细信息,请参阅单向侦听器示例,示例:单向侦听器

双向监听程序的编码方式与单向监听程序类似。 双向监听程序的 ABC 如下:

对于此双向合同,执行方法在调用后返回字符串。 有关详细信息,请参阅双向侦听器示例,示例:双向侦听器

REST 监听程序的编码方式与双向监听程序类似。REST 监听程序的 ABC 如下:

对于 REST 合同,Execute 方法从方法调用中返回一个字符串。 有关详细信息,请参阅 REST 监听程序示例示例:REST 侦听器。 请注意,在 REST 监听程序示例中,实例化 WebServiceHost,而不是像双向示例中那样实例化 ServiceHost

备注

将自带的 (ServiceBusPlugin) 插件与双向或 REST 监听程序配合使用时,该插件不使用从监听程序返回的任何字符串数据。 但是,自定义 Azure- 感知插件可以利用此信息。

在运行监听程序示例时,提示您的颁发者密钥是 Microsoft Azure 服务总线 管理密钥。 WS2007 联合 HTTP 绑定使用“令牌”模式和 WS-Trust 1.3 协议。

筛选器消息

添加到每个代理消息属性 属性(发送自 Microsoft Dynamics 365 和 Dynamics 365(在线))的额外信息都有属性包。 该属性包可用于队列、邮件中继和主题合同终结点,包含以下信息:

  • 组织 URI

  • 调用用户 ID

  • 发起用户 ID

  • 实体逻辑名称

  • 请求名称

此信息识别由 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。 保留所有权利。 版权