羅琴華 馬 櫟(中國郵政集團(tuán)公司江西省分公司數(shù)據(jù)中心 江西 南昌 33005)(江西工業(yè)職業(yè)技術(shù)學(xué)院機(jī)電工程分院 江西 南昌 33009)

0 引 言

各家銀行開辦了代理委托方收費的中間業(yè)務(wù)，通過自建中間業(yè)務(wù)平臺來代理委托方收付費。由于委托方眾多，中間業(yè)務(wù)具有業(yè)務(wù)種類繁多、處理方式各異、接口復(fù)雜多變、交易流程各不相同等特點。大多銀行采用結(jié)構(gòu)化開發(fā)方法開發(fā)中間業(yè)務(wù)平臺軟件,不利于軟件重用，存在開發(fā)周期長、進(jìn)度和成本難以控制等問題[5]。

1 研究目的

本文以江西省郵儲銀行中間業(yè)務(wù)平臺建設(shè)為背景開展研究。平臺要實現(xiàn)電信、移動、聯(lián)通等通信運營商代收費，水電煤等公共事業(yè)費，以及有線電視費、汽車票、稅款等各類代收費，業(yè)務(wù)種類近二十種，委托方涉及三十多家。若采用結(jié)構(gòu)化開發(fā)方法，完成一家委托方業(yè)務(wù)的開發(fā)及上線至少需要1個半月，那么三十多家委托方業(yè)務(wù)全部完成則需要兩年多時間。

如何最大化的兼容各類中間業(yè)務(wù)，無需軟件開發(fā)或少量開發(fā)即可新增一項中間業(yè)務(wù)，這是迫切需要解決的問題。本文提出基于組件的軟件開發(fā)方法[5]來建設(shè)郵儲銀行中間業(yè)務(wù)平臺。將中間業(yè)務(wù)交易處理流程各環(huán)節(jié)拆分成一個個組件，通過接口、組件配置實現(xiàn)不同業(yè)務(wù)的個性定義。然后平臺采用流程驅(qū)動引擎從流程配置中依次讀取業(yè)務(wù)交易流程的各個環(huán)節(jié)，從而完成一個完整交易處理。

2 中間業(yè)務(wù)平臺軟件設(shè)計方法

中間業(yè)務(wù)的多樣性造就了各業(yè)務(wù)處理流程和處理內(nèi)容的多變性[8]。針對各業(yè)務(wù)處理流程的多變性進(jìn)行分析，可將業(yè)務(wù)處理流程拆分為一個個執(zhí)行環(huán)節(jié)，分別對應(yīng)各個組件。針對各業(yè)務(wù)處理內(nèi)容的多變性進(jìn)行分析，抽象出共性與個性化特性，將共性封裝入組件，個性通過接口、組件配置實現(xiàn)個性化處理。各個組件之間的數(shù)據(jù)傳輸則采用接口、數(shù)據(jù)總線等方式傳輸，從而支持通過流程配置實現(xiàn)對業(yè)務(wù)組件的即插即用。

2.1 中間業(yè)務(wù)分析

中間業(yè)務(wù)根據(jù)處理方式可分為信息管理類、現(xiàn)金代收類、卡折代收類、批量代發(fā)類、批量代扣類、聯(lián)機(jī)代收類、脫機(jī)代收類等。根據(jù)委托方可分為電信、移動、聯(lián)通、電力、水業(yè)、煤氣、汽運等代收費，根據(jù)接入渠道可分為網(wǎng)點、網(wǎng)上銀行、便民服務(wù)站等渠道繳費。通過對各類業(yè)務(wù)分析，可從以下五個視角描述中間業(yè)務(wù)：

? 交易發(fā)起方：分網(wǎng)點終端發(fā)起、網(wǎng)銀等各類渠道發(fā)起、委托方發(fā)起、中間業(yè)務(wù)后臺發(fā)起等。

? 交易時與委托方的連接：實時、非實時。

? 客戶辦理方式：現(xiàn)金、賬戶折/卡。

? 數(shù)據(jù)來源：終端輸入、來自委托方傳入、自有數(shù)據(jù)。

? 交易處理方式：單筆、批量。

通過這五個視角的排列組合，至少排列出31種可能的交易，如終端發(fā)起實時單筆現(xiàn)金交易、委托方發(fā)起實時單筆賬戶交易等，基本可涵蓋中間業(yè)務(wù)的各類交易。因此將五個視角涵蓋的內(nèi)容轉(zhuǎn)化為標(biāo)識代碼，采用業(yè)務(wù)標(biāo)識+交易代碼來唯一標(biāo)識各項中間業(yè)務(wù)交易。業(yè)務(wù)標(biāo)識代表委托方，由區(qū)域代碼+委托方代碼組成，區(qū)域代碼6位，如全省統(tǒng)一業(yè)務(wù)的區(qū)域代碼設(shè)為‘999999’，南昌地區(qū)業(yè)務(wù)的區(qū)域代碼設(shè)為‘360100’等；委托方代碼4位，如電信設(shè)為‘X001’，聯(lián)通設(shè)為‘X002’等。因此‘360100X001’就代表代收南昌電信話費業(yè)務(wù)。交易代碼由10位組成，通過交易代碼每一位含義的定義，涵蓋所有交易種類。命名規(guī)則如下：

1) 第1、2位固定為TR。

2) 第3位表示交易發(fā)起方，‘1’：終端或前置發(fā)起；‘2’：委托方發(fā)起；‘3’：中間業(yè)務(wù)后臺發(fā)起；‘4’：儲蓄主機(jī)發(fā)起。

3) 第4位為渠道接入方式，‘0’：無接入方式；‘1’：終端；‘2’：電話銀行；‘3’：ATM；‘4’：POS；‘5’：自助終端。

4) 第5位為代收付區(qū)分，‘1’：代收；‘2’：代付；‘3’：代理；‘4’：代售；‘5’：國債。

5) 第6、7位為交易種類，‘0x’：查詢類；‘1x’：繳費類；‘2x’：兌付類；‘3x’：打印信息類；‘4x’：操作員管理類；‘5x’：空白憑證管理類；‘6x’：加辦/撤消類；‘8x’：管理通知類；‘9x’：特殊處理類。其中x為順序號，為0～Z的數(shù)字或字母。

6) 第8位表示取消區(qū)分，‘0’：正常；‘1’：取消；‘2’：更正；‘3’：沖正；‘4’：恢復(fù)；‘5’：重發(fā)；‘6’：調(diào)整成功；‘7’：調(diào)整失敗。

7) 第9位表示資金種類，‘0’：無資金種類；‘1’：現(xiàn)金；‘2’：支票；‘3’：存折；‘4’：卡。

8) 第10位：擴(kuò)展。

根據(jù)交易代碼定義，可定義出各類交易，如網(wǎng)點的查詢交易為‘TR11100000’，繳費交易為‘TR11110010’。將業(yè)務(wù)標(biāo)識+交易代碼作為接口參數(shù)傳入組件，從而可在組件中封裝入對不同業(yè)務(wù)、不同種類交易的各自處理，實現(xiàn)組件復(fù)用。

2.2 流程拆分

分析各類交易的處理流程，對流程進(jìn)行拆分。如網(wǎng)點終端發(fā)起的查詢交易(涵蓋代收通信資費、代收水電費等各類中間業(yè)務(wù)的查詢交易)，可將一筆交易拆分成終端數(shù)據(jù)輸入、數(shù)據(jù)檢查、發(fā)往委托方報文、接收委托方報文、數(shù)據(jù)更新、終端輸出等各個執(zhí)行環(huán)節(jié)。而網(wǎng)點終端發(fā)起的繳費交易則比查詢交易要多一個單據(jù)打印的環(huán)節(jié)，以實現(xiàn)發(fā)票打印功能。從委托方發(fā)起的中間業(yè)務(wù)交易(如電信發(fā)起的扣繳話費)，則可拆分成接收委托方報文、數(shù)據(jù)檢查、發(fā)往儲蓄主機(jī)扣款、數(shù)據(jù)更新、發(fā)往委托方報文等執(zhí)行環(huán)節(jié)。

各類交易皆按上述方法拆分，可看到大部分交易都存在一些相同的執(zhí)行環(huán)節(jié)。通過提取共性，將各類交易的相同執(zhí)行環(huán)節(jié)對應(yīng)封裝成一個組件，使得每個執(zhí)行環(huán)節(jié)對應(yīng)一個組件，從而通過對組件的拼裝即可組織出各類交易。

2.3 組件設(shè)計

組件是能完成特定功能并且相對獨立的代碼模塊[8]，具有明確的功能定義和訪問接口。如終端數(shù)據(jù)輸入組件：負(fù)責(zé)處理各類業(yè)務(wù)的數(shù)據(jù)輸入，并將數(shù)據(jù)存儲入數(shù)據(jù)總線等；數(shù)據(jù)檢查組件：檢查各類業(yè)務(wù)輸入數(shù)據(jù)的合法性、有效性等，根據(jù)不同種類交易進(jìn)行相關(guān)數(shù)據(jù)準(zhǔn)備。組件訪問接口如下：通過業(yè)務(wù)標(biāo)識+交易代碼參數(shù)唯一標(biāo)識一項交易，從而在組件中可針對不同的交易做出對應(yīng)的處理。

typedef int (*comfunc_ft)(

//組件訪問接口

char *szBusinessID,

//業(yè)務(wù)標(biāo)識

char *szTransID,

//交易代碼

char *szEnterpriseID,

//企業(yè)碼

char *szSequenceNum

//Com序列號

);

組件設(shè)計需要充分考慮組件獨立性，采用面向?qū)ο蟮乃枷?，做到?shù)據(jù)和操作的緊密結(jié)合。為了減少業(yè)務(wù)數(shù)據(jù)在組件之間的傳遞，提高效率，同時也為了組件流程的可配置化，平臺采用數(shù)據(jù)總線的方式實現(xiàn)業(yè)務(wù)數(shù)據(jù)在各組件之間共享[8]。即組件1從數(shù)據(jù)總線中讀取數(shù)據(jù)，做完相應(yīng)的數(shù)據(jù)處理后再寫回數(shù)據(jù)總線，緊接著組件2也是從數(shù)據(jù)總線中讀取、處理后寫回。下面以數(shù)據(jù)檢查組件為例來闡述組件的設(shè)計方法。

? 組件名稱：TermInCheck。

? 組件描述：終端輸入電文檢查。

? 接口參數(shù)：pBusinessID、pTransID、iSequenceNum。

? 使用范圍：應(yīng)用于終端發(fā)起的單筆交易。

? 使用總線數(shù)據(jù)：

此組件使用了交易局號(tb_tr_midsite)、交易日期(tb_tr_midsys)、網(wǎng)點IP地址、操作員ID、原交易流水號(取消/更正交易)、原交易日期(取消/更正/沖正交易)，結(jié)算局號。

? 功能概述：

1) 用GetStructData 函數(shù)從數(shù)據(jù)總線上讀網(wǎng)點機(jī)構(gòu)tb_tr_midsite數(shù)據(jù)，檢查網(wǎng)點運行狀態(tài)，終端運行標(biāo)志，營業(yè)時間，如設(shè)定了IP地址綁定檢查IP地址。

2) 交易代碼pTransID第6位為‘1’or‘2’or‘6’(即繳費類、兌付類、加辦/撤銷類交易)時，獲取賬務(wù)交易日志ZJRZ總線數(shù)據(jù)，否則(即查詢類等交易)，獲取非賬務(wù)交易日志ZJNRZ總線數(shù)據(jù)。

3) 若業(yè)務(wù)標(biāo)識pBusinessID不為全零(即涉及委托方業(yè)務(wù))，進(jìn)行委托方信息檢查：檢查委托方運行狀態(tài)是否開啟，交易日期是否在范圍內(nèi)等。

4) 交易代碼pTransID第6位為‘1’or‘2’(即繳費類、兌付類交易)時，ZJRZ總線的實繳金額FM0001應(yīng)大于等于應(yīng)繳金額FM0019。

5) 當(dāng)交易代碼pTransID第8位為‘1’or‘2’or‘3’(即取消/沖正/更正類交易)，則進(jìn)行原交易信息檢查，檢查原交易應(yīng)存在且業(yè)務(wù)標(biāo)識、代辦號碼、交易金額等重要信息應(yīng)正確。

從上述組件功能概述可以看出，組件通過傳入的業(yè)務(wù)標(biāo)識、交易代碼等參數(shù)，針對各類交易做出對應(yīng)的處理，實現(xiàn)組件通用。

2.4 組件配置

不同委托方的相同交易，比如都是查詢交易，雖然交易流程相同，但與不同的委托方交互的數(shù)據(jù)內(nèi)容及傳輸格式都各不相同，終端輸入的內(nèi)容、單據(jù)打印的內(nèi)容等也各不相同。這就要求將終端輸入/輸出組件、單據(jù)打印組件、與委托方交互的請求報文、響應(yīng)報文等組件開發(fā)成支持可配置化，支持對數(shù)據(jù)內(nèi)容、與委托方報文格式等業(yè)務(wù)規(guī)則的配置，通過組件配置實現(xiàn)不同委托方業(yè)務(wù)的數(shù)據(jù)定義。

以終端輸入組件為例，支持輸入項、數(shù)據(jù)格式、數(shù)據(jù)源等配置。圖1是代收聯(lián)通話費交易的終端輸入組件的配置內(nèi)容，輸入項有服務(wù)類型、用戶號碼、用戶姓名、往月欠費、預(yù)繳費等。這些數(shù)據(jù)項的長度、顯示形式、存儲在總線中哪個數(shù)據(jù)源，都通過配置確定，這些配置信息按業(yè)務(wù)存儲在數(shù)據(jù)庫中。終端輸入組件程序設(shè)計為根據(jù)業(yè)務(wù)標(biāo)識從數(shù)據(jù)庫中讀取該業(yè)務(wù)的終端輸入配置，根據(jù)配置信息將終端輸入的數(shù)據(jù)內(nèi)容按格式寫入數(shù)據(jù)源定義的數(shù)據(jù)總線DATABUS中。

圖1 代收聯(lián)通話費繳費交易的終端輸入組件配置

3 實例分析與實現(xiàn)

下面展示中間業(yè)務(wù)平臺的具體軟件實現(xiàn)，以代收聯(lián)通話費交易為例。

江西聯(lián)通業(yè)務(wù)標(biāo)識：360000X002，繳費交易代碼：TR11110010。圖2是代收聯(lián)通話費交易的流程配置。由終端輸入電文、總線數(shù)據(jù)更新、輸入電文檢查、委托方請求電文、委托方響應(yīng)電文、終端憑證打印、存儲總線數(shù)據(jù)、組織返回終端電文等組件構(gòu)成，組織出一筆完整交易。將該交易流程中各個組件按順序存儲在數(shù)據(jù)庫中，對終端輸入電文、組織委托方請求電文、解析委托方響應(yīng)電文、組織返回終端電文等組件按聯(lián)通繳費交易的數(shù)據(jù)內(nèi)容進(jìn)行配置，并將配置信息存入數(shù)據(jù)庫。運行時流程引擎從數(shù)據(jù)庫中依次讀出組件，在調(diào)用終端輸入電文等組件時再由組件從數(shù)據(jù)庫讀出組件配置，實現(xiàn)整個業(yè)務(wù)處理。

圖2 代收聯(lián)通話費交易流程配置

程序?qū)崿F(xiàn)如下：

(1) 組件定義：

/*定義組件接口*/

typedef int (*comfunc_ft)(

char *szBusinessID,

//業(yè)務(wù)標(biāo)識

char *szTransID,

//交易代碼

char *szEnterpriseID,

//企業(yè)碼

char *szSequenceNum

//Com序列號

);

/*指針數(shù)組變量初始化*/

#define LEN 1024

static CommFunc_t g_tComFuncArr[LEN]={

{3001,ThirdInParse},

{3002,ThirdOutOrgenize},

……

};

#endif

/*在頭文件中對組件聲明*/

//{3001 解析委托方響應(yīng)電文組件

int ThirdInParse(char * pBusinessID, char * pTransID, char * pEnterpriseID, char * pSequenceNum);

……

(2) 主程序?qū)崿F(xiàn)：

/*流程控制函數(shù)*/

TERMDBSS(TPSVCINFO * rqst)

{

/*1.根據(jù)發(fā)起交易的終端畫面號讀取業(yè)務(wù)標(biāo)識、交易代碼、企業(yè)碼*/

if (GetTransId(

szTermPageId,

//IN終端畫面號

szBusinessId,

//OUT業(yè)務(wù)標(biāo)識

szTransId,

//OUT交易代碼

szEnterpriseId

//OUT企業(yè)碼

) != 0)

goto err_return;

/*2.按業(yè)務(wù)標(biāo)識、交易代碼從數(shù)據(jù)庫中讀取流程配置，順序讀出各個組件*/

if (GetComsInvokeQue(

szBusinessId,

//IN業(yè)務(wù)標(biāo)識

szTransId,

//IN交易代碼

szEnterpriseId,

//IN企業(yè)碼

&tFlowFuns

//OUT組件數(shù)組

) != 0)

goto err_return;

/*3.按順序執(zhí)行終端輸入電文解析、總線數(shù)據(jù)更新等各組件，完成一筆交易*/

for(i=0; i

if(NULL == (ftComFuncHandle=

GetComFuncHandle(tFlowFuns.m_tFunArr[i].m_iFunSerials)))

//根據(jù)組件編號取得組件名

goto err_return;

/*4.調(diào)用組件函數(shù)進(jìn)行業(yè)務(wù)處理*/

if( (*ftComFuncHandle)(

szBusinessId,

//業(yè)務(wù)標(biāo)識

szTransId,

//交易代碼

szEnterpriseId,

//企業(yè)碼

tFlowFuns.m_tFunArr[i].m_szRuleSeq

//Com序列號

) != 0 )

goto err_return;

}

……

tpreturn(TPSUCCESS, 0, rqst->data,rqst->len, 0);

}

4 結(jié) 語

在添加新組件時，根據(jù)業(yè)務(wù)需求和組件設(shè)計原則開發(fā)組件[8]。隨著各類功能的組件越來越豐富，可復(fù)用的組件就越多，后期的軟件開發(fā)工作也就越來越少，從而將中間業(yè)務(wù)軟件開發(fā)工作轉(zhuǎn)變?yōu)閺慕M件庫中挑選合適的組件進(jìn)行組裝的過程[8]，實現(xiàn)新業(yè)務(wù)的快速上線。

本中間業(yè)務(wù)平臺自上線以來，通過配置化，僅7個多月即快速實現(xiàn)代收電信、移動、聯(lián)通話費、水電費、稅費、煙草款、代理保險、小額支付等三十多項業(yè)務(wù)開發(fā)上線，強(qiáng)有力支撐了業(yè)務(wù)發(fā)展。

參 考 文 獻(xiàn)

[1] Herzum P,Sims O.基于組件的企業(yè)級開發(fā)[M].韓柯,譯.北京:機(jī)械工業(yè)出版社,2005:2- 6.

[2] 何藝.重慶支付信息綜合服務(wù)系統(tǒng)集中代收付子系統(tǒng)的設(shè)計與實現(xiàn)[D].重慶:重慶大學(xué),2015.

[3] 蔡則祥,王艷君.商業(yè)銀行中間業(yè)務(wù)[M].中國金融出版社,2011:112- 113.

[4] 孫超.基于GAPS的代收付系統(tǒng)的設(shè)計與實現(xiàn)[D].浙江:浙江工商大學(xué),2015.

[5] 黃平.基于組件的軟件開發(fā)方法在金融中間業(yè)務(wù)系統(tǒng)中的應(yīng)用[J].浙江理工大學(xué)學(xué)報,2007,24(4):453- 456.

[6] 曹俊,林捷.銀行聯(lián)機(jī)交易系統(tǒng)中通訊前置系統(tǒng)的二次開發(fā)[J].上海應(yīng)用技術(shù)學(xué)院學(xué)報,2013,13(2):139- 142.

[7] 趙文晉.銀行中間業(yè)務(wù)繳費通平臺的設(shè)計和開發(fā)[EB/OL].(2011-07-22).[2016-11-25].http://www.docin.com/p-235047130.html.

[8] 馬櫟.基于HP-UNIX 11i操作系統(tǒng)的中間業(yè)務(wù)系統(tǒng)設(shè)計與實現(xiàn)[D].南昌:南昌大學(xué),2007.