wcf - significado - Desajuste de ContractFilter en la excepción EndpointDispatcher
wcf vs web api (26)
Tengo la siguiente situación que intento probar:
- Un WSDL común
- Punto final WCF que implementa objetos basados en WSDL y está alojado en IIS.
- Una aplicación cliente que usa un proxy basado en el WSDL para crear solicitudes.
Cuando realizo una llamada al servicio web desde el cliente hasta el punto final del servicio, recibo la siguiente excepción:
{"El mensaje con la acción '' http: // IMyService / CreateContainer '' no puede procesarse en el receptor debido a una discrepancia ContractFilter en el EndpointDispatcher. Esto puede deberse a una discrepancia en el contrato (Acciones no coincidentes entre el remitente y el receptor) o falta de correspondencia / seguridad entre el emisor y el receptor. Compruebe que el emisor y el receptor tengan el mismo contrato y el mismo enlace (incluidos los requisitos de seguridad, por ejemplo, Mensaje, Transporte, Ninguno).
Empecé a utilizar MS Service Trace Viewer, pero no estoy seguro de dónde buscar. Al observar las clases en el cliente y el punto final, parecen idénticas.
¿Cómo se comienza a depurar este problema?
¿Cuáles son algunas causas posibles de esta excepción?
Como se menciona en otras respuestas, como @chinto, esto ocurre cuando el elemento de encabezado SOAP: Acción no coincide con el Endpoint.
Puede encontrar el URI correcto para usar mirando el WSDL del servidor. Verá un elemento de operación con un elemento secundario de entrada que tiene un atributo de "Acción". Eso es lo que su SOAP: la acción debe estar en la solicitud del 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>
Curiosamente, solucionamos este error utilizando la misma carcasa que el nombre de Ruta y OperaciónContrato utilizado. Aparentemente era sensible a mayúsculas y minúsculas. Si alguien sabe por qué, por favor comente. ¡Gracias!
El error indica que hay un desajuste, suponiendo que tiene un contrato común basado en el mismo WSDL, entonces la falta de coincidencia está en la configuración.
Por ejemplo, que el cliente está usando nettcpip y el servidor está configurado para usar http básico.
Entonces, mi caso fue el siguiente. No utilicé el proxy para la interacción cliente-servidor, utilicé ChannelFactory (por lo tanto, todos los consejos para actualizar a la referencia del servicio no tenían sentido para mí).
El servicio se alojó en IIS y, por alguna razón, tenía referencias incorrectas en la carpeta bin allí. La recompilación del proyecto simplemente no dio lugar a nuevas dlls en esa carpeta.
Así que eliminé todas las cosas de allí y agregué una referencia al servicio en la misma solución, luego volví a compilar y ahora todo funciona.
Esto podría ser por 2 razones para esto:
la referencia de servicio no está actualizada, haga clic con el botón derecho en el servicio y actualícela.
El contrato que ha implementado puede ser diferente al que tiene el cliente. Compare el servicio n el contrato del cliente y corrija el desajuste de los contratos.
Lo obtuve después de copiar el archivo svc y renombrarlo. Aunque el nombre del archivo y el archivo svc.cs se cambiaron correctamente de nombre, el marcado aún hacía referencia al archivo original.
Para solucionar esto, haga clic derecho en el archivo svc copiado y elija Ver marcado y cambie la referencia del servicio.
Lo resolví agregando lo siguiente a la implementación de mi contrato:
[ ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
Por ejemplo:
[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
public class MyUploadService : IMyUploadService
{
}
Mi problema resultó ser algo raro, pero lo mencionaré de todos modos.
Me encontré con el problema de implementación en nuestro entorno de desarrollo. En esa máquina, nuestra persona de desarrollo había creado dos carpetas (desplegó dos aplicaciones). Una versión anterior y la nueva versión actual. Entonces, si no tiene dos versiones de su aplicación en el servidor web, esto no se aplica a usted.
La nueva ubicación que creó tenía un nombre no estándar como la primera parte de la url después del host:
net.tcp://dev.umbrellacorp.com/ DifferentFolderName /MyProvider
En mi equipo local, mi cliente estaba señalando el nombre de la carpeta estándar como se configuró en todos los entornos (excepto en el desarrollo), incluido mi entorno local.
net.tcp://dev.umbrellacorp.com/ AppServices /MyProvider
Cuando me escapé y reemplacé el web.config en el desarrollo con mi copia local, la parte de la url que tenía que ser especial quedó impresa con la parte estándar, por lo que el cliente en dev apuntó a la aplicación anterior.
La aplicación anterior tenía un contrato anterior y no entendía la solicitud y lanzó este error.
Para aquellos que están usando NodeJS con axios para realizar las solicitudes SOAP, deben incluir un SOAPAction header . Verifique el ejemplo a continuación:
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)
})
Para un cliente Java que llama a un punto final .net. Esto fue causado por el encabezado de Acción de Soap no coincidente.
Content-Type: application/soap+xml;charset=UTF-8;action="http://example.org/ExampleWS/exampleMethod"
El encabezado HTTP anterior o la siguiente etiqueta XML deben coincidir con la acción / método que intenta invocar.
<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>
Pasé días buscando la respuesta y la encontré, pero no en este hilo. Soy muy nuevo en WCF y C #, por lo que para algunos la respuesta puede ser obvia.
En mi situación, tenía una herramienta cliente que se desarrolló originalmente para el servicio ASMX, y para mí devolvió el mismo mensaje de error.
Después de probar todo tipo de recomendaciones encontré este sitio:
Me puso en el camino correcto. Específicamente "soap: operation" - WCF estaba agregando ServiceName al Namespace:
el cliente esperaba Http://TEST.COM/Login , pero WCF envió Http://TEST.COM/IService1/Login . La solución es agregar la configuración a [OperationContract] esta manera:
[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Ignore los espacios en blanco en Http)
Si llama al método WCF, debe incluir la interfaz en el encabezado.
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+ "/"");
}
Su cliente no se actualizó. Por lo tanto, actualice sus servicios del servicio web y luego reconstruya su proyecto.
También obtendrá esto si intenta conectarse a la URL incorrecta ;)
Tengo dos puntos finales y servicios definidos en mi sistema, con nombres similares.
Obtuve este error exacto cuando las URL se intercambiaron en mi cliente en algún momento. Realmente se rascó la cabeza hasta que finalmente descubrió este estúpido error.
También podría ser útil para aquellos que están haciendo esto mediante la codificación. Debe agregar WebHttpBehavior () a su punto final de servicio agregado. Algo como:
restHost.AddServiceEndpoint(typeof(IRestInterface), new WebHttpBinding(), "").Behaviors.Add(new WebHttpBehavior());
Eche un vistazo a: https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf-service
Tonto, pero olvidé agregar [OperationContract] a mi interfaz de servicio (la marcada con [ServiceContract] ) y luego también recibes este error.
Tuve el mismo error en un servicio WCF implementado, el problema estaba relacionado con otro servicio implementado con otro contrato con el mismo puerto.
Solución
Utilicé diferentes puertos en el web.config y el problema desapareció.
Servicio 1
contract="Service.WCF.Contracts.IBusiness1"
baseAddress="net.tcp://local:5244/ServiceBusiness"
Servicio 2
contract="Service.WCF.Contracts.IBusiness2"
baseAddress="net.tcp://local:5243/ServiceBusiness"
Además , me encontré con esta situación al usar un puerto diferente para la misma dirección entre el servicio y el consumidor.
Tuve el mismo problema. El problema fue que copié el código de otro servicio como punto de partida y no cambié la clase de servicio en el archivo .svc
Abra el archivo .svc y asegúrese de que el atributo de servicio sea correcto.
<%@ ServiceHost Language="C#" Debug="true" Service="SME.WCF.ApplicationServices.ReportRenderer" CodeBehind="ReportRenderer.svc.cs" %>
Tuve este error porque tengo una versión anterior de la DLL en el GAC de mi servidor. Así que asegúrese de que todo esté referenciado correctamente y de que el ensamblado / GAC esté actualizado con el buen dll.
Tuve este error y fue causado por el contrato recevier que no implementa el método que se llama. Básicamente, alguien no había implementado la última versión del servicio WCF para el servidor host.
Tuve este problema en mi servidor de prueba, porque estaba ejecutando dos copias del mismo wcf en el mismo grupo de aplicaciones. Lo que resolví para mí fue crear pools separados para cada versión en mi wcf y reiniciar el IIS después de esto.
Tuve este problema y descubrí que en mi generador de proxy, que copié de otro servicio, olvidé cambiar el nombre del servicio.
Cambié esto ...
Return New Service1DataClient(binding, New EndpointAddress(My.Settings.WCFServiceURL & "/Service1Data.svc"))
a...
Return New Service2DataClient(binding, New EndpointAddress(My.Settings.WCFServiceURL & "/Service2Data.svc"))
Fue un simple error de código, pero casi imposible de depurar. Espero que esto le ahorre tiempo a alguien.
Tuve un error similar. Esto podría deberse a que habría cambiado alguna configuración de contrato en su archivo de configuración después de que se haya refrendado en su proyecto. solución - Actualice la referencia del servicio web en su proyecto VSstudio o cree un nuevo proxy usando svcutil.exe
Un "desajuste de ContractFilter en el EndpointDispatcher" significa que el receptor no pudo procesar el mensaje porque no coincidía con ninguno de los contratos que el receptor configuró para el punto final que recibió el mensaje.
Esto puede ser porque:
- Tienes diferentes contratos entre el cliente y el remitente.
- Está utilizando un enlace diferente entre el cliente y el remitente.
- La configuración de seguridad del mensaje no es coherente entre el cliente y el remitente.
Tenga en cuenta la clase EndpointDispatcher para obtener más información sobre el tema.
Yo tuve este problema también. Resultó que fue causado por el serializador de contrato en el extremo del servidor. No pudo devolver mi objeto de contrato de datos porque algunos de sus miembros de datos eran de solo lectura .
Asegúrate de que tus objetos tengan setters para las propiedades que deben ser serializadas.
Este error generalmente se produce si el código no se implementa correctamente.
En mi caso, tengo dos servicios, ServiceA y ServiceB. Encontré el problema de que los archivos ServiceB no se implementaron correctamente. Por eso, cuando ServiceA llamaba internamente a ServiceB, estaba dando el siguiente error.
Asegúrese de que los archivos y las referencias se implementen correctamente.