第五代呼叫中心之SOA（四）
北京商路通信息技術(shù)有限公司 黃河
2009/11/17
第五代呼叫中心之SOA（一）
第五代呼叫中心之SOA（二）
第五代呼叫中心之SOA（三）
上一章說的是基于SOA思想建設一個呼叫中心很難，主要難點是靈活性和穩(wěn)定性的矛盾。是啊，一方面客戶要求7*24小時不停機，另一方面，客戶需求在不斷變化，處于這個矛盾中間，我們?nèi)绾位赟OA的思想建設呼叫中心呢？
我認為核心在于根據(jù)穩(wěn)定性和靈活性的要求提供呼叫中心需要的服務接口以及接口的組織。
一 服務接口的提供
呼叫中心服務的接口包括以下內(nèi)容：
- 交換機服務接口；
- IVR物理環(huán)境服務接口，如語音板卡、H.323語音終端、SIP語音終端接口；
- 錄音物理環(huán)境服務接口，如錄音板卡、IP語音鏡像錄制軟件接口；
- CTI服務器服務接口；
- IVR服務器服務接口；
- 錄音服務器服務接口；
- ACD服務器服務接口；
- ADS服務器服務接口；
- ACC服務器服務接口；
- ICC服務器服務接口；
- 坐席軟電話服務接口；
- 業(yè)務軟件服務接口；
- 報表服務器服務接口；
- 實時統(tǒng)計服務器服務接口。
我現(xiàn)在對以上的接口進行分析，并提出我的建議。
1.1 通信服務接口的標準化
對于通信相關(guān)的服務接口，標準化程度相對高一些，恰恰是基于SOA思想建設一個呼叫中心中相對簡單的問題。
交換機接口、IVR物理環(huán)境接口、錄音物理環(huán)境接口，有很多標準，有些是ITU、ECMA、W3C的標準，有些則是事實的標準，由國際大廠商主導的。
按照標準提供接口，好處有兩個：
一方面，接口非常穩(wěn)定，以CSTA II為例，現(xiàn)在還是主流的交換機和計算機通信的協(xié)議，這個協(xié)議是ECMA組織在1994年發(fā)布的，經(jīng)過了15年時間，依然是主流協(xié)議；TAPI則是微軟在1994年就開始發(fā)布了，最晚的版本TAPI3.0
也是和Windows 2000同時發(fā)布的，可見這部分標準是穩(wěn)定性很高，標準穩(wěn)定，意味著軟件可以大規(guī)模復制，開發(fā)成本低，而且軟件穩(wěn)定性高；
另一方面，既然有標準，而且還是大廠商主導的，那么大廠商在建立標準的時候，已經(jīng)將大量的復雜或者說多變的需求已經(jīng)考慮進去了，因此，按照標準提供的服務接口，靈活性是有保證的。
對于這部分接口，是通信和計算整合的關(guān)鍵，是世界級的難題，既然是世界級的難題，就讓世界級的大廠商解決，由他們來解決的穩(wěn)定性和靈活性的矛盾解決。我們只需要利用大廠商的勞動成果即可。
1.2 CTI服務器服務接口
CTI服務器穩(wěn)定性要求很高，因為CTI服務器的故障會導致整個呼叫中心的呼叫相關(guān)的軟件無法工作。
CTI服務器靈活性要求很低，它只需要將交換機來的數(shù)據(jù)進行分發(fā)，收集來自其他系統(tǒng)的命令，發(fā)送給交換機即可。
因此，CTI服務器的服務接口相對簡單。
1.3 ACD服務器和IVR服務器的服務接口
ACD和IVR接口是呼叫中心中的難點，相對于用戶來說，ACD和IVR提供了服務接口，而對其他軟件系統(tǒng)，同樣需要服務接口以便ACD和IVR調(diào)用。
ACD和IVR流程控制的復雜性，后面我們會詳細說明，現(xiàn)在重點說一下ACD和IVR對其他軟件系統(tǒng)的服務接口。
一方面，ACD和IVR需要調(diào)用其他軟件的服務接口，接口形式如下：COM、DCOM、DLL、TCP、UDP、ASP、JSP、PHP、Web Service。
另一方面，ACD和IVR需要提供調(diào)用接口以供其他軟件系統(tǒng)調(diào)用，其中包括WebService服務接口、TCP服務器接口�？梢栽O想，ADS需要控制IVR外撥，坐席軟電話需要控制IVR播報需要的語音、ACD服務器需要IVR在客戶排隊的時候播報等待的提示語，ACD服務器需要提供排隊信息給實時統(tǒng)計，ACD服務與ADS進行交互等。
ACD和IVR服務接口沒有標準，需要我們根據(jù)國內(nèi)的客戶需求分析整理，我的建議如下：
服務接口要求全面：必不可少的包括數(shù)據(jù)庫訪問、Web Service和TCP，為了進一步降低用戶開發(fā)成本，建議提供COM、DCOM、DLL、UDP、ASP、JSP、PHP；
實時性：提供的服務接口滿足實時性要求，即要求可以流程并行執(zhí)行，例如，IVR在流程中，需要查詢一個客戶需要的數(shù)據(jù)，大概需要10秒鐘，那么，流程在查詢的過程中，需要同時執(zhí)行放音流程，以便用戶能夠耐心等待；
數(shù)據(jù)復雜計算：在外部交互的時候，需要對數(shù)據(jù)需要復雜處理，需要支持VBScript、Jscript等等，而且，為了保證實時性，建議使用不要使用流行的瀏覽器中腳本引擎。
另外，我建議將交換機定義的坐席狀態(tài)做封裝和擴展，對外提供服務接口。
1.4 錄音服務器服務接口
錄音服務接口實時性要求比較高，建議的接口形式為Web Service和TCP。
需要提供的服務包括以下幾個方面：
- 錄音的啟動停止控制：例如，坐席控制錄音的啟動停止；
- 錄音記錄呼叫標識及數(shù)據(jù)的輸入：第三方系統(tǒng)接收CTI系統(tǒng)的事件，根據(jù)CTI事件控制錄音啟動停止，將CallId、主叫和被叫號碼輸入到錄音系統(tǒng)中；
- 錄音關(guān)聯(lián)的業(yè)務數(shù)據(jù)的輸入：例如，錄音記錄中，需要包含業(yè)務的訂單ID、工單ID、產(chǎn)品名稱等等數(shù)據(jù)；
- 錄音實時統(tǒng)計的輸出：有的呼叫中心經(jīng)常需要顯示每一條線的錄音狀態(tài)和數(shù)據(jù)；
- 錄音記錄數(shù)據(jù)的輸出：很多業(yè)務系統(tǒng)中需要在錄音開始或者錄音剛剛結(jié)束時，即提取錄音相關(guān)數(shù)據(jù)，進行業(yè)務處理，例如提取錄音文件名、錄音時長等記錄到工單數(shù)據(jù)庫中；
- 錄音查詢接口：這是基本的接口。
1.5 ADS服務器服務接口
ADS服務器服務一部分對性能要求有較高的部分，也有較低的部分。
ADS對于性能要求較低部分的接口包括：
- 號碼導入：ADS需要外部號碼導入的服務接口；
- 外撥結(jié)果輸出：ADS需要將外撥運行的結(jié)果輸出到報表服務器，以便形成報表；
- 錄音數(shù)據(jù)整合：為錄音服務器提供錄音需要的特定的ADS的外撥數(shù)據(jù)。
ADS對于性能要求較高部分的接口包括：
- 實時統(tǒng)計數(shù)據(jù)獲�。篈DS為了執(zhí)行外撥算法，需要實時獲得中繼、IVR、隊列、坐席的實時統(tǒng)計數(shù)據(jù)；
- ACD交互：ADS和ACD交互以達到合理的呼叫分配，在呼入呼出混合的呼叫中心中尤其重要；
- 實時統(tǒng)計數(shù)據(jù)輸出：ADS需要將內(nèi)部數(shù)據(jù)實時輸出到管理者控制臺；
- 實時策略調(diào)整輸入：ADS需要接受管理者的實時控制，如加強或減弱外撥強度等。
1.6 ICC服務器和ACC服務器服務接口
ICC服務器和ACC服務器的服務接口我認為在控制和事件的內(nèi)容上按照交換機的服務接口設計，以達到最高的復用程度，建議參考CSTA-II、CSTA-III或者是TSAPI接口。
1.7 坐席軟電話服務接口
坐席軟電話的服務接口是針對坐席業(yè)務軟件提供的。
我的建議提供如下接口：
- 透傳交換機的服務接口（當然是經(jīng)過CTI服務器轉(zhuǎn)換過的）；
- 透傳ACD和IVR服務接口；
- 透傳ADS服務器服務接口；
- 透傳ICC服務器和ACD服務器服務接口；
- 透傳報表服務器中呼叫相關(guān)的服務接口；
- 透傳實時統(tǒng)計服務器中呼叫相關(guān)的服務接口。
1.8 業(yè)務軟件服務接口
業(yè)務軟件服務接口是和具體的服務行業(yè)相關(guān)的，需要按照行業(yè)內(nèi)的需求進行劃分，在這里，我只有一個建議，最好要用WebService接口。
1.9 報表服務器服務接口
報表服務器對外接口方面實時性要求不高。
報表服務器包括兩個部分，一個是呼叫（包含坐席管理）相關(guān)的報表服務器，一個是只包含業(yè)務軟件數(shù)據(jù)的報表服務器。
只包含業(yè)務軟件數(shù)據(jù)的報表服務器服務接口是和具體的服務行業(yè)相關(guān)的，需要按照行業(yè)內(nèi)的需求進行劃分，在這里，我還是只有一個建議，最好要用WebService接口。
呼叫相關(guān)的報表服務器，我建議有兩個方面：
- 以WebService的形式提供；
- 以結(jié)果臨時表的形式提供；
- 報表指標項本身全面。
1.10 實時統(tǒng)計服務器服務接口
實時統(tǒng)計服務器服務接口的形式建議不用WebService這樣效率較低的接口形式，建議如下：
- 采用格式緊湊的TCP基礎上的傳輸形式；
- 對外調(diào)用接口盡量豐富，包括Dll、Ocx；
- 為了B/S調(diào)用方便，最好直接提供封裝AJAX的Java Script對象；
- 提供訂閱方式的接口；
- 提供類似于SQL的查詢方式和結(jié)果集返回方式。
二 ESB與實時服務總線
從上面我們可以看出，各個系統(tǒng)都需要提供服務接口，這樣，各個部分之間的交互會非常非常多。
建議對于實時性要求不高的業(yè)務軟件部分采用ESB降低交互的復雜度；對于實時性要求較高的呼叫相關(guān)的軟件部分建立實時服務總線。
ESB的接口自然以WebService形式提供，而實時服務總線比較復雜，經(jīng)常需要以三種形式提供接口：
- 軟電話OCX：用于坐席業(yè)務和總線通信；
- dll：用于服務器軟件與總線通信；
- Java Script對象：封裝AJAX，用于Web客戶端與總線通信。
三 服務的接口與流程策略的關(guān)系
按照SOA的思想，軟件的功能是按照服務的方式提供的，其他軟件將服務聚合，按照“搭積木”的方式即可快速生成業(yè)務。
第五代呼叫中心中，各個部分只要提供合理的服務，快速生成業(yè)務也就成為可能。
但是，只考慮服務的聚合是不夠的，還要考慮服務的流程策略，不斷變化的流程讓耗費了大量的開發(fā)成本，也大大影響了軟件的穩(wěn)定性。
呼叫中心的流程策略我認為應該分成兩個部分，一部分是實時性要求較低的業(yè)務相關(guān)的流程，另一個部分是實時性要求很高的呼叫相關(guān)的流程。
目前，業(yè)務軟件方面，普元的BPS迅速崛起，就是SOA流程平臺，解決基于SOA思想軟件如何處理復雜多變的流程的。因此，建議業(yè)務軟件為了實現(xiàn)業(yè)務敏捷需要使用或者自行開發(fā)流程平臺。
可是，實時性要求很高的呼叫相關(guān)的流程策略需要特殊的流程平臺，這部分流程包括IVR流程、呼叫路由流程、坐席狀態(tài)管理策略、外撥策略、告警策略等等。因此，建議實時的工作流平臺由呼叫中心廠商自行提供。
下一章，開始講實戰(zhàn)的部分。
第五代呼叫中心之SOA (五)
第五代呼叫中心之SOA（六）
第五代呼叫中心之SOA(七)
第五代呼叫中心之SOA(八)
第五代呼叫中心之SOA(九)
CTI論壇編輯
相關(guān)閱讀: