当第 3 方系统使用 REST API 时，BizTalk Server 是不是支持通过 Azure 文件共享交换大文件？

Posted 2023-02-19

【中文标题】当第 3 方系统使用 REST API 时，BizTalk Server 是不是支持通过 Azure 文件共享交换大文件？

【英文标题】：Does BizTalk Server support exchanging large files over Azure File Shares when 3rd Party system is using the REST API?当第 3 方系统使用 REST API 时，BizTalk Server 是否支持通过 Azure 文件共享交换大文件？

【发布时间】：2019-10-09 00:41:17

【问题描述】：

"从 BizTalk Server 2016 开始，您可以连接到 Azure 文件 使用文件适配器共享。 Azure 存储帐户必须是 安装在您的 BizTalk Server 上。”

来源：https://docs.microsoft.com/en-us/biztalk/core/configure-the-file-adapter

所以乍一看，这似乎是一个受支持的事情。直到最近，我们一直在使用带有 BizTalk Server 的 Azure 文件共享，没有任何问题。但是，我们现在希望交换更大的文件（大约 2 MB）。 BizTalk Server 正在使用这些文件而没有任何错误，但该文件仅包含 NUL 字节。 （跟踪数据库中的消息大小正确，但填充了 NUL 字节）。

写入文件的系统（Azure 逻辑应用程序、Azure 存储资源管理器）出现以下错误：

  "status": 409,
  "message": "The specified resource may be in use by an SMB client.\r\nclientRequestId: 4e0085f6-4464-41b5-b529-6373fg9affb0",

如果我们尝试使用 Windows 资源管理器（因此使用 SMB 协议）将文件上传到已安装的驱动器，则 BizTalk Server 会毫无问题地拾取该文件。

因此，我怀疑当写入或使用文件的系统使用 REST API 而不是 SMB 协议时，不支持 BizTalk Server 文件适配器。

所以我的问题是：

这是对 BizTalk Server 对 Azure 文件共享的支持的警告吗？ 我们可以做些什么来完成这项工作吗？ 还是我们只需要使用不同的文件交换方式？

我们没有成功调查/尝试以下：

我在 Azure 文件存储连接器中看不到任何设置（如 由逻辑应用程序使用），这将确保文件被锁定，直到它们 写得很完整。 尝试使用文件适配器高级适配器属性“读取时重命名文件”，但没有解决问题。

【问题讨论】：

您是否尝试使用与文件接收上的文件掩码不匹配的临时文件名写入文件？

@charlie.mott ：Azure 文件存储连接器仍处于预览阶段。但是无论如何，当连接器写入文件时，您是否仔细检查了文件是否具有不同的扩展名？也许您必须让 biztalk 只提取具有特定文件扩展名的文件。您的另一个选择可能是在写入完成后让某些连接器重命名文件，因此您只选择重命名为熟悉的文件。

我知道我们可以要求第三方在完成文件写入后重命名文件。但我更愿意更改协议而不是要求第 3 方这样做。

附注Azure 文件存储连接器（由逻辑应用使用）没有重命名文件操作。 docs.microsoft.com/en-us/connectors/azurefile。我假设如果我们使用“复制文件”操作，我们会遇到同样的问题。

我们还考虑了信号文件模式 (kentweare.blogspot.com/2008/01/…)。但是，同样，我们更愿意切换到不同的协议，而不是将其构建到逻辑应用程序中并在 BizTalk 中构建自定义适配器或编排逻辑。问题仍然存在，我们能否在不构建重命名或信号文件模式逻辑的情况下让 BizTalk 与 Azure 文件共享一起使用？

【参考方案1】：

这是我们实施的解决方案，并说明了这一选择的理由。

选择的选项：我们坚持使用 Azure 文件共享并实现了信号文件模式

集成系统的逻辑应用程序将信号文件写入创建消息文件的同一文件夹中。信号文件具有相同的文件名，但扩展名为 .done。例如myfile.json.done。 在 BizTalk 解决方案中，已编写自定义管道组件来检索信号文件的相关消息文件。 注意：注意 Azure 文件连接器仍处于预览阶段。

折扣选项 1：逻辑应用使用 BizTalk Server 连接器

虽然这可行，但我热衷于在系统和 BizTalk 之间保持一层分离。这允许部署 BizTalk 应用程序，而不会导致系统端点停机。 限制 BizTalk Server 的负载均衡（限制）功能。注意：我们有一个custom file adapter 来限制文件被拾取的速率。 此选项还需要设置“本地数据网关”。

折扣选项 2：使用文件系统连接器

逻辑应用程序以 2MB 的块写入文件，然后释放对文件的锁定。这使 BizTalk 能够立即获取文件。当连接器尝试写入下一个 2MB 块时，该文件不再可用，因此失败并出现 400 状态错误“请求的操作无法完成。检查您的请求参数以确保路径 //test.json”存在于您的文件系统中。” 文件大小限制为 20MB。 本地数据网关的必需设置。注意：我们还认为现在也是介绍使用集成服务环境 (ISE) 在 vNET 中托管逻辑应用程序的好时机。想法是，这将保持网络内系统和 BizTalk 之间的文件交换。不过，目前有no ISE specific connector for the File System。

折扣选项 3：使用 SFTP 连接器

我们的预期是，使用 FTP 的逻辑应用在逻辑应用写入文件时会遇到类似的分块问题。 Azure SFTP 连接器没有重命名操作。 我们非常希望避免使用这种老化协议。 我们希望避免支持 SFTP 所需的额外基础架构和软件。

折扣选项 4：逻辑应用在写入后重命名文件

File Storage REST API 或文件连接器中没有重命名操作。只有一个复制动作。我们关心的复制是文件仍然需要时间来写入，所以同样的分块问题仍然存在。

折扣选项 5：逻辑应用使用服务总线连接器

maximum size of a message is 1MB。

折扣选项 6：使用 Azure 文件同步将文件镜像到另一个位置。

文件同步仅每 24 小时发生一次，因此不适合我们的集成需求。微软planning to build change notifications into Azure File Shares 来解决这个问题。

【参考方案2】：

查看SFTP-SSH connector。它执行总文件大小为 1 GB 或更小的消息分块，并且：Provides the Rename file action, which renames a file on the SFTP server.!!

在 ISE 环境中，您可能会利用 total file size of 5B

【参考方案3】：

Microsoft 刚刚宣布“Azure 服务总线高级层命名空间现在支持发送和接收高达 100 MB（之前为 1MB）的消息负载。”

https://azure.microsoft.com/en-us/updates/azure-service-bus-large-message-support-reaches-general-availability/ https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-premium-messaging#large-messages-support