Question

我使用了大量的插件代码来实现CRM中的业务逻辑，但现在我已经提出了这个名为Custom Workflow Activity的功能。现在我想知道什么时候在插件上使用这些自定义工作流程？

Answer 1

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

工作流程为您提供更多反馈，因为它们在CRM中以可视方式显示，因此非技术人员可以查看工作流程的状态以及自开始以来执行的步骤。工作流也在异步服务中执行，因此它们以异步方式运行，插件在应用程序池中同步运行。

因此，对于长时间运行的流程，工作流也更好。

话虽如此，插件在以下情况下仍然有用：

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

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

所以，答案就像往常一样：这取决于。：）

Answer 2

我自己深入研究了这个主题并找到了我想分享的有趣的东西，所以这里是完整的比较列表：

插件只会触发数据更改，例如更新或创建记录，但自定义工作流程会参与进程（工作流程，对话框......）

因此，工作流程不仅可以在数据更改时触发，而且可以在其流程内的任何时间点随时按需触发。您可能已经理解，这是实现复杂业务逻辑所需的真正灵活性。

插件不接受参数或传递数据，但是，通过使用如下的InArgument属性，自定义工作流程可以实现：

[Input("Case")]     //label of the field shown in workflow
[ReferenceTarget("incident")]     //if using EntityReference, must point the type
public InArgument<EntityReference> yourArg { get; set; } //almost every data type is supported

业务用户可以简单地使用和操作工作流程。
自定义工作流程绝对可重复使用。使用一个寄存器，您可以使用一种可在多种情况下使用的业务逻辑。在某些情况下，您甚至可能会编写一个可以在许多不同实体上使用的代码。
到目前为止，您知道自定义工作流程比插件更可靠，但是使插件接管自定义工作流程的重点在于您验证数据更改并最终需要还原这些更改。当然，这在自定义工作流程中是可行的，但添加插件要比工作流程更容易。
并且记住插件运行得更快！（正如我自己测试的那样）
然而，CRM中的分析工作流程仍然没有被删除！

Answer 3

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

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

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

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

MS CRM中的自定义WorkFlows与插件

3 个答案: