使用 SQL 存储过程将 MS Dynamics CRM AsyncOperationBase table 中的工作流状态更新为已取消，状态并不总是持续存在
Updating workflow status to cancelled in the MS Dynamics CRM AsyncOperationBase table with a SQL stored procedure, status not always persisting
我目前正在诊断 MS Dynamics CRM 2013 的实施问题，如果应用程序中的某些条件得到满足，CRM 中的系统作业在创建后不久就会以编程方式取消。但是，这些工作流程并未取消，而是继续处理 - 我想知道这是否是由于使用了 SQL 存储过程来更新 CRM 数据库。
这是当前（简化的）流程：
- 应用程序中的事件使用 MS XRM OrganizationServiceProxy 方法触发 CRM 工作流。
- 应用程序中出现问题，我们希望取消最近请求启动的工作流。
- "cancel workflow" 请求已保存，并由自定义应用程序拾取和处理以在不久后进行处理。
- 此应用程序运行是一个存储过程，用于查找相关的 AsyncOperation 条目，并将 ModifiedOn 设置为 getdate()，将 StatusCode 设置为 32（已取消）并将 StateCode 设置为 3（已完成）。
成功处理取消后的一段时间（由我们的应用程序审核），工作流有时会继续处理，并且 StatusCode/StateCode 将不再是 32 和 3。 AsyncOperation 中修改的 DateTime table 也将晚于应用程序的 "cancel workflow request processed" DateTime。
我已经尝试检查 "StartWorkflow" 请求是否尚未被我们的应用程序处理 - 但在任何情况下，在我们尝试阻止它之前，它都已发送到 CRM。因此，CRM 知道工作流，但更新 AsyncOperation table 不会导致它取消。在许多情况下，CreatedOn and/or ModifiedOn 日期时间是在我们尝试停止工作流之后，但是，尽管启动工作流请求之前转到 CRM。
我的主要问题是 - 使用以下方式向 OrganizationServiceProxy 更新 AsyncOperation 发送请求是否有区别：
workflow.Attributes["statecode"] = new OptionSetValue(3);
workflow.Attributes["statuscode"] = new OptionSetValue(32);
organizationServiceProxy.Update(workflow);
...与直接更新 StateCode 和 StatusCode 的存储过程相比？我读过直接更新 CRM 数据库通常不是一个好主意，但是通过从组织服务中检索异步操作然后告诉它更新特定列，它所做的只是存储过程会做什么？这是一个 CRM 系统，有大量的工作流被触发，负载很大，所以我有一个理论，它可能归结为在 CRM 中被触发启动的工作流（但处于排队状态）不会在AsyncOperation table 直到 CRM 接收它...这可能解释了某些条目的 "CreatedOn" 日期略晚于请求停止它的处理日期。但是，我不确定当工作流处于排队状态时，它们在数据库中的存储位置，或者即使它们不会立即进入 AsyncOperation table。我想知道将请求发送到可能 运行 与我相同 SQL 的 CRM 是否是一个可行的解决方案，或者是否有人知道可能导致 CRM 工作流程继续的其他因素处理和覆盖 StateCode/StatusCode 尽管 statecode/statuscode 设置为 cancelled/completed?
由于生产负载，任何我可以减少抽象并直接影响数据库的情况不仅受欢迎，而且几乎是必需的，因为 CRM 中的超时和性能低下。
我每天在生产中看到大约 50 个这样的例子，所以它不是孤立的，但我无法在测试环境中重现它......这让我更相信这是一个负载问题，但 CRM 是否有额外的步骤它更新 AsyncOperation table 中的 Statecode/Status 代码是我主要关心的问题。谢谢！
My main question is - is there a difference between sending a request to the OrganizationServiceProxy update AsyncOperation using:
workflow.Attributes["statecode"] = new OptionSetValue(3);
workflow.Attributes["statuscode"] = new OptionSetValue(32);
organizationServiceProxy.Update(workflow);
...versus a stored procedure that updates StateCode and StatusCode
directly?
差别很大。除了极少数例外情况，例如创建自定义索引、从过滤视图中读取和调整某些设置，直接在 Dynamics SQL 不支持数据库，尤其是直接向表写入数据。
除了非常有限的例外，一切都必须通过 API（即实现 IOrganizationService 的 OrganizationServiceProxy）完成。 CRM 是一个基于消息的平台。如果您直接写入 SQL，则会绕过它的整个消息传递系统，导致不可预测和不受支持的结果。
在您的场景中，您的 SQL 存储过程可能不知道发生其他事情。简而言之，您应该通过 API 实现您想要实现的任何目标，并摆脱对 CRM 数据库的所有 SQL 写入。
Due to load in production, any case where I can reduce abstraction and
just directly affect the DB is not just welcome, but almost a
necessity, due to timeouts and slow performance in CRM.
虽然很想直接在数据库上操作，但请将 CRM 视为 API 而不是数据库。
考虑到这一点，您可以继续 performance analysis and optimization。
对于初学者来说，分析慢速查询并添加一些 indexes. And, since the Filtered Views 在数据库级别强制执行安全模型可能会有所帮助，从中读取任何报告或自定义集成可能会有所帮助。
听起来您要达到受支持状态还有很长的路要走。
我目前正在诊断 MS Dynamics CRM 2013 的实施问题，如果应用程序中的某些条件得到满足，CRM 中的系统作业在创建后不久就会以编程方式取消。但是，这些工作流程并未取消，而是继续处理 - 我想知道这是否是由于使用了 SQL 存储过程来更新 CRM 数据库。
这是当前（简化的）流程：
- 应用程序中的事件使用 MS XRM OrganizationServiceProxy 方法触发 CRM 工作流。
- 应用程序中出现问题，我们希望取消最近请求启动的工作流。
- "cancel workflow" 请求已保存，并由自定义应用程序拾取和处理以在不久后进行处理。
- 此应用程序运行是一个存储过程，用于查找相关的 AsyncOperation 条目，并将 ModifiedOn 设置为 getdate()，将 StatusCode 设置为 32（已取消）并将 StateCode 设置为 3（已完成）。
成功处理取消后的一段时间（由我们的应用程序审核），工作流有时会继续处理，并且 StatusCode/StateCode 将不再是 32 和 3。 AsyncOperation 中修改的 DateTime table 也将晚于应用程序的 "cancel workflow request processed" DateTime。
我已经尝试检查 "StartWorkflow" 请求是否尚未被我们的应用程序处理 - 但在任何情况下，在我们尝试阻止它之前，它都已发送到 CRM。因此，CRM 知道工作流，但更新 AsyncOperation table 不会导致它取消。在许多情况下，CreatedOn and/or ModifiedOn 日期时间是在我们尝试停止工作流之后，但是，尽管启动工作流请求之前转到 CRM。
我的主要问题是 - 使用以下方式向 OrganizationServiceProxy 更新 AsyncOperation 发送请求是否有区别：
workflow.Attributes["statecode"] = new OptionSetValue(3);
workflow.Attributes["statuscode"] = new OptionSetValue(32);
organizationServiceProxy.Update(workflow);
...与直接更新 StateCode 和 StatusCode 的存储过程相比？我读过直接更新 CRM 数据库通常不是一个好主意，但是通过从组织服务中检索异步操作然后告诉它更新特定列，它所做的只是存储过程会做什么？这是一个 CRM 系统，有大量的工作流被触发，负载很大，所以我有一个理论，它可能归结为在 CRM 中被触发启动的工作流（但处于排队状态）不会在AsyncOperation table 直到 CRM 接收它...这可能解释了某些条目的 "CreatedOn" 日期略晚于请求停止它的处理日期。但是，我不确定当工作流处于排队状态时，它们在数据库中的存储位置，或者即使它们不会立即进入 AsyncOperation table。我想知道将请求发送到可能 运行 与我相同 SQL 的 CRM 是否是一个可行的解决方案，或者是否有人知道可能导致 CRM 工作流程继续的其他因素处理和覆盖 StateCode/StatusCode 尽管 statecode/statuscode 设置为 cancelled/completed?
由于生产负载，任何我可以减少抽象并直接影响数据库的情况不仅受欢迎，而且几乎是必需的，因为 CRM 中的超时和性能低下。
我每天在生产中看到大约 50 个这样的例子，所以它不是孤立的，但我无法在测试环境中重现它......这让我更相信这是一个负载问题，但 CRM 是否有额外的步骤它更新 AsyncOperation table 中的 Statecode/Status 代码是我主要关心的问题。谢谢！
My main question is - is there a difference between sending a request to the OrganizationServiceProxy update AsyncOperation using:
workflow.Attributes["statecode"] = new OptionSetValue(3);
workflow.Attributes["statuscode"] = new OptionSetValue(32);
organizationServiceProxy.Update(workflow);
...versus a stored procedure that updates StateCode and StatusCode directly?
差别很大。除了极少数例外情况，例如创建自定义索引、从过滤视图中读取和调整某些设置，直接在 Dynamics SQL 不支持数据库，尤其是直接向表写入数据。
除了非常有限的例外，一切都必须通过 API（即实现 IOrganizationService 的 OrganizationServiceProxy）完成。 CRM 是一个基于消息的平台。如果您直接写入 SQL，则会绕过它的整个消息传递系统，导致不可预测和不受支持的结果。
在您的场景中，您的 SQL 存储过程可能不知道发生其他事情。简而言之，您应该通过 API 实现您想要实现的任何目标，并摆脱对 CRM 数据库的所有 SQL 写入。
Due to load in production, any case where I can reduce abstraction and just directly affect the DB is not just welcome, but almost a necessity, due to timeouts and slow performance in CRM.
虽然很想直接在数据库上操作，但请将 CRM 视为 API 而不是数据库。
考虑到这一点，您可以继续 performance analysis and optimization。
对于初学者来说，分析慢速查询并添加一些 indexes. And, since the Filtered Views 在数据库级别强制执行安全模型可能会有所帮助，从中读取任何报告或自定义集成可能会有所帮助。
听起来您要达到受支持状态还有很长的路要走。