脈絡：在 B2B 整合情境中，企業從不同商業夥伴收到訊息是很常見的事。這些訊息可能意義相同，卻依夥伴各自的內部系統與偏好而採用不同格式。

作者曾為一家隨選付費（pay-per-view）供應商建過方案，它必須接收並處理來自超過 1700 家（!）加盟商的收視資訊，其中多數並不遵循標準格式。

為什麼不能規定統一格式#

從技術角度看，最容易的解法似乎是對所有參與者強制規定統一格式。

若企業是大型集團、且掌控 B2B 交換或供應鏈，這行得通——例如若通用汽車希望供應商以共同格式回報訂單狀態，我們可以相當確定「Joe 的小供應商」會乖乖遵循「指引」。

但許多情況下企業沒有這種奢侈。恰恰相反，許多商業模式把訊息接收方定位成資訊的「彙整者」，而與個別參與者的協議中往往包含「對他們的系統基礎設施只需做最少改動」這一條。

結果就是：彙整者得願意處理任何格式的資料——從 EDI 紀錄、逗號分隔檔，到透過 e-mail 寄來的 XML 文件或 Excel 試算表。

變動速率才是重點#

面對眾多夥伴時，一個重要考量是變動速率：不只每個參與者一開始就偏好不同的資料格式，這個偏好格式還會隨時間改變；新參與者加入、舊參與者退出。

即使某個夥伴每隔幾年才改一次格式，面對幾十個夥伴時，就可能演變成每月甚至每週都有變動。

因此必須盡可能把這些變動與系統其餘部分隔離，以免變更在整個系統中造成「漣漪效應」。

先想到的作法#

要把系統其餘部分與各式進站格式隔離，就得把進站訊息轉換成共同格式。因為進站訊息型別不同，每種格式都需要一個不同的 Message Translator。

最容易的作法是用一組 Datatype Channel——每種訊息型別一個，各自接到不同的 Message Translator。

缺點是：大量的訊息格式就意味著同樣大量的訊息通道。

解法#

Normalizer 用一個 Message Router 把進站訊息導向正確的 Message Translator。

難處：怎麼判斷訊息型別#

這要求 Message Router 能偵測進站訊息的型別。許多訊息系統為每則訊息在表頭配上型別標示欄位，讓這件事很簡單。

但在許多 B2B 情境中，訊息並不是以「符合企業內部訊息系統」的形式抵達，而是逗號分隔檔、或沒有附帶 schema 的 XML 文件這類五花八門的格式。

「為任何進站資料格式配上型別標示」當然是最佳實務，但我們都太清楚這世界遠非完美。因此得想出更通用的辨識方式：

• 無 schema 的 XML 文件——常見作法是用根元素的名稱推定型別。若多種格式共用同一個根元素，就用 XPath 運算式判斷特定子節點是否存在。
• 逗號分隔檔——需要多一點創意。有時可依欄位數量與資料型別（數值 vs. 字串）判斷。
• 以檔案形式抵達的資料——最容易的作法可能是把檔名或資料夾結構當成代用的 Datatype Channel：讓每個商業夥伴以獨特的命名慣例命名檔案，Message Router 就能依檔名把訊息導向適當的 Message Translator。

額外的好處#

加入 Message Router 也讓同一個轉換能被多個商業夥伴共用——當多個夥伴使用相同格式，或某個轉換通用到足以容納多種格式時，這很有價值。

例如 XPath 運算式非常擅長從 XML 文件中挑出元素，即使那些文件的格式有所不同。