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:
After adding this section to the SOAP message and submitting it to BizTalk the message was received and processed successfully.
Read the complete post at http://blogs.msdn.com/nabeelp/archive/2008/03/07/obscure-error-addressfilter-mismatch-at-the-endpointdispatcher.aspx
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。