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