Introducción
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 del Conector de servicios Web
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.
|
Tenga en cuenta que los Traces de interfaces pueden habilitarse en cualquier momento, sin embargo, se recomienda enfáticamente solo habilitarlos de manera temporal (después de obtener el detalle deben ser desactivados). Los cambios en la configuración de Traces posiblemente requieran reiniciar los servicios de su servidor Bizagi. |
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 seis puntos donde se registra detalle que es útil para diagnosticar si el problema está internamente en el servicio Web externo, 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 |
Solicitud |
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 |
Solicitud transformada |
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 |
Mensaje SOAP - Solicitud |
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 |
Mensaje SOAP - Respuesta |
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 |
Respuesta |
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 |
Respuesta transformada |
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 dos 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 |
JSON de mapping de envío |
Ú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. |
JSON de mapping de respuesta |
Ú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 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 de este 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 dos propiedades: el timeout de la actividad asíncrona, o el time-out específico de la invocación (dado a la interfaz a través de su administración desde el módulo de sistemas).
¿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.
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 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.
Last Updated 1/30/2024 4:06:08 PM