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

【问题标题】：Creating a custom SOAP adapter for BizTalk ESB Toolkit 2.0为 BizTalk ESB Toolkit 2.0 创建自定义 SOAP 适配器
【发布时间】：2010-11-13 19:08:08
【问题描述】：

使用 BizTalk ESB 工具包 2.0

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

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

在此之后，我们实现了一个自定义适配器提供程序，但在使其工作时遇到了问题。

我们遵循here 所示的（旧）示例：

自定义适配器提供程序继承自 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 资源网址：/ESB.ItineraryServices.Response/ProcessItinerary.asmx。详细信息：发布的消息可以没有被路由，因为没有订阅者被发现。如果出现此错误订阅编排或发送端口尚未入伍，或者如果某些所需的消息属性订阅评估尚未晋升。请使用 Biztalk 用于故障排除的管理控制台这次失败。

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

我们可能遗漏了什么明显的东西吗？您是否必须明确传递消息正文？如果有怎么办？

编辑：

在request from the BizTalk ESB Toolkit forum 之后，我发布了行程、上下文和发送端口过滤器的屏幕截图。

Itinerary, Context, Port filters.

非常感谢，奈杰尔。

【问题讨论】：

我会首先尝试进入你的适配器代码，看看那里到底发生了什么，看看你是否首先获得了消息数据。

标签： biztalk esb esb-toolkit-2.0

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

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

【讨论】：

感谢您的回复；我们还按照您的建议从编排中调用代理。然而，我们仍然希望采用这种方法。是的，我同意这远非微不足道:)。