BizTalk内部和外部模式

Question

我在网上阅读所有内容，你将你的“外部模式”从你的“内部模式”中分离出来，并且不要将“内部模式”暴露给任何外部参与者。

如果我的解决方案只能作为一个消息总线来创建2个现有系统之间的松散耦合，我是否真的需要任何内部模式？

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通常用于描述在BizTalk等集成机制中创建内部架构（在上例中为SchemaInternal）。

使用经典模式被广泛认为是一个best practice，因为它能够消除任何“其他”系统的架构您的BizTalk流量控制映射（其它系统在这里可以是组织内部的或外部的，如供应商，客户或合作伙伴系统）。这样，如果任何通过BizTalk集成的系统发生更改，它只是外部模式，并映射到需要更改的规范模式。它还可以防止外部架构中固有的外部约定，命名和层次差异泄露到您的内部BizTalk文物中。

通常，传入消息到规范模式的转换尽可能早地完成，例如，在接收和类似的情况下，尽可能晚地进行标准化的转换，例如，在发送端口映射上。

典型模式（CS）的一个常见场景是单个业务流程或消息流对于多个交易方而言是共同的（例如，您可能有许多供应商使用不同的系统，但他们都提交了处理发票）。在这种情况下，每个新供应商系统都需要与您的CS集成 - 不需要添加或复制新的处理逻辑 - CS实际上可以减少此类情况下的总体工作量。 （详细解释n×m问题here）。 CS的重要性的另一个例子是您的业务是在哪里切换消息 - 例如，医疗行业转换将会有许多医生和执业系统发送授权请求和发票，这些系统需要被映射并发送到多个医疗基金（医疗援助）系统。

而且FWIW：

• IMO CS使在最有意义时的BizTalk处于EAI或ESB场景中，例如端到端解决方案直接整合2个或更多的业务系统。否则，如果BizTalk只是较大企业ESB上的一个端点，那么使用公司ESB模式内部可能是有意义的，因此将外部模式直接映射到ESB模式（即不需要另一个一组CS在BizTalk中，假设您在企业中拥有良好的变更管理/版本控制机制）。
• 如果您的行业存在标准模式（例如EDIFACT），那么采用这些模式作为内部CS是否是一个目标是没有意义的。一般而言，这些可能与Canonical的含义相冲突，因为“简单”的原因在于，为了对文档的所有风味和“边缘情况”进行建模，行业模式通常需要是冗长的。我个人会确保我有一个映射到/来自所述行业模式的映射，但会在内部使用自定义模式。

Answer 2

在描述的解决方案中，您不需要内部模式。那么你可以从系统Y的用户隐藏System X的模式，但这并不重要。

Answer 3

在这种情况下，External = Public，意思是在组织外部。

该指南旨在保护内部实施细节，命名约定等等。

如果系统A和系统B都位于您的组织内部，那么'安全'不是问题，但您的应用程序仍然可以向消费者提供'外部'模式，以保护它们免受应用程序内部更改的影响。