业务背景：
系统中存在已经办结成功的机构预约开户的流程需要把流程的相关的附件信息中的pdf文件转换成图片格式推送到中台

开发刚开始做的时候是想着首先通过b_sno的流水编号查出对应的流水的附件，然后直接把pdf的附件通过接口的形式编码成图片格式base 64的文件流，然后在在传送给中台

在第一次的测试中，测试需要把开发的代码升级到测试环境进行验证，实际测试环境验证接口的时候，通过apifox调用接接口直接失败了,测试环境不能进行明文传输进行接口调用

在chrome获取网络请求的时候body是加密的，需要解密之后才可以进行下一步操作，还好之前的测试同事写好了解密的方法，我就只能把抓取到的body先解密之后，在修改成想要参数在进行加密，加密之后才能调用接口。

解决完接口加密的问题，在调用接口的时候，发现接口虽然调用成功了，但是确是所有的流水号的正文附件都可以查，本着需求为原则问了一下开发，他说考虑平台的可复用性，把这个接口做成公共的，而不是特定业务的接口，这样后续可以继续使用。好吧！的确很有道理，那就按照他的思路来呗。测试了一下平台上几个存在附件的流程基本都可以查询出附件，并转换成文件流，主要需要确定一下对应的b_sno流水号的所有文件是否都转成文件流就可以了。由于接口返回的都是文件流，没法对文件流进行验证，只能通过关键字匹配文件流的个数与数据库对应流水存储文件的个数进行对比，一致的话就判定转换成功。也可以通过流水号和正文附件的关联表进行比对。

这里面其实还存在一个问题就是附件pdf较多的时候，通过接口调用返回的数据流会有很多，导致响应的数据在接口工具中进行查看的时候会很卡。当附件过大的时候转换成文件流的时候可能存在失败的情况，当时因为我们上传的模板基本是固定的，就没有考虑到会上传一个很大的正文附件，这个的确是测试的锅，不过好在联调的时候发现了，发现这个问题的时候，首先想到的解决方法是我们在一个FLOW_BUSI_DATA 表的ACCEPT_PARAM字段中存储了在流程提交的时候的相关数据，也包含该流程的正文附件转换成文件流的存储数据，只需要把它提取出来就可以了，但是依然无法解决接口响应的数据太多的问题，最终的解决办法是把相对于的返回压缩成一个zip的文件，把zip文件给第三方解压，然后再让他们按照我们提供的规则解析文件流得到对应的流水的附件数据。