一种联机请求处理方法、服务器及系统与流程

本申请属于信息交互技术领域，特别涉及一种联机请求处理方法、服务器及系统。

背景技术：

现有的银行业务交易通常用如图1所示的星状系统结构，即多个服务请求终端对应一受理服务器。服务请求终端向受理服务器请求交易数据，对于单次联机申请大数据量返回的情况，常见的联机实时解决方案为：服务请求终端向受理服务器发起联机请求；受理服务器接收联机请求，加工整理服务请求终端需要的数据，若请求的数据量超过设定的阈值，则截取该阈值长度内的数据、与翻页信息一并返回服务请求终端；服务请求终端通过多次发送带有翻页信息的交易请求，获得所需的全部信息。以某请求A为例，假设客户请求的交易信息为2000条，每次请求最多支持返回8条信息，则依据现有方案，服务请求终端通过请求A获取全部信息，需要与受理服务器交互2000/8＝250次。

对于单次请求大量数据的联机请求由于受单次返回数据量的限制，不能一次返回所请求的所有数据，需要服务请求终端与受理服务器建立多次连接，才能获得所请求的数据，这就导致数据传输操作总的响应速度慢、响应时间长，影响用户体验。

技术实现要素：

本申请提供一种联机请求处理方法、服务器及系统，用于解决现有技术中银行受理服务器在响应联机请求时由于受单次返回数据量的限制不能一次返回所请求的全部数据，需服务请求终端与受理服务器建立多次连接，导致响应时间长，影响用户体验的问题。

为了解决上述技术问题，本申请的一技术方案为提供一种联机请求处理方法，包括：受理服务器接收并响应服务请求终端发出的联机请求，将生成的处理结果文件传输至文件缓冲服务器；

文件缓冲服务器接收处理结果文件，监测所述服务请求终端联机请求界面是否关闭，若已关闭，则待处理结果文件接收完后通知相应的服务请求终端获取处理结果文件，若未关闭，则待处理结果文件接收完后将其直接提供给相应的服务请求终端，以使服务请求终端联机请求界面显示处理结果。

本申请另一技术方案为提供一种联机请求处理的服务器，包括：受理服务器及文件缓冲服务器；

所述受理服务器用于接收并响应服务请求终端发出的联机请求，将生成的处理结果文件传输至所述文件缓冲服务器；

所述文件缓冲服务器用于接收处理结果文件，监测所述服务请求终端联机请求界面是否关闭，若已关闭，则待处理结果文件接收完后通知相应的服务请求终端获取处理结果文件，若未关闭，则待处理结果文件接收完后将其直接提供给相应的服务请求终端，以使服务请求终端联机请求界面显示处理结果。

本申请的再一技术方案为提供一种联机请求处理系统，包括多个服务请求终端、受理服务器及文件缓冲服务器；

所述服务请求终端发出联机请求至所述受理服务器；

所述受理服务器接收并响应服务请求终端发出的联机请求，将生成的处理结果文件传输至文件缓冲服务器；

所述文件缓冲服务器接收处理结果文件，监测所述服务请求终端联机请求界面是否关闭，若已关闭，则待处理结果文件接收完后通知相应的服务请求终端获取处理结果文件，若未关闭，则待处理结果文件接收完后将其直接提供给相应的服务请求终端，以使服务请求终端联机请求界面显示处理结果。

本申请的上述实施例，受理服务器将响应联机请求而生成的处理结果文件先发送至文件缓冲服务器，通过文件缓冲服务器将数据量大的处理结果提供给服务请求终端，能够释放受理服务器的部分资源，提高受理服务器的响应速度。文件缓冲服务器还能对服务请求终端的联机请求界面的关闭状态进行监控，以便通过离线的方式通知服务请求终端及时获取处理结果，或通过在线的方式直接向服务请求终端提供处理结果。本申请能够突破联机请求数据量的限制，降低服务请求终端与受理服务器的连接次数，及时通知服务请求终端，使服务请求终端一次获得所需要的数据，能够降低受理服务器总响应时间，提高处理结果传输的总响应速度，提升用户体验。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为现有技术中联机请求处理系统的结构图；

图2为本申请实施例的联机请求处理方法的流程图；

图3为本申请实施例的受理服务器实时响应联机请求的流程图；

图4为本申请实施例的受理服务器异步处理联机请求的流程图；

图5为本申请实施例的联机请求处理系统的结构图。

具体实施方式

为了使本发明的技术特点及效果更加明显，下面结合附图对本发明的技术方案做进一步说明，本发明也可有其他不同的具体实例来加以说明或实施，任何本领域技术人员在权利要求范围内做的等同变换均属于本发明的保护范畴。

在本说明书的描述中，参考术语“一个实施例”、“一个具体实施例”、“一些实施例”、“例如”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。各实施例中涉及的步骤顺序用于示意性说明本申请的实施，其中的步骤顺序不作限定，可根据需要作适当调整。

需要说明的是，本申请所述的服务请求终端可以为ATM机、POS机等可与银行服务器进行交互的实体设备，也可以为电话银行、网上银行等可与银行服务器进行交互的APP，本申请对服务请求终端具体为何不做限定。

本申请所述的联机请求可以为历史交易查询、余额查询等从银行服务器获取相应信息的查询请求，本申请对联机请求具体为何不做限定。联机请求包括但不限于交易账号(如银行卡号、用户名等)、流水号、查询条件(如时间信息)、优先级(根据账号类型等信息进行设定)。

如图2所示，图2为本申请一实施例的联机请求处理方法流程图。本实施例能够突破联机实时请求数据量的限制，能够使服务请求终端一次获得所需要的数据，降低受理服务器总响应时间，提高处理结果传输的总响应速度，提升用户体验。具体的，包括：

步骤201：受理服务器接收并响应服务请求终端发出的联机请求，将生成的处理结果文件传输至文件缓冲服务器。

受理服务器响应联机请求的过程具体为根据联机请求获取相关信息，组织该相关数据，生成处理结果文件。

步骤202：文件缓冲服务器接收处理结果文件，监测所述服务请求终端联机请求界面是否状态，若已关闭，则待处理结果文件接收完后通知相应的服务请求终端获取处理结果文件，若未关闭，则待处理结果文件接收完后将其直接提供给相应的服务请求终端，以使服务请求终端联机请求界面显示处理结果。

具体的，联机请求界面已关闭时，文件缓冲服务器可通过发送短信、E-mail等方式通知相应的服务请求终端及时获取处理结果文件，其中，短信或E-mail中可包含获取处理结果文件的链接或文件名。

联机请求界面未关闭时，将接收到的处理结果文件直接提供给相应的服务请求终端进一步包括：通知相应的服务请求端刷新联机请求界面上的结果查询链接，通过(客户)点击该链接获取处理结果文件。服务请求终端接收到处理结果文件后对该文件进行加工整理显示给客户。

本申请一实施例中，为了提高联机请求数据量小的联机请求的响应速度，如图3所示，上述步骤101中，受理服务器接收并响应服务请求终端发出的联机请求，将生成的处理结果文件传输至文件缓冲服务器的过程包括：

受理服务器接收到所述联机请求后，先判断联机请求的数据量是否小于预定阈值，该预定阈值为现有技术中受理服务器单次返回的最大数据量。

如果判断结果为是，则响应所述联机请求，将生成的处理结果文件直接提供给服务请求终端，服务请求端将处理结果文件展现给客户。

如果判断结果为否，则将所述联机请求登记在联机请求控制表中，响应联机请求控制表中的每一联机请求，将生成的处理结果文件传输至文件缓冲服务器。

一具体实施例中，联机请求控制表中除了上述联机请求信息外，还包括联机请求处理状态等信息，具体参阅下表：

本申请一实施例中，为了保证每个渠道(服务请求终端的类型，如POS机类、ATM机类)都能获得公平的处理机会，不至于单个渠道请求过多而影响对其他渠道的服务，采用渠道轮询的方式响应联机请求控制表中的每一联机请求，具体的，如图4所示，轮询过程包括：

步骤401：从联机请求控制表中获取一渠道的一个联机请求。具体实施时，在步骤401之前还包括先判断该渠道中是否有联机请求，如有，则进行步骤401，如无，则获取下一渠道的一个联机请求。

步骤402：响应该渠道的该联机请求，记录响应该渠道的该联机请求的耗费时间T₁。

步骤403：判断该耗费时间T₁是否小于响应该渠道联机请求应该占用的时间T₀。其中，响应该渠道联机请求应该占用的时间T₀可以为响应该渠道联机请求的历史平均时间。

如果判断结果为是，则停止一段时间后继续从联机请求控制表中获取下一渠道的一个联机请求，重复步骤402～403，其中，一段时间为响应该渠道联机请求应该占用的时间T₀减去该耗费时间T₁。停止一段时间能够释放系统资源，避免受理服务器异步处理耗费过多的资源，影响受理服务器同步处理的速度。

如果判断结果为否，则继续从联机请求控制表中获取下一渠道的一个联机请求。

待所有渠道轮询一遍之后，重复上述步骤401～403继续处理渠道中其他未处理的联机请求。

本申请一实施例中，若服务请求终端已关闭联机请求界面，或久未收到通知获取处理结果，服务请求终端也可发送查询请求至受理服务器，其中，查询请求用于查询联机请求的响应状态。受理服务器根据查询请求查询联机请求的响应状态。如果联机请求已被响应，则由所述文件缓冲服务器将处理结果文件提供给相应的服务请求终端；如果联机请求响应失败，则将响应失败原因提供给相应的服务请求终端；如果联机请求还未被响应，则提示相应的服务请求终端于预定时间后再次发送查询请求。

本申请一实施例中，为了使服务请求终端实时了解联机请求处理情况，联机请求处理方法还包括：文件缓冲服务器将处理结果文件接收情况信息提供给服务请求终端。

本申请的上述实施例，受理服务器将响应联机请求而生成的处理结果文件先发送至文件缓冲服务器，通过文件缓冲服务器将数据量大的处理结果提供给服务请求终端，能够释放受理服务器的部分资源，提高受理服务器的响应速度。文件缓冲服务器还能对服务请求终端的联机请求界面的关闭状态进行监控，以便通过离线的方式通知服务请求终端及时获取处理结果，或通过在线的方式直接向服务请求终端提供处理结果。本申请能够突破联机请求数据量的限制，及时通知服务请求终端，使服务请求终端一次获得所需要的数据，能够降低受理服务器总响应时间，提高处理结果传输的总响应速度，提升用户体验。

本申请一实施例中，还提供一种联机请求处理的服务器，包括：受理服务器及文件缓冲服务器。

所述受理服务器用于接收并响应服务请求终端发出的联机请求，将生成的处理结果文件传输至所述文件缓冲服务器。

所述文件缓冲服务器用于接收处理结果文件，监测所述服务请求终端联机请求界面是否关闭，若已关闭，则待处理结果文件接收完后通知相应的服务请求终端获取处理结果文件，若未关闭，则待处理结果文件接收完后将其直接提供给相应的服务请求终端，以使服务请求终端联机请求界面显示处理结果。

具体实施时，所述受理服务器接收到所述联机请求后，先判断联机请求的数据量是否小于预定阈值。

如果判断结果为是，则响应所述联机请求，将生成的处理结果文件直接提供给服务请求终端。如果判断结果为否，则将所述联机请求登记在联机请求控制表中，响应联机请求控制表中的每一联机请求，将生成的处理结果文件传输至文件缓冲服务器。

具体实施时，所述受理服务器响应联机请求控制表中的每一联机请求过程中包括：

从联机请求控制表中获取一渠道的一个联机请求。

响应该渠道的该联机请求，记录响应该渠道的该联机请求的耗费时间。

判断该耗费时间是否小于响应该渠道联机请求应该占用的时间；如果判断结果为是，则停止一段时间后继续从联机请求控制表中获取下一渠道的一个联机请求，其中，一段时间为该应该占用的时间减去该耗费时间；如果判断结果为否，则继续从联机请求控制表中获取下一渠道的一个联机请求。

本申请一实施例中，受理服务器还用于根据所述服务请求终端发送的查询请求查询联机请求的响应状态，如果联机请求已被响应，则由所述文件缓冲服务器将处理结果文件提供给相应的服务请求终端，如果联机请求响应失败，则将响应失败原因提供给相应的服务请求终端，如果联机请求还未被响应，则提示相应的服务请求终端于预定时间后再次发送查询请求。

如图5所示，图5为本申请实施例的联机请求处理系统结构图。具体的，该系统包括：多个服务请求终端501、受理服务器502及文件缓冲服务器503。

服务请求终端501发出联机请求至所述受理服务器。

受理服务器502接收并响应服务请求终端发出的联机请求，将生成的处理结果文件传输至文件缓冲服务器。

文件缓冲服务器503接收处理结果文件，监测所述服务请求终端联机请求界面是否关闭，若已关闭，则待处理结果文件接收完后通知相应的服务请求终端获取处理结果文件，若未关闭，则待处理结果文件接收完后将其直接提供给相应的服务请求终端，以使服务请求终端联机请求界面显示处理结果。

受理服务器及文件缓冲服务器具体处理过程参见上述实施例，本申请对此不再赘述。

为了更清楚说明本申请技术方案，下面以服务请求终端为ATM机为例进行详细说明：

步骤1：ATM机发送联机请求至受理服务器，其中，该联机请求用于查询某一时间段的历史转账信息，包括账号信息、交易类型及时间信息，该联机请求是由ATM根据客户输入信息生成的。

步骤2：受理服务器接收到联机请求后，先对联机请求携带的信息进行校验处理，如账号信息的正确性和存在性校验、交易类型的校验；验证通过后，进行如下处理：

首先，根据联机请求判断请求的数据量是否小于预定阈值。

如果判断结果为是，即请求的数据量小于预定阈值，则单次返回处理结果可满足需求情况，则将处理结果文件直接返回至ATM机。

如果判断结果为否，即请求的数据量大于或等于预定阈值，则单次返回处理结果不满足需求情况，检查该客户是否有预留手机号码，如有预留，则将该联机请求记录到联机请求控制表中，记录该联机请求的状态为未处理，如无预留，则提示服务请求终端提供手机号码，手机号码用于通知。

接着，逐个响应联机请求控制表中的每一联机请求，将生成的处理结果文件传输至文件缓冲服务器中。

步骤3：文件缓冲服务器监测ATM机联机请求界面是否关闭，若已关闭，则待处理结果文件接收完后通知相应的ATM机获取处理结果文件，若未关闭，则待处理结果文件接收完后将其直接提供给相应的ATM机，以使ATM机联机请求界面显示处理结果。具体的，文件缓冲服务器可通过通知ATM机刷新界面上的结果查询链接的方式(在线)，或短信、E-mail等方式(离线)提醒服务请求终端获取查询结果。

步骤4：ATM机未收到短信或处理结果的情况下，也可通过向受理服务器发送查询请求的方式查询联机请求的处理状态，具体的，联机请求处理状态分为：未处理、处理成功及处理失败三种情况。

对于未处理的联机请求，提示相应的ATM机于预定时间后再次发送查询请求。

对于处理失败的联机请求，将响应失败原因提供给相应的ATM机。

对于处理成功的联机请求，由文件缓冲服务器将处理结果文件名提供给相应的ATM机。进一步的，ATM机根据处理结果文件名向文件缓冲服务器发起下载请求，下载处理结果文件后，对处理结果文件进行加工整理展现给客户。

本申请提供一种联机请求处理方法、服务器及系统，与现有技术相比，具备以下优越性：

1.完善联机请求服务管理：受理服务器增加对服务请求终端的异步准实时请求量级管理，可有效避免因请求过于集中，而导致无法响应其它服务请求端的情况。

2.扩展数据传输长度：突破实时联机请求交互数据长度限制，通过时间换空间方式，满足时效性要求略低的系统间大量数据传输，在典型的联机、批量数据传输方式外，提供客户差异化服务。

3.降低交易响应时间：突破系统限制，通过单次提交查询申请异步准实时处理，减少交互次数，提升了客户体验。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述仅用于说明本申请的技术方案，任何本领域普通技术人员均可在不违背本发明的精神及范畴下，对上述实施例进行修饰与改变。因此，本发明的权利保护范围应视权利要求范围为准。