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 entre plataformas. 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 se pueden deshacer mediante transacciones de base de datos.
Los desarrolladores pueden utilizar la función de tiempo de ejecución event() de mvSQL desde 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 utilizar para correlacionar eventos que ocurren dentro de una sola operación, por ejemplo, los eventos ejecutados por una acción CRUD empresarial. -
rowid: Un identificador único para la fila en la que se invocó el evento. En el caso de una regla CRUD empresarial, esto se refiere a la fila objetivo. En el caso de un controlador de acción, esto se refiere a la fila de origen de la acción. -
source.rowid: Un identificador único para la fila de origen de la regla CRUD empresarial. 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 empresarial 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 de origen de la acción para indicar que la fila ha sido procesada. Esto se puede utilizar 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 lógica.)
-
Controlador de fallo: Una regla CRUD de base de datos que actualiza la fila de origen de la acción para indicar que la fila ha fallado. La regla CRUD de base de datos utilizarí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 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 desarrolladores deben exponer las fallas 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.