博西（BOSCH）EDI项目实施日志（二）——shipment订单和运单回传

此次EDI项目实施涉及到三个业务：shipment、Freight Note、Image，下面是业务流程图：

Shipment 订单
是博西发给物流公司的，这个过程通过在edi系统，即RSSBus上调用物流平台的API接口，来将订单发送到物流平台的系统上，完成一次下单；
Freight Note 运单
是物流公司回给博西的，通过物流平台调用EDI系统的API接口，EDI系统RSSBus收到Freight Note.xml文件，知行通过在rssbus上定制化开发，将xml文件转成博西规范中需要的txt文件，发到博西EDI系统上。
Image 物流照片
和Freight Note的流程基本是一致的。

下面重点讲一下shipment订单中的问题

请求API中需要注意的点：
1、请求json的content格式需要和请求API接口要求的格式一致，注意参数之间的层级关系；
2、根据被请求方的要求对内容加密时要注意是否要去除空字符，参数需要按照字母顺序排列等；
3、当参数的value出现空值时，是否会对最终签名造成影响；
4、注意最终签名时根据哪些参数做md5哈希，严格按照接口文档生成**；

使用postman调用api接口可以参考另一篇文章：
https://blog.****.net/channyfish/article/details/86164986

这里分享一个困扰我很久的问题，在处理content的空字符时，一开始使用了regexreplace("\s","")，将空字符全部替换掉，但因为订单时间的格式是yyyy-MM-dd HH:mm:ss，在value内部有空格，我先是在给时间设置格式为：yyyy-MM-ddTHH:mm:ss，后在脚本中做了replace操作，replace(“T”,"")，这样处理之后签名可以正确请求。
但问题出现了，是我刚开始没有考虑到的一点：若是其他参数的value也有空格，做了替换空格的操作，那值就和请求的实际内容不同了，所以regexreplace("\s","")这样的操作时不可取的！！
其实处理这个问题的方法很简单，就是在写json模板时就将所有参数直接的空字符给删除掉，就不用对全部的内容做匹配空格再做去除的操作了！所以在处理问题时一定要考虑全面，有些快速的方法并不一定适合每种场合。

Freight Note和Image中需要注意的问题是调用EDI平台api，需要对请求的content做base64处理，RSSBus相对应的Port会完成自动解码。

在处理请求返回的参数时，例如返回：

{"data":123456,message:"shipment","success":"true"}

需要对success的value判断，true代表请求成功，false代表请求失败，这时就要抛出错误信息。
在RSSBus系统中有个功能可以对发送失败的文件做邮件提醒，这个时候就会收到文件发送异常的邮件。

如果大家对EDI有更多兴趣可以关注下我哦，或者访问知行EDI下载30天免费试用版哦~