工作流是什么样的产品?

在企业里面,因为有组织机构的存在,有些事务的办理需要有一套流程,各部门人员协同工作时,需要共同遵守流程规则;依此进行流程的发起、流转和结束。工作流存在的目的就是解决任务办理时的资源分配、流转路径选择和表单数据权限处理。特意总结了工作流的3个基本职责,可以说明如下:

1. 应对业务规则的变化
比如常见的员工请假流程:如果低于3天提交部门经理,如果多于3天以上,提交总经理审批。这就是一种流程。按照常规代码处理时:

if days < 3
    submit to Department Manager
else if days >=3
    submit to CEO


或许有人会问,既然我代码可用处理,为什么还要用工作流呢?

1). 主要考虑流程的变化因素不可控,比如,公司出来一项新的政策,说是5天以上总经理才去审批,这个时候,如果通过编码的方式就要改代码了,再重新发布,系统的可扩展性太差;

2). 假如有人说我不去把请假天数硬编码,我放在配置文件里面不就可以了吗?
的确是可以的,主要的好处不用重新发布程序。但是这样做,跟流程相关的规则还是零碎的,分散的,不是完整放在一起的。

3). 我们可以认为办法2)就是工作流的萌芽思想,我们将所有跟业务规则有关,任务办理人员有关,任务数据权限有关的信息全部整合的一个配置文件里(相当于流程定义或配置信息),然后在程序运行时,读取这个配置文件,判断流程的执行流转走向,最终结束。

在流程定义文件中,分支节点上的连线可以用来定义规则,可以举例如下:

            <Condition type="Expression">
              <ConditionText>
                <![CDATA[
                      askDays < 3
                ]]>
              </ConditionText>
            </Condition>


2. 维护活动节点的资源
继续看员工请假流程的变化,不仅仅是业务规则发生变化(规定的请假天数),活动节点上的资源也会有变化,假如:公司规定,员工请假时,如果部门主管不在的时候,可以直接发送给HR主管:

if days < 3
    submit to (Department Manager || HR Manager)
else if days >=3
    submit to CEO

从第一点我们总结出,工作流就是把所有跟业务规则有关,任务办理人员有关,任务数据权限有关的信息整合在一个配置文件里。此处角色的变化,同样遵循这个原理,角色作为活动资源,绑定到节点上,可以增加或减少。角色资源在流程文件中的定义如下:

            <Performers>
              <Performer id="3c917748-6752-4bc6-aea8-b85d40521888"/>
              <Performer id="8e54c07d-d424-4186-b86c-cec43019bed0"/>
            </Performers>



3. 控制活动节点的数据权限
应用系统中,单据数据读取或修改权限非常重要,每一个流程步骤的业务数据处理,都会有明确规定,只有具备相应权限的人员才可以修改数据。其关系可以表示为:{ Node, Role, Field }的三元表达式。
比如在请假流程中,只有员工自己可以在“请假申请”节点上修改请假天数,而后续节点的部门经理则不能修改请假天数。数据权限始终要根据节点位置和角色共同来定义。

总结:
以上是对工作流的基本功能职责做以说明,鉴于加入Wf5项目的人员可能对工作流刚接触,特意描述,完整的流程定义文件可以参考项目中的xml文件。此外,后期我们再继续对工作流模式,引擎原理等再做出解释和说明。
发布了22 篇原创文章 · 获赞 10 · 访问量 24万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览