CN101877100A - 基于银行前置业务平台的多渠道接入模块及其接入方法 - Google Patents

Abstract

一种基于银行前置业务平台的多渠道接入方法和模块，其包括后台业务处理程序、客户端及连接所述后台业务处理程序和客户端的前置业务平台，所述客户端包括内置客户端及外置客户端，所述前置业务平台包括用于接收内置客户端请求的主监听程序，及用于接收外置客户端请求的扩展监听程序。本发明可保证交易的一致性和用户信息的完整性，同时，也能保证交易的安全性。

Description

基于银行前置业务平台的多渠道接入模块及其接入方法

技术领域

本发明涉及一种基于银行前置业务平台的多渠道接入方法和模块，属于金融服务技术领域。

背景技术

对于前置业务平台来讲，整合银行的交易渠道，实现渠道之间资源的共享，是系统设计的主要目标之一。在前置业务平台中，渠道接入的工作是由渠道接入子系统完成的，而在渠道接入子系统中，最核心的技术是接入模块的实现，它能够整合各种渠道客户端访问银行内部各个应用系统的交易接入，使前置业务平台可以作为银行内部各个系统的唯一接入点，能够保证交易的一致性和用户信息的完整性。鉴于此，所述多渠道接入技术和模块已逐渐成为前置业务平台中的关键部分，越来越多的多渠道接入技术和模块也随之出现，为此，本发明提供了一种全新的多渠道接入技术和模块，来满足渠道客户端与银行内部的交易接入需求。

发明内容

本发明所解决的技术问题在于提供一种基于银行前置业务平台的多渠道接入方法和模块，其可保证交易的一致性和用户信息的完整性。

为解决上述技术问题，本发明采用如下技术方案：一种基于银行前置业务平台的多渠道接入模块，包括后台业务处理程序、客户端及连接所述后台业务处理程序和客户端的前置业务平台，所述客户端包括内置客户端及外置客户端，所述前置业务平台包括用于接收内置客户端请求的主监听程序，及用于接收外置客户端请求的扩展监听程序。

作为本技术方案的进一步改进，所述主监听程序与扩展监听程序均包括交易接入和交易分发。

作为本技术方案的进一步改进，所述所述扩展监听程序用来接收外置客户端发起的交易请求并对交易请求进行身份识别。

作为本技术方案的进一步改进，来自于所述客户端的请求报文将转换成内部报文后分发到前置业务平台相应的服务进程，从交易结果队列中获取结果报文，并把它转换成外部报文返回给客户端。

作为本技术方案的进一步改进，所述身份识别包括如下三种方式：通过交易方的IP地址判断、通过证书验证的方式、为特定客户单独建立监听程序使得发送到该客户端口的所有连接都是事先指定的用户。

本发明亦可采用如下技术方案：一种基于银行前置业务平台的多渠道接入方法，用于连接客户端与后台业务处理程序，其包括如下步骤：先把客户端的请求报文经所述前置业务平台转换成内部报文，并将该内部报文分发到后台业务处理程序的服务进程，其中，所述前置业务平台包括主监听程序及扩展监听程序；然后从后台业务处理程序给出的交易结果队列中获取结果报文，并把结果报文转换成外部报文返回给客户端。

作为上述技术方案的进一步改进，所述主监听程序和扩展监听程序均包括交易接入和交易分发，而所述扩展监听程序还需要进行内部报文与外部报文的转换。

作为上述技术方案的进一步改进，所述交易接入和接入后的工作流程包括通讯接入、身份识别、获取交易请求报文、获取交易码、转换报文、获取服务编号及写入服务的消息队列。

作为上述技术方案的进一步改进，交易返回时的流程包括从交易队列取交易结果、获取结果报文的返回链路、取交易发起方的信息、转换报文及返回交易结果。

作为上述技术方案的进一步改进，所述交易接入过程中的身份识别、获取交易码、转换报文，及交易返回过程中的获取交易发起方信息、转换报文均用于扩展监听程序。

相较于现有技术，采用本发明所述的基于银行前置业务平台的多渠道接入方法和模块可保证交易的一致性和用户信息的完整性，同时，也能保证交易的安全性。

附图说明

图1为本发明所述的基于银行前置业务平台的多渠道接入模块架构图。

图2为本发明所述的基于银行前置业务平台的多渠道接入模块的工作流程图。

具体实施方式

请参阅图1所示，为本发明所述的多渠道接入模块，其作为客户端和应用程序之间的通讯枢纽，是客户端和应用程序间的唯一通道，该多渠道接入模块的主要作用包括两部分：

第一，把客户端的请求报文转换成内部报文后分发到前置业务平台相应的服务进程；

第二，从交易结果队列中获取结果报文，并把它转换成外部报文返回给客户端。

如图1所示，前置业务平台的监听程序包括两种，主监听程序和扩展(自定义)监听程序。

所述主监听程序用于接收前置业务平台内置客户端发起的请求，内置客户端可以应用于银行内部的各种系统，包括柜面系统、网上银行系统等。该主监听程序采用端口复用技术，可以启动多个实例，每个实例都监听同一个端口，操作系统会自动把连接该端口的请求分配给压力最小的主监听程序。因为主监听程序接收的是内置客户端发起的交易，因此不需要验证客户端的身份，也不需要在外部报文和内部报文之间进行转换。另外，所述主监听程序可以根据前台发送交易数据包的参数自动选择包解析程序和数据压缩程序，目前平台支持标准的XML报文、纯字符流数据包和内部带格式的字符流数据包，采用gzip压缩上下传数据报文。

所述扩展监听程序考虑到平台在实施过程中可能会需要接收各种外部系统发起的交易，因此平台提供了外部系统接入的技术，这就是外置客户端的接入。所述外置客户端发起的交易，包括银企联网中由企业发起的交易、电子商务企业发起的转账交易、银联和中央银行发起的跨行交易等，这些交易的协议和格式都是难以预测的。为充分实现平台的扩展性和高效处理，前置业务平台可以通过定制特殊的监听服务程序来接收企业外部系统发起地交易请求数据包。因为交易发起方的身份和报文结构都是未知的，因此平台需要提供身份识别、报文格式识别、交易码识别和报文格式转换等功能，其中，报文格式识别一般包含在身份识别中，目前假定，对于同一用户的所有交易，上下传使用的报文格式都是相同的。

对于主监听程序和扩展监听程序，其整体的框架是相同的，包括交易接入和交易分发等，唯一的差别是需要进行报文转换。

请参阅图2所示，所述交易接入和接入后的主要工作流程：通讯接入、身份识别、获取交易请求报文、获取交易码、转换报文、获取服务编号及写入服务的消息队列。

所述通讯接入用于接入外置客户端的交易请求，平台采用端口复用和异地通讯的方式，使监听程序可以水平扩展，而且每个监听程序的并发量接入数量可以达到操作系统对文件描述符的最大限制数量。例如，在AIX上的最大并发数量可以超过750路。

所述身份识别主要用于扩展监听程序，识别交易发起方的身份。身份识别一般有三种方式：1.通过交易方的IP地址判断，这种情况下交易方一般通过一台主机和前置业务平台服务器通讯，因此可以通过配置IP地址的方式识别交易方；2.通过证书验证的方式，客户端通过证书加密的方式和服务器通讯，监听程序可以通过证书获取对方的身份；3.为一类客户单独建立监听程序，发送到该端口的所有连接都是事先指定的用户，这种方式主要为解决交易方可以通过多个IP地址发起交易的问题。

对于通过IP地址匹配的方式，扩展监听程序中定义了以下匹配表，用于获取发起方的信息和报文格式信息，此表格可以根据需要进行客户化。

IP地址(通配符：*.*.*.*)
	系统名称
报文类型，8583、list、字符串等
	编码类型，ASC或BCD等
交易码位置，交易码在报文中的偏移量
	交易码长度，报文中定义的交易码长度
报文长度位置，报文长度字段在报文中的偏移量
	报文长度长度，报文中定义的长度字段的长度
固定报文长度
	包头长度
地区码

IP地址(通配符：*.*.*.*)
	交易发起方，渠道标识符
交易列表，发起方的交易列表

所述获取交易请求报文主要用于主监听程序，其一般有四种可能：第一种可以根据报文中提供的长度字段获取总个报文；第二种可以根据事先确定的固定报文长度获取报文；第三种是在未知报文长度的情况下，如果是8583或类8583报文，可以通过解析报文来判断是否已经接收完总个报文；第四种是在未知报文长度的情况下采用一次性接收的方式。

获取交易码主要用于扩展监听程序，交易码识别一般都需要根据报文内容决定，对于不同的报文类型，采用不同的方式获取交易码：

1.对于IS08583或类8583报文，一般由信息码和交易码确定请求对应的

平台交易码；

2.对于字符流报文，一般由固定位置报文交易码；

3.对于自解析的报文(比如XML报文和HTML报文)，可以根据tag确定交易码。

对于交易码识别，扩展监听程序中定义了以下匹配表，用于根据发起方的交易码获取系统内部交易码。

MTI交易的信息码
	对方交易码，报文中的第三方交易码
项目编号，对应内部定义的项目编号
	单位编号
商户交易码
	内部交易码，和项目编号一起确定报文的格式配置信息
平台交易码，平台的服务代码
	超时时间
报文长度

关于转换报文，主要用于扩展监听程序，通过预先定义的报文配置文件来把外部报文转换为内部报文。

关于获取服务编号，主要用于主监听程序，平台程序在启动时维护了一张服务程序和交易的对照表，监听程序通过查询这张表，可以获取服务的提供程序编号。

关于写入服务的消息队列，平台为每类服务程序分配一个单独的交易队列，不同的服务程序采用不同的交易队列，同一服务的不同实例却使用同一个队列，因此，监听程序只需要把请求报文写入服务的交易队列，由操作系统去确定具体由哪个服务的实例进程去处理。

交易返回时的主要流程：从队列取交易结果、取结果报文的返回链路、取交易发起方的信息、转换报文及返回交易结果。

平台为每一个监听程序的进程分配一个交易结果消息队列，不同的监听进程使用不同的结果消息队列，因此，从结果队列中获取的每个报文都是由这个监听程序发起交易的应答信息。

对于取结果报文的返回链路，所述监听程序在接收到客户端的请求后，会为每个报文产生一个唯一的报文编号，应答报文中也会包含这些编号，监听程序可以根据这些报文编号，获取报文的返回链路。

对于取交易发起方的信息，用于扩展监听程序，交易发起方由监听程序在接收请求时识别，并保存在内存中，返回时可以根据交易结果编号获取。

对于转换报文，主要用于扩展监听程序，通过预先定义的报文配置文件来把内部报文转换为外部报文。

最后返回交易结果，根据第2步获得的通讯链路，把交易的应答报文返回给客户端。

以上所述，仅是本发明的最佳实施例而已，并非对本发明作任何形式上的限制。任何熟悉本领域的技术人员，在不脱离本发明技术方案范围情况下，利用上述揭示的方法内容对本发明技术方案做出许多可能的变动和修饰，均属于权利要求书保护的范围。

Claims (10)

1.一种基于银行前置业务平台的多渠道接入模块，包括后台业务处理程序、客户端及连接所述后台业务处理程序和客户端的前置业务平台，其特征在于：所述客户端包括内置客户端及外置客户端，所述前置业务平台包括用于接收内置客户端请求的主监听程序，及用于接收外置客户端请求的扩展监听程序。

2.如权利要求1所述的基于银行前置业务平台的多渠道接入模块，其特征在于：所述主监听程序与扩展监听程序均包括交易接入和交易分发。

3.如权利要求2所述的基于银行前置业务平台的多渠道接入模块，其特征在于：所述扩展监听程序用来接收外置客户端发起的交易请求并对交易请求进行身份识别。

4.如权利要求3所述的基于银行前置业务平台的多渠道接入模块，其特征在于：来自于所述客户端的请求报文将转换成内部报文后分发到前置业务平台相应的服务进程，从交易结果队列中获取结果报文，并把它转换成外部报文返回给客户端。

5.如权利要求4所述的基于银行前置业务平台的多渠道接入模块，其特征在于：所述身份识别包括如下三种方式：通过交易方的IP地址判断、通过证书验证的方式、为特定客户单独建立监听程序使得发送到该客户端口的所有连接都是事先指定的用户。

6.一种基于银行前置业务平台的多渠道接入方法，用于连接客户端与后台业务处理程序，其包括如下步骤：

先把客户端的请求报文经所述前置业务平台转换成内部报文，并将该内部报文分发到后台业务处理程序的服务进程，其中，所述前置业务平台包括主监听程序及扩展监听程序；

然后从后台业务处理程序给出的交易结果队列中获取结果报文，并把结果报文转换成外部报文返回给客户端。

7.如权利要求6所述的基于银行前置业务平台的多渠道接入方法，其特征在于：所述主监听程序和扩展监听程序均包括交易接入和交易分发，而所述扩展监听程序还需要进行内部报文与外部报文的转换。

8.如权利要求7所述的基于银行前置业务平台的多渠道接入方法，其特征在于：所述交易接入和接入后的工作流程包括通讯接入、身份识别、获取交易请求报文、获取交易码、转换报文、获取服务编号及写入服务的消息队列。

9.如权利要求8所述的基于银行前置业务平台的多渠道接入方法，其特征在于：交易返回时的流程包括从交易队列取交易结果、取结果报文的返回链路、获取交易发起方的信息、转换报文及返回交易结果。

10.如权利要求9所述的基于银行前置业务平台的多渠道接入方法，其特征在于：所述交易接入过程中的身份识别、获取交易码、转换报文，及交易返回过程中的获取交易发起方信息、转换报文均用于扩展监听程序。

Images