曹月恬++詹舒波



摘要:本文介紹了計算機輔助電話訪問調查系統的定義和當前發展狀況,為了實現使用和開發過程中具體業務處理與傳統web后臺系統的解耦分離,同時又達到業務流程的高可控自動化管理和業務的快速易擴展性,本文提出了一種基于工作流系統的,松耦合高可擴展的全新架構和實現。本文介紹了該系統的總體設計與實現,舉例詳述了整個系統中的消息流轉和協議的具體定義與實現。
關鍵詞:計算機輔助電話調查系統;工作流;流程管理;web應用
中圖分類號:TP311
文獻標識碼:A
DOI: 10.3969/j.issn.1003-6970.2016.02.011
引言
由于互聯網的高速發展,web應用已經成了了當今社會的重要組成部分。由于web應用具有瘦客戶,跨平臺,簡單易用,維護成本低等顯著優勢,越來越多的管理系統如:社交,電商,呼叫中心等都急需自己可定制的web接入平臺。本文目標就是實現一個高內聚低耦合,高可訂制的呼叫中心電話調查系統(CATI)的web平臺。
目前市場上的眾多后臺web系統中,一個共同的缺點就是業務與流程強關聯,這樣由于業務地不斷修改,后臺系統需要不斷重寫,從而浪費了人力物力。
本應用中使用了工作流技術,充分利用了工作流作為企業辦公中的通用模塊,減少了系統中重復模塊的開發,讓系統各個模塊之間的耦合度大大降低。
1 服務器系統介紹
1.1 計算機輔助電話調查系統簡介
計算機輔助電話調查系統(Computer AssistedTelephone Interviewing System),簡稱CATI系統,是在傳統訪問調查的基礎上加入了電腦操作進行輔助作業的系統。相比傳統問卷來講,CATI系統由計算機輔助控制訪問流程,大大降低了錯誤率。同時對于呼叫中心坐席人員來說,工作強度大大減小,工作要求也大大降低。與傳統的上門拜訪或者街頭調查相比,CATI問卷調查有著低成本,速度快,效率高,質量優等特點,因此,在互聯網高速技術飛速發展的今天,CATI形式的調查問卷系統是必然也是必要的存在。
1.2 工作流系統簡介
WfMC(工作流管理聯盟Workflow ManagementCoalition)給予工作流的定義如下:工作流是一類能夠完全或者部分自動化執行的經營過程,它根據一系列過程規則,文檔,信息或任務能夠在不同的執行者之間進行傳遞與執行。工作流的思想源自于T業自動化的流水線,隨著信息技術的發展和普及,該思想被企業信息系統所采用。在企業的經營過程中,根據企業內部的規章制度和具體的業務流程,一項事務往往會由多個業務部門按照一定順序串行或并行合作執行來完成企業的經營目標。
2 服務器系統設計
2.1 現有系統不足之處
傳統的許多web架構不足之處采用的往往是瀏覽器向服務器發送請求,后臺系統作為一個整體模塊將請求處理完之后向前臺提供頁面下載。后臺模塊雜糅了所有的功能,包括數據庫處理,業務處理,消息交互,第三方調用,webservice調用等等。當系統需要定制新的業務時,這樣的后臺系統往往擴展非常牽一發而動全身,導致程序的擴展非常困難,程序員對這樣的程序維護困難也很大。
2.2 設計目標
在滿足計算機輔助電話調查系統的業務需求如預約,統計等功能的基礎上,本系統的主要設計目標便是設計一個簡單靈活易用,易擴展,穩定,松耦合的系統,而這一切的關鍵在于需要一個好的系統架構。工作流作為一個高度自動化的模塊,在被系統中用來作為業務邏輯的自動處理單元。同時,在調研了大量現有成型商用web程序之后,系統采用了SSH+Json+工作流的架構模式,整個系統各個模塊涉及的功能非常清晰明了,易于維護。同時各模塊之間定義了詳細易用的消息協議,以達到相互交互的目的。
2.3 架構設計
系統大致可分為四個層次,分別為以js為主體的前端,后臺管理系統,工作流系統,數據存儲系統四部分組成。
視圖層可以是多方面的前端實現,位于離用戶最近的一層。基本以由瀏覽器為用戶展示頁面的方式,顯示數據和接收用戶輸入的數據,完成Web系統與用戶的交互功能。前端部分主要由JavaScript結合少量HTML來完成頁面渲染的功能,具體職責包括:1.生成Web頁面的框架;2.生成具體的頁面中的所有元素,并包含元素的數據綁定、元素間的邏輯關聯和JavaScript事件,完成與后臺的交互任務。頁面渲染器使用JavaScript的ExUS框架編寫,通過AJAX技術與后臺管理模塊交互,數據格式使用JSON(JavaScript Object Notation),一種輕量級數據交換格式,具有數據格式比較簡單、易于讀寫、格式清晰、占用帶寬小等優點。
后臺管理模塊是本系統實現的重點,作為系統的主要控制部分,專門負責處理用戶從頁面提交的請求,將請求進行分發,或是訪問數據層服務,或是調用邏輯服務,或是向工作流網關發起工作流任務。本系統才用JavaEE中最普遍使用的后臺框架Spring+Struts+Hibemate+Axis,其中Struts主要提供對視圖層的接口,Hibemate作為ORM框架,Axis提供一種對webService的輕量而又穩定的支持。Spring作為總的協調者和控制者,將各部分松耦合在一起,構建了各部分需要的實例容器,同時提供了諸如對面向切面編程框架,業務中涉及的事務控制等的強大支持。
工作流系統分為工作流網關,工作流引擎,工作流業務模塊(如即時消息)。工作流網關作為工作流系統與外界的門戶,主要起消息的轉換作用,即將消息從HTTP格式轉為工作流總線上的Message形式。工作流引擎根據既定的業務文件定義的流程建立相應的自動機進行跳轉和分發,將消息處理之后傳遞給工作流總線上別的業務模塊,各個業務模塊再根據預先定制的業務需求進行相應處理。
數據存儲系統主要包含呼叫中心底層平臺和多個Mysql數據庫。各個數據庫可能負責各個不同模塊的數據,也可能和系統中的數個模塊進行交互。呼叫中心底層平臺作為已經成熟運行多年的模塊,以webservice服務的形式提供呼叫系統管理服務。凡是呼叫相關的數據和消息必須在此注冊。同時,呼叫中心底層也維護一個同數據庫作為本系統主數據庫的一個副本。
系統的基本架構圖如下所示:
如圖,該系統在傳統web架構基礎之上,加入了工作流網關和工作流引擎,構建了一個高可用性的web服務器。上圖中紅色的模塊是本系統需要實現的主要模塊,流程大致如下:
1、根據系統需求對需要的配置項進行配置,通過解析配置文件獲取初始化參數,并通過spring的ContextLoaderListener調用spring的相關類,進行服務器的初始化并啟動。
2、前端可能由多部分組成,但基本都以表單形式提交頁面。后臺處理模塊由struts攔截請求,轉發給該請求相對應的Action。每個Action繼承統一的BaseAction,有統一的行為,接收到相應的表單參數后進行校驗和數據預處理。
3、由spring統一進行后臺處理邏輯。由hibemate模塊進行數據庫的基本操作,并通過HTTP協議與工作流網關交互,根據預先定義的http內容作為協議。
4、工作流網關作為一個消息隊列掛載在消息總線上,通過消息第三方總線RabbitMQ與工作流引擎進行通信。工作流引擎根據收到的消息類型進行相應的業務處理,如處理數據庫,通知即時消息模塊等。
5、即時消息模塊或是其他業務模塊接收工作流引擎指示后進行相應處理,并統一將任務成功與否的消息回復給工作流網關
6、工作流網關向web后臺邏輯返回http消息,web后臺將消息處理之后轉換成Json形式返回給前臺js模塊,通過前臺模塊渲染成友好界面之后展示給用戶。
3 服務器系統實現
該服務器系統的后臺邏輯模塊選用struts+hibernate+spring+axis的經典java web框架實現,工作流網關是建立在netty服務器基礎上的一個輕量級HTTP服務器。下面分布介紹其具體實現。
3.1 工作流網關具體實現
工作流網關的啟動流程邏輯和主要類定義如下:
1.訂制配置文件,根據實際需求修改配置參數,如端口號等。
2.從配置文件中得到初始化參數,根據netty官方api所示,利用一個BootStrap類調用SeverFactory進行服務器的初始化并啟動。
3.初始化整個channel,在pipeline中綁定繼承自ChannelInboundHandler的ReadHandler類,在其中的channeIRead方法中實現了工作流網關的基本邏輯,即將http請求的各部分內容取出并進行解析,轉化成RabbitMQ總線上以Json形式呈現的消息類型,并發往工作流引擎所在的消息隊列。
3.2 消息定義
工作流系統內部各模塊之間通過RabbitMQ消息總線連接,互傳json形式的消息。而后臺邏輯系統跟丁作流系統之間主要是借助與丁作流網關,使用http的形式進行交互。工作流網關作為工作流系統對外的統一接口,是由netty服務器實現的輕量級服務器,實現消息流從網絡協議到總線json消息的轉換。下面以計算機輔助訪問電話系統中經典功能預約為例,展示消息的定義模式及時序圖。
l、申請建立連接并預約
時序圖如下:
消息:hi(申請預約)
1.傳輸協議:Http的POST消息
2.傳輸方向:邏輯層→工作流
3.回應消息:Http的200 0K消息,無消息體(不附帶任何業務數據)
消息:here(回應)
1.傳輸協議:Http的POST消息
2.傳輸方向:工作流→邏輯層
3.回應消息:Http的200 0K消息,無消息體(不附帶任何業務數據)
2、修改預約
時序圖如下:
1.傳輸協議:Http的POST消息
2.傳輸方向:邏輯層→工作流
3.回應消息:Http的200 0K消息,無消息體(不附帶任何業務數據)
3、撤銷預約
時序圖如下:
消息:done(申請撤銷)
1.傳輸協議:Http的POST消息
2.傳輸方向:邏輯層→工作流
3.回應消息:Http的200 0K消息,無消息體(不附帶任何業務數據)
3.3 后臺邏輯中與工作流網關的通信實現
主要使用HttpUtil作為工具類,主要實現了http的客戶端功能,能非常輕量級地發送http消息。主要包含
buildHttpContent和doHttpPost兩個方法。
其中buildHttpContent主要將參數封裝成發往工作流網關所定義的消息體格式,doHttpPost方法負責發送消息。
程序邏輯如下:
1、通過buildHttpContent方法構造消息體
2、建立HttpURLConnecttion,設置連接參數,如設置請求方法為post,設置超時時間等等。
3、連接成功后,獲取消息流管道。
4、獲取響應碼,看是不是200,如果是,獲取響應消息的消息體。若不是則拋出異常。
3.4 后臺邏輯中與工作流相關的接口實現
后臺處理程序按照標準SSH規范編寫,接口定義統一在XXService中,實現邏輯一般都在是XXServicehnp1中。當需要具體增加業務功能時,程序要需要先定義接口,并在相應方法中實現自己的業務邏輯?,F以預約功能AppointService為例,該接口提供三個方法:
save(Appointlnfo appointlnfo);
update(Appointlnfo appointlnfo);
delete(String streamNumber, Integer sessionNumber)
程序中已經預先實現了工具類HttpUtil,它可以作為客戶端往工作流網關發送消息。其中以delete方法為例,代碼邏輯為先按照消息定義把參數裝配好,利用工具類HttpUtil的buildHttpContent方法封裝成Http消息,然后調用HttpUtil的doHttpPost方法向指定工作流網關URL發送消息。具體代碼如下:
public Appointlnfo delete( String streamNumber.Integer sessionNumber){
dest=workflowDestPrefix+”.”+appointlnfo.getAppointNumber();
params=new HashMap();
params.put(“act”,httpActOfDelete);
params.put(“appoint_no”,appointlnfo.getAppointNumber()):
content=HttpUtil.buildHttpContent(”done”,””,dest,params);
try{
HttpUtil.doHttpPost(workflowUrl,content);
}catch( Exception e){
e.printStackTrace();
throw new RoIIBackException( RtvErrorDef.WorkflowError):
}
retun appointlnfo;
}
4 結論
本文簡單地介紹了計算機輔助電話調查系統的定義和發展背景,并給出了該系統的一種全新的設計與實現,即基于工作流系統的,松耦合的,高可用的系統實現。該設計充分利用了工作流靈活的自動化和快速重組特性,利用丁作流達到了具體事務處理與流程管理的分離。在傳統SSH構造的web后臺應用的基礎上,使得業務邏輯可以高效的擴展和高可控的流程化,既簡化了系統的開發工作量,又免去了坐席很多重復丁作,使得業務的新增和使用顯得簡潔易操作,大大提高了整個系統的效率。