Obscure Error: AddressFilter mismatch at the EndpointDispatcher

Nabeel Prior — Fri, 07 Mar 2008 18:20:00 GMT

While testing the WCF-WSHttp receive adapter this week I ran in this very interesting, and rather obscurely worded error:

The message with To '' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree.

The objective of this integration was to expose a service through which we would be able to receive a message from an IBM WebSphere Message Broker implementation initially. The intention was that other applications and back-end systems would also be able to utilise this service at a later stage. It had therefore been decided way back in the design stage of the project that we would accomplish this by using the SOAP 1.2 protocol for receiving messages into BizTalk. To implement this on the BizTalk side we published the schema for the message we were expecting as a WCF service, and created the matching receive location. My first mistake was that I thought we could use the WCF-BasicHttp adapter, as the only requirement was that the service needed to adhere to the WS-BasicProfile standard. What I did not know at the time was that the BasicHttp adapter only supports SOAP 1.1, and to use SOAP 1.2 you have to use the WCF-WSHttp adapter.

After using the command line utility discussed in a previous post to recreate the service and update the receive location, I figured everything would be ready and I started to test the service via SOAP 1.2 again. That was when this rather obscure error was returned in the SOAP response. The actual response looked something like this:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
   <s:Header>
      <a:Action s:mustUnderstand="1">http://www.w3.org/2005/08/addressing/soap/fault</a:Action>
   </s:Header>
   <s:Body>
      <s:Fault>
         <s:Code>
            <s:Value>s:Sender</s:Value>
            <s:Subcode>
               <s:Value>a:DestinationUnreachable</s:Value>
            </s:Subcode>
         </s:Code>
         <s:Reason>
            <s:Text xml:lang="en-ZA">The message with To '' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree.</s:Text>
         </s:Reason>
      </s:Fault>
   </s:Body>
</s:Envelope>

After scouring the web for an explanation I came across a number of articles that discussed WCF coding changes and endpoint behaviour changes that would remedy the error. The only problem with that is that we do not have access to making code changes, and changing the endpoint behaviour did not make sense either. I also wanted to stay away from implementing custom WCF bindings, as this is supposed to be "out-of-the-box" functionality.

Eventually I came across this article: http://msdn2.microsoft.com/en-us/library/bb246105.aspx, which focuses on using incoming SOAP headers, and I noticed the "To" element within the SOAP Header section. With a little more reading and surfing I came to realise that the WSHttp adapter utilises the WS-Addressing standard to identify the receive location to which the message needs to be submitted. With this knowledge in hand I added the following section to the SOAP message I was sending to BizTalk:

<soap:Header>
<To soap:mustUnderstand="1" xmlns="http://www.w3.org/2005/08/addressing">http://server1/virtualDir/MyService.svc</To>
</soap:Header>

The addressing namespace can, of course go into the "Envelope" declaration of the SOAP message, but for simplicity sake I am reflecting it as shown here.

The URI that is put into the To element is essentially the URI used to get to the service in the first place. A few interesting observations about this URI:

The value of the server name portion of the URI ("server1" in the snippet above) is immaterial.
The portion of the URI after the server name, up to and including the ".svc" must match the URI in your receive location.

After adding this section to the SOAP message and submitting it to BizTalk the message was received and processed successfully.

Switching a Published WCF Service between WSHttp and BasicHttp

Nabeel Prior — Tue, 26 Feb 2008 21:48:00 GMT

When using the BizTalk WCF Service Publishing Wizard to create WCF services a number of files and directories are created in the stipulated virtual directory folder. The directory structure created is shown below, with a brief statement as to what is in each directory:

Root Directory: contains the .svc files for each service that has been published, and the web.config file.

The App_Data directory contains the schemas for those services that have been published.

The Temp sub-directory contains the binding file for the services and the WcfServiceDescription.xml file, which contains the various properties entered into the WCF Publishing Wizard.

At a customer recently there was a requirement to take these published services and change them from using the WCF-WSHttp adapter to using the WCF-BasicHttp adapter. One option was to republish the WCF services, but this was quickly discarded as there were a large number of services. As BizTalk does not include a command line version of the WCF Publishing Wizard in the installation the customer was in the process of developing their own WCF publishing service, using the WcfServiceDescription.xml file located in the Temp directory. After pointing out to them the availability of an existing command line utility, as docmented at http://technet.microsoft.com/en-us/library/bb245933.aspx, they decided to use this instead. Using the command line tool, and by setting the "AdapterName" argument to "WCF-BasicHttp", they were able to very quickly then republish their endpoints and change all their receive locations to use the WCF-BasicHttp adapter.

There are a few things to be aware of when using this command-line utility, however:

The first argument for the utility is "PathName", which is required to be the "Path and file name of the BizTalk assembly (*.dll) or the WCF service description (*.xml) file". If you are using the utility to publish an orchestration then the path to the BizTalk assembly can be used, but if you are publishing schemas using the path to the BizTalk assembly will result in the utility completing successfully, but there will be no .svc files in the root of the directory, and there will be no schema files in the App_Data directory. When publishing a schema as a WCF end-point you will need to use the path to the WCF service description file, which is the WcfServiceDescription.xml file found in the Temp directory of a published WCF end-point.
As the utility overwrites the contents of the virtual directory, when the -Overwrite argument is used, any changes you made to the web.config file will be lost. So, don't forget to add the <trust level="Full" /> text just before the </system.web> text in the web.config file after the utility has completed its execution.

This tool is available for download from: http://go.microsoft.com/fwlink/?LinkId=92955, and the documentation for it is located at: http://technet.microsoft.com/en-us/library/bb245933.aspx.

BizTalk lessons from the field : WCF

Obscure Error: AddressFilter mismatch at the EndpointDispatcher

Switching a Published WCF Service between WSHttp and BasicHttp