MS中的自定义WorkFlows与插件

Question

我在CRM中使用了大量的插件代码来实现业务逻辑，但现在我想出了一个叫做自定义工作流活动的特性。现在，我想知道什么时候应该在插件上使用这些自定义工作流？

Answer 1

我自己深入研究了这个问题，发现了一些有趣的东西，我想和大家分享一下，下面是比较的完整列表：

• 插件只会激发数据更改，如更新或创建记录，但自定义工作流在流程中参与(工作流、对话框、.) 因此，工作流不仅可以在数据更改时触发，而且可以在流程中的任何时间点随时按需触发。正如您可能已经理解的那样，实现复杂的业务逻辑需要真正的灵活性。
• 插件不会接受参数或传递数据，但是通过使用以下InArgument属性，自定义工作流使其成为可能： 工作流ReferenceTarget(“事件”)/所示字段的输入(“Case”)//如果使用EntityReference，则必须指向公共InArgument yourArg { get；set；}//几乎所有数据类型都受支持
• 业务用户可以简单地使用和操作工作流。
• 自定义工作流是绝对可重用的。有了一个寄存器，您就有了一条业务逻辑，可以在几种情况下使用。在某些情况下，您甚至可能碰巧编写了一段代码，可以在许多不同的实体上使用。
• 到目前为止，您知道自定义工作流比插件更可靠，但是插件接管自定义工作流的关键是在验证数据更改并最终需要恢复这些更改时。当然，这在自定义工作流中是可能的，但是添加插件要比添加工作流容易得多。
• 记住插件运行得更快！(当我亲自测试时)
• 然而，CRM中的分析工作流仍然被窃听！

Answer 2

代码活动是自定义步骤，可以插入到一个或多个不同的工作流中。类似于“插件”，但曾经被插入到工作流中。

工作流给您提供了更多的反馈，因为它们是在CRM中直观地表示的，因此非技术人员可以看到工作流的状态，以及从一开始就执行的步骤。工作流也在异步服务中执行，因此它们异步运行，插件在应用程序池中同步运行。

因此，对于长期运行的进程来说，工作流也更好。

尽管如此，在以下情况下，插件仍然是有用的：

• 您需要立即响应，因为它们是在CRM的应用程序池中触发和执行的，
• 您需要在事务中运行任何内容，这样他们就可以通过引发异常来中止事务。

示例:您与第三方服务进行了集成，在该服务中，除非在另一边验证了某些内容，否则无法在CRM中创建记录。另一个例子是并发性:自动编号插件是一个插件，因为它需要锁定事务中的数据库，否则多个并发线程可能会创建重复的ID。

所以，答案就像往常一样:视情况而定。:)

Answer 3

许多开发人员或MS初学者在某些场景中感到困惑，无论是使用工作流还是插件，因为两者都可以使用，并且能够在服务器端执行特定的任务。

插件和工作流有一些显著的差异，比如事件消息的限制，触发点。

您可以参考下面的链接，以全面了解差异-

https://mscrm16tech.com/.../workflows-vs-plugins-in-ms-crm/