Diagnóstico de los errores de los Conectores

<< Clic para mostrar Tabla de Contenidos >>

Navegación:  Automation Server > Automation Server - configuración y administración > Mantenimiento y monitoreo del sistema > Configuración y administración del ambiente > Managment Console > Diagnóstico de los sistemas integrados >

Diagnóstico de los errores de los Conectores

Introducción

Cuando configure conectores en Bizagi, puede utilizar varias funcionalidades para control de errores y diagnóstico.

Una de estas funcionalidades es el uso de Traces cuando detecte que hay un problema con la ejecución del conector y desee traer información adicional.

 

Antes de depurar sus conectores, asegúrese de que el servicio Bizagi Connector Service esté en ejecución. De lo contrario, el conector no funcionará ni generará traces.

 

Connector_Service

 

Traces para Conectores

Cuando esté depurando la ejecución de un conector (en ambientes de desarrollo) o cuando quiera traer detalles adicionales sobre la ejecución fallida de los mismos, usted puede prender los traces de Conectores externos.

 

Connectors_trace_all

 

note_pin

Tenga en cuenta que los traces para conectores pueden ser habilitados en cualquier momento. pero es altamente recomendado habilitarlos temporalmente solo cuando se necesite (y por supuesto, deshabilitarlos).

Los cambios en esta configuración pueden requerir reiniciar los servicios Bizagi de su servidor.

 

Habilitar estos traces es útil para rastrear, después de un error, el punto exacto donde sucedió dicho error. Hay 5 puntos donde se registra el detalle y usted puede diagnosticar si hay un problema en la ejecución de su conector o cuándo se aplicaron las transformaciones de la información.

 

Tipos de traces

Los siguientes traces son registrados como se detalla en la siguiente tabla.

 

Orden cronológico

Tipo de trace

Descripción

1

Entradas

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

Su nombre tiene la siguiente convención:

[Fecha_y_Hora]_[identificador_caso]_IN0_[Nombre_Conector]_[Nombre_acción].json

Tenga en cuenta que la fecha y hora es yyyyMMddHHmmss.

2

Entradas transformadas

Deja un archivo JSON con las entradas enviadas al conector después de la ejecución de su lógica.

Su nombre tiene la siguiente convención:

[Fecha_y_Hora]_[identificador_caso]_IN1_[Nombre_Conector]_[Nombre_acción].json

Tenga en cuenta que la fecha y hora es yyyyMMddHHmmss.

3

Salidas

Deja un archivo JSON con las salidas recibidas desde el sistema externo antes de cualquier transformación hecha por Bizagi.

Su nombre tiene la siguiente convención:

[Fecha_y_Hora]_[identificador_caso]_OU0_[Nombre_Conector]_[Nombre_acción].json

Tenga en cuenta que la fecha y hora es yyyyMMddHHmmss.

4

Salidas transformadas

Deja un archivo JSON con las salidas recibidas desde el sistema externo después de todas las transformaciones hechas por Bizagi.

Su nombre tiene la siguiente convención:

[Fecha_y_Hora]_[identificador_caso]_OU1_[Nombre_Conector]_[Nombre_acción].json

Tenga en cuenta que la fecha y hora es yyyyMMddHHmmss.

5

Lógica del conector

Deja cuatro archivos .log:

Logs del Conector

[Nombre_Conector].[Nombre_Conector].log almacena todos los comandos LOG encontrados durante la ejecución de la lógica del conector. Más información sobre estos comandos se puede encontrar en este artículo.

Logs del servicio

bz-facade.log almacena el historial de métodos invocados por el servicio de conector.

facade-exceptions.log Almacena los errores provocados por funciones asíncronas. Por ejemplo, error en la devolución de llamada de una solicitud REST.

[Nombre_Conector]-bz-ctrl.log almacena los registros del controlador de servicio del conector.

Tenga en cuenta que la fecha y hora es yyyyMMddHHmm.

 

Medida adicional orientada al control de errores

Es altamente recomendado que también defina el tiempo esperado del servicio, de tal forma que pueda asignar: un tiempo de espera para el servicio y  un umbral para el registro.

Estas propiedades pueden ser configuradas en las propiedades de la interfaz específica:

Le parámetro del umbral para el registro de las interfaces deja un registro para alertarlo sobre aquellas interfaces cuya invocación está tardando más de lo esperado (más de lo usual). De esta forma, usted puede realizar diagnósticos tempranos en su servicio web y en cualquier variable adicional que afecte el desempeño.

El timeout lanzado en la invocación de un servicio es debido a que éste se está demorando más tiempo del tiempo de espera definido.

Para un servicio invocado desde una actividad asíncrona, la definición del tiempo de espera se toma del menor tiempo entre la propiedad de tiempo de espera configurada en la tarea asíncrona y la de la interfaz especifica (a través de administración de interfaces en el módulo de sistemas).

 

¿Cómo rastrear su conector?

Con los siguientes pasos, vamos a ilustrar cómo utilizar el rastreo de invocación de interfaces para detectar y diagnosticar problemas en invocaciones de conectores.

 

1. Detecte el error

Como práctica más común, usted puede encontrar que su conector es invocado desde una actividad asíncrona.

Si la invocación falla, se pueden ver errores adicionales desde el menú Admin, en la opción Consola de actividades asíncronas.

 

WSTrace_console

 

2. Prepare la configuración de traces

A través de las opciones de traces, habilite todos los traces de Interfaces.

 

3. Vuelva a ejecutar la invocación de la interfaz (para obetener el detalle del error)

Reintente la invocación de la interfaz para tener un registro detallado.

 

Después, navegue en su servidor Bizagi y en las carpetas de traces de los Conectores (en este ejemplo de .NET, la ubicación sería C:\Bizagi\Projects\[nombre_proyecto]\Temporary\Connectors y C:\Program Files\Bizagi\Bizagi Studio\ConnectorsService\framework\Logs\Connectors\[nombre_proyecto]).

 

Es importante destacar que no en todos los casos podría tener todos los archivos guardados.

Por ejemplo. si ocurre un error en la transformación de las entradas desde Bizagi, solamente aparecerá el primer archivo (entradas) debido a que el error ocurre antes de realizar la transformación.

 

4. Valide los traces para identificar el error (uno a uno)

Valide la información contenida en estas traces.

 

Monitor del servicio de conectores

Cuando instala Bizagi, adicional al servicio de conectores, se instala una tarea programada de Windows, que monitorea constantemente la actividad del servicio de conectores registra en un log si el servicio se está ejecutando.Si el servicio no está corriendo,  esta tarea intenta restablecer el servicio, para que pueda ejecutarse nuevamente.

 

Tarea programada

Cuando abre el Programador de tareas en el servidor Windows donde está instalado Bizagi, puede encontrar la carpeta del Monitor de conector, en la Biblioteca del Programador de tareas.

 

ConnectorMonitor_1

 

Lo que hace esta tarea es ejecutar un conector ficticio, que verifica que los servicios del conector estén funcionando correctamente. Esta tarea está configurada para ejecutarse cada tres minutos, de la siguiente manera:

 

ConnectorMonitor_2

 

note_pin

No recomendamos reducir el tiempo de repetición porque puede afectar el rendimiento del servicio Connector.

 

Los logs asociados a esta tarea se guardan en la siguiente ruta:

 

Bizagi Studio: C:\Program Files\Bizagi\Bizagi Studio\ConnectorsService

Bizagi Engine: C:\Program Files\Bizagi\Engine\ConnectorsService

 

Aquí encuentra el archivo Monitor.text

 

ConnectorMonitor_3

 

Los conectores en Bizagi usar el framework Node.js, por lo que es importante controlar que no solo se esté ejecutando el servicio de Windows, sino también que el marco funciona correctamente. Entonces, esta tarea ejecuta dos tareas de monitoreo: la primera revisa el estado del servicio de Windows Connector, la segunda revisa que el framework node.js funciona correctamente.

 

Cada registro en el log tiene la siguiente estructura:

[TimeStamp] _ [Componente] _ [Mensaje]

 

Time Stamp: WeekDay dd/mm/yyyy HH:mm:ss:ms  

Componente: Monitor.bat es el resultado de una solicitud al servicio de WIndows. Flow monitor.bat es la solicitud al framework node.js.