導語：在線數字商品交易平臺邏輯框架分析一文來源于網友上傳，不代表本站觀點，若需要原創文章可咨詢客服老師，歡迎參考。

摘要：話費、流量等數字商品已成為日常生活中不可或缺的部分，在線購買交易量級不斷攀升，對交易系統業務邏輯的高效性、安全性也提出了更高要求，結合“面向對象程序開發實戰”教學目標，對系統業務邏輯框架進行了分析與設計，制定開發內容。業務框架主要包括接收上游訂單及查詢業務、渠道分配業務、渠道發貨業務、接收渠道結果通知業務、向渠道查詢結果業務、向上游通知結果業務等，業務邏輯完整，確保安全高效。

關鍵詞：數字商品；交易平臺；業務框架

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

1業務需求分析

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

2業務邏輯詳細設計

交易系統業務框架模塊圖如圖1所示，主要由6個業務模塊構成，下文將從流程圖的角度對各個模塊的業務邏輯進行設計說明。

2.1接收上游訂單及查詢業務模塊

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

2.2渠道分配業務模塊

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

2.3渠道發貨業務模塊

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

2.4接收渠道結果通知業務模塊

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

2.5向渠道查詢結果業務模塊

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

2.6向上游通知結果業務模塊

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

3結論

本文對數字交易平臺業務邏輯框架進行了分析與設計，根據高內聚、低耦合的原則設計業務模塊，以狀態變化驅動業務流轉，保證交易安全的同時提高訂單處理效率。本案例應用在“面向對象程序開發實戰”課程實踐中，作為實踐內容，在鍛煉學生動手能力的同時，培養團隊協作精神。

參考文獻：

[1]吳杰明，方英蘭.軟件工程實例教程[M].北京：清華大學出版社，2010.

[2]羅小利，吳清烈.SaaS軟件服務基于大規模定制的業務邏輯框架研究[J].電信科學，2011，27（9）：26-31.

[3]陳偉，沈備軍，戚正偉.面向SaaS應用的業務邏輯定制框架的研究與實現[J].計算機應用研究，2011，28（1）：155-158.

[4]張榮，孫家澤.電信增值業務框架中業務邏輯的設計[J].西安郵電學院學報，2008（3）：111-113.

[5]吳立春.基于Facade模式的業務邏輯層框架設計[J].微計算機信息，2007（24）：245-246+308.

作者：謝劍 單位：湖南信息職業技術學院