关于企业组件延续性说明

2015年7月,从广州回长沙,跨越了应用行业,从配电网应用开发进入管理软件行业。一切重新开始,也不是重新开始。在广州的三年里,工作之余完成了中级软考,这为近4 年的工作打下了业务基础。软考的相关内容在近4年的工作中得以全面应用。合同管理与法律事务管理,我们现在的业务版本,完成了软考中关于合同,软件,及项目管理的整体知识。

合同管理与法律事务管理,基于统一的业务平台为不同的企业/行业打造适合的合同管理或法律事务管理平台。以合同管理为核心,控制签订前事务,签订过程内部审批,合同签订后履行跟踪,合同结束后合同评定等合同全生命周期管理,并且在发生合同纠纷后进行法律事务管理环节等。平台不断地进行更新,吸纳实施过程中遇到的业务场景,形成了当前较为完善的基础平台。

本人进入企业后,有幸赶上了工作流重新定义环节。在全面认识现状的基础上,对工作流引擎进行了延续性改造,使产品能快速增量替换已推广的客户,使客户快速转入新版本的使用中。

工作流引擎,作为管理软件的核心组件,必须是稳定/开放/可扩展/可后期干预的软件平台。才能有生命力,才能兼容客户的实际应用场景。我们的工作流已经接近50程序包组成,但原则是简单的,对工作流事务继续了前/中/后,三个动作拆分。前/后提供了完整的切片方案,使业务应用过程中可以根据业务进行定制。所以在R9版工作流推出后,平台从6个扩展点增加到了近60个扩展点。可以是前置代码扩展,也可是前置存储过程扩展;可以是后置代码扩展,也可以是后置存储过程扩展。使工作流组件可以应用到各行各业的具体业务实现中。

经过前三年业务的完善,平台基本功能已较为完善。在业务应用过程中,相应又提出了审批过程单据概念。用于实现基于岗位或基于特定节点的数据录入功能,并为审批过程单据与标准业务单据间建立了填充机制,使数据的产生可以贯穿整个审批过程,使审批过程更具有实用性。当前审批过程单据已经在多家企业上线使用。

随着业务量的增加,工作流组件的性能成为了核心问题。奇瑞集团有将近4万人员的组织数据在合同管理系统中,参与审批的人员将近4k。已完成审批项将近100w级。基于管理软件数据逻辑的辅助性,软件的计算量是惊人的。由于前期产品基本是单应用类型。所有事务完成依赖与web网站提供服务,使产品在现有4台服务器的支持下基本达到瓶颈期。

近期我们对消息提醒机制进行了改造,把原有由复杂视图提供数据的机制,调整为把消息数据物理化,使用rabbitMQ消息组件完成消息数据的生成,状态的同步以及特定数据的更新。并引入产品基础服务组件,使用quartz调度器完成数据修正监测服务,保障消息数据延后一致性,这将释放大量的计算能力。以便提高工作流组件的吞吐能力。

在改造消息机制的同时,提出了数据访问与数据操作分离方案,对已终审的流程进行转存,以便降低运行库的数据量,用以保障工作流运行能力。

当前我的团队,从手动修订工作流运行异常,转向到对客户的业务梳理,业务改造,与业务规划方向。

我们的工作流组件在不断完善,延续性完善中,在不断吸收客户业务使用场景,以便全面支持客户的业务发展需求。

原文地址:https://www.cnblogs.com/thubier/p/11944280.html