MS CRM MaxDepth 工作流程设置

Question

具体来说，是 MS CRM 2011。这实际上是四题合一：

A.为什么选择 8 作为默认限制？ （这是任意的吗，原始深度计数器是 3 位整数（虽然执行上下文的深度是 32 位有符号的），开发人员只是在考虑 2 的幂，9 是一个邪恶的数字......）

B.将其增加到 16 有什么危险？ （除了以某种方式通过测试的错误递归设置现在会在出错之前潜水 16 次而不是 8 次，而且根据实际情况的糟糕程度，我可能仍然会遇到一些无限循环错误）

C.更改此设置的脚本是否必须在每台 CRM 服务器上运行或仅在其中一个服务器上运行？ （或者我猜，这是存储在本地配置中还是共享的）

D.这是提出这类问题的最佳论坛吗？ （我觉得开发问题有点边界。）

请注意，我已经有了执行此操作的脚本，我了解执行上下文深度是什么，并且我知道如何减少过度深度的可能性。这些不是我的问题，或者至少不是我可以做任何事情的问题。谢谢。

Answer 1

您已经涵盖了上一段中的大部分答案，所以我将从回答问题 D 开始 - 这可能不是提出这些问题的最佳论坛。有些人会发现它们过于宽泛或基于意见。

至于其他问题：

• A.我不知道为什么选择这个值。

• B.最好避免导致问题的情况，而不是提高阈值。我确信您的系统可以在高于 8 的设置下工作，但您可能隐藏了糟糕的设计或其他一些问题。您提到这超出了您的控制范围，但对于其他阅读本文的人，请尝试解决问题或提出更好的设计。

• C.您无需更改每台服务器上的设置。您提到您知道如何更改它，但我会在此处为阅读此答案的其他人提供脚本。

  这是一个将值设置为 n 的 PowerShell 脚本：

  Add-PSSnapin Microsoft.Crm.PowerShell
  $setting = Get-CrmSetting WorkflowSettings
  $setting.MaxDepth=n
  Set-CrmSetting $setting
  

Answer 2

A) 它用于无限循环保护，所以我猜选择这个值是因为它代表了保护性能和功能之间的理想平衡（尽管您需要询问 Microsoft 来确定）。对MSDN稍作阐述：

平台用于防止无限循环。在大多数情况下，这 属性可以忽略。

每次运行插件或工作流向 触发另一个插件或工作流执行的 Web 服务， 执行上下文的 Depth 属性增加了。如果深度 属性在配置的时间内增加到最大值 限制，平台将此行为视为无限循环，并且 进一步的插件或工作流执行被中止。最大深度 (8) 和时间限制（一小时）由微软配置 Dynamics CRM 管理员。

B) 特别是长时间运行的进程可能会影响系统性能（因为其他系统作业在长时间运行的进程后面排队）。如果我在限制防止性能问题方面是正确的，那么提高限制可能会危及您的系统性能。

一般来说，这些不是我们应该更改的设置（如果更改会更容易，例如通过用户界面）。我们可以假设（并希望）微软选择这个值是有原因的（即使我们不确定是哪个原因）。我们可以合理地假设，我们比最初的系统开发人员更了解此设置的功能、作用和可能的副作用。因此，更改设置存在风险，因为我们不完全了解（通过比较）它的作用或它会导致的副作用。

这里还有一个问题是你并没有真正解决问题。在正常使用中，您不应接近此限制。解决症状并不能解决问题。如果是我，并且我处于你的位置，增加限制不是我会使用的解决方案。

最后，让进程运行更长时间可能意味着你会遇到 2 分钟 timeout。

无论插件是同步执行还是同步执行 异步地，有 2 分钟的时间限制施加在 执行在沙箱中注册的插件。如果执行 你的插件逻辑超过了时间限制，一个 System.TimeoutException 被抛出。如果插件需要超过 2 分钟的处理时间 时间限制，考虑使用工作流或其他后台进程 完成预期的任务。

C) 我相信的每一个服务器。

D) 我建议阅读Asking，如果您认为该问题合适，请提出。更糟糕的是，问题被否决并关闭。如果您想进一步讨论，请将其发送至Meta。