TIBFAQS

Resolviendo uno de los problemas más comunes de los desarrolladores usando BusinessWorks

El Transformation failed for XSLT input es uno de los mensajes de error más comunes que podrías ver al desarrollar usando las herramientas de TIBCO BusinessWorks. Entender lo que el mensaje está diciendo es esencial para proporcionar una solución rápida.

He visto desarrolladores necesitando horas y horas tratando de solucionar este tipo de error cuando la mayoría de las veces, toda la información que estás recibiendo está justo frente a ti, pero necesitas entender por qué el motor lo está pidiendo.

Pero primero proporcionemos un poco de contexto. ¿De qué error estamos hablando? Estoy hablando de algo como lo que puedes ver en el registro de trazas a continuación:

...
com.tibco.pvm.dataexch.xml.util.exceptions.PmxException: PVM-XML-106027: Transformation failed for XSLT input '<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:tns1="http://www.tibco.com/pe/WriteToLogActivitySchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tib="http://www.tibco.com/bw/xslt/custom-functions" version="2.0"><xsl:param name="Mapper2"/><xsl:template name="Log-input" match="/"><tns1:ActivityInput><message><xsl:value-of select="tib:add-to-dateTime($Mapper2/primitive,0,0,1,0,0,0)"/></message></tns1:ActivityInput></xsl:template></xsl:stylesheet>'
	at com.tibco.pvm.infra.dataexch.xml.genxdm.expr.IpmxGenxXsltExprImpl.eval(IpmxGenxXsltExprImpl.java:65)
	at com.tibco.bx.core.behaviors.BxExpressionHelper.evalAsSubject(BxExpressionHelper.java:107)
...

¿Te suena más familiar ahora? Como ya dije, todos los desarrolladores de TIBCO BusinessWorks se han enfrentado a eso. Como dije, he visto a algunos de ellos luchando o incluso rehaciendo el trabajo repetidamente sin encontrar una solución adecuada. Pero la idea aquí es tratar de resolverlo de manera eficiente y rápida.

Comenzaré con las advertencias iniciales: Evitemos re-codificar, rehacer algo que debería funcionar pero no está funcionando, porque no estás ganando en ningún escenario:

• Si lo rehaces y no funcionó, pierdes x2 tiempo creando algo que ya tienes, y aún estás atascado.
• Si lo rehaces y funciona, no sabes qué estaba mal, por lo que te enfrentarás a ello nuevamente en breve.
  

Entonces, ¿cómo funciona esto? Usemos este proceso:

Recopilar —> Analizar —> Entender —> Corregir.

Escenario

Primero, necesitamos recopilar datos, y la mayoría de las veces, como dije, es suficiente con el registro de trazas que tenemos, pero en algún momento, podrías necesitar requerir el código de tu proceso para detectar el error y la solución.

Así que comenzaremos con este código fuente que puedes ver en la captura de pantalla a continuación y la siguiente explicación:

Tenemos un Mapper que está definiendo un esquema con un elemento int que es una opción, y no estamos proporcionando ningún valor:

Y luego estamos usando la fecha para imprimir un registro, agregando un día más a esa fecha:

Solución

Primero, necesitamos entender el mensaje de error. Cuando recibimos un mensaje de error titulado `Transformation failed for XSLT input que dice precisamente esto:

Intenté ejecutar el XSLT que está relacionado con una actividad, y fallé debido a un error técnico

Como probablemente ya sabes, cada una de las actividades de BusinessWorks ejecuta una Transformación XSL internamente para hacer el mapeo de entrada; puedes verlo directamente en el Business Studio. Entonces, este error te está diciendo que este XSL interno está fallando.

Y la razón es un problema de tiempo de ejecución que no puede ser detectado en tiempo de diseño. Así que, para dejarlo claro, los valores de algunas de tus variables y la transformación fallan. Así que primero, deberías enfocarte en esto. Usualmente, toda la información está en el registro de trazas en sí, así que comencemos a analizar eso:

Entonces, veamos toda la información que tenemos aquí:

• En primer lugar, podemos detectar qué actividad está fallando. Puedes hacerlo fácilmente si estás depurando localmente, pero si esto está sucediendo en el servidor puede ser más complicado; pero con esta información, tienes: Todo el XSLT en sí que está impreso en el registro de trazas, por lo que puedes fácilmente
• También tienes un Causado por que te está diciendo por qué está fallando:
  
  • Puedes tener varias oraciones de Causado por que deben leerse en modo de cascada, por lo que la más baja es el problema raíz que genera el error para todos los demás arriba, así que deberíamos localizar eso primero.
    

En este caso, el mensaje es bastante evidente, como puedes ver en la traza a continuación.

 com.tibco.xml.cxf.runtime.exceptions.FunctionException: XPath function {http://www.tibco.com/bw/xslt/custom-functions}add-to-dateTime exception: gregorian cannot be null.

Así que la función add-to-dateTime falla porque un argumento Gregoriano (es decir, una fecha) es nulo. Y eso es precisamente lo que está sucediendo en mi caso. Si proporciono un valor al parámetro… Voilà, ¡está funcionando!

 Resumen

Situaciones similares pueden ocurrir con diferentes causas raíz, pero las más comunes son:

• Problema con elementos opcionales y no opcionales, por lo que un nulo llega a un punto donde debería.
• Errores de validación porque el parámetro de entrada no coincide con la definición del campo.
• Tipos XML extendidos que no son compatibles con la función utilizada.
  

¡Todos estos problemas pueden ser fácilmente y rápidamente resueltos siguiendo el razonamiento que explicamos en este post!

Así que, pongámoslo en práctica la próxima vez que veas a un colega con ese problema y ayúdalo a tener una experiencia de programación más eficiente!

Proporcione más agilidad a sus esfuerzos de resolución de problemas depurando exactamente donde ocurre el error utilizando técnicas de Depuración Remota

La revolución de los contenedores ha proporcionado muchos beneficios, como hemos discutido en profundidad en otros artículos, y al mismo tiempo, también ha proporcionado algunos nuevos desafíos que necesitamos abordar.

Toda la agilidad que ahora tenemos en manos de nuestros desarrolladores también necesita extenderse al trabajo de mantenimiento y solución de problemas. Necesitamos ser ágiles también. Conocemos algunos de los principales problemas que tenemos al respecto: Funciona en mi entorno, con el conjunto de datos que tengo, no pude ver el problema, o no pude reproducir el error, son solo frases que escuchamos una y otra vez y retrasan la resolución de algunos errores o mejoras, incluso cuando la solución es simple, luchamos por obtener un escenario real para probar.

Y aquí es donde entra la Depuración Remota. La Depuración Remota es, tal como su propio nombre indica claramente, poder depurar algo que no es local, que es remoto. Se ha centrado desde su concepción en el Desarrollo Móvil porque no importa cuán bueno sea el simulador. Siempre necesitarás probar en un dispositivo real para asegurarte de que todo funcione correctamente.

Así que este es el mismo concepto pero aplicable a un contenedor, lo que significa que tengo una aplicación TIBCO BusinessWorks ejecutándose en Kubernetes. Queremos depurarla como si estuviera ejecutándose localmente, como se muestra en la imagen anterior. Para poder hacer eso, necesitamos seguir estos pasos:

Habilitar la Depuración Remota en el pod

El primer paso es habilitar la opción de depuración remota en la aplicación y para hacerlo, necesitamos usar la API interna que proporciona BusinessWorks, y para hacerlo, necesitamos ejecutar desde dentro del contenedor:

curl -XPOST http://localhost:8090/bw/bwengine.json/debug/?interface=0.0.0.0&port=5554&engineName=Main

En caso de que no tengamos ninguna herramienta como curl o wget para acceder a una URL dentro del contenedor, siempre puedes usar la estrategia de port-forward para hacer que el puerto 8090 del pod sea accesible para habilitar el puerto de depuración usando un comando similar al siguiente:

kubectl port-forward hello-world-test-78b6f9b4b-25hss 8090:8090

Y luego, podemos acceder desde nuestra máquina local para habilitar la depuración remota

Hacer que el Puerto de Depuración sea accesible para el Studio

Para hacer la depuración remota, necesitamos poder conectar nuestro TIBCO BusinessStudio local a este pod específico que está ejecutando la carga y, para hacerlo, necesitamos tener acceso al puerto de depuración. Para obtener esto, tenemos principalmente dos opciones que son las que se muestran en las subsecciones a continuación: Exponer el puerto a nivel del pod y opción de port-forwarding.

Exponer el puerto a nivel del Pod

Necesitamos tener el puerto de depuración abierto en nuestro pod. Para hacer eso, necesitamos definir otro puerto que no esté en uso por la aplicación, y que no sea el puerto de administración predeterminado (8090) para el que se va a exponer. Por ejemplo, en mi caso, usaré 5554 como el puerto de depuración, y para hacerlo, defino otro puerto para ser accedido.

Opción de Port-Forwarding

Otra opción si no queremos exponer el puerto de depuración todo el tiempo, incluso si no se va a usar a menos que estemos ejecutando la depuración remota, tenemos otra opción para hacer un port-forward al puerto de depuración en nuestro local.

kubectl port-forward hello-world-test-78b6f9b4b-cctgh 5554:5554

Conexión al TIBCO Business Studio

Ahora que tenemos todo listo, necesitamos conectar nuestro TIBCO Business Studio local al pod, y para hacerlo, necesitamos seguir estos pasos:

Ejecutar → Configuraciones de Depuración, y seleccionamos el BusinessWorks Remoto

Y ahora necesitamos proporcionar los detalles de la conexión. Para este caso, usaremos el localhost y el puerto 5554 y haremos clic en el botón de Depuración.

Después de ese momento, estableceremos una conexión entre ambos entornos: el pod ejecutándose en nuestro clúster de Kubernetes y nuestro TIBCO BusinessStudio local. Y tan pronto como accedamos al contenedor, podemos ver la ejecución en nuestro entorno local:

Resumen

Espero que encuentres esto interesante, y si eres uno de los que enfrenta este problema ahora, tienes información para no detenerte por este. Si deseas enviar tus preguntas, no dudes en usar una de las siguientes opciones:

• Twitter: Puedes enviarme una mención a @alexandrev en Twitter o un DM o incluso solo usando el hashtag #TIBFAQS que monitorearé.
• Email: Puedes enviarme un correo electrónico a alexandre.vazquez en gmail.com con tu pregunta.
• Instagram: Puedes enviarme un DM en Instagram a @alexandrev

Descubre cómo el comando OSGI lcfg puede ayudarte a estar seguro de cuál es la configuración en tiempo de ejecución.

Conocer la configuración de TIBCO BW en tiempo de ejecución se ha vuelto crítico ya que siempre necesitas saber si los últimos cambios se han aplicado o simplemente quieres verificar el valor específico de una Propiedad del Módulo como parte de tu desarrollo.

Cuando hablamos de aplicaciones desplegadas en la nube, una de las cosas clave es la Gestión de Configuración. Especialmente si incluimos en la mezcla cosas como Kubernetes, Contenedores, Sistema de Gestión de Configuración Externa, las cosas se complican.

La configuración habitual cuando hablamos de un entorno Kubernetes para la gestión de configuración es el uso de Config Maps o Spring Cloud Config.

Cuando puedes cargar la configuración en un paso separado al de desplegar la aplicación, puedes encontrarte en una situación en la que no estás seguro de cuál es la configuración en ejecución que tiene una aplicación BusinessWorks.

Para verificar la configuración de TIBCO BW hay una manera fácil de saber exactamente los valores actuales:

• Solo necesitamos entrar en el contenedor para poder acceder a la consola interna de OSGI que nos permite ejecutar comandos administrativos.
• Hemos hablado otras veces sobre esa API, pero en caso de que quieras echar un vistazo más profundo solo necesitas revisar este enlace:

• Y uno de los comandos es lcfg que permite saber qué configuración está siendo utilizada por la aplicación que está en ejecución:

curl localhost:8090/bw/framework.json/osgi?command=lcfg

Con una salida similar a esta:

Resumen

Espero que encuentres esto interesante, y si eres uno de los que enfrenta este problema ahora, tienes información para no ser detenido por este. Si deseas enviar tus preguntas, siéntete libre de usar una de las siguientes opciones:

• Twitter: Puedes enviarme una mención a @alexandrev en Twitter o un DM o incluso solo usando el hashtag #TIBFAQs que monitorearé.
• Email: Puedes enviarme un correo electrónico a alexandre.vazquez en gmail.com con tu pregunta.
• Instagram: Puedes enviarme un DM en Instagram a @alexandrev

Aprende las principales razones detrás de un estado Deteriorado y cómo puedes realizar la resolución de problemas para identificar y resolver el error.

Este es otro post de la serie #TIBFAQS. Para recordarte de qué se trata todo esto, puedes enviar tus preguntas sobre problemas o dudas de desarrollo de TIBCO e intentar proporcionar una respuesta aquí para tratar de ayudar a la comunidad de desarrolladores de TIBCO.

Así que hoy voy a comenzar con uno de los problemas más comunes cuando trabajamos con BusinessWorks, y es cuando voy a desplegar mi aplicación o probarla localmente, y obtengo este rastro de registro y nada después de eso: Estado Deteriorado de TIBCO BW.

Esta es una de las situaciones habituales para un desarrollador junior de BusinessWorks y una de las razones por las que pasas más tiempo haciendo resolución de problemas. Vamos a obtener algunos trucos hoy, para que este mensaje nunca más te detenga en tu camino a producción.

¿Cuál es la causa de este error?

Este error significa que el tiempo de ejecución de BusinessWorks no puede cumplir con todas las dependencias entre los componentes para poder iniciar. Como probablemente sepas, en BusinessWorks cada uno de los componentes de las aplicaciones se gestiona de manera independiente y se referencian entre sí.

Por ejemplo, la Aplicación depende del Módulo de Aplicación y el Módulo Compartido. El módulo de Aplicación puede tener una dependencia de una Conexión JMS y así sucesivamente.

Situaciones que pueden provocar este error

Veamos ahora la situación que puede provocar este error y cómo resolverlo.

1.- Módulo faltante o versiones incompatibles

Una situación habitual que puede llevar a este problema es la falta de módulos o versiones incompatibles de los módulos. En ese caso, el componente referenciable esperará un módulo o una versión específica de un módulo para iniciarse. Sin embargo, este módulo falta o está iniciando otra versión.

2.- Conexiones compartidas no válidas

Otra opción puede ser si algunos de los componentes requieren establecer la conexión con otras tecnologías como conexiones JDBC, conexiones JMS, conexiones KAFKA u otro de los más de 200 conectores disponibles.

3.- Componente de Inicio faltante en los Descriptores de Módulo

El último de los sospechosos habituales aquí es cuando tienes un componente de Inicio en los Descriptores de Módulo, pero este proceso no está disponible dentro del archivo EAR que estás desplegando. Esa dependencia nunca se satisface, y eso lleva a un estado Deteriorado ilimitado.

¿Cómo detectar qué componente está faltando?

Para ayudarte en el proceso de detectar en qué situación te encuentras, tienes una herramienta increíble a tu disposición que es el comando la de la Interfaz de Consola OSGi.

Este comando nos ayuda a listar las aplicaciones desplegadas en este AppNode o contenedor específico y nos da los detalles de ellas, incluyendo la razón de una situación Deteriorada.

Cómo ejecutar la consola OSGi depende de tu modelo de despliegue, pero puedes leer toda la información al respecto en el siguiente enlace:

Resumen

Espero que encuentres esto interesante para resolver el estado Deteriorado de TIBCO BW en tus aplicaciones, y si eres uno de los que enfrenta este problema ahora, tienes información para no ser detenido por este. Si deseas enviar tus preguntas, siéntete libre de usar una de las siguientes opciones:

• Twitter: Puedes enviarme una mención a @alexandrev en Twitter o un DM o incluso solo usar el hashtag #TIBFAQs que monitorearé.
• Email: Puedes enviarme un correo electrónico a alexandre.vazquez en gmail.com con tu pregunta.
• Instagram: Puedes enviarme un DM en Instagram a @alexandrev

Este es otro post de la serie #TIBFAQS y solo para recordarte de qué se trata todo esto es que puedes enviar tus preguntas sobre problemas o dudas de desarrollo de TIBCO y trato de proporcionar una respuesta aquí para intentar ayudar a la comunidad de desarrolladores de TIBCO allá afuera.

Así que hoy voy a comenzar con uno de los que creo que son los problemas más comunes cuando trabajamos con BusinessWorks Container Edition y estamos desplegando en nuestro entorno objetivo y es un rastro similar a este:

¿Cuál es la causa de este error?

Este error significa que el runtime de BusinessWorks no puede leer y procesar el archivo de propiedades para iniciar la aplicación. Así que eso significa que tu error está relacionado con la configuración de la aplicación y no con la aplicación en sí. Así que, la buena noticia aquí: tu código parece estar bien en este punto.

Como probablemente sabes, todas las aplicaciones de TIBCO BW usan desde hace mucho tiempo un archivo XML para tener los valores de configuración para comenzar. Este es el archivo que en el caso de BusinessWorks Container Edition se almacena en /tmp/tmp/pcf.substvar y se llena de varias fuentes dependiendo de cómo manejes tu configuración.

Como sabes, tienes varias opciones para manejar tu configuración en entornos basados en la nube: Variables de entorno, Mapas de Configuración, Sistemas de Gestión de Configuración como Spring Cloud Config o Consul… Así que es importante que tengas una comprensión clara de lo que estás usando.

Así que el error es que el archivo tiene algo en su contenido que no es válido, porque está mal o porque no puede entenderlo.

Situaciones que pueden provocar este error

Veamos ahora la situación que puede provocar este error y cómo podemos solucionarlo.

1.- Incompatibilidad entre versiones de BW-runtime y EAR

Normalmente, los archivos EAR son compatibles con diferentes runtimes de BusinessWorks, pero esto es cierto cuando el runtime es más actual que el EAR. Así que quiero decir, si genero mi aplicación con BWCE 2.5.0 puedo ejecutarla con runtime 2.5.0, o 2.5.3 o 2.6.0 sin ningún problema, pero si intento ejecutarla con una versión más antigua como 2.4.2 puedo obtener este error porque el archivo EAR tiene algunas «cosas nuevas» que el runtime no puede entender.

Así que es importante validar que la versión del runtime que estás usando es la esperada y actualizarla si ese no es el caso.

2.- Caracteres especiales de XML que necesitan ser escapados

Esta situación solo es cierta en versiones anteriores a la 2.5.0, pero en caso de que estés ejecutando una versión más antigua, también puedes obtener este error porque el valor de tu propiedad tiene un carácter XML que necesita ser escapado. Caracteres como ‘<’ o ‘&’ son los más utilizados para generar este error. Si estás usando una versión más actualizada no necesitas escaparlos porque se escapan automáticamente.

Así que dependiendo de la versión que estés usando, actualiza el valor de tu propiedad en consecuencia.

Resumen

Espero que encuentres esto interesante y si eres uno de los que enfrenta este problema ahora tienes información para no detenerte por este. Si deseas enviar tus preguntas, siéntete libre de usar una de las siguientes opciones:

• Twitter: Puedes enviarme una mención a @alexandrev en Twitter o un DM o incluso solo usando el hashtag #TIBFAQs que monitorearé.
• Email: Puedes enviarme un correo electrónico a alexandre.vazquez en gmail.com con tu pregunta.
• Instagram: Puedes enviarme un DM en Instagram a @alexandrev

Mejora tu conocimiento sobre la tecnología TIBCO y también resuelve los problemas que enfrentas en tus tareas diarias de desarrollo

¡TIBFAQS está aquí! Este nuevo año me gustaría comenzar varias iniciativas, y espero que puedas acompañarme durante este viaje. Como sabrás, soy un Arquitecto de TIBCO, así que en mis actividades diarias recibo muchas preguntas e inquietudes sobre cómo hacer diferentes cosas con la tecnología TIBCO, desde TIBCO BusinessWorks hasta TIBCO EMS o TIBCO Spotfire.

He notado que algunas de estas preguntas son similares de un cliente a otro, así que me gustaría usar esta plataforma para compartir todo este conocimiento para beneficiarnos en nuestras actividades diarias y usar la tecnología de la manera más eficiente.

1.- ¿Cómo va a funcionar esto?

Utilizaré algunos de los temas comunes que conozco en términos de preguntas de desarrollo de TIBCO y crearé un artículo periódico cubriéndolo con detalle y con una aplicación de muestra que muestre el problema y la solución. Todo el código estará disponible en mi repositorio de GitHub para que lo uses como referencia.

https://github.com/alexandrev

2.- ¿Puedo enviarte mis preguntas?

¡Sí, claro! ¡Eso sería increíble! Como dije, me gustaría crear una comunidad participativa alrededor de estas publicaciones para que todos podamos beneficiarnos de ello. Así que me gustaría ver tus preguntas y para enviármelas puedes hacerlo de las siguientes maneras:

• Twitter: Puedes enviarme una mención a @alexandrev en Twitter o un DM o incluso solo usando el hashtag #TIBFAQs que estaré monitoreando.
• Email: Puedes enviarme un correo electrónico a alexandre.vazquez en gmail.com con tu pregunta.
• Instagram: Puedes enviarme un DM en Instagram a @alexandrev

3.- ¿Dónde va a comenzar esto?

Esto comenzará a finales de enero. La idea es tener al menos un artículo con una periodicidad quincenal, pero eso dependerá mucho del compromiso con esta iniciativa. Cuanto más compartas y hables sobre esta iniciativa con tus compañeros, y cuantas más preguntas me envíes, más artículos crearé.

4.- ¿Qué sigue?

Desde hoy puedes comenzar a enviar tus preguntas y compartir tus comentarios sobre esta iniciativa, y puedes seguir este blog para esperar los artículos que vendrán. ¡Hagámoslo juntos!