azure - 自定义逻辑应用连接器

Question

我们正在创建一个 Multi-Tenancy 应用程序。为了允许用户创建业务逻辑，我们希望使用逻辑应用程序。

因此，我想创建一个 Web 应用程序来公开 DocumentDB 更改源。创建逻辑应用时，您可以在不同的现成连接器之间进行选择。我们如何才能将我们的纳入列表中？有相关文档吗？

这个想法是让逻辑应用在每次插入文档时运行。为了实现这一目标，我有两个选择:轮询触发器和 Webhook 触发器。我更喜欢轮询触发器，因为这比实现逻辑来处理每个租户的所有订阅 URL 的工作量要少。有人对此方法有疑问/建议吗？

位置 header 应该成为我来自 DocumentDB 更改源的继续标记，对吗？

1. 逻辑应用将在没有位置 header 的情况下首次调用我的 api

2. 我的 api 将调用 DocDb，而无需继续标记，这将一一返回所有文档，因为最大文档计数设置为 1

3. 我的 api 将返回检索到的第一个文档，并将重试后设置为 0，并将位置设置为我收到的新继续 token 。如果没有找到文档，API 将像步骤 5 一样返回结果。

4. 逻辑应用将启动一个新实例来处理文档，并使用 header 中的继续 token 再次调用 API。

将重复步骤 3 至 4，直到处理完所有文档。因为我每个逻辑应用实例只处理一个文档，Azure 应该能够自动为我扩展？

处理完所有文档后，API 将返回 202 状态代码，其中位置 header 设置为最新的延续 token ，重试后设置为 15。

15 秒后，逻辑应用将使用最新的延续 token 调用我们的 api。这将再次触发该过程。

我的解决方案可行吗？如果由于某种原因我需要停止或克隆逻辑应用配置，我如何知道最新的延续是什么，或者我是否需要将延续 token 保存在某些数据存储中？

Answer 1

是的，您在此处描述的内容应该得到支持。您可以在逻辑应用中使用自己的连接器，方法是单击搜索上方的下拉列表，然后选择使用 API 管理或应用服务中的 API，详细信息 here和 here 。

假设您使用上面的 202 轮询模式，则可以将继续 token 保留在 location header 的“触发状态”中。例如， header 可能是 https://mydocdbconnector.azurewebsites.net/api/trigger?triggerstate={thisCouldBeTheContinuationToken} ——这样，在后续轮询中，最后一个连续 token 将发送回触发器并且可以在手术中使用。只要触发器在定义中保持不变(启用/禁用等都保留触发器状态)，触发器状态就会保留。

我唯一不清楚的部分是您的 Multi-Tenancy 要求。我假设您的意思是您希望每个用户都能够在自己的 documentDb 实例上触发 - 目前最好的支持模式是为每个客户拥有一个逻辑应用程序 - 每个用户都有自己的 triggerState 和触发器。这也可以利用自定义连接器。这是像Microsoft Flow这样的服务的模式。使用基于逻辑应用构建的。

请告诉我这是否有帮助。