可配置參數維護模型及實現方法研究

雷平 禹熹 孟凱

關鍵詞：容器；調度；狀態轉換；任務驅動

1引言

本文提出一種可配置參數維護模型及其實現方法，應用于多參數維護（如金融信息處理）領域。目前，參數維護形態主要包括單參數表維護、多參數表維護和級聯參數表維護，以及所有形態之上的參數狀態機維護。

通過固定參數維護模型的解決方法，可以使維護流程獨立于表級維護之外，提高代碼復用率，保證流程的統一[1]。該方案使用了參數表結構，通過數據表字段簡單配置并根據配置數據實現語句的動態生成，再通過服務端回傳的配置信息動態繪制統一界面。該處理方法非常適用于新業務、新參數需求快速響應的場景。

2設計思路及具體實現

參數維護是Web管理平臺的重要功能之一，其核心功能是為系統中的生產參數的查詢、新增、修改和刪除功能提供可視化，且利于操作界面維護。另外，需要為此操作任務實現統一的控制流程，使不同角色的業務運維人員基于參數維護框架權限進行控制。為實現參數操作任務的流程管理，且不影響生產中使用的參數數據，整個參數維護流程是基于臨時表完成的。流程一般可以分為如下步驟：首先，通過直接錄入或者查詢后更改參數創建任務；其次，參數在臨時表中實現復核、修改、生效等流程。而在生效流程中又分為三步：臨時表同步到正式表、發送生效的消息給其他子系統、其他子系統應答。

詳細的參數維護流程如下：首先，由經辦員創建新增任務，對于錄入中的任務可反復發起修改，經辦員此時可以查看任務詳細信息、正式表參數信息、修改任務權限等。經辦員完成后提交該任務，任務狀態為待復核。復核員在流程中發現有待復核的任務時，可查看任務中參數表詳細信息及任務信息，隨后可進行任務復核操作，若復核不通過，任務重新流轉給經辦員，狀態重新置為錄人中，供經辦員重新修改該任務。若復核通過，生效員可提交生效任務，任務進入生效流程。生效員查詢到與正式表同步失敗的任務，可發起重新同步操作，成功后系統會繼續自動同步其他子系統。同時，生效員也可以發起回退操作，此時任務會回退到復核失敗狀態。若查詢到與其他子系統同步失敗的任務，可重新發起同步操作，成功后任務進入同步成功狀態。另外，生效員還可以發起強制生效操作，此時狀態變更為生效成功。最后，所有任務都應該是同步成功的狀態，此時發起關閉任務操作，后臺會刪除該任務記錄、參數表的臨時記錄。若發起的是刪除任務，也會物理刪除正式表中的參數信息[2]。

可配置參數維護模型主要包括兩大部分，如圖1所示。第一部分即前臺部分，采用Caimgorm輕量級框架，利用富客戶端技術實現。根據后臺Java應用生成的XML數據接口，動態生成參數維護界面，完成參數主題域維護任務。對于不同的參數主題域或單表，只要后臺Java應用根據Flex客戶端的不同請求生成不同的XML數據，采用XML數據接口方式完全實現了前后臺解耦，為前后端實現提供多種選擇[3]。

任務列表頁面會顯示獲取的主題域信息，主要是當前主題域及其不同狀態的任務統計信息，并提供相應的操作人口。界面功能分類如下：任務處理狀態主要統計人工處理流程不同狀態下的任務數目：任務處理分類則查詢任務統計的分類標簽，用于查詢對應任務處理狀態的任務：任務處理操作人口根據不同處理狀態任務，在查詢出來后操作界面區提供不同的按鈕，便于后續任務處理操作。

基于框架的前端設計流程如圖2所示。在View層中定義了整個前臺框架的頁面繪制部分，包括框架視圖、查詢正式表視圖、任務信息視圖、任務列表視圖、任務操作欄視圖、詳細信息視圖、特殊展現視圖、自定義視圖等。視圖通過派發事件（Dispatch Event）與控制層交互。

在控制層，即通過前臺控制器FrontController來監聽用戶的操作行為。在Caimgorm框架中，前臺控制器是事件的唯一監聽者，并不進行實際任務的操作，通過addCommand來確定管理事件（Event）與命令（Command）的映射關系。參數維護模型框架定義了任務控制器TaskController、參數控制器ParamController、配置類控制器ConfigController和界面跳轉類控制器SessionController。

命令層（Command）通過調用execute來負責處理事件。在參數框架中包括三大類命令：任務類（TaskCommand），如創建新增任務、修改任務、刪除任務、任務提交等；參數類（ParaCommand），如查詢臨時表、查詢正式表、新增臨時表記錄、修改臨時表記錄等；配置類（ConfigCommand），如獲取主題域信息、表配置信息、下拉框信息等。Command執行時負責獲取數據，通過委托給業務層Business Delegate類處理具體的業務邏輯數據獲取。

業務代理層（Business

Delegate）主要負責提供Command和Service所謂的無縫接口。BusinessDelegate匹配Service的名稱后會調用后臺Java接口，并返回結果給Command層，這時Command通過IResponder接口獲取返回的數據，并更新定義好的Model，Model綁定于View，如此即完成了后臺結果返回至前臺的展示。

任務驅動的流程模型如圖3所示。在該模型中，整個參數維護模型均基于任務操作。首先，經辦員可分別發起創建任務、修改任務、刪除任務；復核員發起復核任務：生效員則可分別發起生效任務、重新生效任務、強制生效任務以及強制成功任務。其調用邏輯方法類似，均由前臺Flex傳人flashVar：由主題域ID（subjectld）、表ID（tableld）、事件列表（eventlds）構成，調用任務操作服務類TaskService．最后由XML處理類返回給前端Flex繪制。

參數表操作時的記錄狀態及轉換如圖4所示。在對參數表進行新增、修改、刪除操作時，可以調用參數服務類ParameterService，通過其涵蓋的對應操作方法類，再調用后端服務提供的操作方法，返回給前端結果[4]。對表級操作時，比較重要的是記錄狀態的變化。新增參數時，對于臨時表操作標識為I（新增）時，無論用戶如何修改記錄，狀態都不會發生改變，始終為I。若用戶執行刪除操作，將會導致記錄物理上的刪除，此情形不存在狀態的轉換。在修改參數（用戶創建修改任務）時，會初始化所有存在的參數，并將其記錄到臨時表中，同時標記狀態為A（中間狀態）。執行修改操作時，在編輯參數界面點擊保存會觸發狀態變更，此時狀態會改為U，即使沒有修改值，只要點擊保存均會更改狀態為U。若此時對記錄參數進行刪除操作，則會重新將記錄狀態標記為D。創建刪除任務時，會直接標記參數狀態為D，此狀態也為最終同步到正式表的狀態。

圖5描述了同步、生效的操作流程。在復核通過之后，生效人員進入生效流程，并調用StartActiveTask接口觸發命令。由于存在批量的情況，此時將批量事件信息發送到容器的MDB消息中，狀態為暫時同步狀態。MDB收到消息后調用接口SyncTableService進行同步正式表操作。此時，將任務狀態修改為生效中，調用SendParamMessageService接口發送生效消息報文給子系統。通過參數子系統應答消息處理ParamForSubsysCaIIBack接口來進行生效成功判斷，最終完成整個生效流程。

對整個參數維護流程進行適當的擴展也很有必要。在實際的參數維護過程中由于復雜程序不一，往往需要在任何一個操作階段進行附件操作。此時，據此采用通用接口的方式，在進行創建新增任務、修改任務、刪除任務、新增表、修改表、刪除表、任務提交、任務復核、任務生效、任務同步、任務回退、任務關閉、任務強制成功、查詢表、同步表、特殊條件過濾、發送消息擴展等行為時，提供執行前、執行后的方法供調用，使其具有高擴展性，適用于特殊情形的表級維護，如圖6所示。

3結論

本文提出了一種可配置參數維護模型，并給出了具體的實現方法。所述的方案具有如下顯著優點：模型采用富客戶端與后端通用接口應用方案，具有良好的操作性和擴展性。前后臺數據交互基于標準XML格式，流程管理模塊采用參數化方式組裝，代碼的復用率高。該模型也采用了流程化引擎思想設計，在維護的各環節均提供了大量擴展接口，便于模塊化移植及個性化擴展。另外，參數維護前后臺無縫銜接，便于流程的統一應用及變更，參數化的配置方式也使得用戶可自定義顯示界面，使流程模塊不變，從而提高模型的靈活性。