问题标签 [biztalk-2016]

我在 VSTS 中有 Biz Talk 项目，我正在尝试构建该项目。这是我面临的错误

请在附件中找到我的构建定义

我发现我的本地 [C:\Program Files (x86)\MSBuild\Microsoft\BizTalk] 构建参数中存在所述目标文件：

请帮助/建议

BizTalk RosettaNet 加速器链接讨论了它在 BizTalk server 2013 中的支持。BizTalk server 2016 是否支持 Rosetta net 加速器？

我尝试将 BizTalk 2016 连接到 Azure 应用程序洞察力。

我将仪器密钥从 Azure 复制粘贴到组设置，但是当我单击“确定”时，出现下一个错误

我需要通过 BizTalk 发送适配器调用休息 API 服务。API 仅使用标头中的令牌进行身份验证/授权。我已经使用 httpclient 在 C# 控制台应用程序中对此进行了测试，它工作正常：

但是我想使用 BizTalk 拨打电话并处理响应。

我尝试使用 wcf-http 适配器，为安全选择“传输”（它是一个 https 站点，因此需要安全性（？）），没有指定凭据类型，并将带有令牌的标头放在“消息”选项卡中适配器配置。这失败了，但出现以下异常：System.IO.IOException：身份验证失败，因为远程方已关闭传输流。

我已经尝试在谷歌上搜索这个特定的场景，但找不到解决方案。我确实找到了这篇文章，其中包含有关 OAUth 处理的建议，但令我惊讶的是，即使使用 BizTalk 2016，我仍然必须为如此简单的事情创建自定义程序集。

有谁知道如何在 wcf-http 发送适配器中做到这一点？

我们要求在所有服务器上使用 TLS1.2。这意味着使用下面的注册表设置强制 TLS1.2 系统范围。当我设置这些设置并重新启动服务器时，我在 BizTalk Administrator 中展开 BizTalk Group 菜单时收到以下错误消息。在这个特定的环境中，一切都在一个操作系统/服务器上运行。请记住，如果我在注册表中启用 TLS1.0，一切正常。

我已经阅读了几篇文章，指出自从 .NET 4.5 以来，支持 TLS1.1/1.2 所以......这里有什么问题？

操作系统：Windows Server 2016 SQL 版本：SQL Server 2016 BizTalk 版本：BizTalk Enterprise 2016 CU3 .NET 版本 4.7

我需要从中提取一个 REST API，每个响应都有 100 条记录限制（总共 300k+ 条记录）。我正在尝试考虑通过 BizTalk 适配器进行分页/迭代的最佳实践是什么。仅供参考，这很复杂，因为我有 10 个左右的端点需要翻页并且必须使用自定义管道（因为 JSON 响应是唯一可用的类型，所以每个端点都转换为 XML 并指定命名空间）。

我的主要问题是如何有效地管理分页和多个端点。页码和偏移量在 JSON 响应中，所以我的第一个猜测是我必须构建一个编排来分析响应并从中创建新请求。我知道有很多方法可以做到这一点，所以我很好奇最佳实践要求什么以及最有效的方法是什么。

• 我能以某种方式摆脱不使用编排吗？
• 我可以/应该使用动态发送端口吗？

我要做的是为我未来开发的所有应用程序建立一个解耦/灵活的框架/策略，其中包括尽可能多的“重用”。最好我最终希望拥有一个单一的编排，我可以“插入”到任何其他编排中，该编排将接收消息并发送到发送适配器并将响应返回给调用编排（已转换根据向适配器构造的消息动态接收到对 XML 的响应）。这将需要能够在编排中的消息上设置接收管道。

我在正确的轨道上吗？关于在 BizTalk 中重复使用工件的最佳实践，我找不到太多。

我有一个快速的问题。

目前在我的工作中，我们正在尝试实施一个利用 Microsoft Logic Apps 的新项目。逻辑应用实现 BizTalk functoids 用于映射目的，任何熟悉逻辑应用的人都知道。目前虽然我们遇到了 BizTalk functoids 的问题。

functoids 未显示在工具箱中。我们尝试安装任何可能丢失的软件包，我们尝试修复工具箱和 Visual Studio IDE。我们甚至尝试卸载并重新安装 Visual Studio IDE 本身，但没有使 Visual Studio functoid 控件在工具箱区域中可见。

重置工具箱没有产生任何结果，也没有尝试使用选择项来定位 functoid 控件 .dll 文件。有没有我们遗漏的步骤，以前有没有人遇到过这个问题，如果有，您是如何解决的？在我们可以加载 BizTalk functoid 控件之前，我们将陷入困境。

根据此BizTalk 文档，HTTP 接收适配器必须位于应用程序（中间）层。这意味着 BizTalk 仅限于 2 层架构，这对于现代企业来说是一个很大的限制。

微软推荐的反向代理建议（在上面的链接上）是这个问题的常见解决方案吗？是否有人使用任何其他配置来使用 Web/外围层中的 HTTP 接收适配器并能够通过应用程序层协商消息？

如果使用反向代理方法，是使用企业中现有的代理还是为解决方案配置了专用代理？

我们在 SQL Server 2016 AlwaysOn 上运行 BizTalk 2016。

SQL Server 代理作业MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb正在做它的事情，但几个小时后它失败了。有时 10 小时有时 90 小时或介于两者之间的任何时间。我知道，该作业旨在永远运行，并且在出现错误的情况下会在一分钟内自行重新启动。但我想知道这个失败的工作的实际错误信息。作业历史记录没有帮助，因为作业日志条目被截断。

没有发生故障转移。问题是：为什么这项工作会失败，最终：我如何阻止它这样做？

我已经设置了对失败步骤的扩展监控，它显示该作业由于死锁而失败，并且它被选为死锁受害者。那么现在的问题是，为什么会出现死锁？MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb以死锁问题而闻名？