最近在進行一個幫助國內某物流公司建立與博西（BOSCH）的EDI連接，目前基本完成了業務需求，處於數據測試階段，下面分幾個方面記錄一下此次實施的EDI項目
一、報文標準
非國際標準EDI報文
二、業務需求
shipment
Freight Note
Image
三、集成方式
API方式集成物流平臺
四、系統功能實現
物流公司和博西通過AS2連接來互相傳輸文件，基於互聯網即可實現，會對傳輸數據進行簽名加密，保障了數據安全性，且MDN Receipt可以保障傳輸具有不可否認性。
這裏解釋一下AS2的工作原理：
AS2協議是基於 HTTP （超文本傳輸協議）或其更安全的版本HTTPS 通過互聯網或任何 TCP/IP 網絡進行安全可靠的數據交換。通過使用加密和數字簽名傳輸數據封裝格式 S/MIME （安全多用途互聯網郵件擴展協議）的數據，並且使用MDN （消息處置通知）確保數據在互聯網上能夠安全可靠地傳輸。
MDN包含傳遞狀態的有關信息。使數據傳輸具有”不可否認性”
五、實施方案
下圖是知行EDI實施此項目的方案概覽圖，請參考：
Shipment 訂單
是博西發給物流公司的，這個過程通過在edi系統，即RSSBus上調用物流平臺的API接口，來將訂單發送到物流平臺的系統上，完成一次下單；
Freight Note 運單
是物流公司回給博西的，通過物流平臺調用EDI系統的API接口，EDI系統RSSBus收到Freight Note.xml文件，知行通過在rssbus上定製化開發，將xml文件轉成博西規範中需要的txt文件，發到博西EDI系統上。
Image 物流照片
和Freight Note的流程基本是一致的。
六、請求API注意事項及問題分享
請求API中需要注意的點：
1、請求json的content格式需要和請求API接口要求的格式一致，注意參數之間的層級關係；
2、根據被請求方的要求對內容加密時要注意是否要去除空字符，參數需要按照字母順序排列等；
3、當參數的value出現空值時，是否會對最終簽名造成影響；
4、注意最終簽名時根據哪些參數做md5哈希，嚴格按照接口文檔生成密鑰；
使用postman調用api接口可以參考另一篇文章：
https://blog.csdn.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瞭解更多EDI案例或是資訊，還可以免費下載EDI軟件30天試用版哦~