Incompatibilidade de ContractFilter na exceção EndpointDispatcher


116

Tenho o seguinte cenário que estou tentando testar:

  1. Um WSDL comum
  2. Endpoint WCF que implementa objetos com base no WSDL e está hospedado no IIS.
  3. Um aplicativo cliente que usa um proxy baseado no WSDL para criar solicitações.

Quando faço uma chamada de serviço da web do cliente para o terminal de serviço, recebo a seguinte exceção:

{"A mensagem com a ação ' http: // IMyService / CreateContainer ' não pode ser processada no destinatário, devido a uma incompatibilidade de ContractFilter no EndpointDispatcher. Isso pode ser devido a uma incompatibilidade de contrato (ações incompatíveis entre remetente e destinatário) ou um incompatibilidade de ligação / segurança entre o remetente e o destinatário. Verifique se o remetente e o destinatário têm o mesmo contrato e a mesma vinculação (incluindo requisitos de segurança, por exemplo, Mensagem, Transporte, Nenhum). "}

Comecei a usar o MS Service Trace Viewer, mas não tenho certeza de onde procurar. Ao observar as classes no cliente e no terminal, elas parecem idênticas.

Como começar a depurar esse problema?

Quais são algumas das possíveis causas para essa exceção?

Respostas:


75

Uma "incompatibilidade de ContractFilter no EndpointDispatcher" significa que o receptor não pôde processar a mensagem porque ela não correspondia a nenhum dos contratos que o receptor configurou para o terminal que recebeu a mensagem.

Isso pode ser porque:

  • Você tem contratos diferentes entre o cliente e o remetente.
  • Você está usando uma ligação diferente entre cliente e remetente.
  • As configurações de segurança da mensagem não são consistentes entre o cliente e o remetente.

Dê uma olhada na EndpointDispatcheraula para mais informações sobre o assunto.

Assim:

Certifique-se de que seus contratos de cliente e servidor coincidam.

  • Se você gerou seu cliente a partir de um WSDL, o WSDL está atualizado?
  • Se você fez uma alteração recente no contrato, implantou a versão correta do cliente e do servidor?
  • Se você tiver criado suas classes de contrato de cliente manualmente, certifique-se de que os namespaces, nomes de elementos e nomes de ação correspondam aos esperados pelo servidor.

Verifique se as ligações são iguais entre o cliente e o servidor.

  • Se você estiver usando um arquivo .config para gerenciar seus terminais, certifique-se de que os elementos de ligação sejam correspondentes.

Verifique se as configurações de segurança são iguais entre o cliente e o servidor.

  • Se você estiver usando um arquivo .config para gerenciar seus endpoints, certifique-se de que os elementos de segurança correspondem.

3
verifique também se o atributo de serviço está correto no arquivo .svc. Veja minha resposta abaixo.
AntonK de

Só queria acrescentar algo à solução acima (para os novatos), pois encontrei o mesmo problema, mas a solução acima não funcionou para mim. Se você já tentou as soluções alternativas acima e ainda está obtendo o mesmo erro, tente atualizar sua configuração redigitando os pontos de extremidade envolvidos, embora já esteja correto no servidor e no cliente.
devpro101 01 de

74

Eu tive esse erro e ele foi causado pelo contrato do receptor não implementando o método que está sendo chamado. Basicamente, alguém não implantou a versão mais recente do serviço WCF no servidor host.


12
+1 - A mesma coisa aconteceu comigo, só que no meu caso era eu que era o "alguém". Eu tinha esquecido de confirmar e implantar o código do lado do servidor.
Jesse Webb

2
Sim, eu tinha o nome da ação SOAP errado. Ele queria tempuri.org/ICodeGenService/RenderApp , mas por algum motivo o código que analisou o WSDL pensou apenas em tempuri.org/RenderApp .
user435779

Eu também. Eu tinha o método em meu .SVC.CS, mas nenhum OperationContract correspondente em minha interface.
PahJoker

Eu também :) Atualizei o WSDL no SoapUI usando o serviço local em desenvolvimento e, quando criei uma solicitação para o novo método no serviço, o SoapUI usou nosso ambiente de desenvolvimento. Então, o método estava funcionando bem, acabei de consultar a URL errada.
Larsbj

2
Obrigado! Não gastei horas depurando, em vez disso, depois de ler isso, percebi rapidamente que estava enviando solicitações para um ambiente errado.
Jan Matousek

20

Você também obterá isso se tentar se conectar ao URL errado ;)

Tenho dois pontos de extremidade e serviços definidos em meu sistema, com nomes semelhantes.

Recebi este erro exato quando as URLs foram trocadas em meu cliente em algum ponto. Coçou a cabeça de verdade até finalmente descobrir esse erro idiota.


3
É um erro bobo de se ter certeza, mas uma resposta muito útil aqui. Como é algo óbvio, é facilmente esquecido.
mungflesh

O URL incorreto fornece - erro 'não havia endpoint escutando'
AriesConnolly

19

Tive este problema e descobri que no meu gerador de proxy, que copiei de outro serviço, esqueci de mudar o nome do serviço.

Eu mudei isso ...

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

para...

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

Foi um erro de código simples, mas quase impossível de depurar. Espero que isso economize o tempo de alguém.


Esse foi o meu caso também.
Vasyl Boroviak

Obrigado, tive o mesmo problema!
Dieterg de

10

Para um cliente Java chamando um terminal .net. Isso foi causado pela incompatibilidade do cabeçalho Soap Action.

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

O cabeçalho HTTP acima ou a tag XML a seguir precisa corresponder à ação / método que você está tentando chamar.

   <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>

9

Resolvi isso adicionando o seguinte à implementação do meu contrato:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

Por exemplo:

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

}

Isso resolveu meu problema com uma porta encaminhada. Obrigado.
Mathias Müller

Não recebi um novo erro, odeio IIS - CommunicationException: O servidor não forneceu uma resposta significativa; isso pode ser causado por uma incompatibilidade de contrato, um encerramento prematuro da sessão ou um erro interno do servidor.
AriesConnolly

8

Eu consegui isso depois de copiar o arquivo svc e renomeá-lo. Embora o nome do arquivo e o arquivo svc.cs tenham sido renomeados corretamente, a marcação ainda fazia referência ao arquivo original.

Para corrigir isso, clique com o botão direito do mouse no arquivo svc copiado e escolha Exibir marcação e altere a referência de serviço.


5

Conforme mencionado em outras respostas, como @chinto, isso acontece quando o elemento de cabeçalho SOAP: Action não corresponde ao Endpoint.

Você pode encontrar o URI correto a ser usado observando o WSDL do servidor. Você verá um elemento de operação com um filho de entrada que possui um atributo "Action". Isso é o que o seu SOAP: Ação precisa estar na solicitação do cliente.

<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>

depois de dias pesquisando, testando e enlouquecendo - essa resposta me ajudou. obrigado.
babboon

em meu cenário particular, eu estava fazendo a chamada para o WebService de minha classe java usando Apache HttpClient. Para definir o cabeçalho da ação Soap, chamei o método HttpPost SetHeader logo depois de chamar o método setHeader para setContent Type.
vofili

3

Eu tive o mesmo problema. O problema é que copiei o código de outro serviço como ponto de partida e não alterei a classe de serviço no arquivo .svc

Abra o arquivo .svc e verifique se o atributo Service está correto.

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

2

O erro diz que há uma incompatibilidade, supondo que você tenha um contrato comum com base no mesmo WSDL, a incompatibilidade está na configuração.

Por exemplo, se o cliente está usando nettcpip e o servidor está configurado para usar http básico.


2

Eu tive um erro semelhante. Isso pode ser porque você teria alterado alguma configuração de contrato em seu arquivo de configuração depois que ele foi referenciado em seu projeto. solução - Atualize a referência do serviço da web em seu projeto VSstudio ou crie um novo proxy usando svcutil.exe


1

Esse erro geralmente ocorre se o código não for implantado corretamente.

No meu caso, tenho dois serviços ServiceA e ServiceB. Achei o problema de que os arquivos ServiceB não foram implantados corretamente. Por isso, quando o ServiceA estava chamando o ServiceB internamente, ele apresentava o erro abaixo.

**Erro**

Certifique-se de que os arquivos e referências sejam implantados corretamente.


1

Passei dias procurando a resposta e a encontrei, mas não neste tópico. Sou muito novo no WCF e no C #, então, para alguns, a resposta pode ser óbvia.

Na minha situação, eu tinha uma ferramenta cliente que foi originalmente desenvolvida para o serviço ASMX e, para mim, ela estava retornando a mesma mensagem de erro.

Depois de tentar todos os tipos de recomendações, encontrei este site:

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

Isso me colocou no caminho certo. Especificamente "soap: operation" - o WCF estava acrescentando ServiceName ao namespace:

cliente esperado Http://TEST.COM/Login, mas WCF enviado Http://TEST.COM/IService1/Login. A solução é adicionar configurações [OperationContract]como esta:

[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Ignore os espaços em branco em Http)


2
Bem. Sua solução é fazer com que o serviço se comporte como o cliente espera. Mas poderia ser igualmente bem (ou em muitos casos, de preferência) resolvido fazendo com que o cliente realmente cumprisse o contrato do servidor! Afinal, o servidor é o editor do contrato.
The Dag

1

Isso pode ser por 2 motivos:

  1. a referência de serviço está desatualizada, clique com o botão direito do mouse em referência de serviço n atualize-a

  2. contrato que você implementou pode ser diferente do cliente. Compare os dois serviços n contrato do cliente n conserte a incompatibilidade dos contratos.


1

Se você estiver chamando o método WCF, deverá incluir a interface no cabeçalho.

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+ "\"");
}

1

Também pode ser útil para aqueles que estão fazendo isso por meio da codificação. Você precisa adicionar WebHttpBehavior () ao ponto de extremidade de serviço adicionado. Algo como:

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

Dê uma olhada em: https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf-service


Isso me ajudou a economizar tempo, obrigado :)
Sely Lychee

0

Bobagem, mas esqueci de adicionar [OperationContract]à minha interface de serviço (aquela marcada com [ServiceContract]) e você também obterá este erro.


0

Seu cliente não foi atualizado. Portanto, atualize seus serviços a partir do serviço da Web e reconstrua seu projeto


0

Eu tive esse problema também. Descobriu-se que era causado pelo serializador de contrato no lado do servidor. Ele não pôde retornar meu objeto de contrato de dados porque alguns de seus membros de dados eram propriedades somente leitura .

Certifique-se de que seus objetos tenham configuradores para propriedades destinadas a serem serializadas.


0

Estranhamente, contornamos esse erro usando a mesma caixa do nome Path e OperationContract usados. Aparentemente, era sensível a maiúsculas e minúsculas. Se alguém souber por quê, por favor comente. Obrigado!


0

Então, meu caso foi o seguinte. Eu não usei proxy para a interação cliente-servidor, usei ChannelFactory (portanto, todos os conselhos para atualizar a referência de serviço não fizeram sentido para mim).

O serviço estava hospedado no IIS e, por algum motivo, tinha referências erradas na pasta bin lá. A recompilação do projeto simplesmente não levou a novas dlls nessa pasta.

Então, apaguei todo o material de lá e adicionei referência ao serviço na mesma solução, depois recompilei e agora tudo funciona.


0

Meu problema acabou sendo algo raro, mas vou mencioná-lo de qualquer maneira.

Eu encontrei o problema de implantação em nosso ambiente de desenvolvimento. Nessa máquina, nosso responsável pela construção criou duas pastas (implantou dois aplicativos). Uma versão antiga e a nova versão atual. Portanto, se você não tiver duas versões de seu aplicativo no servidor da web, isso não se aplica a você.

O novo local que ele criou tinha um nome diferente do padrão como a primeira parte do url após o host:

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

Em minha máquina local, meu cliente estava apontando para o nome da pasta padrão conforme configurado em todos os ambientes (exceto desenvolvimento), incluindo meu ambiente local.

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

Quando eu perdi o controle e substituí o web.config no desenvolvimento pela minha cópia local, a parte da url que precisava ser especial foi perdida com a parte padrão, então, como resultado, o cliente no dev apontou para o aplicativo antigo.

O aplicativo antigo tinha um contrato antigo, não entendia a solicitação e gerava esse erro.


0

Tive o mesmo erro em um serviço WCF implantado, o problema estava relacionado a outro serviço implantado com outro contrato com a mesma porta.

Solução

Usei portas diferentes no web.config e o problema desapareceu.

Serviço 1

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

Serviço 2

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

Além disso , me deparei com essa situação usando uma porta diferente para o mesmo endereço entre o serviço e o consumidor.


0

Tive este erro porque tenho uma versão antiga da DLL no GAC do meu servidor. Portanto, verifique se tudo está referenciado corretamente e se o assembly / GAC está atualizado com a dll em boas condições.


0

Tive esse problema com meu servidor de teste, porque estava executando duas cópias do mesmo wcf no mesmo pool de aplicativos. O que resolveu para mim foi criar pools separados para cada versão no meu wcf e reiniciar o IIS depois disso.


0

Para aqueles que estão usando NodeJS com axios para fazer as solicitações SOAP, você deve incluir a SOAPAction header. Veja o exemplo abaixo:

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)
  })
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.