系统设计说明书.docx

系统设计说明书.docx

《系统设计说明书.docx》由会员分享，可在线阅读，更多相关《系统设计说明书.docx（31页珍藏版）》请在冰豆网上搜索。

系统设计说明书

（此文档为word格式，下载后您可任意编辑修改！

）

中国XX银行XX分行

中间业务系统金融平台改造项目

系统设计说明书

编写人：

ZZZ

审核人：

XXX

丹东市启东信息工程研究所

变更记录

版本

发布日期

修改内容

修改人

审核人

1.0

新建

ZZZ

XXX

1.1.编写目的

本项目所有中间业务均在金融服务平台——TULIP平台上开发、运行，因此项目的总体设计即为TULIP平台的设计架构，关于各个中间业务的具体设计请参考具体设计书。

下面发介绍金融服务平台的总体设计思想、体系架构，使读者对金融服务平台的研发背景、平台定位、系统功能、设计模型的构建等有一个全面的、深入的理解和认识，并对以后的平台应用起到提纲挈领的作用。

1.2.名词解释

交易渠道

完成交易的通道，负责交易的发起和交易结果的表现。

交易后台

能够针对某种交易请求进行处理并得到相应的处理结果的系统，是交易的实现者和交易最后完成点。

ABIS系统

是对中国XX银行新一代综合业务系统的简称。

内部交易码InternalTransactionCode（ITC）

是金融服务平台内部使用的完成某一特定功能交易的唯一标识，一个交易码唯一对应着一个内部功能的实现，由系统自动生成。

外部交易码ExternalTransactionCode（ETC）

应用系统面向渠道开放的完成某一个特定功能交易的标识。

在金融服务平台中，对外部交易码进行分段管理，不同地区的同一个外部交易码可能会对应着系统内部不同的内部交易实现过程。

交易引擎TransactionEngine（TE）

是金融服务平台内部的交易逻辑解释模块，负责对交易的相关要素进行分析，按照一定的交易流程完成交易。

组件Component

完成某种特定功能的一段执行代码，应用服务流程引擎执行的流程由完成不同功能的组件（或者构件）根据交易功能进行有序的组合构成。

组件可通过二次开发扩充。

根据组件实现方式的不同，组件可以是函数组件和程序组件（CICS下）。

其中，函数组件可以用静态或者动态调用的函数实现。

组件是金融服务平台的流程的组成要素，是运行环境中的最小功能单元。

组件区域ComponentsArea（CR）

是组成金融服务平台的交易流程的基本单位，它由组件与控件共同组成。

产品信息总线TaskChannel（TC）

是金融服务平台在交易流程中所用到的资源的集合，它不是一个物理存在的通道，应该是一个存在于数据库层的配置信息。

运行数据总线DataChannel（DC）

是金融服务平台交易过程中所用到的报文数据。

2平台定位及目标

2.1背景分析

目前面向交易的XX银行应用系统根据处理逻辑的不同分为三个层次：

渠道层、金融产品层、核算层。

其中，核算层及传统金融产品主要部署在ABIS系统中，为银行客户提供传统的金融产品服务，并为其他金融产品提供帐务逻辑处理的服务，而各种新型金融产品的应用逻辑（帐务逻辑除外）则根据业务的不同分别分布于AIPS、中间业务平台、投资业务平台、第三方后台服务等应用系统中。

这样，根据应用部署的不同又可以按照渠道层、前置层、后台服务层等三个层次划分，如下图：

随着全国数据集中项目的稳步进行及ABIS系统的日趋稳定和完善，各分行的工作重点正逐步向渠道层和前置层转移，渠道整合、ACBS两个项目的实施为渠道层的应用逻辑统一处理打下了坚实的基础，而前置层上的应用处理则处于相对混乱的状态，主要有以下一些问题：

一方面，不同的业务在不同的应用系统中实现，就要求渠道层必须根据业务的不同判断其对应的后台并组装该应用系统所定义的报文，从而加重了渠道层应用处理的复杂度；另一方面，各级分行科技人员面临着总行开发推广的各种金融产品和各个不同的应用系统，还要应对各种本地化的新型金融产品，而总行开发推广的产品，大都由不同的产品组开发，有着不同的设计思想、不同的开发习惯、各种不同的工作流程、各种自定义的数据库表、不同的报表生成方式，大量的程序维护、大量的系统维护、各种不同的管理规则……，从总行到分行都在疲于奔命应付各种项目的开发、测试、推广以及技术支持。

最终的结果是对业务需求的反应速度慢；技术人员进行着大量重复性的开发工作，各种低级的应用错误重复出现；同一个应用层上不同的业务归属于不同的技术人员负责，很多人做着相似的工作，从而造成人力、财力资源的严重浪费……

2.2平台定位

随着商业银行发展的需要，银行电子化建设也正向着更深的层次发展，银行的应用系统明显地呈现以下三个发展趋势：

数据趋于集中、处理趋于统一、系统趋于开放。

我行的全国数据大集中正在稳步实施，在前置层上建设一个开放的、处理逻辑统一的金融服务平台已是大势所趋。

2.3平台目标

随着银行间的竞争加剧，各级业务部门设计的新型金融产品越来越多，而这些新型金融产品的大部分业务逻辑都是在前置层上实现的，在此层次上的应用从业务角度上分析是千差万别、难于归纳的。

但是如果将各产品的逻辑拆分成具体的功能单元，则可以发现千差万别的金融产品其实是由可归纳总结的一个个功能单元拼装而成的。

我们可以对现有金融产品所涉及到的功能单元进行系统地分析、归纳和总结，统一其处理方法，而具体逻辑则通过可配置的参数体现出来。

这样，产品逻辑的实现过程就是平台对产品所涉及到的各功能模块的调度过程，产品的开发则由原来的编写程序改变为对各功能单元以及功能单元的调度流程的参数化设置，产品的维护则由原来的程序维护变化为对配置参数的维护。

从而实现了处理方法统一，产品开发方法统一，产品管理方法统一，产品的维护方法统一，产品规范统一。

3总体设计

3.1金融服务平台的应用布局

在XX银行面向交易的应用系统架构中，金融服务平台应当是前置层上的唯一应用处理系统，如下图所示：

在省域数据集中和全国数据集中两种模式并存的情况下，金融服务平台的应用布局如下所示：

如上，金融服务平台负责渠道的接入、后台服务的调用、本地应用处理等三部分功能的实现，在级连模式下，两个金融服务平台之间互为后台服务。

金融服务平台只在各一级分行的数据中心部署，采用集中式管理和应用、分布式开发和维护的架构，全国数据中心部署的金融服务平台还可以有全国业务统计、分析、管理等功能。

3.2金融服务平台的系统架构

金融服务平台（Tulip）是一个集管理、开发、运行、维护、统计分析等功能于一体的应用系统，它由金融服务平台运行环境（TulipFramework）和金融服务平台开发管理环境（TulipStudio）两大部分组成，其系统架构如下图所示：

下面分别对各模块进行说明：

●运行环境（TulipFramework）：

在UNIX环境下实现，基于CICS、SYBASE、C＋SQL编程实现；

●开发管理环境（TulipStudio）：

主要基于.NET架构开发实现；

●产品信息：

一个金融产品的实现包括产品逻辑的定义、产品运行数据、产品管理信息、产品统计分析数据等等，这些数据以各种方式保存在数据库中；

●交易引擎（TransactionEngine）：

是金融服务平台运行环境的核心模块，它负责对交易逻辑及交易相关要素进行解释分析并保证交易的实现；

●组件（Component）：

完成某种特定功能的一段执行代码，是由交易引擎调度的金融服务平台运行环境中的最小功能单元；

●运行数据总线（DataChannel）：

每个交易被调起时系统在内存中动态分配出来的一块数据区，交易过程中产生和使用到的所有数据都在此数据区内，供交易引擎和各组件使用，交易调用结束后该数据区被系统释放；

●流程配置总线（TaskChannel）：

保存于数据库中，由交易引擎访问并获得的交易流程配置信息，是一个虚拟的数据总线；

●应用服务器（ApplicationServer）：

基于WINDOWSIIS（InternetInformationServices）架构开发的WEB服务器，负责客户端应用调度的实现，逻辑上总行数据中心以及各一级分行数据中心各部署一台；

●开发客户端、管理客户端：

金融服务平台的所有开发、管理、运行、维护、统计分析等功能都通过开发和管理两个客户端外在体现出来，其中管理客户端为瘦客户端，可以通过浏览器（例如IE）连接到应用服务器上完成金融服务平台的运行、维护、管理、统计分析等操作；开发客户端为胖客户端，负责金融产品的可视化开发，并通过应用服务器将产品逻辑保存到数据库中。

4功能设计

金融服务平台作为中间业务平台的延伸，它除了要承袭中间业务平台的原有功能外，它还应该能解决原来的中间业务平台的不足。

同时由于金融服务平台与原中间业务平台在实现机制上还是有一定的差别的，因此在设计时应该尽量考虑中间业务平台向金融服务平台的平滑移植。

同时，对于金融服务平台的系统核心，它所要解决的问题或者说它要具备的功能如下：

4.1外部交易信息与内部交易信息的转换

平台由于面临着各种不同的渠道，也就面临着不同的通讯协议和报文标准，而金融服务平台构建在CICS中间件基础之上，平台运行环境内部采用XML报文，所以对非XML报文的渠道的接入，必须进行协议和报文的转换，同时此模块将外部交易码转成内部交易码，其中外部交易报文和内部交易报文是通过格式转换模块所提供的组件来实现的。

4.2安全检查控制

安全检查控制目前主要包括版本检查和IP地址的合法性检查。

其中，版本检查目前只针对柜台渠道发起的交易。

对于IP地址的检查，则是根据交易发起的行所号和IP地址到对应的数据库表中进行正确性检查。

4.3应用状态检查

应用状态检查包括业务活动状态检查、地区可用性检查、交易行可用性检查、渠道可用性检查、授权控制等，其中业务活动状态属于业务动态信息，运行时由运行中心操作员根据规定维护的；后面三项则属于业务静态信息，是业务开发时根据业务需求定义的。

4.4凭证信息处理

凭证信息的记录和查询也在此实现的，交易处理结束后根据需要记录凭证信息，进行凭证补打的处理等。

凭证信息的记录方式则通过如下的方案进行解决：

我们根据交易中的凭证数据源采集配置，将关联交易的相关信息进行在查询流水表中进行保存（记录流水号、基流水号），当进行到凭证生成时通过以上键值去拼装最后的凭证信息数据，保存在凭证流水表中。

此时存在相同节点数据覆盖的问题，原则是以最后的报文信息为准，查询流水表中的数据不能覆盖最后报文中的同路径数据。

以上是渠道接入模块的具体功能，它的实现方式应该是部分功能可以以组件的方式提供，如报文的格式转换、凭证信息处理；但一些流程相对固定的功能，则可以考虑在模块中固化而不是以组件的形式来提供如：

安全检查、应用状态检查等。

4.5流量控制

为了对平台的资源的合理利用及分配，我们考虑在平台引入流量控制。

平台的流量控制分为两个层次，一是对于平台的每个region来说有一个总流量的概念；然后是平台的每个项目会有一个流量，但并不要求每个项目都有流量的控制，我们一般将那些可能会占用系统资源比较长时间的项目进行流量控制。

流量控制考虑放在CWA中，并在CWA中放一个项目流量的一个动态的队列，只有当有交易正在执行的项目才会在队列中注册，这样可以是一个可控的队列。

4.6数据传递方式

金融服务平台的系统设计采用的是组件调度的模式，对于数据在交易调度过程中的传递，我们是以数据总线的形式来提供的，所谓数据总线，就是贯穿整个交易流程的一个线性数据流，它是以XML报文来表示的，同时它是不分请求和应答的。

由于数据总线在传递时不再区分请求和应答，因此在交易结束返回渠道时，我们应该配置该交易的返回报文格式，否则只能将整个数据总线返回，但这样可能会将我们在交易过程中所产生的一些临时的数据返回给渠道，造成不必要的数据冗余。

4.7交易流程调度

金融服务平台面向的是千差万别的业务种类、不同的业务流程控制和不同的流程异常控制，所以我们将交易流程作为一种资源通过配置来实现。

那么平台的交易流程调度就是对所配置的资源的一个调度过程，具体的体现则是对组件的调度过程。

4.8与不同的后台通讯

金融服务平台面向的服务后台的不同，决定了它与各个服务后台的通讯的不同。

对于与委托单位的通讯，我们可以延用原中间业务平台的通讯方式，将具体的通讯交由通讯机来完成，但也不是一成不变的照搬，它也是要作一定的修改。

原中间业务平台与通讯机通讯时是以异步的方式来实现的，这样做反而增加了CICS系统的开销（一次通讯会占用两个AS），因此我们在金融服务平台上与通讯机的通讯时则考虑作用同步的方式进行通讯。

当然也是以TCP/IP方式进行通讯，但通讯机上要作相应的改造。

金融服务平台与同为CICS机制的后台的通讯，我们可以考虑提供两种通讯方式，一种是CICS的同步通讯（LINK方式，主要用于Tulip级连使用），另一种则是CICS的异步通讯（START方式）。

平台提供的三种通讯方式，可以将它们作为一个通用的组件提供给开发人员使用，但为了使平台在交易调度失败时能够发起自冲正/重发，要求我们提供的组件不仅仅是一个通讯处理组件，它至少还应该有报文的打/解包功能，这样做的好处是在进行异常处理时我们可以不用去关心正交易时组件的调度流程，因为我们如果将打包与通讯作为两个组件配置在交易流程中，那么在冲正时的总控的调度也得按顺序去调度相应的打包组件（冲正包）与通讯组件，也就是说异常处理时也得要按一定的流程来处理，这就与我们的异常处理的机制相抵触了。

我们的异常处理力图在进行冲正（或重发）时，并不去关心正交易时去服务后台的顺序，它只需独立的处理掉正交易时所去过的所有的服务后台就行了。

因此我们考虑在通讯组件中完成对通讯报文的打/解包，这样在异常处理时则只需调用原正交易所调用的通讯组件并告诉它是一个异常处理就行了。

4.9异常处理机制

金融服务平台的交易可能会涉及到的系统平台包括各种渠道、银行帐务系统、总行网关、中间业务通讯机、委托单位应用系统、报表服务器等，因为其交易的复杂性，所以必须有一套完善的交易冲正、交易查询、交易重发等机制来保证银行帐务处理结果、委托单位应用系统的处理结果、客户的反馈信息等三方一致。

平台的异常处理机制要能处理如下的几种情况：

☐渠道发起的自冲正、查询、重发

这种情况属于当渠道发起的交易没有明确的应答时所采用的一种异常处理策略，这种异常处理机制要求渠道能将原交易的关键要素再送上来（不同的机制有不同的要求，对于冲正与查询来说，我们要求将关键要素，主要是请求流水号再次上关，而对于重发类的异常处理，则要求将原报文送上来），并要告诉平台是一种什么样的异常处理机制（是冲正、查询还是重发），要求总控能够根据相应的机制进行处理。

同时，对于要求提供这种异常处理机制的渠道要能够独立生成其请求流水号作为请求的唯一键值，否则平台是无法完成此种功能的。

☐柜台发起的抹帐

平台要能提供给柜台一个通用的抹帐交易，而不能是不同的业务有不同的抹帐交易，它的实现思想就是前面在讲通讯组件时所说的，在交易的配置时就得告诉总控该交易有异常处理机制并在正交易时记下所调用的组件的相关属性及当时的数据总线，这样在抹帐时则根据一些关键值（应答流水号等）去异常处理流水中查询相应的信息后，以异常处理的状态来调用相同的组件，也就是要求组件要有异常处理逻辑。

☐交易流程调度发生异常时的自冲正、重发

这种异常处理逻辑实际上是在交易流程调度时，当有任何的异常时，平台都能将在这之前所调用的组件进行相应的异常处理，它的实现思想是这样的：

当总控在调度某个组件时，可以从组件的属性中知道该组件是否有异常处理机制，如果有，则将此步骤的一些关键要素放到一个堆栈中（堆栈中放的实际上是交易所经历的所有需要异常处理的步骤），当交易正常结束时，我们可以将堆栈中的信息删除，而当交易有任何异常时，我们都要将堆栈中的信息插入到异常处理的一个请求列表中，由异常处理总控去进行异常处理。

金融服务平台的异常处理机制的设计，沿用了ABIB的异常处理机制。

也就是由一个独立的服务程序来完成，它会不停的轮询异常处理注册队列，当发现有满足条件的异常处理请求时，则通过异步方式调用另一个处理程序进行具体的异常处理，这样的处理方式比较灵活，而且使得异常处理独立于正交易逻辑。

4.10流水记录方式

由于金融服务平台所面临的业务的特殊性，要求提供流水的记录方式，但也不可能能够提供一个能满足所有要求的流水记录，因此平台在考虑流水的记录时，可以提供两种方式的流水记录，一种是提供一个固定的数据库表，记录一些能够抽象出共性的业务流水，再有就是允许开发人员自定义流水表，并提供给开发人员对数据表的各种管理工具。

流水的记录方式都考虑以组件的形式来提供，这样交易是否记录流水，是记录公共流水还是记录自定义流水表，都由开发人员来决定。

如果要记录流水，则开发人员在开发时就可以选择相应的记录流水的组件，否则开发人员就不必选择记录流水的组件。

4.11调试手段

为了在金融服务平台开发及运行时能够了解交易在不同步骤时的一些关键要素的变化情况，我们考虑为平台提供一定的调试手段，它的基本思想就是在开发或运行过程中，可以不用修改源程序就可以进行跟踪调试。

为了能满足不同的调试需要，我们应该能提供至少两种方式的调试手段：

一种是以组件提供，它的主要功能是可以在交易的任何流程中配置此组件以达到跟踪调试的目的；还有一种则是以函数的形式提供的，它是事先写在相关的程序中，由一个调试级别来决定本函数是否要执行（这个级别可以放在CWA中，根据需要来修改）。

我们甚至还可以考虑利用CICS的系统上的一些调试手段来进行流程的跟踪。

4.12直接调用ABIS交易的处理

金融服务平台应该提供对ABIS进行透明调用的功能，虽然在中间业务平台上也提供过类似的功能，但它并不完善。

并且要求在调用ABIS交易时能够记录流水。

我们以组件的方式来提供此功能。

4.13联机交易防止死循环操作

由于用户在配置流程的过程中很容易不小心配置出来一个死循环的流程，所以我们在开发环境下提供防止死循环的处理手段。

基本处理思想是总控用一个链表记录每一个组件的调用次数，如果同一个组件调用超过一个值，就退出总控，并警告用户流程配置有问题。

以上的控制我只考虑在联机交易流程中提供，在批量流程中不提供，因为批量处理流程中对一个组件进行多次的重复调度是经常存在的。

4.14资源配置信息动态缓存

为了防止在同一个流程中程序重复从表中查询同一个资源配置信息，提高运行的效率，我们把已经用过的配置信息存储在TWA的配置链表中，这样在本流程中如果再次用到本资源就不用再到数据库表中查询，直接从内存中得到所需的配置信息，这个链表在流程开始的时候由总控建立，在退出的时候由总控删除，对于用户是透明的。

4.15规范调用外部函数参数输入

我们在TWA中设置了外部函数参数区，内部函数在调用外部函数的时候首先设置函数参数区，然后调起函数，本函数从参数区得到传入参数进行一些特殊的操作，然后把返回参数写到参数返回区返回给内部函数，这样就统一了平台的函数调用方法，在每一个内部函数调用外部函数的时候都遵循统一的标准，也有利于用户尽快的掌握外部函数的开发方法。

4.16提供统一内存分配管理机制

为了防止开发过程中开发人员对内存分配的不合理使用而产生应的用程序运行中不稳定因素，或者因已分配内存不能及时释放而对系统资源的过多占用，我们提供统一的内存分配管理机制，保证应用程序对内存的安全、高效使用，并且内存管理也可以根据用户的需要打开或者关闭，比如我们在产品的开发阶段可以打开本开关，以发现开发的程序内存使用上的问题，在生产运行过程中可以关闭本开关，以提高交易运行效率。

4.17三种高效内部数据处理变量

系统给用户提供了三种用于内部数据处理的临时变量池，以方便用户在业务逻辑处理中需要临时保存的中间数据，或满足用户在流程的组件中传递数据使用。

这三种变量我们分别叫序号变量、命名变量、临时报文区。

对于序号变量和命名变量都可以象操作XML标签一样进行操作，做到各种变量操作统一；由于一些在流程执行过程中用到的临时变量不需要存到数据总线中，比如大部分的数据表操作语句存到数据总线中会有各种冲突，所以在生成这些语句的时候可以先放到临时变量区，等组件执行的时候由总控自动从变量区拿到对应的值放到组件参数区。

4.18平台提供的组件集功能概要说明

格式转换组件集FormatComponentSet

格式转换主要包括报文格式、文件格式的转换。

在金融服务平台中数据是通过内部数据总线来进行传递的；内部数据总线就是贯穿这个平台的内存数据存储区，以XML格式存在（这里的XML与标准的XML有些区别，因此成为内部XML）；它和数据库表是平台最底层的数据区域，是这个平台的重要部分。

报文格式转换

报文的处理主要有两个操作：

打包、解包。

因此报文格式转换就是在解包时将不同格式的报文解析到内部的XML数据总线中，组包时将内部数据总线中的数据按照格式组装成不同类型的报文。

具体的转换功能有：

标准8583===内部XML数据总线

类8583===内部XML数据总线

标准XML===内部XML数据总线

一般性报文===内部XML数据总线

复合报文===内部XML数据总线

注：

复合报文就是在报文中的含有不同类型的报文。

文件格式转换

文件的处理也主要有两个操作：

读文件、写文件。

因此文件格式转换就是在读文件的时候将文件的内容写入到数据库或者写成另外一个文件，写文件的时候将数据库表中的数据或者一个文件的数据写到另外一种格式的文件中。

具体的转换功能有：

外部文件===数据库表

文件===文件

结合平台的设计思想，我们可以将文件格式转换细化成如下图示：

外部文件===内部XML数据总线===数据库表

文件===内部XML数据总线===文件

客户信息及合约管理组件集CustomerComponentSet

这个组件集处理客户信息和合约信息，包括四部分内容：

个人客户基本资料管理、单位客户基本资料管理、委托单位合约管理、客户合约管理。

1、个人客户基本资料管理：

对个人客户基本资料的增删改查，提供客户号、证件种类＋证件号两种索引方式；

2、单位客户基本资料：

对单位客户基本资料的增删改查，提供客户号、营业机构号、法人证件类型＋法人证件号三种索引方式；

3、委托单位合约管理：

委托单位与银行之间签订的合约信息在此管理，以合约号＋合约号获取方式为索引。

4、客户合约管理：

单位客户和个人客户与银行之间签订的银行代理某项业务的合约信息在此管理，合约号＋客户编号为索引；

票据管理组件集BillComponentSet

金融服务平台中所处理的中间业务涉及到票据管理、票据信息的保存与补打两个问题。

中间业务的票据管理的功能需求与银行内部重要空白凭证的管理要求非常相似，主要功能如下：

1、对票据按项目进行分类，并根据每一个项目的大类分出小类，比如代理电话费时的信息费票据类型和电话费票据类型属于同一个大类中的两个小类；

2、票据由小号到大号逐个使用，不能跨越；

3、每个营业机构应该有一个唯一的“票据库房”，用于记录库房各种重要空白票据的数量和起止号码，控制重要空白票据的出入库；

4、为每个柜员在TULIP上设立票据箱，记录该柜员当前能使用的票据的起、止号码及当前能使用的号码；

5、柜员使用票据前，应该从库房中领用。

柜员领用票据时，库房中的该种票据减少，柜员的票据箱中的票据增加；当柜员将重要空白票据缴回库房时反之；

6、能够对这些重要空白票据作内部作废处理，将某种票据按号码进行作废处理。

调试工具组件集DebugComponentSet

在产品开发期间，开发人员需要对某些特定数据进行跟踪，被跟踪的