企查查更换链接问题处理记录_20190118 记录

lake 2019-1-18 1426

背景以及问题说明:
    1:通过前期沟通,企查查帮开启了用户,之后使用测试地址进行测试。
    2:产生了链接异常的问题
处理过程:
   a)研发团队处理
       1. 最初,赵欢祥发现该问题后,向我进行了反馈
       2.根据赵欢祥的描述,推测问题测试地址的问题,并要求其与可新联系,查看开发过程
       3.可新登陆企查查后台,发现剩余次数为0,断定问题是因为欠费造成的,
       4.当时向我反馈是因为欠费造成,因属于推断性结论,让其确认链接地址性质是测试地址还是开发地址,以确认是否因地址问题造成此问题
       5.之后赵欢祥没有就地址得出结论,也没有进一步应对,得出结论是欠费,就此放弃处理,并未时反馈
       6.隔日,安排赵英男追踪此问题,他向赵欢祥探寻后,得出是欠费问题,就此向我反馈。
       7.登陆企查查后,发现其接口的错误代码中会针对欠费信息返回异常代码,因此推测还是链接的问题,要求赵英男继续针对链接进行追查。
       8.因推测的问题原因是链接的性质问题,赵英男先是确认链接与之前能使用的时候是一致的,但是对错误信息表述不详。后让其改为正式的链接进行测试
       9.赵英男在将链接改为正式链接后,并改变了之前的实现的方式,采用配置式方式进行处理
      10.改用正式链接后,能访问成功,并返回错误码115,进一步确认问题还是欠费的问题。
      11.晚上充值300后,还是返回115代码,问题就此搁置。
   b)后续处理
      1.因问题的结论是欠费,但是付款后还是不能访问,产生死结。后续问题的处理由我接手。
      2.首先确认充值到账,之后与其客服联系
      3.首先将问题与客服描述后,客服居然表示他不负责处理该问题,给了一个商务的电话,让我打商务的电话。
      4.打了商务电话后,商务居然又给了一个客服qq,让我加他好友进行问题处理,不过他反馈了一个有用的问题:他们升级了系统,之前旧的接口系统关闭掉了。新的系统他不知道(此次沟通中唯一有效的问题)
      5.加了商务给的qq,反馈了问题后,那人居然发了一个文档就不理我了。。
      6.根据商务反馈的情况以及咱们实际测试的情况,发现已经很明确的提示了问题:115,用户验证失败。
      7.重新梳理官网的api说明,发现其有header的要求,但是我们的开发环境中并没有指定header,并且客服提供的文档中也有header的要求
     8.后续根据官网api的要求设置header,更新代码后发现还是115错误
     9.百度搜索后发现使用的getfotobject方法不支持设置header,换用其他的实现后,解决。
后记:
    涉及沟通的联系方式:
         企查查商务:18021273213
         接口客服qq:2729142779
总结:
    问题本身:
        1:之前使用的是地址,企查查升级后关闭了该链接,即最初产生IO异常的原因
        2:框架使用的方法不支持设置header,导致后续无法提交header
        3:url地址以及相关key采用固定代码实现,不利用扩展和更换。已经进行了变更
经验教训
    内部:
       1:研发团队成员过度使用经验,没有切实对问题进行分析。
       2:汇报反馈和沟通流程中思维固化,一旦认定后,很难直面问题本身
       3:代码以及文档阅读能力太弱,企查查官网已经明确给出了接口规则,但是没有很好的解读和使用。
       4:代码编程范式需要进一步培养
   外部:
       1:企查查的相关文档比较到位,对遇到的问题有了较好的说明
       2:其客服能力比较弱,官网的客服居然不能应对问题,并且需要折转多次,最终对问题应对也比较应付
       3:其系统开票时居然要输入税号,做企业资料查询的企业,这部分都不能自动获取,还在推广给别的企业使用。这点很说明问题,自己的东西自己用不起来,却希望别人能很好的使用。估计就是设计和执行的差异所在了


最后于 2019-1-18 被lake编辑 ,原因:
最新回复 (0)
全部楼主
返回