在線數(shù)字商品交易平臺邏輯框架分析

時間:2022-07-26 09:52:40

導(dǎo)語:在線數(shù)字商品交易平臺邏輯框架分析一文來源于網(wǎng)友上傳,不代表本站觀點,若需要原創(chuàng)文章可咨詢客服老師,歡迎參考。

在線數(shù)字商品交易平臺邏輯框架分析

摘要:話費、流量等數(shù)字商品已成為日常生活中不可或缺的部分,在線購買交易量級不斷攀升,對交易系統(tǒng)業(yè)務(wù)邏輯的高效性、安全性也提出了更高要求,結(jié)合“面向?qū)ο蟪绦蜷_發(fā)實戰(zhàn)”教學(xué)目標(biāo),對系統(tǒng)業(yè)務(wù)邏輯框架進(jìn)行了分析與設(shè)計,制定開發(fā)內(nèi)容。業(yè)務(wù)框架主要包括接收上游訂單及查詢業(yè)務(wù)、渠道分配業(yè)務(wù)、渠道發(fā)貨業(yè)務(wù)、接收渠道結(jié)果通知業(yè)務(wù)、向渠道查詢結(jié)果業(yè)務(wù)、向上游通知結(jié)果業(yè)務(wù)等,業(yè)務(wù)邏輯完整,確保安全高效。

關(guān)鍵詞:數(shù)字商品;交易平臺;業(yè)務(wù)框架

隨著通信技術(shù)的發(fā)展以及移動互聯(lián)網(wǎng)應(yīng)用軟件的大量出現(xiàn),廣大手機(jī)用戶,特別是年輕用戶更傾向于在移動終端進(jìn)行話費及流量等數(shù)字商品的購買消費,傳統(tǒng)的營業(yè)廳繳費、充值卡繳費等方式逐漸被邊緣化,產(chǎn)業(yè)結(jié)構(gòu)也逐漸發(fā)生調(diào)整,新的行業(yè)在線交易業(yè)務(wù)模式出現(xiàn)并呈多樣化發(fā)展,業(yè)務(wù)邏輯也不斷完善,在確保交易資金安全的基本前提下,不斷調(diào)整系統(tǒng)模塊結(jié)構(gòu),優(yōu)化交易業(yè)務(wù)邏輯,以提高單筆訂單的處理效率,縮短交易時間,給用戶呈現(xiàn)更好的體驗感。通過對話費流量等數(shù)字商品交易業(yè)務(wù)邏輯框架分析與設(shè)計,使學(xué)生了解更多與生活息息相關(guān)的互聯(lián)網(wǎng)應(yīng)用背后的技術(shù)細(xì)節(jié),提升學(xué)習(xí)興趣,并在業(yè)務(wù)邏輯實現(xiàn)的過程中提升動手能力,實現(xiàn)課程教學(xué)目的。

1業(yè)務(wù)需求分析

在數(shù)字商品交易發(fā)展的初期,很多業(yè)務(wù)流程處理都是集成在一個模塊中完成的,從接收上游收單到向渠道發(fā)貨的業(yè)務(wù)邏輯都在統(tǒng)一模塊中順序執(zhí)行完成,此種處理在設(shè)計上相對簡單,所需考慮情況也較少,訂單自始至終都是由一個工作線程處理,處理速度相對較慢,在業(yè)務(wù)發(fā)展的初期訂單量不足時還可接受,但是當(dāng)業(yè)務(wù)量級增長到一定階段時,此種業(yè)務(wù)框架模式的弊端就開始顯現(xiàn),表現(xiàn)在系統(tǒng)不能及時接收處理上游訂單,或是訂單出現(xiàn)網(wǎng)絡(luò)異常等情形時人工介入的頻率增加,這些問題都直接影響到企業(yè)盈利。因此結(jié)構(gòu)調(diào)整成為必然,將業(yè)務(wù)模塊拆分成多個模塊,以訂單狀態(tài)變化驅(qū)動業(yè)務(wù)流轉(zhuǎn),各模塊線程以流水線接力的方式完成訂單的消化,這樣的結(jié)構(gòu)在效率及安全性上都有大幅提升。業(yè)務(wù)框架設(shè)計主要由接收上游訂單及查詢業(yè)務(wù)模塊、渠道分配業(yè)務(wù)模塊、渠道發(fā)貨業(yè)務(wù)模塊、接收渠道結(jié)果通知業(yè)務(wù)模塊、向渠道查詢結(jié)果業(yè)務(wù)模塊、向上游通知結(jié)果業(yè)務(wù)模塊等組成。接收上游訂單及查詢業(yè)務(wù)模塊負(fù)責(zé)接收上游的訂單交易請求以及訂單充值情況查詢請求,兩種請求根據(jù)接口協(xié)議中的命令字段值進(jìn)行區(qū)分,收單業(yè)務(wù)經(jīng)過一定校驗處理后在自身數(shù)據(jù)庫中生成對應(yīng)的訂單記錄繼續(xù)充值過程,接收查詢業(yè)務(wù)則負(fù)責(zé)在本系統(tǒng)查詢上游訂單的充值結(jié)果并按協(xié)議返回數(shù)據(jù)。渠道分配業(yè)務(wù)模塊用于根據(jù)生成的訂單記錄中的交易要素選擇最優(yōu)的下游渠道或下游運營商進(jìn)行交易,由于所選擇的渠道未必都可交易成功,因此該過程可能會重復(fù)多次,但是每次執(zhí)行都會在數(shù)據(jù)庫中生成對應(yīng)訂單流水記錄,用于記錄當(dāng)次選擇的渠道信息。渠道發(fā)貨業(yè)務(wù)模塊負(fù)責(zé)根據(jù)選擇的渠道信息向該渠道發(fā)送交易網(wǎng)絡(luò)請求,并記錄下游響應(yīng)情況。接收渠道結(jié)果通知業(yè)務(wù)模塊用于異步的交易方式,被動接收渠道對交易訂單的完成情況。向渠道查詢結(jié)果業(yè)務(wù)模塊同樣用于異步交易方式,主動向下游查詢訂單完成情況。向上游通知結(jié)果業(yè)務(wù)模塊用于將自身數(shù)據(jù)庫接收的上游訂單的完成情況主動告知上游,實現(xiàn)訂單的完結(jié)。

2業(yè)務(wù)邏輯詳細(xì)設(shè)計

交易系統(tǒng)業(yè)務(wù)框架模塊圖如圖1所示,主要由6個業(yè)務(wù)模塊構(gòu)成,下文將從流程圖的角度對各個模塊的業(yè)務(wù)邏輯進(jìn)行設(shè)計說明。

2.1接收上游訂單及查詢業(yè)務(wù)模塊

本業(yè)務(wù)模塊是交易訂單進(jìn)入平臺的唯一入口,安全性是首先需要考慮的,因此在收到請求時先提取出命令字、上游編號及上游訂單號、上游產(chǎn)品編號、充值號碼等信息,根據(jù)上游編號在數(shù)據(jù)庫中查找對應(yīng)上游信息,判斷上游狀態(tài)是否正常,本次請求IP是否在上游請求IP白名單內(nèi),對請求數(shù)據(jù)進(jìn)行簽名校驗等安全驗證操作,通過后再根據(jù)命令字進(jìn)行后續(xù)處理。若是充值命令,首先根據(jù)上游編號及上游訂單號在數(shù)據(jù)庫訂單表中查詢是否已存在該筆訂單記錄,若存在則按照接口協(xié)議進(jìn)行報文回復(fù),不做其他處理,如不存在則進(jìn)行新訂單入庫操作。訂單入庫邏輯為:首先對充值號碼進(jìn)行白名單及當(dāng)日充值額度上限檢查,若不通過則返回報文,流程結(jié)束;若通過則根據(jù)上游產(chǎn)品編號在平臺產(chǎn)品表中查找平臺產(chǎn)品編號、運營商、省份等信息,同時生成對應(yīng)的系統(tǒng)訂單號,將這些信息插入系統(tǒng)訂單表及訂單發(fā)貨隊列表,訂單表記錄及隊列表記錄狀態(tài)置為等待選擇渠道。訂單表記錄保存訂單的詳細(xì)信息,該表屬于大表,信息永久保留。訂單發(fā)貨隊列表主要記錄訂單狀態(tài),提高搜索速度,記錄在訂單完結(jié)時會刪除。收單業(yè)務(wù)在保證安全的前提下,盡量縮短業(yè)務(wù)處理邏輯,節(jié)省時間,提高收單效率。若是查詢命令,則根據(jù)上游編號及訂單號在訂單表中查詢記錄是否存在,若沒有則回復(fù)訂單不存在,若存在則根據(jù)訂單結(jié)果(充值成功、充值失敗、充值中)組織相應(yīng)報文進(jìn)行回復(fù),完成業(yè)務(wù)處理。流程圖如圖2所示。

2.2渠道分配業(yè)務(wù)模塊

渠道分配業(yè)務(wù)模塊從訂單發(fā)貨隊列表中查找狀態(tài)為等待選擇渠道的記錄信息集合,通過訂單號在渠道發(fā)貨流水表中查找該筆訂單的所有發(fā)貨流水記錄信息。統(tǒng)計發(fā)貨次數(shù)是否超過限制,若超過限制則將訂單置為失敗,修改相關(guān)表狀態(tài)后不再進(jìn)行處理;若沒有超過限制,則根據(jù)訂單表記錄里的面值、省份、運營商等信息在渠道表里查找有支持對應(yīng)產(chǎn)品的渠道信息集合,并按照渠道分流比由大到小的順序?qū)Y(jié)果進(jìn)行排序,優(yōu)先向優(yōu)質(zhì)渠道發(fā)貨以提高成功率。然后逐個取出集合中的記錄,判斷渠道當(dāng)前是否可用,不可用則判斷下一個,可用則判斷當(dāng)前渠道是否在已嘗試發(fā)貨流水記錄中存在,若存在則判斷下一個,當(dāng)集合都遍歷后仍無符合條件渠道,則將訂單置為失敗處理;若不存在則作為本次待發(fā)送的渠道,停止判斷,立即將隊列表記錄鎖定,判斷訂單狀態(tài)是否為等待選擇渠道,若不是則將發(fā)貨隊列狀態(tài)修改為分配渠道中,再根據(jù)選擇的渠道號在渠道產(chǎn)品表中查找對應(yīng)渠道產(chǎn)品編號等信息,生成本次渠道發(fā)貨流水號,將渠道號、訂單號、渠道發(fā)貨流水號、渠道產(chǎn)品編號、流水狀態(tài)等信息插入渠道發(fā)貨流水記錄表,記錄狀態(tài)為等待發(fā)貨,同時將訂單表及隊列表中的記錄狀態(tài)修改為等待發(fā)貨,以便進(jìn)行下一步處理。流程圖如圖3所示。

2.3渠道發(fā)貨業(yè)務(wù)模塊

渠道發(fā)貨業(yè)務(wù)模塊從訂單發(fā)貨隊列表中查找狀態(tài)為等待發(fā)貨的記錄信息集合,對集合中的每條記錄查詢鎖定并判斷訂單記錄狀態(tài)是否為等待發(fā)貨、流水記錄狀態(tài)是否為等待發(fā)貨,狀態(tài)無誤則將發(fā)貨隊列狀態(tài)修改為發(fā)貨中。再根據(jù)流水表中渠道號,查詢對應(yīng)渠道發(fā)貨地址、簽名秘鑰等信息,按照接口協(xié)議組織報文發(fā)送請求,并根據(jù)渠道響應(yīng)的信息修改相關(guān)表狀態(tài)。若發(fā)貨成功,則將訂單表記錄、隊列表記錄、流水表記錄狀態(tài)都修改為等待充值結(jié)果,等待渠道異步返回充值結(jié)果。若發(fā)貨失敗則將訂單表記錄及隊列表記錄狀態(tài)修改為等待選擇渠道,流水表記錄狀態(tài)修改為發(fā)貨失敗,等待再次嘗試。若未接收到響應(yīng)報文,則按發(fā)貨成功處理。流程圖如圖4所示。

2.4接收渠道結(jié)果通知業(yè)務(wù)模塊

接收渠道結(jié)果通知業(yè)務(wù)模塊用于接收渠道發(fā)送的訂單充值結(jié)果,通知的結(jié)果情形只有成功和失敗。簽名校驗后,根據(jù)接口協(xié)議中的訂單發(fā)貨流水號,找到相應(yīng)的訂單發(fā)貨流水記錄、訂單記錄、訂單發(fā)貨隊列記錄,判斷三個記錄的狀態(tài)是否都為等待充值結(jié)果,若不一致則等待人工核實處理,若一致則根據(jù)充值結(jié)果進(jìn)行相應(yīng)處理。若充值成功,則將訂單表記錄、發(fā)貨流水記錄狀態(tài)修改為充值成功,若充值失敗,則將兩個記錄狀態(tài)修改為充值失敗,再將訂單發(fā)貨隊列記錄刪除,同時插入訂單通知隊列記錄,狀態(tài)為等待通知上游,等待將結(jié)果通知給上游。流程圖如圖5所示。

2.5向渠道查詢結(jié)果業(yè)務(wù)模塊

向渠道查詢結(jié)果業(yè)務(wù)模塊作為接收渠道結(jié)果通知模塊的補(bǔ)充,在長時間沒有收到渠道結(jié)果通知的情況下主動向渠道發(fā)起結(jié)果查詢請求,在訂單發(fā)貨隊列表中查找狀態(tài)為等待充值結(jié)果且更新時間超過設(shè)定間隔時間的記錄進(jìn)行查詢,并根據(jù)查詢結(jié)果及時更新訂單相關(guān)狀態(tài),避免因渠道通知模塊異常造成訂單未及時完結(jié),導(dǎo)致訂單交易耗時延長。查詢到結(jié)果后的處理和渠道主動通知結(jié)果處理相同,只是在異常情況下出現(xiàn)返回查詢結(jié)果為訂單不存在時,就需要人工核對溝通處理。訂單狀態(tài)修改與接收渠道通知業(yè)務(wù)基本一致,不再贅述,流程圖與圖5相似,未單獨畫出。

2.6向上游通知結(jié)果業(yè)務(wù)模塊

在系統(tǒng)內(nèi)訂單結(jié)果明確后就要將該充值結(jié)果通知給上游,在通知隊列表中查詢狀態(tài)為等待通知上游且通知次數(shù)少于限定次數(shù)的記錄,分配給工作線程,鎖定通知隊列記錄并將狀態(tài)修改為通知中,避免被再次篩選出來。同時檢查訂單表記錄及發(fā)貨流水記錄狀態(tài)是否同為充值成功或充值失敗,相同時則按照接口協(xié)議將結(jié)果組包發(fā)送到上游,若上游成功接收并響應(yīng)則將訂單表記錄中是否通知上游狀態(tài)改為是,同時刪除通知隊列記錄,訂單邏輯完結(jié);單表記錄及發(fā)貨流水記錄狀態(tài)不同時則將通知隊列狀態(tài)修改為等待通知上游,同時通知次數(shù)加1,等待再次通知。流程圖如圖6所示。

3結(jié)論

本文對數(shù)字交易平臺業(yè)務(wù)邏輯框架進(jìn)行了分析與設(shè)計,根據(jù)高內(nèi)聚、低耦合的原則設(shè)計業(yè)務(wù)模塊,以狀態(tài)變化驅(qū)動業(yè)務(wù)流轉(zhuǎn),保證交易安全的同時提高訂單處理效率。本案例應(yīng)用在“面向?qū)ο蟪绦蜷_發(fā)實戰(zhàn)”課程實踐中,作為實踐內(nèi)容,在鍛煉學(xué)生動手能力的同時,培養(yǎng)團(tuán)隊協(xié)作精神。

參考文獻(xiàn):

[1]吳杰明,方英蘭.軟件工程實例教程[M].北京:清華大學(xué)出版社,2010.

[2]羅小利,吳清烈.SaaS軟件服務(wù)基于大規(guī)模定制的業(yè)務(wù)邏輯框架研究[J].電信科學(xué),2011,27(9):26-31.

[3]陳偉,沈備軍,戚正偉.面向SaaS應(yīng)用的業(yè)務(wù)邏輯定制框架的研究與實現(xiàn)[J].計算機(jī)應(yīng)用研究,2011,28(1):155-158.

[4]張榮,孫家澤.電信增值業(yè)務(wù)框架中業(yè)務(wù)邏輯的設(shè)計[J].西安郵電學(xué)院學(xué)報,2008(3):111-113.

[5]吳立春.基于Facade模式的業(yè)務(wù)邏輯層框架設(shè)計[J].微計算機(jī)信息,2007(24):245-246+308.

作者:謝劍 單位:湖南信息職業(yè)技術(shù)學(xué)院