基于VoiceXML技術(shù)可視化IVR設(shè)計和實現(xiàn)(二)
上海易谷網(wǎng)絡(luò)科技有限公司 查瑋 2009/12/29
基于VoiceXML技術(shù)的可視化IVR系統(tǒng)設(shè)計和實現(xiàn)(一)
交互式語音應(yīng)答(IVR)系統(tǒng)是電話銀行呼叫中心系統(tǒng)的最前端,它的質(zhì)量直接影響整個系統(tǒng)的穩(wěn)定性和可擴(kuò)展性。本文設(shè)計的IVR系統(tǒng)主要分為兩個模塊:可視化過程定義工具(用戶交互接口)、流程執(zhí)行引擎。由于過程定義工具主要是面向用戶,它的設(shè)計規(guī)范首先要符合流程的定義規(guī)則,反應(yīng)到本文中即流程工具涉及到的節(jié)點類型均符合IVR的操作動作和相關(guān)的業(yè)務(wù)動作,同時還要生成符合流程執(zhí)行引擎能處理的文件格式。在流程執(zhí)行引擎方面,符合VoiceXML的設(shè)計框架,將Web應(yīng)用和語音應(yīng)用相結(jié)合。圖3.1 IVR系統(tǒng)整體結(jié)構(gòu)圖
3.2可視化過程化定義工具的分析
可視化建模語言的模型必須具備足夠豐富的描述能力來表達(dá)所需的流程的實體及相互關(guān)系,它必須易于實現(xiàn)且有著良好的用戶的交互性。一種模型描述方式是使用類過程語言的邏輯和實體描述語言,將IVR工作流程寫為一段語言程序,活動、數(shù)據(jù)和邏輯關(guān)系等在內(nèi)部加以界定;另外一種方式是將活動或邏輯從過程邏輯中抽象出來,形成獨立的對象(邏輯關(guān)系可以作為活動對象的內(nèi)部屬性,也可以作為獨立的對象)。
傳統(tǒng)的實現(xiàn)IVR系統(tǒng)的方法[20],經(jīng)歷了一個由復(fù)雜到簡單的發(fā)展歷程。
它已經(jīng)由基本代碼編寫發(fā)展到現(xiàn)在的高度抽象的計算機(jī)模型的實現(xiàn)方法。在這個過程中主要出現(xiàn)了以下幾種方法:
代碼生成:此種方法主要是根據(jù)工作流程的要求,由技術(shù)人員手工編寫代碼實現(xiàn)。這增加了開發(fā)的難度和系統(tǒng)的復(fù)雜度,可擴(kuò)展性較差,不利于系統(tǒng)的復(fù)用,從圖2.1所示的可視化建模工具總體框架可以看出,這種方法將過程建模和業(yè)務(wù)流程以及相關(guān)數(shù)據(jù)和工作流程處理集成在一起,通過代碼生成的方式實現(xiàn)工作流過程。
表格方式:此種方法在過程建模部分由表格方式實現(xiàn),通過手動添加業(yè)務(wù)流程執(zhí)行過程狀態(tài);同時將工作流過程中的每一個狀態(tài)封裝成函數(shù)或類。在工作流引擎執(zhí)行過程中,通過讀取表格內(nèi)容,調(diào)用相應(yīng)的函數(shù)實現(xiàn)功能。這種方法雖然在一定程度上降低了業(yè)務(wù)流程引擎部分的復(fù)雜,但增加了過程建模的復(fù)雜度,導(dǎo)致用戶接口人性化程度降低,應(yīng)用程序交互的接口定義的靈活度受到的限制。
圖和鏈表方式:這種方法在過程建模部分相對于表格方式做了改進(jìn),取消了表格,代之以圖和鏈表,使用戶接口部分體現(xiàn)了圖形化和人性化的特點。但由于圖的結(jié)構(gòu)復(fù)雜,用戶在使用容易出錯,同時業(yè)務(wù)流程引擎在執(zhí)行過程中圖的結(jié)構(gòu)增加了流程解釋執(zhí)行的復(fù)雜度。
樹型方式:樹型方式是目前常用的方法,采用的是父-子關(guān)系模式。這一模式的指樹中的任何節(jié)點(狀態(tài))的下一個狀態(tài)節(jié)點都以此節(jié)點的子節(jié)點方式出現(xiàn)。雖然這種方法使用戶界面更加清晰,但樹的深度加大會給實現(xiàn)業(yè)務(wù)流程引擎和過程建模工具增加了難度。
根據(jù)上述對傳統(tǒng)的IVR系統(tǒng)的分析和實現(xiàn)方法的比較,本文提出VoiceXML應(yīng)用于可視化建模工具中,在用戶接口部分沿用的樹型方式,但根據(jù)VoiceXML的規(guī)范性和靈活性,相鄰節(jié)點之間的關(guān)系由原來的父子關(guān)系變?yōu)樾值荜P(guān)系。這樣無論過程建模還是在工作流程引擎的實現(xiàn)難度都被極大降低。
過程定義模型向用戶提供的用于抽象描述業(yè)務(wù)過程的設(shè)計元素會通過工作流過程定義工具表達(dá)出來,用戶使用過程定義工具提供的輸入界面,通過將各中設(shè)計控件加以組合來完成對實際業(yè)務(wù)流程的抽象描述[21]。在設(shè)計過程定義工具時,本文采用了圖形化的用戶界面,從而簡化了建模操作的復(fù)雜行,提高了易用性,有效降低了使用難度。
3.2.1 過程定義建模語言的描述
根據(jù)可視化建模語言描述的方法,語言和編輯器配置項體現(xiàn)了系統(tǒng)的可配置性。它包括三個部分:圖元庫、編輯器定義文件、界面描述文件。
圖元庫是對可視化建模語言語素的定義。編輯器定義文件中包含了可視化語言語法(抽象語法和具體語法)、圖元操作定義、靜態(tài)語義元類與圖元的靜態(tài)關(guān)系,采用RGVL的方式來描述。界面描述文件定義可視化語言編輯器的主界面,包括對菜單、各種工具條、各種視圖、狀態(tài)條。
3.2.2 基于可視化技術(shù)的過程定義工具的功能
IVR系統(tǒng)的過程定義工具是一個可視化的軟件工具,它主要用于定義工作流模型中各個活動之間的關(guān)系[22]。工作流程過程定義向用戶提供對實際業(yè)務(wù)處理過程分析、建模的手段。其輸入輸出可以用圖3.2表達(dá):
圖3.2 IVR系統(tǒng)流程開發(fā)工具的輸入和輸出
其功能可以細(xì)分為:
圖3.3 IVR系統(tǒng)流程定義工具用例圖
式(3-1)
表示節(jié)點圖元可以連接多個關(guān)聯(lián)關(guān)系,每個關(guān)聯(lián)關(guān)系必須連接到一個節(jié)點圖元。
每一個節(jié)點保存自己的唯一的節(jié)點名稱,由CArrowLine類來保存其關(guān)聯(lián)關(guān)系,因為兩個節(jié)點之間的關(guān)聯(lián)關(guān)系只有二向性,所以只需要保存一個
節(jié)點名稱和一個 節(jié)點名稱。類圖如圖3.5所示,CLinkFactory類的作用是一個獲取當(dāng)前節(jié)點名稱,CNodeMenu類是菜單(Menu)
節(jié)點類,繼承CDiagramEntity類。圖中只是以CNodeMenu類未代表來表示所有的節(jié)點類。
圖3.6 目標(biāo)文件基本框架圖
例如,放音節(jié)點的完整文件描述如下:
圖3.7 目標(biāo)文件生成類圖
MainFramwork
文件的主框架,主要是標(biāo)準(zhǔn)html標(biāo)簽的生成;
CreateVXMLTree
調(diào)用標(biāo)準(zhǔn)的XML類生成VoiceXML樹;
UserAddContent
插入用戶輸入的自定義代碼;
OutPutFile
輸出目標(biāo)文件。
3.5 IVR系統(tǒng)執(zhí)行引擎的分析
IVR系統(tǒng)執(zhí)行引擎作為IVR系統(tǒng)的核心,是整個系統(tǒng)的控制中樞。它所完成的功能是對IVR系統(tǒng)業(yè)務(wù)流程的解釋和驅(qū)動。
3.5.1基于VoiceXML的執(zhí)行引擎
隨著Internet和Web技術(shù)的迅速發(fā)展,越來的企業(yè)開始建立自己的門戶網(wǎng)站,同時又擁有自己的IVR系統(tǒng)(如圖3.8所示),但是兩套系統(tǒng)完全獨立,語音系統(tǒng)和數(shù)據(jù)系統(tǒng)沒有任何交互或者只有很少的交互。而建立IVR系統(tǒng)的目標(biāo)就是給客戶更好的體驗,使客戶能方便的通過電話完成更多以前需要登陸企業(yè)門戶網(wǎng)站,或者親自去企業(yè)或其網(wǎng)點去辦理的業(yè)務(wù),這就需要IVR系統(tǒng)能跟后臺數(shù)據(jù)系統(tǒng)有更多更好的交互!罢Z音門戶”的概念出現(xiàn)也愈發(fā)的證明這一點。
圖3.12 IVR系統(tǒng)執(zhí)行引擎系統(tǒng)交互序列圖
3.6.2 VoiceXML解析器的設(shè)計
作為VoiceXML語言的解釋工具,文檔解析是VoiceXML解析器主要任務(wù),也是執(zhí)行引擎的重要組成部分,文檔解析的內(nèi)容決定了執(zhí)行平臺的下一步操作,也是整個系統(tǒng)運行的核心。因為VoiceXML文檔首先是一個XML文檔,所以主要包含對象樹生成模塊和語義解釋模塊兩個部分。其中對象樹生成模塊是對VoiceXML文檔進(jìn)行XML方式的解析,解釋模塊使用FIA算法對生成的對象進(jìn)行解析。圖3.13描述了VoiceXML解析器文檔解析的模型。
圖3.13 VoiceXML解析器文檔解析模型圖
1.對象樹生成模塊
計算機(jī)無法直接對VoiceXML文檔操作來實現(xiàn)解釋功能,必須把VoiceXML文檔轉(zhuǎn)換成易識別、易操作的數(shù)據(jù)結(jié)構(gòu)。所以,在進(jìn)行VoiceXML語義分析之前,首先要按照對XML文件的處理方式,用接口程序?qū)ξ臋n進(jìn)行分析,生成一棵VoiceXML對象樹。該樹包含了從文檔中獲取的數(shù)據(jù)和處理數(shù)據(jù)的方法,并完成部分的初始化,構(gòu)建索引等輔助工作。這棵樹是后面解釋模塊的核心基礎(chǔ)。對象樹生成模塊負(fù)責(zé)讀取從文檔獲取模塊傳來的VoiceXML文檔,調(diào)用接口程序?qū)ξ臋n分析,生成對象樹,并把此對象樹的指針傳給解釋器。
目前最通用的接口為DOM(Document Object Model)和SAX(Simple API for XML)。
DOM[27]即文檔對象模型,是W3C開發(fā)的一組獨立于語言和平臺的結(jié)構(gòu)化文檔編程接口,它定義了文檔的邏輯結(jié)構(gòu)以及訪問和操縱文檔的方法。使用DOM模型,程序所面對的XML文檔不是一個文本流,而是一棵對象樹。程序員可以方便的創(chuàng)建文檔、導(dǎo)航其結(jié)構(gòu),或增加、修改、刪除、移動文檔的任何部分。
SAX[28]的誕生是在XML-DEV討論組上,提出他的原因是有一些情況不適用DOM接口,而且DOM實現(xiàn)太大而且比較慢。SAX接口規(guī)范是XML分析器和XML處理器提供的較XML更底層的接口。它能提供應(yīng)用以較大的靈活性。SAX是一種事件驅(qū)動的接口,它的基本原理是,由接口的用戶提供符合定義的處理器,XML分析時遇到特定的事件,就去調(diào)用處理器中特定事件的處理函數(shù)。SAX
的主要限制是它無法向后瀏覽文檔。實際上,激發(fā)一個事件后,語法分析器就將其忘記。
在本文設(shè)計的系統(tǒng)中,采用了DOM接口和SAX相結(jié)合的方式:使用SAX構(gòu)建DOM樹,主要是因為對VoiceXML語言解釋的過程中,需要反復(fù)瀏覽不同的接點元素,采用DOM
樹結(jié)構(gòu)會方便許多。結(jié)合DOM和SAX的優(yōu)點,用SAX建立一棵仿DOM的樹,樹的數(shù)據(jù)結(jié)構(gòu)的定義更加符合自身的要求,不僅簡練,而且在定義節(jié)點的同時實現(xiàn)了操作。圖3.14顯示了用SAX解析方法模擬DOM樹的過程。
圖3.14用SAX解析方法模擬DOM樹的過程
2.語義解釋模塊
語義解釋模塊的主要功能是實現(xiàn)流程文檔的解釋工作,控制整個的會話過程和與輸入輸出功能模塊實現(xiàn)交互操作。該模塊處理的數(shù)據(jù)結(jié)構(gòu)是對象樹生成模塊提供的對象樹。模塊功能的實現(xiàn)依賴于對象樹提供的結(jié)構(gòu)及樹節(jié)點上相應(yīng)的操作,對象樹表述了文檔的全部信息以及處理方法,語義解釋模塊依照這棵樹上的信息完成所有控制操作。
VoiceXML文檔結(jié)構(gòu)和執(zhí)行過程
每個VoiceXML文檔都構(gòu)成一個有限狀態(tài)自動機(jī),主要是由Dialog組成,主要分為單文檔和多文檔地執(zhí)行過程。
(1)單個文檔的執(zhí)行過程。文檔默認(rèn)的從第一個Dialog開始執(zhí)行,Dialog沒有指定后繼的Dialog時,文檔解釋結(jié)束。
(2)多文檔的應(yīng)用的執(zhí)行。如果在會話過程中希望使用多個文檔來共同完成一個工作,這時就需要采用多文檔方式。多文檔方式的優(yōu)點是:應(yīng)用根文檔的變量可以為其他子文檔所共享,信息可以被共享和獲取,可以從一個文檔跳到另一個;應(yīng)用根文檔的語法可以一直保持激活的狀態(tài),可以保證用戶總是和通用的Form
或Menu 的交互,例如提示給用戶的一些具有普遍性的幫助信息等。
Form解釋算法[29](FIA:Form Interpretation Algorithm)
Form 解釋算法對VoiceXML文檔進(jìn)行了語義分析和解釋,驅(qū)動Form、Menu 和用戶的交互。FIA 算法主要分為兩個階段:初始化階段和主循環(huán)階段。
(1)初始化階段:完成Form內(nèi)各種變量的初始化操作,包括計數(shù)器置為1,初始化一般變量和Item變量等操作。
(2)主循環(huán)階段又被分為三個子階段:選擇階段、收集階段和處理階段。這三個子階段循環(huán)運行,直到解釋完成為止。
選擇階段:選擇要執(zhí)行的Item,一般情況是順序選擇沒有執(zhí)行的Item。 當(dāng)沒有發(fā)現(xiàn)要執(zhí)行的Item時,解釋操作完成。
收集階段: 完成對用戶輸入信息和事件的收集。首先訪問選定的Item 來播放提示音,可以根據(jù)提示次數(shù)選擇提示音,激活語音或DTMF 的Grammar,然后等待收集用戶輸入或事件。
處理階段:對收集到的用戶輸入信息和事件進(jìn)行處理。如果用戶輸入后,對用戶輸入信息進(jìn)行語法匹配,執(zhí)行相應(yīng)的Filled元素來執(zhí)行輸入處理。如果用戶輸入匹配的是另一個不同Dialog中的Grammar,則完成當(dāng)前Dialog的解釋,跳轉(zhuǎn)到新的Dialog;如果事件被拋出,選擇正確的Catch元素來處理,并執(zhí)行相應(yīng)的事件處理過程。在處理完成后,重新進(jìn)入選擇階段。
解釋器完成文檔的語義功能。它獲得對象生成模塊生成的VoiceXML對象樹。按照算法FIA(表單解釋算法)搜索VoiceXML對象樹、讀取樹節(jié)點的節(jié)點屬性、調(diào)用資源代理模塊,通過輸入輸出模塊接口與客戶進(jìn)行語音交互,完成整個交互流程。
3.6.2 Telephoney Service的設(shè)計
當(dāng)VoiceXML解析器做完解析工作之后,遇到需要語音操作時,就得依靠調(diào)用Telephoney API來完成,同時Telephony Service需要向VoiceXML解析器去返回相應(yīng)的語音操作結(jié)果事件。圖3.15描述了這一過程。
圖3.15 VoiceXML解析器與Telephony Service交互圖
調(diào)用的過程相對簡單,只需按照標(biāo)簽的定義調(diào)用相應(yīng)的API即可,如當(dāng)解析到
標(biāo)簽的時候直接調(diào)用播放語音文件接口。需要向Telephoney Service調(diào)用API所涉及到的VoiceXML標(biāo)簽如表3.2所示。
表3.2 涉及到IVR系統(tǒng)語音操作的VoiceXML標(biāo)簽表
標(biāo)簽名稱 |
說明 |
<prompt> |
播放語音文件或者隊列 |
<transfer> |
呼叫轉(zhuǎn)移 |
<record> |
錄音 |
<disconnect> |
斷開語音 |
當(dāng)Telephony Service處理完相應(yīng)的語音操作的時候,需要向VoiceXML解析器返回操作結(jié)果事件,由VoiceXML解析器重的接收線程來獲取,返回事件分為兩類:正常事件和掛斷事件。正常事件指的是語音卡執(zhí)行完動作后返回的結(jié)果,分為執(zhí)行成功和失敗事件;掛斷事件表示語音卡在收到用戶掛機(jī)事件后發(fā)送給解析器的事件。同時,在VoiceXML解析器向語音平臺調(diào)用Telephoney
API的同時,會啟動一個計時器來進(jìn)行超時判斷,來處理如果語音平臺沒有回消息的情況。
3.7本章小結(jié)
本章首先分析了傳統(tǒng)IVR系統(tǒng)的優(yōu)缺點,并基于可視化建模語言設(shè)計了IVR系統(tǒng)的總體結(jié)構(gòu)。其次在對過程化定義工具的使用上才采用圖形化的方式來實現(xiàn)和用戶交互,滿足簡單易用的特點。最后,分析了傳統(tǒng)的IVR系統(tǒng)執(zhí)行引擎的特性,引入了VoiceXML技術(shù),設(shè)計出基于VoiceXML的IVR系統(tǒng)執(zhí)行引擎的基本框架。
基于VoiceXML技術(shù)的可視化IVR系統(tǒng)設(shè)計和實現(xiàn)(三)
基于VoiceXML技術(shù)可視化IVR設(shè)計和實現(xiàn)(四)
作者獨家提供CTI論壇稿件,其它媒體謝絕轉(zhuǎn)載
CTI論壇報道
基于VoiceXML技術(shù)可視化IVR設(shè)計和實現(xiàn)(三) 2009-12-29 |
基于VoiceXML的可視化IVR系統(tǒng)設(shè)計和實現(xiàn)(一) 2009-09-22 |
上海易谷與Genesys達(dá)成大中華區(qū)長期合作伙伴關(guān)系 2009-04-17 |
聯(lián)絡(luò)中心與3G應(yīng)用 2009-04-09 |