呼叫中心事件模式的选择《一步一步开发呼叫中心系列》
编写基于三汇板卡的呼叫中心之前，我们得先理解三汇提供的4种驱动程序事件处理模式：
1.轮询模式：由应用程序不停地调用驱动程序提供的相关查询函数，以获取任务的进展情况。这种编程方式由于消耗计算机的资源较多，效率很低，只能适用于容量较小的应用系统，目前已经被逐渐淘汰。
2.事件等待：应用程序调用驱动程序提供的事件等待函数，当驱动程序没有事件时，应用程序的调用者线程被阻塞；当驱动程序抛出某个事件时，应用程序的调用者线程被重新激活，恢复对事件的处理。
3.事件回调：由应用程序向驱动程序注册一个回调函数，当驱动程序有事件发生时，由驱动程序调用回调函数，对事件进行处理。
4.Windwos消息模式（只适用于Windows操作系统，且输出事件的数据结构只能是MESSAGE_INFO）：驱动程序将事件发送到Windows的消息队列中，通过Windows统一的消息队列处理机制，来对事件进行处理。由于Windows消息模式可以携带的参数有限，因此实际使用这种编程模式的应用程序并不多。
这4中模式各有优缺点，每个模式的使用场景在官方文档上面已经写得比较清楚。下面我再基于自己的理解进行总结。
轮询模式轮询模式就像我们的缓存自动更新模块，使用一个死循环，不停地扫描数据状态，如果数据发生了变更，再根据业务场景进行业务处理。
在三汇语音板卡中，轮询模式也是一个道理：使用一个死循环，不停地扫描板卡中每个通道的状态，当通道状态发生变更之后，再根据上一次状态与当前状态判断应该进入什么样的业务流程处理。
一般来说，在10个以下通道（包括坐席和外线）的场景下，这个模式还是可以使用的，但是相应的，还是效率会有明显的降低。而且这样做的话，基本上这个呼叫中心已经没有了任何的可扩展性，因为一个公司如果需要添加更多的外线或者坐席，这种模式消耗的资源将完全拖累正常的呼叫系统使用。
通常，这种模式仅用于三汇内部对外提供的Demo中。实际生产过程中，几乎没人会用这种吃力不讨好的事情。
事件等待模式这种模式是官方推荐使用的模式，也是本系统目前采用的模式。
有点类似于C#多线程中的线程阻塞，一直到指定的委托或线程返回结果为止。
此模式消耗的系统资源较少，仅需要开启一个后台线程，编写一个死循环，在循环中阻塞等待直到三汇驱动返回事件为止，再根据事件参数进行业务处理。
据说这种模式，最多支持单卡500坐席的规模。
事件回调模式顾名思义，与C#中的事件回调模式相差无几。
启用这种模式之后，系统不需要开启后台死循环线程，仅需要提供一个内存中存在的函数指针，即可实现。当驱动程序有事件时，将直接把事件信息回调此函数指针，回调到我们编写的应用程序中。
这种模式是三汇官方推荐的第二种方案，前期我也使用了一段时间，但是不知道由于什么原因，始终会有事件回调不回来，故改为事件等待模式。
如果哪位园友对此模式研究甚深，请不吝指教。
Windows消息模式此模式，不仅可以使用Windows消息队列，还可以使用Windows窗口句柄作为消息处理载体。由于并没有对此模式进行深入研究，此处不做细表。
无论如何，我们决定了选择使用轮询模式来开发我们的呼叫中心CTI系统。
事件等待模式，虽然作为官方推荐的模式，但是仍然有很多细节问题需要我们注意：
1.事件等待的线程，必须作为单独的后台线程存在，避免线程阻塞导致整个CTI程序无响应。
2.接收到驱动程序事件返回之后，必须重新启动一个新的后台线程进行业务处理，避免业务处理时间过长，丢失掉驱动程序后续的事件返回信息。
事件模式确认之后，我们需要知晓如何来等待驱动程序的事件返回，这就需要用到SsmWaitForEvent（或者SsmWaitForEventA函数，两者无实际区别）
关于SsmWaitForEvent函数获取Synway驱动程序输出的事件。异步函数，如果有事件则立即返回；如果没有事件，调用者线程将被阻塞，直到有事件发生或者超时才返回。
关于此函数的使用方式，可参考下面的源码：
PRivate static void Polling() { // 开启死循环，进行事件等待 while (true) { // 事件信息 MESSAGE_INFO Event = new MESSAGE_INFO(); // 等待并响应驱动程序抛出的事件 // 参数0xffff表示：如果没有事件，函数一直挂起，直到有事件时才返回； if (ApiFunction.SsmWaitForEvent(0xffff, ref Event) == 0) { EventParameter p = new EventParameter() { Event = (EventCode)Event.wEventCode, Ch = Event.nReference, DwParam = (int)Event.dwParam }; // 新开启线程进行事件处理 // 参数ProcessEvent为内部事件处理函数句柄 ThreadPool.QueueUserWorkItem(ProcessEvent, p); } } }
事件等待模式的确是效率最高的模式，然而，语音板卡的事件有很多（至少我是没有数清到底有多少种事件）如果每一个事件都返回到我们的CTI中处理一次，肯定会给CTI程序带来一定的压力，所以，我们在启动事件模式时，还应该对需要驱动程序返回的事件，进行一次筛选设置，告诉驱动程序，只返回我们关心的事件信息，无用的或者CTI不关心的事件，可以不用返回。
在三汇的驱动包中，有这么一个函数：SsmSetEvent，这是一个神一般的函数，它既担任了设置事件模式的责任，又担任了过滤事件的责任，仅仅是因为参数不一样从而导致作用不一样。
函数原型：
int SsmSetEvent(Word wEvent, int nReference, BOOL bEnable, PEVENT_SET_INFO pEventSet)
其中，wEvent参数含义如下：
0~0xfffe：事件编码，取值范围请参见第1章中“MESSAGE_INFO”部分内容。此时，SsmSetEvent用于通知驱动程序抛出或不抛出特定事件。
0xffff： 设置整个驱动程序的工作模式，即事件等待模式和事件回调模式，此时参数nReference必须为-1。
可参考如下源码：
// 配置文件DefaultEventOutput项已经配置为0，不输出任何事件 EVENT_SET_INFO set = new EVENT_SET_INFO(); set.dwWorkMode = (int)EventMode.EVENT_POLLING; // 事件列表 List<ushort> events = new List<ushort>(); // 设置事件模式 events.Add(0xffff); // E_CHG_RcvDTMF 收到一个Dtmf events.Add(0x000C); // E_CHG_ChState 通道状态改变事件 events.Add(0x0018); // E_CHG_RingCount 模拟中继线通道：铃流信号检测器中信号周期的计数器发生变化 events.Add(0x001E); // E_CHG_FlashCount 坐席通道或者录音通道：在电话机上检测到一次闪断操作 events.Add(0x0023); // E_PROC_PlayEnd 放音任务结束 events.Add(0x000F); int r = 0; foreach (var item in events) { r = ApiFunction.SsmSetEvent(item, -1, 1, ref set); if (r != 0) { SendErrorMessage("事件初始化失败。"); return; } }
好了，对于三汇语音板卡呼叫中心的事件模式就总结到这里，下一篇我们将介绍如何设计事件响应核心CTI系统。
欢迎大家拍砖。
另外，本人QQ：416263499，欢迎交流。
