在日常工作中對接第三方系統(tǒng)的時候，常見的小困擾是第三方系統(tǒng)返回的錯誤信息的處理。為了方便理解，我們需要將錯誤信息轉化為友好型提示，如何轉化呢？一起來學習一下吧。

作為一個B端或者SaaS產(chǎn)品經(jīng)理，在日常的工作中經(jīng)常需要對接第三方的系統(tǒng)。在對接第三方的系統(tǒng)的時候，比較常見的小困擾就是第三方系統(tǒng)返回的錯誤信息的處理。

有一些研發(fā)能力比較強或者說接口做的比較完善的第三方，他們返回的錯誤信息會比較的齊全，會包含錯誤碼，錯誤信息和其他內(nèi)容等，我們可以通過這些信息知道發(fā)生了什么錯誤，應該要怎么解決。

截圖出自：Aftership的API文檔

同時第三方的API文檔中也會有一個公共的錯誤碼查詢頁面，當我們遇到了一些問題之后，可以查看這些文檔去嘗試自己解決問題。

截圖出自：速賣通的API文檔

但是在實際的工作中，我們也會發(fā)現(xiàn)有一些第三方的API其實做得很不完善。有一些錯誤信息沒有規(guī)范處理，可能沒有錯誤碼，也可能錯誤信息都是一些偏術語性的程序錯誤，導致我們拿到了錯誤信息之后并不知道錯誤信息到底是怎么產(chǎn)生的，應該要怎么解決。類似于下圖的錯誤，是在對接一些國際物流渠道的時候經(jīng)常會遇到的問題：

DHL返回的錯誤，即使翻譯了也看不太懂原因是啥

在跨境電商SaaS ERP或者SaaS WMS/TMS這一類系統(tǒng)中，以上問題出現(xiàn)的頻率很高。尤其是SaaS ERP，因為它需要對接很多外部的第三方系統(tǒng)，例如說：

1. 對接電商平臺，Amazon，eBay，Walmart，Shopify等；
2. 對接物流商，國際物流（DHL，F(xiàn)edEx，UPS），跨境物流（云途，燕文，4PX）等；
3. 對接海外倉，谷倉，萬邑通，4PX，其他SaaS WMS等；
4. 對接一些工具服務商，圖片翻譯，圖片編輯，支付收款，選品分析等；

這些第三方系統(tǒng)，有一些是有比較專業(yè)的研發(fā)團隊，有一些則是不太專業(yè)的研發(fā)團隊，所以就會導致在對接完成了之后，用戶在使用的過程中如果遇到了問題或者錯誤，反饋回來的原始錯誤信息有可能是不太好閱讀的，甚至是壓根對不上的錯誤信息。

除此之外，由于要對接很多國外的系統(tǒng)（國際物流商），這些系統(tǒng)返回的錯誤信息還有一些語言上的差異，例如說德國的物流渠道會返回的錯誤是德語，法貨的物流渠道返回的錯誤是法語，即使是比較通用的英語，有一些錯誤信息還是需要借助翻譯工具才能理解其中的意思。

DHL Packet返回的錯誤是德語

基于以上的背景，當我們對接了大量的第三方系統(tǒng)，而第三方系統(tǒng)返回的錯誤信息可能是千差萬別，甚至非常不利于客戶理解的時候，我們就需要考慮去對第三方系統(tǒng)返回的錯誤信息做一個轉換處理，這個處理過程我稱之為：錯誤信息轉化為友好型提示的過程。

一、什么是友好型提示？

當用戶在使用系統(tǒng)的過程中，用戶并不關心系統(tǒng)背后對接了多少家第三方系統(tǒng)，用戶甚至也不擔心在使用的過程中遇到報錯，用戶擔心的是報錯看不懂，報錯有誤，這種不確定性會很容易消耗掉用戶的耐心，從而讓用戶對系統(tǒng)產(chǎn)生一些負面的看法。

作為一款信息系統(tǒng)的設計者（產(chǎn)品經(jīng)理），我們都知道系統(tǒng)運行發(fā)生錯誤，提示錯誤信息是不可避免的。但是我們期待的是，當系統(tǒng)出現(xiàn)了錯誤時，呈現(xiàn)給用戶看到的東西是“友好型的提示”，也就是讓用戶容易理解，最好是能能讓用戶自主排查問題、自行解決問題的一種提示。

友好型提示案例1

如上圖所示，我在刊登產(chǎn)品到Shopify的時候報錯了，系統(tǒng)告訴了我錯誤原因是“Unavaliable Shop”，同時還告訴了我解決方案，是因為我的店鋪不可用，需要重新授權，點擊就可以查看具體的授權操作幫助指引。

這種錯誤提示對用戶來說就是“友好型提示”，除了告訴我出錯了，還告訴了我錯誤原因是啥，我應該怎么去解決這個錯誤。

友好型提示案例2

上面這張圖反饋的也算是“友好型提示”，先告訴了我遇到了錯誤，同時也告訴了我錯誤原因是“account numer must be of the legth 14”，所以我要做的就是查看我的account number是否有超長。

并不是說“友好型提示”就一定要翻譯成中文或者一定要帶上解決方案，只要能讓用戶快速知道問題所在，并知道怎么解決這個問題，那么這種錯誤提示都可以稱之為“友好型提示”。

二、錯誤信息如何轉化為友好型提示？

當我們請求第三方系統(tǒng)的時候，從結果上來看，要么是成功的，要么是失敗的。如果只看失敗的情況下，失敗的提示也就分成兩種，要么是能看得懂的（友好型），要么是看不太懂的（非友好型）。

所以，當我們討論怎么將錯誤信息轉化為友好型提示時，其實前提是將“非友好型”的錯誤信息轉化為“友好型”的提示。因為，有一些第三方系統(tǒng)是會對錯誤信息處理好后才拋給請求方，這樣的錯誤信息一般情況下都是友好型的，而有一些第三方系統(tǒng)則是因為種種原因，所以就直接將非友好型的錯誤信息回傳給請求方了。

如果第三方回傳的是友好型提示，那么后端接收到了錯誤信息之后，無需處理，直接傳給前端去展示對應的錯誤即可；如果第三方回傳的是非友好型提示，那么后端接收到了之后就需要額外處理、轉化加工之后再傳給前端，去展示處理后的友好型提示。

那么，后端怎么判斷第三方系統(tǒng)返回的錯誤信息是友好型提示還是非友好型呢？

錯誤信息轉化為友好型提示的示意圖

最簡單的辦法就是在“錯誤信息”和“友好型提示”之間，加上一個過濾器，也稱之為處理規(guī)則或映射機制。

當系統(tǒng)接收到了第三方返回的錯誤信息之后，將錯誤信息推給處理規(guī)則，如果命中了處理規(guī)則，則返回處理后的數(shù)據(jù)，即友好型提示；如果沒有命中規(guī)則，則返回原始的錯誤信息。

系統(tǒng)增加一個“處理規(guī)則”的維護模塊，可以手動創(chuàng)建多個處理規(guī)則，然后所有的錯誤信息進入系統(tǒng)之后，都去輪詢跑所有的處理規(guī)則，看是否命中了對應的規(guī)則，如果命中了則按規(guī)則的配置進行處理，如果沒有命中在，則循環(huán)下一個規(guī)則，直到所有的規(guī)則都循環(huán)處理完成。

處理規(guī)則其實也很簡單，分成三部分，一個是規(guī)則基礎信息，一個是規(guī)則的匹配邏輯，另一個就是處理后的友好型提示。

在基礎信息模塊，可以定義規(guī)則的名稱，規(guī)則適用于什么第三方物流服務商，以及規(guī)則的優(yōu)先級等，下圖的示意圖沒有設置優(yōu)先級，是以對接的物流服務來舉例的，大家實際在設計的時候可以靈活的調整。

在規(guī)則的匹配邏輯模塊，可以被匹配的原始錯誤數(shù)據(jù)有兩類，一個是錯誤碼，一個是錯誤信息，而匹配的方式有三種，所以組合之后一共是最多6種匹配邏輯，這些匹配邏輯可以采用或的關系，也可以采用且的關系。

舉個例子，如果某第三方物流商的錯誤碼和錯誤信息如下圖所示，當系統(tǒng)需要創(chuàng)建處理規(guī)則來匹配其返回的錯誤碼或者錯誤信息的時候，可以有很多種配置方式。

第三方錯誤碼示意圖

針對錯誤碼設置匹配邏輯，可以有“完全匹配”，“模糊匹配”，“正則匹配”，如下圖所示：

如果是針對錯誤信息設置匹配邏輯，可以有“完全匹配”，“模糊匹配”，“正則匹配”，如下圖所示：

除此之外，還可以設置多條匹配規(guī)則，然后采用且或者或的關系進行組合，有非常多的組合方式，很是靈活。

在處理后的友好型提示模塊，必須要填寫的內(nèi)容是“友好型提示”，而“解決方案”是非必填的。當?shù)谌皆嫉腻e誤信息匹配了該條處理規(guī)則之后，系統(tǒng)會將“友好型提示”和“解決方案”的內(nèi)容傳給用戶展示。這樣用戶就可以看到處理后的提示，能更容易理解遇到了什么問題，將要怎么處理。

同時也要注意一下，為了帶來更好的體驗，“解決方案”這個字段還可以支持維護超鏈接的文字，這樣用戶還可以直接點擊就跳轉到對應的幫助手冊中。

用戶在前端界面看到的友好型提示

三、一些設計背后的思考

截止到寫這篇文章之前，我陸續(xù)做過2次的錯誤碼映射轉化的需求，但是之前的方案感覺建模的過程搞混了，所以有一些邏輯沒有想清楚，就總覺得這個方案不太好，是不是還有什么更優(yōu)解之類的。

當時設計方案的時候，一直把焦點放在了歷史的錯誤信息上。期望的是當一個新的錯誤信息進來后，先在歷史的錯誤信息池中找一遍，看是否能找到對應的錯誤，也就意味著這個錯誤曾經(jīng)發(fā)生過，然后把之前的錯誤信息對應的處理方式賦值給新的錯誤信息，相當于就直接得出了這條新錯誤的處理方式。

但是實際上，這樣的設計就是因為建模對象搞錯了，把重心放在了錯誤信息池上，每次進來的新錯誤都要插入到錯誤信息池中，同時還要標記上對應的處理規(guī)則，而這個處理規(guī)則是從歷史的錯誤信息的處理規(guī)則復制過來的。這樣就會導致每次去匹配歷史的錯誤信息都要花費很多時間，因為錯誤信息池肯定是會無限膨脹，逐步增加的。

當我為了寫這一篇文章，重新去對這些業(yè)務對象梳理、建模之后，發(fā)現(xiàn)只要把建模的核心放在處理規(guī)則上，其實這個事情就沒有想象中的復雜。因為處理規(guī)則是少量的，是可控，也是相對來說固定的，只要預設好處理規(guī)則，把它當做一個管道，原始錯誤進入管道，能處理的就會變成友好型提示，不能處理的就會用原始錯誤信息展示。只需要不斷地對這個管道升級和維護，未來它能處理的消息數(shù)量、類型、種類等都會隨之提升。

在此，我分享一個之前看到的聚水潭ERP的處理方式，當時單看這張圖的時候，我也想了挺久也搞不明白，但是結合我上面的分析之后，我發(fā)現(xiàn)看懂這張圖就不難了。

聚水潭ERP apiErrorMapping

四、總結

剛好最近在體驗ERP的刊登功能，就發(fā)現(xiàn)了原來除了物流系統(tǒng)之外，其實很多系統(tǒng)都會需要與第三方系統(tǒng)對接，而且都會遇到這種錯誤信息不利于用戶理解的場景，所以設計一套錯誤信息的轉化規(guī)則還是挺有價值的。適用于不同的行業(yè)，也適用于不同的系統(tǒng)，學會之后可復用性很高。

我在寫這篇文章的時候，在網(wǎng)上找了一下，發(fā)現(xiàn)幾乎沒有看到什么相關的問題，我猜測一方面是因為產(chǎn)品經(jīng)理可能沒有意識到這些錯誤信息對用戶來說體驗可能不太好，或者意識到了但是不太懂技術也不知道這個東西還可以優(yōu)化；還有一方面就是來自第三方的錯誤信息實在是太多了，這個工程量還是蠻大的，綜合考慮來看，這些優(yōu)先級可能會排的比較后；還是就是寫這種細節(jié)類、實操類總結文章太費時間，而且不是大家愛看的選題……

在我日常的調研和體驗多個SaaS/B端系統(tǒng)的過程中，我發(fā)現(xiàn)只有一些比較知名或者說重視用戶體驗的產(chǎn)品才會在這一塊投入較多的資源去優(yōu)化解決，其他同類型的競品做了類似的優(yōu)化的比較少見。

對于跨境電商領域的SaaS產(chǎn)品來說，這一塊的優(yōu)化尤為重要，尤其是SaaS ERP。畢竟一款成熟的ERP對接的第三方系統(tǒng)實在是太多了，很難保證諸多第三方的API體驗在及格線之上，既然如此，那還是選擇自己去做兜底的事情吧！

希望我的一些小小的思考能夠幫助大家，給大家一些啟發(fā)，如果你們有更好的解決方案的話，也歡迎留言與我交流。

為我投票

我在參加人人都是產(chǎn)品經(jīng)理2022年度作者評選，希望喜歡我的文章的朋友都能來支持我一下~

點擊下方鏈接進入我的個人參選頁面，點擊紅心即可為我投票。

每人每天最多可投35票，投票即可獲得抽獎機會，抽取書籍、人人都是產(chǎn)品經(jīng)理紀念周邊和起點課堂會員等好禮哦！

投票傳送門：https://996.pm/7V69p