上一篇

下一步

轮询触发器

已完成

轮询触发器是定期调用 REST API 服务并检查新数据的实施。 平台确定新数据可用后，触发器将新收集的数据传递到云端流或逻辑应用工作流。

以下图表展示轮询触发器获取新数据的基本流程。

轮询触发器先检索数据并设置状态。 然后通过请求自上次状态更新以来的所有数据定期检查更新。 检索新数据后设置新状态，流程继续运行。 API 需要能够基于参数值增量返回数据。 Power Automate 或 Azure 逻辑应用维护状态，因此 API 并无特殊的状态管理要求。

轮询触发器不同于 webhook 触发器，无设置或拆分要求并且可以随时停止处理。 简化要求是轮询触发器的一项主要优势。

API 要求

轮询触发器仅要求 API 具有可以使用查询字符串参数筛选数据的数据检索方法。 还必须存在从返回的数据中提取下一个参数值的方法。 可通过专用操作或现有操作方法提供实施。

例如考虑订单编号不断增长的在线商店实施。 商店 API 可能包括名为ListOrders的方法，返回商店中创建的订单。

• ListOrders 返回按订单编号降序排序的订单。 因此最大的订单编号属于列表中的第一个订单。

• ListOrders 接受查询字符串参数检索订单编号大于参数值的订单。

这两个特性允许将操作用作轮询触发器。 平台可在返回的数据中提取最大的订单编号并将其作为参数传入下一个请求。 实际上，该方法将“选择自上一个订单以来创建的所有订单”。

实施

使用 Power Automate 中的向导创建轮询触发器。 本流程包括以下步骤：

1. 定义用于检索数据的 HTTP 请求。

   

   请求的查询字符串包括fromWidget参数，该参数启用参数定义预生成。 本参数确保返回增量数据，将“返回自参数指定小组件后创建的所有小组件”。

2. 将参数可见性改为内部，防止用户对本参数进行更改，本参数仅供连接器内部使用。

3. 定义服务返回的数据。 本数据应包括要在连续请求中用作fromWidget值的属性。

   

   在本示例中，属性称为ID。

4. 完成触发器配置。 选择查询参数，定义值或返回值的表达式，然后选择包含触发数据的集合。

   

   本示例包括以下参数：

   • 选择 fromWidget 作为查询参数，接收从实验结果中提取的值。

   • @{triggerBody().widgets[0].id} 表达式提取当前最大的小组件 ID。 返回的集合按 ID 值降序排序，因此从第一个元素中提取值有助于确保值为当前最大 ID。

   • @triggerBody().widgets 表达式定义数据集合。

需要提取并处理参数，本转换只能使用连接器策略来实施。 因此，轮询触发器配置存储为独立于 OpenAPI 连接器定义的策略模板。 其中一项影响在于无法在 Swagger 编辑器中手动编辑所有轮询触发器配置。

您需要注意的限制是触发器正文不能是数组。 例如考虑返回以下数据的ListOrders方法：

[
  {"value" : 42.00, "id" : "2", ... },
  {"value" : 10.00, "id" : "1", ... }
]

不处理本触发器正文，触发器将在运行时在 Power Automate 流或逻辑应用工作流中生成错误。

相反，该方法需要返回包含记录数组的属性，例如：

{
  "orders": [
    { "value" : 42.00, "id" : "2", ... },
    { "value" : 10.00, "id" : "1", ... }
  ]
}  

本数据结构可用作轮询触发器实施的一部分。

批处理

轮询触发器类似于 Webhook 触发器，由扩展到 OpenAPI 的x-ms-trigger定义。 轮询触发器定义的值是批处理，指示该方法将返回数组而非单个对象，类似于 Webhook 响应。

  /trigger/ListInvoices:
    post:
      x-ms-trigger: batch

发生本流程的原因是单次调用服务可以返回多个记录。 在 Power Automate 或逻辑应用中使用轮询触发器时，触发器拆分设置允许配置处理模式。

出于性能原因，将传入数组拆分为多并行实施。 本应用场景中的每个云端流实例都将接收单个对象。 如未设置拆分选项，单们云端流实例将接收值数组。

轮询触发器比 Webhook 触发器更容易定义；但精细度较低，通常也不执行。 生成和使用某类触发器的决定受服务 API 的功能、结构和功能驱动。

继续