CN116939104A - Cti系统和事件处理方法 - Google Patents

Abstract

本公开提出一种CTI系统和事件处理方法，系统包括：FS接口，用于获取到初始事件，向关注初始事件的事件处理模块发送初始事件；事件处理模块，用于在初始事件触发事件处理模块中的第一CTI状态更新，且根据更新后的第一CTI状态确定初始事件与第一应用系统具有关联关系的情况下，根据初始事件，确定与第一应用系统匹配的目标事件，并向应用系统接口发送更新后的第一CTI状态和目标事件；应用系统接口，用于将更新后的第一CTI状态和目标事件发送至第一应用系统，以使第一应用系统根据更新后的第一CTI状态，对目标事件进行响应，由此，无需第一应用系统对初始事件进行处理，提高了第一应用系统对目标事件响应效率，并且降低了第一应用系统的资源占用。

Description

CTI系统和事件处理方法

技术领域

本公开涉及数据处理技术领域，尤其涉及一种CTI系统和事件处理方法。

背景技术

呼叫中心是企业服务客户的窗口，是一个企业重要的IT(InformationTechnology，信息技术)系统，呼叫中心基础部分主要为CTI(ComputerTelephonyIntegration，计算机电话系统集成)系统，由于呼叫中心的许多业务功能都依赖于电话状态及电话事件的处理，因此，CTI系统如何对电话状态和电话事件进行处理是非常重要的。

发明内容

本公开提供一种CTI系统和事件处理方法，以至少在一定程度上解决相关技术中的技术问题之一。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种CTI系统，包括：FS(FreeSwitch，自由交互)接口，用于获取到FS系统生成的初始事件，向关注所述初始事件的事件处理模块发送所述初始事件；事件处理模块，用于接收所述初始事件，在所述初始事件触发所述CTI系统的第一CTI状态更新，且根据更新后的第一CTI状态确定所述初始事件与第一应用系统具有关联关系的情况下，根据所述初始事件，确定与所述第一应用系统匹配的目标事件，并向应用系统接口发送所述更新后的第一CTI状态和所述目标事件，应用系统接口，用于将更新后的第一CTI状态和所述目标事件发送至所述第一应用系统，以使所述第一应用系统根据所述更新后的第一CTI状态，对所述目标事件进行响应。

根据本公开实施例的第二方面，提供了一种事件处理方法，应用于CTI系统，所述CTI系统包括：FS接口、事件处理模块和应用系统接口，所述方法包括：通过FS接口响应于获取到FS系统生成的初始事件，向关注所述初始事件的事件处理模块发送所述初始事件；通过所述事件处理模块接收所述初始事件，在所述初始事件触发所述CTI系统的第一CTI状态更新，且根据更新后的第一CTI状态确定所述初始事件与第一应用系统具有关联关系的情况下，根据所述初始事件，确定与所述第一应用系统匹配的目标事件，并向所述应用系统接口发送所述更新后的第一CTI状态和所述目标事件，通过所述应用系统接口将所述更新后的第一CTI状态和所述目标事件发送至所述第一应用系统，以使所述第一应用系统根据所述更新后的第一CTI状态，对所述目标事件进行响应。

根据本公开实施例的第三方面，提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现如本公开第二方面实施例所述的事件处理方法。

根据本公开实施例的第四方面，提供一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如本公开第二方面实施例所述的事件处理方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，包括：计算机程序，所述计算机程序被处理器执行时实现如本公开第二方面实施例所述的事件处理方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

1、CTI系统可在初始事件触发第一CTI状态更新，且根据更新后的第一CTI状态确定初始事件与第一应用系统具有关联关系的情况下，对初始事件进行处理，有效地确定与第一应用系统匹配的目标事件，无需第一应用系统对初始事件进行处理，提高了第一应用系统对目标事件响应效率，并且降低了第一应用系统的资源占用；

2、CTI系统有效的简化了FS事件及其参数，使呼叫中心的应用系统通过CTI系统可以更方便的集成FS；

3、CTI系统与FS系统对接，可根据目标事件所属的业务类型和优先级，将目标事件路由至对应的目标应用系统进行响应，为呼叫中心提供多样灵活的话务路由及排队功能，有效地降低了成本；

4、CTI系统可确定设定时间段内各第一事件参数在对应设定维度上的出现次数，实现了多维度的话务实时数据的统计，为呼叫中心的应用系统提供了统一的数据支撑。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是本公开第一实施例所示出的CTI系统的结构示意图。

图2为本公开实施例所提供的一种CTI系统的结构示意图。

图3为本公开实施例所提供的一种事件处理方法的流程示意图。

图4是本公开实施例提供的事件处理方法的流程示意图。

图5是本公开实施例提供的状态变迁示意图。

图6是本公开第三实施例所示出的事件处理装置的结构示意图。

图7是本公开一示例性实施例所示出的电子设备的结构示意图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

需要了解的是，使用开源的FreeSwitch(一种开源的软交换技术，简称FS或Fs)软交换技术实现了交换机及排队机的基本功能可有效的降低成本。但是FS系统中的CTI模块，由于便捷性与业务系统集成方便性等性能较差，无法直接用到呼叫中心。

此外，呼叫中心的许多业务功能依赖于电话的状态及电话的事件，一方面FS技术原生的技术底层通讯的事件、底层通讯的状态均混合在一起、这些底层事件数量庞大且附加属性非常复杂，很多事件及属性对呼叫中心的应用系统没有意义。这些庞大且复杂的事件对业务开发人员造成较大的困扰，另一方面FS没有管理业务上的状态的相关内容。当应用和基础通讯功能要集成时，直接使用FS开发呼叫中心的应用系统，要求业务开发人员既要精通FS系统的也要精通业务开发，难度较大。

相关技术中，基于FS系统开发了呼叫中心模块，该模块实现了现呼叫中心的排队和ACD(Automatic Call Distributor，自动呼叫分配)功能。但是该模块存在以下问题：

1、排队功能不够丰富，无法满足呼叫中心中座席多技能、座席多技能等级以及更为高级的路由及排队策略的需求；

2、不具备CTI系统整合应用过程和电话过程、话务追踪、应用开发接口事件追踪处理、用户随路数据等能CTI系统重要的功能。

因此，针对上述问题，本公开提出一种CTI系统和事件处理方法。

下面参考附图描述本公开实施例的CTI系统和事件处理方法。

图1是本公开第一实施例所示出的CTI系统的结构示意图。

如图1所示，CTI系统100包括：FS接口110、事件处理模块120和应用系统接口。

其中，FS接口110，用于响应于获取到FS系统生成的初始事件，向关注初始事件的事件处理模块发送初始事件；事件处理模块120，用于接收初始事件，在初始事件触发事件处理模块中的第一CTI状态更新，且根据更新后的第一CTI状态确定初始事件与第一应用系统具有关联关系的情况下，根据初始事件，确定与第一应用系统匹配的目标事件，并向应用系统接口发送更新后的第一CTI状态和目标事件应用系统接口130，用于将更新后的第一CTI状态和目标事件发送至第一应用系统，以使第一应用系统根据更新后的第一CTI状态，对目标事件进行响应。

需要了解的是，由于FS系统可低成本地实现交换机及排队机的基本功能，因此，在本公开实施例中，可将FS作为CTI的基础通讯平台，FS接口，可用于接收FS生成的初始事件，向关注初始事件的事件处理模块发送初始事件，其中，需要说明的是，FS在接收到呼叫请求或者执行相关应答指令时，可触发自身状态的改变，生成初始事件。

在本公开实施例中，CTI系统作为电话系统和计算机系统集成，首先要获取触发CTI系统状态(即第一CTI状态)变化的事件，及变化后的第一CTI状态，并且把这些状态和事件发送给座席业务系统，座席业务可根据当前状态，对事件进行相应的业务处理。

因此，在本公开实施例中，事件处理模块120，可用于接收初始事件，在初始事件触发事件处理模块中的第一CTI状态更新，且根据更新后的第一CTI状态确定初始事件与第一应用系统具有关联关系的情况下，根据初始事件，确定与第一应用系统匹配的目标事件，并在初始事件所属业务的业务类型为第一业务类型的情况下，向所述应用系统接口发送更新后的第一CTI状态和目标事件，其中，第一业务类型的业务与更新后的第一CTI状态具有关联关系。

也就是说，事件处理模块120，在接收到初始事件后，可在初始事件触发自身的第一CTI状态更新的情况下，根据更新后的第一CTI状态确定该初始事件是否与第一应用系统具有关联关系，在初始事件与第一应用系统具有关联关系的情况下，对初始事件进行处理，以得到与第一应用系统匹配的目标事件，并通过应用系统接口将更新后的第一CTI状态和目标事件发送至第一应用系统，以使第一应用系统根据更新后的第一CTI状态，对目标事件进行响应。其中，需要说明的是，FS接口可用于事件处理模块获取FS事件(初始事件)及其数据，同时还可通过FS接口向FS系统发送应用系统响应目标事件所生成的应答指令。

应用系统接口是CTI系统用于与呼叫中心应用系统交互的SDK(softwaredevilment kit，软件加开发工具包)，应用系统可通过该工具包来获取CTI状态、事件(目标事件)及向CTI系统发送电话操控命令。该应用系统接口不仅定义了通讯API，也定义了完整的报文协议。应用系统接口也作为呼叫中心其他应用系统接入CTI系统的接口，这些应用系统可包括：录音系统、质检系统、传真系统、IVR(Interactive Voice Response，互动式语音应答)系统、智能语音导航系统、排班系统、工单系统以及其他要使用话务数据的系统等。

另外，还需要说明的是，在初始事件未触发事件处理模块120的第一CTI状态更新的情况下，可确定初始事件与第一应用系统不具有关联关系。

综上，通过FS接口响应于获取到FS系统生成的初始事件，向关注所述初始事件的事件处理模块发送所述初始事件；通过事件处理模块接收初始事件，在初始事件触发事件处理模块中的第一CTI状态更新，且根据更新后的第一CTI状态确定所述初始事件与第一应用系统具有关联关系的情况下，根据初始事件，确定与第一应用系统匹配的目标事件，并向应用系统接口发送所述更新后的第一CTI状态和所述目标事件，通过应用系统接口将更新后的第一CTI状态和目标事件发送至第一应用系统，以使第一应用系统根据更新后的第一CTI状态，对目标事件进行响应，由此，CTI系统可在初始事件触发CTI状态更新，且根据更新后的第一CTI状态确定初始事件与第一应用系统具有关联关系的情况下，对初始事件进行处理，有效地确定与第一应用系统匹配的目标事件，无需第一应用系统对初始事件进行处理，提高了第一应用系统对目标事件响应效率，并且降低了第一应用系统的资源占用。

作为本公开实施例的一种可能的实现方式，事件处理模块，具体用于：接收初始事件，根据初始事件所携带的第一事件参数判断初始事件是否触发第一CTI状态更新；在初始事件触发第一CTI状态更新的情况下，获取与第一应用系统匹配的参考状态，并判断更新后的第一CTI状态是否与参考状态匹配；在更新后的第一CTI状态与参考状态匹配的情况下，确定初始事件与第一应用系统具有关联关系；对初始事件进行参数过滤，得到与第一应用系统匹配的目标事件，在初始事件所属业务的业务类型为第一业务类型的情况下，向应用系统接口发送更新后的第一CTI状态和目标事件，

其中，第一业务类型的业务与更新后的第一CTI状态具有关联关系，第一事件参数比如可包括：参数通道状态、通道呼叫状态等。

也就是说，事件处理模块120在接收到初始事件后，可获取当前CTI状态，即第一CTI状态，并提取该初始事件中的参数，即第一事件参数，根据该第一事件参数判断是否触发第一CTI状态更新，比如，第一CTI状态为空(即等待客户来电或外呼的状态)，初始事件为PRESENCE_IN事件，PRESENCE_IN事件中的用于指示参数通道状态(CHANNEL state)的第一事件参数的值为CS_ROUTING(正在路由)，用于指示通道呼叫(CHANNEL state)状态的第一事件参数的值为(RING)振铃。则该初始事件将导致第一CTI状态改变，即将第一CTI状态从空变成振铃状态。进一步地，获取与第一应用系统匹配的参考状态，并判断更新后的第一CTI状态是否与参考状态匹配，即事件处理模块预先存储与第一应用系统匹配的参考状态，即预先存储需要通知第一应用系统的参考状态，判断更新后的第一CTI状态与参考状态是否匹配，即更新后的第一CTI状态是否需要通知第一应用系统，在更新后的第一CTI状态与参考状态匹配(更新后的第一CTI状态需要通知第一应用系统)的情况下，可确定该初始事件与第一应用系统具有关联关系；进而，对初始事件进行参数过滤，得到与第一应用系统匹配的目标事件，进一步判断初始事件所属业务的业务类型是否为第一业务类型，在初始事件所属业务的业务类型为第一业务类型的情况下，通过应用系统接口将更新后的第一CTI状态和目标事件发送至第一应用系统，以使第一应用系统根据更新后的第一CTI状态，对目标事件进行响应。其中，需要说明的是，第一业务类型的业务与更新后的第一CTI状态具有关联关系，如，第一业务类型可为与客户账号相关的业务，如，挂失银行卡号，更改客户信息等。

需要了解的是，由于原生的FS事件(初始事件)含有大量底层通讯的事件、执行过程事件，这些事件中参数也十分复杂。而呼叫中心的应用系统不用关注这些底层的通讯事件及具体的操作事件，应用系统关注的是，如：来电、挂断、接听、保持、接起、咨询、转接、会议、插入、路由、排队、呼出、呼出、回铃等等直观的电话事件。在事件相关的参数中，其他系统关心主要参数有：主叫、被叫、呼叫ID、信道ID、事件类型、触发方(比如是哪方挂机了)、事件后进入的状态等，而不关心底层通讯的参数。如果应用系统为录音系统：通常关注的事件有接通电话(启动录音)、挂断电话(结束录音)，关注的事件参数中关心，主叫、被叫、时间、呼叫ID等参数；在应用系统为座席系统时，则几乎关注所有的事件。因此如果每个应用系统都直接使用原生的FS事件，则需要实现从复杂事件中获取有用事件的处理过程，不仅开发量很大，整个CTI系统也难以维护。

因此，为了提高第一应用系统对目标事件响应效率，并且降低第一应用系统的资源占用，同时，为了避免应用系统直接使用原生的FS事件，在本公开实施例中，可对初始事件进行参数简化，即CTI系统中的事件处理模块120可对初始事件进行参数过滤，得到与第一应用系统匹配的目标事件，在初始事件所属业务的业务类型为第一业务类型的情况下，通过应用系统接口将更新后的第一CTI状态和目标事件发送至第一应用系统，以使第一应用系统根据更新后的第一CTI状态，对目标事件进行响应。由此，CTI系统有效的简化了FS事件及其参数，应用系统通过CTI系统可以更方便的集成FS，提高了应用系统对目标事件响应效率，并且降低了应用系统的资源占用。

其中，需要说明的是，针对一些业务场景，比如，对客户信息的处理，银行场景下卡号挂失等，需要在通话状态下进行对应业务场景下的目标事件的响应，即第一应用系统根据更新后的第一CTI状态，对目标事件进行响应。

作为本公开实施例的一种可能的实现方式，事件处理模块120，还用于：在初始事件所属业务的业务类型为第二业务类型的情况下，向应用系统接口发送所述目标事件，其中，第二业务类型的业务与更新后的第一CTI状态不具有关联关系。

也就是说，在目标事件所属业务的业务类型为第二业务类型的情况下，如，第二业务类型的业务为与客户账号无关的业务，比如，处理客户投诉的业务，事件处理模块120，可确定第一应用系统无需根据更新后的第一CTI状态对该业务下的目标事件进行处理，因此，为了降低第一应用系统的处理负担和提高对目标事件的处理效率，可通过应用系统接口仅将目标事件发送至第一应用系统，以使第一应用系统对目标事件进行响应。

作为本公开实施例的一种可能的实现方式，事件处理模块120，还用于：查询设定待记录事件表，以确定初始事件是否为待记录事件；在初始事件为待记录事件时，查询设定待记录参数，以获取初始事件的待记录参数，并对待记录参数和CTI状态进行记录，以生成事件日志。

也就是说，为了便于话务数据的查询和跟踪，作为一种示例，在初始事件未触发第一CTI状态更新的情况下，可查询设定待记录事件表，以确定初始事件是否为待记录事件，在初始事件是否为待记录事件时，查询设定待记录参数表，以获取初始事件的待记录参数，并对待记录参数和第一CTI状态进行记录，以生成事件日志。

比如，可以通过callid、主叫号码查询一通电话所经过的节点及各节点的操作情况，为后续跟踪和问题查找提供依据。实现的方式通过把事件的信息及操作进行正则化处理，然后按照事件发生顺序，过滤无用数据后，记录在日志中。日志正则化格式如下：事件发生时间(或操作)、事件名称(或操作)、callid(一通电话唯一的标识，本系统采用Fs中呼叫建立时callid)、主叫号、被叫号、事件主体(谁引发了这个事件)、事件原因(如果是操作为操作动作)、第三饭号码，附件随路数据等。

作为另一种示例，在初始事件触发第一CTI状态更新，且根据更新后的第一CTI状态确定初始事件与第一应用系统不具有关联关系的情况下，可查询设定待记录事件表，以确定初始事件是否为待记录事件，在初始事件是否为待记录事件时，查询设定待记录参数表，以获取初始事件的待记录参数，并对待记录参数、第一CTI状态和更新后的第一CTI状态进行记录，以生成事件日志。

作为又一种示例，在初始事件触发第一CTI状态更新，且根据更新后的第一CTI状态确定初始事件与第一应用系统具有关联关系的情况下，在将更新后的第一CTI状态和目标事件发送至第一应用系统之后，查询设定待记录事件表，以确定初始事件是否为待记录事件；在初始事件为待记录事件时，查询设定待记录参数表，以获取初始事件的待记录参数，并对待记录参数、第一CTI状态、更新后的第一CTI状态以及向第一应用系统发送更新后的第一CTI状态和目标事件的过程进行记录。

作为本公开实施例的一种可能的实现方式，事件处理模块120，还用于：针对初始事件所携带的各第二事件参数，确定设定时段内各第二事件参数在对应设定维度上的出现次数；接收第二应用系统所发送的获取指令，响应于获取指令，将设定时间段内各第二事件参数在对应设定维度上的出现次数发送至应用系统接口，以将设定时间段内各第二事件参数在对应设定维度上的出现次数发送至第二应用系统。

为了便于话务数据的监控和分析，在本公开实施例中，可对设定时段内初始事件所携带的各第二事件参数在对应设定维度上的出现次数进行统计，在接收第二应用系统所发送的获取指令，响应于该获取指令，可通过应用系统接口向设定时段内各第一事件参数在对应设定维度上的出现次数发送至第二应用系统，以对各第一事件参数在对应设定维度上的出现次数进行展示或标记，其中，第二事件参数可包括：来电号码、呼叫ID、通话时间等。

作为本公开实施例的一种可能的实现方式，第一应用系统为多个，事件处理模块，具体用于：根据目标事件中所携带的第三事件参数，确定目标事件所属的业务类型和优先级；获取各第一应用系统允许处理的业务类型和各第一应用系统在允许处理的业务类型下的优先级；根据目标事件所属的业务类型和优先级，从多个第一应用系统中，确定目标应用系统，其中，目标应用系统允许处理的业务类型与目标事件所属业务的业务类型匹配，目标事件的优先级与目标应用系统在允许处理的业务类型下的优先级匹配；获取与目标事件匹配的设定路由脚本，并执行设定路由脚本，通过应用系统接口将目标事件和更新后的第一CTI状态发送至与目标应用系统，以使目标应用系统根据更新后的第一CTI状态，对目标事件进行响应，其中，第三事件参数包括指示目标事件所属业务类型的参数和指示目标事件优先级的参数。

为了实现呼叫中心的路由和排队功能，在本公开实施例中，可根据目标事件所属的业务类型和优先级，以及各第一应用系统允许处理的业务类型和允许处理的业务类型下的优先级，从多个第一应用系统中，确定目标应用系统，其中，目标应用系统允许处理的业务类型与目标事件所属业务的业务类型匹配，目标事件的优先级与目标应用系统在允许处理的业务类型下的优先级匹配；进而，采用与目标事件匹配的设定路由脚本，并通过应用系统接口将目标事件和更新后的第一CTI状态发送至与目标应用系统，以使目标应用系统根据更新后的第一CTI状态，对目标事件进行响应。

比如，某金融机构有5种业务(对应5种技能的座席)，每个座席最少可以处理两种业务，其种一种是主要业务(优先级较高)，另一种是次要业务(优先级较低)，优先级等级高的目标事件优先服务，同一优先级的目标事件按照时间先后进行处理。如，在客户来电时，执行脚本，找到技能队列，把电话转入到该技能队列排队(相当于把客户排入对应窗口的队列，即确定目标应用系统)，排队过程中，优先级高的插到最前面，当座席服务完客户后(如，结束一通电话)自然接待排在最前面的客户(接起排在前面的电话)。

其中，需要说明的是，CTI系统还包括：管理模块；其中，管理模块，用于响应于第一配置操作，对各第一应用系统允许处理的业务类型进行配置；响应于第二配置操作，对各第一应用系统在允许处理的业务类型下的优先级进行配置。

作为本公开实施例的一种可能的实现方式，CTI系统还包括：命令处理模块，命令处理模块，用于：接收第一应用系统根据更新后的第一CTI状态，对目标事件进行响应所生成的应答指令；在应答指令与FS模块具有关联关系的情况下，对应答指令进行格式转换，以得到格式转换后的应答指令；将格式转换后的应答指令发送至FS系统，以使FS系统对格式转换后的应答指令进行应答。

也就是说，CTI系统中的命令处理模块，还可以接收第一应用系统根据更新后的第一CTI状态，对目标事件进行响应所生成的应答指令，查询设定应答指令表，以确定该应答指令是否与FS系统具有关联关系，在应答指令与FS系统具有关联关系的情况下，对应答指令进行格式转换，以得到格式转换后的应答指令；通过FS接口将格式转换后的应答指令发送至FS系统，以使FS系统对格式转换后的应答指令进行应答，其中，设定应答指令表中可包括应答指令与FS之间的对应关系。

比如，应答指令为“转接”，该应答指令与FS系统具有关联关系，该“转接”应答指令必须由FS系统处理，则把该应答指令转换为与FS系统对应的应答指令，并将转换后的应答指令发送至FS系统，FS系统可对格式转换后的应答指令进行应答，其中，需要说明的是，在FS系统对格式转换后的应答指令应答时，触发自身状态改变，则可生成与事件处理模块进行下一次交互的初始事件。

此外，还需要说明的是，命令处理模块，还用于：获取与应答指令匹配的第二CTI状态；在第二CTI状态与更新后的第一CTI状态不一致的情况下，将更新后的第一CTI状态更新为第二CTI状态。

也就是说，命令处理模块收到应答指令时，可判断该应答指令是否影响CTI系统的状态，在该应答指令影响CTI系统的状态时，如，应答指令为接收通话指令，当前CTI系统的状态为第一CTI状态(如，振铃状态)，与应答指令匹配的第二CTI状态为通话状态，则将第一CTI状态更新为第二CTI状态。

为了清楚地说明上述实施例，现举例进行说明。

举例而言，如图2所示，CTI系统包括：事件及控制接口(FS接口)、客服其他系统接口(应用系统接口)、事件处理模块、管理服务器(管理模块)和命令处理模块。

其中，事件及控制接口，用于获取FS事件，同时通过该接口向FS系统发送响应的指令；

客服其他系统接口，用于其他系统适应该接口来获取CTI的状态、事件及向CTI发送电话操控命令；

事件处理模块，用于从FS的原生事件中得到CTI系统定义好的CTI事件。包括事件分析、事件参数过滤、座席\话务状态处理、日志正则化处理及保存、上下文缓存及统计数据处理。其总体过程是FS系统的电话状态发生变化时FS系统就会通过EventSocket向事件及控制接口发送对应的事件，事件及控制接口调用相应的事件处理模块，事件处理模块根据不同事件类型做不同的处理，分析事件如果涉及到状态改变的事件，则改变当前的话务或座席的状态，状态改变后如果触发话务数据变化，则进行统计处理及日志记录。事件处理过程是要提炼出业务需要的数据；如果座席业务系统要使用该事件来控制座席的状态及业务过程，则把该事件做格式化处理后通知座席应用系统；

命令处理模块，用于：收到应用发来的命令后，如：座席签入软电话的命令，此时改变座席的状态，记录相应的日志。如果命令必须由FS系统处理，如“转接”，则还要把命令转换称FS系统对应的命令及参数传给FS系统，根据FS系统处理的结果来修改对应的状态，此外，还需要说明的是，不同的命令还可对应不同的出错处理方式，一般情况出错处理简单忽略，并告知调用方出错的原因，由调用方决定后续出错处理方式，比如重新发送请求、忽略等。但是对影响整个流程的错误可做特殊处理。比如电话应答指令，电话应答是重要的步骤，在出错时代码中会对FS系统返回的错误做处理，如果客户已经挂机就返回直接生成挂机事件，并第一时间通知座席。

管理服务器：用于CTI系统的管理，主要是各类配置参数，比如座席参数、技能参数、电话号码、路由参数、排队参数等配置性的管理，同时还要开发这些参数给其他系统集成使用。

CTI系统还包括数据库及Redis，由于CTI系统要保留大量的话务数据，而且在这些数据操作及其频繁，因此本系统在架构上可采用独立的数据库，保证数据库的性能不会收到其他系统的影响。数据库来保存流水性话务数据及座席操作数据、统计结果的中间数据等等，以供管理使用。CTI系统还要保存大量的当前每通电话的状态、每个座席的状态，为支持部署上的可扩展性，本发明采用Redis用以存储电话的上下文、当前状态、各类统计的中间数据，以支持负载均衡的应用部署及提高系统的性能。

为了实现上述实施例，本公开提出一种事件处理方法。该事件处理方法可应用于CTI系统，其中，该CTI系统可包括：FS接口、事件处理模块和应用系统接口。

图3为本公开实施例所提供的一种事件处理方法的流程示意图。

如图3所示，该事件处理方法可包括如下步骤：

步骤301，通过FS接口响应于FS系统中的状态改变生成初始事件，向关注初始事件的事件处理模块发送初始事件。

步骤302，通过事件处理模块接收初始事件，在初始事件触发事件处理模块中的第一CTI状态更新，且根据更新后的第一CTI状态确定初始事件与第一应用系统具有关联关系的情况下，根据初始事件，确定与第一应用系统匹配的目标事件，并向应用系统接口发送更新后的第一CTI状态和目标事件。

步骤303，通过应用系统接口将更新后的第一CTI状态和目标事件发送至第一应用系统，以使第一应用系统根据更新后的第一CTI状态，对目标事件进行响应。

综上，通过FS接口响应于获取到FS系统生成的初始事件，向关注初始事件的事件处理模块发送初始事件；通过事件处理模块接收初始事件，在初始事件触发事件处理模块中的第一CTI状态更新，且根据更新后的第一CTI状态确定初始事件与第一应用系统具有关联关系的情况下，根据初始事件，确定与第一应用系统匹配的目标事件，并向应用系统接口发送更新后的第一CTI状态和目标事件，通过应用系统接口将更新后的第一CTI状态和目标事件发送至第一应用系统，以使第一应用系统根据更新后的第一CTI状态，对目标事件进行响应，由此，CTI系统可在初始事件触发CTI状态更新，且初始事件与第一应用系统具有关联关系的情况下，对初始事件进行处理，有效地确定与第一应用系统匹配的目标事件，无需第一应用系统对初始事件进行处理，提高了第一应用系统对目标事件响应效率，并且降低了第一应用系统的资源占用。

为了清楚地说明上述实施例，现举例进行说明。

举例而言，如图4所示，该事件处理可包括如下步骤：

1、CTI系统中事件处理模块收到接口(FS接口)分发来的FS事件(初始事件)时，首先获取FS事件的属性，即FS事件所携带的参数(第一事件参数)；

2、若该FS事件触发事件处理模块中的第一CTI状态更新，则对第一CTI状态进行更新，比如，当前CTI状态为空，在收到的FS事件，找到PRESENCE_IN事件，其他事件忽略不计，在此状态下，如果PRESENCE_IN事件中的参数通道状态(CHANNEL state)为CS_ROUTING(正在路由)，通道呼叫(CHANNEL state)状态：(RING)振铃。则该FS事件将导致CTI事件改变，此时就要进入“维护当前CTI状态”的操作，即当前的CTI状态从空变成，振铃状态；

3、根据更新后的第一CTI状态确定FS事件与第一应用系统具有关联关系的情况下，首先正则化FS事件(如，参数过滤)，确定业务端(第一应用系统)需要的参数(业务端事件参数和FS事件参数不同)，然后将事件发送给业务端。之后继续处理；

4、若该FS事件要记录日志，则首先正则化对应事件的日志记录内容，主要是重新定义日志格式、去掉非必要的属性，添加必要的内容，然后记录日志，之后继续处理；

5、若该FS事件引发了统计数据的变更(如，同一电话号码来电次数的增加)，则进行数据统计，并记录结果。具体实现设计上，统计变更一般要较为耗时，为提高并发性，一般都采用异步方式执行统计。统计信息作为路由的基础，也为其他系统提供必要的数据支持；其中，统计数据可包括：当前队列数排队数、签入座席数、空闲座席数、通话座席数、忙座席数、当前总来话量、当前服务水平、放弃量、平均排队时长、平均等待时长等。

其中，上述过程以一个电话呼入1002分机后，1002分机接起后通话，然后挂断这个简单过程为例：上述事件流中，应用系统关注只要：电话什么时候呼入，什么时候接通、什么时候挂机，其事件对客服其他应用系统没有实质性的意义，可以不用关心，那么事件处理过程就是从上述事件流找出：来电事件、接起事件、挂机事件。从事件的参数(属性)角度，FS原生事件属性，以接通电话事件为例；总共100多个参数。这些参数中其他系统真正关心的参数只是：主叫、被叫、呼叫ID、信道ID、发生时间、随路数据。

从上例中事件分析的过程，呼入事件“PRESENCE_IN”，所有订阅了该事件的事件处理模块都会触发这个事件，呼入统计数据增加一条呼入、记录一条呼入的流水、记录一条正则化日志。

同理，接通事件“CHANNEL_CALLSTATE”，所有订阅了该事件的事件处理模块都会触发这个事件，同时统计数据的接通数加1，记录一条呼入的流水、记录一条正则化日志。

最后，对于挂机事件CHANNEL_CALLSTATE，所有订阅了该事件的事件处理模块都会触发这个事件，同时统计数据的接通数加1，记录一条呼入的流水、记录一条正则化日志。

上述三个事件还影响了下述CTI状态的改变，如图5所示，状态变迁过程如下：

1、座席上班时，通过座席业务系统登录CTI的按钮，调用CTI的登入方法，登录(签入)CTI系统，表示座席开始上班，一般作为座席上班签到的依据。此时座席还不能接电话；

2、如果座席是处理电话，则要签入软电话，此时告知CTI系统，座席已经登录。签入然电话时，座席一般情况座席的状态会设置成自动忙或空闲，如果指定为空闲，自动进入空闲否则忙。这个一般可以由业务指定；

3、状态为登录的状态如果忙状态，表示座席不可接电话。此时可以指定外呼；

4、空闲状态，表示座席可以接电话。忙和空闲可以通过图示的操作相互转化。在忙和空闲状态都可以直接执行直接签出软电话的操作。座席可以通过操作示忙或示闲的方式，示闲状态的转化，本公开实施例中的CTI系统提供相应的开发接口给座席业务系统调用；

5、如果空闲状态由客户来电(电话状态振铃)或示忙状态执行了外呼(电话状态发起呼叫、等待接听)，则座席进入通话状态。通话状态座席可以对这通电话执行操作；

6、会议状态：座席进入三方通话，此时，可以结束三方通话回到通话状态，或挂机到事后总结状态；

7、保持状态，此时可以结束保持回到通话状态到事后总结状态，或挂机到事后总结状态；

8、咨询会议状态：座席进入咨询，此时，可以结束咨询回到通话状态，或挂机到事后总结状态；

9、事后总结：座席结束通话后，进入事后总结状态，事后总结时，可以设置成自动进入忙或闲，或要操作后进入对应状态；

10、签出软电话；

11、登出，下班。

其中，还需要说明的是，CTI系统还可实现呼叫中心路由功能，其中，呼叫中心路由功能指：一通电话要分配给哪个座席来接听。路由可以在FS中实现，但直接使用FS来实现，要想与业务进行关联实现起来十分复杂。在本公开实施例中，为了满足呼叫到坐席分配的要求，CTI系统需要与业务系统对接，在获得客户信息的基础上进行路由，CTI系统支持的路由策略包括以下几项：

1、按时间路由，如夜间、节假日的特殊路由。夜间节假日上班座席的限制，在路由选择上，与平常不同；

2、按来电区域路由，根据主叫来电信中的区号或手机的地区归属来安排路由，这个一般用在多中心情况，为减少网络负载，本地的来电有先分配到本地座席；

3、黑白名单功能，可设置黑名单拒接或转到特殊IVR、特殊坐席服务等；

4、数据驱动的路由实现，比如在某一技能(业务类型)的座席，客户当前排队时间很长，业界成为服务水品很低，则转入到技能相近的座席来处理，以降低整体客户排队时间，提高整体服务水平：

a)基于技能的路由，不同的业务转到不同技能的座席处理。

b)基于服务等级及用户分级的路由，客户等级越高排队的优先级越高、也优先把服务分给服务等级高的座席，通俗点，谁有钱，谁就优先获得更好的服务。

c)分布坐席路由，在同样技能的座席分布在多中心时，实现中心之间均衡分配。

上述的策略不是孤立，而是相互关联的，CTI系统做为平台，不具体规定具体的采用什么样的路由，而是提供相应的能力，在项目中实现具体的客户路由。比如：某客户有5种业务(对应5种技能的座席)，座席最少都具备两种技能(既每个座席最少可以处理两种业务)，其种一种是主要业务(技能等级高)，其他为次要业务(技能水平低)，客户通过IVR导航后能明确要办理的业务(明确要找什么样技能的座席)，要求排队时间基本一致。排队时：客户优先级高的客户优先服务，同一优先级客户先到先服务，每排队到一段时间，优先级提高一定的值。比如，在本平台可实现的路由如下：

1、配置好5种技能(也称5个技能队列)，每个技能配置好n个优先级，类似于有5个服务窗口，每个窗口办理不同的业务。

2、配置好每个座席所属的技能及每个技能具备的优先级。

3、配置好路由的脚本(一段程序代码)，在客户来电时：

(a)客户来电并转人工时，获取客户要的服务内容、主叫号码、客户等级。

(b)执行脚本，根据客户服务要求找到技能队列，把电话转入到该技能队列排队(相当于把客户排入对应窗口的队列)。

(c)由于座席有两个技能，相当于每个座席都同时在两个技能中，但一般是先处理主技能(座席可以两个窗口之间移动，但是一般情况在主业务的窗口)。

排队过程中，服务等级高的插到最前面，当座席服务完客户后(结束一通电话)自然接待排在最前面的客户(接起排在前面的电话)。由于两个技能，是否移到另一个窗口，需要根据实际情况确定(也可在脚本中配置)，比如次要技能窗口排队排的比现在窗口长很多，或那个窗口有个客户等级高的客户在排队，此时就移到次技能的窗口(即接起次要技能队列的电话)。

与上述图3实施例提供的事件处理方法相对应，本公开还提供一种事件处理装置，由于本公开实施例提供的事件处理装置与上述图3实施例提供的事件处理方法相对应，因此在事件处理方法的实施方式也适用于本公开实施例提供的事件处理装置，在本公开实施例中不再详细描述。

图6是本公开第三实施例所示出的事件处理装置的结构示意图。需要说明的是，该事件处理装置可应用于CTI系统。

如图6所示，该事件处理装置600包括：第一发送单元610、处理单元620和第二发送单元630。

其中，发送单元610，用于通过FS接口响应于获取到FS系统生成的初始事件，向关注初始事件的事件处理模块发送初始事件；处理单元620，用于接收所述初始事件，在所述初始事件触发所述事件处理模块中的第一CTI状态更新，且根据更新后的第一CTI状态确定所述初始事件与第一应用系统具有关联关系的情况下，根据所述初始事件，确定与所述第一应用系统匹配的目标事件，并向应用系统接口发送更新后的第一CTI状态和目标事件，第二发送单元630，用于将所述更新后的第一CTI状态和所述目标事件发送至所述第一应用系统，以使所述第一应用系统根据所述更新后的第一CTI状态，对所述目标事件进行响应。

综上，通过FS接口响应于获取到FS系统生成的初始事件，向关注初始事件的事件处理模块发送初始事件；通过事件处理模块接收初始事件，在初始事件触发事件处理模块中的第一CTI状态更新，且根据更新后的第一CTI状态确定初始事件与第一应用系统具有关联关系的情况下，根据初始事件，确定与第一应用系统匹配的目标事件，并向应用系统接口发送所述更新后的第一CTI状态和所述目标事件，通过应用系统接口将更新后的第一CTI状态和目标事件发送至第一应用系统，以使第一应用系统根据更新后的第一CT I状态，对目标事件进行响应，由此，CTI系统可在初始事件触发CTI状态更新，且初始事件与第一应用系统具有关联关系的情况下，对初始事件进行处理，有效地确定与第一应用系统匹配的目标事件，无需第一应用系统对初始事件进行处理，提高了第一应用系统对目标事件响应效率，并且降低了第一应用系统的资源占用。

在示例性实施例中，还提出了一种电子设备。

其中，电子设备包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，处理器被配置为执行指令，以实现如前述任一实施例提出的事件处理方法。

作为一种示例，图7是本公开一示例性实施例所示出的电子设备700的结构示意图，如图7所示，上述电子设备700，还可以包括：

存储器710及处理器720，连接不同组件(包括存储器710和处理器720)的总线730，存储器710存储有计算机程序，当处理器620执行所述程序时实现本公开实施例所述的事件处理方法。

总线730表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(ISA)总线，微通道体系结构(MAC)总线，增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。

电子设备700典型地包括多种电子设备可读介质。这些介质可以是任何能够被电子设备700访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

存储器710还可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(RAM)740和/或高速缓存存储器750。服务器700可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统760可以用于读写不可移动的、非易失性磁介质(图7未显示，通常称为“硬盘驱动器”)。尽管图7中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如CD-ROM，DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线730相连。存储器710可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本公开各实施例的功能。

具有一组(至少一个)程序模块770的程序/实用工具780，可以存储在例如存储器710中，这样的程序模块770包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块770通常执行本公开所描述的实施例中的功能和/或方法。

电子设备700也可以与一个或多个外部设备790(例如键盘、指向设备、显示器791等)通信，还可与一个或者多个使得用户能与该电子设备700交互的设备通信，和/或与使得该电子设备700能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口792进行。并且，电子设备700还可以通过网络适配器793与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器793通过总线730与电子设备700的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备700使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

处理器720通过运行存储在存储器710中的程序，从而执行各种功能应用以及数据处理。

需要说明的是，本实施例的电子设备的实施过程和技术原理参见前述对本公开实施例的事件处理方法的解释说明，此处不再赘述。

在示例性实施例中，还提供了一种包括指令的计算机可读存储介质，例如包括指令的存储器，上述指令可由电子设备的处理器执行以完成上述任一实施例提出的事件处理方法。可选地，计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供一种计算机程序产品，包括计算机程序/指令，其特征在于，所述计算机程序/指令被处理器执行时实现上述任一实施例提出的事件处理方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种计算机电话集成CTI系统，其特征在于，包括：

自由交互FS接口，用于响应于获取到FS系统生成的初始事件，向关注所述初始事件的事件处理模块发送所述初始事件；

事件处理模块，用于接收所述初始事件，在所述初始事件触发所述CTI系统的第一CTI状态更新，且根据更新后的第一CTI状态确定所述初始事件与第一应用系统具有关联关系的情况下，根据所述初始事件，确定与所述第一应用系统匹配的目标事件，并向应用系统接口发送所述更新后的第一CTI状态和所述目标事件；

应用系统接口，用于将所述更新后的第一CTI状态和所述目标事件发送至所述第一应用系统，以使所述第一应用系统根据所述更新后的第一CTI状态，对所述目标事件进行响应。

2.根据权利要求1所述CTI系统，其特征在于，所述事件处理模块，具体用于：

接收所述初始事件根据所述初始事件所携带的第一事件参数判断所述初始事件是否触发所述第一CTI状态更新；

在所述初始事件触发所述第一CTI状态更新的情况下，获取与所述应用系统匹配的参考状态，并判断所述更新后的第一CTI状态是否与所述参考状态匹配；

在所述更新后的第一CTI状态与所述参考状态匹配的情况下，确定所述初始事件与第一应用系统具有关联关系；

对所述初始事件进行参数过滤，得到与所述第一应用系统匹配的目标事件；

在所述初始事件所属业务的业务类型为第一业务类型的情况下，向所述应用系统接口发送所述更新后的第一CTI状态和所述目标事件，其中，第一业务类型的业务与所述更新后的第一CTI状态具有关联关系。

3.根据权利要求2所述的CTI系统，其特征在于，所述事件处理模块，还用于：

在所述初始事件所属业务的业务类型为第二业务类型的情况下，向所述应用系统接口发送所述目标事件，其中，所述第二业务类型的业务与所述更新后的第一CTI状态未具有关联关系。

4.根据权利要求1所述的CTI系统，其特征在于，所述事件处理模块，还用于：

查询设定待记录事件表，以确定所述初始事件是否为待记录事件；

在所述初始事件为待记录事件时，查询设定待记录参数表，以获取所述初始事件的待记录参数，并对所述待记录参数进行记录，以生成事件日志。

5.根据权利要求1所述的CTI系统，其特征在于，所述事件处理模块，还用于：

针对所述初始事件所携带的各第二事件参数，确定设定时间段内各所述第二事件参数在对应设定维度上的出现次数；

接收第二应用系统所发送的获取指令，响应于所述获取指令，将所述设定时间段内各所述第二事件参数在对应设定维度上的出现次数发送至所述应用系统接口，以将所述设定时间段内各所述第二事件参数在对应设定维度上的出现次数发送至所述第二应用系统。

6.根据权利要求1所述的CTI系统，其特征在于，所述第一应用系统为多个，所述事件处理模块，具体用于：

根据所述目标事件中所携带的第三事件参数，确定所述目标事件所属的业务类型和优先级；

获取各所述第一应用系统允许处理的业务类型和各所述第一应用系统在允许处理的业务类型下的优先级；

根据所述目标事件所属的业务类型和优先级，从多个所述第一应用系统中，确定目标应用系统，其中，所述目标应用系统允许处理的业务类型与所述目标事件所属业务的业务类型匹配，所述目标事件的优先级与所述目标应用系统在允许处理的业务类型下的优先级匹配；

获取与所述目标事件匹配的设定路由脚本，并执行所述设定路由脚本，通过所述应用系统接口将所述目标事件和所述更新后的第一CTI状态发送至与所述目标应用系统，以使所述目标应用系统根据所述更新后的第一CTI状态，对所述目标事件进行响应。

7.根据权利要求6所述的CTI系统，其特征在于，所述CTI系统还包括：管理模块，其中，所述管理模块，用于；

响应于第一配置操作，对各所述第一应用系统允许处理的业务类型进行配置；

响应于第二配置操作，对各所述第一应用系统在允许处理的业务类型下的优先级进行配置。

8.根据权利要求1所述的CTI系统，其特征在于，所述CTI系统还包括：命令处理模块，其中，所述命令处理模块，用于：

接收所述第一应用系统根据所述更新后的第一CTI状态，对所述目标事件进行响应所生成的应答指令；

在所述应答指令与FS系统具有关联关系的情况下，对所述应答指令进行格式转换，以得到格式转换后的应答指令；

将所述格式转换后的应答指令发送至所述FS系统，以使所述FS系统对所述格式转换后的应答指令进行应答。

9.根据权利要求8所述的CTI系统，其特征在于，所述命令处理模块，还用于：

获取与所述应答指令匹配的第二CTI状态；

在所述第二CTI状态与所述更新后的第一CTI状态不一致的情况下，将所述更新后的第一CTI状态更新为所述第二CTI状态。

10.一种事件处理方法，其特征在于，应用于CTI系统，所述CTI系统包括：FS接口、事件处理模块和应用系统接口，所述方法包括：

通过所述FS接口响应于获取到FS系统生成的初始事件，向关注所述初始事件的事件处理模块发送所述初始事件；

通过所述事件处理模块接收所述初始事件，在所述初始事件触发所述CTI系统的第一CTI状态更新，且根据更新后的第一CTI状态确定所述初始事件与第一应用系统具有关联关系的情况下，根据所述初始事件，确定与所述第一应用系统匹配的目标事件，并向所述应用系统接口发送所述更新后的第一CTI状态和所述目标事件；

通过所述应用系统接口将所述更新后的第一CTI状态和所述目标事件发送至所述第一应用系统，以使所述第一应用系统根据所述更新后的第一CTI状态，对所述目标事件进行响应。