CN103036696A - 一种联机业务的实现方法、系统及相应设备 - Google Patents

Abstract

本发明的实施例公开了一种联机业务的实现方法、系统及相应设备，涉及业务支撑领域，解决了现有技术中联机业务执行过程中，受理率低，可靠性差的技术问题。本发明实施例的方法主要包括：自助终端针对第一业务请求，按照规定时间间隔将第一交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端；所述自助终端根据发送的所述第一交易请求消息组确认收到响应信息的情况。本发明主要用于联机业务。

Description

一种联机业务的实现方法、系统及相应设备

技术领域

本发明涉及业务支持领域，尤其涉及一种联机业务的实现方法、系统及相应设备。

背景技术

联机业务是指例如联网售票系统的计算机系统执行的业务，或者自助缴费机系统等执行的联机交易。其特点在于客户端发送交易请求给远端服务器，远端服务器响应请求，生成合适的数据回送给客户端。在通信系统中，用户自助终端经过多年的发展，已承载了缴费、查询、业务办理等众多功能，用户通过自助终端可方便、快捷地缴费、查询和办理业务。

自助缴费机系统主要由自助终端，后台服务端以及BOSS(Business&Operation Support System，业务运营支持系统)接口服务器组成。其中，自助终端分布在各处，并与后台服务端之间通过广域网连接。以缴费业务为例，系统中各设备交互流程主要包括：后台服务端响应自助终端发来的业务请求，将其转发给BOSS接口服务器，BOSS接口服务器受理该业务，将完成结果反馈给后台服务端，后台服务端再向自助终端反馈完成结果。

然而，现有技术中的自助缴费机系统自助终端和后台服务端之间经常发生故障，这是由于自助终端和后台服务端之间地理位置相距遥远，网络中存在大量不确定因素，如网络拥塞、瞬时中断，同时高并发访问等都会对后台服务端产生冲击造成执行的业务失败，导致系统可靠性差，用户满意度下降。

发明内容

本发明的实施例提供一种联机业务的实现方法、系统及相应设备，以便提高联机业务的可靠性。

为达到上述目的，本发明的实施例采用如下技术方案：

一种联机业务的实现方法，包括：

自助终端针对第一业务请求，按照规定时间间隔将第一交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端；

所述自助终端根据发送的所述第一交易请求消息组确认收到响应信息的情况。

进一步地，上述自助终端根据发送的所述第一交易请求消息组确认收到响应信息的情况具体包括：

当所述自助终端确认未得到所述响应信息时，发送探测包到所述后台服务端，并监控所述探测包的响应状况。

进一步地，上述监控所述探测包的响应状况具体包括：

当所述自助终端接收到响应的所述探测包时，针对所述第一业务请求按照所述规定时间间隔将第二交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端。

进一步地，上述第一和第二交易请求消息组中的每个交易请求消息均是相同的，且至少包括标识所述第一业务请求的交易标识码；所述后台服务端存储有记录下已成功接收到的交易请求消息中所包含的交易标识码的交易记录表；相应地，该方法还包括：

针对收到的所述第一和第二交易请求消息组中的任一所述交易请求消息，所述后台服务端根据所述任一所述交易请求消息包含的交易标识码和所述交易记录表确定是否向所述自助终端发送响应信息。

并且，在针对所述第一业务请求发送第二交易请求消息组后，该方法还包括：

当所述自助终端仍未接收到来自所述后台服务端的响应信息时，所述自助终端显示出错信息，并做回退处理。

一种自助终端，包括：

消息组发送模块，用于针对第一业务请求，按照规定时间间隔将第一交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端；

确认模块，用于根据发送的所述第一交易请求消息组确认收到响应信息的情况。

进一步地，该自助终端还包括：

探测模块，用于当确认模块确认未得到所述响应信息时，发送探测包到所述后台服务端。

重发模块，用于当接收到来着所述后台服务端的所述探测包时，针对所述第一业务请求按照所述规定时间间隔将第二交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端。

优选地，该自助终端还包括：

回退模块，用于当重发模块发送第二交易请求消息组后仍未接收到来自所述后台服务端的响应信息时，显示出错信息，并做回退处理。

一种服务器，包括：

接收模块，用于接收到来自自助终端的针对第一业务请求发送的交易请求消息，所述交易请求消息为交易请求消息组中的一个；

确定模块，用于确定是否为首次成功到所述交易请求消息；

响应模块，用于当确定是首次成功到所述交易请求消息时，发送响应信息到所述自助终端。

优选地，该服务器还包括：

记录模块，用于在交易记录表中记录下接收模块已成功接收到的交易请求消息中所包含的标识所述第一业务请求的交易标识码；存储模块，用于存储所述交易记录表；

相应地，上述确定模块包括：确定单元，用于针对收到的所述交易请求消息，判断所述交易请求消息中包含的交易标识码是否已记录于所述交易记录表；若所述交易标识码不存在于所述交易记录表中，则在所述交易记录表中记录所述标识码，再向所述自助终端发送响应信息；否则不作处理。

一种联机业务的实现系统，至少包括：上述自助终端和上述后台服务端。

本发明提供的联机业务的实现方案通过采用发送一交易请求消息组到后台服务端，并在第一交易请求消息组未得到响应时，使用探测包检测网络的技术手段，解决了由于网络瞬时拥塞、瞬时中断导致的单一交易请求消息无法到达后台服务端的技术问题，不仅可防止由于自助终端和后台服务端之间产生的网络拥塞、瞬时中断等导致业务失败的问题，还可提高业务受理成功率，有助于提高联机业务的可靠性。

附图说明

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

图1为本发明实施例一中的联机业务的实现方法的流程示意图；

图2为本发明实施例二中的联机业务的实现方法的系统示意图；

图3为本发明实施例二中自助终端侧的联机业务的实现方法的流程示意图；

图4为本发明实施例二中发送次数和受理成功率之间的关系示意图；

图5为本发明实施例二中发送间隔和网络流量率之间的关系示意图；

图6为交易请求消息的格式示意图；

图7为本发明实施例二中后台服务端侧的联机业务的实现方法的流程示意图；

图8为本发明实施例三中的自助终端的结构示意图；

图9为本发明实施例四中的服务器的结构示意图；

图10为本发明实施例五中的联机业务的实现系统的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。并且，以下各实施例均为本发明的可选方案，实施例的排列顺序及实施例的编号与其优选执行顺序无关。

实施例一

本实施例提供一种联机业务的实现方法，如图1所示，包括：

步骤101，自助终端针对第一业务请求按照规定时间间隔将第一交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端；

其中，该交易请求消息组即为一组交易请求消息，该组交易请求消息中的每个交易请求消息都是相同的，并且均是针对第一业务请求而发出的，也即相当于重复多次发送同一交易请求消息，每个交易请求消息发送之前均无需确定上一个发送的交易请求消息是否成功到达后台服务器。

现有技术中，针对一次业务请求仅发送一次业务请求消息，但是在本实施例中却采用发送一组交易请求消息，这是因为只要其中有一个交易请求消息能被后台服务端成功接收即可保证受理成功。因此将单次发送变成多次发送有益于克服瞬时网络拥塞。

步骤102，自助终端根据发送的第一交易请求消息组确认收到响应信息的情况。

其中，该响应信息指的是针对该第一业务请求的处理结果。收到响应信息的情况包括：自助终端确认未得到响应信息以及自助终端确认得到响应信息的情况。

步骤103，当自助终端确认未得到所述响应信息时，发送探测包到所述后台服务端，并监控所述探测包的响应状况；

其中，上述监控所述探测包的响应状况具体指的是监控该探测包是否从后台服务端返回。

当一组交易请求消息均没有得到后台服务端响应时，说明第一组发送的数次交易请求消息可能全部丢失，故而此时需要诊断网络状况，因此监控探测包响应状况的目的是可以用于定位第一交易请求消息组全部失效的原因是否是由于瞬时网络拥塞、网络中断，或者高并发交易冲击后台服务端等。

步骤104，当所述自助终端接收到响应的所述探测包时，说明第一交易请求消息组全部失效是由于瞬时网络拥塞、网络中断等原因，并且目前网络已不存在该原因，已恢复正常，因此可以针对所述第一业务请求按照所述规定时间间隔将第二交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端，进而再次请求后台服务端受理。

本实施例提供的联机业务的实现方法，可以避免由于瞬时网络拥塞等突发高访问量造成的交易请求发送失败的技术问题，进而取得了可提高业务受理成功率，提高联机业务处理的可靠性的技术效果。

实施例二

本实施例具体结合图2所示的系统示意图，提供一种联机业务的实现方法，如图2所示，在该方法中，主要涉及放置在营业厅等处的自助终端，以及放置在机房的自助系统后台服务端。其中，自助终端也具有与现有技术自助终端相同的业务交易功能，如接收用户输入，向后台服务端发送交易请求消息，接收后台服务端响应，向用户显示交易结果等。后台服务端也具有与现有的后台服务端相同的交易处理功能，如接收自助终端的交易请求消息，并向BOSS接口服务器转发等。

但是，本实施例中的自助终端和后台服务端的不同之处主要在于，自助终端具备了智能检错功能，后台服务端具备了剔重功能。下面以执行的第一业务是常用的缴费交易为例，具体描述该上述两功能的实现方法该方法，如图3所示，包括：

步骤201，用户缴费后按下确认键后，自助终端针对缴费业务请求发送第一交易请求消息组到后台服务端。

具体而言，自助终端针对缴费业务请求，按照规定时间间隔将第一交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端。其中，每个交易请求消息均是相同的，具体格式可参考图6。即按照规定时间间隔重复发送同一交易请求消息来请求缴费业务。

这些交易请求消息的发送间隔非常短，而且发送后一次交易请求时并不需要判断前一次交易请求消费是否得到返回的响应信息，故而多次交易请求消息中只要有一次能被后台服务端成功接收即可保证受理成功。优选地，根据实测结果参照图4所示可知，发送次数和受理成功率之间有如下关系：

重发次数超过3次后，缴费交易受理成功率的升幅趋于平缓，考虑到重发交易会对网络和自助服务端带来额外的压力，重发次数不宜过多，因此可优选重发次数为三次。又由于上行交易请求的数据量极小(一般不超过50字节/次)，这与大数据量的下行数据相比几乎可以忽略不计，因此重发交易请求消息的方案并不会给网络带来额外压力。

更优选地，根据实测结果可知，多个交易请求消息之间的发送间隔对成功率影响不大，但是间隔过短，会给自助服务端带来较大的并发压力。以自助服务端的网络流量作为衡量并发压力的指标，参照图5所示，并发压力和发送间隔间有如下关系：

时间间隔超过3秒后，网络流量趋于平缓，多次发送带来的并发压力影响趋于缓和。因此，在本实施例中，可优选发送间隔为3秒。

需要说明的是，上述发送次数和发送时间间隔仅是本发明实施例提供的一种优选的方式，本领域技术人员均知根据实际应用的需要或网络环境的不同这些取值是可以变换的，因此本发明的保护范围并不限于本实施例中提出的上述发送次数和上述时间间隔。

此外，优选地，在本实施例中，为了适应上述发送交易请求消息组机制，上述第一交易请求消息组中的每个交易请求消息至少包括标识所述第一业务请求的交易标识码。具体方案可通过如图6所示的方式实现：除了交易类型代码，交易请求正文外，在交易请求消息中新增加了交易标识码，并且，该交易标识码由自助终端编号，交易发起时间，4位随机码组成。其中交易发起时间精确到毫秒、随机码由自助终端随机生成，上述三个要点组合形成的数字序列，可以保证缴费交易记录的唯一性。

步骤202，第一交易请求组发送后，自助终端启动交易请求计时，等待后台服务端的响应信息(其中，后台服务端接收到交易请求消息后的具体处理过程可参考下述步骤301-305)。若在规定计时内收到来自后台服务端的响应信息，则执行步骤206；否则执行步骤203。

步骤203，自助终端向后台服务端发送ICMP(Internet Control MessageProtocol，Internet控制报文协议)数据包，并监控ICMP数据包的响应状况；若后台服务端接收到响应的ICMP数据包，则执行步骤204，否则执行步骤207。

计时器时间耗尽后，仍没有收到后台服务端的响应，说明第一组多次发送的交易请求消息可能全部丢失，自助终端服务端发送ICMP数据包，根据ICMP包的响应情况对当前环境做出诊断。即诊断第一组交易请求消息全部失效的原因是否由于瞬时网络拥塞、网络中断还是高并发交易冲击服务端。

在TCP/IP协议中ICMP工作于网络层，主要用于在主机与路由器之间传递控制信息。和普通的数据包相比ICMP数据包非常小，格式非常简单，无论是网络设备还是服务器，处理ICMP的开销都非常小。因此，即使网络发生瞬时拥塞，应用数据在发送过程中丢失，只要网络没有彻底中断，ICMP数据包通常都不受影响。据此原理，在第一交易请求消息组没有得到后台服务端响应时，向后台服务端发送ICMP数据包，再根据ICMP数据的返回结果来判断网络是瞬时拥塞还是中断。若有ICMP数据包有返回，说明网络畅通，可能由于网络瞬时拥塞导致第一组业务请求全部丢失，因此可以执行步骤204。若ICMP数据包无返回，则说明网络彻底中断，可执行步骤207。

步骤204，自助终端针对上述缴费业务请求按照所述规定时间间隔将第二交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端。

该第二交易请求消息组与第一请求消息组格式、功能等均相同，发送次数和发送时间间隔也可以参照上述第一交易请求消息组中的，并且均是由多个相同的交易请求消息组成，用于请求缴费业务。

步骤205，第二交易请求组发送后，自助终端启动交易请求计时，等待后台服务端的响应信息。若在规定计时内收到来自后台服务端的响应信息，则执行步骤206；否则执行步骤207。

步骤206，自助终端根据接收到的响应信息，显示确切的缴费交易结果，或缴费交易成功，或缴费交易失败，给用户退款。

步骤207，自助终端显示出错信息，并做回退处理。

例如：自助终端显示缴费失败，并给用户退款。同时营业终端显示设备故障，退出工作状态，不再接收新的业务交易请求。

需要说明的是，本实施例是以发送2组交易请求消息，一次探测包为例进行描述的，但是具体发送交易请求消息组的数量，以及探测包的数量并不受限制，根据实际需要也可以设计成更多次的发送次数。

本实施例提供的上述方案通过多次发送交易请求消息以及在未得到响应时，发送探测包得技术手段，解决了现有技术中由于网络瞬时拥塞，突发高访问率等原因造成的联机业务交易失败的技术问题，进而取得了提高交易受理成功率，增加联机业务交易可靠性的技术效果。

上述步骤201-207可以实现自助终端的智能检错功能。下面具体介绍后台服务端接收到交易请求消息后，实现剔重功能的处理过程。

其中，本实施例中提供的后台服务端存储有用于记录下已成功接收到的交易请求消息中所包含的交易标识码的交易记录表。具体过程，如图7所示，包括：

步骤301，后台服务端接收来自自助终端发来的请求缴费业务的交易请求消息；

后台服务端可能接收到第一或第二交易请求消息组中任一的交易请求消息，针对该任一交易请求消息，后台服务端是否是首次接收到针对步骤201中的缴费业务请求发送的交易请求消息。具体而言，

步骤302，后台服务端接收到任一交易请求消息时，根据其包含的交易标识码和存储的交易记录表确定是否向自助终端发送响应信息。即：后台服务端即判断该任一交易请求消息中包含的交易标识码是否已记录于所述交易记录表；若所述交易标识码不存在于所述交易记录表中，则代表首次接收成功到该交易请求消息，因此需要执行步骤303；否则代表该交易请求消息已经成功接收到过，并已经处理过，因此需要执行步骤305。

步骤303，后台服务端在上述交易记录表中记录所述标识码，并向BOSS接口服务器转发该交易请求消息。

步骤304，后台服务端接收到BOSS接口服务器返回的处理结果，并将该处理结果回复到自助终端(不执行下述步骤305)。

步骤305，对该交易请求消息不作处理。

在服务端增加了对重复发送的交易请求消息的剔重功能，即服务端根据交易标识码对交易请求消息进行甄别，对前期已经接收成功过的交易请求消息，不做处理。

本实施例提供的上述方案，根据交易标识码进行的唯一性剔重，避免由于多次重复交易请求消息这种冗余机制的引入，使单笔业务交易被错误计算为多笔业务交易的问题，可取得在提高交易成功率的同时，不影响交易准确度，加强交易可靠性的技术效果。

实施例三

本实施例提供一种自助终端，可用于作为实施一或二中的自助终端使用。如图8所示，包括：消息组发送模块30，确认模块31。

其中，消息组发送模块30，用于针对第一业务请求，按照规定时间间隔将第一交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端；确认模块31，用于根据发送的第一交易请求消息组确认收到响应信息的情况。

优选地，还包括：探测模块32，重发模块33。

探测模块32，用于当确认模块确认未得到所述响应信息时，发送探测包到所述后台服务端。重发模块33，用于当接收到来着所述后台服务端的所述探测包时，针对所述第一业务请求按照所述规定时间间隔将第二交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端。

进一步，该自助终端还可包括：回退模块34。

回退模块34，用于当重复模块33发送过第二交易请求消息组后，仍未接收到来自所述后台服务端的响应信息时，显示出错信息，并做回退处理。

其中，确认模块31包括：消息组发送单元311，用于针对所述第一业务请求，按照规定时间间隔将所述第一或第二交易请求消息组中的多个交易请求消息逐一发送到所述后台服务端。

优选地，该交易请求消息组的每个交易请求消息中除了交易类型代码，交易请求正文外，新增加了交易标识码，并且，该交易标识码由自助终端编号，交易发起时间，4位随机码组成。其中交易发起时间精确到毫秒、随机码由自助终端随机生成，上述三个要点组合形成的数字序列，可以保证缴费交易记录的唯一性。

本实施例提供自助终端可以针对同一业务交易请求重复向后台服务端发送交易请求消息，并在确定未接收到响应信息时发送探测包检测网络状态进而确定是否需要再发送交易请求消息组，由此防止因网络瞬时拥塞等突发高访问造成的交易请求失败的问题，进而提高了交易受理成功率，增加了联机业务的可能性。

实施例四

本实施例提供一种服务器，可用于作为实施一或二中的后台服务端。如图9所示，包括：接收模块41，确定模块42，响应模块43。

接收模块41，用于接收到来自自助终端的针对第一业务请求发送的交易请求消息，所述交易请求消息为交易请求消息组中的一个；确定模块42，用于确定是否为首次成功到所述交易请求消息；响应模块43，用于当确定是首次成功到所述交易请求消息时，将BOSS接口服务器对该交易请求消息的回复的响应信息转发到所述自助终端。

优选地，该服务器还包括：记录模块44，存储模块45。

记录模块44，用于在交易记录表中记录下已成功接收到的交易请求消息中所包含的标识所述第一业务请求的交易标识码；存储模块45，用于存储所述交易记录表；

进一步，确定模块42包括：确定单元421，用于针对收到的所述交易请求消息，判断所述交易请求消息中包含的交易标识码是否已记录于所述交易记录表；若所述交易标识码不存在于所述交易记录表中，则在所述交易记录表中记录所述标识码，再向所述自助终端发送响应信息；否则不作处理。

本实施例提供的服务器可以对自助终端重复发送的交易请求消息进行剔重，避免由于多次重复交易请求消息这种冗余机制的引入，使单笔业务交易被错误计算为多笔业务交易的问题，可取得在提高交易受理成功率的同时，不影响交易准确度，加强交易可靠性的技术效果。

实施例五

本实施例提供一种联机业务的实现系统，包括BOSS接口服务器，以及至少一个自助终端和至少一个后台服务端。如图10所示，其中，BOSS接口服务器50可同现有技术中的，每台自助终端51可如实施四中的自助终端所述，每台后台服务端52可如实施例五中的服务器所述，具体自助终端51和每台后台服务端52的功能和作用在此不赘述。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘，硬盘或光盘等，包括若干指令用以使得一台设备执行本发明各个实施例所述的方法。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (12)

1.一种联机业务的实现方法，其特征在于，包括：

自助终端针对第一业务请求，按照规定时间间隔将第一交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端；

所述自助终端根据发送的所述第一交易请求消息组确认收到响应信息的情况。

2.根据权利要求1所述的联机业务的实现方法，其特征在于，所述自助终端根据发送的所述第一交易请求消息组确认收到响应信息的情况具体包括：

当所述自助终端确认未得到所述响应信息时，发送探测包到所述后台服务端，并监控所述探测包的响应状况。

3.根据权利要求2所述的联机业务的实现方法，其特征在于，所述监控所述探测包的响应状况具体包括：

当所述自助终端接收到响应的所述探测包时，针对所述第一业务请求按照所述规定时间间隔将第二交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端。

4.根据权利要求3所述的联机业务的实现方法，其特征在于，所述第一和第二交易请求消息组中的每个交易请求消息均是相同的，且至少包括标识所述第一业务请求的交易标识码；所述后台服务端存储有记录下已成功接收到的交易请求消息中所包含的交易标识码的交易记录表；该方法还包括：

针对收到的所述第一和第二交易请求消息组中的任一所述交易请求消息，所述后台服务端根据所述任一所述交易请求消息包含的交易标识码和所述交易记录表确定是否向所述自助终端发送响应信息。

5.根据权利要求4所述的联机业务的实现方法，其特征在于，所述后台服务端根据所述任一所述交易请求消息包含的交易标识码和所述记录表确定是否向所述自助终端发送响应信息具体包括：

所述后台服务端接收到所述任一交易请求消息时，判断所述任一交易请求消息中包含的交易标识码是否已记录于所述交易记录表；

若所述交易标识码不存在于所述交易记录表中，则在所述交易记录表中记录所述标识码，将向所述自助终端发送响应信息；否则不作处理。

6.根据权利要求3至5中任意一项所述的联机业务的实现方法，其特征在于，在针对所述第一业务请求按照规定时间间隔将第二交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端后，该方法还包括：

当所述自助终端仍未接收到来自所述后台服务端的响应信息时，所述自助终端显示出错信息，并做回退处理。

7.一种自助终端，其特征在于，包括：

消息组发送模块，用于针对第一业务请求，按照规定时间间隔将第一交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端；

确认模块，用于根据发送的所述第一交易请求消息组确认收到响应信息的情况。

8.根据权利要求7所述的自助终端，其特征在于，该终端还包括：

探测模块，用于当确认模块确认未得到所述响应信息时，发送探测包到所述后台服务端。

重发模块，用于当接收到来着所述后台服务端的所述探测包时，针对所述第一业务请求按照所述规定时间间隔将第二交易请求消息组中的多个交易请求消息逐一无确定地发送到所述后台服务端。

9.根据权利要求8所述的自助终端，其特征在于，还包括：

回退模块，用于当重发模块发送第二交易请求消息组后仍未接收到来自所述后台服务端的响应信息时，显示出错信息，并做回退处理。

10.一种服务器，其特征在于，包括：

接收模块，用于接收到来自自助终端的针对第一业务请求发送的交易请求消息，所述交易请求消息为交易请求消息组中的一个；

确定模块，用于确定是否为首次成功到所述交易请求消息；

响应模块，用于当确定是首次成功到所述交易请求消息时，将业务运营支持系统BOSS接口服务器对该交易请求消息的回复的响应信息转发到所述自助终端。

11.根据权利要求10所述的服务器，其特征在于，

该服务器还包括：

记录模块，用于在交易记录表中记录下已成功接收到的交易请求消息中所包含的标识所述第一业务请求的交易标识码；

存储模块，用于存储所述交易记录表；

所述确定模块包括：确定单元，用于针对收到的所述交易请求消息，判断所述交易请求消息中包含的交易标识码是否已记录于所述交易记录表；若所述交易标识码不存在于所述交易记录表中，则在所述交易记录表中记录所述标识码，再向所述自助终端发送响应信息；否则不作处理。

12.一种联机业务的实现系统，其特征在于，至少包括：如权利要求7至9中任意一项所述的自助终端，和如权利要求10或11中任意一项所述的后台服务端。

Images