基于低代碼平臺的合同管理系統開發

王天媛，張楷

（天津航天瑞萊科技有限公司，天津 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源碼為基礎的，對于目前流行的各類前端框架無法使用，所以僅能使用簡便的頁面設計，而如果全套前端自行搭建框架實現的話，對流程綁定表單等功能會有影響，無法使用流程；其次，所有業務邏輯必須流程化。對于合同管理系統來說，流程是必須的，所有操作都需要經過審批，把這個低代碼平臺的作用發揮到極致了，但如果對于其他業務，不包含流程的需求支持度不好，任何一個操作都需要轉化為流程，比如編輯自己客戶的信息，原本編輯修改的操作要改成發起修改流程，即使不需要審批。

總的來說，低代碼平臺是利大于弊的，但也需要結合自身業務來確認，比如，對頁面要求很大但又不需要流程的系統來說，該套平臺是不適用的，強行使用反而耽誤工期，影響系統效果。所以利弊了解清楚才是關鍵。低代碼平臺的本身也是用傳統開發模式開發出來為大家提供便利的，因此并不能說低代碼平臺可以完全取代傳統的開發方式，兩者是并存的，無須因為部分的限制完全排斥低代碼平臺，也無須完全無視這部分限制而堅持使用，畢竟開發一套系統需要消耗人力物力，所以選擇上還是很重要的。希望每一個系統設計人員可以在充分了解低代碼平臺的優缺點的基礎上，結合自身系統的業務需求，選擇合適的開發方式，充分發揮低代碼平臺的優勢，提高開發效率。