银行金卡前置系统的设计与实现

银行金卡前置系统的设计与实现 目 录 摘 要 ..................................................................................................................... I ABSTRACT ............................................................................................................ III 第1章 绪论 ............................................................................................................. 1 1.1系统开发背景 ............................................................................................................... 1 1.2 国内外研究现状 .......................................................................................................... 2 1.3 解决的主要问题 ........................................................................................................... 2 1.4 本文的主要工作 ........................................................................................................... 3 1.5 论文的组织结构 ........................................................................................................... 4 第2章需求分析 ....................................................................................................... 5 2.1总体业务描述 ................................................................................................................ 5 2.2系统目标和解决的问题 .............................................................................................. 6 2.3系统需求分析 ................................................................................................................ 6 2.3.1系统功能性需求 ................................................................................. 7 2.3.2系统非功能性需求 ............................................................................ 11 第3章 系统概要设计 ........................................................................................... 13 3(1系统设计原则 ........................................................................................................... 13 3(2设计思路 .................................................................................................................... 14 3(3 与外部关系 .............................................................................................................. 14 3.3.1 逻辑关系图.....................................................................................14 3.3.2 清分数据流向分析 .........................................................................15 3.3.3 信息数据流向分析 ...........................................................................16 3.4系统技术架构设计 ..................................................................................................... 16 3.4.1 系统的逻辑架构 .............................................................................16 3.4.2 系统的物理架构 .............................................................................18 3.5系统功能架构 .............................................................................................................. 19 第4章 系统详细设计 ........................................................................................... 20 4.1 系统整体结构 ........................................................................................................... 20 4.2 详细设计 .................................................................................................................... 21 i 4.2.1 进程调度详细设计 ...........................................................................21 4.2.2 文件收发详细设计 ...........................................................................25 4.2.3 清分详细设计 ...................................................................................26 4.2.4 数据清理详细设计 ...........................................................................27 4.2.5 直连商户入账详细设计 ...................................................................28 4.2.6 间连商户入账详细设计 ...................................................................29 4.2.7 历史数据生成详细设计 ...................................................................29 4.2.8 文件装载详细设计 ...........................................................................31 4.2.9 错误信息报告详细设计 ...................................................................33 4.2.10 差错处理详细设计 .........................................................................33 4.2.11 模拟客户端详细设计 .....................................................................34 4.2.12信付通商户管理详细设计 ..............................................................34 4.3 数据库的设计 ............................................................................................................. 36 4.3.1数据库需求 .......................................................................................36 4.3.2数据库划分 .......................................................................................37 4.3.3数据库可用性 ....................................................................................39 4.3.4数据库性能 .......................................................................................39 4.3.5数据库容量分析 ................................................................................40 4.4 接口设计 ...................................................................................................................... 41 4.1.1 外部接口 ........................................................................................41 4.1.1 内部接口 ........................................................................................41 第5章 系统实现与测试 ....................................................................................... 43 5.1 系统实现 ...................................................................................................................... 43 5.1.1 商户信息管理 .................................................................................47 5.1.2 终端信息管理 .................................................................................48 5.1.3 直连商户入账 .................................................................................49 5.1.4 信付通商户管理 .............................................................................49 5.2 系统测试 ...................................................................................................................... 60 第6章 结论 ........................................................................................................... 62 ii 参考文献 ................................................................................................................ 64 致 谢 ................................................................................ 错误～未定义书签。65 iii CONTENTS Chinese Abstract ......................................................................................................... I English Abstract ...................................................................................................... III Chapter 1 Introduction ............................................................................................... 1 1.1 Background...................................................................................................................... 1 1.2 Current Status .................................................................................................................. 2 1.3 Main Contribution .......................................................................................................... 2 1.4 Main problems ................................................................................................................ 3 1.5 Contents Organization ................................................................................................... 4 Chapter 2 Requirements Analysis .............................................................................. 5 2.1 Description of Overall business .................................................................................. 5 2.2 Project Goal ..................................................................................................................... 6 2.3 Requirements Analysis .................................................................................................. 6 2.3.1 Functional Requirement ...................................................................... 7 2.3.2 Non- functional Requirement ............................................................. 11 Chapter 3 Construction Design ............................................................................... 13 3(1 Desing aim and Principle ...................................................................................... 13 3(2 Design Ideas ............................................................................................................... 14 3(3 External Relations ..................................................................................................... 14 3.3.1 Logic Diagram ................................................................................14 3.3.2 Sorting Data Flow Analysis .............................................................15 3.3.3 Aanalysis ofInformation and Data Flow..............................................16 3.4 Technology Construction Design .............................................................................. 16 3.4.1 Technology Construction .................................................................16 3.4.2 Logical Construction .......................................................................18 3.5 Functional Construction .............................................................................................. 19 Chapter 4 Detail Design for the System .................................................................. 20 4.1 Overall Structure ....................................................................................................... 20 4.2 Detail Design ............................................................................................................. 21 iv 4.2.1 Process Scheduling .............................................................................21 4.2.2 File Transceiver ..................................................................................25 4.2.3 Sorting ...............................................................................................26 4.2.4 Data Cleaning.....................................................................................27 4.2.5 Direct Connect Business .....................................................................28 4.2.6 Inter-connected Business ....................................................................29 4.2.7 Historical Data ...................................................................................29 4.2.8 Loading Files .....................................................................................31 4.2.9 Error Message Report .........................................................................33 4.2.10 Error Handling .................................................................................33 4.2.11 Simulation of Client .........................................................................34 4.2.12 management of XinFuTong ..............................................................34 4.3 Database Design ........................................................................................................... 36 4.3.1 The Requirements of Database ...........................................................36 4.3.2 Database Divided ...............................................................................37 4.3.3Database Availability ...........................................................................39 4.3.4 Database Performance ........................................................................39 4.3.5 Database Capacity Analysis ................................................................40 4.4 Interface.......................................................................................................................... 41 4.1.1 External Interface ............................................................................41 4.1.1 Internal Interface .............................................................................41 Chapter 5 Implementation and Tesing ...................................................................... 43 5.1 Implementation ............................................................................................................. 43 5.1.1 The Management of Merchant ......................................................47 5.1.2 The Management of Terminal ..........................................................48 5.1.3 Accounted for Direct Connect Business ...........................................49 5.1.4 Management of XinFuTong ..........................................................49 5.2 Tesing .............................................................................................................................. 60 Chapter 6 Conclusions and Prospect ........................................................................ 62 References ............................................................................................................... 64 v Acknowledgment .................................................................. 错误～未定义书签。65 vi 山东大学硕士学位论文 摘 要 近年来，IT技术的迅猛发展使得国内外银行业掀起了大集中的浪潮，各家银行纷纷展开了大集中系统的建设。银行数据集中建设，在业务上，能够为银行建立全行业务的统一视图。在IT建设上，能够通过对系统的集中投入，加快银行系统的建设步伐，提高银行的整体竞争力。银行金卡前置系统是实现数据大集中的重要部分。它主要处理银行和银联之间的交易转发、报文转换以及除核心系统以外的其他业务。金卡前置涉及方面众多，系统复杂，因此本文选取其中的清分清算子系统进行详细分析设计。 本文按照软件工程的流程，对清分清算子系统的相关业务进行需求分析和系统设计。针对系统与用户的特点，控制台形式上采用B/S架构模式，功能上采用多层次的软件架构，技术上采用基于MVC基础的Structs+Spring框架，以java为编程语言，利用XML配置和BO、Hibernate等相关技术，遵循J2EE、EDI/XML、XML Signature、XML Encryption等技术标准实现了清分清算平台的商户信息管理、终端信息管理、直连商户入账、信付通商户管理等功能。后台形式上采用C/S结构模式，采用开放的Unix系统，服务器核心进程均采用多进程并行处理。清分清算平台核心清分模块实现了数据清理、历史数据备份、清分数据、商户入账、文件装载、进程调度、差错处理等功能。控制台与服务器端采用标准TCP/IP通讯，提高系统稳定性和扩展性。在数据库设计中采用了数据分区技术，使得并行技术的使用具有数据基础并且保证了数据的安全性。 本文在银行前置系统的基础上对清分清算的需求进行了描述，并分析了它与外部系统的逻辑关系和数据流向以及系统的技术架构和功能架构。按照配置管理的方式对它的各个核心模块进行了详细的设计。其中信付通属于分行特色业务，为实现数据大集中将其集中到总行。对于数据库，分析了它的容量和性能。本文对系统核心模块与WEB控制台及其内部进程之间的通讯报文进行了详细描述。对于系统实现，我们重点描述了信付通业务中九家分行的验证规则。最后详细描述了系统的测试并给出了测试结果。 目前部分系统已在某银行总行及分行成功上线，并取得了一定的效果。在一定 I 山东大学硕士学位论文 程度上实现了数据大集中，降低了维护成本，提高了银行的市场竞争力。 关键字:金卡;前置系统;清分清算;银行 II 山东大学硕士学位论文 ABSTRACT In recent years，the rapid development of IT technology makes the domestic bank started the tide of centralization, banks have launched the system construction(The bank IT system data centralism construction，in business，can establish a uniform view of all for the bank. In the IT construction，can focus on the investment banking IT systems to accelerate the pace of building, thereby can enhance the competitiveness of the banking system. The Gold Card Front System for Bank is the important part of data centralism construction. Mainly handling forward transactions between banks and CUP ,message switch and other business except for the core system.The system is complicated and involves many aspects ,so the article selects clearing and settlement ,makes a detailed analysis and design. According to the software engineering processes, this paper accomplishes analysis and design of the system. For the user and system characteristics,the console implements many function modules ,for example , merchants information management, terminal information management etc, using B/S architecture model in form , using multi-level software functional framework in function, based on the MVC-based technical Structs+Spring framework . The system uses java as the programming language and uses XML configuration and Hibernate related technologies and follows some standard like EDI/XML, XML Signature，XML Encryption(The background system uses C/S architecture model in form , using unix systems and server Core processes are multi-process parallel processing. The core module implements many functions ,for example data cleaning, historical data backup, clearing data, merchants accounting , file loading, process scheduling, and error handling .In order to improve stability and expansibility of the system ,console and server use standard TCP / IP protocol to communicate.We use data partitioning technology to design the database. Base on the gold front system, this paper describes the needs of clearing and III 山东大学硕士学位论文 settlement ,Analyse the logical relationship with external systems, data flow , the technical architecture and functional structure.In accordance with configuration management, we make detailed designd for each mudule. In order to achieve data centralization,we put anypay in the head office which belongs to branch features. We analyse capacity and performance of the database. we describe communication message that between the core module and console ,as well as between process.We describe validation rule of nine branches about anypay in realization.Finally a detailed description of the system test results are given. Now, part of the system has been used successfully by bank. In a certain degree ,it achieved data concentration, reduce maintenance costs and improve the bank's market competitiveness. Keyword: Gold; Lead System; Sorting liquidation; Banks IV 山东大学硕士学位论文 第1章 绪论 1.1系统开发背景 自从上世纪60年代，第一台商业计算机系统问世后，IT开始以一种置于玻璃房的主机挂终端的形式起步发展。由于较低的附加开销、较低的劳工费用，使整个工业界的趋势走向分布式及部门式管理。为了加快对市场的响应时间，对IT应用系统开发的速度提出了更快的要求，因此IT的体系结构从原来单一集中式模式，走向分布式模式。经过几年实践证明，在这种分散式模式下，带来许多负面效果:降低了IT的效率;增加数据安全性、完整性的风险;软件需要分散的重复投资，维护费用急剧上升;计算机硬件资源利用率低;企业内部无法形成数据集中及应用集中;无法承受灾难备份的投资。面对这些挑战，IT的管理者自然要问:如何更好地支持、管理网络、软件及服务器,如何更好地控制投资回报,如何有效快速地分析业务数据,如何集成分布式应用及数据,如何保证关键应用的高可用性及安全性, 大集中就是在这种背景下产生的。 自1997年以来,中国银行业开始了深层次的银行改革.特别是在中国加入WTO之后,商业银行的决策层有了更强的历史紧迫感.在诸多的改革中,实施数据大集中模式改革和建设新一代核心业务系统己经成为我国银行业的一种趋势。 银行需要的不再是简单的技术平台和业务的整合，将不同的系统综合在一起已经不能满足银行客户的需求。我们需要为银行在总分行的体制下，提供一套完整的业务数据的集中与分布的管理的解决，甚至需要从某种程度上改变原有的运作模式，有机地将业务处理与技术平台结合起来。保证核心业务系统的稳定性的同时，能不断扩展不同地域的服务渠道，即能满足大集中的数据集中处理，又能解决不同地域的特色业务处理。然而目前银行系统普遍存在的主要问题在于外围前置设备较多，部分业务流程不合理，服务渠道(柜台、网银、客户服务系统等)需要与主机和其他前置系统交叉联系完成前端服务请求，业务扩展时需改动的外围系统较多，导致业务扩展较为困难。数据分布非常分散，核心业务主机负担越来越重，因而为进一步的优化应借助综合业务前置系统的建设，重组优化业务流程和数据分布，减轻主机的压力，使业务系统成为简单而稳定的核心。 1 山东大学硕士学位论文 1.2 国内外研究现状 面对激烈的商业竞争，“数据大集中”则成为各家商业银行比拼的焦点之一。 国外银行先后经历了二次数据中心合并的高潮，其结果是美英等国的许多具有代表性的大银行，都建立了自己在世界范围内的数据集中处理中心，并在此基础上完成了从数据集中到应用集中和业务集中的升级，例如花旗和汇丰。另外一方面，2000年以来，也出现了银行由于成本考虑，在数据集中和运营(尤其是后台)集中后，向离岸外包模式转变的趋势。 国内的银行以前是以省市为中心，建立相对独立的IT中心和业务系统。这种模式，不仅造成资源浪费，而且系统信息各自分割，不能有效交流。从1999年9月1日各个银行开始开展数据大集中，到现在为止，工、农、中、建、招、中国银联基本完成了数据大集中的工作。各自开发了一套实现大集中的前置系统。 尽管从流程而言，数据集中为银行风险防范提供了核心数据基础，但是，不能否认的是，数据集中后对于银行的风险管理，特别是操作风险管理和灾难备份系统建设提出了更高的要求。数据集中后的系统，如果出现崩溃，很可能引发灾难性的结果。目前国内商业银行的灾难备份中心建设、风险监控系统、应急体系建设和集约化数据中心安全生产管理等方面的建设却相对滞后，这对于防范数据大集中之后的风险可能产生负面的影响。这导致旧的系统无法满足银行的需求，需要开发一套新的前置系统解决这些问题。 1.3 解决的主要问题 银行金卡前置系统是建立在整个银行核心系统之上的子系统，该系统实现了总行对分行的集中式统一管理，提高了总行在技术和业务层面对分行的支撑。由于该系统涉及方面众多，系统复杂。因此本论文主要解决银行金卡前置系统的子系统清分清算平台的设计和开发。 在需求分析方面，要在充分理解整个金卡前置系统需求的础上，获得清分清算平台的需求和业务流程，需求包括功能需求和非功能需求。通过分析总结出2 山东大学硕士学位论文 合理的设计和开发思路。 在设计方面，要考虑清分清算的技术架构、功能架构和业务特点，设计有利于解决设备老化、分行主机处理能力低及维保成本高的问题的系统。 在实现方面，在实现前文设计基础上，主要解决设计出方便各分行操作和易于维护的控制台。 1.4 本文的主要工作 本文在深刻理解金融软件的开发、应用现状和需求的基础上，描述了银行金卡前置系统中清分清算子系统的设计与实现，分析了前置系统开发的背景和国内外银行数据大集中的发展现状。采用需求管理统一方法确定系统需求和系统设计目标，介绍了系统技术架构和功能架构以及清分清算与外部系统的联系，并对系统的内部外部接口设计进行了描述。对清分清算系统中各部分的特点进行了分析。通过测试环节，分析并给出了测试结果。 本文所作工作主要集中在一下方面: 1.分析了数据大集中前置系统的开发背景和国内外银行的研究现状，结合前置系统的特点,深刻分析了数据大集中同时也是前置系统存在的风险。 2.总体描述需求，通过对清分清算业务的分析，理出一个清晰地清分清算系统，对它的功能分为清分、数据清理、数据备份、文件处理、异常处理、控制台六个部分，并分别对各个部分的需求进行了详细的分析。 3.分析了整个系统的设计思路，对清分清算子系统与外部系统的逻辑关系和数据流向进行分析设计。分析了系统的技术架构和功能架构。系统的控制台和核心模块采用不同的架构，他们之间采用TCP/IP通讯。 4.系统的详细设计:按配置管理的方式将系统分成多个可独立运行的模块。通过一条指令可调用其中的一个或多个模块。设计核心模块之间、进程之间以及核心模块和控制台之间的通讯方式;分析数据量，设计数据库的分区;分析并设计各个模块之间的接口和系统与外部系统的接口。 5.系统的实现和测试:好的设计方案，好的系统要有一个友好的界面，方便用户使用，更重要的是通过严格的测试保证质量和最终效果。如何保证系统的各个模块之间能正确的工作、完成整个流程需要多长时间这是测试过程中需要重点 3 山东大学硕士学位论文 考虑的问题。本项目的系统测试方法，为其他项目提供了良好的参考价值。 在需求分析基础上，讨论清分清算系统的概要设计。首先根据前文的系统需求提出系统设计的目标和原则以及设计思路，然后通过逻辑关系图、清分数据流 最后，本文对清分清算子系统的应用情况作了简单介绍，并对系统的实现和测试进行了总结。 1.5 论文的组织结构 第1章绪论，主要描述银行金卡前置系统的开发背景、国内外研究现状，本文解决的主要问题和完成的工作。 第2章系统需求分析，主要进行银行金卡前置系统中清分清算子系统的需求分析。首先进行银行金卡前置系统项目背景介绍和金卡前置系统的概述。其次描述了该系统的系统目标和解决的问题。最后对需求分析按照功能需求和非功能需求两个类别进行描述。 第3章清分清算子系统架构设计，主要进行系统的架构设计。首先对系统的设计目标和原则以及设计思路进行了阐述。其次，介绍了清分清算子系统与外部的关系。最后是清分清算子系统的技术架构和功能架构。在技术架构设计中，分别按照物理架构和逻辑架构进行设计。 第4章清分清算子系统详细设计，本章主要进行系统的详细设计。首先在系统建模部分，在对烟草行业电子商务系统的整体模型结构描述的基础上，对客户关系管理系统的整体结构进行设计。其次，按照差异化管理和一体化管理两个思路，分别进行了各个模块的详细设计。 第5章清分清算子系统的实现与测试，首先描述了系统的整体实现，并对各个模块的实现进行了描述。然后本章描述了系统测试的情况，并对测试方法进行了详细描述。 第6章对论文进行了总结，并对系统的进一步提升提出了改进意见。 4 山东大学硕士学位论文 第2章 需求分析 2.1总体业务描述 银行金卡前置系统是介于中国银联处理系统和银行帐务主机处理系统之间的一个交易处理系统，负责银行金卡业务同银联的交易转发、报文转换以及除核心系统之外的业务处理。清分清算是属于除核心系统之外的业务处理之一。是金卡前置系统的子系统之一。 清分(Clearing)是清算的数据准备阶段,主要是将当日的全部网络交易数据按照各成员行之间本代它、它代本、贷记、借记、笔数、金额、轧差净额等进行汇总、整理、分类。清分是网络交换中心和各成员行交易主机系统在清算阶段的主要工作,将产生三级清分数据 :各成员行对网络交换中心的清算净额，各成员行相互之间交易的各类汇总，当日的全部网络交易明细。 对于金融交易的清分,交换中心和各成员行主机根据各自的交易流水记录即可进行。对于授权交易,日间交易期间并不扣减客户帐户余额,日结后也并不根据交易流水进行清分和清算,一般采取日结后由代理行批量上传交易数据,而后进行清分。如MasterCard国际组织的清分系统INET规定,每日23时、次日5时、9时,圣路易中心分三次接收成员行批量上传授权类交易明细数据,清分后于10时,向其清算银行(纽约的化学银行)提交清算数据,由化学银行实施清算。同时,5时、9时、23时(较上传滞后一个时段)分三次向成员行批量下传经中心清分后的授权交易明细数据,供发卡行记客户信用卡帐。 清算(Settlement)在清分与对帐的基础上进行,交换中心向清算银行(中心)提交各成员行与交换中心之间的净额清算数据,由清算银行(中心)按照预先商定的清算方式发起清算。在成员行的清算帐户之间实施清算划付,或通过清算网络传递资金调拨指令,完成银行间的清算。为了确保清算的正确性,可在清算结束后,由各成员行的清算系统将清算数据送达银行卡系统,再作一次末端对帐。清算网络及流程见图。清算网络由清算中心和各成员行的清算系统组成,网上传递的是银行之间的资金转移信息。 5 山东大学硕士学位论文 2.2系统目标和解决的问题 随着金融业务领域的竞争加剧，各家银行都在积极完善自己的金融产品，提高客户的服务体验，因此银行也通过对业务集中的方式，发挥银行整体服务功能，提高市场竞争力。新的系统要具有以下目标: 1、银行需要在清分清算平台具备良好的可扩展性和二次开发能力，支撑业务的快速开发和开通，以保持业务上的竞争优势。 2、总行实现银行清分清算的业务和各分行自行开发的特色业务，实现系统应用集中处理和数据集中存储。 3、降低维护成本、减少建设投资。 由于原有系统存在设备老化，总行难以对分行实现集中化管理，系统维护代价较高的问题。因此系统要解决的问题有以下几个方面: 1、促进建立以总行为中心的集中式管理模式。 2、要解决数据量大的问题，使数据库易于管理维护。 3、如何设计一个易于维护的系统。 2.3系统需求分析 清分清算平台处理的业务种类繁多。从业务角度来看，清分清算平台目前支持日终处理流程。 清分清算平台通过流程控制的方法并配合表驱动的方式，实现上述业务流程，并通过参数化设计满足多样性的业务要求，由于使用了上述表驱动技术，为日后业务流程的扩展提供了良好的基础。 清分清算平台必须具有相当的容错能力，以保证清算的准确性和实时性。容错主要有两个方面的考虑。一是“瑕疵”数据的处理。由于数据种类繁多，可能存在一定数量的“瑕疵”数据，但并不能因为“瑕疵”数据而使整个平台的清算受到影响。清分清算平台通过剔除个别“瑕疵”数据，来达到继续进行清算处理的目的。被剔除的“瑕疵”数据登记到例外日志中。容错的另一方面是出现异常后，要求清分清算平台具备重新清分的能力，通过清空前次清分留下的“垃圾数据”及流程控制状态表的控制，清分清算平台可以实现多次重作清分的能力。 6 山东大学硕士学位论文 2.3.1系统功能性需求 为满足银行客户的需求，我们需要为银行在总行的体制下，提供一套完整的业务数据集中和分布管理的解决方案。使系统能够不断扩展不同区域的服务渠道，即能满足数据集中处理，又能解决分行的特色业务处理。因此需要系统采用配置管理的方式，将每一项任务作为一个独立的可执行模块，大大增加系统的灵活性和可伸缩性。 所有可独立执行的模块均可在数据库表中进行参数配置。在后台发送一条指令，调度服务通过侦听端口响应控制台客户端发起的TCP/IP请求服务。调度服务接收到请求后，首先给客户端返回命令接收成功响应。随后，从配置文件中取出进程名和TCP端口号并初始化共享内存，调度相应的模块进行处理。 清分清算平台在业务上应具备的功能点有:清分，数据清理，商户入账，备份历史数据，文件处理，异常处理，控制台。 1(清分 清分是该系统的主要部分。目前负责清分的机构是银行和银联。 清分是将银行交易流水和银联交易流水进行分类汇总。根据发卡受理可分为受理方流水，发卡方流水。根据清算方式可分为本金、手续费、回退手续费，费用。根据交易类型分为:撤销、冲正、退货。根据借贷标识，分为借记，贷记。按照以上四种分类，分别对总行、分行、商户进行清分。如果在受理方流水中有商户，需要查找终端信息。若未找到终端信息，则将此记录插入例外日志表中。未勾兑成功的交易直接清分给总行。在清分过程中，如果发生严重错误或错误过多时将停止清分。最后将成功清分的记录经过一定的转换，插入到清算结果表和终端交易统计表中。为提高对数据库操作的速度，每处理一定量的记录后在提交。 2(数据清理 在清分和文件装载之前，根据进程调度命令中的清算日期，清空银行和银联的交易日志表，删除清算结果表、终端交易统计表、例外日志表中相应日期的信息。 3(备份历史数据 为提高对灾害的防御能力，需要定期备份历史数据。一般保存最近六个月的数据。每一天都要将银行交易明细表、银联交易明细表、清算结果表、终端交易 7 山东大学硕士学位论文 统计表备份到当月的历史数据表中。在每个月的第一天，删除六个月前的历史数据。 4(文件处理 文件处理包括银联流水文件装载和文件收发。清分清算的数据来源于日终产生的银行银联流水和差错处理流水。二次清分平台要处理这些数据，需要先转换成该平台能识别的格式，然后导入银联流水日志表和银行流水日志表中。 系统根据清算日期获取要收发的文件的信息，包括文件名、文件路径。然后登陆FTP服务器，发送或接收相关文件。如果是接收，还要在创建目录。一般目录格式是:清算日期/机构号。 5(异常处理 异常处理包括差错处理和错误信息报告。差错处理是判断差错处理流水中的记录是发卡方还是受理方。如果是受理方，表示本条差错处理失败。如果是发卡方，找到原始银联交易流水，进而找到清算明细中的记录，重新进算手续费。处理成功后，将该流水的状态置为成功。 系统运行中需要记录调试信息和错误信息，并将其插入到系统事件表中。系统根据发生错误的严重程度，将系统调试信息和报错信息分为以下等级，如表2-1所示: 表2-1 调试信息和错误信息等级表 分类 名称 描述 等级值 备注 ELVL_FATAL 错误严重错误 1 一般为导致清算结果错误，不得级别 不停止处理的问题 ELVL_ERROR 错误 2 用于发生错误但清算仍可继续的 情况，如:找不到商户扣率信息， 找不到清算方式配置参数等 ELVL_WARNING 错误警告 3 发生错误但不影响清算结果，提 示操作人员事后处理该错误 ELVL_INFO 一般信息 4 非错误，只是显示特定信息 DLVL_CAUTION 调试警告信息 3 用于显示认为需要注意的、程序级别 可能出错的信息 DLVL_INFO 一般调试信息 5 在程序流程中显示一些特定信息 8 山东大学硕士学位论文 DLVL_RUNFLOW 程序流程信息 7 一般在一段程序流程结束处，显 示提示信息 DLVL_BUF 调式缓存 9 对程序执行无影响，仅用来显示 一些变量内容 6(控制台 不同分行的用户可通过控制台处理各自分行的业务。包括管理商户信息、管理终端信息、管理信付通商户、直连商户入账。 管理商户信息包括商户信息增加、商户类型维护、商户类型组别维护。用户可直接通过控制台录入商户信息，同时可以增加删除修改手续费算法。在进行商户新增时主要涉及的元素:商户代码、商户名称、结算帐号、商户类型、所属分行号、所属支行号、地址、电话。查看商户组别的时候，需要显示商户类型号、商户类型维护、外卡标识、商户类型组别、记录状态。并可以对商户类型和商户类型组别进行增删改。用例图如下所示: 二次清分平台 填写商户信息 修改商户类型 查看商户类型 删除商户类型 用户查看商户类型组别修改商户类型组别 删除商户类型组别 图2-1商户信息管理用例图 管理终端信息包括终端信息增加、终端信息维护、终端类型维护、终端类型组别维护。用户可通过控制台录入终端信息，并对终端信息、终端类型、终端类型组别进行增删改查。 信付通是成都、大连、福州、广州、昆明、南京、宁波、上海、苏州、武汉 9 山东大学硕士学位论文 九家分行的特色业务。它为银行卡持卡人提供面向家庭、办公室和行业应用支付需求的一种自助刷卡支付新业务。用户通过支付易终端，即可方便的享受银行跨行转帐、公共事业缴费、手机充值、机票订购等金融服务。 用户从控制台输入信付通商户的签约信息，将其插入商户信息表和付款关系表中同时登记签约编号进行信付通商户签约。操作员通过控制台录入信付通商户终端信息，后台验证终端与信付通商户的绑定是否符合业务规则，若符合则在终端信息表中登记终端信息。若不符合，则显示失败。用户可通过终端号、绑定商户代码、签约分行、绑定商户名称、转入卡账号、转入账号类型、转入账户户名中的一项或几项查询符合条件的信付通商户。对其相应的终端信息进行增删改查。用户可通过商户代码、签约分行、商户名称、转入卡账号、转入账号类型、转入账户户名查询符合条件的商户信息，并对其增删改查。若修改了绑定卡账号，则首先验证是否符合匹配规则，如果匹配，在修改绑定卡账号的同时，更新商户的签约信息。用户还可以查询信付通商户的付款信息，并进行增删改操作。如果原来签约时没有对付款业务签约，则在增加付款信息的同时想主机发送付款业务签约的请求。已签约的商户可对其付款业务或收款业务进行解约。信付通商户管理的用例图如下所示: 10 山东大学硕士学位论文 二次清分平台 录入信付通商户签约信息登记签约编号 录入信付通商户终端信息验证是否符合业务规则 查询信付通商户终端信息修改终端信息 用户 修改商户信息查询信付通商户信息 增加付款信息查询信付通商户付款信息 信付通商户解约 图2-2 信付通商户管理用例图 直连商户入账可通过输入机构号，对入账机构表进行增删改查，但仅限于清算日期是“123456400”的记录(清算日期不必显示)。涉及的字段有:内部机构号、是否直连、是否保存流水。输入清算日期、入账状态可以查询入账记录的信息。显示机构号、商户号、账号、账户类型、商户名称、清算金额、佣金、币种、处理日期、应答描述、对账结果、重做次数、入账状态。当查询入账记录不成功的记录时，可以点击“差错重新入账”，发送2011请求。 2.3.2系统非功能性需求 清分清算平台要求系统具有如下特性: 1(高性能 要求系统具有很高的性能。 2(可靠性 11 山东大学硕士学位论文 系统应具备一定的异常处理能力，对于少量原始数据异常，能将异常数据剔除;对于清分过程软硬件环境异常，允许在排除故障后重新开始清分。同时单点故障应不影响整个系统的运行。 系统应对清分后数据进行备份，用于差错处理、查询以及必要时的数据恢复重做清分。由于系统对实时性要求不高，可在系统空闲时间进行系统软硬件及数据库维护。 3(易用性 本系统的操作人员主要为业务人员，对于用户不应有过高的技术技能要求，为能顺利、高效地完成系统功能，需要提供简单、明确、易用的操作界面和提示信息。 4(扩展性 随着业务的拓展，新的计费算法、清算模式也会不断出现，平台必须考虑具有良好的扩展性，在不修改内核的基础上，通过参数配置或者修改少量外围代码给予满足，尽量减少业务扩充对系统的影响。 支撑平台运行的主机系统应具有良好的纵向扩展性，通过在单机中增加CPU、内存等资源可提高系统处理性能。 12 山东大学硕士学位论文 第3章 系统概要设计 3.1系统设计原则 随着金融业务领域的竞争加剧，各家银行都在积极完善自己的金融产品，提高客户的服务体验。为发挥整体服务功能，提高市场竞争力，清分清算平台应具备良好的可扩展性和二次开发能力，支撑业务的快速开发和开通，以保持业务上的竞争优势。要在实现各分行自行开发的特色业务的基础上降低维护成本、减少建设投资。 清分清算平台的建设必须遵循如下建设原则: 1(整体规划，统一组织，分步实施的原则 流程和标准。系统开发与建设必须做到工作标准统一、业务流程统一、服务程序统一。要采用行业、国家和国际标准化组织制定的有关技术规范与标准。保证信息流传递快速顺畅，网络运行安全可靠。 2(稳定现有业务的原则 在总行金卡前置系统建设中，必须保证业务系统的稳健。在系统设计时，要尽量减少对现有业务流程规则的改造，避免因系统建设影响行内业务开展。 3(前瞻性原则 在金卡前置系统建设中，要充分考虑未来业务的发展和管理的变化，方便新业务和新需求的扩展和支持，满足未来银行金卡业务发展的需要。采用当前成熟的技术，符合国际、国内标准的软硬件技术规范。软件设计思想成熟稳定，充分考虑金卡业务各系统之间的建设关系以及有可能产生的相互影响，符合金融业务发展需求。 4(良好的扩展性原则 要充分考虑系统承担的集中处理的压力，在软件功能设计上独立分开。在功能部署上即可以统一部署在一台主机设备上，也可以在主机压力大时，将部分功能灵活部署到其他主机设备中。 5(安全性原则 13 山东大学硕士学位论文 系统必须具备安全性和稳定性。对于系统级，数据级，应用级，运行管 理级设计完善的安全体系。同时，辅以完整高效的备份恢复方案。 6(系统建设灵活性原则 系统业务流程的设计要具备灵活，满足业务流程创新的需要，减少重复 和交叉，以提高工作效率。系统应采用平台化建设方式，做到业务管理、定 制与系统监控、维护的相对分离。 3.2 设计思路 通过以上的分析，为清分清算的灵活多样性要求，在平台设计过程中，着重考虑了以下技术关键点，并贯穿于总体架构和各模块的概要设计中: 1(采用开放的Unix系统构建清分清算平台核心清分模块。基于开放的Unix系统，可确保平台基础架构的可持续发展性，且使得平台长期的总体拥有成本得以降低。 2(采用数据分区技术，使得并行技术的使用具有数据基础。 3(采用B/S方式构建清分清算平台控制台客户端。 4(为最大限度提高平台的处理性能，在应用设计中广泛采用将应用系统参数及非易变性数据装载入内存的技术，从而大大减少数据库操作，提高系统性能。 5(最大限度地采用参数化设计，提高对业务变化的适应能力和可管理性。 6(服务器上的核心进程均采用多进程并行处理技术，提高处理效率及横向扩展性。 7(在可能的情况下，采用多机并行技术。 8(控制台与服务器端采用标准TCP/IP协议通讯，提高系统稳定性和扩展性。 9(服务器进程间采用消息队列通信，提高进程调度效率和可靠性。 3.3 与外部关系 3.3.1 逻辑关系图 日终平台产生的CUPS/银行的流水数据和差错处理流水数据经过清分清算平台的处理，产生报表文件和明细文件，并将一部分结果返回给控制台。它与外14 山东大学硕士学位论文 部的关系如下图3-1所示: CUPS流水/ 银行流水 数据 清分清算平台Web控制数据库 日终平台 明细文件差错处理报表文件流水数据 图3-1 清分清算平台与外部关系 3.3.2 清分数据流向分析 清分清算平台清分数据流向示意如下图3-2所示: 历史数据生CUPS流水/清分数据调度服务成银行流水文件 流水数据清分信息数据导入 差错处理流水 文件 Web服务 统查询计 报表文件 图3-2 清分清算平台清分数据流向示意 对于输入数据源，经过CUPS的交易全部包含在日终平台下发的流水中，并由日终平台导入清分清算平台的源数据表。不经过CUPS的交易也由日终平台导入清分清算平台的源数据表。 输出最终数据主要包括报表文件及明细文件。清分功能模块生成的清分数据 15 山东大学硕士学位论文 存在于数据库中，作为报表子系统处理的数据来源。数据服务以数据库接口形式提供。 3.3.3 信息数据流向分析 清分清算平台信息数据流向示意如下图3-3所示: 清分信息数据查询 统计 Web服务 增量同步文件 人工录入 POSP 图3-3 清分清算平台信息数据流向示意 人工录入作为机构、商户、终端信息的输入数据源，经过Web服务加工以后，存入到数据库表中。 数据库表中的信息数据向查询服务提供数据接口。查询服务模块可直接访问信息数据(同时还有清分数据)。 清分清算参数数据库每天生成参数信息增量文件，POSP可以通过访问增量文件方式同步信息。 3.4系统技术架构设计 3.4.1 系统的逻辑架构 综合上述数据流向及业务功能点对应功能模块分析，结合总体设计方法和决策，可提出清分清算平台总体逻辑架构如下图3-4所示: 16 山东大学硕士学位论文 OutQ cleanCups1 hisDataGene Database cleanCups2 truncate errProc1 报表服务 loadCups1 errProc2 loadCups 2 procMan InQ JDBC 参数维护 查询 emory Share m Web(JSP、Servlet) TCP/IP WSRP (Web Service) WEB控制台 统一用户认证 browser 图3-4 清分清算平台逻辑架构图 清分服务器进程包括银联流水清分(cleanCups)、数据备份(hisDataGene)、数据清理(truncate)、银联流水导入(loadCups)和进程调度(procMan)等。其中进程调度(procMan)负责总体流程控制和进程间通讯。进程间通讯采用消息队列，从进程调度模块角度看，输出(Output)消息队列为多个，分别对应不同的模块，输入(Input)消息队列为一个，所有模块共用。 上图中，清分进程部署两个，clean1和clean2，银联流水装载进程也部署两个loadCups1和loadCups2。在实际应用中，可根据硬件资源匹配情况和测试结果部署多个应用进程进行并行操作，提高系统性能。共享内存用于频繁使用参数的装载。在一个扩展性良好的系统中，必然使用大量的技术和业务参数，参数 17 山东大学硕士学位论文 装载到共享内存中极大提高系统处理效率。参数装载到共享内存中的过程由进程调度模块实现，在每一次收到请求时执行。只有参数装载完成才进行进程调度。其他模块连接共享内存，从中获得参数。 进程调度模块与控制台之间采用标准TCP/IP进行通讯。TCP/IP方式实现C/S模式操作命令传递，仅返回操作命令接受状态。执行状态通过查询数据库表完成。不必等待，界面友好。 信息管理与清分过程在流程上是完全独立的，只是两个流程共享数据库中的信息数据，共用同一个控制台客户端发起请求。信息管理数据服务仅提供数据服务，无需提供应用服务，信息管理的应用服务在Web Server中实现。 参数维护功能模块采用java的数据库操作机制进行参数维护(增删改)。 3.4.2 系统的物理架构 数据库系统 应用层服务器 应用系统 数据库服务器 加密机 存储器 通讯层服务器 外接系统 TCP/IP包 API包 Web控制台服务器 银联总中心 Web浏览器 图3-5 清分清算平台物理架构图 18 山东大学硕士学位论文 数据库服务器将数据和应用单独部署，避免应用和数据出现故障时候造成交叉影响。数据库服务器为应用服务器提供数据存储服务，将业务数据集中提高数据一致性，简化交易流程，降低数据管理成本和提高数据管理的效率。 应用服务器是清分清算的核心部分，负责业务数据及逻辑处理。在应用服务器上部署有ATM本代他和他代本标准服务模块、POS本代他和他代本服务模块、本代他和他代本特色服务模块以及同核心之间的通讯服务。安全模块通过加密机实现与外部系统之间的安全控制，包括密钥交换、报文加密等。 通讯服务器同外部系统建立报文交换通道，应用服务器处理的交换数据发送到通讯服务器，通讯服务器针对报文路由到银联、公共服务平台。通讯服务器各通讯模块负责内部数据交换协议和外部系统报文交换协议的转换，将外部系统报文协议差异性屏蔽在系统的业务处理流程之外，保证外部系统报文变化以及新增外部系统接入的时候避免对应用服务器造成大的影响。 3.5系统功能架构 以上分析，我们获得清分清算子系统的功能架构图，进程调度模块接收控制台客户端发起的命令，对不同的事件通知调度相应的处理模块。如图所示: 进程调度 文件收发清分 数据清理模拟客户端 直连商户入账间连商户入账 生成历史数据文件装载 差错处理错误信息报告 信付通商户管理 图3-6 清分清算平台功能架构图 19 山东大学硕士学位论文 第4章 系统详细设计 经过需求分析和架构设计，我们了解了清分清算的业务需求和架构流程。本章在此基础上，进一步分析系统的模型结构和数据库结构。 4.1 系统整体结构 要确切的分析清分清算子系统的设计，有必要先了解银行金卡前置系统的整体结构，该银行金卡前置系统的整体逻辑结构如图4-1所示: 旧核心新核心 旧核心通讯服务新核心通讯服务 旧核心消息处理服务新核心消息处理服务 新旧系统判断服务(调用Bridge) CUPS银管理本代他ATM服务本代他POS服务本代他特色服务联银平台消联上海息监控通他代本ATM服务他代本POS服务他代本特色服务流讯平台处服广州理日终务服业务处理流程服务平台务„„ 渠道消息流处理服务 渠道通讯服务 XBANKATMPPOSP网银 图4-1 系统逻辑结构图 从上图可以看出业务处理流程服务是金卡系统的核心，是金卡的业务逻辑实现和数据访问中心，其建设是金卡系统总中心集中的关键环节。 通讯服务的设置主要是为了保证金卡业务处理流程业务的稳定性而屏蔽外部系统的差异性接入，降低金卡前置业务系统和外部系统的耦合度，便于新渠道的接入和新业务的拓展。 20 山东大学硕士学位论文 核心通讯服务保证了新旧核心系统切换无缝过渡，将新旧核心接口差异性与业务处理模块分离，便于业务处理服务在新旧切换过程中版本统一及便于维护。 渠道通讯服务提供多种协议接口，便于ATMP、POSP和银行业务终端XBANK的直接接入。 监控系统负责金卡前置系统各模块服务的监控，基于开放式的监控协议，在各应用系统中采集所需的系统状况信息，提供直观的系统监督、预警和管控功能。 清分清算平台和日终平台关系紧密。它接受来自日终的CUPS/银行流水数据和差错处理数据，并对其进行整理、分类、汇总。 4.2 详细设计 清分清算子系统由很多模块组成:进程调度模块、错误报告模块、模拟客户端模块、文件装载模块、明细文件生成模块、信息同步文件生成模块、历史数据生成模块、数据清理模等。下面分别详细讨论各个模块的设计。 4.2.1 进程调度详细设计 调度服务接收控制台客户端发起的命令，对不同的事件通知调度相应的处理模块。 调度服务通过侦听端口响应控制台客户端发起的TCP/IP请求服务。调度服务接收到请求后，首先给客户端返回命令接收成功响应。随后，调用调度预处理函数，进行异常数据清理、参数装载处理等。完成预处理后，从清分流程控制明细视图取出对应事件代码的业务步骤，对每步进行业务调度处理。所有步骤处理完毕后，再调用调度控制后处理函数，进行清分场次状态表修改。 调度服务通过消息队列与其他进程通信，其中发往其他进程的消息队列SVC_IN(n)有多个，每种服务标识对应一个，从其他进程接收的消息队列SVC_OUT有一个。其他进程从属于自己的SVC_IN(n)消息队列读取命令，读取成功后将自己的进程号写入SVC_OUT消息队列，同时启动处理过程。处理完成后，不管成功或者失败，均将处理结果再次写入SVC_OUT消息队列。 SVC_IN消息队列定义如下所示: 21 山东大学硕士学位论文 表4-1 svc_in消息队列表 序号 名称 字段名 长度 取值说明 1001:清分 1601:POSP流水清分 2001:检查银联文件 存在 2008: 直连商户入账 1 服务标识 serviceId 5 2041:生成报表 2208:间连商户入账 3001:数据信息同步 6009:差错处理 2 服务类型 serviceTp 3 3 清算日期 settleDate 9 YYYYMMDD 4 参数 para 513 SVC_OUT消息队列定义为: 表4-2 svc_out消息队列表 序号 名称 字段名 长度 取值说明 1001:清分 1601:POSP流水清分 2001:检查银联文件 存在 2008: 直连商户入账 1 服务标识 serviceId 5 2041:生成报表 2208:间连商户入账 3001:数据信息同步 6009:差错处理 2 服务类型 serviceTp 3 3 进程标识 procId 9 B:开始 4 处理状态 state 2 A:异常结束 E:正常结束 进程调度模块的工作原理是:通过UNIX IPC机制控制各功能模块(或服务)， 如文件装载、清分、数据清空等; 1(流程控制服务启动时，初始化、建立多个消息队列，每个消息队列与一个 服务对应; 2(启动各服务，各服务均连到与之对应的消息队列; 22 山东大学硕士学位论文 3(监听客户端的socket指令 4(接收到指令后，发送相应的请求到相应服务的消息队列; 服务从消息队列接收到请求后，开始工作。在该模块中使用共享内存，共享内存的使用，使常用的、不易变的数据处理速度大大加快，并且由于公用的数据被多个进程共享，也节省了对内存的使用。使得流程参数可配，以灵活实现不同分 行、不同流程的调度任务。当服务为多进程时，可同时异步发送多个对该服务的请求，当一个进程接收到消息后，进行相应的处理，如进行清分;这时后面的请求被其他进程获得，其他进程转入响应的处理。当请求数大于进程数时，处理完请求的进程会被再次分配到新的请求。直到所有的请求被完成为止。这种消息队列的特性，使得系统具有了一定的负载均衡特性。 进程调度模块的处理流程如下图4-2所示: 23 山东大学硕士学位论文 开始 监听客户端发出N的socket指令监听到, Y 参数装载共享内 存 读流程控制表，解析指令 向对应功能模块N的消息队列写入指令消息 写完, Y 获取功能模块返回的状态，记录日志和系统事件 结束 图 4-2进程调度流程图 24 山东大学硕士学位论文 4.2.2 文件收发详细设计 文件收发服务接收进程调度服务发出的指令，使用ftp协议收发文件，根据流程调度服务的消息类型判断是接收文件还是发送文件。 文件收发模块是标准Unix进程，由流程调度模块调用，当接收到流程调度模块发出的服务请求时开始运行，以单进程方式运行。需要接收和发送文件的信息，由文件收发模块从文件类型表和文件管理选项表中查询获得。流程如图所示: 开始 消息队列、 共享内存初始化 访问文件传输共 享内存获得待传 输文件信息 根据文件名匹配字符 串、清算日期、文件 MOUNT路径等 生成文件全路径 判断是否处理 完所有文件?是 否 调用ftp函数发送 结束或接收文件 图4-3 文件收发流程图 25 山东大学硕士学位论文 4.2.3 清分详细设计 清分清算模块是清分清算平台上的核心模块，主要完成对各清算角色的资金计算和数据划分，生成各种清算结果和明细文件，为各清算方的资金报表和明细文件提供数据。该模块由调度服务进行调度控制，主要有确认清算方式，确认手续费及分润决定方式，计算终端手续费，查找清算结果，插入例外日志表，终端交易统计，添加清算结果等部分组成，输入包括信息处理中心下发的一次清分全流水文件、异地交易SUMMARY REPORT文件和本地交换系统产生的交易日志文件等统一格式的数据库文件，输出清分清算后的数据库文件。 确认清算方式是根据交易代码、本地清算标志，在指定的清算方式结构集合中找出相匹配。如果找不到返回失败，找到，返回清算方式索引。用于查找清算角色和清算方式。 及分润决定方式是根据手续费决定方式表结构中交易代码、商户确认手续费 代码、终端代码，在手续费决定方式表中查找相匹配的记录，查找成功，返回手续费及分润决定方式索引，查找不成功，返回失败。 计算终端手续费是根据终端手续费决定方式表结构中商户类型和终端号，在终端手续费方式表中查找相匹配的记录，查找成功，返回终端手续费及分润决定方式索引，查找不成功，返回失败。 查找清算结果是根据清算结果结构中机构标识码、机构类型、清算日期、终端批结标志、直联标记、交易代码、交易渠道、清算货币代码、发送/接收标记，在清算结果表结构集合中找出相匹配。如果找不到返回失败，找到，返回清算结果在清算结果集合中的位置。 插入例外日志表是根据例外原因和例外条目，向例外日志表插入该条记录。 终端交易统计是根据终端交易统计表中相关字段，在终端交易统计结构集合中找出相匹配。如果找不到返回失败，找到，返回索引。 添加清算结果是把已经处理好的终端清算结果和其他清算结果插入清算结果表结构集合。 清分进程接收进程调度服务发出的消息队列，既而对各清算角色的手续费，分润进行计算并生成各种清算结果和明细文件，处理完成，不管成功与否，返回消息队列给进程调度服务。 26 山东大学硕士学位论文 4.2.4 数据清理详细设计 数据清理模块接受进程调度服务的调度，根据消息类型进行文件装载、清分前清空当天的日志和清算数据。该模块由调度服务进行调度控制，主要有清空银行交易日志表，清空银联交易日志表，清理银行清算记录，清理银联清算记录。清空银行/银联交易日志表是根据进程调度程序发送的消息类型清空相应的数据表。清理银行/银联清算记录是根据消息类型删除银行/银联交易清算明细表，银行/银联交易例外日志表，清算结果表，终端交易统计表中相匹配的记录。它采用装载空表方式清空数据表。处理流程如下图所示: 开始 消息队列、连接 数据库等初始化 工作 根据流程控制调用参数中 的消息类型，分别清空日 志、清算数据或全部清空 结束 图4-4数据清理流程图 27 山东大学硕士学位论文 4.2.5 直连商户入账详细设计 直连商户是指在某银行开的商户，使用银联的POS机。所有的交易必须通过银联，故银联能收到一定比例的手续费和服务费。在日终时，根据银联发过来的商户入账文件，由开户行给商户入账。 直连商户入账的处理流程包括以下几步。检查相关分行的商户入账文件是否达到。因为该文件是入账的根据，所以只有文件到达的分行才能进行入账。导入商户入账文件到数据库中。实际表中还设置了好几个状态位，为后续处理准备。生成入账文件。该交易只是针对旧核心使用他行卡的本行商户。发起入账交易。根据新核心、老核心，本行、他行对需要入账的商户进行入账。入账结果对账交易。老核心本行账号时，入账之后必须有的对账交易。 需要注意的是一旦有过入账动作的分行，是不允许再入账的。由于涉及新旧核心切换以及商户的账号在本行还是他行，所以入账的方式不同。 直连商户入账需要与主机之间进行拼报文，发报文，接收报文。交易报文格式，无结束符，数字应该转化为网络字节序。机构号与柜员号必添，而8位的柜员号的前4位其实就是机构号，如机构号域添0300，柜员号域添03000352;系统信息头有个信息长度，以及交易数据头有个交易包长度，这两个域都是先不添，等业务数据到达后再补添上。发送报文时，发送函数会在报文前再加4个字节的长度，然后发送。只要请求报文格式正确，就能收到返回报文(超时除外)，不存在的交易码，主机会应答“该交易的描述信息不存在”。 由于要调用新核心接口，库文件和makefile比较特别。所有账户逐渐都将迁移到新核心上，所以在给商户进行入账时，必须兼顾考虑账户位置。 直连商户入账给每个商户生成入账凭证，写格式文件与数据文件，再使用工具很容易就生成报表。不足之处是由控制台发起“生成报表”服务请求时，执行结束，控制台并不能实时直观的看到报表。 商户信息表(TBL_INF_MCHNT_INF)中的收单机构号域使用的是银联机构号，而商户入账控制表中使用的是银行内部机构号，而内部机构号只在机构信息表里有。使用视图，两个表关联的那部分是由ORACLE表完成，简化了程序。 处理时要注意机构号。清算机构信息表的机构号是含长度的，而以机构号命名的文件夹的机构号不含长度。 28 山东大学硕士学位论文 与主机通信时，交易报文的业务数据部分，是在各个服务中手工拼起来的，比较麻烦。当前实现是，在服务头文件中创建一个交易请求的结构体，在服务C文件中创建函数，由该交易的结构体生成交易报文格式的业务数据。 直连商户入账表(TBL_DAT_LOCAL_IN_FILE)的数据会随着时间的推移越来越多，而实际上常用的数据也就是最近一两天的。大量的数据使搜索变得很慢，逐渐成为服务性能的瓶颈。因此考虑把某一段时间之前的数据备份到历史数据表中，这样商户入账时处理得很快。功能实现时，先查直连商户入账表，如果没有，再查历史数据表，再没有，则返回错误。 在做入账交易时，可能入账不成功。如果是明显错误如“对公账户不存在”之类，应该是账号错误，通常没必须再入账;如果是超时错误，应该再入账。根据商户入账表的“入账状态”字段来标识状态。 4.2.6 间连商户入账详细设计 间连商户是指在某某银行开的商户，使用的是该银行的POS机，所有交易都先送到受理行，再进行处理。对于他行卡交易，银联不再收手续费，只收一定的服务费。POSP交易的的流水，经清分平台处理后，根据终端、商户汇总到终端汇总表中，该表是间连商户入账的数据来源。 首先是把终端数据汇总表的数据转换格式到商户入账信息表，再为7888交易生成入账文件，接着分别对老核心、新核心发起入账动作，最后对老核心的所有7603交易进行7625对账操作。 间连商户入账主要步骤与直连商户入账相同，区别在于间连商户入账时，不需要检查文件，而入账金额是需要计算的。 4.2.7 历史数据生成详细设计 历史数据生成模块将当日清算数据(清算明细表、清算结果表、B2B交易统计表、终端交易统计表)备份到当月的历史表中，历史数据保留半年，每月1日清空七个月前的表。 历史数据生成模块在收到进程调度服务的请求命令后将当天的清算数据复制到历史库的对应数据表中，需要处理的数据表有:清算明细表、清算结果表、 29 山东大学硕士学位论文 B2B统计表、终端交易统计表。 历史数据生成服务可以多进程并发运行，进程调度服务将需要处理的数据库表表名、清算机构代码、消息类型(用来区分生成清算历史明细表还是其他历史表)等参数写入历史数据生成服务的消息队列。在生成清算明细历史表数据时，历史数据生成服务按照清算机构代码划分明细数据，一个进程处理一个清算机构的数据，实现多进程并行处理。这里所说的清算机构，在同城交易和本地受理异地发卡的交易中为发送机构(交易报文33#域所填机构)，在本地发卡异地受理的交易中为接受机构(100#)。 它的技术实现与特点是: 1(支持多进程处理。可按机构多进程处理，目前未实现。 2(支持重复处理。采用insert + update操作，如有重复记录会自动修改原记录。 3(处理速度优化。采用在内存中缓存数据，再一次commit到数据库的办法。 流程如图所示: 开始 消息队列、 连接数据库 等初始化工作 是否为当 月1号,是 否 清空七个月前 的历史表 将当日明细表、结果表、 B2b表、终端统计表备份 到当月历史表中 结束 图4-5 历史数据生成流程图 30 山东大学硕士学位论文 4.2.8 文件装载详细设计 将银联/银行流水数据表的数据格式转换为清分模块能识别的日志格式，即从一张表导入另一张表。 装载银联/银行流水模块是标准Unix进程，可多进程并发运行, 装载银联/银行流水模块从数据库取出银联/银行流水数据表中的记录，使用函数在内存中对记录进行格式转换，同时本模块提供记录预处理和记录后处理接口，可生成明细文件的特殊要求字段使用。 与文件装载模块相关的表有:文件类型表、服务配置表、流程控制表。 它的技术实现和特点是: 1(多进程支持。通过流程控制表中消息类型的区分，可支持多进程装载处 理，但需要全流水拆分处理，目前还未拆分。所以按单进程运行。消息 类型配置为空。 2(特殊处理的字段。转帐交易手续费特殊处理、填写转入、转出机构。弥 补全流水的缺陷，如全流水未填写手续费支付方的借方手续费，但二次 清分需要该字段;退货交易将回退手续费字段填到了手续费字段，在这 里再把把它搬过来。预授权等无清算金额的交易， 将清算本金置成0。 双信息交易代码转换为单信息交易代码。差错交易，机构字段填写问题 弥补。暂扣交易打标记的处理。 文件转载流程图如下所示: 31 山东大学硕士学位论文 开始 消息队列、共 享内存等初始 化工作 从文件装载视图获取待装载文件 信息 根据文件路径、清算日期、消息类型和文件信息生成文件全路径 打开文件 判断文件是是否结束 否 取出一行文件记录结束 按照文件结构转换各字段为 数据库结构 对某些字段进行 特殊处理 将记录写入 数据库 图4-6文件装载流程图 32 山东大学硕士学位论文 4.2.9 错误信息报告详细设计 错误信息报告模块主要用来记录系统运行过程输出的调试信息和报错信息。它收到其他模块的消息队列请求命令后，根据错误信息，往数据库系统事件表里插入一条记录。该模块支持多进程处理。 开始 消息队列初始化 、连接数据库 向调试信息、报错信息文件输 出从消息队列接收到的调试或 报错信息 结束 图4-7 错误信息报告流程图 4.2.10 差错处理详细设计 差错处理模块接受进程调度服务的调度，根据消息类型处理差错处理流水表的数据。查找原始交易记录，对手续费重新分配。 该模块首先初始化差错处理流水表，银联交易流水表，银联清算明细表。分别判断差错处理流水表中的每条记录，若是受理方，则表明本条差错记录处理失败。若是发卡方，则根据差错处理流水找到原银联交易流水，进而找到此条流水的清算明细，并进行手续费划分的处理处理结束后置该流水状态为处理成功。当处理的差错处理流水数到达一定数目后，提交事务。 33 山东大学硕士学位论文 4.2.11 模拟客户端详细设计 模拟web客户端从后台向服务端发出socket指令，用于调试程序或web端程序失效的情况。socket指令的格式是:restCli 请求标识 清算日期 是否检查清分状态 重做标志 参数 返回码。其中各项均需要在清分流程控制表和服务配置表中进行配置。如:restCli 1001 20050808 1，表示发起2005年8月8日的同城清分，需要检查清分状态。 根据配置文件，与procMan监听的端口建立socket连接，发送并接收数据。 开始 将命令行参数参数作为调用 参数，向流程调度服务发送 TCP/IP报文 输出流程调度服务 的反馈 结束 图4-8 模拟客户端流程图 4.2.12信付通商户管理详细设计 信付通是一种为银行卡持卡人提供面向家庭、办公室和行业应用支付需求的一种自助刷卡支付新业务。用户通过支付易终端，即可方便的享受银行跨行转帐、公共事业缴费、手机充值、机票订购等金融服务。它属于分行的特色业务。只有成都、大连、福州、广州、昆明、南京、宁波、上海、苏州、武汉这几个分行有此业务。信付通商户管理分为商户签约、录入商户终端信息、商户终端信息维护、商户信息维护、商户付款信息查询、录入信付通商户付款信息、信付通商户解约这七部分。 信付通商户签约总体流程是操作员通过控制台页面录入信付通商户的签约34 山东大学硕士学位论文 信息;控制台根据约定的报文结构将录入的信付通商户的签约信息组装成报文，转发至联机模块;联机模块解析控制台转发的报文，将之转换成指定的结构;联机模块校验是否有重复的信付通商户签约的信息;联机模块登记信付通商户签约信息。 录入信付通商户终端信息总体流程是:操作员通过控制台页面录入信付通商户的终端信息;控制台根据约定的报文结构将录入的信付通商户的终端信息组装成报文，转发至联机模块;联机模块解析控制台转发的报文，将之转换成指定的结构;联机模块校验终端与信付通商户的绑定是否符合信付通的业务规则;联机模块登记信付通商户的终端信息。 信付通商户终端信息维护总体流程是:操作员通过控制台页面查询开通的信付通商户的终端信息;操作员选定要进行维护的信付通商户的终端，在控制台页面对信付通商户的终端信息进行修改;控制台根据约定的报文结构将录入的信付通商户的终端信息组装成报文，转发至联机模块;联机模块解析控制台转发的报文，将之转换成指定的结构;联机模块校验终端与信付通商户的绑定是否符合信付通的业务规则;联机模块修改信付通商户的终端信息。 信付通商户信息维护总体流程是:操作员通过控制台页面查询开通的信付通商户的信息;操作员选定要进行维护的信付通商户，在控制台页面对信付通商户信息进行修改;控制台根据约定的报文结构将录入的信付通商户的信息组装成报文，转发至联机模块;联机模块解析控制台转发的报文，将之转换成指定的结构;联机模块修改信付通商户的信息，如果信付通商户的绑定卡/账号有变动，则首先校验是否符合匹配规则，如果符合则在修改对应信付通商户的绑定卡/账号的同时向主机发送修改签约信息的请求，以同步更新主机中的签约信息。 信付通商户付款信息查询就是直接通过控制台页面查询开通的信付通商户信息。 录入信付通商户付款信息流程是:操作员选定要录入付款信息的信付通商户，在控制台页面增加信付通商户的付款信息;控制台根据约定的报文结构将录入的信付通商户的付款信息组装成报文，转发至联机模块;联机模块解析控制台转发的报文，将之转换成指定的结构;联机模块对信付通商户的付款信息进行相应的维护，如果原来签约时没有对付款业务进行签约，则在增加付款信息的同时 35 山东大学硕士学位论文 向主机发送付款业务签约请求。 信付通商户解约流程是:操作员通过控制台页面查询开通的信付通商户的信息操作员选定要解约的信付通商户，在控制台页面对信付通商户进行解约;控制台根据约定的报文结构将录入的信付通商户的解约信息组装成报文，转发至联机模块;联机模块解析控制台转发的报文，将之转换成指定的结构;联机模块分析信付通商户的签约关系，如果信付通商户的相关业务已签约则向主机发送修改签约信息的请求。 4.3 数据库的设计 4.3.1数据库需求 二次清分平台对数据的要求在业务层面可以进行如下归纳: 1.高效、可靠、灵活的计费处理 复杂、灵活的手续费计算;手续费算法可配置;分润方式多样化，支持多方交易相关/交易无关的分润;分润算法可配置。 2(灵活的输入输出接口 接收多种处理中心下发的文件、前置系统上传的流水文件;生成格式多样的报表/明细文件;文件格式可灵活配置，以适应业务发展需要。 3(统一、规范、友好的信息管理 信息格式统一、规范，要素齐全，便于以后集中管理;界面友好，操作简单。 (安全的操作员权限控制 4 分级的操作员权限控制，各级之间权限分明，互不干扰;权限可灵活定制。 在进行数据库逻辑设计时，在技术上主要进行了如下的考虑和约定: 1(制定了数据库的各种命名规范 对数据库各种对象的命名进行了规定;与该项目其他命名规范的衔接。 2(数据库范式的考虑 尽量采用数据库设计的第3范式，减少数据库的冗余;考虑应用访问的效率，在必要时非范式化某些表的设计。 3(其他问题 36 山东大学硕士学位论文 具有长度的消息域，在数据库中均具有长度字段，以减少垃圾数据的干扰;为提高数据库的性能，除了个别存储量较大的表外，数据库其他表所有字段均设为非空，并具有相关默认值;金额字段均设置为decimal数据类型，以分为单位，单笔金额长度为12，累计金额长度为16;笔数的长度均设置为decimal数据类型，长度为10;日志中的部分关键域，如金额，原始金额设置为数值型，而其他多数域均设置为char数据类型，以方便数据的移植和尽量保持应用与机器的无关性;数据表的查找速度，在相关必要的字段设置索引，同时进行索引的优化和合并，以减少不必要的索引;高应用系统事件的可监控性及减少数据库之间的干扰，在相关数据库均设置事件监控表;管理参数/安全信息采用审计表，静态代码表采用一个公共的审计表;留一定的可扩充性，相关表设立一定的保留域，建立数据库之间的主外键关联，从而保证数据关系的完整性，同时为保证相关表的性能，还必须对影响性能的外键进行整合，甚至取消;常被访问的字段定义为方便处理的数据类型;对较少出现的字段，定义为varchar，减少数据库容量;据表均设立修改时间戳和创建时间戳，以增强数据的可管理性。 4.3.2数据库划分 考虑到灾备的需要，将数据库划分为参数库、日志库、历史库三个数据库。日志库的数据可以通过重做清分获得，并且由于带宽限制，只对参数库进行灾备。例外日志表、清分状态表和系统事件表中，保存了一些不可重现的现场数据，灾备时应将这部分数据纳入灾备范围，因此，这三张表部署在参数库。这样，应用对例外日志表、清分状态表和系统事件表的操作涉及跨库操作。 其中日志库主要包括以下表: 表4-3 日志库表 表名 描述 tbl_log_settle_dtl 清算明细表 tbl_log_settle_rslt 清算结果表 tbl_log_b2b_trans_sum b2b交易统计表 tbl_log_term_trans_sum 终端交易统计表 参数库的表分为以下几类: 清算配置类表如下所示: 37 山东大学硕士学位论文 表4-4 清算配置表 表名 描述 tbl_inf_settle清算方_md 式表 tbl_inf_disc_d清算结et 果表 tbl_inf_disc_a计费算lgo 法表 tbl_inf_term_a终端分llot 润表 流程配置类表如下所示: 表4-5 流程配置表 表名 描述 tbl_inf_svc_opt 服务配置表 tbl_inf_clean_flow_流程控制表 ctrl tbl_inf_file_tp 文件类型表 tbl_inf_file_gen_co文件生成转nv 换表 商户、终端、机构信息表如下表所示: 表4-6 商户终端机构信息表 表名 描述 tbl_inf_mchnt商户信 _inf 息表 tbl_inf_term_终端信 inf 息表 tbl_inf_ins_i机构信 38 山东大学硕士学位论文 nf 息表 代码表如下所示: 表4-7 代码表 表名 描述 tbl_inf_disc计费代 _cd 码表 tbl_inf_even事件代 t_cd 码表 表的命名规则为:tbl(viw)_[dbname]_[tablename],其中dbname为表所在的数据库名的前3个字符，tablename为表英文名称缩写，各单词缩写间以下划线连接。 4.3.3数据库可用性 由于二次清分平台不是实时交易系统，仅在每天运行一场清分，其余时间都处于待命状态。而其他前置系统对于信息管理的数据库表要求较高。如果采用共享数据库的方式，则管理信息必须支持实时交易;如果采用信息同步到其他数据库的方式，则不要求管理信息实时在线。考虑第二种方式在数据库维护过程中必须启用备份数据库，并完成管理信息读取切换。 4.3.4数据库性能 二次清分平台的数据库表主要由日志数据、配置参数和历史数据三部分组成。对于日志信息，有如下性能考虑: 1(对于日志表，在清分完成后备份到历史数据中，采用load空表的方式清除数据。 2(建立索引时，充分考虑基于该表的可能的访问 3(尽可能的减少对索引字段的修改 4(对所有的字段设置初始值，避免应用读取数据时判定是否为NULL值，同时也提高数据的读取速度 39 山东大学硕士学位论文 5(对于配置参数，部分直接访问，部分通过视图的方式进行访问，表的设计考虑了数据库表的可维护性 6(尽量采用数据库设计的第3范式，减少数据库的冗余 7(考虑应用访问的效率，非范式化某些表的设计 8(建立索引时，充分考虑基于该表的可能的访问 4.3.5数据库容量分析 数据库存储容量情况分析如下:根据最大差错期限6个月以及一个月的数据周转期确定，历史数据在线保存7个月。数据库所需容量乘以1.5倍以提供一定裕量。 历史数据库占用空间最大数据为清分明细历史数据，所需容量分析如下: 表4-8 历史数据库容量分析表 交易量 每笔交易信息量 信息在线保存周期 数据库所需容量 100万 1.6Kbytes 7个月 100万 X 1.6K X 210 X 1.5约等于504G 200万 1.6Kbytes 7个月 1T 对于日志数据库，所有数据只保存一天，假定参与交易机构为100家，参与交易终端为20000个，发生的交易类型组合10种各表所需容量分析如下所示: 表4-9 日志数据库容量分析表 交易量 中文表名 记录长度(bytes) 数据库所需容量 100万 交易日志表 1156~1556 100万 X 1.2K X 1.5约等于1.8G(min) 100万 X 1.6K X 1.5约等于2.4G(max) 清分明细表 1156~1556 同上 清算结果表 205 100 X 205 X 10约等于200K B2B交易统计表 249 100 X 100 X 249 X 10约等于25M 终端交易统计表 166 2万X 166 X 10约等于33M 200万 交易日志表 1156~1556 3.6G(min) 4.8G(max) 清分明细表 1156~1556 同上 清算结果表 205 400K B2B交易统计表 249 50M 40 山东大学硕士学位论文 交易量 中文表名 记录长度(bytes) 数据库所需容量 终端交易统计表 166 66M 4.4 接口设计 清分清算平台不是一个独立的系统，是金卡前置系统中的一部分。需要通过接口与外部进行联系，下面分别讨论该系统的外部接口和内部接口。 4.1.1 外部接口 清分清算平台以服务请求/应答报文的形式与WEB控制台进行信息交换。调度服务与请求调用者之间通过TCP/IP协议传递服务请求及应答信息，接口报文包含报文头和报文体。报文头为4个字节长度，其后紧跟报文体。报文体中所有字段均为char型，每个字段包含结束符‘\0’，报文体包括:服务标识、清算日期、参数、返回码。其中服务标识、清算日期、参数要在数据库中的tbl_inf_svc_opt和tbl_inf_clean_flow_control 这两张表中进行相应的配置。例如报文体中的服务标识是1001，清算日期是20100101，参数是0的报文表示一条进行银联流水清分的消息。返回码00表示成功，其他是异常。 4.1.1 内部接口 系统内部各进程之间通过通讯报文进行信息传递。清分清算平台模块间的数据接口主要是清分明细数据和汇总数据，报文接口主要是输入消息和输出消息。输入消息和输出消息格式不一致，但所有输出消息的格式是一致的，所有输入消息的格式也是一致的。输入消息格式中所有字段均为char型，每个字段包含结束符‘\0’，SVC_IN消息队列包括服务标识、清算日期、参数、返回码。输出消息格式中所有字段也是均为char型，每个字段包含结束符‘\0’，SVC_OUT消息队列包括服务标识、进程标识、处理状态、返回码。内部接口的报文和外部接口报文一样需要在数据库表中进行配置。 进程调度通过消息队列与其他进程通信，其中发往其他进程的消息队列有多个，每种服务标识对应一个，从其他进程接收的消息队列有一个。其他进程从属于自己的SVC_IN(n)消息队列读取命令，读取成功后将自己的进程号写入 41 山东大学硕士学位论文 SVC_OUT消息队列，同时启动处理过程。处理完成后，不管成功或者失败，均将处理结果再次写入SVC_OUT消息队列。 42 山东大学硕士学位论文 第5章 系统实现与测试 5.1 系统实现 统一二次清分平台以集中式为主，同时也兼顾到有的分行要求将系统在物理上进行分布式部署。对于用户管理和用户认证，从用户数据集中的大方向出发，用户数据仍然放在信息中心进行集中管理，否则用户数据分离，用户维护将变得异常复杂。统一系统可以将用户管理和认证的功能包装成Web Service接口供分布系统进行调用。对于信息管理平台，则将其放置在分行，这是因为分布式部署方式需要将数据库放在分行，如果信息管理平台放在信息中心，每次数据访问都将需要穿过多道防火墙进行远程数据访问，效率必将下降很多。至于数据集中，仍然可以通过数据同步功能做到数据统一。同时，对于部署在分行的二次清分平台，数据库访问仍采用schema的方式进行访问，这样，将来需要统一商户管理时，只要在信息中心的数据库中增加分行对应的schema，数据就能很方便的移植。 二次清分控制台主要是进行商户信息管理、终端信息管理、商户入账、信付通商户管理。由于白天有大量的交易数据，服务器很忙，进行二次清分会加重服务器的工作量，因此一般会在第三天的凌晨两点到三点之间自动进行清分，在控制台只显示清分结果和清算日期。例如今天是第T+2天，就会在早上两点到三点进行第T天清分。这样做是因为清分的数据来源于日终。T+1天的这个时间段进行T天日终和差错处理以及装载银联文件，产生清分所需数据，T+2天的这个时间段，大量业务已经完成，服务器的工作量不是很大。此时清分不会加重工作量。因此当装载银联文件完成后就自动清分。缺点是不能对清分过程进行监控，若失败，无发显示具体原因，目前尚未有具体解决办法。 进行自动清分时，后台会发送TCP服务调用报文，报文格式如下所示: 43 山东大学硕士学位论文 typedef struct { char reqId[5]; char settleDate[9]; char checkFlag[2]; char redoFlag[2]; char para[513]; char respCode[3]; } TCP_PKG_DEF; 其中reqId是请求标识，不是服务ID，请求标识与服务标识是一对多的关系;settleDate表示清算日期;checkFlag表示是否检查清分状态，0表示否;1表示是;redoFlag是重做标志，0表示否，1表示是;para是参数，暂时无用;respCode是由后台返回的返回码。当respCode的值是“00”时，表示发送报文成功，“01”表示“无此服务”，“02”表示“必须重做”，“03”表示“不能重做”，“04”表示“正在清分”。 发起清分的代码如下所示: while(1) { if(glbSocketConnect(svrIp, NULL, tcpPort, &fd, &ret) != SUCCESS) { fprintf(stderr, "Error: init failure! [%s,%d,%d,%d,%s]\n",svrIp, tcpPort, ret, errno, strerror(errno)); return FAILURE; } if(send(fd, lenBuf, 4, 0) <= 0) { fprintf(stderr, "Error: send failure! [%d,%s]\n",errno, strerror(errno)); return FAILURE; } memset(bodyBuf, 0, sizeof(bodyBuf)); memset(&tcpPkg, '\0', sizeof(TCP_PKG_DEF)); strncpy(tcpPkg.reqId, "1001", 4); strncpy(tcpPkg.settleDate, settleDate, 8); strncpy(tcpPkg.redoFlag, "0", 1); tcpPkg.checkFlag[0] = NO; HtStrcpy(bodyBuf, "111111"); HtMemcpy(bodyBuf + 6, &tcpPkg, sizeof(TCP_PKG_DEF)); 44 山东大学硕士学位论文 if(send(fd, (char *)bodyBuf, sizeof(TCP_PKG_DEF), 0) <= 0) { fprintf(stderr, "Error: send failure! [%d,%s]\n",errno, strerror(errno)); return FAILURE; } if(recv(fd, lenBuf, 4, 0) <= 0) { fprintf(stderr, "Error: receive failure! [%d,%s]\n",errno, strerror(errno)); return FAILURE; } lenBuf[4] = '\0'; if(recv(fd, bodyBuf, atoi(lenBuf), 0) <= 0) { fprintf(stderr, "Error: receive failure! [%d,%s]\n",errno, strerror(errno)); return FAILURE; } memset(&tcpPkg, 0, sizeof(tcpPkg)); HtMemcpy((char *)&tcpPkg, bodyBuf+6, sizeof(TCP_PKG_DEF)); tcpPkg.reqId[4] = 0; tcpPkg.settleDate[8] = 0; tcpPkg.checkFlag[1] = 0; tcpPkg.redoFlag[1] = 0; tcpPkg.para[512] = 0; tcpPkg.respCode[2] = 0; if(memcmp(tcpPkg.respCode, "00", 2)==0) { break; }else if(memcmp(tcpPkg.respCode,"01", 2)==0){ return FAILURE; }else if(memcmp(tcpPkg.respCode, "04", 2)==0){ HtLog(gLogFile, HT_LOG_MODE_NORMAL, __FILE__, __LINE__, "重新发 送报文"); }else { return FAILURE; } } close(fd); 报文发送给进程调度程序，由它来启用相应的服务，实现代码如下所示: 45 山东大学硕士学位论文 int bootApp(SVC_INF_DEF svcInf[]) { int i=1, j; while(TRUE) { if(strlen(rtrim(svcInf[i].svcOpt.svc_id)) == 0) break; if(!strcmp(rtrim(svcInf[i].svcOpt.svc_id), SHELL_ID)) continue; for(j = 0; j < svcInf[i].svcOpt.proc_num; j++) execApp(svcInf[i].svcOpt.exec_file_nm); i++; } return SUCCESS; } 系统的控制台采用B/S架构设计，技术上采用基于MVC基础的Structs+Spring 框架，以java为编程语言，利用XML配置和BO、Hibernate等相关技术，遵循J2EE、EDI/XML、XML Signature、XML Encryption等技术标准。 银行金卡前置TOPFe控制台默认页面是整个系统的访问界面，是用户访问整个系统的接口，通过次界面用户可以浏览整个系统的信息管理平台、二次清分平台、差错管理平台等各部分功能。 图5-1 金卡前置控制台 46 山东大学硕士学位论文 其中二次清分平台根据清分清算的特点，结合总行集中管理和分行各具特色的思想，为银行建立了易于使用的控制平台。包括商户信息管理、终端信息管理、直连商户入账、信付通商户管理。 5.1.1 商户信息管理 商户信息管理包括商户信息增加、商户类型维护、商户类型组别维护。涉及的表有:商户类型表(TBL_INF_MCHNT_TP), 商户类型组别表(TBL_INF_MCHNT_TP_GRP), 商户信息表(TBL_INF_MCHNT_INF)，商户编号流水表(TBL_INF_MCHNT_NEXT_ID)，计费代码表(TBL_INF_DISC_CD)，计费算法表(TBL_INF_DISC_ALGO).通过商户信息管理平台录入商户的各种基本信息，例如商户号码、商户类型、商户所属组别、商户属性等等。商户类型维护和组别维护分别对商户类型和商户类型组别进行增删改查。商户类型有兽医服务、土木工程承包商、电气承包商等。商户类型组别有农业服务类、承包服务类等。二次清分平台可根据某些商户信息进行清分处理，如:连接方式、商户类型等。如图所示: 图5-2 商户信息管理控制台 其中商户信息增加的页面如下所示: 47 山东大学硕士学位论文 图5-3 商户基本信息页面 5.1.2 终端信息管理 终端信息管理包括终端信息增加、终端信息维护、终端类型维护、终端类型组别维护。涉及的表主要有:终端类型表(TBL_INF_TERM_TP)，终端类型组别表(TBL_INF_TERM_TP_GRP)，终端信息表(TBL_INF_TERM_INF)，该平台可对终端信息、终端类型、终端类型组别进行增删改查。终端类型有A0、A1、P1、P0、PA、PI、PM等。终端类型组别有ATM、POS等。若商场在银行开有账户，并且该商场可以通过刷卡结账，银行需要登记该商场及其pos机的相关信息。商场信息通过商户信息管理登记，而pos机的信息要通过终端信息管理录入，终端类型组别是POS 。我们在日常生活中经常用到的ATM取款机也是终端机的一种。银行也要登记ATM机的相关信息。如图所示: 图5-4 终端信息管理控制台 48 山东大学硕士学位论文 其中终端信息增加的页面如图所示: 图5-5 终端信息增加页面 5.1.3 直连商户入账 直连商户入账控制台包括入账机构增加、入账机构维护。涉及的表主要有入账机构表(TBL_INF_IN_INF)。该平台是通过对表tbl_inf_in_inf的操作来实现入账机构的增删改查，仅限于清算日期是12365400的记录。涉及的字段有;机构号(ins_id_cd)，是否入账(conn_md),直连、间连(connect_md),是否保存流水(save_seq_in)。直连商户是指商户直接与银联连接，交易信息直接送相关的发卡行。与之相对应的是间连商户。如图所示: 图5-6 直连商户入账控制台 5.1.4 信付通商户管理 信付通商户管理的控制台界面如下所示: 49 山东大学硕士学位论文 图5-7 信付通商户管理控制台 信付通商户管理包括信付通商户签约，录入信付通商户终端信息，信付通商户终端信息维护，信付通商户信息维护，信付通商户付款信息查询，录入信付通商户付款信息，信付通商户解约。涉及的表主要有:信付通入账机构控制表(TBL_INF_XFT_ACCT_INS), 信付通付款机构控制表(TBL_INF_XFT_PAY_INS), 信付通付款流水表(TBL_LOG_XFT_PAY), 信付通商户付款关系表(TBL_INF_XFT_PAY_RELATION), 信付通商户入账表(TBL_DAT_XFT_ACCT), 信付通对账前置流水表(TBL_LOG_XFT_ACTCHE_FRONT_LOG), 信付通对账结果表(TBL_LOG_XFT_ACTCHE_RESULT_LOG), 信付通对账银联流水表 (TBL_LOG_XFT_ACTCHE_CUPS_LOG)。 1(信付通商户签约 该部分主要是将要签约的商户信息插入到付款关系表 (TBL_INF_XFT_PAY_RELATION)，商户信息表(TBL_INF_MCHNT_INF)中。商户签约后才能通过支付易终端，享受银行跨行转帐、公共事业缴费、手机充值等金融服务。如图所示: 50 山东大学硕士学位论文 图5-8 信付通商户签约控制台 控制台将商户签约信息以报文形式发送给后台，后台根据交易代码(6321)将报文转换成相应的结构体。转换成结构体后，要判断该商户是否已签约。不同分行判断签约条件不同，如大连分行根据大连的收单机构代码(acq_ins_id_cd)，PSAM卡号(psam_no)记录状态(rec_st)，信付通商户标志(mchnt_xft_type)在商户信息表(tbl_inf_mchnt_inf)查找看是否存在相应信息，若有则表示该商户已签约，不能再进行签约。而成都分行则是根据成都的记录状态(rec_st)，信付通商户标(mchnt_xft_type)，收单机构代码(acq_ins_id_cd)，终端号(term_id)，商户代码(mchnt_cd_transfer)，结算账户(settle_acct)在终端手续费视图(viw_inf_term_disc)中查找看是否有记录，若有，则该商户已签约。其中大连的验证规则代码如下所示: 51 山东大学硕士学位论文 tbl_inf_mchnt_inf_def mchntInf; mchntInf.rec_st[0] = '1'; mchntInf.mchnt_xft_type[0] = '1'; HtMemcpy(mchntInf.acq_ins_id_cd, acqInsIdCd, strlen(acqInsIdCd)); HtMemcpy(mchntInf.psam_no, psamNo, strlen(psamNo)); ret = DbsTBL_INF_MCHNT_INF(SELECT_DALIANXFT, &mchntInf); if (ret != SUCCESS){ if(ret != DB_NOTFOUND){ HtSprintf(errMsg, "%s", ERR_DATABASE); return SUCCESS; }else { return FAILURE; } } 若判断商户未签约，则将相应商户签约信息记录到信付通商户付款关系表 (TBL_INF_XFT_PAY_RELATION)中。 信付通商户签约需要向主机发送修改签约信息的请求。信付通商户签约的 业务交易请求报文格式如下表: 表5-1 商户签约请求报文格式 字段名 字段索引 偏移量 104 源服务ID 0 目的服务ID 104 4 消息类型 117 8 交易代码 106 24 转入卡号长度 3 28 转入卡号 新加字段，索引待定 30 分行内部机构代码 16 65 服务产品编号 9 69 商户编号 37 79 付款业务标志 170 94 终端号 201 95 52 山东大学硕士学位论文 应答报文格式如下表所示: 表 5-2 商户签约应答报文格式表 字段名 字段索引 偏移量 104 源服务ID 0 目的服务ID 104 4 消息类型 117 8 交易代码 106 24 应答码 35 28 转入卡号 新加字段，索引待定 30 分行内部机构代码 14 65 商户编号 37 69 付款业务标志 170 84 终端号 201 85 服务产品编号 9 105 签约编号 新加字段，索引待定 115 2(录入信付通商户终端信息 将信付通商户的终端信息插入到终端信息表(TBL_INF_TERM_INF)中。界面 如图所示: 53 山东大学硕士学位论文 图5-9 录入终端信息控制台 开通信付通业务的九个分行中目前只有成都和上海签约时有终端信息。在录入信息之前需要检验终各个分行的终端信息是否已存在。例如成都的检验规则是根据它的记录状态(rec_st)，信付通商户标志(mchnt_xft_type)，收单机构代码(acq_ins_id_cd)，商户编号(mchnt_cd)在商户信息表(TBL_INF_MCHNT_INF)中查找商户代码(mchnt_cd_transfer)。然后再根据商户代码，终端号，收单机构代码，记录状态、信付通商户标志在终端手续费视图中查找相应信息。若找到，则表明终端信息和信付通商户已绑定，不能再录入终端信息。否则将信息插入到终端信息表中。代码如下所示: 54 山东大学硕士学位论文 viw_inf_term_disc_def termDisc; tbl_inf_mchnt_inf_def mchntInf; mchntInf.rec_st[0] = '1'; mchntInf.mchnt_xft_type[0] = '1'; HtMemcpy(mchntInf.acq_ins_id_cd, acqInsIdCd, strlen(acqInsIdCd)); HtMemcpy(mchntInf.mchnt_cd, pst->mchntCdT, MCHNTCDTLEN); ret = DbsTBL_INF_MCHNT_INF(DBS_SELECT2, &mchntInf); if(ret !=0) { HtSprintf(errMsg, "%s", ERR_DATABASE); return SUCCESS; } HtMemcpy(mchntCd, mchntInf.mchnt_cd_transfer, MCHNTCDLEN); ret = CommonRTrim(mchntCd); HtMemcpy(termDisc.mchnt_cd_transfer, mchntCd, strlen(mchntCd)); termDisc.rec_st[0] = '1'; termDisc.mchnt_xft_type[0] = '1'; HtMemcpy(termDisc.term_id, termCd, strlen(termCd)); HtMemcpy(termDisc.acq_ins_id_cd,CHENGDU_BRBANKINSIDEID, BRBANKINSIDEID_ACTTUALLEN); ret=DbUserVIW_INF_TERM_DISC(SELECT_CHENGDUXFT,&termDisc,&sqlCode); if (ret != SUCCESS){ if (sqlCode != DB_NOTFOUND){ HtSprintf(errMsg, "%s", ERR_DATABASE); return SUCCESS; }else { return FAILURE; } } 3. 信付通商户终端信息维护 信付通商户终端信息维护是修改已和信付通商户绑定的终端信息。并将修改后的信息在终端信息表中更新。 4. 信付通商户信息维护 修改已开通信付通的商户信息。根据约定的报文结构将录入的信付通商户的信息组装成报文，转发至联机模块;如果信付通商户的绑定卡/账号有变动，则首先校验是否符合匹配规则，如果符合则在修改对应信付通商户的绑定卡/账号的同时向主机发送修改签约信息的请求，以同步更新BP中的签约信息。 各分行的验证规则均不同。上海、南京、成都是根据终端号、记录状态 55 山东大学硕士学位论文 (rec_st)、信付通商户状态、商户编号、收单机构代码、商户代码在终端手续费视图中查询是否有相应信息。昆明、福州、宁波、苏州、武汉、泉州、大连是根据记录状态、信付通商户状态、收单机构代码、PSAM卡号在商户信息表中查找是否有相应信息。其中成都分行的验证规则代码如下所示: termDisc.rec_st[0] = '1'; termDisc.mchnt_xft_type[0] = '1'; HtMemcpy(termDisc.acq_ins_id_cd,CHENGDU_BRBANKINSIDEID, BRBANKINSIDEID_ACTTUALLEN); HtMemcpy(termDisc.term_id, viwInfTermDisc.term_id, strlen(viwInfTermDisc.term_id)); ret = DbUserVIW_INF_TERM_DISC(SELECT_CHENGDUXFT, &termDisc, &sqlCode); if (ret != SUCCESS){ if (sqlCode != DB_NOTFOUND){ HtSprintf(errMsg, "%s", ERR_DATABASE); return SUCCESS; }else { return FAILURE; } } 信付通商户信息维护向主机发送的请求报文格式如下所示: 表5-3 商户信息维护请求报文格式表 字段名 字段索引 偏移量 104 源服务ID 0 目的服务ID 104 4 消息类型 117 8 交易代码 106 24 转入卡号长度 3 28 转入卡号 214 30 分行内部机构代码 132 65 服务产品编号 213 69 商户编号 37 79 发送BP标志 105 114 应答报文如下所示: 56 山东大学硕士学位论文 表5-4 商户签约请求报文格式 字段名 字段索引 偏移量 104 源服务ID 0 目的服务ID 104 4 消息类型 117 8 交易代码 106 24 应答码 35 28 转入卡号 214 30 分行内部机构代码 132 65 服务产品编号 213 69 商户编号 37 79 5. 信付通商户付款信息查询 根据商户代码、签约分行、商户名称、转入卡/账号、转入账号类型、转入账户户名查询所有符合条件的已开通信付通的商户(对商户信息表tbl_inf_mchnt_inf和信付通付款关系表tbl_xft_pay_relation进行联合查询)。然后再查询信付通商户的付款信息。 6. 录入信付通商户付款信息 录入信付通商户付款信息控制台界面如下所示: 图5-10 录入付款信息控制台 57 山东大学硕士学位论文 操作员通过控制台页面查询开通的信付通商户的信息;选定要录入付款信息的信付通商户，在控制台页面增加信付通商户的付款信息。核心模块在增加付款信息之前根据相应规则验证付款业务是否已签约。所有分行都是根据收单机构代码和商户编号在商户信息表中查找信付通付款业务签约编号。如果不是空，表示付款业务已签约，否则是未签约。未签约在增加付款信息的同时向BP发送付款业务签约请求。验证规则的代码如下所示: tbl_inf_mchnt_inf_def mchntInf; HtMemcpy(mchntInf.mchnt_cd, pst->mchntCdP, MCHNTCDPLEN); HtMemcpy(mchntInf.acq_ins_id_cd, pst->acqInsIdCdP, ACQINSIDCDPLEN); ret = DbsTBL_INF_MCHNT_INF(DBS_SELECT, &mchntInf); if (ret != SUCCESS){ if(ret != DB_NOTFOUND){ return FAILURE; } } ret = CommonRTrim(mchntInf.xft_pay_sign_seq); if(strlen(mchntInf.xft_pay_sign_seq)==0){ HtMemcpy(mark, "1", 1); }else { HtMemcpy(mark, "2", 1); } 7. 信付通商户解约 信付通商户解约的界面如下所示: 图5-11 商户解约控制台 58 山东大学硕士学位论文 信付通商户解约是删除商户信息表中该商户的签约信息。在解约之前需要 验证该商户是否已解约，各分行的验证规则都一样。均是在商户信息表中根据 记录状态、信付通商户状态、商户编号、收单机构代码、查询是否有符合条件 的信息。代码如下: tbl_inf_mchnt_inf_def mchntInf; mchntInf.rec_st[0] = '1'; mchntInf.mchnt_xft_type[0] = '1'; HtMemcpy(mchntCdT, pst->mchntCdT, MCHNTCDTLEN); ret = CommonRTrim(mchntCdT); HtMemcpy(mchntInf.mchnt_cd, mchntCdT, strlen(mchntCdT)); HtMemcpy(acqInsIdCd, pst->acqInsIdCd, ACQINSIDCDLEN); ret = CommonRTrim(acqInsIdCd); HtMemcpy(mchntInf.acq_ins_id_cd, acqInsIdCd, strlen(acqInsIdCd)); ret = DbsTBL_INF_MCHNT_INF(DBS_SELECT2, &mchntInf); if(ret != SUCCESS) { if(ret != DB_NOTFOUND) { HtSprintf(errMsg, "%s", ERR_DATABASE); return FAILURE; } else { HtSprintf(errMsg, "%s", ERR_MCHNTNOTFOUND); return FAILURE; } } 如果信付通商户的相关业务已签约则向主机发送修改签约信息的请求。请 求报文格式如下表所示: 表5-5 商户解约请求报文格式表 字段名 字段索引 偏移量 104 源服务ID 0 目的服务ID 104 4 消息类型 117 8 交易代码 106 24 转入卡号长度 3 28 转入卡号 214 30 分行内部机构代码 132 65 服务产品编号 213 69 59 山东大学硕士学位论文 字段名 字段索引 偏移量 商户编号 37 79 解约类型 105 94 应答报文格式如下表所示: 表5-6 商户解约应答报文格式表 字段名 字段索引 偏移量 104 源服务ID 0 目的服务ID 104 4 消息类型 117 8 交易代码 106 24 应答码 35 28 转入卡号 214 30 分行内部机构代码 132 65 服务产品编号 213 69 商户编号 37 79 解约类型 105 97 5.2 系统测试 该系统的成败与否,要取决于它是否能够在实际应用中得以体现，是否能够确保清算正确、资金安全。通过一年多的设计开发，现在清分清算系统已完成基本功能及一些特色业务的开发与测试，如:信付通。在测试中主要进行单元测试、集成测试、对比测试、并行测试。 单元测试的目的是使每个个性化模块都能正常工作，通过测试所配置的参数，清算流程正确、单清算结果正确。单元测试须有测试案例和测试记录。 使 集成测试的目的是通过集成测试案例，确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。需要提交测试案例和测试，并通过评审;并准备测试数据、操作二次清分平台。 对比测试的目的是通过与老系统输出结果的对比，验证新系统的正确性。需要提交测试案例和测试计划，并通过评审;准备测试数据、操作二次清分平台，对比报表和明细文件，及时反映问题，并解决。 并行的目的是验证二次清分平台在生产系统的运行流程是否顺畅，输出结果是否准确。需要每天清算两天前的清算日数据，并与原清算系统的输出进行比较。 60 山东大学硕士学位论文 其中对比测试的主要流程是:首先对本分公司某一清算日的清算数据进行统计，生成统一格式的清算结果文档;其次使用统一二次清分平台清算同一清算日的交易，并使用研究院提供的脚本统计统一二次清分平台的清算结果，同样生成统一格式的清算结果文档;然后对两者生成的清算结果文档进行对比，找出不一致的地方，并查找原因;可能的原因有:二次清分参数配置错、分公司清算系统自身问题、由总分公司间某些业务差异导致的不一致;最后通过统一格式清算结果文档的对比，确定二次清分平台清算结果无误以后，再进行报表的对比。 在测试过程中根据测试问题的特征，分为五种错误级别，分别是:致命错误、严重错误、一般错误、较小错误、测试建议。由于程序所引起的死机非法退出，程序接口错误，数据通讯错误异常中断，严重的数值计算错误，交易报文域填写错误。交易控制参数失效，.报文转换错误，交易流程错误属于致命错误。功能不符，数据流错误，限额控制有误，轻微的数值计算错误，统计错误属于严重错误。界面错误，打印内容、格式错误，简单的输入限制未放在前台进行控制，删除操作未给出提示属于一般错误。辅助说明描述不清楚，显示格式不规范，功能标题错误，.提示窗口文字未采用行业术语，可输入区域和只读区域没有明显的区分标志属于较小错误。操作界面不够友好属于测试建议。 通过以上方法的测试，证明了清分清算系统的每个个性化模块都能正常工作，清算流程及单清算结果正确;各单元组合在一起后能够按照既定意图协作运行。但在测试过程中有时出现清算失败的情况，原因主要有:对数据源的理解有误、报表、流水体现过程的问题、过渡模块的问题。整个清分清算流程运行时间在1秒到2秒之间，在系统的正常范围之内。 61 山东大学硕士学位论文 第6章 结论 随着中国银行业深层次的银行改革，实施数据大集中模式改革和建设新一代核心业务系统己经成为我国银行业的一种趋势。银行金卡前置系统正是顺应这种趋势的产物。它提高了银行的市场竞争力，便于银行总行对分行的集中式管理，降低了维护成本，也提高了银行的工作效率。本文所描述的清分清算子系统是金卡前置系统的一部分，结合银行的业务需求和功能需求开发的一套系统。 系统的控制台采用了B/S架构设计，以J2EE为技术平台，采用Struts+Spring+Hibernate技术架构。清分清算平台核心清分模块采用C/S架构设计，使用开放的Unix系统构建。开发过程中采用目前流行的数据库建模工具Power Designer以及集成开发环境Eclipse 等先进的系统开发工具,极大的提高了系统开发的效率。实现了具备商户信息管理、终端信息管理、信付通商户管理、数据清分、历史数据备份、差错处理、商户入账等功能的清分清算系统。 系统在论文初始阶段，切合学校论文管理的量化要求，将学位论文进行严格的量化管理和时间进度控制，从而增强学生和导师之间的沟通，提高论文的质量。 实现数据大集中后，为保证数据的安全性以及方便数据的管理，采用数据库分区技术，将清分清算平台的数据库分成了日志库、参数库、历史库，不同的用户只能访问特定的数据库，也使得并行技术的使用具有数据基础。为最大限度提高平台的处理性能，在应用设计中广泛采用将应用系统参数及非易变性数据装载入内存的技术，从而大大减少数据库操作，提高系统性能。为提高服务器的处理效率及横向扩展性，核心进程均采用多进程并行处理技术。数据大集中将分行特色业务集中到总行，为提高对业务变化的适应能力和可管理性，最大限度地采用了参数化设计。系统可在服务配置表和清分流程控制表中对清分流程进行配置管理。 本论文详细分析了清分清算的需求，对系统与外部的逻辑关系、数据流向、技术架构、功能架构、各个部分的功能、数据库、内外部接口以及系统实现进行了详细设计。重点描述了信付通业务，它是某些分行的特色业务，将其放到总行， 62 山东大学硕士学位论文 实现了数据大集中。 系统的设计已基本满足了银行的要求，但是对于清分，若交易失败，目前尚不能在控制台显示具体失败原因，只能对其过程进行监控，待以后寻求新的方法进行改进。 63 山东大学硕士学位论文 参考文献 [1] 中国银联信息交换处理中心系统业务需求 中国银联股份有限公司 [2] 信息系统安全技术国家标准汇编 中国标准出版社 [3] 银行卡联网联合技术规范V2.0 中国银联股份有限公司 [4] 技术业务文档汇编 银行卡信息交换总中心 [5] 银行卡文件汇编 全国银行卡办公室 [6](美)Alistair Cockburn著，王雷，张莉译 编写有效用例 北京:机械工业出版社 ，2002.09 [7](美)Shari Lawrence Pfleeger著, 吴丹译，软件工程理论与实践(第2版) 北京: 清华大学出版社，2003.08 [8](澳)Leszek A.Maciaszek著，金芝译 需求分析与系统设计 北京:机械工业出版社，2003.06 [9] 冀振燕著 UML系统分析设计与应用案例 北京:人们邮电出版社， 2003 [10](美)Wendy Boggs,Michael Boggs著，邱仲潘译 UML with Rational Rose 从入门到精通 北京:电子工业出版社，2000 [11](美)Ronald J.Norman著，周之英译 面向对象系统分析与设计 北京:清 2000.11 华大学出版社， [12](美) Erich Gamma 等著，李英军等译 设计模式:可复用面向对象软件的基础才 北京:机械工业出版社，2005.06 [13]宫云站 软件测试 北京:国防工业出版社，2006 [14]段念 软件性能测试过程详解与案例剖析 北京:清华大学出版社 [15] Gerald D.Everelt Raymond McLeod 软件测试——跨越整个软件开发生命周期 北京:清华大学出版社，2008 [16]张红 资金汇划清算系统的实现 中国金融电脑 2001(8).-36 -39 64 山东大学硕士学位论文 [17]Financial transaction card originated messages-Interchange message specifications(5First edition), 2003-06-15 [18] Craig Larman .Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development(Third Edition). Addison Wesley Professional, 2004 [19]Fowler M.Patterns of Enterprise Application Architecture Reading. Addison-Wesley, 2002 [20]Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software . Addison-Wesley, 1995. 65