将应用和解决方案从 BizTalk 服务迁移到 Azure 逻辑应用
Azure BizTalk 服务 (MABS) 已停用。 若要将 MABS 集成解决方案移动到 Azure 逻辑应用,请使用本文中的指南。
简介
BizTalk 服务由两个子服务组成:
- Microsoft BizTalk 服务混合连接
- 基于 EAI 和 EDI 网桥的集成
Azure 应用服务混合连接替代了 BizTalk 服务混合连接。 Azure 混合连接可以通过 Azure 门户利用 Azure 应用服务获得。 此服务提供了一个混合连接管理器,以用于管理现有 BizTalk 服务混合连接,以及你在门户中创建的新混合连接。
逻辑应用替代了 EAI 和 EDI 基于桥的集成,提供与 BizTalk 服务相同的所有功能以及其他功能。 此服务提供基于云规模消耗的工作流和业务流程功能,使得你可以使用浏览器或 Visual Studio 快速轻松地生成复杂的集成解决方案。
此表将 BizTalk 服务功能映射到逻辑应用。
BizTalk 服务 | 逻辑应用 | 用途 |
---|---|---|
连接器 | 连接器 | 发送和接收数据 |
桥接 | 逻辑应用 | 管道处理器 |
验证阶段 | XML 验证操作 | 针对架构验证 XML 文档 |
扩充阶段 | 数据令牌 | 将属性升级为消息或升级属性供路由决策 |
转换阶段 | 转换操作 | 将 XML 消息从一种格式转换为另一种格式 |
解码阶段 | 平面文件解码操作 | 将平面文件转换为 XML |
编码阶段 | 平面文件编码操作 | 将 XML 转换为平面文件 |
消息检查器 | Azure Functions 或 API 应用 | 在集成中运行自定义代码 |
路由操作 | 条件或切换 | 将消息路由到指定的连接器之一 |
BizTalk 服务项目
BizTalk 服务有几种类型的项目。
连接器
BizTalk 服务连接器帮助网桥发送和接收数据,包括启用了基于 HTTP 的请求/响应交互的双向网桥。 逻辑应用使用相同的术语,并且有成百上千个连接器,这些连接器通过连接到广泛的技术和服务来实现相同的目的。 例如,连接器可用于云 SaaS 和 PaaS 服务(例如 OneDrive、Office365、Dynamics CRM 及其他服务)并可通过本地数据网关用于本地系统,本地数据网关替代了 BizTalk 服务的 BizTalk 适配器服务。 BizTalk 服务中的源仅限于 FTP、SFTP 和服务总线队列或主题订阅。
默认情况下,每个网桥都有一个 HTTP 终结点,这是通过网桥的“运行时地址”和“相对地址”属性配置的。 若要通过逻辑应用实现相同结果,请使用请求和响应操作。
XML 处理和网桥
在 BizTalk 服务中,网桥类似于处理管道。 网桥可以获得从连接器接收的数据,对数据执行某些操作,然后将结果发送到另一个系统。 逻辑应用通过支持与 BizTalk 服务相同的基于管道的集成并提供其他集成模式来执行相同的操作。 在 BizTalk 服务中,XML 请求-答复网桥称为 VETER 管道,它包括执行以下任务的各个阶段:
- (V) 验证
- (E) 扩充
- (T) 转换
- (E) 扩充
- (R) 路由
下图显示了处理在请求和答复之间的拆分情况,这允许分别对请求和答复路径进行控制,例如,通过为每个路径使用不同的映射:
另外,XML 单向网桥还在处理开头和末尾添加了解码和编码阶段。 直通网桥包含单个扩充阶段。
消息处理、解码和编码
在 BizTalk 服务中,可以接收不同类型的 XML 消息,并确定所接收消息的匹配架构。 此工作是在接收处理管道的“消息类型”阶段执行的。 然后,解码阶段通过提供的架构,使用检测到的消息类型对消息进行解码。 如果架构为平面文件架构,则此阶段会将传入的平面文件转换为 XML。
逻辑应用提供类似的功能。 你使用不同的连接器触发器通过不同的协议(文件系统、FTP、HTTP,等等)接收平面文件,并使用平面文件解码操作将传入的数据转换为 XML。 无需进行任何更改即可将现有的平面文件架构直接移动到逻辑应用,然后再将架构上传到集成帐户。
验证
传入数据转换为 XML后(或者如果接收到的消息格式为 XML),将运行验证以确定消息是否符合 XSD 架构。 若要在逻辑应用中执行此任务,请使用 XML 验证操作。 无需进行任何更改即可使用 BizTalk 服务中的相同架构。
转换消息
在 BizTalk 服务中,转换阶段将一种基于 XML 的消息格式转换为另一种格式。 此工作是通过使用基于 TRFM 的映射程序来应用映射完成的。 在逻辑应用中,过程与此类似。 转换操作会从集成帐户执行映射。 主要区别是,逻辑应用中的映射是 XSLT 格式。 XSLT 能够重复使用现有 XSLT,包括为 BizTalk Server 创建的包含 functoid 的映射。
路由规则
BizTalk 服务会做出路由决策,决定由哪个终结点或连接器来发送传入的消息或数据。 可以使用路由筛选器选项从预配置的终结点中进行选择:
在 BizTalk 服务中,如果只有两个选项,则使用“条件”是用于转换 BizTalk 服务中的路由筛选器的最佳方式。 如果不止两个选项,则使用“切换”。
逻辑应用通过条件语句和 switch 语句提供更复杂的逻辑功能以及高级控制流和路由。
扩充
在 BizTalk 服务处理中,扩充阶段会向与接收的数据关联的消息上下文添加属性。
例如,通过查找数据库提升要用于路由的属性,或者通过使用 XPath 表达式来提取值。
逻辑应用将提供前面操作的所有上下文数据输出的访问权限,使复制相同的行为变得十分简单。
例如,使用 Get Row
SQL 连接操作,可从 SQL Server 数据库返回数据,并在决策操作中使用数据进行路由。
同样,触发器触发的传入服务总线队列消息的属性是可寻址的,使用 xpath 工作流定义语言表达式的 XPath 也是如此。
运行自定义代码
BizTalk 服务允许你运行在你自己的程序集中上传的自定义代码。 此功能是通过 IMessageInspector 接口实现的。 网桥中的每个阶段都包括两个属性(On Enter Inspector 和 On Exit Inspector),它们提供你创建的实现了此接口的 .NET 类型。 通过自定义代码,可以对数据执行更复杂的处理,还可以重复使用程序集中执行常见业务逻辑的现有代码。
逻辑应用提供两种主要方式来执行自定义代码:Azure Functions 和 API 应用。 可以创建 Azure Functions,也可以从逻辑应用中调用。 请参阅通过 Azure Functions 为逻辑应用添加和运行自定义代码。 使用 API 应用(Azure 应用服务的一部分)创建自己的触发器和操作。 了解有关创建用于逻辑应用的自定义 API 的详细信息。
如果程序集中有从 BizTalk 服务中调用的自定义代码,可以将此代码移到 Azure Functions,也可以使用 API 应用创建自定义 API;具体取决于要实现什么。 例如,如果代码包装了逻辑应用没有其连接器的另一个服务,则请创建 API 应用,并在逻辑应用中使用你的 API 应用提供的操作。 如果有帮助程序函数或库,则 Azure Functions 很有可能是最合适的。
EDI 处理和参与方管理
BizTalk 服务和逻辑应用包括 EDI 和 B2B 处理,并支持 AS2(适用性语句 2)、X12 和 EDIFACT。 在 BizTalk 服务中,需要在专用的跟踪和管理门户中创建 EDI 网桥以及创建或管理参与方和协议。 在逻辑应用中,此功能是通过 Enterprise Integration Pack (EIP) 实现的。 EIP 提供了用于 EDI 和 B2B 处理的集成帐户和 B2B 操作。 还可以使用集成帐户来创建和管理参与方和协议。 创建集成帐户后,可以将一个或多个逻辑应用链接到该帐户。 然后,可以使用 B2B 操作从逻辑应用访问参与方信息。 提供了以下操作:
- AS2 编码
- AS2 解码
- X12 编码
- X12 解码
- EDIFACT 编码
- EDIFACT 解码
与 BizTalk 服务不同,这些操作与传输协议无关。 因此,创建逻辑应用时,可以更加灵活地选择要使用哪个连接器来发送和接收数据。 例如,可以将电子邮件附件接收为 X12 文件,然后在逻辑应用中处理这些文件。
管理和监视
在 BizTalk 服务中,专用门户提供了跟踪功能来监视和解决问题。 逻辑应用为在 Azure门户中监视逻辑应用提供了更丰富的跟踪和监视功能,并包括一个移动应用,用于在你移动时监视项目。
高可用性
若要在 BizTalk 服务中实现高可用性 (HA),可以通过在特定区域中使用多个实例来共享处理负载。 逻辑应用提供区域中 HA 且不另外收费。
在 BizTalk 服务中,B2B 处理的区域外灾难恢复需要执行备份和还原过程。 为实现业务连续性,逻辑应用提供了跨区域主动/被动 DR 功能,这允许跨不同区域中的集成帐户来同步 B2B 数据。