因表单设计器满足运行过程中的表单修改(增删改字段),所以表单版本控制不需要特别修改。如仍希望进行控制,也应是通过不同表单版本对应不同html,而后台数据库表名不变的形式进行。如每发布一次表单版本对应一张新表,版本控制也失去了原有意义。
建议表单版本控制仍按现有方案,不做变动。
以最近一次离职单更新为例,新版本离职单增加了部门会签功能,将原本在线下走的行政、IT、财务、学院的审批放在线上进行。新版本不仅流程重新规划,表单变化也很大,比如新增了是否签订以及是否需要履行竞业协议、部门会签意见填写等等。在流程版本管理的有效控制下,新老版本流程均能运转正常,但是表单就存在冲突。为保证新老版本之间的协调,临时的解决方案是:保留新老版本所有流程实例对修改前后字段的可见性。这样最大的缺陷就是新老版本的样式及字段纠结在一起,凌乱无序,用户体验极差。
所谓版本管理,就是对版本标识的管理,让不同版本之间的表单相互运行,互不干涉或者具有一定规律的相互兼容。OA表单版本的管理就是要做到相互独立,各不干扰。
方案如下:为表单建立版本表,以存放历史版本信息(包括最新版本信息);最新版本信息存放在表单定义表中。在流程的发起以及审批时将表单版本信息带出,凡有取fromDefineId的均应替换为对应的verId。为兼容无版本管理之前的流程:如版本id为空,则取formDefine表中最新的formDefineId所对应的html、template。同时表单权限的设置需以verId为标识,而不是formDefineId为标识。
表单管理方案的缺陷:表单的更新较版本的更新更加频繁,这样会大大加重开发和运维人员维护表单权限表的任务量。
缺陷的解决方法:表单版本的更新不应像流程版本更新一样,每次发布必然产生一个新的版本。点击表单保存后,应当弹出选择框,由开发或运维人员决定是发布一个新的表单版本还是不发布新的表单版本。如果发布新版本,则需要维护表单权限;如果只是js或增加隐藏字段、修改样式,则可以选择不发布新版本,保存的动作不更新版本号。
字段名称 | 字段类型 | 约束 | 备注 |
id | varchar | 版本标识 | |
formDefineId | varchar | 表单标识 | |
html | |||
template | |||
talbeDefineId | 实体表id | ||
2.3.2 t_bpm_form_define增加一列version(目前已存在)
2.3.3t_bpm_process_execution增加version字段,以此作为标识加载表单
2.3.4目前已知的多数打开流程的action都是doJob,以doJob作为入口,并且将所有的queryByFormDefineId以及FormDefineEntity.getHtml等处,均可能需要替换。
风险:改动涉及面较大,改动处较多,需全面测试。
最终方案采用本文档中所述表单版本管理方案。
本文出自 “江南矿工技术空间” 博客,请务必保留此出处http://jncumter.blog.51cto.com/812546/1746247
原文地址:http://jncumter.blog.51cto.com/812546/1746247