cbps-se应用系统构建方案与设计要求

《cbps-se应用系统构建方案与设计要求》由会员分享，可在线阅读，更多相关《cbps-se应用系统构建方案与设计要求（26页珍藏版）》请在金锄头文库上搜索。

1、1. 范围1.1 标识项目名称：中国人寿核心业务处理系统（超强版） （暂定名）开发项目代号：CBPS-SE文档名称：CBPS-SE 应用系统构建方案与设计要求文档配置管理标识：COPIA_SW_2003_00_00011.2 项目概述受中国人寿总公司委托，北京科比亚公司承担中国人寿核心业务处理系统的设计与开发。该系统的主要用户为省级集中的业务处理中心，系统要满足业务处理集中后的业务处理要求及业务处理模式，系统要具有与其它处理系统的数据接口能力。系统在 TUXEDO 作为处理中间件的基础上构建，以满足集中后数据量及并发用户数规模。1.3 文档概述本文档的目的是确定技术的选择，确定业务逻辑的分配，

2、确定主要的设计约束，确定进一步设计的规格要求。进一步的系统设计及业务规格的设计应在本文档规定的条件下进行。1.4 预期读者项目负责人、SERVICES 设计人员、界面设计人员、系统管理员、数据库设计与管理叫、方案评审组人员。2. 引用文件3. 定义3.1 术语用户控制块 是应用系统的内存存储区域，用以存放 CBPS-SE 的用户注册信息活跃产品定义块 是应用系统的内存存储区域，用以存放目前仍在销售的险种的基本约束要求业务代码字典 是业务中使用的各项代码，代码字典是企业标准化要求的一部分业务代码字典块 是应用系统的内存存储区域，用以存放各项业务代码字典的数据3.2 缩略语CBPS-SE Core

3、 Business Processing System Super ExcellenceUCB User Control BlockAPDB Active Products Define BlockBCDB Business Code Dictionary Block4. 项目概述CBPS-SE 包括寿险的各项业务处理功能，支持业务要求的处理模式，提供数据接口标准使其它处理系统可以与核心业务系统进行数据交换或作为核心系统的客户端访问 CBPS-DNCBPS-SE 用 TUXEDO/T 作为中间件保证系统的高可用性、可扩展性及好的系统响应能力。CBPS-SE 用 TUXEDO/Q 作为消息中间件

4、来满足不同服务器间可靠的数据传输。CBPS-SE 用数据路由技术解决超大数据的存储与管理。CBPS-SE 用科比亚的任务管理平台来满足业务中的工作流管理要求。CBPS-SE 具备支持超大并发用户及超大数据访问的能力。5. CBPS-SE 目标分析5.1 中国人寿背景中国人寿保险公司是国务院直属企业，是目前中国最大的专业寿险公司，2002 年的营业收入 1287.19 亿元，客户 1.5 亿人，占国内寿险市场近 60%的份额。中国人寿在全国拥有分支机构 3400 个，正式员工 5.2 万人，设立代办机构 8 万多个，聘请专兼职代理人 65 万人。中国人寿保险公司的核心业务系统建设经过 6 年多的

5、努力，取得了很大的成绩： 总颁条款的业务管理按总公司的实务管理办法，已经全部实现上机处理，并且正在向省级集中； 短意险的业务处理系统也已经开发完毕并正在全国推广使用； 老业务的处理系统正在测试中，将于 2003 年 4 月投入运行。5.1.1 组织机构中国人寿的组织结构是按行政区划设置的集团公司。总公司为一级法人，主要负责公司各项规范的指定及执行情况的检查，除一些特大型的团体业务外，总公司并不具体负责产品销售。对于超过规定的大额件承保或理赔，总公司负责案子的核查及处理。5.1.2 业务现状及特点目前中国人寿已经开办的业务或即将开办的业务有： 按产品类别分：普通寿险、两全险、意外险、健康险、养老

6、年金 按业务性质分：团体业务、个人营销业务、代理业务 按缴费性质分：普通、投联、万能、基金、储金 按盈余分配性质分：红利、利差返还CBPS 及 CBPS-O 已经能够处理上述的各类产品。目前的 CBPS 在支持的业务模式上主要是“申请-审核-生效”的模式。5.1.3 业务量由于中国人寿是全国性的公司，各分公司之间东西差异比较大，以中等规模的省作为依据，目前全省的并发用户数约为 1,000-1,200 ，数据量约为 30G（不包括影像数据） 。分地区的每天新单数、保全的业务数、理赔业务数、收付费交易笔数等的各项统计中国人寿信息技术部正在统计。5.1.4 电子化现状硬件 IBM-AIX，HP-UX

7、 ，PC-SERVER 等基于 UNIX 的小型机或服务器软件 OS：UNIXDBPS：INFOMIX业务处理系统：CBPS财务处理系统：CLAF营销员管理系统：AMIS5.2 业务目标 业务处理逐步集中 引入原始单证影像件管理后的工作流管理 客户服务的一柜制业务模式5.3 技术目标 先进性：基于 TUXEDO 中间件的三层 C/S 模式是目前开发大型关键业务处理系统最为先进技术，同时也是成熟的技术。这项技术在支持超大并发用户，超大数据规模时是必不可少的 灵活性：由于业务逻辑与表示逻辑的分离，使得调整业务逻辑或增加业务逻辑时不会引起界面的调整；反之如果用户要求设计新的界面风格，而基本的业务逻辑

8、不变时，不必修改服务逻辑。这对业务要求可能不断发生改进的企业来说是十分必要的 安全可靠性：系统除注册用户安全性检查外，增加了注册位置、注册时间的安全性检查，并且增加了安全性审计功能。在应用设计时增加了安全服务处理层来解决安全性检查，在必要时可加入数据传输加密及关键数据存储加密的服务 易操作性：前端界面全面以 WINDOWS 风险提供，操作上既提供鼠标操作又提供操作的操作方式。配合业务部门一柜制的管理要求，专门设计柜面业务处理子系统，使得窗口服务更为方便 开放性：系统设计中采用的技术都是基于标准的，并且都是运行在开放平台上。坚持开放性也就是坚持系统的可扩展性。在我们的应用系统中可以通过更换数据访

9、问服务来存取不同的数据库6. 总体解决方案6.1 系统总体结构系统架构中主要的的是把表示逻辑、业务逻辑通过事务处理中间件构建成“请求-响应”这样的服务形式。6.2 分布计算环境CLIENT 端只反映表示逻辑，即数据的录入，并把请求发给 TUXEDO 服务，CLIENT不对输入的数据做任何加工处理。对于返回的结果，按要求组织数据并显示。SERVER 端为业务逻辑，所有的逻辑以 TUXEDO SERVICES 组织。多个 SERVICES可组成一个 SERVER，多个相同或不同的 SERVER 可分布在不同的物理的服务器上。服务的集群架构是应用系统具有高可用性及响应速度快的技术基础。系统中可配置一

10、个或多个数据库服务器，不同的数据可存放在数据库服务器中，同一数据对象可按一项或多项属性值分布在多个数据库服务器中，并通过数据路由透明访问数据库。基于消息中间件可构造 MSG-HUB，满足不同业务系统间的数据交换。对于外部接入的服务请求，在系统中设置前置机，并且把前置机的请求程序作为CBPS-SE 的一个 CLIENT。6.3 应用系统结构应用系统的业务逻辑是分层设计的，每层都具有一定的独立性，要求任何一层的修改只要不修改调用接口的数据，就不会影响其它层的处理逻辑。CBPS-SE 应用按如下要求分层6.3.1 CLIENT 的启动及退出启动 CLIENT 时首先要进行登录，登录时要输入“机构号”

11、 ， “用户名” ， “口令” ，系统将自动获取用户登录的位置，如果需安全认证的，将读取安全证书号。登录时首先发出 CS_LOGIN 请求： CS_LOGIN(BRANCHID，USERID，PWD ，SUBSYSID ，CID ，认证码)，返回STATUS，UCBIDLOGIN 成功后，发 CS_CHKVER 请求： CS_CHKVER(SUBSYSID)，返回 STATUS，各程序、数据文件的版本列表CS_CHKVER 检查系统本地资源的版本，以清单方式发回，读到后可比对本地的资源版本清单，如果相同的则启动系统，如果不同则显示需重新下载的的资源名称，选择后启动 FTP 进行文件传输。本地资

12、源列表可以正文方式存储，但为防止文件内容被修改，另需记录文件的 CHKSUM，在比对前若 CHKSUM 不对，则要求重新下载全部本地资源。系统退出时要求发 CS_LOGOUT： CS_LOGOUT(UCBID)，返回 STATUS6.3.2 客户端程序对于输入数据可通过定义域的属性对输入的域的格式（日期型，字母数字型、字符型、字母型、数字型等）进行检查对于显示结果，如果是列表格式，可对显示结果按指定列排序，或按某属性值进行选择，也可调整列的显示位置。若某显示域为其它域的简单算术运算结果，则可在 CLIENT端完成。CLIENT 功能一般不通过编方式，而是通过工具的属性定义完成。对于服务请求，所

13、有的 CLIENT 程序一律通过统一的接口函数调用，接口函数把 VB的结构的数据转换成 CARRAY 结构，并发出 TPCALL 调用。若数据需传输加密的，则加密逻辑封装在接口函数中。在接口服务请求时，如果返回 TIMEOUT，则要求发 CS_RELOGIN 请求： CS_RELOGIN(BRANCHID，UCBID，USRID，PWD，SUBSYSID，CID ，认证码)，返回 STATUS6.3.3 登录与退出服务任何一个 CLIENT 在请求服务前必须建立应用级的会话，这是通过 CBPS LOGIN 完成的。登录时，服务将在内存为每个用户建立一个用户控制块（UCB） ，用以存放有关登录的

14、状态及其它信息。当用户退出时，系统将 UCB 内容记入 UCB 的日志。UCB 日志的结构为：UCBID BRANCHID USRID LOINING TIME SUBSYSID LOGIN CIDLAST CALL TIMELOGIN TRY TIMESLOGOUT TIME FLAGUCB 是内存中的存储区，当用户 LOGIN 成功时建立，同一个用户在同一时刻只能登录一次。UCB 内容与 UCB 日志内容基本相同，但不包括 LOGIN TRY TIMES、LOGOUT TIME、FLAG 。 UCB 空间在建立时动态分配，在 LOGOUT 时释放。在连续 N1分钟内没有服务请求时，系统将自

15、动释放空间。登录完成时，系统同时要把登录信息写入用户登录日志；释放空间时，系统要把 UCB 信息、LOGIN TRY TIMES、LOGOUT TIME 及 FLAG 写入登录日志表中，作为审计用。UCB 内容包括： UCBID 为建立时系统分配的唯一标识，在以后的服务请求中，均要传递UCBID，系统将检查其操作权限； BRANCHID 为登录用户的所在机构，USRID 为登录用户帐号。BRANCHID+USRID 唯一确定一个用户； LOGIN TIME 为登录时间； SUBSYSID 为登录子系统标识； LOGIN CID 为登录 CLIENT 位置标识； LAST CALL TIME 为

16、最近一次服务请求时间； LOGIN TRY TIMES 为试图 LOGIN 的次数，每 LOGIN 失败一次则+1，在 N2次失败后则将在 M3分钟内拒绝该用户再次 LOGIN； LOGOUT TIME 为退出时间。在 UCB 中没有该项，但在用户登录日志中有此属性，在退出时由服务写入； FLAG 为退出原因：LOGOUT/自动释放/强制退出/ 超过 LOGIN TRY TIMES登录及退出 SERVICE 是按名调用的，数据为 CARRAY 结构。登录及退出 SERVICE的功能：1） CS_LOGIN(BRANCHID，USERID，PWD ，CID ，认证码 )，返回STATUS，UCBID根据 BRANCHID，USERID ，读取用户表，检查 PWD，认证码，如果找不到用户、口令不对、证书不对或过期，返回出错状态，记 LOGIN TRY TIMES+1，如果LOGIN TRY TIMES 超过系统规定次数，则写 UCB 日志，并返回状态；检查用户的子系统访