Esta crónica me hace recordar una escena de Futurama, del episodio en que Fry se come un sandwich descompuesto y los parásitos que se desarrollan en su interior comienzan a mejorarlo, tanto física como mentalmente. La escena en particular prosigue a un accidente en el edificio del Planet donde una tubería termina incrustada en el abdomen de Fry. Cuando están en el consultorio del Dr. Zoidberg, este llega para examinar a Fry y dice (link como título de la imagen si quieren verlo):
-¡Ah!, el hipocondriaco ha vuelto, ¿y qué tienes esta vez?
Cuando escuché ese diálogo, me hizo reír tanto que se quedó en mi mente, aunque no con la exactitud que debería, ya que cada vez que la he referido la he expresado como sigue:
–¿Y ahora qué le pasa al hipocondriaco?
La primera vez que usé esta frase fue en mi segundo trabajo. Colaborando con mi equipo, estábamos desarrollando un sistema de análisis de costos basado en actividades; habíamos ejecutado varios ciclos de prueba en los que encontramos numerosos errores, tanto de programación como de lógica o faltantes en las reglas de negocio, hasta que eventualmente el sistema alcanzó una madurez y una estabilidad suficiente para ser desplegado en producción. Fue todo un logro personal y de equipo, ya que según contaban las historias de la oficina donde nos encontrábamos, era el tercer intento por generar el sistema y la primera ocasión en tener éxito.
Durante los primeros meses de operación productiva tuvimos varios reportes de error, en su gran mayoría, obedecían a casos no contemplados referentes a los datos de entrada: datos faltantes, números negativos que no deberían estar, inexistencia de datos (contables por ejemplo), entre otros. Luego de haber solventado una gran cantidad de ellos, los nuevos reportes de error seguían relacionándolos a defectos en la programación, sin embargo, 80% de ellos no lo eran, así que en una de esas ocasiones en que yo no estaba del mejor humor, alguien llegó a comentarme de un aparente bug y lo único que vino a mi mente como respuesta fue: -¿ahora qué le pasa al hipocondriaco?
Y desde entonces, cada vez que un sistema falla, es mi expresión de bienvenida al reporte que recibo.
Pues el día de hoy, el hipocondriaco fue un programa que conecta a un web service. Resulta que mientras el programa estuvo en desarrollo y validación en su correspondiente ambiente de QA, no tuvo problemas en conectar a un servicio web de tipo SOAP publicado por HTTP.
No obstante, cuando se hace el pase al ambiente productivo, al realizar la prueba de ejecución, el cliente no lograba consumir el web service correctamente y el siguiente error era devuelto como parte del reporte:
Cuando activamos la variable FGLWSDLDEBUG, lo que indica el cliente al ejecutar el servicio es que no se lleva a cabo el handshake entre cliente y servidor.
-Uhmmm, ¿y luego?
Hay un particular en esta crónica que no mencioné al inicio. A diferencia del sistema de análisis de costos, este programa no lo desarrollé yo ni apoyé en su realización, se me consultó para ver si yo podía lograr hacerlo funcionar, por lo que tampoco tenía mucho contexto para poder emitir algún diagnóstico basado en los mensajes de error (más allá de lo obvio).
Cuando pido la URL para consultar la WSDL del servicio y hago lo propio en un navegador, lo primero que salta a la vista, es que aunque la URL indica que la WSDL está expuesta mediante HTTPS, el certificado no es identificado como válido, parece un certificado autoemitido (lo cual es normal porque es un servicio interno).
Cuando intentamos general el código 4GL base para el cliente mediante la herramienta fglwsdl apuntando directamente a la WSDL con la URL compartida, la herramienta tampoco logra generar el cliente acusando el mismo error: discrepancias con el certificado.
De tal suerte que el cliente lo volvimos a generar a partir de la WSDL obtenida desde el navegador y guardada como archivo. Volvimos a ejecutar la prueba en productivo y nada… error -15553 y la leyenda del handshake cuando se activa la variable FGLWSDEBUG.
No negaré que emití juicios respecto de que quien publica el servicio por HTTPS es quien tiene que asegurarse que la publicación sea correcta, porque así lo es; sin embargo, mirando el error nuevamente con la cabeza fría y recordando algunas experiencias previas volví a revisar la WSDL, y vi esto:
La WSDL, aunque acusa un certificado inválido, sí está respondiendo por HTTPS. La herramienta SoapUI logra procesar la WSDL por completo, y cuando se hace desde archivo, también la herramienta fglwsdl puede procesarla; la WSDL no parecía ser el origen del problema… Entonces se me ocurrió revisar el endpoint:
La WSDL está expuesta por HTTPS, pero el endpoint no. Aquí es donde la experiencia previa me fue útil.
Hay ocaciones en que el servidor de aplicaciones que expone un servicio no está preparado o no se tiene necesidad de configurarlo para exponer sus servicios mediante HTTPS, de tal suerte que se usa un servidor Web o un componente SOA para exponer el servicio por este protocolo, funcionando como un puente o un proxy. Sin embargo, esa configuración no se hace completa, a veces la WSDL sí queda expuesta en el protocolo deseado, pero no así los componentes asociados, como los XSD asociados, o los endpoints. Esta condición, además de errónea, es un trabajo incompleto… funciona, pero está incompleto ya que implica ajustes manuales para quien hace las veces de cliente.
¿La solución?
Una vez generada la biblioteca mediante la herramienta fglwsdl, hubo que cambiar manualmente el endpoint en el archivo 4gl autogenerado, apuntando el cliente al endpoint como aparece en la WSDL:
Si bien, este dato es asignado correctamente cuando la herramienta fglwsdl importa los datos de la WSDL, quien desarrolló el servicio había estado usando un endpoint diferente porque así le fue comunicado, y adicionalmente, el servicio está publicado con autenticación básica (usuario y contraseña), por lo que el cliente había sido ajustado también para pasar las credenciales en el header:
Como se aprecia en la captura de pantalla, la autenticación estaba siendo apuntada al servicio mediante HTTPS, mismo que no existe así, sino en HTTP por el puerto 50100; de tal suerte, que la autenticación ajustada quedó así:
Habiendo modificado el componente en turno, lo siguiente fue recompilar, desplegar en el servidor correspondiente y ejecutar la prueba.
Todo correcto, no más errores -1553 ni de handshake.
A veces el hipocondriaco sí presenta un problema… aunque no lo haya provocado él mismo.
Deja un comentario