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