最近我们的产品在山东港试运行,由于上个月对我们的工作流平台提出了流程预设置需求。在大多数流程平台采用配置到人的策略时,我们全面引入了执行者作为审批人员基础。
在配置过程中,为了让流程在集团内广泛适用,并能自动按照规则完成符合身份人员参与到流程审批中,执行者与参照体系让我们的工作流平台拥有了绝对优先的能力。
但广泛适用的同时,审批人员将无法完全准确获取,会签节点暂时是无法提供自动识别能力的,需要发起人在流程发起时,对整体业务流程中的执行者进行一次设置,及流程预设置功能。
流程预设置是工作流引擎的一个高度中和运用。在这次调整中对组织结构的员工模型添加了属性,由于没有为对象添加serialVersionUID属性,使虚拟机在进行对象序列化时自动生成了个serialVersionUID编号。
生成规则是根据包名,类名,继承关系,非私有的方法和属性,以及参数,返回值等诸多因子计算得出的,极度复杂生成的一个64位的哈希字段。
也就意味着如果模型对象变化,serialVersionUID的值就不一致。虚拟机在序列化反序列化时,会优先对比serialVersinUID,如果不一致,将不进行反序列化。这就意味者对象不兼容了,
昨天的问题由于对象不兼容,时在途流程无法正常支持。由于产品在试运行期,并且刚下通知试用预设置功能。所以在跟换版本后的两个小时内,全集团上报了60多份合同,为了兼容大局,全库中有2k多流程业务单据,为了大局,只能把serivlVersionUID设置到先前版本,这60多份业务单据只能进行手动处理了..........
所以:在今天之后的模型构建中,必须为所有支持序列化的对象提供serialversionUID值,原则上在后续的版本中不允许修改,如果需要修改,需要对序列化与反序列化进行评估后执行。
private static final long serialVersionUID = xxxxL;