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.
Traces para Conectores
Cuando esté depurando la ejecución de un conector (en ambientes de desarrollo) o cuando quiera conocer detalles adicionales sobre la ejecución fallida de los mismos, usted puede prender los traces de Conectores externos.
|
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 posteriormente 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 cinco 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.
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.
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:
|
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
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.