我想知道您（SO读者）使用Workflow Engines解决的特定问题，以及如果您不自己动手使用的库/框架。我还想知道何时工作流引擎不是最佳选择，以及是否/如何选择更简单的东西，例如使用状态机的TaskList / WorkList / Task-Management类型的应用程序。
问题：
我正在寻找第一手经验。
我检出的一些资源：
我想知道您（SO读者）使用Workflow Engines解决的特定问题，以及如果您不自己动手使用的库/框架。我还想知道何时工作流引擎不是最佳选择，以及是否/如何选择更简单的东西，例如使用状态机的TaskList / WorkList / Task-Management类型的应用程序。
问题：
我正在寻找第一手经验。
我检出的一些资源：
Answers:
我也有偏见，因为我是StonePath的主要作者。
我已经为美国国务院，日内瓦人道主义排雷中心，多个财富500强客户以及最近的华盛顿特区公立学校系统开发了工作流应用程序。每当我看到一个“工作流引擎”试图成为业务流程的主要参考时，我都会看到一个组织在努力使用该工具。这可能是由于以下事实：这些解决方案一直都是由供应商/产品驱动的，然后最终由一个由“顾问”组成的战术团队不断为该应用程序供食...但是，因此，当我听到这些消息时，我往往会做出负面反应基于流程的工具的好处，它们承诺“将工作流定义集中在一个地方，并使它们可重复”。
就是说，我非常喜欢Ruote-我已经关注该项目一段时间了，如果我需要那种解决方案，它将成为我愿意尝试的下一个工具。StonePath的目的与ruote完全不同-Ruote通常对Ruby有用，而StonePath则针对用Ruby编写的Web框架Rails。Ruote涉及长期的业务流程及其相关定义，而StonePath则涉及管理基于状态的工作流和任务。坦率地说，我认为与外部查看的区别可能很微妙-很多时候可以用任何一种方式表示相同类型的业务流程-但是基于状态和任务的模型往往会映射到我的思维模型。
让我描述基于状态的工作流的重点。简而言之，想象一个工作流围绕着诸如抵押贷款或护照更新之类的处理。当文档在“办公室周围”移动时，它会从一个州到另一个州。想象一下，如果您对文档负责，您的老板每隔几个小时问您一次状态更新，并想要一个简短的答案...您会说诸如“它正在数据输入中”之类的内容……“我们正在检查申请人的凭据” ...“我们正在等待质量审查” ...“我们已经完成” ...等等。这些是基于状态的工作流程中的状态。我们通过过渡（例如“批准”，“应用”，反冲”，“否定”等在状态之间移动），这些往往是动作动词。
基于状态/任务的工作流的下一部分是任务的创建。任务是一个工作单元，通常具有截止日期和处理说明，该任务将工作项（例如，贷款申请或护照续签）连接到用户的“收件箱”。任务可以彼此并行或顺序发生，并且我们可以在进入状态时自动创建任务，在人们意识到需要完成工作时手动创建任务，并要求任务完成后才能进入新状态。所有这些行为都是可选的，并且是工作流定义的一部分。
兔子洞的作用远不止于此，我为《实用程序员》杂志《 PragPub》第4期撰写了一篇有关它的文章。请查看上方的reo链接，以获取该文章的更新的PDF。
在最近几个月与StonePath的合作中，我发现基于状态的模型可以很好地映射到宁静的Web架构-特别是任务和状态转换可以很好地映射为嵌套资源。希望将来能看到我写的关于这个主题的文章。
我有偏见，我是ruote的作者之一。
变体1）附加到资源（文档，订单，发票，书籍，家具）上的状态机。
变体2）附加到名为任务的虚拟资源的状态机
变体3）工作流引擎解释工作流定义
现在，您的问题被标记为“ BPM”，我们可以扩展为“业务流程管理”。每个变体如何进行这种管理？
在变体1中，业务流程（或工作流）分散在应用程序中。附加到资源的状态机强制执行工作流的某些方面，但仅执行与资源相关的那些方面。遵循相同的业务流程，可能还有其他资源具有自己的状态机。
在变体2中，工作流可以集中在任务资源周围，并由该资源周围的状态机表示。
在变体3中，通过解释称为工作流定义（或业务流程定义）的资源来制定工作流。
业务流程发生变化时会发生什么？在业务流程可管理的资源中拥有工作流引擎是否值得？
大多数状态机库具有1个设置状态+过渡。大多数情况下，工作流引擎是工作流定义解释器，它们允许多个不同的工作流一起运行。
更改工作流程的成本是多少？
变体不是互斥的。我看到了许多示例，其中工作流引擎更改了多个资源的状态，其中一些资源由状态机保护。
对于人工任务，我也经常使用变体3 + 2：工作流引擎，在运行流程实例时的某些时候，将任务（工作项）交给人工参与者（资源任务已创建并处于“就绪”状态） 。
单独使用变体2（任务管理器变体），您可以走很长一段路。
我们还可以提到变量0），其中没有状态机，没有工作流引擎，并且业务流程在应用程序中分散和/或硬编码。
您可以问很多问题，但是如果您不花时间阅读答案，也不花时间尝试和尝试，您就不会走得太远，也永远不会有什么用的天赋这个或那个工具。
我是我们在Uber开发的Cadence工作流引擎的作者之一。Cadence与大多数现有工作流引擎之间的区别在于，它以开发人员为中心，并且具有极高的灵活性和可扩展性（每秒更新数万次，打开的工作流多达数十亿个）。工作流被编写为面向对象的程序，并且引擎可确保在主机发生故障时完全保留工作流对象（包括线程堆栈和局部变量）的状态。
您使用工作流引擎解决了哪些问题？Cadence实际上用于超出单个请求回复范围的任何后端应用程序。用法示例如下：
还有很多
其他用例集基于移植现有工作流引擎以在Cadence上运行。实际上，任何现有的引擎工作流规范语言都可以移植到Cadence上运行。移植了多个内部Uber系统。这样，单个后端服务就可以为多个特定于域的工作流系统提供支持。
您使用了哪些库/框架？
Cadence是使用Go和Java客户端库用Go编写的自包含服务。唯一的外部依赖性是存储。支持Cassandra和SQL数据库。
Cadence还支持异步跨区域（使用AWS术语）复制。
什么时候像系统这样简单的状态机/任务管理就足够了？
在Uber内部，Cadence服务由我们的团队管理。因此，构建任何自定义状态机/任务管理的开销总是比使用Cadence高。在公司外部，需要为其设置服务和存储。如果您已经有一个SQL数据库，则通过Docker映像进行服务部署非常简单。泊坞窗还用于运行本地Cadence服务，以便在个人计算机或便携式计算机上进行开发。
检查rails_workflow gem-我认为这与您搜索的内容很接近。
我是Imixs-Workflow的作者之一。Imixs-Workflow是基于BPMN 2.0的开源工作流引擎，已完全集成到Java EE技术堆栈中。
十多年来，我一直在自己开发工作流引擎。我会尽力回答您的问题：
>您使用工作流引擎解决了哪些问题？
当我开始考虑工作流引擎时，我的个人目标是避免硬编码应用程序中的业务逻辑。业务应用程序中的许多内容都可以重用，因此使其具有可配置性是有意义的。例如：
从此功能列表中，您可以看到我正在谈论以人为本的工作流程。简而言之：以人为中心的工作流引擎回答了以下问题：谁负责一项任务，接下来需要通知谁？这些是业务需求中的典型问题。
>您使用了哪些库/框架？
5年前，我们开始重新实现专注于BPMN 2.0的Imixs-Workflow引擎。BPMN是流程建模的通用标准。而令我感到惊讶的是，我们突然能够描述甚至可以可视化并执行的高度复杂的业务流程。我建议每个人都使用BPMN对业务流程进行建模。
>什么时候像系统这样简单的状态机/任务管理就足够了？
如果您只想跟踪业务对象的状态，则简单的状态机就足够了。当您开始将'status'属性引入对象模型时就是这种情况。但是，如果您需要具有职责，日志记录和流控制的业务流程，那么状态机将不再足够。
>奖金：您如何/如何区分任务管理和工作流引擎？
这正是此处提到的许多工作流引擎有所不同的地方。对于以人员为中心的工作流程，通常需要任务管理以在人员之间分配任务。对于过程自动化，这一点并不重要。如果引擎执行某些任务就足够了。无法比较任务管理和工作流引擎，因为任务管理始终是工作流引擎的功能。
我滚动了自己的工作流引擎来支持文档的分阶段处理-编目，发送图像处理（我们与rededit sw一起工作），如果需要发送至验证，然后发布并最终发回给客户。在我们的案例中，我们要处理大量的文档，因此有时我们需要分别运行每个服务以控制交付和资源使用。概念简单，但需要高性能和分布式处理，而且我们找不到适合我们的现成产品。
我有使用Activiti的经验 BPMN 2.0引擎处理网络节点基础结构中的高性能和高吞吐量数据传输过程的经验。基本任务是允许配置和监视此类传输过程，并控制每个网络节点（即请求node1通过特定的传输层将数据文件发送到node2）。
一次可能有成千上万个进程在运行，而每天总共有成千上万个进程。
有许多不同的过程定义，但不一定要求系统的操作员可以创建自定义工作流。因此，BPM引擎本身的主要用例是健壮，可伸缩并允许监视每个流程。
最后，它基本上可以正常工作，但是我们从该项目中学到的是BPMN平台，或者确切地说是Activiti引擎，并不是这种高吞吐量系统的最佳选择。
主要挑战是任务执行优先级划分，数据库锁定，重试执行等，仅涉及BPM本身。因此，我们必须开发这些的自定义处理，例如：
我不知道其他BPMN引擎是否会更适合这种情况，因为BPMN主要用于长期运行的业务任务，涉及用户交互，而性能可能与我们的情况不同。