Share via

Obscure Error: AddressFilter mismatch at the EndpointDispatcher

  • Article

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="https://www.w3.org/2003/05/soap-envelope" xmlns:a="https://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">https://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: https://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="https://www.w3.org/2005/08/addressing">https://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.

Comments

  • Anonymous
    March 07, 2008
    PingBack from http://msdnrss.thecoderblogs.com/2008/03/07/obscure-error-addressfilter-mismatch-at-the-endpointdispatcher/

  • Anonymous
    April 20, 2009
    Hi: I am facing a similar problem. I would like to know how you passed the  custom header metadata information to the client. The msdn  documentation you have referred to states that we need to create a custom wsdl file manually to include information on header. Now, how do I indicate the schema for the header in this wsdl file?  Even if I create custom soap header in BizTalk ( along with property schema), it is not displayed in the wcf publishing wizard. It would help if you could show that portion of your wsdl that  gives header information and also the schema about the header. Thanks in advance, Meena K

  • Anonymous
    June 05, 2012
    Thanks. This saved me a lot of time.

  • Anonymous
    March 03, 2014
    Thank you for taking the time to help others.

  • Anonymous
    July 16, 2014
    It helped me in resolving the same issue. Nice of you.

  • Anonymous
    September 25, 2014
    Thank you very much for that! Helped a lot! I was feeling so stupid in not being able to fix that issue while using SoapUI as my WS client. Adding that header worked "sweet as" ;-)