曹月恬++詹舒波

摘要：本文介紹了計(jì)算機(jī)輔助電話(huà)訪問(wèn)調(diào)查系統(tǒng)的定義和當(dāng)前發(fā)展?fàn)顩r，為了實(shí)現(xiàn)使用和開(kāi)發(fā)過(guò)程中具體業(yè)務(wù)處理與傳統(tǒng)web后臺(tái)系統(tǒng)的解耦分離，同時(shí)又達(dá)到業(yè)務(wù)流程的高可控自動(dòng)化管理和業(yè)務(wù)的快速易擴(kuò)展性，本文提出了一種基于工作流系統(tǒng)的，松耦合高可擴(kuò)展的全新架構(gòu)和實(shí)現(xiàn)。本文介紹了該系統(tǒng)的總體設(shè)計(jì)與實(shí)現(xiàn)，舉例詳述了整個(gè)系統(tǒng)中的消息流轉(zhuǎn)和協(xié)議的具體定義與實(shí)現(xiàn)。

關(guān)鍵詞：計(jì)算機(jī)輔助電話(huà)調(diào)查系統(tǒng)；工作流；流程管理；web應(yīng)用

中圖分類(lèi)號(hào)：TP311

文獻(xiàn)標(biāo)識(shí)碼：A

DOI： 10.3969/j.issn.1003-6970.2016.02.011

引言

由于互聯(lián)網(wǎng)的高速發(fā)展，web應(yīng)用已經(jīng)成了了當(dāng)今社會(huì)的重要組成部分。由于web應(yīng)用具有瘦客戶(hù)，跨平臺(tái)，簡(jiǎn)單易用，維護(hù)成本低等顯著優(yōu)勢(shì)，越來(lái)越多的管理系統(tǒng)如：社交，電商，呼叫中心等都急需自己可定制的web接入平臺(tái)。本文目標(biāo)就是實(shí)現(xiàn)一個(gè)高內(nèi)聚低耦合，高可訂制的呼叫中心電話(huà)調(diào)查系統(tǒng)（CATI）的web平臺(tái)。

目前市場(chǎng)上的眾多后臺(tái)web系統(tǒng)中，一個(gè)共同的缺點(diǎn)就是業(yè)務(wù)與流程強(qiáng)關(guān)聯(lián)，這樣由于業(yè)務(wù)地不斷修改，后臺(tái)系統(tǒng)需要不斷重寫(xiě)，從而浪費(fèi)了人力物力。

本應(yīng)用中使用了工作流技術(shù)，充分利用了工作流作為企業(yè)辦公中的通用模塊，減少了系統(tǒng)中重復(fù)模塊的開(kāi)發(fā)，讓系統(tǒng)各個(gè)模塊之間的耦合度大大降低。

1 服務(wù)器系統(tǒng)介紹

1.1 計(jì)算機(jī)輔助電話(huà)調(diào)查系統(tǒng)簡(jiǎn)介

計(jì)算機(jī)輔助電話(huà)調(diào)查系統(tǒng)（Computer AssistedTelephone Interviewing System），簡(jiǎn)稱(chēng)CATI系統(tǒng)，是在傳統(tǒng)訪問(wèn)調(diào)查的基礎(chǔ)上加入了電腦操作進(jìn)行輔助作業(yè)的系統(tǒng)。相比傳統(tǒng)問(wèn)卷來(lái)講，CATI系統(tǒng)由計(jì)算機(jī)輔助控制訪問(wèn)流程，大大降低了錯(cuò)誤率。同時(shí)對(duì)于呼叫中心坐席人員來(lái)說(shuō)，工作強(qiáng)度大大減小，工作要求也大大降低。與傳統(tǒng)的上門(mén)拜訪或者街頭調(diào)查相比，CATI問(wèn)卷調(diào)查有著低成本，速度快，效率高，質(zhì)量?jī)?yōu)等特點(diǎn)，因此，在互聯(lián)網(wǎng)高速技術(shù)飛速發(fā)展的今天，CATI形式的調(diào)查問(wèn)卷系統(tǒng)是必然也是必要的存在。

1.2 工作流系統(tǒng)簡(jiǎn)介

WfMC（工作流管理聯(lián)盟Workflow ManagementCoalition）給予工作流的定義如下：工作流是一類(lèi)能夠完全或者部分自動(dòng)化執(zhí)行的經(jīng)營(yíng)過(guò)程，它根據(jù)一系列過(guò)程規(guī)則，文檔，信息或任務(wù)能夠在不同的執(zhí)行者之間進(jìn)行傳遞與執(zhí)行。工作流的思想源自于T業(yè)自動(dòng)化的流水線(xiàn)，隨著信息技術(shù)的發(fā)展和普及，該思想被企業(yè)信息系統(tǒng)所采用。在企業(yè)的經(jīng)營(yíng)過(guò)程中，根據(jù)企業(yè)內(nèi)部的規(guī)章制度和具體的業(yè)務(wù)流程，一項(xiàng)事務(wù)往往會(huì)由多個(gè)業(yè)務(wù)部門(mén)按照一定順序串行或并行合作執(zhí)行來(lái)完成企業(yè)的經(jīng)營(yíng)目標(biāo)。

2 服務(wù)器系統(tǒng)設(shè)計(jì)

2.1 現(xiàn)有系統(tǒng)不足之處

傳統(tǒng)的許多web架構(gòu)不足之處采用的往往是瀏覽器向服務(wù)器發(fā)送請(qǐng)求，后臺(tái)系統(tǒng)作為一個(gè)整體模塊將請(qǐng)求處理完之后向前臺(tái)提供頁(yè)面下載。后臺(tái)模塊雜糅了所有的功能，包括數(shù)據(jù)庫(kù)處理，業(yè)務(wù)處理，消息交互，第三方調(diào)用，webservice調(diào)用等等。當(dāng)系統(tǒng)需要定制新的業(yè)務(wù)時(shí)，這樣的后臺(tái)系統(tǒng)往往擴(kuò)展非常牽一發(fā)而動(dòng)全身，導(dǎo)致程序的擴(kuò)展非常困難，程序員對(duì)這樣的程序維護(hù)困難也很大。

2.2 設(shè)計(jì)目標(biāo)

在滿(mǎn)足計(jì)算機(jī)輔助電話(huà)調(diào)查系統(tǒng)的業(yè)務(wù)需求如預(yù)約，統(tǒng)計(jì)等功能的基礎(chǔ)上，本系統(tǒng)的主要設(shè)計(jì)目標(biāo)便是設(shè)計(jì)一個(gè)簡(jiǎn)單靈活易用，易擴(kuò)展，穩(wěn)定，松耦合的系統(tǒng)，而這一切的關(guān)鍵在于需要一個(gè)好的系統(tǒng)架構(gòu)。工作流作為一個(gè)高度自動(dòng)化的模塊，在被系統(tǒng)中用來(lái)作為業(yè)務(wù)邏輯的自動(dòng)處理單元。同時(shí)，在調(diào)研了大量現(xiàn)有成型商用web程序之后，系統(tǒng)采用了SSH+Json+工作流的架構(gòu)模式，整個(gè)系統(tǒng)各個(gè)模塊涉及的功能非常清晰明了，易于維護(hù)。同時(shí)各模塊之間定義了詳細(xì)易用的消息協(xié)議，以達(dá)到相互交互的目的。

2.3 架構(gòu)設(shè)計(jì)

系統(tǒng)大致可分為四個(gè)層次，分別為以js為主體的前端，后臺(tái)管理系統(tǒng)，工作流系統(tǒng)，數(shù)據(jù)存儲(chǔ)系統(tǒng)四部分組成。

視圖層可以是多方面的前端實(shí)現(xiàn)，位于離用戶(hù)最近的一層?；疽杂蔀g覽器為用戶(hù)展示頁(yè)面的方式，顯示數(shù)據(jù)和接收用戶(hù)輸入的數(shù)據(jù)，完成Web系統(tǒng)與用戶(hù)的交互功能。前端部分主要由JavaScript結(jié)合少量HTML來(lái)完成頁(yè)面渲染的功能，具體職責(zé)包括：1.生成Web頁(yè)面的框架；2.生成具體的頁(yè)面中的所有元素，并包含元素的數(shù)據(jù)綁定、元素間的邏輯關(guān)聯(lián)和JavaScript事件，完成與后臺(tái)的交互任務(wù)。頁(yè)面渲染器使用JavaScript的ExUS框架編寫(xiě)，通過(guò)AJAX技術(shù)與后臺(tái)管理模塊交互，數(shù)據(jù)格式使用JSON（JavaScript Object Notation），一種輕量級(jí)數(shù)據(jù)交換格式，具有數(shù)據(jù)格式比較簡(jiǎn)單、易于讀寫(xiě)、格式清晰、占用帶寬小等優(yōu)點(diǎn)。

后臺(tái)管理模塊是本系統(tǒng)實(shí)現(xiàn)的重點(diǎn)，作為系統(tǒng)的主要控制部分，專(zhuān)門(mén)負(fù)責(zé)處理用戶(hù)從頁(yè)面提交的請(qǐng)求，將請(qǐng)求進(jìn)行分發(fā)，或是訪問(wèn)數(shù)據(jù)層服務(wù)，或是調(diào)用邏輯服務(wù)，或是向工作流網(wǎng)關(guān)發(fā)起工作流任務(wù)。本系統(tǒng)才用JavaEE中最普遍使用的后臺(tái)框架Spring+Struts+Hibemate+Axis，其中Struts主要提供對(duì)視圖層的接口，Hibemate作為ORM框架，Axis提供一種對(duì)webService的輕量而又穩(wěn)定的支持。Spring作為總的協(xié)調(diào)者和控制者，將各部分松耦合在一起，構(gòu)建了各部分需要的實(shí)例容器，同時(shí)提供了諸如對(duì)面向切面編程框架，業(yè)務(wù)中涉及的事務(wù)控制等的強(qiáng)大支持。

工作流系統(tǒng)分為工作流網(wǎng)關(guān)，工作流引擎，工作流業(yè)務(wù)模塊（如即時(shí)消息）。工作流網(wǎng)關(guān)作為工作流系統(tǒng)與外界的門(mén)戶(hù)，主要起消息的轉(zhuǎn)換作用，即將消息從HTTP格式轉(zhuǎn)為工作流總線(xiàn)上的Message形式。工作流引擎根據(jù)既定的業(yè)務(wù)文件定義的流程建立相應(yīng)的自動(dòng)機(jī)進(jìn)行跳轉(zhuǎn)和分發(fā)，將消息處理之后傳遞給工作流總線(xiàn)上別的業(yè)務(wù)模塊，各個(gè)業(yè)務(wù)模塊再根據(jù)預(yù)先定制的業(yè)務(wù)需求進(jìn)行相應(yīng)處理。

數(shù)據(jù)存儲(chǔ)系統(tǒng)主要包含呼叫中心底層平臺(tái)和多個(gè)Mysql數(shù)據(jù)庫(kù)。各個(gè)數(shù)據(jù)庫(kù)可能負(fù)責(zé)各個(gè)不同模塊的數(shù)據(jù)，也可能和系統(tǒng)中的數(shù)個(gè)模塊進(jìn)行交互。呼叫中心底層平臺(tái)作為已經(jīng)成熟運(yùn)行多年的模塊，以webservice服務(wù)的形式提供呼叫系統(tǒng)管理服務(wù)。凡是呼叫相關(guān)的數(shù)據(jù)和消息必須在此注冊(cè)。同時(shí)，呼叫中心底層也維護(hù)一個(gè)同數(shù)據(jù)庫(kù)作為本系統(tǒng)主數(shù)據(jù)庫(kù)的一個(gè)副本。

系統(tǒng)的基本架構(gòu)圖如下所示：

如圖，該系統(tǒng)在傳統(tǒng)web架構(gòu)基礎(chǔ)之上，加入了工作流網(wǎng)關(guān)和工作流引擎，構(gòu)建了一個(gè)高可用性的web服務(wù)器。上圖中紅色的模塊是本系統(tǒng)需要實(shí)現(xiàn)的主要模塊，流程大致如下：

1、根據(jù)系統(tǒng)需求對(duì)需要的配置項(xiàng)進(jìn)行配置，通過(guò)解析配置文件獲取初始化參數(shù)，并通過(guò)spring的ContextLoaderListener調(diào)用spring的相關(guān)類(lèi)，進(jìn)行服務(wù)器的初始化并啟動(dòng)。

2、前端可能由多部分組成，但基本都以表單形式提交頁(yè)面。后臺(tái)處理模塊由struts攔截請(qǐng)求，轉(zhuǎn)發(fā)給該請(qǐng)求相對(duì)應(yīng)的Action。每個(gè)Action繼承統(tǒng)一的BaseAction，有統(tǒng)一的行為，接收到相應(yīng)的表單參數(shù)后進(jìn)行校驗(yàn)和數(shù)據(jù)預(yù)處理。

3、由spring統(tǒng)一進(jìn)行后臺(tái)處理邏輯。由hibemate模塊進(jìn)行數(shù)據(jù)庫(kù)的基本操作，并通過(guò)HTTP協(xié)議與工作流網(wǎng)關(guān)交互，根據(jù)預(yù)先定義的http內(nèi)容作為協(xié)議。

4、工作流網(wǎng)關(guān)作為一個(gè)消息隊(duì)列掛載在消息總線(xiàn)上，通過(guò)消息第三方總線(xiàn)RabbitMQ與工作流引擎進(jìn)行通信。工作流引擎根據(jù)收到的消息類(lèi)型進(jìn)行相應(yīng)的業(yè)務(wù)處理，如處理數(shù)據(jù)庫(kù)，通知即時(shí)消息模塊等。

5、即時(shí)消息模塊或是其他業(yè)務(wù)模塊接收工作流引擎指示后進(jìn)行相應(yīng)處理，并統(tǒng)一將任務(wù)成功與否的消息回復(fù)給工作流網(wǎng)關(guān)

6、工作流網(wǎng)關(guān)向web后臺(tái)邏輯返回http消息，web后臺(tái)將消息處理之后轉(zhuǎn)換成Json形式返回給前臺(tái)js模塊，通過(guò)前臺(tái)模塊渲染成友好界面之后展示給用戶(hù)。

3 服務(wù)器系統(tǒng)實(shí)現(xiàn)

該服務(wù)器系統(tǒng)的后臺(tái)邏輯模塊選用struts+hibernate+spring+axis的經(jīng)典java web框架實(shí)現(xiàn)，工作流網(wǎng)關(guān)是建立在netty服務(wù)器基礎(chǔ)上的一個(gè)輕量級(jí)HTTP服務(wù)器。下面分布介紹其具體實(shí)現(xiàn)。

3.1 工作流網(wǎng)關(guān)具體實(shí)現(xiàn)

工作流網(wǎng)關(guān)的啟動(dòng)流程邏輯和主要類(lèi)定義如下：

1.訂制配置文件，根據(jù)實(shí)際需求修改配置參數(shù)，如端口號(hào)等。

2.從配置文件中得到初始化參數(shù)，根據(jù)netty官方api所示，利用一個(gè)BootStrap類(lèi)調(diào)用SeverFactory進(jìn)行服務(wù)器的初始化并啟動(dòng)。

3.初始化整個(gè)channel，在pipeline中綁定繼承自ChannelInboundHandler的ReadHandler類(lèi)，在其中的channeIRead方法中實(shí)現(xiàn)了工作流網(wǎng)關(guān)的基本邏輯，即將http請(qǐng)求的各部分內(nèi)容取出并進(jìn)行解析，轉(zhuǎn)化成RabbitMQ總線(xiàn)上以Json形式呈現(xiàn)的消息類(lèi)型，并發(fā)往工作流引擎所在的消息隊(duì)列。

3.2 消息定義

工作流系統(tǒng)內(nèi)部各模塊之間通過(guò)RabbitMQ消息總線(xiàn)連接，互傳json形式的消息。而后臺(tái)邏輯系統(tǒng)跟丁作流系統(tǒng)之間主要是借助與丁作流網(wǎng)關(guān)，使用http的形式進(jìn)行交互。工作流網(wǎng)關(guān)作為工作流系統(tǒng)對(duì)外的統(tǒng)一接口，是由netty服務(wù)器實(shí)現(xiàn)的輕量級(jí)服務(wù)器，實(shí)現(xiàn)消息流從網(wǎng)絡(luò)協(xié)議到總線(xiàn)json消息的轉(zhuǎn)換。下面以計(jì)算機(jī)輔助訪問(wèn)電話(huà)系統(tǒng)中經(jīng)典功能預(yù)約為例，展示消息的定義模式及時(shí)序圖。

l、申請(qǐng)建立連接并預(yù)約

時(shí)序圖如下：

消息：hi（申請(qǐng)預(yù)約）

1.傳輸協(xié)議：Http的POST消息

2.傳輸方向：邏輯層→工作流

3.回應(yīng)消息：Http的200 0K消息，無(wú)消息體（不附帶任何業(yè)務(wù)數(shù)據(jù)）

消息：here（回應(yīng)）

1.傳輸協(xié)議：Http的POST消息

2.傳輸方向：工作流→邏輯層

3.回應(yīng)消息：Http的200 0K消息，無(wú)消息體（不附帶任何業(yè)務(wù)數(shù)據(jù)）

2、修改預(yù)約

時(shí)序圖如下：

1.傳輸協(xié)議：Http的POST消息

2.傳輸方向：邏輯層→工作流

3.回應(yīng)消息：Http的200 0K消息，無(wú)消息體（不附帶任何業(yè)務(wù)數(shù)據(jù)）

3、撤銷(xiāo)預(yù)約

時(shí)序圖如下：

消息：done（申請(qǐng)撤銷(xiāo)）

1.傳輸協(xié)議：Http的POST消息

2.傳輸方向：邏輯層→工作流

3.回應(yīng)消息：Http的200 0K消息，無(wú)消息體（不附帶任何業(yè)務(wù)數(shù)據(jù)）

3.3 后臺(tái)邏輯中與工作流網(wǎng)關(guān)的通信實(shí)現(xiàn)

主要使用HttpUtil作為工具類(lèi)，主要實(shí)現(xiàn)了http的客戶(hù)端功能，能非常輕量級(jí)地發(fā)送http消息。主要包含

buildHttpContent和doHttpPost兩個(gè)方法。

其中buildHttpContent主要將參數(shù)封裝成發(fā)往工作流網(wǎng)關(guān)所定義的消息體格式，doHttpPost方法負(fù)責(zé)發(fā)送消息。

程序邏輯如下：

1、通過(guò)buildHttpContent方法構(gòu)造消息體

2、建立HttpURLConnecttion，設(shè)置連接參數(shù)，如設(shè)置請(qǐng)求方法為post，設(shè)置超時(shí)時(shí)間等等。

3、連接成功后，獲取消息流管道。

4、獲取響應(yīng)碼，看是不是200，如果是，獲取響應(yīng)消息的消息體。若不是則拋出異常。

3.4 后臺(tái)邏輯中與工作流相關(guān)的接口實(shí)現(xiàn)

后臺(tái)處理程序按照標(biāo)準(zhǔn)SSH規(guī)范編寫(xiě)，接口定義統(tǒng)一在XXService中，實(shí)現(xiàn)邏輯一般都在是XXServicehnp1中。當(dāng)需要具體增加業(yè)務(wù)功能時(shí)，程序要需要先定義接口，并在相應(yīng)方法中實(shí)現(xiàn)自己的業(yè)務(wù)邏輯。現(xiàn)以預(yù)約功能AppointService為例，該接口提供三個(gè)方法：

save（Appointlnfo appointlnfo）；

update（Appointlnfo appointlnfo）；

delete（String streamNumber， Integer sessionNumber）

程序中已經(jīng)預(yù)先實(shí)現(xiàn)了工具類(lèi)HttpUtil，它可以作為客戶(hù)端往工作流網(wǎng)關(guān)發(fā)送消息。其中以delete方法為例，代碼邏輯為先按照消息定義把參數(shù)裝配好，利用工具類(lèi)HttpUtil的buildHttpContent方法封裝成Http消息，然后調(diào)用HttpUtil的doHttpPost方法向指定工作流網(wǎng)關(guān)URL發(fā)送消息。具體代碼如下：

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 結(jié)論

本文簡(jiǎn)單地介紹了計(jì)算機(jī)輔助電話(huà)調(diào)查系統(tǒng)的定義和發(fā)展背景，并給出了該系統(tǒng)的一種全新的設(shè)計(jì)與實(shí)現(xiàn)，即基于工作流系統(tǒng)的，松耦合的，高可用的系統(tǒng)實(shí)現(xiàn)。該設(shè)計(jì)充分利用了工作流靈活的自動(dòng)化和快速重組特性，利用丁作流達(dá)到了具體事務(wù)處理與流程管理的分離。在傳統(tǒng)SSH構(gòu)造的web后臺(tái)應(yīng)用的基礎(chǔ)上，使得業(yè)務(wù)邏輯可以高效的擴(kuò)展和高可控的流程化，既簡(jiǎn)化了系統(tǒng)的開(kāi)發(fā)工作量，又免去了坐席很多重復(fù)丁作，使得業(yè)務(wù)的新增和使用顯得簡(jiǎn)潔易操作，大大提高了整個(gè)系統(tǒng)的效率。