脈絡：Content Enricher 幫我們處理「接收端需要比建立端提供得更多、或不同的資料」的情況。而需要相反效果——從訊息中移除資料元素——的情況多得出乎意料。

為什麼要移除有價值的資料#

理由一：安全#

資料的請求方可能無權看到訊息所含的全部資料元素；而服務提供者可能對安全方案毫無概念，不論使用者是誰都回傳所有資料元素。

因此我們需要加一個步驟，依請求方已證實的身分移除敏感資料。

例如薪資系統可能只暴露一個「回傳某員工所有資料」的簡單介面，其中包含薪資資訊、社會安全號碼與其他敏感資訊。若你只是要建一個「回傳員工到職日」的服務，就該把所有敏感資訊從結果訊息中剔除。

理由二：簡化處理、減少網路流量#

許多流程由商業夥伴送來的訊息啟動。基於明顯的理由，我們希望與第三方的通訊建立在標準化的訊息格式上；許多標準組織與委員會為特定產業與應用定義了標準 XML 資料格式（RosettaNet、ebXML、ACORD 等等）。

這些格式對「基於協定標準與外部單位互動」很有用，但文件可能非常龐大——許多文件有數百個欄位、巢狀多層。

這種大文件很難用於內部訊息交換：多數視覺化（拖放式）轉換工具在文件有數百個元素時就變得不堪使用，除錯更是惡夢。

因此我們想簡化進站文件，只保留內部處理步驟真正需要的元素。從某種意義上說，移除元素反而增益了訊息的有用性——冗餘與不相關的欄位被拿掉，留下更有意義的訊息，也少了讓開發者犯錯的空間。

解法#

它不只是刪欄位#

Content Filter 也很適合用來簡化訊息的結構。

訊息常被表示成樹狀結構。來自外部系統或套裝應用的訊息，往往有很多層巢狀、重複的群組，因為它們是照著通用、正規化的資料庫結構建模的。

但已知的限制與假設常讓這種巢狀程度變得多餘——Content Filter 可以把階層「壓平」成一個簡單的元素清單，讓其他系統更容易理解與處理。

範例：資料庫配接器

許多整合套件提供 Channel Adapter 連接既有系統，但這些配接器發布的訊息格式往往長得像應用程式的內部結構。

假設我們把資料庫配接器接到一個資料庫。

實體資料庫 schema 把相關實體存在不同表格、以外鍵與關聯表連結（例如 ACCOUNT_CONTACT 連結 ACCOUNT 與 CONTACT），這是非常典型的作法。

許多資料庫配接器會把這些相關表格轉成階層式訊息結構，其中可能含有主鍵、外鍵這類對接收者毫無意義的欄位。

為了讓處理更容易，我們用 Content Filter 把訊息結構壓平、只抽出相關欄位——把一則橫跨多層、超過十幾個欄位的訊息，縮減成一則只有五個欄位的簡單訊息。其他元件處理起來會容易得多（也更有效率）。

Content Filter 不是這個特定問題的唯一解法。例如我們也可以在資料庫中設定一個 view 來解析表格關聯、回傳簡單的結果集——若我們有權為資料庫加 view，這會是簡單的選擇。

但許多情況下，企業整合力求盡可能不侵入，而這條準則可能就包含「不在資料庫中新增 view」。 >