Creating a custom SOAP adapter for BizTalk ESB Toolkit 2.0

Question

Using the BizTalk ESB Toolkit 2.0

We are working on a project where we need to call a proxy to a web service which is a DLL. We have no problems doing this via an orchestration since you can use a static port and configure it to use the SOAP adapter with the web service setting pointing at the assembly in the BizTalk Admin interface. In the itinerary though there doesn't seem to be an obvious way to do this since dynamic ports don't have the option to use the SOAP adapter.

There is a good reason why we want to do this, don't worry.

Following on from this, we implemented a custom adaptor provider but are having problems getting it to work.

We followed an (old) example shown here:

The custom adaptor provider inherits from BaseAdapterProvider and overrides the SetEndPoint(Dictionary, IBaseMessageContext) method.

The method extracts the assembly name, type name, and method name that are passed in via the resolver dictionary and then writes them to the pipeline context:

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);

and sets the transport type to soap:

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

In all other respects the adapter provider is nearly identical to the example shown in the link above, except for the obvious change from SMTP to SOAP.

The adapter provider assembly is signed, GACed, and added to the esb.config.

The adapter provider is called from an itinerary that only calls the service and then returns the response. We are testing the itinerary from the Itinerary Test Client that is shipped with the toolkit. Event logging within the custom adapter shows that the adapter code is being called. The problem is that the message is not being routed to the service proxy. The event viewer gives the following error:

The Messaging engine failed to process a message submitted by adapter:SOAP Source URL:/ESB.ItineraryServices.Response/ProcessItinerary.asmx. Details:The published message could not be routed because no subscribers were found. This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted. Please use the Biztalk Administration console to troubleshoot this failure.

Investigating the suspended service instamces in Group Overview shows two things: The values for assembly name, type name, and method name are being set correctly. The message body is missing. We have tried configuring the send and receive pipelines on the send port to be both XMLTransmit/XMLReceive and ItinerarySendPassthrough/PassthroughReceive and it makes no difference.

Is there something obvious we might have missed? Do you have to explicitly pass the message body through? If so how?

EDIT:

Following a request from the BizTalk ESB Toolkit forum I am posting screen shots of the itinerary, context and send port filters.

Itinerary, Context, Port filters.

Many thanks, Nigel.

Answer 1

Hello Nigel, first of all I'll say you are trying to over engineer the solution. Adapter development is not trivial and there are various things you need to take in to consideration. Developing and Deploying adapters are categorized as platform changes, which effects your whole environment, so if you are not familiar then your shouldn't do it. I would recommend you taking some other route. At this point I personally don't have enough insight into ESB internals, so won't be able to comment on it. At worst case you may be better off using the .NET proxy dll directly inside your orchestration (expression or message shape) rather than building an adapter. Even though its not recommended approach, still I feel its better than custom adapter approach.