CN110324317B - 业务处理方法、装置、设备及存储介质 - Google Patents

Abstract

本发明属于通信技术领域，公开了一种业务处理方法、装置、设备及存储介质。该方法包括：接收用户通过呼叫组件触发的呼叫业务请求，根据呼叫业务请求确定待处理的呼叫业务的识别号；根据预先构建的映射关系表，确定识别号对应的呼叫业务的业务种类；根据业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出呼叫组件与软交换平台通信所需的TCP长连接；利用TCP长连接，将呼叫业务请求发送至软交换平台的事件处理接口，由事件处理接口对呼叫业务进行处理。通过上述方式，显著提升了呼叫中心的并发性能，从而无需在大量服务器上部署呼叫中心业务，在兼顾资源的同时，有效缩短了部署周期。

Description

业务处理方法、装置、设备及存储介质

技术领域

本发明涉及通信技术领域，尤其涉及一种业务处理方法、装置、设备及存储介质。

背景技术

呼叫中心，又称客户服务中心，起源于20世纪30年代，最初是把用户的呼叫转移到应答台或者专家处。此后，随着要转移的呼叫和应答增多，开始建立起交互式语音应答系统，这种系统能把客户部分常见问题的应答实现由机器“自动话务员”来应答和处理。传统意义上的呼叫中心，是指以人接电话为主的呼叫响应中心，为客户提供各种电话响应服务。

目前，各大企业推出的呼叫中心系统，在进行外呼操作时，具体是由相应功能组件使用超文本传输协议(Hyper Text Transfer Protocol，HTTP)调用FreeSWITCH(一个电话的软交换解决方案)中自带的远程过程调用(Remote Procedure Cal，RPC)接口，通过RPC接口实现外呼功能。然而，FreeSWITCH自带的RPC接口支持的最大并发量都不足20。但是，随着服务行业规模的不断扩大，各大企业推出的呼叫中心系统，在同一时刻需要支持的并发量需要高达几千。因此，如果采用FreeSWITCH自带的RPC接口，需要设置多台服务器，并在服务器上部署呼叫业务。这样不仅会面临部署周期长的问题，还会导致严重的资源浪费。

所以，亟需提供一种业务处理方法，以解决现有技术部署周期长，以及难以兼顾资源占用和并发性能的问题。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

发明内容

本发明的主要目的在于提供一种业务处理方法、装置、设备及存储介质，旨在解决现有技术部署周期长，以及难以兼顾资源占用和并发性能的技术问题。

为实现上述目的，本发明提供了一种业务处理方法，所述方法包括以下步骤:

接收用户通过呼叫组件触发的呼叫业务请求，根据所述呼叫业务请求确定待处理的呼叫业务的识别号；

根据预先构建的映射关系表，确定所述识别号对应的所述呼叫业务的业务种类，所述映射关系表为所述识别号与所述业务种类之间的对应关系；

根据所述业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接；

利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口，由所述事件处理接口对所述呼叫业务进行处理。

优选地，所述根据所述业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接的步骤之前，所述方法还包括：

在原生远程过程调用组件的基础上使用java编程语言，为各呼叫业务分配对应的端口号，得到所述重定义远程过程调用组件。

优选地，所述根据所述业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接的步骤，包括：

根据所述业务种类和所述重定义远程过程调用组件，确定所述呼叫业务对应的端口号；

根据所述端口号，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接。

优选地，所述根据所述端口号，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接的步骤，包括：

将所述端口号作为索引项，从预先记录的TCP长连接记录表中查找所述端口号对应的TCP长连接的标识号；

若查找到所述端口号对应的TCP长连接的标识号，则根据所述标识号，从所述预先构建的TCP连接池中查找出所述标识号对应的TCP长连接，并将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接；

若未查找到所述端口号对应的TCP长连接的标识号，则创建一个TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接，并将创建的TCP长连接的标识号更新到所述TCP长连接记录表中。

优选地，所述将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接的步骤之前，所述方法还包括：

判断查找出的所述TCP长连接是否处于空闲状态；

其中，所述将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接的步骤，包括：

若查找出的所述TCP长连接处于空闲状态，则将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接。

优选地，所述利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口的步骤之前，所述方法还包括：

判断所述呼叫业务请求是否符合预设要求；

其中，所述利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口的步骤，包括：

若所述呼叫业务请求符合预设要求，则利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口。

优选地，所述判断所述呼叫业务请求是否符合预设要求的步骤之后，所述方法还包括：

若所述呼叫业务请求不符合预设要求，则获取所述呼叫业务请求对应的异常日志文件；

将所述呼叫业务请求和所述异常日志文件发送至管理人员的终端设备，以使所述管理人员能够根据所述呼叫业务请求和所述异常日志文件，定位出导致所述呼叫业务请求不符合预设要求的原因。

此外，为实现上述目的，本发明还提出一种业务处理装置，所述装置包括：

第一确定模块，用于接收用户通过呼叫组件触发的呼叫业务请求，根据所述呼叫业务请求确定待处理的呼叫业务的识别号；

第二确定模块，用于根据预先构建的映射关系表，确定所述识别号对应的所述呼叫业务的业务种类，所述映射关系表为所述识别号与所述业务种类之间的对应关系；

查找模块，用于根据所述业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接；

发送模块，用于利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口，由所述事件处理接口对所述呼叫业务进行处理。

此外，为实现上述目的，本发明还提出一种业务处理设备，所述设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的业务处理程序，所述业务处理程序配置为实现如上文所述的业务处理方法的步骤。

此外，为实现上述目的，本发明还提出一种存储介质，所述存储介质上存储有业务处理程序，所述业务处理程序被处理器执行时实现如上文所述的业务处理方法的步骤。

本发明提供的业务处理方案，通过预先构建传输控制协议TCP连接池，并在TCP连接池中添加TCP长连接，利用TCP长连接在通信双方完成了一次通信操作后不会自动关闭的特性，使得后续通信操作可以直接复用已有的TCP长连接，无需重复执行创建操作，从而有效的减小了对部署呼叫中心系统的服务器资源的占用。

此外，本发明提供的业务处理方案，呼叫中心系统在接收到用户触发的任意呼叫业务请求时，通过确定待处理的呼叫业务的识别号，并根据预先构建的映射关系表确定所述识别号对应的呼叫业务的业务种类，然后根据确定的业务种类和预先编译获得的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出用于处理本次呼叫业务的TCP长连接，最终根据查找出的TCP长连接，将用户触发的呼叫业务请求发送至软交换平台的事件处理接口进行处理，使得呼叫业务能够分端口、分TCP长连接处理，实现了呼叫业务的疏通，从而显著提升了呼叫中心系统的并发性能。

并且，通过这种呼叫业务的处理方案，无需在大量服务器上部署呼叫中心业务，从而在兼顾服务器资源的同时，有效缩短了呼叫中心系统的部署周期。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的业务处理设备的结构示意图；

图2为本发明业务处理方法第一实施例的流程示意图；

图3为本发明业务处理方法第二实施例的流程示意图；

图4为本发明业务处理装置第一实施例的结构框图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

参照图1，图1为本发明实施例方案涉及的硬件运行环境的业务处理设备结构示意图。

如图1所示，该业务处理设备可以包括：处理器1001，例如中央处理器(CentralProcessing Unit，CPU)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(WIreless-FIdelity，WI-FI)接口)。存储器1005可以是高速的随机存取存储器(RandomAccess Memory，RAM)存储器，也可以是稳定的非易失性存储器(Non-Volatile Memory，NVM)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的结构并不构成对业务处理设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及业务处理程序。

在图1所示的业务处理设备中，网络接口1004主要用于与网络服务器进行数据通信；用户接口1003主要用于与用户进行数据交互；本发明业务处理设备中的处理器1001、存储器1005可以设置在业务处理设备中，所述业务处理设备通过处理器1001调用存储器1005中存储的业务处理程序，并执行本发明实施例提供的业务处理方法。

本发明实施例提供了一种业务处理方法，参照图2，图2为本发明一种业务处理方法第一实施例的流程示意图。

本实施例中，所述业务处理方法包括以下步骤：

步骤S10，接收用户通过呼叫组件触发的呼叫业务请求，根据所述呼叫业务请求确定待处理的呼叫业务的识别号。

具体的说，本实施例的执行主体为呼叫中心系统。应当理解的是，在实际应用中，所述呼叫中心系统具体可以部署在任意类型的服务器上，比如传统的物理服务器(占用实际物理地址)，或者虚拟云服务器，此处不做限制。

此外，在实际应用中，所述呼叫中心系统可以由多种功能组件组成，比如目前常用的FreeSWITCH(一个电话的软交换解决方案，在实际应用中可以将其称为一个软交换平台)，以及上述提到的用于进行呼叫业务的呼叫组件。

需要说明的是，上述所说的呼叫组件，具体可以包括软电话装置(即一个虚拟的电话呼叫软件)、坐席话机等，此处不再一一列举，对此也不做任何限制。

所述FreeSWITCH具体可以包括呼叫中心(Callcenter)模块、远程过程调用(Remote Procedure Cal，RPC)模块、事件套接字(event-socket)模块等，此处不再一一列举，对此也不做任何限制。

此外，值得一提的是，由于实际应用中，呼叫中心系统涉及的呼叫业务有很多种，因而为了便于区分各种呼叫业务，在部署呼叫中心系统之前，可以根据业务需求，预先为呼叫中心系统支持的呼叫业务分配用于标识其唯一性的识别号。

比如，为呼入业务分配的识别号是CI，为呼出业务分配的识别号是CO。

相应地，在接收到用户通过软电话装置或者坐席话机等呼叫组件触发的呼叫业务请求时，系统会自动根据触发的呼叫业务请求确定待处理的呼叫业务的识别号，比如在用户触发的呼叫业务请求对应的呼叫业务为呼入业务时，则获取到的识别号便是CI，相应地，在用户触发的呼叫业务请求对应的呼叫业务为呼出业务时，则获取到的识别号便是CO。

进一步地，在实际应用中，呼叫中心系统支持的呼入业务和呼出业务通常会有多种，因而为了便于区分，还可以进一步细化各呼入业务对应的识别号，比如设置为CI1、CI2等。

相应地，各呼出业务对应的识别号，可以设置为CO1、CO2等。

应当理解的是，以上仅为举例说明，对本发明的技术方案并不构成任何限定，在具体应用中，本领域的技术人员可以根据需要进行设置，本发明对此不做限制。

步骤S20，根据预先构建的映射关系表，确定所述识别号对应的所述呼叫业务的业务种类。

具体的说，上述所说的映射关系表主要是用来记录所述识别号与所述业务种类之间的对应关系的。

此外，值得一提的是，由于在实际作业中除了可以将呼叫业务划分为呼入业务和呼出业务两大类，还可以根据触发呼叫业务请求的呼叫组件的不同、调用接口的不同进一步细化。

比如，对于呼入业务可以细化为：通过坐席话机直接调用FreeSWITCH的呼入业务、调用排队派工接口的呼入业务，此处不再一一列举，对此也不做限制。

相应地，对于呼出业务可以细化为：通过坐席话机直接调用FreeSWITCH的呼出业务、通过软电话调用原生RPC模块的呼出业务，通过软电话调用重定义远程过程调用组件(以下称为RPC2.0模块/组件)的呼出业务等，此处不再一一列举，对此也不做限制。

相应地，为上述各个呼入业务和各个呼出业务分配的识别号也需要有所差异，为了便于理解，以下给出一个具体的映射关系表，详见映射关系表1。

映射关系表1

相应地，如果根据用户触发的所述呼叫业务请求确定的待处理的呼叫业务的识别号为CI1，则根据上述映射关系表1可以确定，所述CI1对应的所述呼叫业务的业务种类为：通过坐席话机直接调用FreeSWITCH的呼入业务。

需要说明的是，以上给出的仅为一种具体的映射关系表，对本发明的技术方案并不构成任何限定，在具体实现中，本领域的技术人员可以根据需要设置，此处不做限制。

步骤S30，根据所述业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接。

为了便于理解重定义远程过程调用组件的功能，以下先对原生远程过程调用组件进行简要说明。

具体的说，所述原生远程过程调用组件，即FreeSWITCH自带的RPC(RemoteProcedure Call)，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如传输控制协议(TransmissionControl Protocol，TCP)或用户数据报协议(User Datagram Protocol，UDP)，为通信程序之间携带信息数据。在呼叫中心系统中的作用就是提供服务器端服务(以下称为：serverlet服务)，允许使用万维网(World Wide Web，web)的方式管理FreeSWITCH。

此外，在实际应用中，呼叫中心系统的其他功能组件通过调用基于该协议生成的RPC模块/组件，可以使用HTTP协议与FreeSWITCH通信并执行任何应用程序编程接口(Application Programming Interface，API)对应的API命令。

然而，FreeSWITCH自带的RPC模块/组件所能支持的并发最多只有20。因而，为了同时兼顾呼叫中心系统的资源和并发性，需要在执行步骤S30之前，使用java编程语言，对原生远程过程调用组件(即RPC模块/组件)进行编译，获得所述重定义远程过程调用组件，为了便于区分本实施例中将其称为RPC2.0模块/组件。

关于在原生远程过程调用组件的基础上使用java编程语言，得到所述重定义远程过程调用组件的操作，具体是使用java编程语言在原生远程过程调用组件的基础上，为呼叫中心系统支持的各种呼叫业务分配预先设定的端口号，然后重新打包得到。

具体的说，所述为呼叫中心系统支持的各种呼叫业务分配预先设定的端口号的操作，可以大致如下：

比如，为通过话机直接调用FreeSWITCH外呼业务和呼入业务分配5060的端口号，为排队派工的呼入业务分配5080的端口号，为通过ESL接口调用的呼叫业务分配8021的端口号，为通过软电话调用原生RPC模块/组件调用的呼叫业务分配7002-7007的端口号，为通过软电话调用RPC2.0模块/组件的呼叫业务分配30847的端口号。

需要说明的是，上述所说的ESL接口，具体是FreeSWITCH提供的一个接口，全称是event-sodket-library，在实际应用中通常被理解为电话事件处理组件。通过ESL接口，FreeSWITCH实现接受外部的控制，将FreeSWITCH发出的消息事件进行过滤、并封装成DTO(数据传输对象)，具体使用就是通过ESL获取坐席的软电话状态，坐席外呼或呼入的时候实现电话条翻转，标识当前坐席的状态，比如示忙，通话中，空闲等。

此外，应当理解的是，上述给出的端口号是根据业务需求自行分配的，并非固定，在实际应用中，可以根据当前部署的呼叫中系统所支持的呼叫业务的业务种类、数量，以及服务器具备的端口号进行合理分配，此处不做限制。

通过上述描述不难发现，由于在预先编译的重定义远程过程调用组件中设置了各个业务种类的呼叫业务对应端口号，因而在确定待处理的呼叫业务的业务种类后，上述步骤S30中的操作，具体可以通过如下所示的两个子步骤实现：

(1)根据所述业务种类和所述重定义远程过程调用组件，确定所述呼叫业务对应的端口号。

应当理解的是，由于在编译重定义远程过程调用组件时，重新分配了每个呼叫业务对应的端口号，因而在确定待处理的呼叫业务的业务种类后，可以快速确定所述呼叫业务对应的端口号。

(2)根据所述端口号，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接。

具体的说，此处所说的TCP即传输控制协议(Transmission Control Protocol，TCP)，通常情况下，基于TCP协议的连接，大致有TCP连接、TCP短连接和TCP长连接。

其中，TCP连接在建立过程中需要完成三次握手，释放过程需要完成四次握手，因而每个TCP连接的建立都是需要资源消耗和时间消耗。

TCP短连接在建立过程中则仅需完成一次握手，便可以进行通信操作，但是在一次通信操作完成后，必需要执行一次close操作来断开所述TCP短链接，也就是说采用TCP短链接进行通信，需要重复执行创建和关闭的操作，因而会给占用过多的设备资源，导致部署呼叫中心系统的服务器出现卡顿、阻塞等问题。

而TCP长连接则是在建立之后，即便通信双方完成了一次通信操作，该TCP长连接也不会自动关闭，因而后续的通信操作可以继续复用该TCP长连接，而无需重复执行创建操作，因而可以有效的减小对部署呼叫中心系统的服务器资源的占用。

通过上述描述不难发现，由于TCP长连接在创建后不会自动关闭，可以直接复用，因而为了能够提升呼叫业务的处理速度，可以预先构建用于存储这些TCP长连接的TCP连接池，从而在确定所述呼叫业务对应的端口号后，直接根据所述端口号，从TCP连接池中查找所述呼叫组件与软交换平台通信所需的TCP长连接即可。

为了便于理解上述步骤(2)中所说的根据所述端口号，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接的方式，本实施例给出一种具体的实现方式，大致如下：

(2-1)将所述端口号作为索引项，从预先记录的TCP长连接记录表中查找所述端口号对应的TCP长连接的标识号。

应当理解的是，在实际应用中，为了便于检索，在创建TCP长连接记录表时，会采用键值对的方式，将具有唯一性的端口号作为检索所需的关键信息存入记录表的key(键)区域，然后将与各端口号对应的TCP长连接的标识号存入与存储各端口号的key对应的value(值)区域。因而，查找所述呼叫组件与软交换平台通信所需的TCP长连接时，先利用所述端口号，从预先记录的TCP长连接记录表中查找所述端口号对应的TCP长连接的标识，然后再进行后续查找操作，不仅方便查找，并且可以便于扩展和管理。

(2-2)若查找到所述端口号对应的TCP长连接的标识号，则根据所述标识号，从所述预先构建的TCP连接池中查找出所述标识号对应的TCP长连接，并将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接。

应当理解的是，每一个TCP长连接都会有一个属于自己的标识号，因而根据查找到的标识号，可以快速、准确的从预先构建的传输控制协议TCP连接池中查找到所述标识号对应的TCP长连接。

此外，值得一提的是，由于在实际应用中，为了尽可能的节约设备资源，添加在预先构建的TCP连接池中的TCP长连接的个数是有限的，所以可能会存在查找到的TCP长连接目前正处于使用状态。因而，为了保证用户触发的呼叫业务请求能够被及时处理，在将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接之前，还可以先判断一下查找到的所述TCP长连接是否处于空闲状态，若处于空闲状态，则直接拿来复用；否则，重新创建一个TCP长连接。

(2-3)若未查找到所述端口号对应的TCP长连接的标识号，则创建一个TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接，并将创建的TCP长连接的标识号更新到所述TCP长连接记录表中。

关于TCP长连接的创建，在具体实现时，本领域的技术人员可以参考现有TCP的相关文档自行实现，此处不再赘述。

此外，在实际应用中，上述TCP连接池中存在的TCP长连接，具体可以是在呼叫中心系统第一次接收到呼叫业务请求时创建的，并且在所述TCP长连接处于空闲状态时，可以利用所述TCP长连接定时发送心跳包，以保证所述TCP长连接能够在使用过程中，始终处于连接状态。

应当理解的是，以上给出的仅为一种具体的实现方式，对本发明的技术方案并不构成任何限定，在具体应用中，本领域的技术人员可以根据需要进行设置，本发明对此不做限制。

此外，值得一提的是，本实施例中所说的所述呼叫组件与软交换平台通信所需的TCP长连接，具体是指每一个端口号与FreeSWITCH中的事件处理接口进行通信所需的TCP长连接。

步骤S40，利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口，由所述事件处理接口对所述呼叫业务进行处理。

具体的说，在实际应用中，所述呼叫业务的处理，实质是由所述事件处理接口调用所述呼叫业务对的端口号，进而实现对所述呼叫业务的处理的。

通过上述描述不难发现，本实施例中提供的业务处理方法，呼叫中心系统在接收到用户触发的任意呼叫业务请求时，通过确定待处理的呼叫业务的识别号，并根据预先构建的映射关系表确定所述识别号对应的呼叫业务的业务种类，然后根据确定的业务种类和预先编译获得的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出用于处理本次呼叫业务的TCP长连接，最终根据查找出的TCP长连接，将用户触发的呼叫业务请求发送至软交换平台的事件处理接口进行处理，使得呼叫业务能够分端口、分TCP长连接处理，实现了呼叫业务的疏通，从而显著提升了呼叫中心系统的并发性能。

并且，通过这种呼叫业务的处理方法，无需在大量服务器上部署呼叫中心业务，从而在兼顾服务器资源的同时，有效缩短了呼叫中心系统的部署周期。

参考图3，图3为本发明一种业务处理方法第二实施例的流程示意图。

基于上述第一实施例，本实施例业务处理方法在所述步骤S40之前，还包括：

步骤S00，判断所述呼叫业务请求是否符合预设要求。

比如，根据预设的呼叫业务请求规则来判断所述呼叫业务请求是否符合预设要求。

需要说明的是，上述所说的呼叫业务请求规则，具体可以包括呼叫业务请求的标准格式、要求携带的字段、采用的协议等，此处不再一一列举，对此也不做限制。

相应地，在通过上述判断操作之后，若确定所述呼叫业务请求符合预设要求，则进入步骤S40，执行用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口的操作，从而保证所述软交换平台在收到所述呼叫业务请求之后，能够做出正确的响应，保证呼叫业务能够被正常处理。

此外，应当理解的是，在实际应用中，使用坐席话机、软电话等呼叫组件发起呼叫业务请求的用户往往不熟悉相关技术，因而为了在出现异常时能够及时告知相关管理人员，以便管理人员解决导致呼叫业务请求不符合预设要求的问题，保障用户的使用体验，在通过步骤S00中的操作判定所述呼叫业务请求不符合预设要求时，还可以包括：

步骤S50，获取所述呼叫业务请求对应的异常日志文件，将所述呼叫业务请求和所述异常日志文件发送至管理人员的终端设备。

应当理解的是，本实施例中所说的管理人员具体可以是部署呼叫中心系统的工作人员。

相应地，所述管理人员的终端设备具体可以是管理人员使用的开发设备，比如个人计算机、服务器等，此处不再一一列举，对此也不做限制。

进一步地，在将获取到的异常日志文件和当前不符合预设要求的呼叫业务请求发送至管理人员的终端设备之前，还可以先将所述异常日志文件与预存的发起所述呼叫业务请求时产生的正常日志文件进行比较，并对不一致的内容进行标记，得到标记版本的异常日志文件；然后将所述呼叫业务请求和所述标记版本的异常日志文件发送至管理人员的终端设备，从而可以使所述管理人员能够根据所述呼叫业务请求和所述标记版本的异常日志文件，定位出导致所述呼叫业务请求不符合预设要求的原因。

应当理解的是，以上仅为举例说明，对本发明的技术方案并不构成限定，在具体实现中，本领域的技术人员可以根据需要进行设置，此处不做限制。

通过上述描述不难发现，本实施例中提供的业务处理方法，在利用查找到的TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口之前，通过对呼叫业务请求进行判断，在判定符合预设要求时，才将所述呼叫业务请求发送至所述软交换平台的事件处理接口，从而可以保证所述软交换平台的事件处理接口在收到所述呼叫业务请求之后，能够做出正确的响应，保证呼叫业务能够被正常处理；而在判定不符合预设要求时，通过将所述呼叫业务请求及所述呼叫业务请求对应的异常日志文件发送至管理人员的终端设备，从而可以使所述管理人员能够根据所述呼叫业务请求和所述异常日志文件，定位出导致所述呼叫业务请求不符合预设要求的原因，快速解决异常现象，进而保证用户体验。

此外，本发明实施例还提出一种存储介质，所述存储介质上存储有业务处理程序，所述业务处理程序被处理器执行时实现如上文所述的业务处理方法的步骤。

参照图4，图4为本发明业务处理装置第一实施例的结构框图。

如图4所示，本发明实施例提出的业务处理装置包括：第一确定模块4001、第二确定模块4002、查找模块4003和发送模块4004。

其中，第一确定模块4001，用于接收用户通过呼叫组件触发的呼叫业务请求，根据所述呼叫业务请求确定待处理的呼叫业务的识别号；第二确定模块4002，用于根据预先构建的映射关系表，确定所述识别号对应的所述呼叫业务的业务种类；查找模块4003，用于根据所述业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接；发送模块4004，用于利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口，由所述事件处理接口对所述呼叫业务进行处理。

需要说明的是，本实例中所说的映射关系表具体是用于记录所述识别号与所述业务种类之间的对应关系的。

此外，应当理解的是，本实例中所说的预先编译的重定义远程过程调用组件，具体是在所述查找模块4003执行根据所述业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接的操作之前，通过使用java编程语言，对原生远程过程调用组件进行编译得到的。

关于在原生远程过程调用组件的基础上使用java编程语言，得到所述重定义远程过程调用组件的操作，具体是使用java编程语言在原生远程过程调用组件的基础上，为呼叫中心系统支持的各种呼叫业务分配预先设定的端口号，然后重新打包得到。

此外，值得一提的是，在实际应用中，所述查找模块4003在根据所述业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接时，具体是通过如下步骤实现：

(1)根据所述业务种类和所述重定义远程过程调用组件，确定所述呼叫业务对应的端口号。

应当理解的是，由于在编译重定义远程过程调用组件时，重新分配了每个呼叫业务对应的端口号，因而在确定待处理的呼叫业务的业务种类后，可以快速确定所述呼叫业务对应的端口号。

(2)根据所述端口号，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接。

为了便于理解上述步骤(2)中所说的根据所述端口号，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接的方式，本实施例给出一种具体的实现方式，大致如下：

比如，将所述端口号作为索引项，从预先记录的TCP长连接记录表中查找所述端口号对应的TCP长连接的标识号；若查找到所述端口号对应的TCP长连接的标识号，则根据所述标识号，从所述预先构建的TCP连接池中查找出所述标识号对应的TCP长连接，并将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接；若未查找到所述端口号对应的TCP长连接的标识号，则创建一个TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接，并将创建的TCP长连接的标识号更新到所述TCP长连接记录表中。

进一步地，在实际应用中，为了尽可能的节约设备资源，添加在预先构建的TCP连接池中的TCP长连接的个数是有限的，所以可能会存在查找到的TCP长连接目前正处于使用状态。因而，为了保证用户触发的呼叫业务请求能够被及时处理，本实例中提供的业务处理装置还可以包括状态检测模块。

其中，所述状态检测模块，用于在将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接之前，判断查找出的所述TCP长连接是否处于空闲状态。

相应地，若确定查找到的所述TCP长连接处于空闲状态，则将将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接。

应当理解的是，以上仅为举例说明，对本发明的技术方案并不构成任何限定，在具体应用中，本领域的技术人员可以根据需要进行设置，本发明对此不做限制。

通过上述描述不难发现，本实施例中提供的业务处理装置，呼叫中心系统在接收到用户触发的任意呼叫业务请求时，通过确定待处理的呼叫业务的识别号，并根据预先构建的映射关系表确定所述识别号对应的呼叫业务的业务种类，然后根据确定的业务种类和预先编译获得的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出用于处理本次呼叫业务的TCP长连接，最终根据查找出的TCP长连接，将用户触发的呼叫业务请求发送至软交换平台的事件处理接口进行处理，使得呼叫业务能够分端口、分TCP长连接处理，实现了呼叫业务的疏通，从而显著提升了呼叫中心系统的并发性能。

并且，通过这种呼叫业务的处理装置，无需在大量服务器上部署呼叫中心业务，从而在兼顾服务器资源的同时，有效缩短了呼叫中心系统的部署周期。

需要说明的是，以上所描述的工作流程仅仅是示意性的，并不对本发明的保护范围构成限定，在实际应用中，本领域的技术人员可以根据实际的需要选择其中的部分或者全部来实现本实施例方案的目的，此处不做限制。

另外，未在本实施例中详尽描述的技术细节，可参见本发明任意实施例所提供的业务处理方法，此处不再赘述。

基于上述业务处理装置的第一实施例，提出本发明业务处理装置第二实施例。

在本实施例中，所述业务处理装置还包括呼叫业务请求检测模块。

其中，所述呼叫业务请求检测模块，用于判断所述呼叫业务请求是否符合预设要求。

相应地，若所述呼叫业务请求符合预设要求，则触发发送模块执行利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口的操作。

此外，应当理解的是，在实际应用中，为了尽快解决所述呼叫业务请求不符合预设要求的问题，本实施例中提供的业务处理装置还可以包括日志获取模块和异常信息发送模块。

其中，所述日志获取模块，用于在所述呼叫业务请求检测模块通过对呼叫业务请求进行判断，确定呼叫业务请求不符合预设要求时，获取所述呼叫业务请求对应的异常日志文件；所述异常信息发送模块，用于将所述呼叫业务请求和所述异常日志文件发送至管理人员的终端设备，以使所述管理人员能够根据所述呼叫业务请求和所述异常日志文件，定位出导致所述呼叫业务请求不符合预设要求的原因。

进一步地，为了方便管理人员处理，能够快速定位出导致所述呼叫业务请求不符合预设要求的原因，可以在将所述呼叫业务请求和所述异常日志文件发送至管理人员的终端设备之前，还对异常日志文件中的内容进行标记。因而，本实施例中提供的业务处理装置还可以包括异常标记模块。

其中，所述异常标记模块，用于将所述异常日志文件与预存的发起所述呼叫业务请求时产生的正常日志文件进行比较，并对不一致的内容进行标记，得到标记版本的异常日志文件。

相应地，所述异常信息发送模块，在发送所述呼叫业务请求及所述呼叫业务请求对应的异常日志文件等异常信息时，具体是将所述呼叫业务请求和所述标记版本的异常日志文件发送至管理人员的终端设备，从而可以使所述管理人员能够根据所述呼叫业务请求和所述标记版本的异常日志文件，定位出导致所述呼叫业务请求不符合预设要求的原因。

应当理解的是，以上仅为举例说明，对本发明的技术方案并不构成任何限定，在具体应用中，本领域的技术人员可以根据需要进行设置，本发明对此不做限制。

通过上述描述不难发现，本实施例中提供的业务处理装置，在利用查找到的TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口之前，通过对呼叫业务请求进行判断，在判定符合预设要求时，才将所述呼叫业务请求发送至所述软交换平台的事件处理接口，从而可以保证所述软交换平台的事件处理接口在收到所述呼叫业务请求之后，能够做出正确的响应，保证呼叫业务能够被正常处理；而在判定不符合预设要求时，通过将所述呼叫业务请求及所述呼叫业务请求对应的异常日志文件发送至管理人员的终端设备，从而可以使所述管理人员能够根据所述呼叫业务请求和所述异常日志文件，定位出导致所述呼叫业务请求不符合预设要求的原因，快速解决异常现象，进而保证用户体验。

需要说明的是，以上所描述的工作流程仅仅是示意性的，并不对本发明的保护范围构成限定，在实际应用中，本领域的技术人员可以根据实际的需要选择其中的部分或者全部来实现本实施例方案的目的，此处不做限制。

另外，未在本实施例中详尽描述的技术细节，可参见本发明任意实施例所提供的业务处理方法，此处不再赘述。

此外，需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

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

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种业务处理方法，其特征在于，所述方法包括：

接收用户通过呼叫组件触发的呼叫业务请求，根据所述呼叫业务请求确定待处理的呼叫业务的识别号；

根据预先构建的映射关系表，确定所述识别号对应的所述呼叫业务的业务种类，所述映射关系表为所述识别号与所述业务种类之间的对应关系，其中，所述业务种类根据呼叫业务、触发呼叫业务请求的呼叫组件以及调用接口进行划分；

根据所述业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接；

利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口，由所述事件处理接口对所述呼叫业务进行处理。

2.如权利要求1所述的方法，其特征在于，所述根据所述业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接的步骤之前，所述方法还包括：

在原生远程过程调用组件的基础上使用java编程语言，为各呼叫业务分配对应的端口号，得到所述重定义远程过程调用组件。

3.如权利要求2所述的方法，其特征在于，所述根据所述业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接的步骤，包括：

根据所述业务种类和所述重定义远程过程调用组件，确定所述呼叫业务对应的端口号；

根据所述端口号，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接。

4.如权利要求3所述的方法，其特征在于，所述根据所述端口号，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接的步骤，包括：

将所述端口号作为索引项，从预先记录的TCP长连接记录表中查找所述端口号对应的TCP长连接的标识号；

若查找到所述端口号对应的TCP长连接的标识号，则根据所述标识号，从所述预先构建的TCP连接池中查找出所述标识号对应的TCP长连接，并将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接；

若未查找到所述端口号对应的TCP长连接的标识号，则创建一个TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接，并将创建的TCP长连接的标识号更新到所述TCP长连接记录表中。

5.如权利要求4所述的方法，其特征在于，所述将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接的步骤之前，所述方法还包括：

判断查找出的所述TCP长连接是否处于空闲状态；

其中，所述将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接的步骤，包括：

若查找出的所述TCP长连接处于空闲状态，则将查找出的所述TCP长连接作为所述呼叫组件与软交换平台通信所需的TCP长连接。

6.如权利要求1至5任一项所述的方法，其特征在于，所述利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口的步骤之前，所述方法还包括：

判断所述呼叫业务请求是否符合预设要求；

其中，所述利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口的步骤，包括：

若所述呼叫业务请求符合预设要求，则利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口。

7.如权利要求6所述的方法，其特征在于，所述判断所述呼叫业务请求是否符合预设要求的步骤之后，所述方法还包括：

若所述呼叫业务请求不符合预设要求，则获取所述呼叫业务请求对应的异常日志文件；

将所述呼叫业务请求和所述异常日志文件发送至管理人员的终端设备，以使所述管理人员能够根据所述呼叫业务请求和所述异常日志文件，定位出导致所述呼叫业务请求不符合预设要求的原因。

8.一种业务处理装置，其特征在于，所述装置包括：

第一确定模块，用于接收用户通过呼叫组件触发的呼叫业务请求，根据所述呼叫业务请求确定待处理的呼叫业务的识别号；

第二确定模块，用于根据预先构建的映射关系表，确定所述识别号对应的所述呼叫业务的业务种类，所述映射关系表为所述识别号与所述业务种类之间的对应关系，其中，所述业务种类根据呼叫业务、触发呼叫业务请求的呼叫组件以及调用接口进行划分；

查找模块，用于根据所述业务种类和预先编译的重定义远程过程调用组件，从预先构建的传输控制协议TCP连接池中查找出所述呼叫组件与软交换平台通信所需的TCP长连接；

发送模块，用于利用所述TCP长连接，将所述呼叫业务请求发送至所述软交换平台的事件处理接口，由所述事件处理接口对所述呼叫业务进行处理。

9.一种业务处理设备，其特征在于，所述设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的业务处理程序，所述业务处理程序配置为实现如权利要求1至7中任一项所述的业务处理方法的步骤。

10.一种存储介质，其特征在于，所述存储介质上存储有业务处理程序，所述业务处理程序被处理器执行时实现如权利要求1至7任一项所述的业务处理方法的步骤。

Images