完 表结构,采取代码生成方式生成了base_api,假定调试并且通过单元测试。这 些base_api里面涵盖了对请假表的增删改查功能以及对周边系统的处理机制
图7:表设计示意图(工作
列表、活动定义是engine的已有的定义)
有如下主要api
====================================================
活动 需要的API 说明
----------------------------------------------------
请假单填写 insertLeaveInfo()
updateLeaveInfo() 在请假表中插入新纪录
----------------------------------------------------
经理审批 getLeaveInfo()
updateLeaveInfo() 在请假表中更新纪录
----------------------------------------------------
数据处理 getLeaveInfo()
updateWorkDayInfo()
insertWorkDayInfo() 在工作日报表中新插入、更新纪录
-----------------------------------------------------
申请人销假 getLeaveInfo()
updateLeaveInfo() 在请假表中更新纪录
updateWorkInfo() 在出勤表中更新纪录
updateSalaryInfo() 在薪酬系统中更新纪录
-------------------------------------------------------
这里只对“请假人销假”作一个业务逻辑事例,其他的类似,设计业务逻辑有3 种方式,目前拟使用直接生成代码的方式 假定销假业务逻辑用到了如下api: ===================================================== api名称 函数说明 ------------------------------------------------------ updateLeaveInfo 更新请假表 getLeaveInfo 获取更新表信息 updateWorkInfo 更新工作日报表 updateSalaryInfo 更新薪酬表 ------------------------------------------------------ 以上api可以是代码生成直接使用,也可以是手工设计, 以上api称呼为原子服 务 或 base_api 判断节点:当请假为婚假,休假,只是修改工作日报表
如果是其他请假类型(事假,病假,扣薪水的基数也有不同),则还需要修改薪 酬表,表示需要扣点薪水 ;)
图8、申请人销假后的业务逻辑设定
五、实例运行
1、 流程平时保存在模型库中,点击启动后,就会产生一个流程实例,每个实例 都不同,流程实例有自己的主键,每个流程的活动,同样也有唯一的活动实例主 键
2、 人工活动有两种类型,假定我们现在采取的是“自定义页面”方式,也就是 通过一个URL地址和页面关联, 并能通过一定的方式传入参数(这里需要翔实信 息),,
3、 业务页面(比如请假单填写部分)是一个没有状态的数据载体,需要有个参 数来控制界面显示什么数据。这个数据就是工单号。
A、 第一次请假单填写的时候,工单号为空,故界面展示的是一个可以输入的 form表单,(界面参看图4)。
B、 第二次是经理打开,这个界面就是前面界面携带数据流转过来的,因为是请 假单数据,故是调用getLeaveInfo(),这个时候需要从第一个页面携带的工单 号,用于提取已经保存的数据,经理在其后填写其他内容(界面参看图5)。
C、 这里有个很重要的地方,就是填写结论结果YES/NO,如果是yes,则调用后 续的自动活动,如果是NO,则返回给请假申请人,需要他修改部分条件,重新 申请一次。在判断后续分支走向,这里有2种方式,我们这里假定采取一种免编 程的方式[注5]。在设计流程的时候,该“经理审批活动”处需要设定一个应用 数据(applica