[發明專利]一種與銀行進行交互重試的方法和系統

在審

• 申請號: 201710740013.6
• 申請日: 2017-08-23
• 公開（公告）號: CN107544853A
• 公開（公告）日: 2018-01-05
• 發明（設計）人: 王子嵩;容賾
• 申請（專利權）人: 萬惠投資管理有限公司
• 主分類號: G06F9/54
• 分類號: G06F9/54;G06Q40/02
• 代理公司: 北京超凡志成知識產權代理事務所(普通合伙)11371
• 代理人: 王術蘭

技術領域

本發明涉及數據處理領域，特別涉及一種與銀行進行交互重試的方法和系統。

背景技術

現代的互聯網金融應用為了實現自身需求，其系統內部需要和大量的銀行接口進行交互調用，比如充值、提現、還款等。在交互過程中，存在各種跨機房、跨網段、跨運營商的場景，由于距離較遠、網絡穩定性不確定等因素，會經常性發生交互失敗。交互失敗后，一般會采用重試等機制來解決交互失敗的問題。傳統同類方法因其設計思路、理念的不同，主要有以下缺點：

1.無法快速開發，無法方便的應用于各種各樣需要重試的業務。傳統方案只能根據某一具體業務實行重試，比如充值、提現、投資等，沒有抽象出一套靈活的、可擴展的，方便快速適用的解決方法。需要為每一種業務定義重試記錄表、編寫定時調度代碼，開發過程繁瑣，存在大量邏輯相似或重復的代碼。

2.重試的觸發時間無法靈活配置。傳統方案只能根據事先配置好的策略進行簡單的定時重試，比如每X秒，重試一次。無法指定重試停止條件，無法根據不同業務信息參數，指定重試觸發時間、最大重試次數等。

3.重試過程、結果無法追蹤。傳統方法僅僅是單純反復調用，行為比較單一，比如定時查詢，調用某一銀行接口，沒有記錄調用結果過程上下文等，無法跟蹤、定位、調試重試過程中遇到的異常問題。

4.手工操作。傳統方法往往會提供一個后臺管理界面，由管理員或客服人員在后臺執行重試邏輯。比如充值場景，當用戶充值，調用銀行接口時發生網絡異常，需要商戶登錄后臺管理界面，自行針對該筆業務進行查詢、重試，最終達到業務成功或失敗結果。此種方案在當今的互聯網信息技術中，顯得十分笨拙，當交互異常大量發生時，需要消耗大量的人力、時間去進行手工操作。

發明內容

針對現有技術中的缺陷，本發明提出了一種與銀行進行交互重試的方法和系統，提供了一種更加完善，方便的與銀行接口交互的重試方法。

具體的，本發明提出了以下具體的實施例：

本發明實施例1公開了一種與銀行進行交互重試的方法，應用于包括客戶端以及服務端的系統中，該方法包括：

當在觸發調用銀行接口的操作時，客戶端判斷所述調用的返回結果是否滿足預設的重試條件；

若判斷結果為是，判斷待進行的重試是同步模式還是異步模式；

若為同步模式，則以預設時間段為周期進行預設次數的重試，并將重試的結果輸入狀態機，以及執行與狀態機所反饋的結果對應的處理流程；

若為異步模式，則向服務端發送異步重試消息，并將調用銀行接口的結果返回給調用方。

在一個具體的實施例中，當重試為同步模式時，所述重試為同步阻塞式重新調用銀行接口。

本發明實施例還提出了一種與銀行進行交互重試的方法，應用于包括客戶端以及服務端的系統中，該方法包括：

服務端接收客戶端發送的異步重試消息；

根據所述異步重試消息獲取重試任務配置信息；

基于所述重試任務配置信息確定下次重試的執行時間，并創建重試任務；

初始化所創建的重試任務；

將所述重試任務持久化到存儲設備上。

在一個具體的實施例中，還包括：

定時獲取所述存儲設備上的重試任務；

執行所獲取的重試任務。

在一個具體的實施例中，還包括：

獲取所述執行的執行結果；

將所述執行結果發送給狀態機；

接收所述狀態機所反饋的輸出結果；

執行與所述輸出結果對應的處理流程。

本發明實施例還提出了一種客戶端，應用于包括客戶端以及服務端的系統中，該客戶端包括：

第一判斷模塊，用于當在觸發調用銀行接口的操作時，判斷所述調用的返回結果是否滿足預設的重試條件；

第二判斷模塊，用于當所述第一判斷模塊的判斷結果為是時，判斷待進行的重試是同步模式還是異步模式；

執行模塊，用于當重試為同步模式時，則以預設時間段為周期進行預設次數的重試，并將重試的結果輸入狀態機，以及執行與狀態機所反饋的結果對應的處理流程；

發送模塊，用于當重試為異步模式時，向服務端發送異步重試消息，并將調用銀行接口的結果返回給調用方。

在一個具體的實施例中，當重試為同步模式時，所述重試為同步阻塞式重新調用銀行接口。

本發明實施例還提出了一種服務端，應用于包括客戶端以及服務端的系統中，該服務端包括：

接收模塊，用于接收客戶端發送的異步重試消息；

獲取模塊，用于根據所述異步重試消息獲取重試任務配置信息；