答复: 工作流系统：在误区中漫步

关于动态诠释 参与者，我想的一个方案就是用企业业务逻辑规则这个概念来解决。 关于某个业务，涉及某些条件由谁批准的问题。如果能够很好地抽象出这些就可以解决这个问题。 比如说： 业务 条件 执行者 车费报销 金额<50元 科长 车费报销 100>金额>50 处长 车费报销 金额>100 局长 如果企业建立一套这样的业务规则库，系统中应用业务规则引擎迅速找到执行者， 再将其赋给工作流系统的参与者，工作流就可以运作。 工作流系统要和业务规则引擎系统，以及企业组织机构建模良好地配合，才能更加灵活和强大。 目前，我所做的权限资源管理平台正在朝这个方向发展。由于时间和精力问题，现在还抽不出精力解决这个问题，但是我想迟早要将企业的业务规则同授权系统以及工作流系统要很好地整合起来，提供更加灵活和强大的平台。

看到你在别人那边的回复，就跟着跑进来，才发现，原来。。。。好吧，不下结论了，给你多点时间。

引擎独立,暴露一个执行者接口.怎么实现,看你的了
我们的做法是做个配置,让管理员自由添加条件,制定规则,感觉不错.

如果仅仅是暴露条件借口，那osworkflow很明显是个典型的代表，和你说的解决方案很符合。
如果要固定做一个规则库，每个流程有每个流程的特点，这个流程的规则是：如果金额超过10w就报处长审批，那个流程的规则是：如果上一步是A提交的，就提交经理审批，规则实在是五花八门，使用自己写的规则库来绑定工作流，到最后可能会觉得库无法穷尽，每一个流程几乎都是一种新的规则。

多花点时间研究一下现成的东西吧，这些问题早就很好的解决了

规则很多并不可怕，可怕的是对规则进行硬编码。增加新的规则就是向规则库中增加记录，没有什么可怕，规则引擎的接口是稳定的，工作流调用规则引擎的代码也就稳定了。那么即使规则成千上万，不需要改变程序代码，还有什么可怕的呢？

 

从规范的角度：

 

“车费报销 金额<50 ”这是 XPDL中的连接弧定义，BPEL的IF-ELSE定义。

不算是“动态诠释 参与者”

 

当满足了上述的“连接弧”或“IF-ELSE”后，工作流引擎会创建新的活动实例、继而产生新的工作项实例，

产生工作项实例的时候会用到你说的“动态诠释 参与者”，比如说“级别大于某某的执行人”，如果仅仅就科长、处长这样的静态角色而言，而达不到动态。

 

当然，用规则引擎与工作流引擎结合的角度，规则引擎只处理规则，而将结果传递给工作流。

 

这问题也不算是行业解决方案版面讨论的内容，纯工作流讨论。

 

行业解决方案区讨论的内容应该是：http://www.itpub.net/index.php?gid=50

似乎更有意思一些！

 

BPEL的规范中的连接固然可以解决这个问题，我们目前的工作流也是这样解决这个问题。他的优点是能直观反映业务规则。如果流程中这样分支的连接弧过多，整个流程看起来会很乱。所以有的客户提出能不能不要这样的定义方式。于是我们就在业务中使用业务规则来解决这个问题。流程看起来很干净，易于读懂。扩展性也会很好，而且非常复杂的条件组合定义起来也更加容易。

那最起码有一个简单的流程吧。
如将上面的分支流程做成最简单的流程？

“节点A----->节点B”


节点B的执行人定义为“车费报销 金额<50元 科长 车费报销 100>金额>50 处长 车费报销 金额>100 局长”

节点B可以的执行人为一个业务方法，业务方法的逻辑用规则引擎生成……

？

大概就是那个意思，我遇到的客户喜欢这种方式 。对于审批一类的业务用这个比较方便。分支一般在根据不同条件处理不同的业务时使用，这主要是导致流程分支时用。而不同的条件导致同一业务不同人处理时，用规则比较好。其含义是： 某某业务的处理权限规则。一家之言，个人遇到的一些客户现场的问题之后的一些思考，仅供参考。