2008-06-11

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

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

评论
ltian 12 小时前
jmszhang 写道
比较同意。

其实也就是将容易变化的因素（或者说规则引擎），在这里是与组织机构相关的一部分规则逻辑，抽取到工作流引擎之外处理。

和组织机构相关的部分其实还有更多，一般的工作流软件是为每一个人工活动定义执行人（角色、执行人）等。
顺着你的想法，上面这个过程可以反过来，也就是说在组织机视图中定义每一种角色可以执行的节点。


是的，所以有时我想，所谓的权限和资源分配。比如某个角色可以使用某个URL所提供的资源（人机界面），或者使用某些数据资源（比如不同的仓库管理员角色可以管理不同的仓库，不同的设备维护人员维护不同的设备）等等，那么权限资源管理是不是业务规则的一个简单的子集呢?如果是业务规则的一个子集，那么我就可以把权限资源管理系统同规则定义进行整合，从而站在另外一个角度看待授权管理，这样可以解决以前授权系统很多局限之处。
我这些想法主要源于我们在为客户开发基于工作流业务的时候，要通过访问权限资源管理系统提供的API来最终确定由那个参与者可以操作当前环节，并且，在当前环节中能够引用哪些数据资源。所以，我觉得规则引擎和权限资源管理系统需要整合，整合后的系统不仅能为那些普通的业务提供权限和资源服务，可以为工作流引擎提供相关服务。
jmszhang 12 小时前
比较同意。

其实也就是将容易变化的因素（或者说规则引擎），在这里是与组织机构相关的一部分规则逻辑，抽取到工作流引擎之外处理。

和组织机构相关的部分其实还有更多，一般的工作流软件是为每一个人工活动定义执行人（角色、执行人）等。
顺着你的想法，上面这个过程可以反过来，也就是说在组织机视图中定义每一种角色可以执行的节点。
ltian 12 小时前
大概就是那个意思，我遇到的客户喜欢这种方式 。对于审批一类的业务用这个比较方便。分支一般在根据不同条件处理不同的业务时使用，这主要是导致流程分支时用。而不同的条件导致同一业务不同人处理时，用规则比较好。其含义是： 某某业务的处理权限规则。一家之言，个人遇到的一些客户现场的问题之后的一些思考，仅供参考。
jmszhang 13 小时前
那最起码有一个简单的流程吧。
如将上面的分支流程做成最简单的流程？

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


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

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

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

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

 

从规范的角度：

 

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

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

 

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

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

 

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

 

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

 

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

似乎更有意思一些！

 

ltian 2008-08-22
规则很多并不可怕，可怕的是对规则进行硬编码。增加新的规则就是向规则库中增加记录，没有什么可怕，规则引擎的接口是稳定的，工作流调用规则引擎的代码也就稳定了。那么即使规则成千上万，不需要改变程序代码，还有什么可怕的呢？
RCFans 2008-08-22
多花点时间研究一下现成的东西吧，这些问题早就很好的解决了
tsylo 2008-08-21
如果仅仅是暴露条件借口，那osworkflow很明显是个典型的代表，和你说的解决方案很符合。
如果要固定做一个规则库，每个流程有每个流程的特点，这个流程的规则是：如果金额超过10w就报处长审批，那个流程的规则是：如果上一步是A提交的，就提交经理审批，规则实在是五花八门，使用自己写的规则库来绑定工作流，到最后可能会觉得库无法穷尽，每一个流程几乎都是一种新的规则。
whiletrue 2008-08-14
引擎独立,暴露一个执行者接口.怎么实现,看你的了
我们的做法是做个配置,让管理员自由添加条件,制定规则,感觉不错.
justshare 2008-07-24
看到你在别人那边的回复，就跟着跑进来，才发现，原来。。。。好吧，不下结论了，给你多点时间。
发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

您还没有登录，请登录后发表评论

ltian
搜索本博客
最近加入圈子
存档
最新评论