Manejo de Errores en Interfaces

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Asistente de Procesos > Integrar > Integración con aplicaciones > Conector de servicios Web >

Manejo de Errores en Interfaces

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.

 

ErrorHandling01_OutputSchema

 

 

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.

 

ErrorHandling02_Action

 

 

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).

 

note_pin

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.

ErrorHandling00_AttachedTransition

 

Para este ejemplo, seleccionaremos la opción Lanzar excepción.

 

 

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).

 

ErrorHandling03_AddValidation

 

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).

 

ErrorHandling04_ErrorConfigured

 

Usted también puede ingresar un texto fijo como mensaje de error  en contraposición a la descripción retornada por el servicio.

 

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.