保险收付费系统技术方案

保险收付费系统技术方案
1．项目背景
保险有限公司是中国第一家全国性股份制财产保险公司，1996年8月29日在北京正式开业，公司注册资本金 13.33 亿元人民币，50家股东多为实力强、规模大、效益好的大型企业和企业集团，覆盖石油、电力、冶金、化工、航运等24个行业。

公司在全国38个城市设有分支机构，已经形成面向全国的经营布局。

2002年5月，世界著名保险集团─—美国ACE集团参股，为带来了先进的经营理念和全球性业务支持网络。

2006年，公司保险业务持续稳定增长，投资业务创下历史新高，成为国内唯一一家自成立以来连续十年实现盈利和分红的保险公司。

随着财险业务的不断扩大，电子支付清算体系得到越来越多的重视。

银行外部清算渠道的不断丰富、直联不落地的电子支付处理方式成为支付领域新的特点。

同时，支付工具和支付手段不断创新，如银行卡支付、网上支付、手机支付、电子票据等新支付手段日益被民众所接受，所占业务比重不断加大。

面对这样一个快速变化的形势，保险现有核心系统、柜面系统、大前置系统和网银系统的升级改造变得越来越复杂和困难。

改造的风险、工作量、对现有业务平稳运行的影响、新上支付渠道和原有系统的整合等等，都是保险公司需要妥善解决的问题。

公司多年来在支付清算领域承接数十个本、外币支付清算项目，与各家银行的资深业务专家、技术专家不断研究和探讨支付业务的规律性和解决途径。

统一支付清算平台就是归纳总结以往经验，力图妥善解决上述难题的答卷。

2基本设计理念
基于办公自动化技术和自动控制技术的计算机网络系统。

由计算机，通过网络管理卡连接的窗口消费机，运行于计算机的配套管理软件。

可配置一台标准并行口打印机，用于打印各种记录和报表。

使用双机热备份，磁盘阵列的RAID技术等多项系统备份和恢复手段以求达到系统主要部分无单点故障可能；严格的口令管理，完善的多用户系统平台，和完备的加密手段提高系统的安全性；提供良好的接口，方便和HLR、客服中心、省中心、合作公司、金融网、Internet
及视聆通等系统互联；考虑对现有投资的保护，可以最大限度的利用现有资源；通过性能监控、故障发现和告警、远程维护、日志记录等多种手段和友好的用户界面最大程度地强化系统管理和简化用户操作。

3开发工具与运行环境
●硬件环境： IBM / HP / Sun / PC Server
●网络环境：系统的网络架构遵循银行的网络规范，充分利用现有的网络资源、硬
件设备及软件产品等，无需额外的网络建设。

●主机与操作系统：
系统采用通用的开放平台，以支持以下操作系统：IBM小型机：RS6000 例如：P550,P650,P670等系列根据业务量选择。

操作系统：AIX 5.3 或AIX6.1
●数据库：系统的数据库可以采用目前流行的数据库，如：IBM DB2 9.0或以上
●Web应用服务： IBM WebSphere 6.1，Weblogic
●中间件：中间件建议MQ6.0 或以上
●开发语言： Java 、C
●双机热备：基于系统冗余性的设计原则，避免系统维护及单机故障时导致业务
停顿。

双机热备与支付平台无关，主要从系统及硬件角度考虑，主流的包括HP的
双机热备方案与IBM HACMP。

4技术架构
系统的整体架构采用MVC的架构设计
M代表模型Model, V代表视图 View， C代表控制器Controller。

MVC的目的是增加代码的重用率，减少数据表达，适当调节数据描述和应用操作的耦合度。

同时也使得软件可维护性，可修复性，可扩展性，灵活性以及封装性大大提高。

MVC设计模式由三部分组成。

模型是应用对象，没有用户界面。

视图表示它在屏幕上的显示，代表流向用户的数据。

控制器定义用户界面对用户输入的响应方式，负责把用户的动作转成针对Model的操作。

Model 通过更新View的数据来反映数据的变化。

对于一个复杂系统通过把数据模式从各种可以被存取和控制的数据中分离出来可以改善分布式系统的设计。

5．功能描述
做为提供支付清算公共服务的关键系统，统一支付清算平台集中处理全行的支付清算业务。

统一支付清算平台是后台作业系统，它与行内各个系统协作分工，完成整个支付清算业务流程。

前台产品系统（如柜面业务系统、汇兑系统、网银、国际结算系统、资金交易系统等）完成往账的发起和来账的最终处理。

核心账务系统完成所有的账务处理。

支付清算系统对往来账进行清分，并向核心系统提供账务处理的依据。

技术要求：
1、对数据交换的要求：
采用实体-关系模型描述系统的数据逻辑关系，采用关系模型数据库来实现系统的数据逻辑关系。

利用Powerdesigner工具描述帐务系统中的数据逻辑关系，形成数据逻辑模型(E-R关系)。

在数据逻辑模型完成数据的组织定义和说明，Powerdesigner工具根据其生成详细的设计文档。

在数据逻辑模型的基础上Powerdesigner工具根据其自动生成物理数据模型，形成关系数据库的数据库定义语言，即形成关系数据库的数据库、表、视图、存储过程、
主外键关系等的定义及相关说明。

在此基础上进行数据库的补充设计、完成数据库的最终设计，即完成系统的数据库的物理设计。

2、对数据共享的要求：
收付费系统平台通过内联网关（也称交换平台、数据总线）实现与保险公司内众多业务应用系统的数据交互。

收付费系统平台通过报文网关实现与外部清算系统(渠道)进行数据交互。

收付费系统平台采取直联方式与行内、外部系统无缝连接，实现业务直通处理。

3、对资源管理的要求：
随着代理业务的不断深入，信息资源的开发、利用、共享，将自然成为代理管理系统建设过程中最重要的指标之一，而信息资源系统的建设与管理是利用共享的前提。

可以及时了解企业的动态，以及统计某个时间段的费用。

方便快捷的开通、关闭企业的使用权限，随时调整企业的使用年限。

打印功能使得数据更直观更真实反映出来。

4、对应用整合的需要
从技术上，整合需要跨越不同硬件平台、不同的网络环境、不同的数据库系统，实现不同应用系统的数据交换、信息共享、业务协同。

5.1通过金融系统托销帐
提供与金融系统的数据接口，金融系统能取得已开办金融系统托收业务的用户的话费，在金融系统中进行对用户金融帐户进行扣款交费操作，返回结果给帐务管理系统，帐务管理系统对用户进行销帐处理。

移动帐务系统对通过金融系统托收销帐提供两种支持方式。

异步托收销帐：所谓的异步是指金融系统对用户金融帐户进行扣款交费、帐务管理系统对用户进行销帐两个事件可以以非实时的方式进行。

同步托收销帐：所谓的同步是指金融系统对用户金融帐户进行扣款交费、帐务管理系统对用户进行销帐两个事件需要以实时的方式进行。

5.2通过金融系统代收销帐
提供与金融系统的数据接口，金融系统能查询取得用户的话费，用户进行现金交费，金融系统将交费结果返回给帐务管理系统，帐务管理系统对用户进行销帐处理。

移动帐务系统对通过金融系统代收销帐只提供实时同步的处理方式，具体的处理流程是金融系统发起一个代收用户费用查询（消息类型为0012）到帐务系统的查询队列，请
求取得指定托收用户费用情况（在查询失败情况下不能进行代收交费，只能再次尝试查询）；
金融系统根据查询结果进行现金交费处理，并将一个相应的代收销帐请求（消息类型为0002，包含现金交费信息）发送到帐务系统的销帐队列中（超过预设时间仍没收到相应的回应消息认为此次交易失败）；
帐务系统收到托收销帐请求后对该用户进行销帐操作，根据销帐结果给金融系统发送回应消息（消息类型为8002）。

金融系统收到回应消息，根据销帐结果进行处理。

5.3通过金融系统办理托收关系
提供与金融系统的数据接口，金融系统能查询得知指定用户是否能办理新的托收关系（欠费或旧的托收关系没解除时不能办理），金融系统接收用户填写资料进行相应的办理手续，将结果返回给帐务管理系统，帐务管理系统保存更新用户的新托收关系信息。

移动帐务系统对通过金融系统办理托收关系只提供实时同步的处理方式，具体的处理流程如下
金融系统发起一个办托用户情况查询（消息类型为0013）到帐务系统的查询队列，请求取得指定用户的情况（在查询失败情况下不能进行新托收关系的办理，只能再次尝试查询）；
金融系统根据查询结果决定能否给用户办理新的托收关系，能办理则在进行相应手续后，将一个办理托收关系请求（消息类型为0003，包含新托收关系信息）发送到帐务系统的交易队列中（超过预设时间仍没收到相应的回应消息认为此次交易失败）；
帐务系统收到办理托收关系请求后更新用户的新托收关系信息，根据托收信息更新结果给金融系统发送回应消息（消息类型为8003）。

金融系统收到回应消息，根据托收信息更新结果进行处理。

5.4通过金融系统返销帐
提供与金融系统的数据接口，金融系统在销账时保存交易流水号，返销帐时根据流水号来确定是否是该笔交易需要返销帐。

金融系统将交易流水号返回给帐务管理系统，帐务管理系统对该笔交易进行返销帐处理。

移动帐务系统对通过金融系统返销帐只提供实时同步的处理方式，具体的处理流程是金融系统根据销账结果查询得到原交易流水号，然后将一个相应的返销帐请求（消息类
型为0004）发送到帐务系统的销帐队列中（超过预设时间仍没收到相应的回应消息认为此次交易失败）；
帐务系统收到返销帐请求后对该用户进行返销帐操作，根据返销帐结果给金融系统发送回应消息（消息类型为8004）。

金融系统收到回应消息，根据返销帐结果进行处理。

5.5销帐帐目核对功能
提供与金融系统的数据接口，查帐发起方能查询得知被查方在指定时间段内托收/代收交易的情况(成功、失败的笔数，成功交易的总金额)，查帐发起方收到查询结果后，将结果与己方中的日志记录进行比较核对，根据比较核对的结果决定是否进行详细交易清单查询；进行详细交易清单查询时，查帐发起方同样发送一个查询，回应方通过索引消息返回查询交易清单文件。

帐目核对只提供实时同步的处理方式，具体的处理流程如下
查帐发起系统发送一个办托用户情况查询（消息类型为0014，查询方式为00）到目标系统的查询队列，然后等待回应消息以取得指定时间段内发生交易的统计情况，如果超时，本次查询失败；
目标系统收到查询消息后，按条件根据己方日志中内容作出统计结果,将结果返回给查询发起系统（消息类型为8014）；
查帐发起系统将查询结果与己方系统中日志内容进行比较核对，如果核对结果正确，一般不需要再做进一步详细清单查询，否则进行下一步；
查帐发起系统发送一个办托用户情况查询（消息类型为0014，查询方式为01）到目标系统的查询队列，请求取得指定时间段内发生交易的详细情况，同时指定返回生成的交易清单文件路径名，然后等待相应的索引消息，如果超时，认为本次查询失败；
目标系统收到查询消息后，按条件根据己方日志中内容生成交易清单文件,并发送一个索引消息给查询发起系统，触发交易清单文件传送；
查帐发起系统收到回应消息（一个索引消息）后，打开生成的交易清单文件，与己方交易日志中内容进行核对。

6．异常设计与后期维护设计
异常是利用java异常处理机制，捕获/处理所有异常，并在程序中进行处理成用户可理解形式表现。

利用事件日志跟踪应用程序的出错信息。

维护方面各子系统使用配置文件存储有关数据库的连接信息等应用程序配置信息。

可进行灵活的维护修改。

数据库备份与维护采用厂家自带的工具。