Saltar al contenido

Manejo de errores de acción en Jitterbit App Builder

Manejo de errores

La mayoría de los tipos de acción terminan inmediatamente en respuesta a una excepción no controlada. La excepción se registra en el historial de eventos. Es responsabilidad del desarrollador validar los datos antes de realizar la acción.

Las acciones de CRUD empresarial realizan operaciones multiplataforma. En algunos casos, la operación incluye una o más solicitudes de API a servicios de terceros, como puntos finales REST. A menudo, es difícil validar los datos antes de realizar la acción. En su lugar, los desarrolladores deben atrapar y manejar la excepción.

Con este fin, las acciones de CRUD empresarial admiten las siguientes características:

Continuar en caso de error

Una acción de CRUD empresarial recupera las filas de origen de la regla en lotes y ejecuta el evento (Insertar, Actualizar o Eliminar) para cada fila en el lote. Por defecto, una excepción no controlada termina la operación: no se procesan filas adicionales.

Sin embargo, cuando la opción Continuar en caso de error está habilitada, la excepción se captura. La acción continúa procesando las filas restantes y el evento se completa con éxito. Se convierte en responsabilidad del desarrollador manejar cualquier fallo utilizando un manejador de acción.

Manejadores de acción

Un manejador de acción es fundamentalmente una acción. Sin embargo, los manejadores de acción difieren de las acciones en las siguientes formas:

  • Mientras que las acciones están registradas para ejecutarse antes o después de un evento, los manejadores de acción se ejecutan después de que una acción tiene éxito o falla.

  • Mientras que las acciones están vinculadas a la fila del objeto de datos, los manejadores de acción están vinculados a la fuente de la acción.

Los manejadores de acción se pueden utilizar para los siguientes propósitos:

  • Registrar el estado de filas individuales.

  • Rastrear el progreso de una operación de CRUD empresarial de larga duración.

  • Correlacionar fallos de filas con entradas en el objeto de datos público EventHistory.

  • Revirtiendo el efecto de acciones fallidas que no pueden ser revertidas por transacciones de base de datos.

Los desarrolladores pueden usar la función de tiempo de ejecución event() de mvSQL desde dentro de los controladores de acción para acceder a información de eventos y a nivel de fila, incluyendo lo siguiente:

  • contextid: Un identificador único que se puede usar para correlacionar eventos que ocurren dentro de una sola operación, por ejemplo, los eventos ejecutados por una acción CRUD de negocio.

  • rowid: Un identificador único para la fila en la que se invocó el evento. En el caso de una regla CRUD de negocio, esto se refiere a la fila objetivo. En el caso de un controlador de acción, esto se refiere a la fila fuente de la acción.

  • source.rowid: Un identificador único para la fila fuente de la regla CRUD de negocio. Esto se aplica a reglas de inserción y actualización.

  • exception: Un mensaje de excepción. Este valor es accesible para los controladores de fallo de acción si el evento falló como resultado de una excepción.

Las propiedades rowid y source.rowid permiten a los desarrolladores correlacionar un fallo a nivel de fila con una entrada en el objeto de datos público EventHistory. Una configuración típica podría incluir:

  • Acción: Una regla de inserción CRUD de negocio que apunta a un endpoint REST. La opción Continuar en caso de error está habilitada.

  • Controlador de éxito: Una regla CRUD de base de datos que actualiza la fila fuente de la acción para indicar que la fila ha sido procesada. Esto se puede usar para informar el estado de una operación en curso o para excluir la fila de ejecuciones futuras. (Para que este controlador sea visible, la regla asociada debe apuntar a la capa de lógica.)

  • Controlador de fallo: Una regla CRUD de base de datos que actualiza la fila fuente de la acción para indicar que la fila ha fallado. La regla CRUD de base de datos usaría la función event('rowid') para registrar el identificador de la fila. (Para que este controlador sea visible, la regla asociada debe apuntar a la capa de lógica.)

  • Controlador de reversión: Acciones que revierten el efecto de todas las acciones exitosas que ocurrieron antes de una acción fallida. La acción fallida en sí no es manejada por este controlador.

Los controladores de acción requieren una fila en contexto

Los controladores de acción se ejecutan por fila y están vinculados a la fila de origen de la acción, por lo que un controlador de fallos se ejecuta solo cuando hay una fila en contexto en el momento del fallo. Si un evento falla antes de que se establezca cualquier fila (por ejemplo, cuando una consulta se agota o genera un error al seleccionar o iterar las filas de origen, en lugar de procesar una fila individual), no hay ninguna fila a la que vincular el controlador, y el controlador de fallos no se ejecuta.

Los desarrolladores deben exponer los fallos en la interfaz de usuario. Por ejemplo, el desarrollador podría construir una página con dos paneles. El primer panel enumera las filas fallidas. El segundo panel está vinculado al objeto de datos público EventHistory. Este último panel está vinculado al primero, emparejando RowId con SourceRowId.