BizTalk 2016 在导入特定绑定文件时挂起
BizTalk 2016 hangs while importing a specific bindings file
一位同事让我查看在我们的 CI 代理之一上构建的失败 BizTalk 应用程序。长话短说，在导出 .MSI 文件后，部署脚本会尝试导入应用程序的绑定文件。它只旋转了一个小时，然后出现以下错误：
Error: Failed to update binding information.
Exception of type ||'Microsoft.BizTalk.CachingService.NotificationFailedException||' was thrown.
脚本通过以下方式使用 BizTalk PowerShell 管理单元：
Add-PSSnapin –Name BizTalkFactory.PowerShell.Extensions
上面给出错误的行是：
Import-Bindings -Path "BTS:\Applications$AppToDeploy" -Source "$bindingsFileName"
就 CI 管道而言，这是一个新的应用程序。我已经在我的本地和另一台开发 BizTalk 机器上尝试了 运行 相同的脚本，并且它可以顺利导入。
还尝试使用 BizTalk 管理控制台手动导入绑定 xml 文件。它也挂在 CI 框上，但在开发机器上工作正常。
当它挂起时，如果您查看 SQL（托管在同一台机器上），就会发现进程被阻塞。导致阻塞的进程没有进行任何更新，所以我假设它是某种 DTC 锁。 BizTalk 中没有加载其他活动 SQL 用户或应用程序。 CPU 处于空闲状态，内存为 20%，磁盘 activity 已完全耗尽。
看起来像是这个新应用程序的 CI 代理机器特有的东西，只是不知道下一步该去哪里。 BizTalk 是否有任何我可以启用的日志或跟踪以查看绑定导入卡住的位置和原因？
P.S。为其他现有应用程序导入绑定工作正常。如果我将绑定文件中唯一编排的程序集版本更改为无效版本，导入运行正常，但显然应用程序无法运行，因为该程序集不存在。
终于！多亏了 Dijkgraaf 的一些发人深省的想法，让它开始工作。
简短版：在 CI 框上启动 SQL 代理。
事实证明，我们在绑定文件中的 Orchestration 上有以下跟踪选项：
TrackingOption="ServiceStartEnd MessageSendReceive InboundMessageBody OutboundMessageBody OrchestrationEvents TrackPropertiesForIncomingMessages TrackPropertiesForOutgoingMessages"
如果此列表被提炼为：
TrackingOption="ServiceStartEnd MessageSendReceive OrchestrationEvents"
...导入会起作用。这让我想到这是一个跟踪基础设施问题，促使我检查执行维护的 SQL 代理作业。因为它是 CI 代理并且没有任何实际使用 BizTalk 的功能，所以没有人关心检查 BizTalk 的健康状况。
启动代理并让作业完成它们的工作后，原始绑定文件的导入就像做梦一样。
希望这对某人有所帮助。
一位同事让我查看在我们的 CI 代理之一上构建的失败 BizTalk 应用程序。长话短说，在导出 .MSI 文件后，部署脚本会尝试导入应用程序的绑定文件。它只旋转了一个小时，然后出现以下错误：
Error: Failed to update binding information. Exception of type ||'Microsoft.BizTalk.CachingService.NotificationFailedException||' was thrown.
脚本通过以下方式使用 BizTalk PowerShell 管理单元：
Add-PSSnapin –Name BizTalkFactory.PowerShell.Extensions
上面给出错误的行是：
Import-Bindings -Path "BTS:\Applications$AppToDeploy" -Source "$bindingsFileName"
就 CI 管道而言，这是一个新的应用程序。我已经在我的本地和另一台开发 BizTalk 机器上尝试了 运行 相同的脚本，并且它可以顺利导入。
还尝试使用 BizTalk 管理控制台手动导入绑定 xml 文件。它也挂在 CI 框上，但在开发机器上工作正常。
当它挂起时，如果您查看 SQL（托管在同一台机器上），就会发现进程被阻塞。导致阻塞的进程没有进行任何更新，所以我假设它是某种 DTC 锁。 BizTalk 中没有加载其他活动 SQL 用户或应用程序。 CPU 处于空闲状态，内存为 20%，磁盘 activity 已完全耗尽。
看起来像是这个新应用程序的 CI 代理机器特有的东西，只是不知道下一步该去哪里。 BizTalk 是否有任何我可以启用的日志或跟踪以查看绑定导入卡住的位置和原因？
P.S。为其他现有应用程序导入绑定工作正常。如果我将绑定文件中唯一编排的程序集版本更改为无效版本，导入运行正常，但显然应用程序无法运行，因为该程序集不存在。
终于！多亏了 Dijkgraaf 的一些发人深省的想法，让它开始工作。
简短版：在 CI 框上启动 SQL 代理。
事实证明，我们在绑定文件中的 Orchestration 上有以下跟踪选项：
TrackingOption="ServiceStartEnd MessageSendReceive InboundMessageBody OutboundMessageBody OrchestrationEvents TrackPropertiesForIncomingMessages TrackPropertiesForOutgoingMessages"
如果此列表被提炼为：
TrackingOption="ServiceStartEnd MessageSendReceive OrchestrationEvents"
...导入会起作用。这让我想到这是一个跟踪基础设施问题，促使我检查执行维护的 SQL 代理作业。因为它是 CI 代理并且没有任何实际使用 BizTalk 的功能，所以没有人关心检查 BizTalk 的健康状况。
启动代理并让作业完成它们的工作后，原始绑定文件的导入就像做梦一样。
希望这对某人有所帮助。