如何使用标准 Azure 逻辑应用的无状态工作流可靠地处理 Azure 服务总线消息

Question

我们有一个具有无状态工作流的标准逻辑应用。对于 Azure 服务总线，触发器是“当消息在队列中可用时”，下一步是 For each 循环。由于限制，这种组合似乎存在缺陷，并导致两个问题。

1. 无状态触发器似乎只允许自动完成，因此出现错误时所有消息都会丢失。
2. 无状态触发器似乎不允许配置批处理，因此任何大于 100 的批处理都会导致以下错误。

无效的模板。无法处理“{line}”行和“{column}”列的操作“For_each”的模板语言表达式：“操作“For_each”的 foreach 项目数超出限制：最大“100”和实际“{messageCount}” '.'。

我在这里遗漏了什么，还是有状态工作流是处理 Azure 服务总线消息的唯一可靠方法？

[编辑] - 使用 host.json 文件中的extensions.serviceBus.prefetchCount 配置可以limit the number of messages that are read from the queue in a batch，但由于“for each”控制操作的限制，最大数量将是 100。在使用 I1V2 ASP 的 ASE 负载下，我们观察到每个工作流执行抓取 66 条消息并花费约 4 秒（工作流进行一些转换并进行 HTTP POST）。

[编辑] - 2021 年 10 月，Microsoft 发布了 peek lock 触发器和使用内置连接器完成消息的功能。这个问题不再相关。

Answer 1

我们在本地环境中进行了测试，以下陈述基于我们的分析。

1. 无状态触发器似乎只允许自动完成，因此出现错误时所有消息都会丢失。

根据Azure documentation，服务总线队列支持2个触发器

1. 在队列中收到消息时（自动完成）
2. 在队列中收到消息时（窥视锁定）

在基于消费的逻辑应用中，您可以在逻辑设计器中选择上述任一触发器

这里是截图供参考：

如果您使用标准计划逻辑应用程序，而不管有状态或无状态工作流程，您将拥有以下服务总线队列触发器When a message is received in a queue 并且它没有任何选项来确认它是自动完成还是偷看-锁。

这是供参考的屏幕截图：

1. 无状态触发器似乎不允许配置批处理，因此任何大于 100 的批处理都会导致以下结果 错误。

无效的模板。无法处理“{line}”行和“{column}”列的操作“For_each”的模板语言表达式：“数字 超出操作“For_each”的 foreach 项目限制：最大“100” 和实际的“{messageCount}”。

根据 Azure documentation ， For_each loop 在逻辑应用程序中默认仅支持 100 个项目，如果您使用的是无状态工作流。如果您使用有状态的工作流程，它支持 1,00,000 个项目。