Introducción
Bizagi provee un asistente de interfaces para configurar fácilmente la invocación de servicios externos en integración a nivel de Proceso (sin necesidad de programar).
Este Asistente brinda pasos asistidos para configurar el mapeo de parámetros involucrados en la invocación de esos servicios (servicios Web o REST), y cómo manejar posibles errores de negocio en tales invocaciones (un manejo de errores funcionales diferente al manejo de errores técnicos).
Cuando se aplica la integración de aplicación en Procesos (por ejemplo, verificando alguna información en un servicio externo, consultar información de clientes, actualizar el sistema de nómina, etc), la integración aplicada puede responder con un error de negocio.
Los errores de negocio hacen referencia a mensajes tales como "No se encontró el cliente", "La operación no se pudo completar debido a razones internas", entre otros.
El Asistente de interfaz guía al usuario paso a paso para evaluar y manejar errores de negocio potenciales en flujos de Proceso e implementarlos acordemente.
Usted puede mostrar distintos mensajes de error específicos o lanzar un Evento de Error para causar una transición a un estado diferente del flujo.
Configuración de manejo de errores
El manejo de errores se implementa en el último paso (Manejo de Errores) del Asistente de Interfaces.
Adicionalmente, para convertir las respuesta de la invocación, la cual se envía por una aplicación externa en formato XML, también se puede definir cierta información contenida en esta respuesta.
Esto se hace de la siguiente manera:
1. Decidir la acción correctiva del error.
Esto implica especificar si se envía un mensaje de error o se lanza un evento de error para disparar una transición.
2. Definir la respuesta de error.
Esto implica crear una tabla de decisión para asignar la información encontrada en el XML de salida, cuando se lanza un error o excepción durante el servicio.
Ejemplo
En el siguiente ejemplo, consideraremos el Proceso de Crédito que invoca un servicio Web externo, para verificar si un cliente está en la lista negra.
Bizagi debería mostrar mensajes de error generados por el servicio externo, si se plantean (por ejemplo, cuando el resultado del Código de Error tiene un valor diferente a "001").
En el paso de Datos de Respuesta, consultamos la respuesta estructurada en XML del servicio Web externo, ResponseBlackList, el cuál se presenta como una tabla a la izquierda. El encabezado de la tabla, BlackList915, referencia el nombre de los servicios Web externos.
1. Decidir la acción para el error
Primero, decidimos la acción correctiva a seguir en respuesta a un error potencial.
La lista desplegable de los campos de Acción presenta las dos opciones: Mostrar un mensaje de error o lanzar una transición desde un evento BPMN.
La segunda opción, Realizar Ajustes (habilita una transición), solo se contemplará si el diseño del diagrama de Proceso permite el manejo de errores; específicamente, un Evento de captura de error debe estar adjunto a los límites de la actividad relevante.
Cuando se selecciona la segunda opción, note que el error de la transición posee el mismo nombre por defecto de la transición y se llamará Realizar Ajustes (como se muestra en la siguiente imagen).
|
Cuando se activa el camino de la excepción, Bizagi no hará commit de los cambios realizados en la tarea a través de la invocación de servicio (los parámetros de salida mapeados no se tienen en cuenta). Recuerde que esto se debe a que el evento de excepción realiza una interrupción de la tarea, al cancelar la transición regular/esperada del flujo. |
Para este ejemplo, seleccionaremos la opción Lanzar excepción.
|
Tenga en cuenta las siguientes consideraciones: •Las interfaces externas deben ser compensadas adecuadamente cuando se ejecutan en un proceso para realizar modificaciones en datos externos a Bizagi a través de Servicios Web o de Librería de componentes. Se deben evitar actividades que realicen reversiones en muchos casos porque la actividad no sabrá cuales fueron satisfactorias y cuales deben ser revertidas de nuevo. |
2. Definir los errores de respuesta
El mensaje de la excepción generada se encontrará en el XML de salida cuando se lancen errores o excepciones durante el servicio.
Guardaremos la respuesta de error en un XPath dado como se encuentra en el parámetro de salida del método de servicio Web.
Usted puede escribir la definición del XPath directamente en el campo de fondo blanco, para navegar al campo del XPath de respuesta.
Observe cuando navegue (profundice) en la estructura del XML de respuesta, que el caracter slash (/) precede los datos contenidos en el XML retornado.
El esquema del XML de retorno se mostrará en el paso previo, Datos de Respuesta, del asistente de interfaces, cuando se importe la definición de la estructura del XML. En nuestro ejemplo, el esquema contiene los siguientes dos elementos de manejo de errores:
Código de Error (ErrorCode): Código del error que ocurrió, de otra manera estará vacío.
Descripción del Error (Error Description): Mensaje del error que ocurrió, de otra manera estará vacío.
En nuestro ejemplo, el XPath se especificará como el nombre de la respuesta XML,ResponseBlackList, seguido por el caracter slash (/) y por último el nombre del elemento, ErrorCode, en la salida XML: ResponseBlackList/ErrorCode
En este ejemplo, el código de error desde la respuesta se envía como ResponseBlackList/ErrorCode (como se ve en la estructura de la respuesta en la imagen previa de las configuraciones de salida).
Dé clic en Agregar validación de Error para validar la información retornada por el elemento ErrorCode.
Cuando el valor del elemento ErrorCode difiere de "001", Bizagi debería mostrar el elemento ErrorDescription contenido en esa misma estructura de respuesta (como ResponseBlackList/ErrorDescription).
Usted también puede ingresar un texto fijo como mensaje de error en contraposición a la descripción retornada por el servicio.
Importante
El manejo de errores implica que únicamente aquellos errores que hayan sido configurados como excepciones funcionales de manera explícita dentro de la ventana de configuración de manejo de errores, serán interpretados como los aplicables a que disparen un camino alterno (p.e., aquel de un Evento de Error adjunto). Todos los demás errores, tales como aquellos que sean excepciones técnicas (p.e, una interrupción del servicio externo, problemas de red, o configuración errónea), no tomarán este camino alterno y su ejecución deberá ser reintentada.
Información Adicional
Si el manejo de errores se especifica como la acción Lanzar Excepción, las invocaciones fallidas que se configuraron como Actividades Asíncronas se pueden revisar y monitorear en las opciones de Administración en el Portal de Trabajo.
Para mayor información, consulte la Administración de Actividades Asíncronas.
Last Updated 1/26/2022 4:18:52 PM