人工活动, 谁启动了该流程, 该活动就分配给谁 (参 与者为流程启动者)。
4、 《经理审批》会在该员工的请假单上填写同意与否和备注(经理参与 者由前面活动动态指定)。
5、 《条件判断》是路由活动,有2个后续分支,如果审批为不同意,则 会把该表单反馈给申请者。
6、 《数据处理》是自动活动,根据请假类型和请假天数,存入请假系统 中
7、 《请假人销假》填写实际请假天数,存入请假系统,并和考勤系统, 工资系统交互会。之后该流程会全部完成
四、系统
设计 1、 界面设计
该流程在《请假单填写》,《经理审批》,《请假人销假》设定的 是3个人工活动,采取Flex作为人机交互的界面,界面设计采取自定义界面方 式。
《数据处理》这里是自动活动,没有交互界面,在审核通过后自动 处理,在这里是调用一个业务逻辑处理;《申请人销假》是人工活动,在销假完 毕后, 脚本中也会调用到几个预先设定好的业务逻辑处理, 分别完成一些系统的 后台处理。
《请假单填写界面》:填写基本信息后,选择自己的审批人,在下 拉列表框中选择自己的上级。
图5:请假单填写界面
《经理审批界面》
打开后获得该用户的填写纪录
1、填写审批过程
2、在结论处选择通过,不通过
选择不通过后,该页面会反馈给申请人,需要重新填写
这个时候只有请假时间和事由可以重新修改,其他输入框为只读
图5:经理回复界面
2、 流程设计
在流程详细说明的基础上,在流程建模器中设定业务流程
图6:流程建模器设计的流程 在设计流程的时候,有3个地方要注意:
A. 请假单填写,需要选定上级审批人,选定后,该页面将由选定的的审 批人打开
B. 经理审批,有个结论进行YES/NO的选择,选择yes,表示通过,
C. 条件判断节点,设定一个相关数据,用来控制后续变迁的走向
3、参与者设定 人工活动就是需要有人参与的工作流活动,在实际流程中, 它体现在产生由人完 成的工作项以及由人决定一些决策变量, 这些决策变量会对流程的运行产生影响 (例如分支的选择等等)。 在流程中确定参与者,有2种方式:设计期间指定和运行时动态指定 1. 设计期间指定:在建模器就设定了某人工活动的参与者,该参与者类型可以 是员工,角色,部门,如果是采取部门,角色的参与者,他们之间有个竞争关系, 看谁能获取到该任务。 2. 运行期间动态指定:需要在流程运行期间指定的,比如有的人工活动是流程 启动者就需要的,还有的人工活动是前面页面中指派的。比如请假流程, 《请假 单填写》活动,就是由流程启动者来完成,他启动这个流程就是为了完成自己的 请假申请。《经理审批》活动,其参与者是由前面活动指派的,在流程设计期间 并不能预见谁是该活动的执行者。 参与者设计期间指定,这种方式简单,这里不作阐述。参与者动态有2种类型: 1、 参与者为流程启动者,设定参与者类型为“assign_myself”,流程启动后 会有个信息存储在run process表中,由engine负责提取。 2、 参与者由前面流程指定,设定参与者类型为“assign_ dynamic”:
A、 设定相关数据, 方式经理审批的路由判断方式一样: 在 《请假单填写》 活动中,设定一个应用数据,并在《经理审批》活动设定一个相关数据, 应用数据和相关数据的id相同,engine会自动根据相关数据的id获取 应用数据的值,从而获得参与者信息
B、
程序指定,在《经理审批》活动所引用到的参与者,在这里设定一个 class,负责返回一个员工信息,该员工信息即为该活动的实际执行者。
4、表设计,自动生成代码
假定我们已经获取了需求, 该需求就是设定一个请假流程, 并且界面也提交给用 户,并且获得了通过,用户交互界面看图4,图5。
然后我们采取表驱动设计模式,对于密集数据的企业应用,比较适用的,设计