前言

作为B端或者SaaS产品经理，日常工作中经常需要对接第三方系统，在对接第三方系统时，一个常见的问题就是第三方系统返回的错误信息的处理。

有些第三方的研发能力比较强，或者接口开发得比较完善，他们返回的错误信息会比较全，包括错误码，错误信息等内容，我们可以通过这些信息知道到底出现了什么错误，应该怎么解决呢？

截图来自：API 文档

同时第三方API文档中也会有公开的错误码查询页面，当我们遇到一些问题的时候，可以查阅这些文档，尝试自己解决问题。

截图来自： API 文档

但在实际工作中，我们也发现部分第三方API并不完善，有些错误信息处理不规范，可能没有错误码，也可能错误信息是一些比较技术性的程序错误，导致我们拿到错误信息后不知道这个错误信息是怎么产生的，如何解决。类似下面的错误是一些国际物流渠道对接时常见的问题：

DHL 返回的错误即使翻译后也不清楚。

在跨境电商SaaS ERP或者SaaS WMS/TMS系统中，经常会出现上述问题，尤其是SaaS ERP，因为需要对接很多外部第三方系统，比如：

与电商平台对接，eBay等；

对接物流商，国际物流（DHL、UPS）、跨境物流（云途、燕文、4PX）等。

对接海外仓、粮仓、万亿通、4PX、其他SaaS WMS等。

对接一些工具服务商，包括图片翻译，图片编辑，货款收款，选品分析等等。

这些第三方系统有的研发团队比较专业，有的研发团队比较不专业，导致在对接完成后，用户在使用过程中遇到问题或者错误，会进行反馈，而返回的原始错误信息可能很难读懂，甚至完全不可靠。

另外，由于需要对接很多国外的系统（国际物流商），这些系统返回的错误信息也存在一些语言差异。比如德国物流渠道返回的错误信息会是德语，法国物流渠道返回的错误信息则是德语，而德国物流渠道返回的错误信息则是法语。即使是比较常见的英语，有些错误信息仍然需要借助翻译工具才能理解其含义。

DHL 返回的错误是德语

基于上面的背景，当我们对接大量的第三方系统，而第三方系统返回的错误信息可能千差万别，甚至非常难以让客户理解的时候，我们就需要考虑如何对第三方系统返回的错误信息进行一个转换的过程，我称之为：将错误信息转换成友好提示的过程。

什么是友情提示？

用户在使用系统时，并不关心系统中接入了多少第三方系统，甚至不担心使用过程中遇到错误，他们担心的只是看不懂错误报告，或者错误报告有误。这种不确定性很容易磨灭用户的耐心，导致他们对系统产生负面看法。

作为一个信息系统的设计者（产品经理），我们都知道系统运行中的错误和错误信息在所难免。但我们期望的是，当系统出现错误时，呈现给用户的是“友好的提示”，是易于用户理解的提示，最好是允许用户自行排查和解决问题的提示。

温馨提示示例1

如上图，我在发布商品的时候报错，系统告诉我错误原因是“店铺”，还告诉我解决办法，就是我的店铺不可用，需要重新授权，点击查看具体的授权操作帮助指南。

这种错误提示对于用户来说是一种“友好提示”，它除了告诉我发生了错误之外，还告诉我错误的原因以及我应该如何解决这个错误。

温馨提示 案例2

上图是“友情提示”，我遇到了错误，错误原因是“必须是14的”，所以我所要做的就是检查我是否超出了限制。

并不是说“友好提示”一定要翻译成中文或者必须包含解决方案，只要用户能够快速了解​​问题所在，并且知道如何解决，这样的错误提示就可以称得上是“友好型提示”。

如何将错误信息转变为友好提示？

当我们请求第三方系统的时候，结果要么成功，要么失败，如果单看失败的话，失败提示无非就两种类型，要么可以理解（友好型），要么很难理解（不友好型）。

因此，当我们讨论如何将错误信息转换为友好提示时，前提其实是将“不友好”的错误信息转换为“友好”的提示。因为有些第三方系统会对错误信息进行处理。这样的错误信息一般都是友好的，但有些第三方系统会因为各种原因，直接将不友好的错误信息发回给请求者。

如果第三方返回的是友好提示，后端收到之后不需要对错误信息进行处理，直接传递给前端显示相应错误；如果第三方返回的是非友好提示，后端接收到之后需要进行额外的处理和转换，处理完之后才传递给前端显示友好提示。

那么，后端如何判断第三方系统返回的错误信息是友好提示还是非友好提示呢？

错误消息转换为友好提示的图表

最简单的办法就是在“错误信息”和“友好提示”之间增加一个过滤器，这也叫处理规则或者映射机制。

当系统接收到第三方返回的错误信息时，将错误信息推送至处理规则，若匹配处理规则，则返回处理后的数据，即友好提示；若不匹配规则，则返回原始的错误信息。

系统增加了“处理规则”维护模块，可以手动创建多条处理规则，然后所有错误信息进入系统后，会轮询并跑遍所有的处理规则，看是否命中对应的规则，如果命中，则按照规则的配置进行处理，如果没有命中，则循环执行下一条规则，直至循环处理完所有规则。

处理规则其实很简单，分为三个部分：一个是规则的基本信息，一个是规则的匹配逻辑，一个是处理后的友好提示。

在基础信息模块中可以定义规则的名称，该规则适用于哪些第三方物流服务商，以及该规则的优先级。下图没有设置优先级，只是以对接物流服务为例，设计时可以灵活调整。

在规则匹配逻辑模块中，可以匹配的原始错误数据有两种，一种是错误码，一种是错误信息，匹配方式有三种，所以组合起来之后，一共有最多6种匹配逻辑，这些匹配逻辑可以是或的关系，也可以是与的关系。

例如某个第三方物流商的错误码和错误信息如下图所示，当系统需要创建处理规则来匹配其返回的错误码或错误信息时，可以有多种配置方法。

第三方错误代码图

错误码的匹配逻辑可以选择“完全匹配”、“模糊匹配”或“常规匹配”，如下图所示：

如果要设置错误信息的匹配逻辑，可以选择“精确匹配”、“模糊匹配”或“常规匹配”，如下图所示：

另外，还可以设置多条匹配规则，然后通过and、or、or关系进行组合，组合方式非常多，非常灵活。

在处理后的友好提示模块中，必填内容为“友好提示”，而“解决方案”为选填内容，当第三方原始错误信息符合此处理规则时，系统会将“友好提示”和“解决方案”的内容展示给用户，这样用户看到处理后的提示，就能更容易的明白自己遇到了什么问题，如何解决。

同时请注意，为了提供更好的体验，“解决方案”字段还可以支持维护超链接文本，以便用户直接点击跳转到相应的帮助手册。

前端界面友好提示背后的一些思考

在写这篇文章之前，曾经做过两个错误码映射转换的需求，但是之前的解决方案感觉建模流程比较混乱，所以有些逻辑不太清晰，总感觉这个解决方案不太好。好吧，有没有更好的解决方案呢？

在设计解决方案的时候，我们始终把关注点放在历史错误信息上，我们预期当有新的错误信息进来时，会先去历史错误信息池里搜索，看能不能找到对应的错误，如果能找到就说明这个错误之前出现过，然后将之前错误信息对应的处理方法赋值给新的错误信息，相当于直接推导出这个新错误的处理方法。

但实际上这样的设计是因为建模对象把重心放在了错误信息池上，每个新进来的错误都要插入到错误信息池中并标注相应的处理规则，而这个处理规则是从历史错误信息的处理规则中复制过来的，这样就会导致每次都花很多时间去匹配历史错误信息，因为错误信息池肯定会无限扩大，逐渐变大。

当我为了写这篇文章重新整理和建模这些业务对象的时候，我发现只要把建模的核心放在处理规则上，这件事情并没有想象的那么复杂，它是可控的，相对固定的。只要预先设定好处理规则，就可以看成是一个流水线，原来的错误进入这个流水线，如果可以处理就变成友好提示，如果不能处理就用原来的错误信息。只要我们不断的升级和维护这个流水线，未来它能处理的消息数量、类型、种类都会越来越多。

在这里分享一下我之前看到的聚水潭ERP的一个处理方法，当时单独看这张图的时候想了好久都看不懂，但是结合我上面的分析之后发现，这张图其实是可以理解的，看图并不难。

聚水潭ERP概述

刚好最近在体验ERP的发布功能，发现除了物流系统之外，其实很多系统都是需要对接第三方系统的，就会遇到这样的错误信息不利于用户理解的场景，因此我设计了一套错误信息的转换规则，还是挺有价值的，适用于不同的行业和系统，学会之后复用性很强。

在写这篇文章的时候，我在网上搜了一下，发现几乎没有相关的问题。我猜想，一方面可能是产品经理没有意识到这些错误信息对用户来说可能不是一个好的体验。或者意识到了但是对技术不太了解，不知道可以优化；另一方面，第三方的错误信息太多了，工作量还是挺大的，综合考虑各方面因素，这些优先级可能会排在后面；又或者写这种详细实用的总结文章太耗时，不是大家喜欢看的话题……

在我日常对多个SaaS/B端系统的调研和体验中，发现只有一些知名的产品或者重视用户体验的产品才会投入较多的资源来优化解决这个问题，很少看到对产品做出类似的优化。

对于跨境电商领域的SaaS产品来说，这个优化尤为重要，尤其是SaaS ERP，毕竟成熟的ERP对接的第三方系统太多了，很多第三方的API体验很难保证在及格线以上，这种情况下，还不如选择自己做备份呢！

希望我的这些小想法能够帮助到大家，给大家一些启发，如果你有更好的解决方案，欢迎留言和我交流。

其他说明

最近开始回归职场，所以公众号相关的内容更新比较少，但是我还是坚持每天的知识摄入和输出，知识星球里放了一些碎片化、短小精悍的内容，如果你认同维他命公众号上的文章，那么我相信维他命的知识星球一定不会让你失望。

和公众号的文章一样有诚意有料，关键是价格还很诱人，目前价格159元/年，预计春节期间涨价到199元/年。

如果使用微信V（转账或者红包）可以享受150元/年的小优惠，有兴趣的朋友可以试试，文章最后我放了试用卡，先试用3天，满意了再去网约车。

结尾