【问题标题】:LogicApp that returns newly generated ID back to original source将新生成的 ID 返回到原始源的 LogicApp
【发布时间】:2020-11-16 05:18:26
【问题描述】:

您好,我正在尝试首先创建一个 LogicApp

  1. 从 CosmosDB 中提取数据,使用查询

  2. 循环遍历结果

  3. 将结果数据推送到 CRM

旁注:一旦这些数据被推送到 CRM 中,CRM 会自动为每条记录生成一个 ID。那我该怎么办:

  1. 我最大的难题是弄清楚如何将新生成的 ID 返回到从中提取它的原始 CosmosDB 容器中?

我已经开始了,这些是我的问题:

这第一部分在我正在做的事情中看起来正确吗?我必须为此使用这个 SQL 查询:

一个。我只是告诉逻辑应用从 CosmosDB 中的特定容器中提取数据

b.然后我想循环一下我刚刚得到的结果,然后把它推送到CRM

c。我的困境是:

一旦数据被推送到 CRM,CRM 就会自动为每条上传的记录生成一个 ID我如何将更新后的 ID 返回给 cosmos?

我是否应该创建一个存储 IDS 的变量,然后用新 ID 替换旧 ID?

我不确定如何在 LogicApps 中构建/编写此逻辑,并且一直在研究这方面的示例。

非常感谢任何帮助。

谢谢

【问题讨论】:

标签: azure azure-functions dynamics-crm azure-cosmosdb azure-logic-apps


【解决方案1】:

如果对您的 CRM 系统的调用返回您正在谈论的 ID,那么我只需在 Azure Logic App 的循环中添加一个额外的操作,以更新 Azure Cosmos DB 中的读取记录。鉴于您正在从容器中执行SELECT *,您应该拥有整个原始文档。

添加“创建或更新文档”操作作为一个步骤,并引用THFeature 容器以及您的Database ID,然后为文档提供新值。我在下面粘贴了一个示例。

顺便说一句。您的选择查询看起来很奇怪 - 如果可以,您应该避免缓慢的跨分区查询。

【讨论】:

  • 谢谢马丁!这可能有效!我是从一个小集合中提取的,这就是我使用这个特定的 SELECT 语句的原因。 “跨分区查询慢”意味着它没有时间效率?
  • 如果它是一个小数据集,那么它不会产生太大影响,但是当它开始增长时,您希望避免跨分区查询,从而有效地扫描您的所有数据。如果您觉得有帮助,请采纳答案。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-11-18
  • 1970-01-01
  • 2021-03-16
  • 2020-05-30
  • 1970-01-01
  • 2021-11-05
  • 2018-04-20
相关资源
最近更新 更多