中国移动渠道协同系统的设计与实现

1、摘要近几年，伴随着电信业的迅猛发展，国内移动运营商间的竞争日趋激烈，为了取得行业竞争优势，移动运营商们采取的重要手段之一是提高面向客户方面的服务质量。中国移动渠道协同系统是中国移动客服系统的组成部分，客服系统旨在提高客户服务的效率和用户的满意度，渠道协同系统的服务宗旨也在于此。渠道是中国移动面向客户进行销售和服务的载体，各种渠道的集合构成中国移动营销服务网(例如客服渠道、营业厅渠道、短信渠道、宽带渠道、无线音讯互动服务渠道、网厅渠道等)。本文根据中国移动湖南分公司客服系统的现状分析，为了实现各个渠道之间协同工作以提高客户的感知度和满意度，设计此渠道协同系统。本文采用面向对象的思想，以统一建模语

2、言为分析设计工具，对渠道协同任务处理过程中的相关业务进行详细的需求分析，根据需求和系统特点采用标准有效的软件设计架构来完成系统需求任务。系统的主要功能包括业务请求接入管理、随机密码服务、协同调度管理、规则管理以及流程发布。系统采用BS架构模式，功能上采用多层次的软件功能架构，技术上基于MVC基础的Spring框架，以Java为编程语言，利用XML配置以及DAO、Hibernate等相关技术实现了渠道系统之间协同工作的业务要求，渠道协同系统通过WebService方式向外部渠道系统提供服务。本文详细描述了系统的设计过程，包括系统类结构设计和数据库设计，从各个层面展现渠道协同系统的开发研究过程。渠

3、道协同系统的突出特点是处理的协同业务流程复杂纷繁，分支众多，并且业务流程多变，随时有添加协同业务流程实例的需求，针对这种特点，渠道协同采用工作流引擎技术处理业务流程，并且提供GUI配置界面，方便开发人员和非开发人员进行业务流程的发布和业务决策规则的制定。这种体系架构大大提高了系统处理业务流程的吞吐量和执行效率，避免了大量逻辑判断的存在；增强了系统的可维护性。该系统应用后收到了良好的效果，不仅提高了移动客户服务方的客户满意度，并且全面提升了移动的品牌影响力，有效的维持了老用户和争取了新用户入网，在一定程度上拓展了移动增值服务的市场。第1章绪论11系统开发背景中国移动通信集团公司(简称“中国移动)

4、于2000年4月20日成立，注册资本518亿元人民币，中国移动全资拥有中国移动(香港)集团有限公司，由其控股的中国移动有限公司(简称“上市公司”)在国内31个省(自治区、直辖市)和香港特别行政区设立全资子公司，并在香港和纽约上市。目前，中国移动有限公司是中国在境外上市公司中市值最大的公司之一，也是全球市值最大的通信公司。中国移动主要经营移动话音、数据、IP电话和多媒体业务，并具有计算机互联网国际联网单位经营权和国际出入口局业务经营权。除提供基本话音业务外，还提供传真、数据、IP电话等多种增值业务，拥有“全球通、“神州行、“动感地带等著名客户品牌。随着中国移动的发展壮大，对移动使用的客服系统也提

5、出了更高的要求，逐渐加大对用户的服务项目，提升移动运营商的市场价值。目前，移动增值服务成为移动通信的新的利润增长点，主要类型包括短消息、小区广播、WAP应用、多媒体消息和语音信箱等。短消息业务近年来在中国发展迅速，取得惊人成绩并有望进一步拓展潜力；小区广播处于起步阶段；另外，多媒体短消息服务成为热点并且正在推出。近年来，全球各运营商在语音业务方面的竞争日趋激烈，话音通信的利润空间日益缩小，移动通信网络的单位客户平均收益(ARPU)正在逐年下降。ARPU的下降，意味着收益的减少和投资回收期的延长，这对于投资兴建新一代移动通信网络的运营商来说，无疑是一个挑战。未来巨大的移动增值服务市场潜力，吸引了

6、大量的服务提供商跳入洪流，一试身手。现阶段，移动增值服务五大类基础业务发展得如火如荼，预示着一个新的服务经济时代已经到来，未来的体验经济时代亦杏帘在望。究其本质，服务的核心存在形态是应用，高性价比的应用需要开放的软件系统平台承载，这将促使在未来的移动增值服务领域中，计算体系与通讯体系在无线网络环境下的完美统一。所以，加强这些渠道的协作能力，将有力推动移动增值服务市场的发展。中国移动渠道协同系统是中国移动客服系统的组成部分，渠道是中国移动面向客户进行销售和服务的载体，各种渠道的集合构成中国移动营销服务网(例如客服渠道、营业厅渠道、短信渠道、网厅渠道等等)。随着移动的发展壮大，面对庞大的使用移动产

7、品的用户群，如何更好的对在网用户进行维系和挽留，提升用户群的满意率，加强服务效果，减少失散用户群，争取竞争对手用户，需要各个渠道之间的协同工作。所以渠道协同系统就应运而生了。12研究现状目前，中国移动各个渠道系统之间都是独立工作的，存在着很多的问题。比如在湖南地区移动服务存在着的问题：问题一，顾客通过营销中心外呼业务介绍或者朋友介绍等途径对某项业务产生兴趣，于是打电话给移动客服要求办理，有些业务客服系统可以直接办理，但有些业务只能到营业厅办理，此时客服话务员会要求客户去营业厅办理，客户到营业厅之后，营业厅人员并不知道该客户要办理什么业务，只能通过询问客户需要办理什么业务得知，这样造成客户感知非

8、常不好，并且使得营销部门的营销效果严重打折扣。问题二，营销中心通过号码10086外呼向目标客户进行营销推广，或是因欠费提醒电话。但因客户没有接到电话而未完成，客户回来看到手机上有10086电话来电显示，并回拨电话查询来电原因(用户回拨10086直接连接到移动客服)，客服接到电话后，不知道客户来电原因(客服方面不知道营销中心外呼需要向客户推销什么)，而无法给客户一个满意的答复，造成客户对客服产生负面印象，也使得营销效果大打折扣。在营销、终端资源预约等方面也存在类似情况。这就要求建设渠道协同系统来完善这些问题。13本文的主要工作本文主要对渠道协同系统的设计和实现进行描述，分析了系统开发的背景及业务

9、场景，采用典型的软件设计方法进行系统的设计，主要分需求分析阶段、系统架构设计、详细设计和实现几个步骤，论文对这几个阶段分别进行描述，在各个环节上展示系统的设计和开发过程，对系统的技术难点即协同调度处理过程和重点功能进行了更一步的叙述，更深层次的展现开发研究的过程，并通过实现部分描述系统功能实现情况。具体内容分以下几个部分：1、背景分析，渠道协同系统是中国移动客服系统的组成部分，渠道是中国移动面向客户进行销售和服务的载体，这部分分析了目前各个渠道系统之间没有实现协同工作的现状，由此获取渠道协同的需求；2、需求分析，该部分将功能性需求分为了几个部分进行详细的阐述，并通过UML建模的方式对需求进行分

10、析描述；3、系统设计，对渠道协同系统的软件体系架构和系统功能结构进行设计，以需求分析作为依据，将系统所采用的技术架构和功能架构用UML包图和序列图等进行详细的描述；4、详细设计，设计系统实现的类组织结构，分析系统业务信息以及调用关系，对业务建立实体类，并类和类之间的联系，分析业务请求信息和业务处理过程，进行数据库表设计；5、系统实现，整合各个实现框架，通过xml配置参数，利用工作流引擎实现业务预约的流程，以及环节配置和流程发布的方法和过程。14本文的组织结构第l章绪论，首先描述了系统开发背景和研究现状，其次描述了本文的主要工作。第2章需求分析与获取，首先对业务进行总体描述，其次描述本系统的目标

11、和需要解决的问题，最后对需求分析按照功能需求和非功能需求两个类别进行描述。第3章是系统概要设计，首先阐述了系统的软件架构设计，阐述系统所使用的技术；其次，详细描述了系统功能架构的设计。第4章是系统的详细设计部分，主要描述了类结构设计和数据库的详细设计。第5章主要描述了系统的实现和测试，针对系统实现过程中的主要流程配置和解决的技术问题进行了阐述。第6章总结与展望部分，对本文进行了总结，并对下一步的工作进行了展望。第2章需求分析与获取21总体系统描述移动用户接触的渠道有：客服、营业厅、短信、网厅等。渠道协同系统对用户不可见，系统外部关系图如图：渠道协同与CRM(即营业系统)核心业务逻辑关系：渠道协

12、同向营业系统核心组件转发其他渠道的服务请求协同，营业系统核心业务组件处理服务请求；同时营业系统核心业务逻辑也可以向渠道协同申请其他渠道的协同处理，共同完成客户服务处理逻辑。渠道协同与RBOSS(即账务系统)核心业务逻辑关系：渠道协同向账务系统核心组件转发其他渠道的服务请求协同，账务系统核心业务组件处理服务请求；同时账务系统核心业务逻辑也可以向渠道协同申请其他渠道的协同处理，共同完成客户服务处理逻辑。渠道协同与统一接口平台关系：统一接口平台向渠道协同申请业务协同处理，渠道协同系统负责协同的拆分，转发及跟踪管理。系统框架图如图：系统描述：规则元数据管理：规则元数据是对协同规则参考因素的定义，包括元

13、数据类型定义，取值约束，取值来源等；元数据是协同处理的数据基础。协同规则管理：协同规则管理实现协同处理规则、流程节点、动作、执行路径等相关协同策略信息的管理。在渠道协同管理中使用工作流引擎来实现协同规则的管理。协同调度：协同调度是渠道协同的执行引擎，支持异步和同步处理两种模式。负载均衡管理：渠道协同系统实时收集各电子渠道业务处理量和性能指标(排队量、业务处理量、处理时长)及经验负载情况分析信息进行渠道业务转发，实现跨渠道的业务负载均衡。请求转发：业务请求转发内容包含客户通过渠道提交的业务请求，以及营业系统中的市场营销、销售、客户服务功能域发起的业务请求。转发的方式支持异步、同步两种处理模式。随

14、机服务密码管理：随机服务密码管理功能使渠道协同系统各电子渠道和实体渠道提供的一项基础服务功能，主要是通过快速的短信方式协助其他渠道快速获取随机密码。随机密码功能支持密码生成，密码验证，密码有效期管理等。预约管理：预约管理功能是客户通过电子渠道申请到实体渠道的预约服务。通过与实体营业厅的排队系统的接口，可为客户提供快速业务办理通道。业务协同管理：业务协同管理是指将业务处理流程分解，由渠道协同负责渠道跨渠道接触调度来完成客户服务功能；业务协同管理典型的应用有业务办理短信通知，客户二次确认等。协同内容管理：主要实现服务转发或业务协同时各渠道之间的内容的转换，生成，加工等。接口管理：接口管理完成协同调

15、度逻辑与相关渠道和营业系统核心业务逻辑之间的交互；交互接口要求是同步调用接口。渠道协同总体需求如下：1接收各个渠道的跨渠道业务请求信息；2针对不同的业务请求信息进行转发或处理；3对业务协同流程进行监控；4提供同步的随机密码服务。22系统目标和解决的问题渠道协同系统要实现与渠道基础平台的连接，实现客户接触过程中的连接、监控、异常等管理与控制，并根据客户或业务需要实现跨渠道的业务请求接收、拆分、发送、监控功能。协同调度根据协同逻辑对来自各渠道和营业系统内部的协同请求进行解析、分解成各渠道的协同任务及其执行策略，并根据渠道特性对协同任务进行封装后发给渠道执行。如下图所示：当一个协同任务产生时，渠道协

16、同系统根据业务情况进行协同处理，比如业务预约这个案例，如下图所示，渠道协同系统要达到这样的功能。业务预约场景中，渠道协同作为一个信息记录和转发的中心，有效的将多个渠道在业务办理流程中串接起来，为实现闭环化的服务能力提供了技术可能。另外，渠道协同系统要对协同处理过程进行监控，针对异常情况做出反应，或告知用户或进行相关的处理，并且用户可查询到协同处理状态。渠道协同系统本身要有一定的健壮性，对多变的业务规则的现状有较高的适应性。23系统需求分析软件开发的目标是在预算内按时开发符合客户真正需要的高质量软件。需求分析主要通过建立模型的方式来描述用户的需求，为客户、开发方等不同参与方提供一个交流的渠道。这

17、些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需求的分析与用户需求的获取有着相似的步骤，区别在于分析用户需求时使用模型，以获取用户更明确的需求。分析用户的需求，需要执行下列活动。通过建立图形，描述系统的整体结构。渠道协同功能结构图基本如下：渠道协同系统按功能分可分为业务请求接入管理、规则管理、随机服务密码、协同调度处理、流程发布五个功能模块。231系统功能性需求系统的核心功能大致分为：接入。主要实现将接收到的协同请求以一定的数据格式保存在系统中；请求处理。主要实现将渠道请求分解成各个系统能够独立施工的子任务，并与之交互。然后回写处理结果(如果有需要进行回写的话)；请求回复。根

18、据各个协同渠道的处理结果，向源请求系统发送处理结果。系统总体状态图如下：详细分析系统的需求可以归纳为以下几个方面：1接入管理完成来自其他渠道的协同请求接收，并形成协同请求实例。在渠道协同中，所有交互用到的数据都要满足元数据要求，因此从协同请求接口中接收到的请求数据，都转换为元数据格式，然后保存到业务请求数据表。每个协同请求实例数据都以统一的“数据语言(元数据)进行表达，形成“数据池”。因此在处理过程中各环节都可以从访问数据池中的数据。为了避免错误的请求进入渠道协同平台，在接收请求的时候，还会进行如下逻辑判断：(1)权限认证：为欲接入的渠道配置一定的权限(如认证密码等)。权限以及渠道信息存储在数

19、据库表里，建议认证密码以密文的方式传入。(2)冲突检查：为避免重复的业务请求，渠道协同应该提供冲突检查的功能。将其设置为数据库表里的一个字段，在冲突检查的时候结合数据库表里的相关字段来进行验证。业务流程如下：2协同调度处理协同调度完成协同请求的分解及调度功能。这部分是渠道协同的核心功能，除了协同请求的分解之外，还有分解后的协同任务与各渠道交互的功能。协同调度管理完成两大部分的功能：(1)协同请求分解及协同通过建模的过程将协同请求进行分解，并通过分解后的各个环节来完成各个协同任务的协同功能。(2)协同任务处理在流程中的各个环节，都完成对应的协同任务。在渠道协同中，可以通过自动的方式将协同任务发送

20、到其他渠道进行处理，也支持通过手工的方式完成协同任务处理。对接收到的协同请求处理过程大致如下：在接收到协同请求之后，根据流程模板适用规则，匹配到正确的流程模板，并通过工作流引擎的接口，创建流程实例，并开始进行调度。协同逻辑是在流程模板上实现的，在匹配流程模板的过程就是选择分解规则的过程。每环节的协同任务处理是需要根据各个业务逻辑来实现的，在渠道协同中环节执行功能定义就是配置每个环节处理协同任务所需要执行的功能。另外，协同请求的元数据适配也是在协同调度过程中完成的。在每个环节的协同任务开始处理之前，由系统根据数据提取组件来获取该环节配置的元数据，并维护到协同请求的数据池中。业务流程如下：对于渠道

21、协同平台来说，预约服务管理也是一种特殊的渠道协同服务请求管理，渠道协同平台只是按照需要将这样的请求转发给相应的渠道平台即可。下面将通过预约服务作为特例讲述一下协同调度处理的过程：预约是指客户通过各个渠道申请预定服务或资源等，并由电信运营商在预约保留期内提供此项服务的过程。预约服务涉及多个渠道，工作人员的协同工作；预约服务管理在渠道协同的处理模式上属于异步处理模式。在预约服务管理流程中，针对预约任务的执行，工作流引擎负责预约业务流程的执行控制。流程描述如下：(1)渠道协同系统接收预约请求，根据预约请求的处理规则，生成预约处理任务单。(2)协同调度进行执行任务类，调用规则配置接口，启动预约执行流程

22、，工作流引擎开始执行业务流程。(3)工作流引擎向资源配置模块发送资源配置请求，等待资源分配。(4)资源配置模块完成分配后，调用渠道协同预约资源确认接口，触发流程继续执行。(5)工作流引擎触发生成预约编号，并发送预约办理短信。(6)客户根据预约短信到营业前台进行业务办理，输入预约编号，查询预约信息后进行相关业务办理。业务办理成功后调用渠道协同预约成功接口，触发渠道协同预约流程继续执行。(7)回写预约任务单执行状态。业务流程：3随机密码管理随机密码服务是一种同步的协同业务请求，按照上述业务流程处理接口。随机服务密码管理功能是渠道协同系统提供的基础功能，系统功能包括服务密码的生成管理，随机服务密码的

23、有效期管理，服务密码的验证管理等功能。平台接收到随机服务密码生成请求后，生成一条记录到数据库表，其有效时长通过系统参数配置。随机密码生成后需要通过短信网关将短信发送给密码发送给用户。随机密码验证步骤如下：(1)接收到随机密码验证请求：(2)根据输入参数获取系统中的随机密码；(3)判断随机密码是否过期，若过期，转5；(4)验证密码是否正确；(5)向短信网关发送密码验证结果。业务流程：4管理规则（1）环节参数配置流程模板发布之后，通过触发渠道协同系统流程发布回调接口，保存流程模板信息和模板相关的环节信息。通过配置信息，可以通过模板名找到与之对应的环节，通过可视化的配置，对每一环节进行规则配置(即配

24、置每个环节的调用接口和对应参数)(2)元数据管理元数据管理主要是针对渠道协同中涉及到的参数进行管理，此功能目的主要是维护系统中参数一致性，保证各个渠道在协同工作时的参数一致。(3)协同决策规则管理协同决策规则主要是对接入进来的业务请求适配相应的流程模板。要制定出匹配规则即协同决策规则，以业务请求的相关字段匹配不同的流程模板，也即配置渠道和业务请求对应的模板。主要功能有：渠道协同决策规则的配置(增加，修改，删除)、渠道协同决策规则的查询。5流程发布渠道协同系统提供图形化的发布流程方法，这样使得开发和维护变得简单，非开发人员也可以制定业务流程，通过流程发布工具发布业务流程并进行参数配置，使整个系统

25、更加灵活，发布流程的过程如下图：使用渠道协同来实现协同业务将变得更为简单。大概需要实现下面的几项工作即可：(1)制定协同请求处理流程使用jbpm提供的建模工具，根据协同业务要求，制定协同请求处理流程。因为这是图形化的工具，所以使用起来非常简单。(2)开发各环节与渠道交互的组件编写各环节协同任务处理组件，即环节与各渠道交互接口组件，在该组件中完成本环节的协同任务处理。(3)定制协同请求规则数据包括配置各环节使用的元数据、各环节执行的组件、流程模板的适用规则上述3个步骤，只有第2个步骤是需要开发的，其他步骤都可以通过配置完成。232系统非功能性需求非功能性需求分为几个方面：1性能方面。响应时间。分

26、日常交互类、日常查询类、批量处理分别考虑。日常交互指传统的大量交互业务，以及一次完成多笔业务处理的交易，日常交互类业务具有较高的响应要求。查询类业务如查询业务处理状态、查询业务规则信息等。查询业务由于受到查询的复杂程度、查询的数据量大小等因素的影响，需要根据具体情况而定，给出一个参考范围。批处理业务如批处理业务转发等业务处理，该类业务处理复杂、操作数据量大、处理时间长。响应时间指标包括：平均响应时间参考值(秒)、峰值响应时间参考值(秒)。吞吐量。系统交易量的估算。指标有年交易笔数(笔年)、高峰期交易笔数(笔天)。数据存储量。每年的数据存储容量及未来几年该数量的预期(增长)值。指标包括累计存储容

27、量、年增长。2系统可靠性：渠道协同系统应该满足724小时都可以使用，客户在任意时间发出的协同请求都能够及时处理；3可扩展性：可实现负载均衡；日后若信息量较大，则系统可相应增加服务器实现扩展。并且针对一些业务上的扩展，系统要有很强的适应性，或者能通过低成本的改造达到要求。第3章系统设计31系统技术架构客服系统是采用MVC(ModelView-Controller)模式。MVC的主要思想是把应用程序划分为三部分，其中M代表模型Model，V代表视图View，C代表控制器Controller。分层的目的是增加代码的重用率，减少数据表达，数据描述和应用操作的耦合度，同时也使得软件可维护性、可修复性、可

28、扩展性、灵活性以及封装性大大提高。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。“MVC设计模式由三部分组成。1模型(Model)：封装数据和所有基于对这些数据的操作，也就是业务流程状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC的核心。2视图(View)：封装对数据的显示，即用户界面。MVC设计模式对于视图的处理仅限于视图上数据的采集和处

29、理，以及用户的请求，而不包括在视图上的业务流的处理。业务流程的处理交予模型(Model)处理。3控制器(Controller)：封装外界作用于模型的操作和对数据流向的控制等。划分控制层的作用也很明显，它清楚地告诉你它选择什么样的模型，选择什么样的视图，以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接控制层接收请求后，并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知视图导致显示的更新。这实际上是一种模型的变化一种传播机制。渠道协同系统是客服系统的一部分，主要是向外提供相应的渠道协同的服务(

30、即主要实现模型部分)，所以它的视图和控制放在各个渠道系统去实现，比如在营业前台的处理界面上嵌入渠道协同请求信息录入界面，工作人员录入信息后，调用渠道协同系统的相应的服务，启动渠道协同的业务流程。该业务流程完成后，返回给各个渠道系统相关信息。本文将不再叙述在各个渠道系统嵌入的渠道协同的界面以及控制模块的设计与实现。渠道协同系统采用Spring框架、Webservice组件和Hibernate框架整合的框架模型，另外又整合进去规则引擎和工作流引擎，以达到业务需求。Spring框架的功能可以用在任何J2EE服务器中，大多数功能也适用于不受管理的环境。Spring的核心要点是：支持不绑定到特定J2EE

31、服务的可重用业务和数据访问对象。毫无疑问，这样的对象可以在不同J2EE环境(Web或EJB)、独立应用程序、测试环境之间重用。简单来说，Spring是一个轻量级的控制反转(IOC)和面向切面(AOP)的容器框架，它的目标是为J2EE应用提供了全方位的整合框架，在Spring框架下实现多个子框架的组合，这些子框架之间可以彼此独立，也可以使用其它的框架方案加以代替，Spring希望为企业应用提供一站式的解决方案。Hibernate是采用ORM模式实现数据持久层的一个优秀的Java组件，它提供强大、高效的将Java对象进行持久化操作的服务。利用Hibemate，开发人员可方便地按照Java对象的结构

32、进行持久化层的开发，并可以使用Hibernate所提供HQL(Hibernate Query Langage，Hibernate查询语言)完成Java对象和关系型数库之间的转换和操作。WebService是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得WebService能与其他兼容的组件进行互操作。它可以使用标准的互联网协议，像超文本传输协议HTTP和XML，将功能体现在互联网和企业内部网上。WebService平台是一套标准，它定义了应用程序如何在Web上实现互操作性。从表面上看，WebService就是一个应用程序，它向外界暴露出一个能够通过Web进行

33、调用的API。这就是说，我们能够用编程的方法通过Web调用来实现某个功能的应用程序。工作流引擎是指workflow作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。如果开发一个系统最关键的部分不是系统的界面，也不是和数据库之间的信息交换，而是如何根据业务逻辑开发出符合实际需要的程序逻辑并确保其稳定性、易维护性(模块化和结构化)和弹性(容易根据实际业务逻辑的变化作出程序上的变动，例如决策权的改变、组织结构的变动和由于业务方向的变化产生的全新业务逻辑等等)。Workflow引擎解决的就是这个问题：如果应用程序缺乏强大的逻辑层

34、，势必变得容易出错(信息的路由错误、死循环等等)。本系统中就是这样的问题，复杂的部分是业务流程的转向和业务的分发，而非数据库的操作等，本系统使用工作流引擎解决复杂的业务流程的问题。规则引擎是一种嵌套在应用程序中的组件，它实现了将业务规则从应用程序。代码中分离出来。规则引擎使用特定的语法编写业务规则，规则引擎可以接受数据输入、解释业务规则、并根据业务规则做出相应的决策。引入规则引擎后带来的好处：实现业务逻辑与业务规则的分离，实现业务规则的集中管理；可以动态修改业务规则，从而快速响应需求变更；使业务分析人员也可以参与编辑、维护系统的业务规则；使用规则引擎提供的规则编辑工具，使复杂的业务规则实现变得

35、的简单。渠道协同系统正是这样一类系统：它面临的业务规则多变。如果每次都要改动业务逻辑模块的大量代码，又费时又费力，维护成本大量增加。使用规则引擎来解决，这个问题的解决过程将大量简化，并且高效准确的发布和执行业务流程。本系统使用的是Drools40规则引擎，Drools是Jboss公司旗下一款开源的规则引擎，它完整的实现了Rete算法；提供了强大的Eclipse Plugin开发支持；通过使用其中的DSL(Domain Specific Language)，可以实现用自然语言方式来描述业务规则，使得业务分析人员也可以看懂业务规则代码。该系统的总体架构图如下：接口层包括OBD接口、WEBSERVI

36、CE、SOCKET，这些是外部渠道调用渠道协同服务的入口，通过这些方式调用渠道协同服务或者进行外部渠道和渠道协同系统之间的交互。系统业务层，为系统提供业务逻辑操作、业务规则校验并返回处理结果和业务处理接口。业务层主要由业务服务对象及其相关功能包，业务规则处理组件以及相关服务功能包组成。业务层使用规则引擎技术，将业务规则处理分离，并可以根据业务要求灵活修改业务规则的处理而不修改业务代码，增强了系统的健壮性以及可维护性，适应了渠道协同系统业务多变的特性。持久层主要负责与数据访问层的交互，执行数据操作并返回处理结果。数据访问层主要由数据对象映射包、数据操作包、Hibernate服务组件组成。Hibe

37、rnate屏蔽了各商业数据库建立数据连接的复杂的处理过程，增强了系统的可移植性。32系统功能架构通过对系统技术架构和需求分析的讨论，可以明确系统的功能架构如下图：如图所示：渠道协同系统包括了五个功能模块：业务请求接入管理、规则管理、随机密码服务、协同调度处理、流程发布。接入管理这个功能模块的职责是接收业务请求信息，对请求信息进行一系列的验证和检测后，把数据格式化，存入数据库。如下面序列图所示：随机密码服务功能模块主要向外部渠道提供生成随机密码和密码验证的功能。外部渠道通过渠道协同系统提供的WebService接口调用随机密码服务。下面是这两部分服务的时序图：规则管理功能模块针对系统中协同决策规

38、则的配置、流程文件的配置要求、各个流程环节参数的配置等等。流程模板发布之后，通过触发渠道协同系统流程发布回调接口，保存流程模板信息和模板相关的环节信息。环节配置是在GUI界面上配置完成的，可以通过模板名找到与之对应的环节，通过可视化的配置，对每一环节进行规则配置(即配置每个环节的调用类和对应参数)配置步骤：1、打开配置界面，界面自动调用组件显示出所有模板信息。选择需要配置的模板可以显示出该模板下所有的环节。2、对环节逐个进行配置，得到配置界面，配置每个环节对应执行的类名或者接口。3、对每个环节用到的参数进行配置，包括出参和入参。协同调度处理功能模块又包括调度进程、任务回调、环节回调和请求回复处

39、理。协同调度采用异步的处理方式，有专门的调度进程定时的轮询数据库中的业务请求表，如果有未处理的业务请求，则启动协同调度流程进行处理。每个环节都对应一个业务处理逻辑，即对应规则库中的一个处理类。在环节回调时如何找到对应的处理类，这里就需要用到环节和规则对应关系。在渠道协同系统中，流程环节回调需传回一定参数，其中有环节名，故可以根据环节名在环节与规则对应关系表中找到相应的规则。然后调用规则引擎对规则进行处理。外部渠道在提交业务请求之后，有些希望得到请求结果，至于结果回复采用什么方式，主要是根据业务请求是同步还是异步请求，如果是同步请求，则在接入请求的接口中提供了需要回复的内容，请求完成后，需要回复

40、的内容返回给接口，接口提供给外部渠道回复结果；如果是异步请求，则需要渠道协同系统提供结果回复接口定义文件，交由外部请求渠道实现，这样在请求处理完成后，通过引擎回调接口来调度外部提供的接口来做回复请求(至于调用外部接口的方式可以采用规则引擎。此系统可扩展，通过发布流程模板和配置环节相关参数，可实现需要的业务实例。流程模板发布工具在发布流程模板时，工作流引擎会回到流程发布接口，流程发布接口调用对应的回调接口，进而保存流程模板相关信息(流程模板信息、环节信息。渠道协同系统提供自己的流程发布接口让系统在流程发布时触发，进入调用系统提供的模板与环节信息查询接口得出流程和环节的对应关系，并且保存在流程模板

41、与对应环节信息表中。第4章系统详细设计详细设计的目标是为系统结构设计确定的各个具体任务选择适当的技术手段和处理方法，为系统的实现奠定良好的基础。本章将从系统建模、数据库设计等方面详细描述系统的设计，系统建模通过静态建模方式清晰描述了工程项目的业务的组织；数据库设计部分，对系统建立数据库概念模型和具体的数据表设计。41系统建模本文采用静态建模方式描述渠道协同系统的对象结构，并描述了各个对象间的逻辑关系。为了表现系统的设计层次，本文采用包图来描述设计的相关元素如何按组结合在一起，以及他们之间的关系。 下面是包内容的简要描述：业务请求接入管理包括接入控制和接入管理，接入控制的处理类为：OperHan

42、dler，接入管理的处理类为：ReceiveRequest。随机服务密码管理密码请求和密码验证，密码请求的处理类是ReqRandPWD，密码验证的处理类是CheckPWDService。协同调度管理包括调度进程、环节回调、请求回复处理和任务调度。他们的处理类分别是DispatchProcess、TacheBackcall、ReqReplyHandle、TaskDispatch。渠道协同系统提供流程发布回调接口给规则管理模块，规则管理模块提供模板与环节查询接口给渠道协同系统调用。流程发布回调类为FlowTmpllssueBackCall类，流程发布结束回调类为FlowFinishBackCall

43、类，流程发布可用GUI界面发布或者EXCEL表格发布。流程模板发布之后，通过触发流程发布回调接口，保存流程模板信息和模板相关的环节信息。GUI界面上，可以通过模板名找到与之对应的环节，通过可视化的配置，对每一环节进行规则配置(即配置每个环节的调用类和对应参数)配置步骤：1、打开配置界面，界面自动调用组件显示出所有模板信息。选择需要配置的模板可以显示出该模板下所有的环节。2、对环节逐个进行配置，得到配置界面，配置每个环节对应执行的类名字和配置文件。3、对每个环节用到的参数进行配置，包括出参和入参。涉及的数据信息有：环节执行功能定义信息、环节定义信息和环节元数据配置信息。规则管理还包括协同决策规则

44、管理，协同决策规则主要是对接入进来的业务请求适配相应的流程模板。在这里主要是采用两个维度匹配：渠道标识，业务请求类型；这两个维度唯一确定一个流程模板。故在现场开发制定了流程模板之后，必须制定协同决策规则，也即配置渠道和业务请求对应的模板。规则管理的主要处理类有：环节功能配置类OperTacheIntf、环节参数(元数据)配置类OperTacheParam、模板适配规则配置类OperFlowTmplRule。42数据库设计设计数据库时，我采用powerdesigner工具进行关系数据库的设计，PowerDesigner是Sybase公司的CASE工具集，使用它可以方便地对管理信息系统进行分析设计

45、，它几乎包括了数据库模型设计的全过程。面向对象建模主要解决应用程序的结构问题；概念数据建模主要解决现实世界中信息的表达以及信息之间的关系问题；物理数据建模主要解决现实世界中信息在DBMS中的存储结构问题。实体，也叫实例，对应现实世界中可区别于其他对象的“事件或“物体，它可以是有形的或无形的、具体的或抽象的、有生命的或无生命的。在渠道协同系统中的实体主要包括：业务请求信息、渠道类型信息、渠道权限信息、请求回复信息、密码信息、流程模板信息等。关系是指实体集之间或实体集内部实例之间的连接，实体之间可通过关系来相互关联。按照实体类型中实例之间的数量对应关系，通常可将其分为四类，即一对一、_对多、多对一

46、、和多对多关系。根据渠道协同的数据归总，我们对渠道协同系统所涉及的数据进行分析。渠道协同系统共涉及了四个方面的数据：渠道及业务请求相关信息、环节执行及定义信息、流程模板相关信息、密码相关信息。渠道和业务请求相关信息可以分为：渠道定义信息、渠道协同业务请求权限信息、业务类型定义信息、协同业务请求信息；环节执行及定义信息可以分为：环节执行功能定义信息、环节定义信息；流程模板相关信息可以分为：流程模板适用配置信息、流程环节元数据配置信息、流程模板定义信息；密码相关信息可以分为：随机服务密码信息、密码验证结果信息、密码记录历史信息、随机密码配置信息。根据数据库概念关系模型建模方法，给出渠道协同系统的数

47、据信息模型：第5章系统实现与测试本章分为系统实现和测试两部分。系统实现部分的主要任务是根据系统设计的结果、使用J2EE的技术进行程序设计，将重点讲述系统实现过程中的几个关键问题：流程创建与发布、系统配置文件说明、渠道协同配置界面设计。在本章最后一节将着重介绍系统测试的设计和测试效果。51框架之间的整合本系统采用的架构是Spring、webservice、hibernate、jbpm、drools的整合架构。在整合的时候采用webservice、hibernate、drools、jbpm往Spring整合的方式，在工程中加入各个框架的功能jar包后，若要实现整合webservice组件，需在we

48、bxml里添加一下代码段：52流程创建与发布用jbpm工具来画流程图，下面以一个测试的案例来说明建模时的要求。环节代码统一为ngcrm_chncprmgnt，名称根据业务自行定义。流程引擎的变量模块固定的变量。在每个流程的第一个环节，都要求固定设置2个全局的变量：GLOBAL：REQ ID(模块内部使用的变量)，RESULT FLAG(渠道协同将业务模块回单结果保存到该变量中，作为流程决策的条件值)；其他变量。在不同业务流程中，需要使用到不同变量去控制流程的转向，这些变量可以根据具体业务来设置。在各业务中，可以根据业务执行情况，将这些变量的值放在接口返回参数中，渠道协同将这些值更新到引擎的变量

49、中。建模时，通过脚本环节中使用这些变量来进行流程调试的决策因素。2流程模板的发布流程发布后，通过渠道协同将模板名称和节点名称自动保存到模板表及环节定义表中，写这2张配置表的规则：(1)模板表模板名称写入到模板表的：模板ID字段(DEFINITION ID)；(2)环节定义表节点名称写入到环节定义表的：环节名称字段(TACHE NAME)；模板定义表和环节定义表的其他字段信息通过界面来进行配置。3异常回滚管理渠道协同管理的回滚，需要将回滚分支定义在流程模板上。以下图所示：当发起取消操作时，流程将进行回滚操作，这时将进入回滚分支，即图中“取消预约”“释放号码”专“终端预订取消54渠道协同配置界面设

50、计渠道协同的配置包括流程、环节、及渠道业务请求相关配置，为了方便配置，将所有配置放在同一个窗口中操作，达到高效、直观、系统的配置效果。各个配置信息在不同的TAB页中进行。组件配置界面55系统测试随着软件应用领域越来越广泛，其质量的优劣也日益受到人们的重视。质量保证能力的强弱直接影响着软件业的发展与生存。软件测试是一个成熟软件企业的重要组成部分，它是软件生命周期中一项非常重要且非常复杂的工作，对软件可靠性保证具有极其重要的意义。在软件的测试过程中，应该应用各种测试方法，以保证产品有一个较高、较稳定的质量。根据不同的生产过程进行不同的测试，包括黑盒测试、白盒测试、功能测试、压力测试、安装卸载测试、

51、兼容性测试、a测试、13测试等。1基本测试渠道协同系统采用黑盒法和白盒法分别进行测试，黑盒法主要针对系统功能测试，白盒主要针对系统逻辑结构进行测试。(1)黑盒测试方法及结果：黑盒测试是不考虑系统内部结构，主要观察系统的输入、输出关系。本系统主要是向各模块分别大量的输入各种信息，包括输入正常信息、输入非法信息、输入类型匹配的信息以及输入类型不匹配的信息等，观察系统响应，并针对系统响应做出适当的修改。经测试本系统在接收各个渠道系统的协同请求时，对不符合标准的数据给予警告，在监控界面可看到协同请求进行的阶段情况，在每个阶段出现非法的情况都会返回警告信息，告知工作人员出错原因和出错结果。通过配置界面配

52、置元数据，组件，流程模板，环节信息，渠道信息后，可在相关的数据库表中找到配置的数据，可知配置过程正常无误。按照格式发给渠道协同系统一个协同任务(预约3G终端)，通过渠道协同请求监控界面检查协同请求信息如下表：可知一个协同任务处理完成。然后对随机密码服务的测试，发送一个密码请求，然后系统返回了6位的随机码，再发送验证消息，系统返回验证结果正确。(2)白盒测试方法及结果：白盒测试主要是考虑系统内部逻辑结构，对系统的逻辑进行测试，主要目的在于保证程序需求的实现。本系统的白盒测试主要由作者在熟悉软件代码的基础上，分别人工检测系统的每条链路，通过使用大量涵盖每条链路需求的用例，对系统进行全面测试。本文利用白盒测试工具TrueCoverage对系统进行了白盒测试，查出一些不符合业务逻辑的规则，经过仔细修改