可配置参数维护模型及实现方法研究

雷平 禹熹 孟凯

关键词：容器；调度；状态转换；任务驱动

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格式，流程管理模块采用参数化方式组装，代码的复用率高。该模型也采用了流程化引擎思想设计，在维护的各环节均提供了大量扩展接口，便于模块化移植及个性化扩展。另外，参数维护前后台无缝衔接，便于流程的统一应用及变更，参数化的配置方式也使得用户可自定义显示界面，使流程模块不变，从而提高模型的灵活性。