何时使用工作流引擎？

过去，我曾以程序员的身份工作于某些工作流引擎，但从未明确说明为什么我们首先选择工作流引擎。作为程序员，我知道编写代码时至少有100种方法可以执行任何操作，但是只有少数几种是最好的！

我仍然不了解工作流引擎（或更确切地说是它们的概念）能最好地解决哪些用例，而不是设计一个支持DI的应用程序。我正在寻找与领域无关的用例的任何一般特征，其中工作流引擎是最好的选择之一。

所以我的问题是：需求的一般特征是什么，可以作为选择一个好的工作流引擎并对其进行编码的信号？

当您需要从头到尾完成工作，但是有许多不同的路径/逻辑/规则可以到达时，工作流引擎将非常有用。

例如，假设我编写了一个发布内容的程序。因此，以我为例，发布过程要经过审核，合法和最终批准。我编写了实现过程逻辑和步骤的程序。现在，这项工作对我和我的公司都非常有用。因此，我决定其他人应该使用我的程序。

不幸的是，并不是每个人都使用相同的过程发布内容，因此，我们不会为每个不同的案例编写单独的过程，而是实施工作流程过程，以便该程序可以灵活地适应每个人。无论这两点之间有多少步骤，规则或逻辑，结果都是相同的。

因此，如果您的流程从始至终都是可变的，请使用工作流程。如果每个人都可以使用相同的过程，那么您就不需要工作流程。

我知道您要求用例，但是列出优点比想象所有可能的用例容易。优势当然取决于您要比较的引擎和语言，但总的来说：

1. 将规则保留为数据而不是代码意味着您不必重新编译，因此您可以快速测试更改，在运行时进行更改等。但是，如果不必首先进行重新编译，则没有太多优势。

2. 可以更合理地期望用户编辑规则。他们可能会以一种交互的方式修改它们，而这需要程序员为他们编写代码时不可行。

3. 将规则保留为数据可允许编写工具以可视化和更改数据。

4. 将规则保留为数据可以使元编程更加容易-您可以编写代码来分析数据并以某种复杂的方式进行插入，这对于代码来说是非常困难的。

所有这些事情都可以直接与代码一起完成（例如，编写C＃解析器以查找特定类型的所有规则并生成更多规则的代码，以允许卸载程序集的方式将其动态插入到程序集中，编写用于用户也可以使用您的可视化器和编辑器执行此操作），但根据您的语言，可能会困难得多（使用Lisp的程序员可能将第1-4项称为“编程”）。

恕我直言，您应该使用这种东西的唯一情况是，价值不高的用户可以配置它。如果您可以通过给他们提供一种工具来解决问题，然后又去做其他更重要的事情，那么请使用一个。

如果您仍然需要为他们设置它，那么我想您会想到10种不同的方法可以通过您熟悉的工具获得相同的结果，并且支持和自定义将更加容易。

这似乎是一个古老的问题，但在野外却屡屡出现。我同意乔恩的回答。我发现工作流引擎在以下情况下效率很高：

1. 您正在尝试通过软件来表示/实施一个基础业务流程。
2. 在该过程的所有或某些阶段中，只有一个（可能是复合的）业务实体在工作。在乔恩（Jon）给出的示例中，此实体或工作流项目将是内容或文章。将错误跟踪视为工作流的另一个示例，错误是根据用户执行的操作在各种状态之间转换的。
3. 仅当您希望业务流程发生变化时，才使用工作流对流程进行建模。变化是指由于用户操作或过渡而执行的顺序或操作。

要非常小心和关键，以查看您的问题域/需求是否具有业务流程，请勿尝试将其“适合”到工作流程中。

我有一些指导工作流程引擎的指导原则。

1）当业务分析师没有编码背景但可以绘制图表时。

现代的工作流引擎使用业务流程建模符号或SharePoint和类似系统中功能较弱的版本。这些使团队中技术精湛但又受代码挑战的成员可以设计和开发许多工作流程。

2）当您需要监视工作进度时，请执行升级，在计算机控制的流程和人工控制的流程之间来回切换。

监控和自我参考是现代工作流程引擎的标志。

从人力资源业务的角度来看，工作流程引擎非常重要。

1. 它们提供了一个结构化的过程，即使每次都相同。

2. 他们提供透明度

   • 谁要求更改，
   • 何时要求
   • 谁批准等

   这种透明性有助于推动流程并促进所有权。

假设表单是集成的和智能的，并支持业务逻辑，那么它对时间轴，处理效率和数据质量也将产生巨大影响。安全性也是一个考虑因素，在安全系统中包含敏感信息比使纸质表格等待签名更可取。它也更具移动性。在最近实施之后，一位经理告诉我，这为他省去了很多麻烦，因为他经常旅行时，把东西张贴给他签名。

代表人力资源：工作流万岁！