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

Question

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

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

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

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

[编辑] - 使用extensions.serviceBus.prefetchCounthost.json 文件中的配置可以限制批量从队列中读取的消息数量，但由于“for each”控制操作的限制，最大数量将是100.在使用 I1V2 ASP 的 ASE 负载下，我们观察到每个工作流执行抓取 66 条消息并花费约 4 秒（工作流进行一些转换并进行 HTTP POST）。

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

Answer 1

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

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

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

1. 在队列中收到消息时（自动完成）
2. 在队列中收到消息时（peek-lock）

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

这是供参考的屏幕截图：

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

这是供参考的屏幕截图：

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

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

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