银行核心业务系统总体设计.doc

核心系统项目文档 总体设计

核心业务系统
总体设计说明书

目 录
§1 综述 5
§2 系统总体结构 6
§2.1 系统运行环境 6
§2.2 系统网络总体架构 7
§2.3 应用逻辑结构 8
§3 核心系统技术结构 9
§4 综合前置系统构架 10
§5 系统设计总体目标 11
§5.1 技术设计思想 11
§5.1.1 三层结构，从面向交易过渡到面向客户、面向服务 11
§5.1.2 全面贯彻以客户为中心的设计思想 11
§5.1.3 多渠道接入平台系统的采用 12
§5.1.4 银行服务形式“产品化”及产品定制 12
§5.1.5 服务模块组织“构件化”、“构件封装”及构件驱动平台 12
§5.1.6 “引领式”操作模式、流程定制及流程再造 13
§5.1.7 批处理控制平台，增强批处理的并发程度，缩短批处理的时间 13
§5.1.8 标准的外部系统接口 14
§5.2 业务设计思想 14
§5.2.1 一体化的会计核算体系及核算主体定义 14
§5.2.2 支持全天候“7X24小时”不间断营业 14
§5.2.3 支持多分行，支持多级清算 15
§5.2.4 “全功能柜员” 15
§5.2.5 客户信息集中，统一的客户授信体系，实行额度管理 15
§5.2.6 加强了内控体系，强化柜员权限管理，完善的系统安全性和灵活的交易授权机制 16
§5.2.7 灵活的计息模块，支持“利率市场化” 16
§5.2.8 灵活的收费模块，支持银行自主地制定收费政策 17
§5.2.9 提供“以客为尊”的一站式服务 17
§5.2.10 合理利用计算机优势，减轻业务人员的工作量 17
§6 系统功能要点逻辑设计 18
§6.1 运行平台和交易组装 18
§6.1.1 核心交易平台的总体结构 18
§6.1.2 核心交易平台设计要求 18
§6.1.3 核心构件库的组成 21
§6.1.4 构件形成及使用原则 21
§6.1.5 交易驱动设计结构 22
§6.1.6 交易驱动设计要求 23
§6.1.7 交易驱动实现方法 24
§6.2 报文接口及拆组包 31
§6.2.1 主报文格式 31
§6.2.2 系统拆包流程 31
§6.2.3 系统组包流程 31
§6.3 操作流程定制 33
§6.3.1 操作流程定制设计构架 33
§6.3.2 操作流程定制设计要求 34
§6.4 分录接口设计 35
§6.4.1 分录接口模式 35
§6.4.2 设计准则 35
§6.5 总账设计 37
§6.5.1 总账设计结构 37
§6.5.2 核心总账的处理模式 39
§6.5.3 总账汇总口径 40
§6.6 帐务体系 42
§6.6.1 帐务结构 42
§6.6.2 帐户设置 42
§6.6.3 建立以“款项”管理为基础建立综合账务管理体系 44
§6.6.4 内部账户体系 45
§6.7 产品化模式 47
§6.7.1 设计目标 47
§6.7.2 产品分类 47
§6.7.3 产品结构设计 47
§6.8 7×24小时营业设计 49
§6.8.1 不间断营业设计架构 49
§6.8.2 7×24小时营业任务序列 50
§6.8.3 7×24小时营业设计要求 51
§6.9 统一冲销模式设计 52
§6.9.1 实现方式 52
§6.9.2 反交易的编写 53
§6.9.3 存储过程调用 54
§6.10 权限管理 56
§6.10.1 设计思路概述 56
§6.10.2 交易权限设计 56
§6.11 复核模式设计 64
§6.11.1 概述 64
§6.11.2 表结构 65
§6.11.3 记帐录入流程 67
§6.11.4 复核流程 67
§6.11.5 后台接口 68
§6.11.6 复核权限控制 69
§6.12 收费设计 69
§6.12.1 公共收费流程 70
§6.12.2 费用计算 70
§6.12.3 服务收费配置 71
§6.13 清算模式 71
§6.13.1 清算系统结构 71
§6.13.2 清算系统与其他各系统之间关系 73
§6.13.3 核算模式及术语解释 74
§6.13.4 数据结构设计 74
§6.13.5 应用接口（ClsMainApi） 76
§6.14 批量调度 78
§6.14.1 运行周期交易调度 78
§6.14.2 周期交易录入 79
§6.14.3 生成周期调度方案 84
§6.14.4 周期调度运行 86
§7 业务功能组件划分 92
§7.1 100000-客户服务 92
§7.1.1 110000-客户信息 92
§7.1.2 120000-存款业务 93
§7.1.3 130000-贷款业务 97
§7.1.4 140000-结算业务 100
§7.1.5 150000-外汇买卖 103
§7.1.6 160000-债券业务 103
§7.1.7 170000-银行卡业务 105
§7.2 200000-柜台零售 108
§7.3 300000-内部运营 108
§7.3.1 320000-内部账管理 108
§7.3.2 330000-现金管理 109
§7.3.3 340000-凭证管理 110
§7.3.4 360000-系统内资金上存借调 111
§7.4 500000-交易工具 112
§7.5 600000-内部管理 114
§7.5.1 640000-机构管理 114
§7.5.2 650000-柜员管理 114
§7.5.3 660000-业务量管理 115
§7.6 700000-业务咨询 115
§7.7 800000-代理业务 116

§1 综述
在全面覆盖传统银行业务的基础上，突出“金融产品”概念，银行可方便定制新的业务品种或更改业务模式；系统整合了银行的业务服务渠道，方便银行增值服务范围的扩展，在无须更改系统内核的情况下方便实现与外部系统的互联互通。系统在深化“大集中”、“大会计”、“一本帐”、“以客户为中心”、“综合柜员制”等成熟的设计思想的基础上，建立了从“客户”、“产品”到“服务”、“渠道”的集约化经营管理模式，提供了真正的面向客户的服务模式，作到了为客户定制差别化的服务。从而实现了银行集中经营、规范业务、个性服务、丰富渠道、减少风险、辅助决策、降低成本的目标。
系统实现原则满足了银行业务系统所要求的：先进性、实时性、可靠性、完整性、安全性、网络化、开放性、易扩展性、易维护性、易移植性。

§2 系统总体结构
§2.1 系统运行环境
l 主机/操作系统
HP UNIX 或 IBM-RS6000 AIX

l 前置机/操作系统
HP UNIX 或IBM-RS6000 AIX

l 数据库
INFORMIX 或DB2

l 中间件
CICS 或TUXIDO

l 网点前台
PC SCOUNIX

l 应用数据维护服务器
PC SERVER Windows2000/XP TOMCAT（或WEBSPHERE）
通过IE登录访问

§2.2 系统网络总体架构

§2.3 应用逻辑结构

应用系统逻辑结构

§3 核心系统技术结构

§4 综合前置系统构架

§5 系统设计总体目标
§5.1 技术设计思想
§5.1.1 三层结构，从面向交易过渡到面向客户、面向服务
系统设计分为三层结构：核心管理层、应用服务层和服务渠道层。核心管理层是整个系统的数据中心，存放着客户信息数据、总帐会计数据、公用信息数据，控制信息数据等，负责会计核算、客户信息管理、授信额度管理、资金清算管理、费率管理、机构管理、库房管理和公共数据管理等；应用服务层由存款系统、贷款系统、结算系统、卡业务系统、中间业务系统、资金市场系统、外汇市场系统等应用系统组成，分别完成银行对客户的各种不同服务手段；通过多渠道接入平台系统连接着各种各样的服务渠道，包括柜员界面、客户经理界面、ATM、POS、电话银行界面、自助银行界面、网络银行界面等，是核心业务系统的客户界面，是银行柜台业务的延伸。
这样的层次结构划分，可以使得系统的数据更加集中、更加安全，使系统的核心尽可能的坚固和稳定；可以使得系统对客户的应用服务更加具有可拓展性，满足市场快速变化和银行因应增加服务品种的需要；可以使得系统支持的服务渠道更加广泛；从而达到由以前的面向交易过渡到现在的面向客户、面向服务的目标。

§5.1.2 全面贯彻以客户为中心的设计思想

建立具有深度和广度的关系型客户信息中心，降低银行的客户风险；为实现更高级的客户管理方式（如客户信用等级制度的建立），为实现客户分析提供了全面基础信息。采用面向客户提供差别化服务的设计思想，根据来自客户经理的分析资料及时地给操作人员以客户关怀提示或风险预警；根据管理分析系统提供的客户等级评定接口、根据产品定价系统提供的客户优惠价格接口在核心系统中提供个性化服务及控制。

§5.1.3 多渠道接入平台系统的采用

系统采用了多渠道接入平台VisionBanking MCP来完成各种终端设备（字符终端、图形终端）和自助服务设备（ATM、POS、电话银行、手机银行、自助银行、网络银行等）的接入、管理功能。系统能够支持各种通信协议，提供全辖的网络监控、设备控管和应用监控，能处理各种各样的数据报文格式，具有强大的功能扩展性、严格的安全控制机制。

§5.1.4 银行服务形式“产品化”及产品定制

在核心业务系统的设计中，引入了“银行产品”的概念。银行所提供的服务是以产品的形式出现的，系统中把所有经办的存款、贷款等业务根据业务的属性、业务的主要组成要素按照业务流程的不同阶段分层次制定相应的处理计划，根据各处理计划的不同组合灵活地定制产品，并分配相应的产品代码进行唯一的标识。银行业务“产品化”的优点在于让最终用户（而非IT人员）更灵活地根据市场需求定制有自身特色的银行产品，满足不同客户群体的需要，快速适应市场的变化。

§5.1.5 服务模块组织“构件化”、“构件封装”及构件驱动平台

核心业务系统对交易服务的设计基于“构件化”的模式，本着“降低耦合”“功能内聚”的原则，将业务处理功能划分为完成某一具体功能的最小单元，形成“积木”式构件库，这些构件可以以一定形式按照要求搭建在一起形成完成某一业务功能的“组件”，每项交易服务均由“构件”及“组件”依据一定次序的集合组成，完成一项交易服务对构件的组装过程称为“交易封装”，这些组装过程是由填制配置脚本来实现的，而无需单独编程。
已经封装的交易服务通过系统提供的“构件驱动平台”统一驱动。
提高业务处理程序（构件）的共享；可以灵活地进行构件的组织而定制出新的交易服务，缩短了新服务功能推出的时间；减少了系统维护的工作量。

§5.1.6 “引领式”操作模式、流程定制及流程再造

系统可以通过前台的操作流程定制，实现“引领式”的操作模式。对核心业务系统联机交易操作的过程细分为具体的单一步骤，为每个步骤用一个唯一的步骤编号进行标识，其中每个步骤都包括其独立的必须的输入输出项目，柜员交易就是通过将步骤编号按照一定顺序有条件地组织在一起而形成，而组装的过程只需要简单地配置相应的脚本，不需要编写代码，这样，根据不同的业务要求，可以灵活地对操作流程进行重组，以实现流程的定制和再造。同时，由于每个操作步骤本身的产生都是通过工具定制的方式，对于新的原来没有的操作描述也可以方便地扩充。
这种流程定制的方式使前端交易体现出人性化的特色，能够方便地制定出符合操作人员习惯的流程及界面风格，临柜人员的操作可以不再是呆板的录入、提交产生结果，而是通过人机交互的模式引导操作人员逐步达到完成交易服务的目的。

§5.1.7 批处理控制平台，增强批处理的并发程度，缩短批处理的时间

系统将批处理业务（例如：日终批处理、批量结息、预提利息、年终结转等）分成若干个处理模块，每个处理模块都以作业方式运行；相同功能的作业放入同一个队列中，队列内顺序执行；不同功能的作业放入另外的队列中，不同的队列之间是并行执行的，互不影响。由批处理控制平台来完成作业的提交和作业执行顺序的控制，作业之间的制约关系也可在平台中进行预先的定义。
这样安排批处理业务，有效地增强了批处理的并发程度，使系统资源得到很大的利用，减少了批处理的时间。

§5.1.8 标准的外部系统接口
系统提供了标准的外部系统接口，能够方便地与其他系统（如同城清算系统、电子联行系统、人行现代化支付系统、证银转帐系统、银联系统、代理业务系统、国际结算系统等）进行接口。

§5.2 业务设计思想

§5.2.1 一体化的会计核算体系及核算主体定义
系统采用大会计模式，实现了对公、对私一体化，本币、外币一体化，自营性会计和政策性会计一体化，多币种、多帐套的会计核算方法，实现了会计核算集中和应用系统的统一。
系统支持核算主体上移的“一本帐”模式。“一本帐”模式有利于银行简化资金调拨流程，实现精细核算，推行专业化和扁平化管理，达到增加利润、控制成本、强化绩效、提供决策的目的。这是一项系统工程，不仅需要观念更新，还需要机构更新、制度更新。所以在实际执行过程中，要循序渐进，逐步实施。例如：有些银行尝试采用核算主体逐步上移的方式，先实现，可以以支行为一本帐，实现同一支行辖内的各网点之间资金的通融，改变了旧系统中支行辖内网点之间频繁的资金清算。因应此种情况，系统支持系统内任意级别的核算主体上移，可以将核算主体定义到任意级别层次的机构。

§5.2.2 支持全天候“7X24小时”不间断营业
核心业务系统支持“7X24小时”不间断营业，不仅包括ATM、POS、电话银行、网上银行等自助设备，也支持营业网点不间断营业，实现“夜间银行”，保证对客户服务渠道的畅通，满足各地区不同的服务时间要求，实现全天候的变现能力。

§5.2.3 支持多分行，支持多级清算
单一系统支持多分行的运作，把多个分行的业务数据集中到一个数据库中；支持从总行到省行到分行到支行网点的多级清算，全面的支持“大集中”的目标；系统也支持跨系统的清算。系统对于清算支持可定义的清算模式，在系统中提供独立的清算系统进行清算支持，以清算路径、资金帐户、清分方式等为主线，对清算流程及方法进行拆分后实施组装，来确定具体的清算种类，按照清算种类实现系统的自动多级清算，同时通过定义清算模式可以支持实时清算和日终批量清算。

§5.2.4 “全功能柜员”
系统满足了全行实行综合柜员制的需要，由柜员直接负责每笔业务的全过程，在权限允许的范围内，不分业务种类，顾客可以选择任意一个窗口办理所需的全部业务。为今后实行“客户经理”的服务奠定了基础。采用综合柜员制有如下优点：提高工作效率；减少柜员人数；提高员工素质；方便客户；改善服务质量；方便绩效考核。
同时，考虑到国内的实际情况，系统也支持传统的柜员管理方式。
§5.2.5 客户信息集中，统一的客户授信体系，实行额度管理
客户信息集中管理，使银行可以综合掌握客户状况，以便提供全面的客户追踪和决策分析手段，如资信评估、风险评估。也可以为客户提供全方位多功能的代客理财服务。
系统通过额度管理功能，根据客户的信用情况，给客户分配一定的额度，决定为客户提供的某些业务服务的范围和程度，使银行降低为客户提供某些服务而带来的风险；同时，银行也可以根据自身的情况，通过额度管理系统决定本身所进行的一些业务的范围和程度。
§5.2.6 加强了内控体系，强化柜员权限管理，完善的系统安全性和灵活的交易授权机制
系统加强了内控管理，突出了安全保障意识，系统中对业务监督方面倡导的思想是尽可能规避风险的发生，及时发现经办风险，减少因业务监督产生的银行运营成本。系统中强化了柜员管理的力度，采用柜员操作权限控制、授权、双敲复核与事后复核等方式综合控制的模式。
对柜员操作权限提供灵活的参数化管理，建立严格的柜员类别与等级管理体系，从柜员经办交易、客户类别和等级、经办金额等多种角度控制柜员的经办权限。
对柜员经办业务加强授权、复核与监督，系统提供了即时授权、异步授权等多种授权模式，业务办理期间突出的风险点可通过授权的方式规避风险；业务管理部门也可采用系统提供的双敲复核的方式减少操作风险，同时考虑操作工作量，采用大额授权、超大额双敲复核的方式进行管理规划，也可以采用事后复核的方式，对规定金额的业务进行逐笔核对，确保在最短时间内发现风险。

§5.2.7 灵活的计息模块，支持“利率市场化”
核心业务系统中，对于利率的管理采用利率指标的方式管理，并考虑对于利率市场化后银行能够对利率的浮动进行有效的控制，在利率指标中按实点浮动及百分点浮动分别设定浮动上下限。
同时，为了使系统计息方式更为灵活，更能适应银行利率政策的变化，系统采用利息计划的理念，按照不同业务种类设定利息计划参数；目前系统的利息计划制定兼顾了国内及国外的多种计息模式：支持全额计息、分段计息、金额分档计息、按利率调整周期计息等；可定义成本核算时机：先预算、后入帐等。在每个业务种类中对于不同的产品可以采用不同的利息计划，业务部门可以根据业务发展需要开发新的产品时，制定相应的利息计划。
系统内部设计中，考虑利息计划使用的灵活性和可扩展性，改变了原来单一的积数法计息模式，采用计息明细的方式，使利息的计算入帐等动作独立于帐务系统之外，便于计息模式的扩充。
§5.2.8 灵活的收费模块，支持银行自主地制定收费政策
核心业务系统提供统一的收费模块，在系统中设置费率种类及使用“费率种类”的“收费计划”，以费用的计算方式、收取方式、核算方式、收费时机及控制方式等信息设定费率种类，并可按照客户的类别级别、产品、服务、渠道等要素制定相应标准的收费计划。
§5.2.9 提供“以客为尊”的一站式服务
客户到柜台办理业务以用身份证件或帐号登录系统的方式，系统根据该客户的类别和级别和帐户性质提供特定交易供使用；从开始到退出，控制客户交易范围，全程记录客户交易的全过程，统一提供交易确认凭证。
§5.2.10 合理利用计算机优势，减轻业务人员的工作量
系统具有友好的用户界面，可根据客户和柜员定制不同的功能菜单，新推出的浏览器前台还具有个性化工作界面配置和信息沟通等功能，便于柜员的操作；针对特定业务设计交易，增大主机统计数据存储，减少大量的手工帐簿；大量的机制凭证由主机统一定义管理，自动打印；会计分录也由系统自动完成；批量处理采用批处理控制平台自动提交作业，大大提高了主机资源的利用率，缩短了主机批处理时间，减少了主机操作员的工作量。

§6 系统功能要点逻辑设计
§6.1 运行平台和交易组装
§6.1.1 核心交易平台的总体结构
逻辑网络
信息存储
信息展现
交易驱动
报文拆组
通讯传输
交换控制
控制信息
前台信息流程
功能展现
通讯传输
信息存储
控制信息
交换控制
报文拆组
交易驱动
后台信息流程

§6.1.2 核心交易平台设计要求
1、 信息展现模块：实现信息的录入和输出，实现对屏幕及各种设备的控制。
l 包括对多种设备的支持，如屏幕（键盘）、磁盘、网络、磁条读写器、打印机（各种型号存打、行打）、密码键盘、IC卡读写设备等，同时需支持各种设备复合使用情况。
l 实现对信息的多种展现形式，包括交易响应信息如正常应答信息（可能多条）、提示信息（可能多条）、拒绝信息（可能多条）、授权信息（可能多条）、复核信息等的支持，也包括多页式查询返回的信息、返回的多条编辑信息、带格式文本信息等。

2、 交易驱动模块：实现原交易的启动、已定制交易联动流程的控制。
l 实现原/子交易联动控制；
l 实现字段启动交易的控制；
l 实现子交易本身为原交易（组交易）的控制；
l 实现自动启动现金、凭证打印、收费等公用模块组交易的控制；
l 需要评估系统灵活性与系统效率之间的矛盾。

3、 报文拆组模块：实现对应用收发的报文进行组织和拆解，组织后的报文供通讯收发，拆解的报文供应用使用。
l 对报文格式的支持：支持自定义报文格式、ISO8583报文格式、类ISO8583、类HTML等；
l 也可考虑应用系统内采用统一的一套内部报文格式，对外提供多种格式支持；
l 支持同一交易返回多条不同格式报文的处理；
l 对报文定义的支持：前后台统一定义一套报文格式；
l 需要考虑拆组的效率和通讯数据包的精简。

4、 交换控制模块：完成路由分捡、多服务器信息交换功能。
l 对于前台模块支持子交易/字段启动交易级别的个性路径选择；
l 对于后台模块同时考虑对多个分布在不同主机上的独立系统实现集中清算模式的支持；

5、 通讯传输模块：完成通讯传输的功能。
l 支持多中通讯协议，如TCP/IP、SNA等；
l 支持不同交易采用不同的通讯协议；
l 支持通讯报文的加密/解密；
l 支持通讯报文的校验，如MAC码；
l 不论前台还是后台，均需支持主动/被动通讯模式；

6、 功能展现模块：完成真正的具体交易功能，本着提高功能内聚、降低模块耦合的原则进行结构划分，由核心构件资源库及组装交易所需的接口模块组成。处于应用级别，不属于平台范畴。

7、 信息存储模块：
l 需要考虑不同交易数据的信息隔离；
l 需要考虑同一原交易下交易数据的信息共享；
l 需要考虑部分特定类型信息的历史数据存储，如凭证打印信息；
l 临时存储的数据实现自动清理。

8、 控制信息的定制：此处所指的控制信息，包括菜单定义、交易定义、屏幕定义、数据字典定义、通讯传输格式定义、授权信息定义、提示信息定义、列表定义、打印格式定义、输出信息格式定义、设备定义等以及其他平台所需的控制信息。
l 各种与具体交易相关的控制信息的定义数据可以以交易为主线进行卸载和安装；
l 定义的控制信息需要满足系统性能上的要求，既保证系统开发的灵活性，又保证访问的快捷，以确保系统整体运行效率。

9、 特殊交易的实现
统一的当日冲销（抹帐）模式
统一的双敲复核模式
统一的授权模式
统一的事后复核模式
前台外挂交易的实现
后台直通式交易的支持

§6.1.3 核心构件库的组成
核心构件库由两部分组成：子交易、API。
其中每个子交易由四部分组成，子交易可大致分为五类：帐务类、事物类、查询类、数据准备、组合类。
API可大致分为三类：帐务类、事物类、查询类。

§6.1.4 构件形成及使用原则
l 每个业务系统包含的内容，由各自提供的核心子交易、API及相应的独立对外展现交易组成；
l 每个业务系统都有其独立的数据库体系，相互之间拒绝数据库的直接访问，确保数据文件的隔离。对于联机交易，如需使用其他系统的数据，通过联动子交易或调用对应系统提供的API实现。对于后台批量交易，少量数据交易采用API调用方式，大量数据处理则采用对应系统提供的接口文件方式由相应的系统进行处理，在7X24模式下，大量数据处理也可以采用API方式；
l 核心业务系统功能由各个业务系统提供的核心构件资源库中相应的构件（子交易、API、接口数据文件）进行组装定制而成，任何系统提供的构件中都只包括对其自身系统功能的处理和数据库文件的操作，核心构件的划分，按照各业务系统提供的具体服务类别划分，具体的划分不在此处详细描述；
l 根据具体业务特点，各系统实现帐务一体化，客户类别、币种类别、帐务类别、做为具体业务系统的属性出现，从数据结构底层实现一体化，只区分不同服务功能，对于同一种服务功能以单一交易处理，对于前台，交易组装时对部分交易要考虑可操作性，以引领式模式实现。

§6.1.5 交易驱动设计结构

通讯传输
报文拆组
交换处理
交易驱动
交易输出空间|多格式存储
。
。
。
多条存储
。
。
。

。
。
。

原交易空间
共享空间
子交易空间
联动入口
联动入口
联动入口
子交易
子交易
子交易
联动出口
联动出口
联动出口
图中兰色单线箭头方向表示信息的流转方向
原交易出口
子交易输出

§6.1.6 交易驱动设计要求
1、 做到原交易空间、子交易空间、共享空间信息的独立性；
2、 交易输出空间为整个原交易共享，信息可能为多格式，考虑其中存储访问的条理性；
3、 各个级别层次的交易模块都由交易驱动主控统一驱动；
4、 如果某个子交易本身为组交易，基于组交易本身既是独立的原交易，需考虑联动过程中对原始原交易空间和原始共享空间数据的保存和恢复；
5、 交易联动组装实现主要是通过联动入口和联动出口的编制完成的，对于交易入口，一般可通过定义启动条件和参数转换规则的定制方式来实现，不需要编写入口程序，如有特殊情况，则也可以通过编写新的子交易，通过联动出入口或子交易输出子交易输出空间实现，考虑未知情况，在平台中保留通过入口函数启动子交易的控制；
6、 可考虑在平台中支持公共启动交易的参数化定制；
7、 在交易输出空间信息发送前台前，进行平台统一的信息检查和整理处理，如统一授权产生、事前复核、交易平衡性、信息的优先级处理等。

§6.1.7 交易驱动实现方法
根据具体的业务功能需要，选择性地将一系列的子交易和API组织起来，通过定义组装的方式联动在一起，构成一个原交易。
下图以柜台归还贷款为例来说明：

每个子交易我们称为PU，每个原交易称为MU，驱动规则称为RuleSet，驱动主控称为TPloader。

§6.1.7.1 数据关联

对每一交易调用过程，WU、PU、RuleSet之间共享一个全局的数据空间(DataPool)。

DataPool的形式

存储方式

DataPool使用全局内存变量的方式进行数据的存储，在一个交易执行过程中不会释放，其大小可随时增加。

数据结构

DataPool采用HashMap(散列表)的存储方式和数据提取算法。

数据区域

DataPool划分为公共区域(PubArea)和共享区域(ShareArea)两大块，其中公共区域存放系统流水号、系统日期、交易号、输入报文等全局信息，共享区域存放个WU、PU之间需要交换的中间数据或输出数据。

DataPool的生命周期

创建

DataPool由TPLoader创建，并进行初始化， TPLoader应提供相关的操作函数进行DataPool的访问。

使用

在TPLoader执行一个脚本，即完成一个交易的过程中，除了各个功能单元的自有变量外，所有的需要传递的数据都通过DataPool进行存储。DataPool根据名字匹配的相关规则和算法提供数据的调入、调出。DataPool的大小是变化的。

释放

DataPool由TPLoader进行释放。

DataPool与其他模块的关联

DataPool是整个交易过程的数据调度中心。任何需要交换或存储的数据都通过DataPool进行，各个模块通过DataPool的接口进行数据处理。

条件规则
一.1.1.1.1.1.1.1.1 RULESET

交易主控
一.1.1.1.1.1.1.2 MU

Name Value DataType
Name Value DataType
………
Name Value DataType

流程单元
一.1.1.1.1.1.1.3 WU
DataPool
工作单元
一.1.1.1.1.1.1.4 WU

§6.1.7.2 交易调度、组装过程

交易调度的实现由TPLoader根据交易联动表的配置，根据RuleSet的相关条件与逻辑，并结合交易环境的具体形式，调用PU与WU，以实现完整的交易流程实现业务。TPLoader的对条件逻辑的判断、对PU的调用、对WU的调用，通过Assemble层提供的接口实现组装过程。在整个调度过程中的数据存储和共享通过DataPool及其相关的接口完成。

TPLoader的调度过程

启动TPLoader

TPLoader作为一个PG（在CICS环境下），当CICS接收到请求报文后，根据ServiceName启动TPLoader。当TPLoader与不同的PU、WU绑定时，对应与不同的Service。

TPLoader载入交易配置

TPLoader将对应的配置载入，并进行自身的初始化处理。

根据交易配置表中的内容进行预处理

根据交易配置表中内容，进行相关的交易预处理如检查、报文解析、获取流水号、获取系统日期等。

进行交易处理

根据交易联动表的内容和逻辑判断条件调用PU或WU进行交易处理。

进行异常处理

若功能处理异常或其他不确定情况，进行特定的异常处理。

根据交易联动表中的内容进行结束处理

根据交易配置的内容，进行相关的交易结束处理如打包、提交事务等。

结束TPLoader

流程结束，并释放资源。

交易联动表的作用方式

系统通过交易联动表的配置作为执行交易过程的定义。在交易联动表中体现交易过程中的功能和执行条件规则。在集成基本的PU和WU及RuleSet功能的前提下，通过交易联动表组装交易。

交易联动表与其他模块的关联

交易主控
一.1.1.1.1.1.1.4.1 TPLoader
条件规则
RuleSet
工作单元
WU
数据池
DataPool

交易代码 ****
工作单元 ****
执行条件 ****
联动属性 ****

Load MU

交易联动表

数据的分类和交换方式

TPLoader的私有数据

TPLoader的私有数据包括，当前调用的MU 、PU、WU名称，Script中的变量等。这些变量以特殊的标记存放在DataPool中，一般有TPLoader进行使用或提供特殊接口为各模块使用。

交易的公用数据

在一个交易过程中一般不变的，各个模块、工作单元需要使用的公共数据，如流水号、系统日期、请求报文数据等。这些数据在整个交易过程中，供各模块和功能单元调用获取信息，一般不能改动。

共享数据

对于个工作单元、流程单元、条件规则功能模块需要互相交换、共享、存储的数据，通过DataPool进行。数据的名称转换、存储、提取、数据预处理等通过DataPool提供的接口和相关的配置数据库进行。

TPLoader的生成方式

TPLoader的主程序只有一个，将TPLoader与不同的交易流程和功能单元绑定在一起就可以实现多个可供调用的、实现完整交易功能的可执行体（TPLoader1、TPLoader2、……TPLoadern），通过不同的TPLoader通过调用不同的脚本实现不同的交易功能。

同时TPLoader的功能实现还需要TPCommon、DataPool、Assemble、RuleSet等模块的支撑功能，因此TPLoader的生成过程还需要绑定这些基本库。

由于使用函数指针的方法调用相关的工作单元，因此，对于每一个具体的TPLoader的生成过程，需要载入不同的头文件和获取函数指针的函数，以完成函数名称与函数指针的映射关系。

§6.2 报文接口及拆组包
§6.2.1 主报文格式
采用类HTML格式，使用Key＝Value方式(散列表)描述数据，对Key使用“< >”进行标注。针对核心交易平台，采用这种报文结构的优点在于：
l 增强报文适应能力；
l 适应报文的灵活可扩充；
l 方便报文数据提取；
l 提高系统的可调试能力。

§6.2.2 系统拆包流程
根据交易报文头信息进行如下处理：
l 从原交易定义表中根据交易代码读出MACChk标志，决定是否进行MAC检查；
l 如果需要MAC检查，调用HSM提供的API进行MAC检查；MAC检查出错，返回前台提示信息：MAC出错；
l 根据交易代码检索交易字典(TranDataDic)，根据交易字典定义表，进行报文解包。如果交易字典定义的是’M’信息，报文中必须上传。没有上传，返回前台提示信息：必要的输入信息不全；
l 根据KEY值解包。

§6.2.3 系统组包流程
l 根据交易代码检查交易字典（TranDataDic）,根据交易字典定义表，找出KEY；
l 根据KEY，查询交易输出数据定义表(MUOutData)，根据交易输出定义表内容组织数据；
l 根据MACChk标志，调用HSM提供的API进行MAC计算；

§6.3 操作流程定制
§6.3.1 操作流程定制设计构架
交 易 主 控
某 个 子 交 易 处 理
屏幕入口
屏幕处理
屏幕出口
复核授权
本地交易处理
交易签名
交易上传
交易下传
信息转换、分析、存放、处理
输出处理
交易出口
交易入口
字段入口
字段处理
字段出口

SERVER
柜 员
处理函数
输出设备
交换处理
交易动态使用空间
交 易 定 义
数 据 字 典
交易
菜单
屏幕
字段
上传信息结构
下传信息结构
授权复核
输出格式
配 置 定 义

§6.3.2 操作流程定制设计要求
1、 交易入口主要完成交易的启动条件判断和交易入口参数赋值，正常情况下不需要编写函数，而是通过启动条件定义和入口参数映射的定义实现定制；
2、 屏幕入口、字段入口的实现同交易入口的实现模式；
3、 为实现开发过程的定制，必须采用统一的数据字典；
4、 平台提供自动启动子交易的应用定义，而不是将个别功能集成在平台中，应用只需定义入口/出口；
5、 实现交易权限定义的灵活性，通过柜员类别/级别、客户类别/级别、交易类别/级别、菜单类别/级别控制显示和操作，实现个性化菜单定制；
6、 实现凭证格式的共用，建立凭证格式库，提供凭证输出的统一接口，提高凭证格式的复用率，并实现事后凭证的重复打印功能；
7、 用定制方式实现前台列表信息的动态显示，避免编写函数；
8、 授权模式统一，前台可以实现简单的授权定义，需将授权信息统一存储在后台，便于统一管理授权记录；
9、 提供集成在运行平台内的终端间、结点间消息通知功能，便于下一步实现工作流程定制；
10、 支持子交易循环启动、原交易循环启动；
11、 支持菜单项目的出入口执行交易功能，实现真正面向客户的设计模式，按照客户类别、级别等控制信息实现对不同客户允许执行交易的控制；
12、 支持当日冲销、复核、事后复核、异步授权等特殊交易模式；
13、 支持前台平台外挂其他交易系统。

§6.4 分录接口设计
§6.4.1 分录接口模式

总帐报表

总

帐

分录流水

分录接口
分录代码定义
子交易
交易分录代码
联动交易信