通过

为 Windows 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 支持的三种其他服务总线合同编写监听程序：单向、双向和 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 CRM 2015 和 CRM Online）的额外信息都有属性包。 该属性包可用于持久队列和主题合同终结点，包含以下信息。

  • 组织 Url

  • 调用用户 ID

  • 发起用户 ID

  • 实体逻辑名称

  • 请求名称

此信息识别由 Microsoft Dynamics 365 处理的组织、用户、实体和信息请求，从而使服务总线消息得到发布。 您的侦听代码可选择处理基于此信息接收到的消息。详细信息：示例：执行多个请求

另请参阅

Microsoft Dynamics CRM 2015 的 Azure 扩展
编写 Azure 感知自定义插件
示例：持久队列侦听器
示例：单向侦听器
示例：双向侦听器
示例：REST 侦听器
通过 Azure 服务总线发送 Microsoft Dynamics CRM 2015 数据

© 2017 Microsoft。 保留所有权利。 版权