Diagnóstico y control de errores para conectores

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Administración del Sistema Bizagi > Mantenimiento y administración > Administración del entorno > Diagnóstico y control de errores >

Diagnóstico y control de errores para conectores

Cuando se configuran conectores en Bizagi, puede contar con varias opciones para el diagnóstico y control de errores.

Una de las opciones es el uso de Traces cuando se detecta que hay un inconveniente con la ejecución de un conector, y por lo tanto se desea obtener mayor detalle sobre este.

 

 

Traces de Conector

Cuando se hace debug a un conector (en ambientes de desarrollo) o cuando se desea obtener log detallado sobre una ejecución fallida, se pueden habilitar los Traces de WS Connector.

 

Connectors_trace_all

 

 

note_pin

Tenga en cuenta que los Traces de conectores pueden habilitarse desde Bizagi Studio o desde el Management Console y se recomienda enfáticamente solo habilitarlos de manera temporal (después de obtener el detalle deben ser deshabilitados).

Los cambios en la configuración de Traces posiblemente requieran reiniciar los servicios de su Portal de trabajo.

 

 

La habilitación de los Traces es útil para detectar en qué punto exactamente hubo un fallo en la ejecución, principalmente porque se cuentan con 5 puntos donde se registra detalle que es útil para diagnosticar si el problema está al ejecutar el conector, o en cualquiera de las transformaciones aplicadas a la información.

 

Tipos de Traces

Los siguientes Traces se registran en un orden cronológico.

 

Orden cronológico

Tipo de Trace

Descripción

1

Entradas de la acción

Registra un archivo JSON con las entradas de la acción enviadas al conector antes de la ejecución de su lógica.

Su nombre tiene la siguiente estructura:

[timestamp]_[identificador_del_caso]_IN0_[Nombre_del_conector]_[nombe_de la acción].json

Nótese que el timestamp se define como: yyyyMMddHHmmss.

2

Entradas de la acción transformadas

Registra un archivo JSON, con la información de negocio después  de aplicar una transformación por la ejecución de la lógica del conector.

El nombre de este archivo sigue esta estructura:

[timestamp]_[identificador_del_caso]_IN1_[Nombre_del_conector]_[nombre de la acción].json

Nótese que el timestamp se define como: yyyyMMddHHmmss.

3

Salidas de la acción

Registra un archivo JSON con las salidas de la acción recibidas del conector antes de la ejecución de su lógica.

Su nombre tiene la siguiente estructura:

[timestamp]_[identificador_del_caso]_OU0_[Nombre_del_conector]_[nombre de la acción].json

Nótese que el timestamp se define como: yyyyMMddHHmmss.

4

Salidas de la acción transformadas

Registra un archivo JSON con las salidas de la acción recibidas del conector antes de la después de su lógica.

Su nombre tiene la siguiente estructura:

[timestamp]_[identificador_del_caso]_OU1_[Nombre_del_conector]_[nombre de la acción].json

Nótese que el timestamp se define como: yyyyMMddHHmmss.

5

Lógica del conector

Registra un archivo .log que almacena todos los comandos LOG encontrados durante la ejecución de la lógica del conector. Más información acerca de dichos comandos puede ser encontrada en este artículo..

El nombre de este archivo sigue esta estructura:

[nombre del proyecto]-bz-ctrl.log

 

Medida adicional para el control de errores

Se recomienda enfáticamente que se definan los tiempos esperados para la invocación de un servicio externo, de manera que se pueda tener explícitamente un valor para: el time-out del servicio, y el tiempo esperado de umbral de la respuesta (logging threshold).

El parámetro para definir el tiempo umbral de respuesta para las interfaces provee un log que da alertas sobre aquellas interfaces que se están demorando más del tiempo esperado. De esta manera, se puede hacer un diagnóstico a los servicios Web y un control anticipado para revisar las variables que puedan estar afectando el desempeño del sistema externo.

El time-out arrojado por un servicio se da cuando la invocación del mismo es más demorada que su definición de time-out (o tiempo de espera).

Cuando el servicio es invocado desde una actividad asíncrona, esta definición se toma del menor tiempo asignado a cualquiera de las 2 propiedades: el timeout de la actividad asíncrona, o el time-out específico de la invocación (dado a la interface a través de su administración desde el módulo de sistemas).

 

Para mayor información sobre estas opciones, consulte la Administración de interfaces.

 

 

¿Cómo diagnosticar la invocación a un servicio Web?

Con los siguientes pasos, ilustramos cómo utilizar los Traces de interfaces para detectar o diagnosticar errores en la invocación de servicios externos.

 

1. Detectar el error

Partiendo de las prácticas comunes, podrá verificar si hay algún error en la invocación de un servicio Web a través de la Consola de actividades asíncronas (desde las opciones de Administración, ubicada como Asynchronous Activities console).

Esto aplica para las actividades asíncronas.

 

WSTrace_console

 

 

2. Habilite los Traces

A través de Traces, habilite todos los que se utilizan en interfaces.

 

3. Vuelva a ejecutar la invocación (para obtener el log)

Ejecute un reintento de la invocación para que se registre un log detallado.

 

Seguidamente, ubique en la ruta de su servidor Bizagi en la carpeta Connectors, el log de la ejecución (en este ejemplo con .NET, la ubicación es C:\Bizagi\Projects\[nombre del proyecto]\Temporary\Connectors).

 

Es muy importante tener en cuenta que no en todos los escenarios, se visualizarán todos los tipos de logs.

Por ejemplo, si el error ocurre en la extracción de información desde Bizagi, entonces solamente el primer log (Request mapping) quedará registrado dado que el error ocurre antes de que siquiera se realice la invocación.

 

4. Validar los Traces para identificar el error (uno por uno)

Valide la información que se registra en estos logs.