CBPSSE应用系统构建方案与设计要求解读.docx

CBPSSE应用系统构建方案与设计要求解读.docx

《CBPSSE应用系统构建方案与设计要求解读.docx》由会员分享，可在线阅读，更多相关《CBPSSE应用系统构建方案与设计要求解读.docx（30页珍藏版）》请在冰豆网上搜索。

CBPSSE应用系统构建方案与设计要求解读

1.范围

1.1标识

项目名称：

中国人寿核心业务处理系统（超强版）（暂定名）开发

项目代号：

CBPS-SE

文档名称：

CBPS-SE应用系统构建方案与设计要求

文档配置管理标识：

COPIA_SW_2003_00_0001

1.2项目概述

受中国人寿总公司委托，北京科比亚公司承担中国人寿核心业务处理系统的设计与开发。

该系统的主要用户为省级集中的业务处理中心，系统要满足业务处理集中后的业务处理要求及业务处理模式，系统要具有与其它处理系统的数据接口能力。

系统在TUXEDO作为处理中间件的基础上构建，以满足集中后数据量及并发用户数规模。

1.3文档概述

本文档的目的是确定技术的选择，确定业务逻辑的分配，确定主要的设计约束，确定进一步设计的规格要求。

进一步的系统设计及业务规格的设计应在本文档规定的条件下进行。

1.4预期读者

项目负责人、SERVICES设计人员、界面设计人员、系统管理员、数据库设计与管理叫、方案评审组人员。

2.引用文件

3.定义

3.1术语

用户控制块

是应用系统的内存存储区域，用以存放CBPS-SE的用户注册信息

活跃产品定义块

是应用系统的内存存储区域，用以存放目前仍在销售的险种的基本约束要求

业务代码字典

是业务中使用的各项代码，代码字典是企业标准化要求的一部分

业务代码字典块

是应用系统的内存存储区域，用以存放各项业务代码字典的数据

3.2缩略语

CBPS-SE

CoreBusinessProcessingSystem–SuperExcellence

UCB

UserControlBlock

APDB

ActiveProductsDefineBlock

BCDB

BusinessCodeDictionaryBlock

4.项目概述

CBPS-SE包括寿险的各项业务处理功能，支持业务要求的处理模式，提供数据接口标准使其它处理系统可以与核心业务系统进行数据交换或作为核心系统的客户端访问CBPS-DN

CBPS-SE用TUXEDO/T作为中间件保证系统的高可用性、可扩展性及好的系统响应能力。

CBPS-SE用TUXEDO/Q作为消息中间件来满足不同服务器间可靠的数据传输。

CBPS-SE用数据路由技术解决超大数据的存储与管理。

CBPS-SE用科比亚的任务管理平台来满足业务中的工作流管理要求。

CBPS-SE具备支持超大并发用户及超大数据访问的能力。

5.CBPS-SE目标分析

5.1中国人寿背景

中国人寿保险公司是国务院直属企业，是目前中国最大的专业寿险公司，2002年的营业收入1287.19亿元，客户1.5亿人，占国内寿险市场近60%的份额。

中国人寿在全国拥有分支机构3400个，正式员工5.2万人，设立代办机构8万多个，聘请专兼职代理人65万人。

中国人寿保险公司的核心业务系统建设经过6年多的努力，取得了很大的成绩：

●总颁条款的业务管理按总公司的实务管理办法，已经全部实现上机处理，并且正在向省级集中；

●短意险的业务处理系统也已经开发完毕并正在全国推广使用；

●老业务的处理系统正在测试中，将于2003年4月投入运行。

5.1.1组织机构

中国人寿的组织结构是按行政区划设置的集团公司。

总公司为一级法人，主要负责公司各项规范的指定及执行情况的检查，除一些特大型的团体业务外，总公司并不具体负责产品销售。

对于超过规定的大额件承保或理赔，总公司负责案子的核查及处理。

5.1.2业务现状及特点

目前中国人寿已经开办的业务或即将开办的业务有：

●按产品类别分：

普通寿险、两全险、意外险、健康险、养老年金

●按业务性质分：

团体业务、个人营销业务、代理业务

●按缴费性质分：

普通、投联、万能、基金、储金

●按盈余分配性质分：

红利、利差返还

CBPS及CBPS-O已经能够处理上述的各类产品。

目前的CBPS在支持的业务模式上主要是“申请-审核-生效”的模式。

5.1.3业务量

由于中国人寿是全国性的公司，各分公司之间东西差异比较大，以中等规模的省作为依据，目前全省的并发用户数约为1,000-1,200，数据量约为30G（不包括影像数据）。

分地区的每天新单数、保全的业务数、理赔业务数、收付费交易笔数等的各项统计中国人寿信息技术部正在统计。

5.1.4电子化现状

硬件

IBM-AIX，HP-UX，PC-SERVER等基于UNIX的小型机或服务器

软件

OS：

UNIX

DBPS：

INFOMIX

业务处理系统：

CBPS

财务处理系统：

CLAF

营销员管理系统：

AMIS

5.2业务目标

●业务处理逐步集中

●引入原始单证影像件管理后的工作流管理

●客户服务的一柜制业务模式

5.3技术目标

●先进性：

基于TUXEDO中间件的三层C/S模式是目前开发大型关键业务处理系统最为先进技术，同时也是成熟的技术。

这项技术在支持超大并发用户，超大数据规模时是必不可少的

●灵活性：

由于业务逻辑与表示逻辑的分离，使得调整业务逻辑或增加业务逻辑时不会引起界面的调整；反之如果用户要求设计新的界面风格，而基本的业务逻辑不变时，不必修改服务逻辑。

这对业务要求可能不断发生改进的企业来说是十分必要的

●安全可靠性：

系统除注册用户安全性检查外，增加了注册位置、注册时间的安全性检查，并且增加了安全性审计功能。

在应用设计时增加了安全服务处理层来解决安全性检查，在必要时可加入数据传输加密及关键数据存储加密的服务

●易操作性：

前端界面全面以WINDOWS风险提供，操作上既提供鼠标操作又提供操作的操作方式。

配合业务部门一柜制的管理要求，专门设计柜面业务处理子系统，使得窗口服务更为方便

●开放性：

系统设计中采用的技术都是基于标准的，并且都是运行在开放平台上。

坚持开放性也就是坚持系统的可扩展性。

在我们的应用系统中可以通过更换数据访问服务来存取不同的数据库

6.

总体解决方案

6.1系统总体结构

系统架构中主要的的是把表示逻辑、业务逻辑通过事务处理中间件构建成“请求-响应”这样的服务形式。

6.2分布计算环境

CLIENT端只反映表示逻辑，即数据的录入，并把请求发给TUXEDO服务，CLIENT不对输入的数据做任何加工处理。

对于返回的结果，按要求组织数据并显示。

SERVER端为业务逻辑，所有的逻辑以TUXEDOSERVICES组织。

多个SERVICES可组成一个SERVER，多个相同或不同的SERVER可分布在不同的物理的服务器上。

服务的集群架构是应用系统具有高可用性及响应速度快的技术基础。

系统中可配置一个或多个数据库服务器，不同的数据可存放在数据库服务器中，同一数据对象可按一项或多项属性值分布在多个数据库服务器中，并通过数据路由透明访问数据库。

基于消息中间件可构造MSG-HUB，满足不同业务系统间的数据交换。

对于外部接入的服务请求，在系统中设置前置机，并且把前置机的请求程序作为CBPS-SE的一个CLIENT。

6.3应用系统结构

应用系统的业务逻辑是分层设计的，每层都具有一定的独立性，要求任何一层的修改只要不修改调用接口的数据，就不会影响其它层的处理逻辑。

CBPS-SE应用按如下要求分层

6.3.1CLIENT的启动及退出

启动CLIENT时首先要进行登录，登录时要输入“机构号”，“用户名”，“口令”，系统将自动获取用户登录的位置，如果需安全认证的，将读取安全证书号。

登录时首先发出CS_LOGIN请求：

●CS_LOGIN（BRANCHID，USERID，PWD，SUBSYSID，CID，认证码），返回STATUS，UCBID

LOGIN成功后，发CS_CHKVER请求：

●CS_CHKVER（SUBSYSID），返回STATUS，各程序、数据文件的版本列表

CS_CHKVER检查系统本地资源的版本，以清单方式发回，读到后可比对本地的资源版本清单，如果相同的则启动系统，如果不同则显示需重新下载的的资源名称，选择后启动FTP进行文件传输。

本地资源列表可以正文方式存储，但为防止文件内容被修改，另需记录文件的CHKSUM，在比对前若CHKSUM不对，则要求重新下载全部本地资源。

系统退出时要求发CS_LOGOUT：

●CS_LOGOUT（UCBID），返回STATUS

6.3.2客户端程序

对于输入数据可通过定义域的属性对输入的域的格式（日期型，字母数字型、字符型、字母型、数字型等）进行检查

对于显示结果，如果是列表格式，可对显示结果按指定列排序，或按某属性值进行选择，也可调整列的显示位置。

若某显示域为其它域的简单算术运算结果，则可在CLIENT端完成。

CLIENT功能一般不通过编方式，而是通过工具的属性定义完成。

对于服务请求，所有的CLIENT程序一律通过统一的接口函数调用，接口函数把VB的结构的数据转换成CARRAY结构，并发出TPCALL调用。

若数据需传输加密的，则加密逻辑封装在接口函数中。

在接口服务请求时，如果返回TIMEOUT，则要求发CS_RELOGIN请求：

●CS_RELOGIN（BRANCHID，UCBID，USRID，PWD，SUBSYSID，CID，认证码），返回STATUS

6.3.3登录与退出服务

任何一个CLIENT在请求服务前必须建立应用级的会话，这是通过CBPSLOGIN完成的。

登录时，服务将在内存为每个用户建立一个用户控制块（UCB），用以存放有关登录的状态及其它信息。

当用户退出时，系统将UCB内容记入UCB的日志。

UCB日志的结构为：

UCBID

BRANCHID

USRID

LOININGTIME

SUBSYSID

LOGINCID

LASTCALLTIME

LOGINTRYTIMES

LOGOUTTIME

FLAG

UCB是内存中的存储区，当用户LOGIN成功时建立，同一个用户在同一时刻只能登录一次。

UCB内容与UCB日志内容基本相同，但不包括LOGINTRYTIMES、LOGOUTTIME、FLAG。

UCB空间在建立时动态分配，在LOGOUT时释放。

在连续N分钟内没有服务请求时，系统将自动释放空间。

登录完成时，系统同时要把登录信息写入用户登录日志；释放空间时，系统要把UCB信息、LOGINTRYTIMES、LOGOUTTIME及FLAG写入登录日志表中，作为审计用。

UCB内容包括：

●UCBID为建立时系统分配的唯一标识，在以后的服务请求中，均要传递UCBID，系统将检查其操作权限；

●BRANCHID为登录用户的所在机构，USRID为登录用户帐号。

BRANCHID+USRID唯一确定一个用户；

●LOGINTIME为登录时间；

●SUBSYSID为登录子系统标识；

●LOGINCID为登录CLIENT位置标识；

●LASTCALLTIME为最近一次服务请求时间；

●LOGINTRYTIMES为试图LOGIN的次数，每LOGIN失败一次则+1，在N次失败后则将在M分钟内拒绝该用户再次LOGIN；

●LOGOUTTIME为退出时间。

在UCB中没有该项，但在用户登录日志中有此属性，在退出时由服务写入；

●FLAG为退出原因：

LOGOUT/自动释放/强制退出/超过LOGINTRYTIMES

登录及退出SERVICE是按名调用的，数据为CARRAY结构。

登录及退出SERVICE的功能：

1）CS_LOGIN（BRANCHID，USERID，PWD，CID，认证码），返回STATUS，UCBID

根据BRANCHID，USERID，读取用户表，检查PWD，认证码，如果找不到用户、口令不对、证书不对或过期，返回出错状态，记LOGINTRYTIMES+1，如果LOGINTRYTIMES超过系统规定次数，则写UCB日志，并返回状态；检查用户的子系统访问权限，如果不正确返回状态；如果检查正确，则建立UCB，记LOGINTIME，初始化LASTCALLTIME为LOGINTIME，返回UCBID。

2）CS_RELOGIN（BRANCHID，USERID，PWD，SUBSYSID，CID，认证码），返回STATUS，UCBID

功能与CS_LOGIN类似，只是不用建立UCB。

3）CS_LOGOUT（UCBID，FLAG）

读用户表中的LOGINTRYTIMES，取系统时间，修改UCB日志。

4）CS_CHKVER（SUBSYSID）

读取指定子系统的资源列表，并返回列表内容。

6.3.4接口服务

由CLIENT端发出的服务请求称为接口服务。

在按提交功能键（F12）或CLICK“确认”键后发出的服务请求。

接口服务的SERVICES以CI_SVRnnn命名，每个CI_SVRnnn具有相同的结构，分组的目的主要是为协同开发，同时具有相同优先级的交易可以组织在同一个SERVICES中，方便系统的配置。

数据类型统一为CARRAY格式。

CI_SVRnnn的输入参数为：

●UCBID：

LOGIN时获得的UCBID

●TXID：

交易号。

在设计时，对于每一个请求，将分配唯一的编号

●TXNAME：

交易名。

在设计时，对于每一个请求，将有唯一的命名

●CID：

请求CLINET的ID

●SUBSYSID：

请求的子系统ID

●INDATA：

交易请求数据

CI_SVRnnn的返回数据为：

●STATUS：

状态

●OUTDATA：

交易结果数据

所有的请求都要求编号与命名

●UCBID：

LOGIN时系统返回的UCBID

●TXID：

交易编号，长整数型，为6位数字。

1-2位是00-79时为功能组编号，其中第3位是0-4时为更新服务请求，5-9时为非更新服务请求，4-5位为该功能模块的交易序号。

1-2位是80-89时为公共的非更新服务请求，是90-99时为公共的非及时更新服务请求。

非更新服务请求在交易恢复时不作处理

●TXNAME：

交易名，按业务取有意义的英文命名，为32位字符串

●DATA：

交易数据是批本次请求需要的数据

按业务逻辑组织的接口服务有：

●00nnn，MIO_XXXXXXX：

收付费管理

●01nnn，ENT_XXXXXXX：

数据录入管理。

录投保单，清单等，复核，差错管理

●02nnn，TXW_XXXXXXX：

交易窗口管理。

收单登记，各种批改及保全项目（如果需提交审核或核保的项目只包括申请受理），理赔报案及简易理赔，贷款、权益转换。

●03nnn，CSV_XXXXXXX：

服务窗口管理。

生成金给付及其它需审核的给付？

？

？

，咨询服务，理赔收益人身份确认（一部分可与窗口管理调整，最后根据业务需求定）

●04nnn，CLM_XXXXXXX：

理赔管理。

立案、调查报告、理算，结案，理赔流程调度

●05nnn，UWR_XXXXXXX：

核保管理。

提取待核保件（按下一个未核保的，按投保单号或保单号），加费处理，参数化的特别约定、文字型的特别约定，团单协议书核保，约定费率

●80nnn，GET_XXXXXXX：

获取业务对象数据，作为公共的查询处理。

按健值读取。

GET一个保单，GET投保人，GET保单全部被保人，GET一个被保人，GET……

●90nnn，QRY_XXXXXXX：

查询统计日结管理。

各种报表生成请求，统计报表打印，查询请求与结果显示，各岗位的日结及日结表打印

在接口服务中，在按交易码调用实际的处理逻辑前，首先要执行一系列请求检查服务。

对于业务数据如果有合规性要求的须调用数据检查服务。

6.3.5系统检查服务

对于每一个CI_SVRnnnSERVICES，首先要调用传输数据的解析函数，把CARRAY结构的数据解析成CSTRUCTURE的数据。

如果数据是加密传输的，则需在解析前先把数据解密。

解析完成后，首先要调用如下服务：

1）CS_CHKTXID（TXID，TXNAME）

读取交易列表，检查交易号与交易名是否匹配。

2）CS_NEWCALL（UCBID，SUBSYSID，CID，FLAG），返回STATUS，TIMESTAMP

检查发送的SUBSYSID，CID是否与登录时一致，如果FLAG=CHKTIMEOUT，则检查是否超时，若FLAG=NOCHKTIMEOUT，则不检查超时。

修改UCB的LASTCALLTIME

3）CS_CHKOPGRANT（USRID，TXID，CID）

检查该用户的操作权限。

检查该交易是否是开放交易（开发交易表启动服务时在内存建立表格），若不是则读取用户权限表，检查用户对指定交易的操作权（包括时间限制、位置限制），如果无权限则返回出错状态。

若有权限，但有值约束，则构造值约束条件子句，用于以后的值约束检查。

4）CS_CHKXOPGRANT（SUBSYSID，BRANCHID，OPPBRANCHID）

检查该用户的跨机构操作权限。

上级机构的操作员自动具有下级机构操作员的相同交易操作权，非上下机构的跨机构操作要定义跨机构操作表（按子系统划分），只有列入表中的机构操作人员才具有同交易的跨机构操作权。

机构间的交叉操作权约定要求对待的。

如果跨机构操作权表只有一条记录，机构为最高层的机构号，则表示系统内的全部机构具有完全的跨机构操作权。

本服务总在是更新操作前调用。

在调用该项检查前，要根据不同的交易号，取得对手机构号（OPPBRANCHID），根据返回结构决定是否允许作更新操作。

5）CS_GETOPPBRANCHS（SUBSYSID，BRANCHID），返回OPPBRANCHIDS

得到OPPBRANCHIDS。

根据对手机构列表，构造查询条件子句，用于以后的查询。

该项服务总是在查询前调用。

6）CS_GETSUBBRANCHS（SUBSYSID，BRANCHID），返回SUBBRANCHIDS

得到SUBBRANCHIDS。

6.3.6数据检查服务

对于传入的数据进行数据合规性检查。

命名为CK_XXXXXX，数据为CARRAY格式。

●CK_TOPINSURAMNT

●CK_TOPAGE

●……

全部的数据检查服务一律由业务处理的服务调用。

6.3.7计算服务

对于与业务逻辑有关的计算，这些计算一般需要从库中读取相关数据，命名为CC_XXXXXX，数据为CARRAY格式.

●CC_REFUND001

●CC_REFUND002

●……

●CC_CASHVALUE001

●CC_CASHVALUE002

●……

●CC_PREMIUM001

●CC_PREMIUM002

●……

6.3.8数据对象访问服务

如果需要访问数据库，则要求一律通过数据对象访问服务完成。

命名为CO_XXX_XXXX，数据为CARRAY格式。

这类服务以对象来构建，与具体的交易不一定是1-1对应的关系。

如：

团单增加一个被保人，新契约与保全的团单增人都有相同的处理。

如果数据访问有值约束的，则需传递约束条件子句，并在本服务中，与形成SQL语句，根据权限表，对于数据访问的范围权限是以扩展的条件子句作为输入参数由调用者传入的。

●CO_GET_A_CONTRACT

●CO_PUT_A_BENEFICIARY

●……

6.3.9基本函数

如果某项逻辑具有一定的独立性，可设计成基本函数。

基本函数独立管理并建立函数库用于程序的联接编译。

基本函数以CF_XXXX命名。

●CF_YEARS

●CF_QUARTERS

●CF_MONTHS

●CF_WEEKS

●CF_DAYS

●CF_CORRDAY_YEAR

●CF_CORRDAY_QUARTER

●CF_CORRDAY_MONTH

●CF_COMP_INTEREST

●CF_SIMP_INTEREST

6.4系统的启动与关闭

基于TUXEDO的C/S结构的应用系统与传统的二层的C/S结构有启动时有较大的区别。

CBPS-SE服务必须启动后，CBPS-SE的客户端程序才能进行联接并请求服务的响应。

CBPS-SE启动最主要的工作是初始化全局量或内存数组，使某些处理只需通过查询内存中的数据而无需访问数据库，这样的处理是为提高系统的响应速度。

系统启动及控制时的相关参数通过读取CBPSCONFIG..INI文件获得。

CBPS-SE的关闭的主要工作是要把记入在内存中的数据或状态写回数据库。

6.4.1启动

1）系统参数中要设立系统关闭状态（数据库值），在全局量中也要设立系统运行状态（系统运行状态可考虑按机构设置，使得系统可暂停对某个机构的服务，但机构级别要有所限制，以防止状态过多）。

2）正常启动：

如果系统关闭状态是“正常关闭”，则允许正常启动。

初始化全局量，建立APCB，读入各计数器初始值并建立计数器全局变量。

启动完成后设置系统运行状态为“正在运行”，写系统关闭状态为“正在运行”。

如果系统关闭状态为“非正常关闭”，则不能正常启动。

3）恢复启动：

如果系统关闭状态是“正在运行”，则系统可恢复启动，若是“正常关闭”则提示是否要恢复启动。

由于系统非正常停机（如COREDUMP等），则启动时除初始化全局量，建立APCB外，首先要从各种表中找到计数器的最大值并恢复（写入计数器表），再建立建立计数器全局变量。

启动完成后设置系统运行状态为“正在运行”。

写系统关闭状态为“正在运行”。

4）取消暂停：

如果服务没有退出，只是系统状态为暂停，则状态恢复正常。

6.4.2关闭

1）正常关闭：

检查是否还有活动用户，如果有则提示是否要强行关机或广播关机通知，如果没有，则要反需保存的状态写回库中。

系统关闭状态改为“正常关闭”。

2）非正常关闭：

不可预料与控制，但系统关闭状态改应仍为“正在运行”。

3）暂停：

把系统运行状态设为“正在运行”（如果状态按机构设定，则可暂停某一机构的服务）。

4）强制中止用户：

从UCB中清除指定用户的记录。

6.5数据库

本项目核心数据库结构基本保持不变，但为配合工作流管理，对于新契约的投保申请数据的存储从原“投保单与保单”数据存储中分离出来，单独存为“新投保申请”，在合同生效后转为“保险合同”，对于未生效的申请转为“未受理投保申请”。

为加快工作流中各岗位的任务查询，对每个岗位建立任务表。

7.应用系统功能设计

7.1.1业务模式支持

支持多种工作流模式。

可按机构设置（要求业管确定设置的机构级别）。

7.1.2CLIENT端子系统划分

子系统的划分是以业务模式作为基础的，根据南京研讨会的讨论结果，总公司有意引入一柜制的管理办法，基于这样的要求，我们在设计系统的功能分配，建议对于业务管理的功能分成以下几个子系统：

1）数据录入/复核子系统

数据录入/复核子系统提供批量数据录入与复核的功能，其录入的内容与具体的业务部门无关。

系统除提供上述基本功能外，另提供岗位日结，工作考核等管理功能

2）新契约管理子系统

团体投保计划书

新契约管理子系统可提供从投保申请到回执登记的业务跟踪。

如果新申请在核保通过后为手动生效，则提供生效处理

3）核保子系统

团体投保计划的预核保、健康加费、职业加费、特约、责任特约、约定免赔额、免赔比例、免责期等。

发体检通知、特约与要求加费通知。

业务日结、工作考核。

4）柜面子系统

是