基于低代码平台的合同管理系统开发

王天媛，张楷

（天津航天瑞莱科技有限公司，天津 300462)

1 引言

随着计算机行业的不断发展，各行业信息化建设的不断完善，系统开发的需求量越来越大，而传统的系统开发方式存在着开发周期长，维护困难等问题，因此，低代码平台越来越受欢迎。低代码，顾名思义，使用足够少的代码完成系统的开发，本质上就是将大部分通用功能进行封装，而个性功能通过界面的拖拽和业务逻辑代码的绑定来完成，大大降低了开发难度和开发周期。传统的销售合同管理系统是具有普遍性和通用性的，但试验检测行业的合同管理系统具有自身的独特性，合同的属性、钱款的流动，流程的审批等都不同于普通的销售合同管理系统，而且合同数据等需要跟试验检测的业务系统进行对接，因此采购的合同系统无法满足自身需求，需要定制开发。如果采购系统后进行二次开发，局限性大，灵活性小，成本高，数据无法自己掌控，因此，使用封装好的低代码平台，省去开发框架搭建，编写自己业务逻辑成为最好的选择。

2 低代码开发优势

2.1 开发速度快

传统开发方式开发系统需要搭建代码环境，确认架构，构建数据库实体，对于合同管理系统来说还需要进行流程引擎的开发，然后才能进行业务的开发，上述整个流程，有专业的技术团队支持也需要半年左右的时间。而低代码平台基于可视化编程语言，依靠少量的代码就能完成上述工作，在很大程度上剥离了专业业务知识，进而实现提质增效、降低成本的目的[1]。例如页面表单直接通过数据库字段生成，流程走向在界面拖拽设计，除在业务逻辑处理上需要少量的代码支持外，难点仅在于低代码平台接口的熟悉与使用，无须搭建代码架构，直接调用接口开发，开发周期缩短到两个月左右，人数可一到两人，省时省力。

2.2 扩展性强

低代码平台的特点在于低代码，高扩展，简单来说就是公用的部分进行了封装，个性的部分支持扩展。以组织架构为例，一般系统都需要有组织架构，这样才能确认使用者，所以平台直接集成了组织架构功能，但不同业务对组织架构的需求不同，例如有些系统的架构需要进行同步而非直接设置，有些业务需要对架构人员赋予角色、权限，有些业务需要组织机构的代码来拼接编号，因此，平台在提供组织架构的基础上提供了个性化设置，允许对接其他接口同步，也允许各类角色的设置，并支持额外属性的设置，能够满足大多数业务需求。

2.3 易上手，学习成本低

使用传统的开发模式，大多数人都会面临一个问题，即开发人员不懂业务而业务人员不懂开发，这就使得整个开发过程业务人员无法介入而开发人员仅通过文档进行编写代码，最终会导致开发出来的程序与实际业务需求存在偏差。

低代码开发平台通常将在线表单、流程引擎、数据报表、用户界面等进行模块分装，让不具备IT背景的用户通过“搭积木”的方式完成业务应用的开发[2]，所以低代码平台除了实际的业务处理需要代码实现外，其他的大部分内容是通过界面拖拽等方式来完成的，也就意味着，使用者不需要完全懂代码逻辑，只需要确认自己想要实现的问题即可，换言之，界面设计和流程设计可以不需要程序员，业务人员可以通过简单的培训来完成。以流程设计为例，开发人员无法了解在实际业务中，合同需要谁来审批，不同的金额，不同的部门如何去分配，使用低代码平台开发，业务人员了解简单的使用规则后，在开发的辅助下可以直接进行拖拽设计，省去了产出逻辑关系图和给开发讲解的时间，简单的流程仅需几个小时便可完成，规避了沟通带来的成本与风险，加快了开发进度。

2.4 支持微服务架构

如今各个企业的信息化建设在逐渐完善，即使非互联网公司也需要各种系统作为日常工作的支持，而对于这些应用的部署和管理就成为企业的需求点，多个系统使用多个服务器部署会导致运维困难、成本高等问题。如果单独建立一个合同管理系统必然会和其他的应用系统的一些功能和数据重复，造成重复建设，产生新的数据孤岛，数据无法有效利用[3]，而微服务架构使得各个服务间独立部署的同时又可方便地进行接口互通，避免了数据孤岛的产生，且每个服务独立启停，不影响其他服务，可单独进行系统的升级维护。低代码平台直接集成了微服务，无须额外开发，仅需将不同业务开发成不同的应用，每个应用作为一个服务独立运行，互不影响，可按应用独立启停，可同步运维。

3 基于低代码的合同管理系统开发

3.1 开发准备工作

结合业务定制需求和流程的需要，选用流程引擎为主的低代码开发平台最为合适。开发开始前需要将业务需求转化为开发需求，并完成数据库设计，理清业务逻辑，梳理开发要点，便于后续程序开发。

以客户管理为例，业务部门提出的需求点在于：客户池的建立和维护，客户信息需要包含基本信息，工商信息，财务信息和联系人信息，有客户池，有公共客户，公共客户可再次分配；梳理上述业务需求后，业务需求到开发需求的转换如下：客户存储表分为基本信息表、财务信息表、工商信息表和联系人信息表，客户基本信息表为主表，其他几个表以客户编号作为外键，同时还包含公共客户的状态位，能够分清客户的归属，另外了解到一个客户允许多个客户经理，就额外需要一张记录客户经理、客户以及联系人关系的表，以各自的编号存储，理清客户与客户经理的一对多、客户经理与联系人的一对多以及客户与联系人的一对多关系，并产出数据库关系图1，以及实体关系图2。

图1 数据库关系图

图2 ER图

基于上述的准备，所有的业务需求均可转化为对数据库的增删改查操作，再根据低代码流程平台的特性，将所有业务划分为流程结束前后、表单提交前后，子表更改前后等节点发生，例如：在客户新增表单提交前校验必填项并生成客户编号，客户新增流程结束后更新客户库表及对应的财务工商等关联表信息。将所有的业务划分规整之后开发就会变得很容易。

3.2 表单设计

数据库和业务逻辑都已经完成了拆解，开始进行系统的开发。平台中表单模型采用了开放的技术架构和VUE3.0，灵活性高[4]，可自行创建也可根据数据库字段自动生成表单，开发人员只需要根据实际情况进行字段的删减隐藏，修改UI组件类型，设计界面风格等即可，图3为表单设计图。

图3 表单设计图

如果特殊界面需求，可通过编辑页面源码，写html和js来做实现，数据的获取可以通过ajax调用后台接口。图4为源码编写界面。

图4 源码编写界面

总的来说，表单的设计是很灵活的，一般的需求均可实现，如果不喜欢统一的默认样式，官方是给出了几种简单的配色方案的，都不满足也可以自行编写css修改样式，除了不能用IDE编码这一方面不太方便之外，其他都能满足开发与业务的需求。

3.3 流程设计

流程的设计这里最好是一个开发加一个业务人员一起来设计，业务人员清楚流程的走向和审批等相关要求，而开发人员负责实际的操作，能够减少理解差异带来的风险。

以合同审批为例，对每一步审批人员能够编辑哪些字段，每个节点需要哪些角色进行审批，到达某一个节点时判断不同的条件决定不同的流程走向等，这些可由业务人员直接进行设计，开发人员辅助，页面如图5。

图5 流程设计界面

3.4 代码开发

数据库、表单、流程都已经设计完毕，接下来就只剩下单纯的业务逻辑开发了，只需要单纯的业务上的增删改查，并且操作数据库有专门的接口，按照文档操作，代码量低，效率高。

以合同审批流程为例，业务需求是：合同审批流程结束后，将合同入库，更新合同表、交易信息表信息；从代码角度来讲，就是监听流程结束事件，在结束的时候，执行数据库更新操作，所以代码需要继承监听类，然后实现流程业务，绑定在流程事件上[5]。代码如下：

可以看到，在实现的execute方法的时候，是有“ProcessExecutionContext”这个参数的，通过这个参数，直接拿到与流程有关的所有属性，包括审批人、审批信息、表单数据等，所以只要知道如何获取这些数据，使用这些数据完成业务逻辑即可。

3.5 代码部署

开发人员写完代码后，需要将代码进行部署。该低代码平台支持微服务，每个应用单独部署启停，将编写完的代码打成jar包，放在对应应用下的lib文件夹下，系统检测到jar包增加或更换，系统会自动重启该应用，对jar包的名称和数量没有限制。

当jar包部署完之后，找到对应的流程，在流程设置里找到事件绑定，因为此前继承了特定的类，所以在绑定的时候选到情景之后就能直接找到对应的类。例如上面的代码，完成的是合同审批结束后更新表的操作，那就需要在流程设置的事件绑定中选择“流程结束后事件”，然后选中刚刚写的类名添加，保存。然后就会在实际审批结束后进入到这个方法执行，非常简便。

4 结束语

本套合同管理系统从业务提出需求到完整上线历时四个月，其中业务需求转换为开发需求及数据库设计工作用时半个月，系统开发两人共两个月，测试、修改bug共用时半个月，上线试用，功能调整用时一个月，目前系统稳定运行时间已一年左右时间，其间未出现宕机、数据丢失等问题，在运行半年多的时候考虑数据量问题进行过一次数据库迁移，备份及迁移共用时半小时。使用大半年后，综合公司业务部门需求进行过一次升级开发，增加了一部分功能，包含对历史数据的兼容、现有数据的处理统计等问题，共一人一个月的时间。

从上述数据可以看出，本套系统最多开发的人员为两人，最初开发的时间也就两个月，运维便捷，一人足矣，升级对原程序业务无影响，迁移及升级都在半小时内可完成，整体对比传统开发方式在开发人数上大大缩减，开发时间上缩短不止一半，运维、升级、部署等都一键完成节省了人力物力，且系统运行稳定，未出现过漏洞、攻击、程序崩溃等问题。

图6 代码绑定界面

全程参与开发运维之后，总结出不足之处有以下几点：首先是前端的限制性较大，如果不使用系统默认表单，编辑前端页面比较麻烦，因为页面更改是以html源码为基础的，对于目前流行的各类前端框架无法使用，所以仅能使用简便的页面设计，而如果全套前端自行搭建框架实现的话，对流程绑定表单等功能会有影响，无法使用流程；其次，所有业务逻辑必须流程化。对于合同管理系统来说，流程是必须的，所有操作都需要经过审批，把这个低代码平台的作用发挥到极致了，但如果对于其他业务，不包含流程的需求支持度不好，任何一个操作都需要转化为流程，比如编辑自己客户的信息，原本编辑修改的操作要改成发起修改流程，即使不需要审批。

总的来说，低代码平台是利大于弊的，但也需要结合自身业务来确认，比如，对页面要求很大但又不需要流程的系统来说，该套平台是不适用的，强行使用反而耽误工期，影响系统效果。所以利弊了解清楚才是关键。低代码平台的本身也是用传统开发模式开发出来为大家提供便利的，因此并不能说低代码平台可以完全取代传统的开发方式，两者是并存的，无须因为部分的限制完全排斥低代码平台，也无须完全无视这部分限制而坚持使用，毕竟开发一套系统需要消耗人力物力，所以选择上还是很重要的。希望每一个系统设计人员可以在充分了解低代码平台的优缺点的基础上，结合自身系统的业务需求，选择合适的开发方式，充分发挥低代码平台的优势，提高开发效率。