Consumir un web service al cual hay que pasarle un parámetro a través de un header SOAP

Primero se debe agregar los headers soap en forma implícita en los wsdl de los servicios web que los utilicen. Es decir, hay que modificar los wsdl si no tienen definidos los headers. La recomendación nuestra es agregar la definición de los headers en todos los wsdl que correspondan, porque así quedarán oficializados y para nosotros será transparente el consumo de los web services. Si no lo hacen los creadores del wsdl, entonces lo tendremos que hacer nosotros en una copia nuestra del wsdl, pero eso tendrá el inconveniente que cada vez que ellos modifiquen el wsdl, nosotros tendremos que volver a editarlo.

Pedir esto no es nada malo ni fuera de los estándares, dado que el propio estándar wsdl contempla la definición de headers tanto en forma implícita como en forma explícita. Nosotros utilizaremos la forma implícita, dado que ello no tendrá impacto en otras aplicaciones que utilizan los web services. Esto es así porque la forma explícita obliga a agregar un parámetro por cada header en todos los métodos web que los utilicen y la forma implícita no.

Una vez agregada la definición de los headers al wsdl, se puede crear una clase cliente de WCF a partir del wsdl, utilizando la herramienta svcutil.exe en lugar de wsdl.exe. Ambos utilitarios permiten crear clases proxy de servicios web a partir de un wsdl, pero svcutil.exe crea clases cliente (por un tema de claridad las llamamos “cliente” en lugar de “proxy”) basadas en Windows Communication Foundation (WCF). Esto tiene múltiples ventajas, como por ejemplo las siguientes: 1) Permite la configuración de los protocolos de acceso a los web services desde un archivo .config; 2) En dicho archivo de configuración se puede cambiar el dimensionamiento del canal de comunicación, la seguridad, los timeouts, etc; 3) Se puede modificar la url de acceso al servicio web; 4) Se pueden registrar en un log todos los mensajes de ida y vuelta entre la clase cliente y los servicios web; 5) Se pueden activar contadores de performance para monitorear el comportamiento de la comunicación; 6) Se pueden crear clases cliente para acceder a servicios basados en WCF, no solo para web services estándar; 7) Al crearse la clase cliente, si hay métodos web que reciben parámetros a través de headers soap (como es el caso que nos interesa), estos se agregan automáticamente al resto de los parámetros del método web. Obviamente, si los headers no están definidos en el wsdl, el utilitario svcutil.exe no puede hacer nada para inferirlos.

Dicho lo anterior, el procedimiento para consumir los métodos web que utilizan headers es el siguiente:

1) En cada wsdl en el que se necesiten enviar información a través de headers, hay que agregar los fragmentos de xml que están en el ejemplo de abajo.

Nota: En este ejemplo, sólo se agregó el header al método web “consultarEmpresaBasica”.

2) Generar la clase cliente a partir de cada wsdl, utilizando como base los archivos .bat que están en la subcarpeta ClientGeneration, que se encuentra dentro de la carpeta de instalación de EngageServices. El procedimiento es similar a la creación de clases proxy con los .bat de la subcarpeta ProxyGeneration.

3) En los archivos de configuración de EngageServices y ESProxyManager, agregar el siguiente fragmento de configuración, respetando la posición dentro de la estructura del xml:

Nota: Este xml se genera automáticamente junto con la clase cliente, en un archivo con la extensión “.config”. Tener en cuenta que el binding se agrega una sola vez si son del mismo tipo (en este caso: “basicHttpBinding”), mientras que los endpoints se agregarán uno por cada servicio web.

4) Copiar las dlls generadas a la carpeta de instalación de EngageServices y reiniciar el servicio.

5) Agregar un parámetro nuevo a la definición del mensaje TCP que Engage le envia a EngageServices. Ese parámetro debe ser el primero y debe contener el valor de IdSesionAST obtenido previamente con el método web “ValidarAccesoPortal” del web service de usuarios. Aplicado a este caso específico, la forma genérica del mensaje debería ser el siguiente:

WSX|
ClientInformacionEmpresa|
InformacionEmpresaClient|
consultarEmpresaBasica|
< CustPkey>|
< JobPkey>|
< UserId>|
< id_transformation>|
< ivsesion>|            <— Nuevo parámetro que representa al header, agregado automáticamente por svcutil.exe
< codCanal>|
< codBancoInterno>|
< codEmpresa>|
< codBancoProd>|
< codProducto>|
< codSubproducto>
[EOM]

Según los valores de la invocación que registraron en el ticket:

WSX|
ClientInformacionEmpresa|
InformacionEmpresaClient|
consultarEmpresaBasica|
< CustPkey>|
< JobPkey>|
< UserId>|
< id_transformation>|
20091|
0026|
85|
00029081|
85|
1380|
0
[EOM]

Nota: Si abren la dll con el utilitario ESProxyManager, podrán ver la forma que tiene la función.

6) Armar la transformación en el archivo Transformations.xml, para procesar la respuesta del método web y guardar los resultados en tablas de Engage.

Nota: Si abren la dll con el utilitario ESProxyManager, podrán ver el tipo que tiene la respuesta de la función.