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 - ＆gt; SchemaInternal - ＆gt; SchemaB

Answer 1

术语canonical schema通常用于描述内部模式（在上一个示例中为SchemaInternal）到BizTalk等集成机制的创建。

规范模式的使用被广泛认为是best practice，因为它将您的BizTalk流控制映射与任何“其他”系统的模式分离（此处的其他系统可能在您的组织内部或在其外部，例如供应商，客户或合作伙伴系统）。这样，如果通过BizTalk集成的任何系统发生变化，它只是外部模式，并映射到需要更改的规范模式。它还可以防止外部模式中固有的外部约定，命名和层次结构差异泄漏到您的内部BizTalk伪像中。

通常，尽可能早地将传入消息转换为规范模式，例如，在接收上，类似地，尽可能晚地完成规范的转换，例如：在发送端口地图上。

Canonical Schemas（CS）的一个常见场景是单个业务流程或消息流对多个交易方来说是共同的（例如，您可能有许多供应商使用不同的系统，但是，所有供应商都提交了处理发票）。在这种情况下，每个新的供应商系统只需要与您的CS集成 - 不需要添加或复制新的处理逻辑 - CS实际上可以减少此类情况下的总体工作量。 （n {m}问题详细解释here）。 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

在此上下文中，External = Public，意味着在您的组织之外。

该指南旨在保护其他人的内部实施细节，命名惯例等。

如果系统A和系统B都在您的组织内，那么“安全性”不是问题，但您的应用程序仍然可以向消费者提供“外部”架构，以保护他们免受应用程序的内部更改。