工作流引擎的用例

Question

我想知道您（SO读者）使用Workflow Engines解决的特定问题，以及如果您不自己动手使用的库/框架。我还想知道何时工作流引擎不是最佳选择，以及您是否/如何选择更简单的东西，例如使用状态机的TaskList / WorkList / Task-Management类型应用程序。

问题：

• 您使用工作流引擎解决了哪些问题？
• 您使用了哪些库/框架？
• 什么时候像系统这样简单的状态机/任务管理就足够了？
• 奖励：您如何/如何区分了任务管理和工作流引擎？

Answer 1

我也有偏见，因为我是StonePath的主要作者。

我已经为美国国务院，日内瓦人道主义排雷中心，多家财富500强客户以及最近的华盛顿特区公立学校系统开发了工作流程应用程序。每当我看到一个“工作流引擎”试图成为业务流程的主要参考时，我都会看到一个组织在努力使用该工具。这可能是由于以下事实：这些解决方案一直都是由供应商/产品驱动的，然后最终由一个由“顾问”组成的战术团队不断为该应用程序供食…但是，因此，当我听到这些消息时，我往往会做出负面反应基于流程的工具的好处，它们承诺“将工作流定义集中在一个地方并使其可重复”。

就是说，我非常喜欢Ruote-我已经关注该项目一段时间了，如果我需要那种解决方案，它将成为我愿意尝试的下一个工具。StonePath的目的与ruote完全不同-Ruote通常对Ruby有用，而StonePath则针对用Ruby编写的Web框架Rails。Ruote涉及长期的业务流程及其相关定义，而StonePath则涉及管理基于状态的工作流和任务。坦率地说，我认为与外部查看的区别可能很微妙-很多时候可以用任何一种方式表示相同类型的业务流程-但是基于状态和任务的模型往往会映射到我的思维模型。

让我描述基于状态的工作流的重点。简而言之，想象一个工作流围绕着诸如抵押贷款或护照更新之类的处理。当文档在“办公室周围”移动时，它会从一个州到另一个州。想象一下，如果您对文档负责，您的老板每隔几个小时问您一次状态更新，并想要一个简短的答案…您会说诸如“它正在数据输入中”之类的内容……“我们正在检查申请人的凭据” …“我们正在等待质量审查” …“我们已经完成” …等等。这些是基于状态的工作流程中的状态。我们通过过渡（例如“批准”，“应用”，反冲”，“否定”等在状态之间移动），这些往往是动作动词。

基于状态/任务的工作流的下一部分是任务的创建。任务是一个工作单元，通常具有截止日期和处理说明，该任务将工作项（例如，贷款申请或护照续签）连接到用户的“收件箱”中。任务可以彼此并行或顺序发生，并且我们可以在进入状态时自动创建任务，在人们意识到需要完成工作时手动创建任务，并要求任务完成后才能进入新状态。所有这些行为都是可选的，并且是工作流定义的一部分。

兔子洞的作用远不止于此，我为《实用程序员》杂志《 PragPub》第4期撰写了一篇有关它的文章。请查看上方的reo链接，以获取该文章的更新的PDF。

在最近几个月与StonePath的合作中，我发现基于状态的模型可以很好地映射到宁静的Web架构-特别是，任务和状态转换可以很好地映射为嵌套资源。希望将来能看到我写的关于这个主题的文章。