BizTalk內部和外部架構

Question

我正在網上閱讀你將你的“外部模式”與你的“內部模式”分開，並且永遠不會將“內部模式”暴露給任何外部參與者。

如果我的解決方案僅作為消息總線在兩個現有系統之間創建松散耦合，那么我真的需要任何內部模式嗎？

System A makes a Request(Message with SchemaA) to Biztalk

Biztalk Maps SchemaA to SchemaB 

Biztalk forwards request of type SchemaB to SystemB

SystemB returns ResponseB 

Biztalk maps ResponeB to ResponeA

Biztalk routes the result back to System A

我看不到擁有內部架構和地圖的專業人士：

SchemaA - > SchemaInternal - > SchemaB

？

Answer 1

術語canonical schema通常用於描述內部模式（在上一個示例中為SchemaInternal ）到BizTalk等集成機制的創建。

規范模式的使用被廣泛認為是最佳實踐 ，因為它將您的BizTalk流控制映射與任何“其他”系統模式分離（此處的其他系統可能在您的組織內部或在其外部，例如供應商，客戶或合作伙伴系統）。 這樣，如果通過BizTalk集成的任何系統發生變化，它只是外部模式，並映射到需要更改的規范模式。 它還可以防止外部模式中固有的外部約定，命名和層次結構差異泄漏到您的內部BizTalk工件中。

通常，傳入消息到規范模式的轉換盡可能早地完成，例如在接收上，並且類似地，盡可能晚地完成規范的轉換，例如在發送端口映射上。

Canonical Schemas（CS）的一個常見場景是單個編排或消息流對於多個交易方是共同的（例如，您可能有許多供應商使用不同的系統，但是，所有供應商都提交了處理發票）。 在這種情況下，每個新的供應商系統只需要與您的CS集成 - 不需要添加或復制新的處理邏輯 - CS實際上可以減少此類情況下的總體工作量。 （ 這里詳細解釋了nxm問題）。 CS至關重要的另一個例子是您的業務切換消息 - 例如，醫療行業轉換將有許多醫生和實踐系統發送授權請求和發票，這些需要映射並路由到多個醫療基金（醫療援助）系統。

和FWIW：

• 當BizTalk是EAI或ESB場景中的終端解決方案時，IMO CS最有意義，例如直接集成2個或更多業務系統。 否則，如果BizTalk只是大型企業ESB上的一個端點，那么在內部使用公司ESB模式可能是有意義的，因此將外部模式直接映射到ESB模式（即，不需要在BizTalk中提供另一組CS，提供您在整個企業中擁有良好的變更管理/版本控制機制。
• 如果您的行業存在標准模式（例如EDIFACT ），那么采用這些模式作為內部CS的目標是沒有意義的。 一般來說，這些可能與Canonical的含義相沖突是“簡單”，因為行業模式通常需要冗長才能模擬文檔的所有風格和“邊緣情況”。 我個人會確保我有一個映射到/來自所述行業模式，但會在內部使用自定義模式。

Answer 2

在描述的解決方案中，您不需要內部模式。 那么你可以從System Y的用戶那里隱藏System X的模式，但這並不是那么重要。

Answer 3

在這種情況下，外部=公共，意味着在您的組織之外。

該指南旨在保護內部實施細節，命名約定等。

如果系統A和系統B都在您的組織內，那么“安全性”不是問題，但您的應用程序仍然可以向消費者提供“外部”架構，以保護他們免受應用程序的內部更改。