把 EDI 轉換從客製程式變成可配置系統

情境

長榮的 EDI 資料交換量很大，而且涵蓋的業務非常廣。

財務、資產、POS、船務等不同系統，都有自己的資料結構與交換格式。

當時很多 EDI 作業的實作方式，是工程師逐欄撰寫轉換邏輯：

A 系統 Table A 的某個欄位 → 對應到 EDI Format 的某個欄位 → 再處理型別、格式或特殊轉換

每新增一種資料交換，就再建立一套新的 Mapping Code。

問題不只是程式碼很多。

真正麻煩的是：

大量程式其實都在重複描述「哪個欄位對應哪個欄位」這件事。

我的判斷與做法

我開始思考：

如果每一個 EDI Job 真正不同的只是欄位 Mapping，那這些差異是不是根本不需要被寫成一行一行的轉換程式？

所以我把欄位對應關係從程式流程中抽離。

利用 Java Annotation 在 Entity 欄位上描述 EDI Mapping 規則，再透過 Reflection 解析這些 metadata。

執行轉換時，由共用的 Mapping Mechanism 動態取得來源欄位與目標欄位，再完成 Get / Set 與資料轉換。

原本：

每一種 EDI → 撰寫一套專用 Mapping Code

逐漸變成：

Entity 欄位 → Annotation 描述 Mapping → Reflection 解析 → 共用轉換機制執行

新增 EDI Format 時，重點從「再寫一次轉換流程」，變成「描述這份資料如何映射」。

形成的結果

原本大量重複的欄位轉換邏輯，可以由同一套機制處理。

不同 EDI Job 真正需要維護的內容，逐漸收斂成各自的 Mapping Definition，而不是散落在大量客製程式裡。

當交換格式或欄位發生變化時，也更容易直接找到真正描述這項差異的位置。

留下的思考

這是我很早期開始形成的一個工程直覺：

如果很多程式的差異只是「資料不同」，那差異本身也許應該被描述成資料，而不是繼續複製程式。

當時我還不會把它稱為 Config-driven Architecture。

但後來回頭看，從 EDI Mapping、ERP / MES UI Pattern，到 No-code Framework，我其實一直在處理同一類問題：

把反覆變動的差異抽離，把真正穩定的規則留在系統裡。