Cómo invocar web services SOAP/XML que no respetan estándares.

Cómo invocar web services SOAP/XML que no respetan estándares.

Hace unos meses me encontré con un problema al invocar servicios expuestos desde un Middleware propietario (PSI Metals/iFace) desde Biztalk Server.

PSI es un sistema que permite administrar el proceso de producción de Acero y Aluminio y derivados http://www.psimetals.de/en/met-home/.

Para facilitar el proceso de integración con los otros sistemas que puedan existir en una implementación, PSI cuenta con un componente que hace las veces de Middleware.

Una de las prestaciones de dicho Middleware es el consumo y publicación de servicios SOAP/XML; sin embargo, tiene algunas limitaciones que no permiten interactuar de manera simple con ellos.

Al menos se han detectado dos problemas con el manejo de namespaces:

  • Sólo permite interactuar con servicios que implementan un único namespace.
  • El formato del request que aceptan sus servicios no respeta el estándar SOAP/XML.

Justo el segundo punto es el que se explica a continuación.

Al invocar servicios SOAP, uno de los componentes relevantes del contrato de servicio es el namespace. El contrato define un namespace con el que se intercambiará la información y existen varias maneras de indicar este dato

1) Implícitamente:

image

2) A través de un calificador de namespace:

image

3) O a través de una variante completamente calificada:

image

Biztalk y .Net utiliza por default la primera forma. El problema con iFace en este caso, es que si bien el servicio responde, el response no respeta el namespace definido en el contrato (no incluye namespaces en la respuesta).

image

Lo anterior provoca que el receptor no reconozca el mensaje. Aun cuando los tags vengan, no se identifican dentro del namespace definido en el contrato del servicio.

Cuando se utiliza el segundo y tercer formato responde correctamente.

image

Para resolver esto, desde Biztalk, fue posible modificar el comportamiento default para que al enviar el request, lo enviara completamente calificado.

image

En el caso de .Net, es necesario modificar el comportamiento del proxy generado para el consumo generando un Custom Message Inspector.El detalle en el siguiente link (en inglés):

https://blogs.msdn.microsoft.com/stcheng/2009/02/21/wcfhow-to-inspect-and-modify-wcf-message-via-custom-messageinspector/

Esto tiene un impacto en el tamaño del mensaje, ya que los prefijos van a aumentar el tamaño del mismo. La realidad es que PSI debería corregir (si no lo ha hecho ya), su implementación para que respete el estándar XML/SOAP. Pero mientras tanto, se puede aplicar alguna de las alternativas comentadas acá.