a:ActionNotSupported
  The message with Action '<BtsActionMapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Operation Name="Method1" Action="http://tempuri.org/Ib2b/Method1" />
  <Operation Name="Method2" Action="http://tempuri.org/Ib2b/Method2" />
  <...' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver.  Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

To further complicate matters, the orchestration that I inherited took the above message and loaded into XML, which failed with this message: {“‘<‘, hexadecimal value 0x3C, is an invalid attribute character. Line 8, position 501.”} (The line/position numbers may be different, because I changed the sample above). The basic issue is that BizTalk, when building the message, built some invalid XML in the faultstring. In my case, I had a lot more methods, and they were truncated in the middle of an attribute. So the XML parser never found the close of the attribute “Action=”, and when it found the next < sign, it decided that was an invalid character in an attribute.

One quick possibility is that you might be pointing to the wrong service (i.e. your orchestration is bound to the wrong endpoint). Or the web service you are calling has a method removed or renamed (and perhaps they didn’t communicate that with you).

When you call a web service method (also known as “Operation”), you specify the operation name in the second box of the logical send port; for example “Method3” in the Port_Demo below. In the main part of the orchestration, there is a send and receive shape tied to this port.

(Note: when you create a new logical port in the orchestration, the method name will default to “Operation_1”, and you will need to change that to one of your method (operation) names.

I’m going to mention some basic here in case you are new to BizTalk:
1) The orchestration is deployed and the you find it under it’s Application in BizTalk Admin Console.
2) In BizTalk Admin, the orchestration logical (internal) ports need to be bound to SendPorts defined in BizTalk Administration. One of those SendPorts will be a webservice for this example.
3) In that web service SendPort, if you click Configure, then on the “General” tab there will be a section called “Action”. The value will look something like this, depending on your method names and namespaces.

 

So if you try to call Method3, which is non-existent in the webservice specified in the SendPort, you will get this error (or a similar one). It could be that someone changed the webservice, and you need to rebuild you schemas and your binding file to pickup the new or changed methods. So in other words, you could be passing a request message that doesn’t match one of the operation names.

It’s also possible that you have a new Method3 created on the development/test system, but perhaps you are pointing to a QA or Production URL for the webservice.  You either have to point back to the development/test system, or have someone promote the web service code up to the next environment of the URL that you are using.

Another “obvious” thing to check is the orchestration binding.  Make sure the internal port names (called “Outbound Logical Ports” in the binding), match the proper “Send Port”.  If you pick the wrong SendPort, that will cause this error.

Originally when you ran the ‘Add Generated Items”, and selected “Consume WCF Service”, then Visual Studio built a schema file for you, containing all the request/responses messages for each of the methods. I believe, but have not verified for 100% of the scenarios, that the root element of the request message will match the operation (method) name. Then the response message schema will be the same with the letters “Response” suffixed on the end.

For further information: StackOverflow