Configuracion de Tracing
De
<keywords content="keywords"> seguimiento, tracing, errores, advertencias, traza, todo, trazas, rastros, traces, debug </keywords>
Contenido |
Debug y Trazas en Bizagi (Tracing)
Introducción
Durante el desarrollo de un proceso hay situaciones en donde las expresiones, reglas, validaciones, interfaces e incluso el mismo proceso se comportan de manera inesperada. Puede Por ello los usuarios necesitan identificar el origen dentro de todos estos factores y hacer seguimiento de todos los elementos que lo componen.
Para identificar qué no está funcionando correctamente se pueden activar los traces (o trazas) para hacer seguimiento a la ejecución del proceso. Bizagi cuenta con una funcionalidad muy poderosa y detallada de Logs y trazas la cual crea uno o varios archivos planos para que sean revisados después de la ejecución y hacer un seguimiento a varios niveles. Estos niveles empiezan en el proceso y pasan por actividades, reglas de asignación, validaciones, expresiones de negocio, interfaces y llegan hasta la generación de formas y campos. En otras palabras, es posible hacerle seguimiento a todo el proceso y los objetos que lo conforman durante la ejecución de un caso en la aplicación web.
Ademas del detalle, también es posible seleccionar la prioridad del suceso, permitiendo generar todo un log de todo lo que ocurre en la aplicación, o solamente advertencias y errores o solamente errores.
¿Cómo funcionan?
La funcionalidad de trazas está orientada a ambiente de desarrollo, sin embargo, pueden llegar a ser muy útiles para detectar errores en pruebas y en producción de igual manera.
Para activar las trazas y hacer un seguimiento al proceso, se siguen los siguientes pasos: habilitar las trazas (los diferentes tipos), y definir el detalle de la traza.
Habilitar las trazas (diferentes tipos)
Para habilitar las trazas, seleccione la opción Seguimiento (Tracing) del menú estándar en Bizagi Studio (para ambiente de desarrollo):
De igual manera se pueden configurar también estas opciones de trazas "Tracing" desde la Consola de Administración (especialmente para el ambiente de Pruebas o Producción):
De ambas maneras, la ventana de opciones "Tracing" mostrará los diferentes tipos de trazas para habilitar. Como se enseña en la tabla a continuación, son 7 tipos de trazas principales:
|
Elemento |
Descripción |
|
|
Registra cuándo comienza una transacción, cuándo se salva la información en la base de datos, cuándo se crea un caso y la ejecución de cada figura. Cuando se selecciona "Asignación (Assignment)", entonces se registra la evaluación en las reglas de asignación. |
|
|
Se registra la ejecución de los cambios en la base de datos. |
|
|
Registra cuándo la capa SOA se usa para trazar solicitudes y respuestas. |
|
|
Registra la construcción de la formas y sus campos en la aplicación Web. |
|
|
Registra la evaluación de reglas y políticas. Si se ha seleccionado "Personalizado(Custom)" también, entonces se registran las trazas que el usuario ha solicitado en la ejecución de Reglas de Negocio usando la función CHelper.trace (ejemplo y utilización). |
|
|
Registra la sincronización de usuarios desde el LDAP. |
|
|
Registra la ejecucíón de las tareas que realiza el servicio programador (scheduler). |
Definir el detalle de la traza
Para definir exactamente qué rastrear (el nivel de detalle), desde la misma ventana haga clic sobre el tipo de traza (o seleccione varios) y defina el nivel de detalle que desea en los archivos de seguimiento: Error, Warning, All.
- Cuando Error es seleccionado, el archivo de texto sólo contendrá registros de errores.
- Cuando Advertencia (Warning) es seleccionado, el archivo de trazas registrará errores y advertencias.
- Cuando Todo (All) es seleccionado, el archivo contendrá errores, advertencias e información paso a paso sobre la operación de Bizagi.
En esta configuración, puede definir diferentes niveles de detalle para los diversos tipos de trazas:
Después de realizar cambios, es posible que se requiera reiniciar el Servicio del servidor (por ejemplo y si se usa IIS, entonces un IISreset).
Ubicación de las trazas
Once enabled, traces will be located as plain text files on the BPM Server.
This path is different according to the specific web and application server used in the BPM Server.
Para Bizagi Xpress o Bizagi Enterprise .Net
En proyectos que utilicen IIS (ambientes en .Net), las trazas quedarán en la ruta:
C:\Bizagi\[bizagi_edition]\Projects\[project_name]\Trace
Las trazas de tipo interfaces SOA quedarán en una ruta separada a la anterior, y está será:
C:\Bizagi\[bizagi_edition]\Projects\[project_name]\SOA
Para Bizagi Enterprise JEE
En proyectos que utilicen un servidor de aplicaciones JEE (ambientes basados en la plataforma de Java), las trazas se almacenan en una ruta diferente, y de acuerdo a la plataforma.
En sistemas opertivos Linux, esta ruta será la carpeta temporal del usuario (como se haya definido previamente en el sistema operativo).
En sistemas operativos Windows, esta ruta será:
C:\Windows\Temp
Las trazas de tipo interfaces SOA quedarán en una ruta separada a la anterior, y está será la carpeta bin del servidor de aplicaciones JEE.
Consideraciones adicionales en la edición JEE
Para la edición Bizagi Enteprise JEE, se presenta una ventana ligeramente diferente. Las mismas opciones de trazas se encuentran disponible, a excepción de la subcategoría de SOAP message body (Request y Response), de la categoría Interfaces:
Ejemplos
Como se ha mencionado anteriormente, hay más de un tipo de traza en Bizagi.
En los siguientes ejemplos, vamos a ilustrar cómo interpretar algunos de los archivos de trazas más frecuentemente utilizados como lo son: la traza de la ejecución del portal de trabajo (aplicación web), los archivos de traza de la ejecución de las reglas de negocio, y las trazas de interfaces SOA cuando se invocan servicios web externos.
Traza del portal de trabajo (aplicación web)
Toda la información de seguimiento sobre el proceso se encuentra en el archivo BATrace_Web de la ruta de trazas (en este ejemplo de .Net, esta será C:\Bizagi\[edición_Bizagi]\Projects\[nombre_proyecto]\Trace).
En este archivo es donde reside la información que hemos activado en la configuración de Tracing en Bizagi Studio o en la Consola de Bizagi.
1. En la primera parte del archivo, tenemos la cabecera que tiene información importante acerca del software, versión y plataforma sobre la que esta corriendo la aplicación web.
2. Luego , están los nombres de las columnas para interpretar los datos como fecha de registro de evento, nivel, modulo, submodulo y mensaje.
3. Dentro de los módulos están los objetos que hacen funcionar todo el workflow como reglas, asignaciones, workflow, compuertas, políticas, validaciones etc.
4. Dentro del mensaje de cada evento, esta la descripción detallada de lo que esta ocurriendo como por ejemplo cuando inicia una actividad, que numero d caso se ha generado, identificadores de tareas y usuarios asignados y mas información paso a paso.
5. En caso de que ocurra un error, aparecerá dentro de este archivo como ERROR WORKFLOW y dentro del detalle estará el mensaje de error para ser interpretado.
Trazas en Expresiones (reglas)
Además de seleccionar el nivel y las opciones de las trazas, para las Expresiones es necesario incluir una sentencia en el código de la regla y así identificar qué es exactamente lo que se quiere rastrear.
Dé clic para conocer más acerca de Trazas en las Expresiones
Trazas en Intefaces SOA
La utilidad para hacer seguimiento (trace) sobre las invocaciones de interfaces SOA tiene un gran nivel de detalle en Bizagi, brindando la posibilidad de ver el mensaje de envío (Request) y de respuesta (Response) de los sistemas externos, así como el resultado de las transformaciones. De esta forma, podemos detectar en que lado de la comunicación está el error, cuando se presenta en estas integraciones.
En caso de que ocurra un error de una interfaz, se debe habilitar la función de traces en las interfaces (Tracing-Workflow-Interfaces) y revisar los archivos y validar que los mensajes y su estructura estén de acuerdo con la estructura y del modelo de datos de Bizagi.
Por ejemplo, si la interfaz para generar el archivo de la orden de compra (pdf) en el proceso de Orden De Compra fallara, se debe habilitar los traces y revisar los archivos generados y así detectar la falla de comunicación.
1. Detectar el error
En este caso, el error es lanzado por una actividad asíncrona. El detalle del error se consulta en el menú de Admin, en los reintentos de actividades asíncronas ("Asynchronous Work item Retries").
2. Habilitar el seguimiento de las interfaces
3. Ejecutar nuevamente la interfaz para reproducir el error.
Ir a la carpeta C:\Bizagi\[Enterprise o Xpress]\Projects\"Nombre del proyecto"\SOA.
Observar que existen 6 tipos de archivo XML por cada intento de una interfaz. Para su fácil identificación, el nombre de estos archivos esta conformado por el numero del caso, el tipo de archivo y la fecha y hora en que fueron ejecutados.
Existen 6 tipos de archivos:
- Salida (Request)
- Salida Transformada(RequestTransformed)
- Salida del cuerpo del documento XML (SOAP Body Request)
- Respuesta(Response)
- Respuesta Transformada (ResponseTransformed)
- Respuesta del cuerpo del documento XML (SOAP Body Response)
Es importante aclarar que no en todos los casos aparecen los 6 archivos. Por ejemplo, si existe un error en la extracción de los datos en Bizagi, entonces solamente aparecerá el primer archivo (Request) ya que en ese momento ocurre el error luego la comunicación no es completa.
Por otro lado, si las interfaces no manejan archivos de transformación estos lógicamente no aparecerán. Las siguiente imágenes enseñan los 6 tipos de archivos de seguimiento para SOA.La primera imagen resalta los archivos de seguimiento para el request (petición de información) en orden cronológico:
1. El Request registra la información que se obtiene de Bizagi.
2. El RequestTransformed registra la información que se obtiene de Bizagi después de aplicar una transformación XSLT.
3. SOAPBody Request registra el cuerpo (body) de la estrucura de información XML tal como se envia al sistema externo (nótese que el "SOAP header" no se incluye, ya que esta información puede contener información privada tal como credenciales autorizadas para la invocación).
Esta imagen resalta los archivos de seguimiento del response (respuesta) en orden cronológico:
1. SOAPBody Response registra el cuerpo (body) de la estrucura de información XML tal como se recibe desde el sistema externo (nuevamente, el "SOAP header" no se incluye).
2. Response registra la información que se obtiene del sistema externo, presentado como datos de entrada para Bizagi.
3. ResponseTransformed registra la información que se obtiene del sistema externo después de aplicar una transformación XSLT.
4. Validar uno por uno los archivos hasta identificar el error
En este caso, si observamos la respuesta del servicio en el archivo : BizagiSOARequestTransformed , vemos que la respuesta trae el tag <Quotation>, pero la entidad se llama Quotations, por lo cual genera el mensaje de error de “Quotation : Relacion no encontrada.”
Artículos Relacionados
<comments />
