項目背景
醫療器械行業的發展直接受制於其供應鏈上下游的發展狀況，“上游”零組件供應商的支持佔據着重要地位。如何確保與供應鏈“上游”建立長期穩定的合作關係，對醫療器械行業的企業而言至關重要。國內某醫療器械行業客戶(以下簡稱M公司)在國內市場已有近三十年的行業經驗，在持續鉅額的研發投入之外，通過EDI技術，有效加強與“上游”供應商的合作關係。
方案簡介
近期，醫療器械行業M公司與知行軟件達成合作，在本地部署EDI系統，並與其“上游”供應商TI建立EDI連接，實現業務數據收發流程的自動化。通過EDI系統向TI下訂單，並且將負載均衡應用於本次EDI項目，實現高可用。 雙方達成的方案如下：
1.EDI 平臺部署，需考慮數據安全及高可用
2.EDI 平臺對接 TI EDI
EDI平臺部署方案
知行之橋 EDI 系統的單個實例已經能輕鬆地滿足大多數企業的自動化傳輸需求，在本次M公司EDI部署過程中，考慮到客戶日處理數據量龐大，並且具有長期的數據處理需求，我們的項目經理將把負載均衡以及高可用的共享存儲服務以及高可用數據庫服務納入本次EDI部署方案之中，從而實現更高級別的可用性和伸縮性。下圖是EDI平臺部署方案示例：
出於數據安全考慮，我們的顧問協助客戶部署了Nginx服務器。使用Nginx 作爲反向代理實現負載均衡，將所有請求平均分發到每臺部署EDI的服務器，保證了M公司內網的安全，同時減少內存佔用，提高併發能力，實現了高可用併發需求。 如上圖所示，應用程序Server1和Server2 表示部署EDI平臺的兩臺服務器，通過共享存儲服務，實現EDI平臺的配置共享，通過數據庫服務實現平臺所有交易日誌、訪問日誌的共享。
EDI 平臺部署方案達成一致後，結合 TI EDI需求，通過知行之橋EDI平臺，實現AS2通信，同時對於EDI國際標準報文格式進行轉換，通過 tRFC 連接 SAP 以 IDOC 形式將數據同步到 M 公司的SAP系統。
EDI平臺對接方案
1. 傳輸方式
通過AS2端口實現與 TI EDI的通信。
2. 報文標準
TI 支持的報文標準包括EDIFACT、X12以及RNIF。本次項目M公司選擇的是X12標準，基於TI的PO & POC模式，業務層面涉及了以下五種業務單據；
| 報文代碼 | 業務含義 | 傳輸方向 |
| 850 | 訂單 | M公司發送給TI |
| 855 | 訂單回覆 | TI發送給M公司 |
| 860 | 訂單變更 | M公司發送給TI |
| 865 | 訂單變更回覆 | TI發送給M公司 |
| 856 | 發貨通知 | TI發送給M公司 |
本次EDI項目共使用5種業務報文，如果企業還需採用JIT模式，則需要再加上830物料需求預測以及830R物料需求預測回覆等報文。
3. 數據格式轉換
將接收到的X12報文通過X12端口轉換爲EDI XML，再將得到的EDI XML通過XML Map端口進行映射，轉換爲IDoc XML。通過SAP IDoc端口連接到客戶的SAP系統，傳輸IDoc文件。
知行之橋如何連接 SAP 系統呢？可以參考文章：SAP(IDoc) 端口配置
EDI平臺對接方案概覽如下圖所示：
通過方案概覽我們可以很清晰地看到，本次EDI項目中，M公司與TI之間的EDI項目需要完成以下環節：
- M公司本地部署EDI系統
- 與TI通過AS2建立EDI連接
- M公司的EDI系統與SAP系統進行集成
- M公司的EDI系統與TI的EDI系統之間交換業務文件
項目計劃
我們的項目經理會提前根據項目的實際情況安排EDI部署流程和項目週期。通常情況下，由於對接交易夥伴以及EDI項目難易程度的不同，項目週期也各不相同。對接TI的EDI項目，通常情況下，項目週期爲兩到三個月。項目計劃明細如下圖所示：
需要注意，與TI進行業務場景測試階段，是整個EDI項目中時間佔比最大的部分。這部分需要完成上文提到的PO&POC模式或者JIT模式的測試。業務場景測試過程短則4-6周，長則需要6-8周。由於這個階段需要溝通業務場景和業務細節，因此需要進行多方參與。如果企業希望在這個環節加快項目進度，那麼需要企業及時跟進項目，多多協調配合才能確保項目高效進行。
項目回顧
在EDI項目實施過程中，爲了使業務數據更加切合企業間數據傳輸需求，我們的顧問根據M公司的需求以及TI EDI項目的特點，對本次EDI項目進行了針對性處理：
預計到貨時間和實際到貨時間不匹配
預計到貨日期與實際到貨日期之間會存在時間差，該問題不僅出現在M客戶案例中，對於其他客戶而言也可能存在這樣的問題。如果需要消除這個時間差，獲取到實際到貨日期，如何在實際項目中處理交期問題呢？有以下兩種方案：
需求日期提前
M公司在下單時可以選擇將交期提前，這樣預計到貨時間雖早，但是實際到貨時間滿足實際需求到貨時間。
預計到貨日期延遲
M公司在收到TI的發貨通知後，將預計到貨時間進行處理，加上一段在途或者從中轉倉庫運輸至實際倉庫的時間，這樣預計到貨時間就更加準確了。
數據拆分處理
儘管在EDI規範中對數據進行了嚴格的要求，但是實際情況遠遠比預期要更加複雜。比如數據拆分，應該如何處理呢？
例如，供應商傳輸的XML文件包含一批數據，例如多個訂單、多個行項目或多個客戶記錄時，想要將每個訂單/項目/記錄從這個“批量”的XML數據中拆分出來。就可以使用知行之橋的Split端口，實現XML文件劃分。實現的效果如下圖所示：
類似這樣的需求幾乎每天都在發生，我們在滿足客戶需求的同時，也在不斷地對知行之橋EDI系統的功能進行優化升級。
通過以上介紹，想必大家已經對M公司&TI的的EDI項目案例有了較爲清晰的瞭解，如果大家有任何疑問或者希望瞭解更多的EDI案例，歡迎聯繫知行軟件。