Невідповідність ContractFilter за винятком EndpointDispatcher

У мене є такий сценарій, який я намагаюся перевірити:

1. Поширений WSDL
2. Кінцева точка WCF, яка реалізує об'єкти на основі WSDL і розміщується в IIS.
3. Клієнтська програма, яка використовує проксі на основі WSDL для створення запитів.

Коли я здійснюю дзвінок веб-служби від клієнта до кінцевої точки обслуговування, я отримую таке виняток:

{"Повідомлення з Дією" http: // IMyService / CreateContainer "неможливо обробити на одержувачі через невідповідність ContractFilter у EndpointDispatcher. Це може бути через невідповідність контракту (невідповідні дії між відправником та одержувачем) або Невідповідність прив’язки / безпеки між відправником та одержувачем. Перевірте, чи є у відправника та одержувача однаковий договір та однакові обов'язкові зобов'язання (включаючи вимоги безпеки, наприклад повідомлення, транспорт, відсутність). "}

Я почав використовувати MS Service Trace Viewer, але не знаю, де його шукати. Переглядаючи класи в клієнті та кінцеві точки, вони здаються однаковими.

Як почати налагоджувати цю проблему?

Які можливі причини цього винятку?

"Невідповідність ContractFilter у EndpointDispatcher" означає, що одержувач не міг обробити повідомлення, оскільки він не відповідав жодному з контрактів, які приймач налаштував для кінцевої точки, яка отримала повідомлення.

Це може бути тому, що:

• У вас різні контракти між клієнтом і відправником.
• Ви використовуєте різну прив'язку між клієнтом та відправниками.
• Параметри безпеки повідомлень не відповідають клієнту та відправнику.

Перегляньте EndpointDispatcherклас для отримання додаткової інформації з цього питання.

Так:

Переконайтеся, що ваші клієнтські та серверні договори відповідають.

• Якщо ви створили свого клієнта з WSDL, чи є WSDL актуальним?
• Якщо ви внесли останні зміни в контракт, чи розгорнули ви правильну версію як клієнта, так і сервера?
• Якщо ви склали вручну класи клієнтських контрактів, переконайтеся, що простори імен, назви елементів та назви дій відповідають тим, які очікує сервер.

Перевірте, чи зв’язки однакові між клієнтом і сервером.

• Якщо ви використовуєте файл .config для керування кінцевими точками, переконайтеся, що елементи зв’язування відповідають.

Перевірте, чи налаштування безпеки однакові між клієнтом та сервером.

• Якщо ви використовуєте файл .config для управління своїми кінцевими точками, переконайтеся, що елементи захисту відповідають.

У мене виникла помилка, і це було спричинено тим, що контракт отримувача не реалізував викликаний метод. В основному, хтось не розгорнув останню версію послуги WCF на хост-сервері.

Ви також отримаєте це, якщо спробуєте підключитися до неправильної URL-адреси ;)

У мене в системі визначено дві кінцеві точки та служби із схожими назвами.

Я отримав цю точну помилку, коли URL-адреси замінилися на моєму клієнті в якийсь момент. Дійсно почухав голову, поки нарешті не з'ясував цю тупу помилку.

У мене виникла ця проблема, і я виявив, що в своєму генераторі проксі, який я скопіював з іншої служби, я забув змінити назву служби.

Я змінив це ...

Return New Service1DataClient(binding, New EndpointAddress(My.Settings.WCFServiceURL & "/Service1Data.svc"))

до ...

Return New Service2DataClient(binding, New EndpointAddress(My.Settings.WCFServiceURL & "/Service2Data.svc"))

Це була проста помилка коду, але майже неможлива налагодження. Сподіваюся, це економить комусь час.

Для клієнта Java, який викликає кінцеву точку .net. Це було викликано невідповідністю заголовка Soap Action.

Content-Type: application/soap+xml;charset=UTF-8;action="http://example.org/ExampleWS/exampleMethod"

Наведений вище заголовок HTTP або наступний тег XML повинні відповідати дії / методу, який ви намагаєтеся викликати.

   <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:tem="http://tempuri.org/" xmlns:gen="http://schemas.datacontract.org/2004/07/GenesysOnline.WCFServices">
   <soap:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
      <wsa:To>https://example.org/v1/Service.svc</wsa:To>
      <wsa:Action>http://example.org/ExampleWS/exampleMethod</wsa:Action>
   </soap:Header>
   <soap:Body>
    ...
   </soap:Body>
</soap:Envelope>

Я вирішив це, додавши до виконання мого контракту наступне:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

Наприклад:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
public class MyUploadService : IMyUploadService
{

}

Я отримав це після того, як я скопіював файл svc і перейменував його. Хоча ім'я та файл svc.cs були правильно перейменовані, розмітка все ще посилалася на вихідний файл.

Щоб виправити це, клацніть правою кнопкою миші скопійований файл svc та виберіть Перегляд розмітки та змініть посилання служби.

Як було сказано в інших відповідях, таких як @chinto, це відбувається, коли елемент заголовка SOAP: Action не відповідає Кінцевій точці.

Ви можете знайти правильний URI для використання, переглянувши WSDL сервера. Ви побачите елемент операції з дочірньою інформацією, яка має атрибут "Дія". Це те, що ваша SOAP: Дія повинна бути виконана за запитом клієнта.

<wsdl:operation name="MethodName">
<wsdl:input wsaw:Action="http://tempuri.org/IInterface/MethodName" message="tns:IInterface_MethodName_InputMessage"/>
<wsdl:output wsaw:Action="http://tempuri.org/IInterface/MethodNameResponse" message="tns:IInterface_MethodName_OutputMessage"/>
</wsdl:operation>

У мене було те саме питання. Проблема полягала в тому, що я скопіював код з іншої служби як вихідну точку і не змінив клас обслуговування у файлі .svc

Відкрийте файл .svc і переконайтесь, що атрибут Service правильний.

 <%@ ServiceHost Language="C#" Debug="true" Service="SME.WCF.ApplicationServices.ReportRenderer" CodeBehind="ReportRenderer.svc.cs" %>

Помилка говорить про те, що існує невідповідність, якщо припустити, що у вас є спільний контракт, заснований на тому ж WSDL, то невідповідність є в конфігурації.

Наприклад, що клієнт використовує nettcpip, а сервер налаштований на використання базового http.

У мене була подібна помилка. Це може бути тому, що ви змінили б якесь налаштування контракту у своєму конфігураційному файлі після того, як воно було переглянуто у ваш проект. рішення - оновіть посилання веб-сервісу на проект VSstudio або створіть новий проксі за допомогою svcutil.exe

Ця помилка зазвичай виникає, якщо код не розгорнуто належним чином.

У моєму випадку у мене є два сервіси ServiceA і ServiceB. Я виявив проблему в тому, що файли ServiceB не були розгорнуті належним чином. Через що, коли ServiceA викликав ServiceB внутрішньо, він давав нижче помилки.

Переконайтесь, що файли та посилання розгорнуті належним чином.

Я витрачав дні на пошуки відповіді і знайшов її, але не в цій темі. Я дуже новачок у WCF та C #, тому для деяких відповідь може бути очевидною.

У моїй ситуації у мене був клієнтський інструмент, який спочатку був розроблений для служби ASMX, і для мене він повертав те саме повідомлення про помилку.

Спробувавши всілякі рекомендації, я знайшов цей сайт:

http://myshittycode.com/2013/10/01/the-message-with-action-cannot-be-processed-at-the-receiver-due-to-a-contractfilter-mismatch-at-the-endpointdispatcher/

Це поставило мене на правильний шлях. Зокрема "soap: аперація" - WCF додає ServiceName до простору імен:

клієнт очікував Http://TEST.COM/Login, але WCF відправив Http://TEST.COM/IService1/Login. Рішення полягає в тому, щоб додати такі налаштування [OperationContract]:

[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Ігноруйте порожні пробіли в Http)

Це може бути з двох причин:

1. посилання сервісу застаріло, клацніть правою кнопкою миші послугу ref оновіть його.

2. контракт, який ви реалізували, може відрізнятись від клієнта. Порівняйте обидві послуги n клієнтський договір n виправте невідповідність контрактів.

Якщо ви викликаєте метод WCF, вам слід включити інтерфейс у заголовку.

HttpWebRequest req = (HttpWebRequest)WebRequest.Create(Url);
if (Url.Contains(".svc"))
{
    isWCFService = true;
    req.Headers.Add("SOAPAction", "http://tempuri.org/WCF_INterface/GetAPIKeys");
}
else 
{
    req.Headers.Add("SOAPAction", "\"http://tempuri.org/" + asmxMethodName+ "\"");
}

Також може бути корисним для тих, хто робить це шляхом кодування. Вам потрібно додати WebHttpBehavior () до кінцевої точки доданої послуги. Щось на зразок:

restHost.AddServiceEndpoint(typeof(IRestInterface), new WebHttpBinding(), "").Behaviors.Add(new WebHttpBehavior()); 

Погляньте на сторінку: https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf-service

Нерозумно, але я забув додати [OperationContract]до свого сервісного інтерфейсу (той, який позначений символом [ServiceContract]), і тоді ви також отримаєте цю помилку.

Ваш клієнт не оновлювався. Отже, оновіть свої послуги за допомогою веб-сервісу та відновіть проект

У мене була і ця проблема. Виявилося, що це було викликано серіалізатором контрактів на кінці сервера. Він не міг повернути об'єкт мого контракту, оскільки деякі його члени даних були лише властивостями для читання .

Переконайтесь, що у ваших об’єктів встановлені налаштування для властивостей, які мають бути серіалізовані.

Як не дивно, ми обходили цю помилку, використовуючи той самий кожух, що і назва Path і OperationContract. Мабуть, це було чутливим до регістру. Якщо хтось знає чому, будь ласка, прокоментуйте. Дякую!

Отже, мій випадок був такий. Я не використовував проксі для взаємодії клієнт-сервер, я використовував ChannelFactory (тому всі поради щодо переходу на посилання на службу для мене були безглуздими).

Служба розміщувалася в IIS, і вона чомусь мала неправильні посилання у папці bin. Перекомпіляція проекту просто не призвела до появи нових dll у цій папці.

Тож я просто видалив звідти всі речі та додав посилання на сервіс у тому самому рішенні, потім перекомпілював і тепер усе працює.

Моє питання виявилося чимось рідкісним, але я все одно згадаю його.

Я зіткнувся з проблемою розгортання нашого середовища розробки. На цій машині наша особа по створенню створила дві папки (розгорнула дві програми). Стара версія та нова поточна версія. Отже, якщо у вас немає двох версій вашої програми на веб-сервері, це не стосується вас.

Створене ним нове місцезнаходження отримало нестандартне ім'я як першу частину URL-адреси після хоста:

net.tcp://dev.umbrellacorp.com/DifferentFolderName/MyProvider

На моїй локальній машині мій клієнт вказував на стандартне ім'я папки, як було встановлено для всіх середовищ (крім розробки), включаючи моє місцеве середовище.

net.tcp://dev.umbrellacorp.com/AppServices/MyProvider

Коли я підірвав і замінив web.config на розробці моєю локальною копією, частина URL-адреси, яка мала бути спеціальним, була здута стандартною частиною, тому в результаті клієнт на розробці вказав на стару програму.

У старій програмі був старий договір, і не зрозумів запит, і він видав цю помилку.

У мене була така ж помилка в розгорнутій службі WCF, проблема була пов'язана з іншою службою, розгорнутою з іншим контрактом з тим же портом.

Рішення

Я використовував різні порти в web.config, і проблема зникла.

Служба 1

contract="Service.WCF.Contracts.IBusiness1" 
baseAddress="net.tcp://local:5244/ServiceBusiness" 

Служба 2

contract="Service.WCF.Contracts.IBusiness2"
baseAddress="net.tcp://local:5243/ServiceBusiness"

Також я зіткнувся з цією ситуацією, використовуючи інший порт для тієї самої адреси між службою та споживачем.

У мене була ця помилка, оскільки в GAC мого сервера є стара версія DLL. Тому переконайтеся, що все посилається правильно, і що збірка / GAC відповідає сучасній якості.

У мене виникла ця проблема на моєму тестовому сервері, оскільки я працював дві копії одного wcf в одному пулі додатків. Що для мене вирішило - створити окремі пули для кожної версії на моєму wcf та перезапустити IIS після цього.

Для тих, хто використовує NodeJS з axios, щоб робити запити SOAP, ви повинні додати SOAPAction header. Перевірте приклад нижче:

axios.post('https://wscredhomosocinalparceria.facilinformatica.com.br/WCF/Soap/Emprestimo.svc?wsdl',
           xmls,
  {headers:
  {
    'Content-Type': 'text/xml',
    SOAPAction: 'http://schemas.facilinformatica.com.br/Facil.Credito.WsCred/IEmprestimo/CalcularPrevisaoDeParcelas'}
  }).then(res => {
    console.log(res)
  }).catch(err => {
    console.log(err.response.data)
  })