Diagnóstico y control de errores para servicios Web

<< 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 servicios Web

Cuando se configuran invocaciones a servicios Web desde 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 invocación a un servicio Web, y por lo tanto se desea obtener mayor detalle sobre este.

 

 

Traces de WS Connector

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

 

WSTrace_all_patch

 

 

note_pin

Tenga en cuenta que los Traces de interfaces 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 6 puntos donde se registra detalle que es útil para diagnosticar si el problema está internamente en el servicio Web exterrno, o si se produjo cuando se realizaban transformaciones de datos a la información de Bizagi.

 

 

Tipos de Traces

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

 

Orden cronológico

Tipo de Trace

Descripción

1

Request

Registra un log con estructura XML, con la información de negocio extraída desde Bizagi.

El nombre de este archivo sigue esta estructura:

[identificador_del_caso]_BizAgiSOARequest_[timestamp].json

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

2

Request transformed

Registra un log con estructura XML, con la información de negocio después  de aplicar una transformación a los datos extraídos desde Bizagi.

El nombre de este archivo sigue esta estructura:

[identificador_del_caso]_BizAgiSOARequest_[timestamp].json

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

3

SOAP Message body - Request

Aplica para las invocaciones a servicios Web de tipo SOAP (los de tipo REST no se incluyen).

 

Registra un log la información detallada de la invocación, particularmente sobre los datos enviados en el request (solicitud).

Esta información queda en un archivo con esta estructura:

SOAP_TraceVersion02_[timestamp].svclog

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

 

En versiones anteriores de Bizagi, se registra el contenido del XML justo como se envía al servicio externo pero sin los datos que van en la cabecera de SOAP (sin el SOAP Header).

4

SOAP Message body - Response

Aplica para las invocaciones a servicios Web de tipo SOAP (los de tipo REST no se incluyen).

 

Registra un log la información detallada de la invocación, particularmente sobre los datos recibidos en la respuesta (response).

Esta información queda en un archivo con esta estructura:

SOAP_TraceVersion02_[timestamp].svclog

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

 

En versiones anteriores de Bizagi, se registra el contenido del XML justo como se recibe del servicio externo pero sin los datos que van en la cabecera de SOAP (sin el SOAP Header).

5

Response

Registra un log con estructura XML, con la información de negocio tal y como es retornada por la respuesta del servicio Web.

El nombre de este archivo sigue esta estructura:

[identificador_del_caso]_BizAgiSOAResponse_[timestamp].json

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

6

Response transformed

Registra un log con estructura XML, con la información de negocio después de aplicar una transformación a los datos retornados por la respuesta del servicio Web.

El nombre de este archivo sigue esta estructura:

[identificador_del_caso]_BizAgiSOAResponseTransformed_[timestamp].json

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

 

Además de los anteriores, existen 2 trazas adicionales que proporcionan una ayuda para verificar cómo quedó configurado el mapeo de los datos de entrada y datos de salida.

 

Tipo de Trace

Descripción

Request mapping JSON

Útil principalmente para el ambiente de producción, como medida inmediata para la consulta de la configuración del mapeo.

 

Registra un log con estructura JSON, con la información sobre cómo se realizó el mapeo para los datos de entrada (involucrando las transformaciones necesarias).

El nombre de este archivo sigue esta estructura:

[identificador_del_caso]_BizAgiSOARequestMapping_[timestamp].json

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

Response mapping JSON

Útil principalmente para el ambiente de producción, como medida inmediata para la consulta de la configuración del mapeo.

 

Registra un log con estructura JSON, con la información sobre cómo se realizó el mapeo para los datos de salida (involucrando las transformaciones necesarias).

El nombre de este archivo sigue esta estructura:

[identificador_del_caso]_BizAgiSOAResponseMapping_[timestamp].json

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

 

 

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 respuessta 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 traves 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 de Bizagi en la carpeta SOA, el log de la ejecución (en este ejemplo con .NET, la ubicación es C:\Bizagi\[edición_Bizagi]\Projects\[nombre_proyecto]\SOA).

 

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.
 

Si encuentra que todos los archivos de request están allí, entonces el error debe estar justo cuando Bizagi invoca el servicio Web, y podrá revisar el archivo SOAP_TraceVersion02_[timestamp].svclog o enviarlo a nuestro equipo de soporte.

 

WSTrace_svclog

 

Tenga en cuenta que este tipo de log puede ser visualizado con herramientas como SvcTraceViewer de Microsoft, que usualmente vienen en el framework 4.0 de .NET.

 

WSTrace_prog