Question

我目前正在诊断MS Dynamics CRM 2013的实施问题，如果满足应用程序中的某些条件，则CRM中的系统作业在创建后将以编程方式取消。但是，这些工作流尚未取消，而是继续处理-我想知道这是否是由于使用SQL存储过程来更新CRM数据库。

这是当前（简化）的过程：

应用程序中的事件使用MS XRM OrganizationServiceProxy方法触发CRM工作流。
应用程序中发生了某些事情，因此我们希望取消最近被要求启动的工作流程。
“取消工作流程”请求已保存，并由自定义应用程序提取和处理，以在之后不久处理。
此应用程序运行一个存储过程，该存储过程查找相关的AsyncOperation条目，并将ModifiedOn设置为getdate（），将StatusCode设置为32（已取消），将StateCode设置为3（已完成）。

成功处理取消后的一段时间（经我们的应用程序审核），工作流有时将继续处理，并且StatusCode / StateCode不再是32和3。AsyncOperation表中的修改后的DateTime也将是晚于应用程序的“已取消工作流程请求已处理”日期时间。

我已经尝试检查“ StartWorkflow”请求是否尚未由我们的应用程序处理-但是在每种情况下，它都已发送到CRM，然后再尝试停止。因此，CRM知道工作流程，但是更新AsyncOperation表不会导致其取消。在很多情况下，CreatedOn和/或ModifiedOn日期时间是在我们尝试停止工作流之后，但是，尽管开始工作流请求之前已转到CRM。

我的主要问题是-使用以下命令向OrganizationServiceProxy更新AsyncOperation发送请求之间是否有区别？

workflow.Attributes["statecode"] = new OptionSetValue(3);
workflow.Attributes["statuscode"] = new OptionSetValue(32);
organizationServiceProxy.Update(workflow);

...与直接更新StateCode和StatusCode的存储过程相反？我已经读到直接更新CRM DB通常是个坏主意，但是可以肯定的是，通过从组织服务中检索异步操作，然后告诉它更新特定的列，它所要做的就是存储过程将要做什么？这是一个CRM系统，具有大量触发的工作流和大量的负载，因此我有一个理论认为，它可能取决于已触发以CRM启动（但处于排队状态）的工作流不会处于AsyncOperation表，直到CRM提取它为止。。。这可以解释为某些条目的“ CreatedOn”日期稍晚于停止它的请求的处理日期。但是，我不确定当工作流处于排队状态时，或者即使它们不立即进入AsyncOperation表时，它们在数据库中的存储位置也不确定。我想知道是否将请求发送到CRM可能在其中运行与我相同的SQL是可行的解决方案，或者是否有人知道可能导致CRM工作流继续处理并覆盖StateCode / StatusCode的其他元素尽管将状态码/状态码设置为取消/完成？

由于生产中的负载，在任何情况下我都可以减少抽象并直接影响数据库，这不仅受到欢迎，而且由于CRM的超时和性能下降而几乎是必须的。

我每天在生产中看到大约50个这样的示例，因此它不是孤立的，但是我无法在测试环境中重现它。这使我更加相信这是一个负载问题，但是CRM更新时是否还有其他步骤我主要关心的是AsyncOperation表中的Statecode / Status代码。谢谢！

Answer 1

我的主要问题是-使用以下命令向OrganizationServiceProxy更新AsyncOperation发送请求之间是否有区别？

workflow.Attributes["statecode"] = new OptionSetValue(3);
workflow.Attributes["statuscode"] = new OptionSetValue(32);
organizationServiceProxy.Update(workflow);

...与更新StateCode和StatusCode的存储过程相比直接吗？

两者之间存在巨大差异。除了极少数例外，例如创建自定义索引，从“过滤视图”中读取信息以及调整某些设置，不直接进行Dynamics SQL数据库的操作，尤其是不支持直接将数据写入表。

除了非常有限的例外之外，所有操作都必须通过API（即实现OrganizationServiceProxy的{{1}}）来完成。 CRM是基于消息的平台。如果直接写SQL，则会绕过它的整个消息传递系统，结果无法预测且不受支持。

在您的方案中，SQL存储过程可能不了解其他情况。简而言之，您应该通过API实现您要实现的目标，并摆脱对CRM数据库的所有SQL写入。

由于生产中的负载，我可以减少抽象和只是直接影响数据库不只是受欢迎，而且几乎由于超时和CRM的性能下降，因此有必要。

虽然很想直接在数据库上操作，但将CRM视为API而不是数据库。

请记住，您可以在performance analysis和optimization上工作。

对于初学者来说，分析慢速查询并添加一些indexes可能会有所帮助。而且，由于Filtered Views在数据库级别实施了安全模型，因此从它们中读取任何报告或自定义集成可能会有所帮助。

听起来您要获得支持的状态还有很长的路要走。

使用SQL存储过程将工作流状态更新为已在MS Dynamics CRM AsyncOperationBase表中取消，状态并不总是持久的

1 个答案: