工作stream引擎的用例
我想知道你的SO读者已经使用Workflow Engines解决了哪些具体问题，以及如果你没有自己开发的库，使用了什么库/框架。 我还想知道什么时候工作stream引擎不是最好的select，以及如何/如何select简单的东西，比如使用状态机的TaskList / WorkList / Task-Managementtypes的应用程序。
问题：
- 您使用工作stream引擎解决了哪些问题？
- 你使用了什么库/框架？
- 什么时候比较简单的状态机/任务pipe理系统就足够了？
- 奖金：您是如何区分任务pipe理和工作stream程引擎的 ？
我正在寻找第一手的经验。
我已经检查了一些资源：
- Ruote和状态机！=工作stream引擎
- StonePath和Docs
- 使用Oracle创build和pipe理工作列表任务计划
- 工作stream引擎的devise与实现 – 论文
- 什么使用Windows Workflow Foundation的
- JBoss jBPM文档
我也有偏见，因为我是StonePath的主要作者。
我已经为美国国务院，日内瓦人道主义排雷中心，几个财富500强的客户以及最近的华盛顿特区公立学校系统开发了工作stream应用程序。 每当我看到一个试图成为业务stream程的主要参考的“工作stream引擎”时，我就看到一个组织为自己的工作而努力。 这可能是由于这些解决scheme一直是由供应商/产品驱动的，然后最后是一个由顾问组成的策略团队，不断地为应用程序提供…但正因为如此，当我听到基于过程的工具的好处，承诺“将工作stream定义集中在一个地方，使其可重复”。
这就是说，我非常喜欢Ruote – 我一直在关注这个项目一段时间，如果我需要这样的解决scheme，它将成为我愿意尝试的下一个工具。 StonePath有一个非常不同的目的而不是ruote – 在一般情况下，Ruote对Ruby有用，StonePath是针对Rails，用Ruby编写的Web框架。 如果Ruote是关于长期的业务stream程及其相关的定义，StonePath是关于pipe理基于状态的工作stream程和任务。 坦率地说，我认为从外部看的区别可能是微妙的 – 许多时候同样的业务stream程可以用任何方式表示 – 基于状态和任务的模型往往映射到我的心智模型。
让我来描述基于状态的工作stream程的亮点。 简而言之，设想一个围绕处理抵押贷款或护照更新等工作的工作stream程。 随着文件在“办公室周围”移动，它将从一个州到另一个州。 想象一下，如果你对这份文件负责，而且你的老板每隔几个小时问你一次状态更新，想要一个简短的答案……你会说“这是在数据录入”……“我们正在检查申请人的全权证书现在“…”我们正在等待质量审查“…”我们完成了“…等等。 这些是基于状态的工作stream程中的州。 我们通过转换从一个状态转移到另一个状态，比如“批准”，“应用”，“回扣”，“拒绝”等等，这些都是动作动词，像软件一样， 。
基于状态/任务的工作stream程的下一部分是创build任务。 任务是一个工作单元，通常有一个到期date和处理指令，将工作项目（例如贷款申请或护照更新）连接到用户“收件箱”中。 任务可以相互并行或按顺序进行，我们可以在进入状态时自动创build任务，当人们意识到工作需要完成时手动创build任务，并且在我们移动到新状态之前需要完成任务。 所有这些行为都是可选的，也是工作stream定义的一部分。
兔子的洞可以做得比这更深，我为PragPub的第四期“实用程序员杂志”写了一篇文章。 查看上面的reo链接，获取该文章的更新PDF。
在过去的几个月中，我发现基于状态的模型非常适合平稳的web架构 – 特别是任务和状态转换很好地映射为嵌套资源。 期待在这个问题上看到我的未来写作。
我有偏见，我是ruote的作者之一。
变种1）附属于资源（文件，订单，发票，书籍，家具）的状态机。
变体2）状态机连接到名为任务的虚拟资源
变体3）工作stream引擎解释工作stream定义
现在您的问题被标记为“BPM”，我们可以将其扩展为“业务stream程pipe理”。 这种pipe理在每个变体中如何发生？
在变体1中，业务stream程（或工作stream）分散在应用程序中。 连接到资源的状态机强制执行工作stream程的某些方面，但只涉及与资源有关的方面。 遵循相同的业务stream程，可能会有其他自己的状态机的资源。
在变种2中，工作stream可以集中在任务资源周围，并由该资源周围的状态机表示。
在变型3中，通过解释称为工作stream定义（或业务stream程定义）的资源来制定工作stream程。
当业务stream程发生变化时会发生什么？ 值得拥有一个业务stream程是可pipe理资源的工作stream引擎吗？
大多数状态机库有1个状态+转换。 工作stream引擎大多数是工作stream定义解释器，它们允许多个不同的工作stream一起运行。
改变工作stream程的成本是多less？
变体不是相互排斥的。 我看到很多例子，工作stream引擎改变了一些状态机保护的多个资源的状态。
对于人工任务，我也使用变型3 + 2：工作stream引擎，在运行stream程实例的某些点上，将任务（工作项）交给一个人参与者（资源任务被创build并置于“就绪”状态） 。
您可以单独使用变体2（任务pipe理器变体）。
我们也可以提到变体0），其中没有状态机，没有工作stream引擎，业务stream程在应用程序中分散和/或硬编码。
你可以提出很多问题，但如果你没有花时间阅读答案，也没有花时间去尝试和尝试，那么你就不会走得太远，也不会在何时使用它这个或那个工具。
在之前的一个项目中，我在Healhcare行业的一些政府表格中增加了一些工作streamtypes规则。
表格需要由最终用户填写，根据一些答案，其他表格计划在以后填写。 还有外部事件会取消预定的表格或安排新的表格。
样品stream程：
病人录取 – >时间表初始评估文件 – >时间表季度评估表格 – >病人死亡 – >取消评估 – >时间表出院评估表格
许多其他的规则是基于诸如病人年龄等被接纳的地方
这是一个ASP.NET应用程序，规则基本上是数据库中的一个表。 我添加了脚本，所以脚本会在Form完成时运行，以确定下一步该怎么做。 这是一个可怕的devise，而且对于一个适当的工作stream引擎来说是完美的。
检查rails_workflow的gem – 我认为这是接近你search。
我推出了自己的工作stream引擎，以支持分阶段处理文档 – 编目，发送image processing（我们使用编辑软件sw），如果需要发送到validation，然后发布，最后发回客户端。 在我们的情况下，我们有一大堆文件要处理，所以有时我们需要单独运行每个服务来控制交付和资源使用。 简单的概念，但高性能和分布式处理所需要的，我们找不到任何适合我们的帐单产品。
我有使用Activiti BPMN 2.0引擎处理networking节点基础架构中的高性能和高吞吐量数据传输过程的经验。 基本任务是允许configuration和监视这样的传输过程并控制每个networking节点（即，请求节点1通过特定传输层向节点2发送数据文件）。
一次可能有成千上万的进程在运行，每天总共有数十或数十万个进程。
有许多不同的stream程定义，但系统的操作员不一定需要创build定制的工作stream程。 因此，BPM引擎本身的主要用例是健壮的，可扩展的，并允许监视每个stream程。
最后它基本上可以工作，但是我们从这个项目中学到的东西是BPMN平台，特别是Activiti引擎不是这种高吞吐量系统的最佳select。
主要的挑战是任务执行优先级，数据库locking，执行重试，仅举几例BPM本身。 所以我们不得不开发自定义处理这些，例如：
- 处理BPM中的重试，以便在节点没有空闲工作人员进行给定任务或节点完全没有运行的情况下。
- 在单个进程中执行并行传输任务并同步结果（成功/失败）。
我不知道其他BPMN引擎是否会更适合这种情况，因为BPMN主要用于涉及用户交互的长时间运行的业务任务，而性能可能与我们的情况不同。
