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都在您的组织内，那么“安全性”不是问题，但您的应用程序仍然可以向消费者提供“外部”架构，以保护他们免受应用程序的内部更改。