问题标签 [biztalk-wcf]

如果我想从编排中调用 Web 服务或 wcf 方法，我可以通过向项目添加服务引用或添加生成的项来实现。这两种方法的优点是什么 - 是否有最佳实践？

我在 BizTalk 中使用该服务并使用它创建了一个架构。使用该架构，我做了一些映射和映射的 XML 输出，我发送到 WCF 服务。从地图中，我在 XML 中正确获取要发送到 WCF 服务的值。但是在 WCF 服务请求对象中，我得到一些字段 NULL。

如果有人对此问题有解决方案，请帮助我。由于这个问题，我被困住了。

在一个业务流程 (BizTalk 2010) 中，我们收到一条 xml 消息，根据架构验证消息，并执行 schematron（内容）验证。我们的编排通过 WCF 服务公开。我们的验证例程能够捕获所有验证错误，我们希望通过包含所有验证错误的 soap 错误返回这些错误。此外，我们希望编排正常完成，即使在验证错误的情况下（没有挂起的消息）。我们怎样才能做到这一点？

我试图在我的 BizTalk 业务流程中使用已经编写的 WCF 服务。但是在配置消费的端口和端口类型时，发现 Visual Studio 中的“WCF 服务消费向导”提供 HTTP 传输类型作为唯一选项，并且没有 WCF-BasicHttp/WCF-WSHttp 传输类型选项可用。

但是，我们始终可以通过从 BizTalk 管理控制台导入所需的绑定文件来进行所需的 WCF-BasicHttp/WCF-WSHttp 设置，开发人员是否可以通过编程方式从 Visual Studio 内部执行相同操作（而不是指定那些稍后从管理控制台绑定）？

我目前需要配置一个动态发送端口来连接不符合 WS-I Basic Profile v1.1 的 ASMX Web 服务。具体来说，R9981 声明“一个信封必须恰好有 0 个或一个 soap:Body 元素的子元素。 ”我正在使用的 Web 服务期望一个具有多个元素的主体，导致 SOAP 主体看起来像：

我曾尝试同时使用 WCF-BasicHttp 和 WCF-Custom 适配器，但均未成功。似乎 BizTalk WCF 适配器无法处理具有多个元素的 SOAP 主体。

在接收位置，我使用模板将消息包装在一个元素下，以解决消息通过 BizTalk 传输的问题，我认为我可以使用自定义发送管道/自定义组件简单地拦截消息以去除包装元素。然后我尝试了一个带有消息检查器的自定义行为扩展，但这仍然发生在 BizTalk 的 WCF“BizTalkBodyWriter”工作之前。

因为我使用的是 ESB 2.1 工具包，所以我不能使用 HTTP 适配器从头开始创建我的 SOAP 消息。我最后的想法是我需要创建一个自定义 WCF LOB 适配器，但在我走这条路之前，我想确保我不会在这里让事情变得过于复杂，并且没有一个我刚刚忽略的简单方法。

我试图让 BizTalk 代理与 WCF 服务的通信，该服务将其一些数据映射到响应消息的标头而不是正文部分。经过研究，解决方案是将标头数据写入 OutboundCustomHeaders 消息上下文属性，然后 BizTalk WCF 适配器将其注入到传出消息中。在我使用证书启用消息级安全性之前，这非常有效。在这种情况下，标头仍然包含在响应消息中，但在消息被加密之后。这会导致接收客户端抛出 MessageSecurityException 消息“所需消息部分未加密”。

有没有办法将 BizTalk 配置为在加密发生之前写入 OutboundCustomHeaders 或以另一种方式在响应中注入我的标头？

我不确定它有多大帮助或使答案复杂化，但 BizTalk 中的接收位置使用 ws2007HttpRelayBinding 为客户端连接创建 Azure 端点。

我需要使用 BizTalk 调用具有多个参数的 Web 服务。使用 SOAP 适配器，我可以发送多部分消息（每个参数一个部分）。但是，我想改用 WCF-BasicHttp 适配器，因为 SOAP 适配器自 BizTalk 2009 以来已被弃用。

从各种来源，我看到 WCF 适配器不支持调用多参数操作（例如参见http://seroter.wordpress.com/biztalk-and-wcf-part-v-publishing-operations-patterns中的场景 4 / )

有没有办法解决这个限制，例如通过开发自定义管道组件？

我有一个使用两种方式 WCF-BasicHttp 发送端口调用 WCF 服务的编排。出于测试目的，我的 WCF 服务只接受一个参数，并返回一个值，因此我知道它没有任何耗时的逻辑。事实上，使用 WCFTestClient 客户端工具，我知道 WCF 服务调用只需几毫秒。

当我在编排中调用 WCF 服务时，发送形状大约需要 7 秒左右，而接收形状大约相同。因此，例如，在我的编排中花费的时间可能是 15 秒，而 wcf 服务的发送和接收形状占据了其中的 90 多秒。

我唯一能想到的是我主机上的轮询设置不正常。我有 3 台主机，1 台用于发送端口，1 台用于接收端口，1 台用于编排。每个都配置有默认配置。

此外，我对发送端口的打开、发送和关闭超时设置分别为 5,4 和 3 秒。这两个操作都没有超时，我相信问题不在于 wcf 服务本身，而在于 BizTalk 或我的 BizTalk 解决方案。

在下图中，请注意 sndGetDemographics 和 recGetDemographicsResponse 每个都需要大约 7 秒才能完成：

我有一个非关键/可选的 WCF 发送端口，它在正常操作期间很有用，但需要在一定的消息吞吐量下自动禁用。当连接的系统执行数据加载（每小时 100 000 条消息或更多）时，就会出现这种高容量。不应保留或处理来自大量时间的消息，而应完全丢弃。一旦音量降至阈值水平以下，发送端口应恢复处理/发送消息。该应用程序不使用编排。到目前为止，我唯一的想法是使用自定义管道组件和类似 redis 的东西来跟踪吞吐量，然后基于此删除或发送消息。这似乎不是一个很好的hack。

我的问题是：使用 WCF 适配器（或其他东西）是否有一种简单的方法可以根据当前的消息吞吐量删除或发送消息？