为 BizTalk ESB Toolkit 2.0 创建自定义 SOAP 适配器

Question

使用 BizTalk ESB Toolkit 2.0

我们正在开发一个项目，需要调用 Web 服务的代理（DLL）。 我们通过编排执行此操作没有任何问题，因为您可以使用静态端口并将其配置为使用 SOAP 适配器以及指向 BizTalk Admin 界面中的程序集的 Web 服务设置。 但在行程中，似乎没有明显的方法可以做到这一点，因为动态端口没有使用 SOAP 适配器的选项。

我们这样做是有充分理由的，不用担心。

接下来，我们实现了一个自定义适配器提供程序，但在使其正常工作时遇到了问题。

我们遵循了一个（旧）示例 这里：

自定义适配器提供程序继承自 BaseAdapterProvider 并重写 SetEndPoint(Dictionary, IBaseMessageContext) 方法。

该方法提取通过解析器字典传入的程序集名称、类型名称和方法名称，然后将它们写入管道上下文：

pipelineContext.Write("TypeName", 
    "http://schemas.microsoft.com/BizTalk/2003/soap-properties", typeName);
pipelineContext.Write("MethodName", 
   "http://schemas.microsoft.com/BizTalk/2003/soap-properties", action);
pipelineContext.Write("AssemblyName", 
    "http://schemas.microsoft.com/BizTalk/2003/soap-properties", assembly);

并将传输类型设置为soap：

pipelineContext.Write("TransportType",
    "http://schemas.microsoft.biztalk.practices.esb.com/itinerary", "SOAP");

在所有其他方面，适配器提供程序几乎与上面链接中显示的示例，除了从 SMTP 到 SOAP 的明显更改之外。

适配器提供程序程序集经过签名、GAC 处理并添加到 esb.config 中。

适配器提供程序是从仅调用服务然后返回响应的行程中调用的。 我们正在通过工具包附带的行程测试客户端测试行程。 自定义适配器内的事件日志记录显示适配器代码正在被调用。 问题是消息没有被路由到服务代理。 事件查看器给出以下错误：

消息引擎无法处理 适配器提交的消息：SOAP 来源 URL：/ESB.ItineraryServices.Response/ProcessItinerary.asmx。 详情：发布的消息可以 由于没有订阅者而不会被路由 被发现。 如果出现此错误 订阅编排或发送端口 尚未入伍，或者如果其中一些 所需的消息属性 订阅评价尚未 晋升。 请使用 Biztalk 用于故障排除的管理控制台 这次失败。

调查“组概览”中暂停的服务实例可以发现两件事： 程序集名称、类型名称和方法名称的值设置正确。 消息正文丢失。 我们尝试将发送端口上的发送和接收管道配置为 XMLTransmit/XMLReceive 和 ItinerarySendPassthrough/PassthroughReceive，但没有什么区别。

有什么明显的我们可能错过的事情吗？ 您是否必须显式传递消息正文？ 如果是这样怎么办？

编辑：

遵循 来自 BizTalk ESB Toolkit 论坛的请求 我正在发布行程、上下文和发送端口过滤器的屏幕截图。

行程, 上下文， 端口过滤器。

非常感谢，奈杰尔。

Answer 1

首先，我会说你试图过度设计解决方案。 适配器开发并不是一件小事，您需要考虑很多事情。 开发和部署适配器被归类为平台更改，这会影响您的整个环境，因此如果您不熟悉，则不应该这样做。 我建议您采取其他路线。 目前我个人对 ESB 内部结构还没有足够的了解，因此无法对此发表评论。 在最坏的情况下，您最好直接在编排（表达式或消息形状）中使用 .NET 代理 dll，而不是构建适配器。 尽管不推荐这种方法，但我仍然觉得它比自定义适配器方法更好。

Answer 2

从语义上讲，我不明白为什么涉及 WCF-BasicHtpp 适配器的解决方案在您的场景中不起作用。 无论如何，我肯定会尝试看看使用 WCF-BasicHttp 适配器会发生什么，一旦我获得了可行的解决方案，如果确实有必要，我会切换到自定义 SOAP 适配器。

目前，您的解决方案很奇怪 - 从某种意义上说，您有一个直接连接到出口匝道的入口匝道。 我在我的任何行程中都从未见过这种情况。 您可能需要在两者之间创建中间消息传递或编排行程服务。

否则，消息会有效地发布到消息框，并且显然没有订阅者，因此您会遇到错误。