从 Dynamics 365 运行自定义工作流时出现 2 分钟超时问题

Posted 2023-02-19

【中文标题】从 Dynamics 365 运行自定义工作流时出现 2 分钟超时问题

【英文标题】：2 minute timeout issue when running a custom workflow from Dynamics 365

【发布时间】：2021-12-20 01:31:22

【问题描述】：

我们正在运行由作业触发的工作流。工作流运行 用 C# 开发的自定义工作流活动。代码在 2200 到 10000 之间读取 处理后的记录会更新实体中的某些字段。的 当然，当部署自定义工作流活动插件时，此过程会超时 在沙盒模式下，但在插件部署在非沙盒中时有效 模式（无）。原因是客户不想给我们一个 驻留在部署管理员组中的用户帐户 在非沙盒模式下部署插件的用户是必需的。 是否有另一种将插件部署到 Dynamics 365 的方法 非沙盒模式下的组织？

【问题讨论】：

这个问题感觉超出了范围。尝试指导您的客户如何在不授予您额外权限的情况下切换插件的沙盒模式

【参考方案1】：

documentation 确认用户必须在部署管理员组中。

也许客户可以创建一个他们控制的帐户，然后您引导他们在该帐户下注册插件。

从长远来看，最好考虑一下本地实例有朝一日可能会迁移到云中的可能性，在云中非沙盒注册是不可能的。 （虽然这在未来可能会改变，但微软一直在将一切都推向 Azure，所以我个人不会打赌）。

有鉴于此，考虑重新设计功能以在沙盒的限制范围内运行可能是有意义的。 例如，您可以创建一个 Azure-aware plugin，将上下文发送到 Azure 端点，当它在任何沙盒限制之外处理记录时。 当然，这需要一个 Azure 帐户，并且在本地可能会使连接回 Dynamics 的 Azure 资源变得复杂。

虽然这肯定是一种“破解”，但您可以先运行工作流查询以获取您需要处理的所有 ID，然后开始处理它们。当 2 分钟超时临近时，您可以将未处理记录列表保存到文本字段或 XML Web 资源。 在infinite loop detection 启动之前，工作流最多可以调用自身 7 次，因此您可以再次触发工作流、检索未处理记录的列表并恢复处理。 这是相当复杂的，并假设所有处理都可以在 14 分钟内完成（包括关闭/恢复时间）。首选的解决方案是使用 Azure，但如果没有其他选择，这也可行。

而且，如果您想使用简历功能变得更加老练，总是有旧的 Bulk Deletion trick。