【问题标题】:Usecase for Workflow Engine工作流引擎用例
【发布时间】:2010-06-10 20:21:36
【问题描述】:

我们遇到了一个问题,即必须根据特定实体的状态更新数据库表。目前,它的所有 Java 代码都有很多 if 条件和状态更新。我一直在考虑使用工作流引擎,因为将来可能会有多个流。在这里使用工作流引擎是不是有点矫枉过正......你在哪里划清界限?

【问题讨论】:

  • 要求每个状态都应该能够转换到其他所有状态。所以现在对于每个新状态,我必须添加转换到每个现有状态的动作,并且每个现有状态都必须有动作来移动到新状态。是否有以非重复方式处理这些问题的 WorkFlow 解决方案?
  • @ktaylorjohn - 当然有一个阶段是退出。
  • 伊卡洛斯,你和 wwu 论坛里的伊卡洛斯一样吗?

标签: java workflow


【解决方案1】:

这取决于您的用例的复杂程度。

在一个简单的用例中,我们有一个由多个消费者针对订单生命周期中的每个阶段更新的数据库列。这是通过调用数据库的 Web 服务来完成的。 简单的生命周期从 ACKNOWLEDGED > ACCEPTED/REJECTED > FUFILED > CLOSED 开始。所有这些都在同一列的同一张表中。这是在没有工作流的 java 类中执行的。

工作流引擎适用于更复杂的用例,其中涉及对多个数据提供者的操作,例如:数据库或内容管理或文档管理或搜索引擎、多个并行进程、基于上一步的成功/失败的分叉,在某个步骤发送电子邮件,离线错误警报。

你可以看看Apache ODE来实现这个。

【讨论】:

    【解决方案2】:

    我们遇到了一个问题,即必须根据特定实体的状态更新数据库表。目前,它的所有 Java 代码都有很多 if 条件和状态更新。

    听起来很准时,不需要在工作流程参与者之间协调行动。

    也许规则引擎更适合于此。 Drools 可能是一个不错的候选人。当 X 然后 Y。

    【讨论】:

    【解决方案3】:

    如果您使用的是 Spring,这是一篇关于如何实现您的需求的好文章

    http://www.javaworld.com/javaworld/jw-04-2005/jw-0411-spring.html

    【讨论】:

      【解决方案4】:

      我认为您应该考虑使用工作流引擎。工作流应该与应用程序逻辑分离。

      原因:

      1. 可维护:更容易修改、添加新流程,甚至更容易被另一个工作流引擎替换。
      2. 业务流程管理:工作流主要是 BPM 的软件表示。所以它通常是由流程设计师(非技术人员)设计的。因此,在应用程序内部编写代码并不是一个好主意。相反,应该使用支持图形工作流设计的 BPM 产品,例如 ALBPM 或 JPBM。
      3. 监控业务流程:通常由高层管理人员监控并用于制定战略决策。
      4. 更容易进行数据挖掘/报告/统计。

      ALBPM(现在是 Oracle BPM):是 Oracle 的一款商业工具,适用于大型项目。

      我的推荐是JBPM。 JBOSS 的开源工具。与需要单独的数据库和应用程序服务器的 ALBPM 不同,它可以与您的应用程序一起打包并在您的应用程序中作为另一个模块运行。我认为适合您的项目。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2012-12-12
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2013-01-06
        • 2012-05-11
        相关资源
        最近更新 更多