核心银行系统 之十九 技术架构（一）
技术架构（一）
image.png
image.png
核心交易平台设计
image.png
1、信息展现模块:实现信启、的录入和输出,实现对屏幕及各种设备的控制。
(1)包括对多种设备的支持,如屏幕(键盘)、磁盘、网络、磁条读写器、打印机(各种型号存打、行打)、密码键盘、JC卡读写设备等,同时需支持各种设备复合使用情况。
(2)实现对信息的多种展现形式,包括交易响应信息如正常应答信息(可能多条)、提示信息、(可能多条)、拒绝信J息(可能多条)、授权信息(可能多条)、复核信息等的支持,也包括多页式查询返回的信息、返回的多条编辑信息、带格式文本信息等。
2、规则驱动模块:实现原交易的启动、己定制交易联动规则的控制、原交易控制规则的驱动及子交易控制规则的驱动。
(1)实现原/子交易联动控制;
(2)实现字段启动交易的控制;
(3)实现交易权限规则的驱动;
(4)实现子交易级规则的驱动;
(5)实现子交易本身为原交易(组交易)的控制:
(6)实现自动启动现金、凭证打印、收费等公用模块组交易的控制;
(7)需要平衡系统灵活性与系统效率之间的矛盾。
3、报文拆组模块:实现对应用收发的报文进行组织和拆解,组织后的报文供通讯收发,拆解的报文供应用使用。
(1)对报文格式的支持:支持自定义报文格式、ISO8583报文格式、类HTML等,基本要求要实现对类HTML格式报文的支持;
(2)可考虑应用系统内采用统一的一套内部报文格式,对外提供多种格式支持;
(3)支持同一交易返回多条不同格式报文的处理:
(4)对报文定义的支持:前后台统一定义一套报文格式;
(5)需要考虑拆组的效率和通讯数据包的精简
4、交换控制模块:完成路由分捡、多服务器信J息交换功能。
(1)对于前台模块支持子交易/字段启动交易级别的个性路径选择;
(2)对于后台模块同时考虑对多个分布在不同主机上的独立系统实现集中清算模式的支持
5、通讯传输模块:完成通讯传输的功能。
(1)支持多中通讯协议,如TCP/工P、SNA等:
(2)支持不同交易采用不同的通讯协议;
(3)支持通讯报文的加密/解密,考虑使用加密机进行硬件加密;
(4)支持通讯报文的校验,如MAC码;
(5)不论前台还是后台,均需支持主动/被动通讯模式:
6、功能展现模块:完成真正的具体交易功能,本着提高功能内聚、降低模块藕合的原则进行结构划分,由核心构件资源库及组装交易所需的接口模块组成。处于应用级别,不属于平台范畴。
7、信息存储模块:
(l)需要考虑不同交易数据的信息隔离;
(2)需要考虑同一原交易下交易数据的信J息共享;
(3)需要考虑部分特定类型信息的历史数据存储,如凭证打印信息;
(4)临时存储的数据实现自动清理。
8、控制信息、的定制:此处所指的控制信息,包括菜单定义、交易定义、屏幕定义、数据字典定义、通讯传输格式定义、授权信息定义、提示信息定义、列表定义、打印格式定义、输出信息格式定义、设备定义等以及其他平台所需的控制信息。
(1)各种与具体交易相关的控制信J息、的定义数据可以以交易为主线进行卸载和安装。
(2)定义的控制信息需要满足系统性能上的要求,既保证系统开发的灵活性,又保证访问的快捷,以确保系统整体运行效率。
核心构件库的组成
核心构件库由两部分组成:子交易、API。
其中每个子交易由四部分组成,子交易可大致分为五类:账务类、事物类、查询类、数据准备、组合类。
API可大致分为三类:账务类、事物类、查询类。
构件形成及使用原则
1、每个业务系统包含的内容,由各自提供的核心子交易、A卫1及相应的独立对外展现交易组成:
2、每个业务系统都有其独立的数据库体系,相互之间拒绝数据库的直接访问,确保数据文件的隔离。对于联机交易,如需使用其他系统的数据,通过联动子交易或调用对应系统提供的API实现。对于后台批量交易,少量数据交易采用
API调用方式,大量数据处理则采用对应系统提供的接口文件方式由相应的系统进行处理,在7X24模式下,大量数据处理也可以采用API方式;
3、核心业务系统功能由各个业务系统提供的核心构件资源库中相应的构件(子交易、API、接口数据文件)进行组装定制而成,任何系统提供的构件中都只包括对其自身系统功能的处理和数据库文件的操作,核J自构件的划分,按照各业务系统提供的具体服务类别划分,具体的划分不在此处详细描述;
4、根据具体业务特点,各系统实现账务一体化,客户类别、币种类别、账务类别、作为具体业务系统的属性出现,从数据结构底层实现一体化,只区分不同服务功能,对于同一种服务功能以单一交易处理,对于前台,交易组装时对部分交易要考虑可操作性,以引领式模式实现。
image.png
交易驱动设计要点
1、做到原交易空间、子交易空间、共享空间信J自、的独立性;
2、交易输出空间为整个原交易共享,信息可能为多格式,考虑其中存储访问的条理性;
3、各个级别层次的交易模块都由交易驱动主控统一驱动
4、交易联动组装实现主要是通过联动入口和出口的编制完成的,对于交易入口,一般可通过定义启动条件和参数转换规则的定制方式来实现,不需要编写入口程序,如有特殊情况,则也可以通过编写新的子交易,通过联动出入口或子交易输出子交易输出空间实现,考虑未知情况,在平台中保留通过入口函数启动子交易的控制;
5、可考虑在平台中支持公共启动交易的参数化定制:
6、在交易输出空间信息发送前台前,进行平台统一的信息检查和整理处理,如统一授权产生、事前复核、交易平衡性、信J息的优先级处理等。
规则引擎的设计
规则引擎(Rules Engine)的组成
规则引擎由三部分内容构成:
1、规则描述:即由算术表达式及逻辑表达式组成的综合逻辑表达式,规则的结果一般为逻辑变量值,“成立”或“不成立“;
2、规则成立的驱动目标:即当规则成立时需完成的任务或动作;
3、规则执行:即完成上述两点需要的程序级支持;
规则引擎实现基础
规则引擎实现的基础是“数据信息流”机制和规则解析:
1、规则解析,对给定的表达式规则进行解释和运算,得出唯一的逻辑一结果:“成立”或“不成立”。
2、“数据信息流”,为表达式解析提供数据基础的数据产生和存储机制,应该满足四点要求:
(1)数据可提取:存储的数据可以在表达式解析过程中提取到并用于计算;
(2)数据可归集:交易流程中每个流程单元均可将数据元素输出到“数据流”中;
(3)数据可扩展:在交易流程配置中任何流程单元均可方便地增加“数据流”中数据元素个数;
(4)数据互斥:不同流程单元输出到“数据流”中的数据元素,应该互相隔离.避免相同元素的覆盖;
交易驱动实现方法
根据具体的业务功能需要,选择性地将一系列的子交易和API组织起来,通过定义组装的方式联动在一起,构成一个原交易。
image.png
每个子交易我们称为PU,每个原交易称为MU,驱动规则称为RuleSet,驱动主控称为TPloader。
交易调度和组装过程
交易调度的实现由TPLoader根据交易联动表的配置,根据RuleSet的相关条件与逻辑,并结合交易环境的具体形式,调用PU与WU,以实现完整的交易流程实现业务。
TPLoader的对条件逻辑的判断、对PU的调用、对WU的调用,通过Assemble层提供的接口实现组装过程。在整个调度过程中的数据存储和共享通过DataPool及其相关的接口完成。
1、TPLoader的调度过程
(1)启动TPLoader:
TPLoader作为一个PG(在CICS环境下),当CICS接收到请求报文后,根据SerViceName启动TPLoader。当TPLoader与不同的PU、WU绑定时,对应与不同的Service。
(2)TPLoader载入交易配置:
TPLoade:将对应的配置载入,并进行自身的初始化处理。
(3)根据交易配置表中的内容进行预处理:
根据交易配置表中内容,进行相关的交易预处理如检查、报文解析、获取流水号、获取系统日期等。
(4)进行交易处理:
根据交易联动表的内容和逻辑判断条件调用PU或恻进行交易处理。
(5)进行异常处理:
若功能处理异常或其他不确定情况,进行特定的异常处理。
(6)根据交易联动表中的内容进行结束处理:
根据交易配置的内容,进行相关的交易结束处理如打包、提交事务等。
(7)结束TPLoader:流程结束,并释放资源。
交易组装方式
系统通过交易联动表的配置作为执行交易过程的定义。在交易联动表中体现交易过程中的功能和执行条件规则在集成基本的PU和WU及RuleSet功能的前提下,通过交易联动表组装交易。
交易联动表与其他模块的关联:
image.png
报文接口及拆组包
主报文格式
采用类HTML格式,使用Key＝value方式(散列表)描述数据,对Key使用“<>”进行标注。针对核心交易平台,采用这种报文结构的优点在于:
1、增强报文适应能力
2、适应报文的灵活可扩充
3、方便报文数据提取
4、提高系统的可调试能力
系统拆包流程
根据交易报文头信息进行如下处理:
1、从原交易定义表中根据交易代码读出MACChk标志,决定是否进行MAC检查;
2、如果需要MAC检查,调用HSM提供的API进行MAC检查:MAC检查出错,返回前台提示信息:MAC出错;
3、根据交易代码检索交易字典(TranDataDic),根据交易字典定义表,进行报文解包。如果交易字典定义的是'M'信息,报文中必须上传。没有上传,返回前台提示信息:必要的输入信息不全;
4、根据KEY值解包。
系统组包流程
1、根据交易代码检查交易字典(TranDataDic),根据交易字典定义表,找出KEY;
2、根据KEY,查询交易输出数据定义表(MUOutData),根据交易输出定义表内容组织数据;
3、根据MACChk标志,调用HSM提供的API进行MAC计算。
操作流程定制
操作流程定制设计架构
image.png
操作流程定制设计要求
1、实现引用完全参数配置模式
2、交易入口主要完成交易的启动条件判断和交易入口参数赋值,通过启动条件定义和入口参数映射的定义实现定制;
3、屏幕入口、字段入口的实现同交易入口的实现模式;
4、为实现开发过程的定制,必须采用统一的数据字典:
5、平台提供自动启动子交易的应用定义,而不是将个别功能集成在平台中,应用只需定义入口厂出口;
6、实现交易权限定义的灵活性,通过柜员类别/级别、客户类别/级别、交易类别/级别、菜单类别/级别控制显示和操作,实现个性化菜单定制:
7、实现凭证格式的共用,建立凭证格式库,提供凭证输出的统一接口,提高凭证格式的复用率,并实现事后凭证的重复打印功能;
8、用定制方式实现前台列表信息的动态显示;
9、授权模式统一,前台可以实现简单的授权定义,需将授权信息、统一存储在后台,便于统一管理授权记录;
10、提供集成在运行平台内的终端间、结点间消息通知功能,便于下一步实现工作流程定制;
11、支持子交易循环启动、原交易循环启动;
12、支持当日冲销、复核、事后复核、异步授权等特殊交易模式;
13、支持前台平台外挂其他交易系统
统一冲销模式
核心系统采用统一的当日冲销(抹账)用户接口模式,即统一的冲销交易。操作人员可以使用此接口对系统中任何可以冲销的交易(业务),包括账务类交易和非账务类交易进行冲销,冲销时使用统一的一个专门用于冲销的交易。
实现方式
在核心业务系统中当日冲销采用“反交易十存储过程”的模式实现。
当日冲销可以冲销账务的和非账务的交易,账务的交易必须有流水记录,非账务的交易可以有也可以没有流水记录,但必须产生一个流水号(因为银行需要统计柜员的业务量及对特殊交易记录进行稽核,所以系统中所有处理登记簿的交易都要登记一条非账务流水,方便查询)。反交易一般针对处理账户的子交易专门设定,每一个记账子交易或API必须有一个对应的反交易函数。
image.png
优点
1、使用存储过程减少对反交易的开发工作量
2、使用存储过程减少反交易对数据库表操作的差错率
3、使用存储过程实现在冲销时对数据库表的统一操作遵、使用存储过程提高在对数据库表变动监控的效率
5、使用反交易支持隔笔冲销及特殊的冲销方式
技术实现要点
1、一个交易里面可以同时包括反交易冲销和存储过程冲销。
2、存储过程冲销对于不允许隔笔冲销的交易或对于如果隔笔冲销不受到影响影响的字段,都可以使用存储过程方式对交易进行冲销。
3、反交易冲销
对于隔笔冲销对字段有影响的情况下或不需要存储过程冲销的,需要用反交易冲销。要求每一个记帐子交易或API都要有唯一一个相应的反交易函数。
4、存储过程、反交易冲销的界定
原则上如果需要或允许隔笔冲销(隔笔冲销有收到影响的字段),不能够使用存储过程冲销以及调用存储过程。
5、子交易定义表
使用存储过程冲销的交易时,不需要在子交易定义表中定义反交易程序,存储过程平台统一调用。
使用反交易冲销的交易,必须在子交易定义表中定义该子交易的反交易程序名称。
6、冲销登记簿定义表
原则上要求每个数据表都要在冲销登记簿定义表中进行定义。
7、存储过程的使用
(1)由平台提供统一的生成存储过程的工具,对每个已经在冲销登记簿定义表中已经定义的数据表生成一个存储过程:存储过程的命名为:P十数据表名
(2)如果有不需要用存储过程进行冲销的字段,不能在冲销登记簿定义表中定义,一旦定义则冲销时根据存储过程对该字段进行恢复
(3)存储过程调用的参数包括机构代码、交易流水号、交易日期、序号,以及数据表键字的新旧值
(4)每个物理文件必须定义唯一键字。且对表操作必须使用平台自动生成的表操作接口程序。该接口程序通过是否调用存储过程接口(1:调用)调用存储过程
(5)存储过程关联程序根据固足接口(子交易中详细描述),将记录原始信息保存
(6)对表操作时,在更新(包括删除)记录方式下,在表更新操作前调用存储过程;在插入记录方式下,在表插入操作后调用存储过程
8、反交易的编写
(1)每个子交易或API,有且只能有一个反交易函数
(2)每一笔账务必须有一笔流水,非账务交易视情况写流水
(3)在原始交易时有可能一个子交易产生多笔流水,要求在编写反交易函数时有特殊处理
(4)可以利用流水中一些字段保存原始交易的一些信息,但需要按照制定的统一规范使用
(5)将原始交易流水置为“己冲销”状态,并登记反交易流水,借贷方向同原始交易,交易金额为红字。此处考虑在平台处理。
存储过程的封装
对存储过程的封装目标是,应用程序中不会出现与存储过程技术有关的实现过程,便于应用程序开发。下面简要描述用于封装生成程序的大致过程。
功能:对每个数据表生成对应的存储过程、存储过程关联程序、冲销时调用API
概要流程:
(1)取得数据表名(可通过数据表定义文件读取或手工调用)
(2)生成存储过程
EXECSQL
CREATE PROCEDURE 存储过程存放库/存储过程名称
(IN 交易机构 CHAR(长度),IN交易流水号 NUMERIC(长度,小数),
IN 子流水号 NUMERIC(长度,小数),IN 交易日期CHAR(长度))
LANGUAGE RPGLE
NOT DETERMINISTIC CONTAINS SQL
EXTERNAL NAME存储过程关联程序存放库/存储过程关联程序
PARAMETER STYLE GENERAL
(3)生成存储过程关联程序
接口:交易机构、交易流水号、子流水号、交易日期、键字值结构、
操作方式
功能:将备份信息写入信息保存登记簿
流程:根据键字检索数据表,将交易机构、交易流水号、子流水号、交易日期、键字值结构、记录格式结构操作方式写入冲销前信息保存登记簿PFSFMREVI
(4)生成存储过程冲销API
接口:原交易流水号、子流水号、(目前交易机构、交易日期对于查找备份信息、无用,但仍作为接口参数)
功能:将数据表备份按字段定义恢复数据
流程:根据备份信息中的键字机构值检索数据表,将备份结构信息、值赋值到与文件记录格式相同的结构中,将在冲销定义表中定义的字段在上述结构中取值,更新文件。
权限管理
设计思路概述
应用系统中的权限管理分为两个层次：
- 交易权限——有无权限；
-
授权——有权限时是否需要他人授权，授权条件；
系统中对权限的控制采用了统一的模式，并预留给应用部分接口以应对特殊情况。在公共权限检查中，系统中控制的思路是：
image.png
交易权限设计
系统交易权限的检查由后台统一模块处理，各交易不需要对柜员权限进行单独的检查。现有交易的权限已不仅仅限于机构和柜员，而且与交易的要素（例如产品，客户等）有关，因此权限检查放在后台进行统一处理。
目前系统的授权分为两个部分：公共处理部分和特殊处理部分。公共处理部分只需要对表进行配置，能处理的授权有：做某个交易需要授权，做每个交易时根据产品种类、币种类别、客户类别、客户最低服务级这些交易要素确定是否需要授权。特殊处理部分需要具体交易程序内进行判断，例如修改了利率，就需要在自己的程序中处理。
公共授权的配置说明如下：
1． 配置柜员交易权限定义表
该表的作用是定义某类机构某类柜员能够做的交易（具体可以定义到交易内能操作的产品种类、币种类别、客户类别、客户最低服务级别），以及能操作的情况下是否需要授权。若做交易需要授权（跟产品种类、币种类别、客户类别、客户最低服务级要素无关），只需要定义这张表，表中的产品种类、币种类别、客户类别、客户最低服务级可用通用表示（详见数据结构）。若根据交易内的产品种类、币种类别、客户类别、客户最低服务级要素确定是否需要授权，不仅需要配置这张表，还要配置权限检查参数定义，见下面公共授权配置说明2。
2． 配置权限检查参数定义
该表的作用是定义产品种类、币种类别、客户类别、客户最低服务级要素如何取值，作用等同与子交易入口定义，这些要素来自交易哪些私有字典。由于一个交易涉及交易的两方，所以对于同一交易可以不只一个记录。
特殊授权处理说明如下：
授权要素超出公共处理的范畴，需要自己在交易里处理。例如利率修改等，请在自己的程序中进行判断，调用公共提供的函数即可，程序按正常流程继续往下走。程序例：if( 输入利率 != 标准利率 )
{
自己定义授权规则码，取授权规则定义表pubauthrule。
if( pubRegAuth( pstPubcom, 授权提示信息，授权方式，授权机构类别，授权机构级别，授权柜员级别 ) )
FUNCERR_PRO
}
配置授权规则定义表：该表的作用是定义授权提示信息，授权方式，授权机构类别，授权机构级别，授权柜员级别。可以根据需要进行调整，而避免修改程序。
权限配置说明
交易权限定义表的配置思路为：某类机构的某类柜员具有某交易的操作权限，在该交易内能操作哪个产品，币种，客户类别，客户服务级别。
1．机构定义
机构按类别和级别确定一类机构。如果在机构类别字段定义了具体机构，则该交易只有定义的机构具有操作权限。若干在机构类别字段定义号，则所有机构具有操作权限。
2．柜员定义
操作员按类别来定义。若干在操作员类别字段定义号，则前面定义的机构的所有柜员对交易都有操作权限。
3．交易码
按前台的交易码定义。
4．产品种类
现有交易内可能会出现好多的产品，如果要限制操作员只能操作某类产品，则在该字段定义。
5．币种类别
定义该交易内，操作员能操作的币种类别。
0.操作员可操作所有币种
1.只能操作本币
2.只能操作外币
6． 客户类别
定义该交易内，操作员能操作的客户。
*.所有客户
1.对私客户
2.对公客户
3.同业客户
7．客户服务级别
定义最低服务级别的客户，低于该级别的客户，操作员无操作权限。
由于币种类别，产品类别，客户类别及服务级别等要素，在各交易中的字段不会一致，所有需要由开发人员定义权限参数配置表pubrightparam。该表定义在某一交易中币种，产品类别，客户类别及客户服务级别分别取之哪个字段。
核心后台处理流程
权限处理由后台公共权限处理模块统一处理，处理流程如下：
image.png
系统授权处理流程
image.png
1.前台柜员录入交易要素后提交后台，后台公共授权产生模块根据相关要素检查该交易是否需要授权，若需要授权则登记相应授权信息。
2.交易调度模块调度各子交易运行，各子交易根据特殊的授权条件检查是否授权并登记相应授权信息。
3.交易调度完成后，公共授权产生模块判断交易是否需要授权，若不需要授权则提交数据库落实事务，交易成功返回前台。若需要授权，则交易回滚，同时从登记的多个授权信息中挑选一授权级别高的授权信息（优先原则为：授权机构级别，同授权机构级别选择非本机构，同机构级别时授权柜员级别），并返回授权信息至交易前台。
4.前台接收到授权信息（授权柜员类别及级别）后，柜员选择本地或异地授权：若选择本地授权，则授权柜员输入秘密，提交后台运行。若选择异地授权，系统通知授权柜员。
5.柜员可等待授权后提交本交易或暂时退出本交易待授权后再通过执行异地授权交易提交本交易。
6.授权柜员进入异地授权交易界面，查询授权码，系统返回交易界面供授权柜员检查，授权柜员同意授权或拒绝授权，后台授权检查模块检查该需授权交易的授权记录，登记授权状态。
7.操作员执行异地授权交易，查询授权号，执行原有交易。
公共授权模块
公共授权处理模块由公共授权产生模块，授权登记选择模块及授权检查模块组成。公共授权产生模块对公共的授权要素进行检查，公共授权要素可以包括：交易码，操作员（类别，级别），产品，币种类别，客户类别，客户的服务级别等信息。各子交易授权产处理特定条件下产生的授权，例如：根据账户的类型，交易的具体特征，交易的金额等各种限额的定义等。
复核模式
此处“复核”指事中复核模式,即双敲复核,一个交易由两个柜员完成;录入柜员录入交易要素后,由复核柜员重新输入部分或全部交易要素,确认正确后提交主机完成交易。
复核交易的定制在前台配置完成,其中复核交易及复核要素、复核条件完全实现参数化配置。
事中复核:在交易开始至完成交易的期间内进行的对各业务要素的双人双敲过程。
复核交易:针对银行业务的风险控制需要,需双人双敲的交易即为复核交易。
复核要素:针对一个复核交易,复核要素指交易中需要双人双敲的信息、集合。
复核条件:针对一盒复核交易,复核条件指对交易进行复核的前提条件。
优点评析
1、复核交易的定制完全参数化,包括交易是否需要复核、复核条件、复核要素;
2、复核交易的定制面向前台,简单易用,与主机交易配置无关;
3、交易复核时自动产生复核编号,复核柜员只需根据复核编号便可查看录入柜员的交易画面,复核要素高亮显示,一目了然。
4、主机建立复核登记簿,保留系统全部交易复核的历史信息,方便查询。
要点分析
1、复核交易定义
在前台的联动交易表中定义。通过复核开关标志位十复核条件表达式。
2、复核字段定义
在前台屏幕字段信息中定义,通过复核开关标志位+复核条件表达式;
字段判断方式:
标志位==O令非复核字段
标志位==1AND条件表达式空令复核字段
标志位==1AND条件表达式结果为真令复核字段
标志位二=1AND条件表达式结果为假令非复核字段
3、检查复核位置
每个子交易提交之前。
4、复核号的产生
在后台生成,柜员号斗复核号唯一,每个柜员每个交易日从1开始
后台生成复核号、记登记簿、返回复核号及响应信息。
5、复核交易原始信息、存储
前台将要保存的原始交易数据输出到文件,文件名为柜员号和交易日期,然后提交后台保存(使用文件服务器);
6、原始交易信息重现
复核柜员录入复核号,查询主机复核登记簿,主机通过文件服务器回传复核交易原始信息保存文件,前台重现原始交易画面,恢复画面时根据复核字段标志隐藏复核字段。
7、复核失败后的处理
录入柜员重新做,复核柜员重新复核。
8、复核权限控制
权限控制方式同其他正常交易。
image.png
记帐录入流程
image.png
复核流程
复核统一交易入口:公共复核交易
image.png
- 输入柜员号和复核号（可选），进行查询需复核的交易
- 选择其中一笔，按空格执行
- 根据保存的数据文件恢复画面，恢复画面时根据复核字段标志隐藏复核字段
- 进行字段复核，每个字段输入完后进行检查
- 复核成功后：恢复交易数据，设置复核柜员号，柜员号是录入的柜员，提交主机
- 若把当前复核交易当成原录入柜员的，当此交易需要异地授权时，回不到复核柜员。
- 若把当前复核交易当成复核员的，现有的异地授权可以支持复核以后的异地授权
- 核对失败后的处理：录入柜员重新做，复核柜员重新复核
- 复核登记簿查询：提供一个查询交易，可以查询复核登记簿
后台接口
- 前台生成数据文件名： sqfh_YYYYMMDD_Brc_Teller．hhmmss后台接收文件以后，根据生成的复核号替换 hhmmss ，这样复核号和文件可以直接关联;
- 前台提交复核登记交易：上传数据：机构号、柜员号、交易日期、数据文件名、复核状态（未复核）等
- 下传数据：复核号
- 登记簿信息：机构、柜员、复核员、交易日期、复核号、数据文件名、复核状态等
复核权限控制
系统提供两种模式：１．他人 ２．任意
收费设计
核心系统中采用统一的收费模块，对各种费用的计算方式、收费来源、收取时机、核算模式、优惠方式等进行归纳总结，并考虑一定的扩充性，收费模块的设计思路如下图所示：
image.png
系统的公共收费模块实现了费用的计算以及收费的实时记账,各应用交易通过配置可增加及调整各项收费。
公共收费流程
1、前台柜员交易录入完毕提交,前台根据该交易配置中的费用计算标志进行不同处理:若费用计算标志为不收费,直接提交后台运行。若费用计算标志为收费,则调用后台费用计算交易。
2、后台费用计算交易根据交易配置计算各项费用,返回前台显示,操作员可以修改收费的账号以及是否收费,提交后台。
3、后台公共收费记账模块对各项费用记账处理。然后进入交易调度处理,对原交易进行账务处理。
4、前台打印收费凭证以及交易凭证。
5、前台收费显示界面收费来源有两种选择:现金或转账。当选择现金时,后台实时记账并等于收费登记簿。当选择转账时,收费模块判断是否为签约客户,假如时签约客户,只登记收费登记簿,不实时收费。假如不是签约客户,系统实时收费。
日终自动扣收手续费考虑
1.目前日终自动扣取费用是逐笔扣取，若当日余额不足扣，则往后每天都尝试扣取。对于客户的明细来说也是单笔。
2.可以改为按费率种类汇总收取，客户明细帐的笔数与费用种类相同，收费明细不按费用种类汇总，可以打印具体的费用明细。
3.因为对于未扣的费用以后每天都会扣取，可以打印当日未扣成功清单供柜员留意。同时，不按所有费用总额判断余额是否足扣，按费率种类汇总额判断是否足扣。
费用计算
系统费用计算模块根据预先对收费的定义完成对各项费用的计算,不同的费用计算方法定义在专门的费率参数配置中,计算方式如:固定金额,按交易金额比例等,所有的计算方式最终汇总为收费模块的核心知识库,后续对任何服务的收费定制均根据这些标准规则计算各项费用,确定费用核算方式,以及费用发生机构等等。
服务收费配置
如果某项服务需要收费,则需要定义交易收费标准。系统可根据交易中不同产品、不同客户种类等级、不同服务方式、不同的渠道,定制相应的费用标准。为了保持系统的可扩充性,在收费定义中也预留了额外的接口。
批量调度
日终周期调度模式采用批次式管理,以多进程并发处理的方式充分利用主机的各种资源,以期望最大程度提高日终批处理的效率。整体思路如下图所示:
image.png
批量调度概述
为提高日终批量业务处理的性能,对日终批量业务采用并发的方式进行处理,同时,为提高日间联机业务处理性能,简化日间联机交易负责程度,在不影响业务完整性的前提下对联机业务进行适当拆分,将日间部分处理转化为与联机交易并行的跟随处理。
平台设计主要针对这两种目标进行描述。
支持业务处理形式
批量调度平台提供对以下业务处理进行调度的功能:
1、日终周期业务
提供对日终自动账务处理、日终清算、日期切换、总账处理、报表生成等业务进行启动、控制及执行的调度;
2、日间联机批量业务
提供对日间联机发生的批量处理业务的异步处理调度,如代发工资、批量代收费业务等;
3、日间联机业务的跟随处理业务
提供对日间联机发生的实时业务的后续处理(Follow Transaction)的调度,如日间异步清算处理、日间异步分录汇总处理、日间异步产生统计数据处理等:
4、定期数据整理
后台服务提供对定期环境整理、定期清理数据、产生历史数据等处理的调度。
技术结构
系统批量调度从技术上分为四个层次:应用业务层、应用主控层、平台控制层、和应用运行层。平台提供支持的是平台控制层、应用主控层,应用运行层环境由平台提供。
1、平台控制层:为各类需批量运行处理的业务提供运行环境的初始化处理及伺服机制,即触发作业运行入口,将批量业务处理作业根据作业类型提交到对应的运行环境运行,并提供作业提交的控制。各业务类型伺服机制统一;
2、应用主控层:为各类需要批量运行处理的业务提供对平台伺服作业的触发,各业务类型分别具有各自的应用触发接口;
3、应用运行层:提供批作业运行环境,根据平台定义参数初始定义:
4、应用业务层:包含应用处理,由应用开发人员根据业务要求自行编写处理;
image.png
技术要点分析
1、伺服机制的提供及批处理平台的运行触发在主机进程间控制采用DataQ做为做为进程启动渠道,平台作业控制进程监控DataQ,应用主控将具体应用作业信息传送至DataQ进行作业运行触发。平台伺服进程采用预启东的方式。
2、批处理作业使用资源的控制
通过对主机子系统及JobQ使用资源、运行优先级、允许活动作业数等的限制,对批处理作业使用资源进行控制,联机子系统、各类批量处理子系统考虑分别建立,以平衡会系统资源的使用。
3、日终批量业务处理的运行模式
(1)建立日终批量处理运行计划表,该表数据由批量运行主控依照日终批量处理作业定义内容生成。
(2)日终批量服务控制程序依照日终批量处理运行计划表内容提交作业至批量处理提交数据队列,并接收作业运行结果进行后续处理。
4、联机批量业务处理的运行模式
(1)建立联机批量处理运行定义表及联机批量处理运行结果表。
(2)日间联机批量业务根据需要调用日间联机批量主控,将联机作业信息提交至批处理提交数据队列。
(3)由批量应用主控处理作业运行结果。
5、日间联机跟随业务处理的运行模式
(1)建立日间联机跟随业务处理定义表及结果表。
(2)日间联机业务根据需要调用联机跟随业务接口,将联机业务类型提交至联机跟随业务服务队列。
(3)联机跟随处理服务主控监控服务队列判断处理并提交作业。
6、定期数据整理业务处理的运行模式
(1)建立定期数据整理处理业务定义表及结果表。
(2)由日终批量服务程序启动定期数据整理主控。
(3)定期数据整理主控根据整理业务定义表内容提交数据整理作业。
批量调度流程
image.png
