Reglas de validación en Jitterbit App Builder

Las validaciones son una regla propósito utilizada para proteger la integridad de los datos. Pueden ejecutarse contra los datos que los usuarios finales ingresan manualmente, rechazando registros que violan la lógica empresarial (por ejemplo, registros duplicados). Si se define una regla CRUD para un objeto de negocio, sus validaciones también se ejecutan automáticamente cada vez que se ejecuta esa regla CRUD. Los mensajes de validación mostrados a los usuarios son configurables y admiten sustitución dinámica para una mejor experiencia del usuario.

Al igual que otras reglas, una regla de validación se crea en la capa de negocio y solo tiene efecto una vez que está registrada en un evento. Para una guía completa sobre cómo crear una regla de validación y registrarla en un evento intrínseco, consulta Reglas de validación en Introducción a App Builder - Lección 7: Más sobre reglas, y Validaciones en Apéndice B para un ejemplo más avanzado. Esta página cubre los campos del diálogo de Validación en detalle, junto con las mejores prácticas a tener en cuenta al trabajar con reglas de validación.

Registrar una validación en un evento

Una vez que la cláusula WHERE de una regla de validación define los datos que debe capturar, regístrala en un evento intrínseco o personalizado para que se ejecute. En el panel de Validaciones del evento, haz clic en Registrar para abrir el diálogo de Validación:

El diálogo de Validación incluye los siguientes campos:

• Tipo: Selecciona Regla para ejecutar una regla de negocio como la validación, o Plugin para usar un plugin de validación preconstruido en su lugar, como el plugin de validación Regex.

• Regla: Selecciona la regla de validación a ejecutar. Solo se muestra cuando el Tipo está configurado como Regla.

• Vinculación: Selecciona Implícita o Explícita. Consulta Vinculación implícita y explícita para decidir cuál usar.

• Fallo: Selecciona Fallar en datos devueltos si la regla está escrita para encontrar datos incorrectos (el enfoque más común). Selecciona Fallar en ningún dato devuelto si la regla está escrita para encontrar datos correctos, de modo que la ausencia de datos devueltos indique un fallo.

• Severidad: Selecciona Error para bloquear completamente el guardado, Advertencia para permitir que el usuario elija si continuar, o Información para mostrar un mensaje sin interrumpir el flujo de trabajo.

• Mensaje: Ingresa el mensaje que se muestra al usuario cuando se activa la validación. Este campo admite sustitución dinámica utilizando marcadores de posición {{ ColumnName }}. Cualquier columna sustituida también debe estar disponible en el objeto de negocio en el que se registra el evento.

• Etiqueta: (Opcional) Ingresa una etiqueta que se mostrará en el diagrama del evento. Se utiliza el nombre de la regla si se deja en blanco.

• Posición: Establece Orden para controlar la secuencia de ejecución entre múltiples validaciones, y Activo para habilitar o deshabilitar la validación sin eliminarla.

• Código de estado HTTP: (App Builder 4.65 y posteriores) (Opcional) Ingresa el código de estado HTTP que se devolverá al llamador cuando esta validación falle mientras se invoca en el contexto de una llamada de webhook. Este campo no tiene efecto en las validaciones invocadas en el contexto de una llamada a la API REST (SNAPI).

  Nota

  Si más de una validación en la misma cadena de eventos falla con un Código de estado HTTP configurado, solo se devuelve el valor de la primera validación activada en la cadena al llamador. Si el campo se deja en blanco, una validación fallida típicamente devuelve 400 (Solicitud incorrecta) por defecto; consulta Sobre el cuerpo de la respuesta para otros códigos de estado predeterminados.

• Ayuda técnica: (Opcional) Ingresa una descripción de la validación para otros desarrolladores.

Mejores prácticas y recomendaciones

1. Utiliza el enlace implícito para la mayoría de las reglas de validación, ya que verifica los datos que actualmente están en memoria en la pantalla del usuario antes de ser guardados. Reserva el enlace explícito para los casos en los que la validación necesita verificar datos que ya están guardados en la base de datos, como una regla de validación de XP que valida datos a través de una fuente de datos diferente. Consulta Enlace implícito y explícito para más información.

2. Elige el objetivo correcto para la validación, dependiendo de dónde deseas que se ejecute:

   • Dirige a la tabla y registra la validación en su Detalle de Evento de Tabla si deseas que se ejecute cada vez que se guarde algún registro a través de cualquier objeto de negocio que apunte a esa tabla.

   • Dirige al objeto de negocio y registra la validación en su Detalle de Evento de Regla si deseas que se ejecute solo cuando se utilice ese objeto de negocio específico.

   Consulta Dónde se configuran los eventos y Tabla vs. objeto de negocio para más información.

3. Cuando una regla de validación utiliza enlace implícito, el objeto de negocio en el que está registrada debe contener cada columna referenciada en la regla. App Builder necesita que estas columnas estén presentes para sustituir con éxito sus valores en memoria. Consulta el ejemplo de validación de correo electrónico duplicado a continuación para una configuración de muestra.

4. La severidad de Advertencia de una validación solo funciona cuando la validación es activada directamente por el panel o evento de la interfaz de usuario. Cuando una regla que contiene la validación se ejecuta como una acción dentro de la ejecución de otro evento (por ejemplo, desde una regla padre más arriba en una cadena de eventos), no hay interfaz disponible en ese momento para mostrar al usuario un aviso de proceder o cancelar, por lo que la severidad de la validación se eleva a Error.

5. Utiliza sustitución dinámica para hacer que los mensajes de validación sean más útiles para los usuarios finales. Agrega el valor a sustituir como una columna en el objeto de negocio en el que está registrado el evento, luego haz referencia a él en el campo Mensaje de la validación utilizando la sintaxis {{ ColumnName }}.

6. Si estás creando una regla de validación que hace referencia a una tabla, o a varios objetos de negocio construidos sobre la misma tabla, más de una vez, como una regla que verifica si la dirección de correo electrónico de un nuevo registro duplica una ya guardada en esa tabla (como en el ejemplo a continuación), añade la tabla objetivo a la regla una segunda vez. Haz esto en la pestaña Tablas de la regla, mientras construyes la regla en el generador de reglas. Esto asegura que el nuevo registro realmente sea validado, porque el enlace implícito de App Builder sustituye automáticamente solo la primera instancia de esa tabla con el registro en memoria que se está editando. Sin una segunda instancia sin tocar, la regla no tendría datos guardados reales para comparar con el nuevo registro, y la validación nunca capturaría el duplicado que se supone debe detectar.

   Nota

   El mismo riesgo aparece cuando una regla de validación utiliza más de un objeto de negocio que todos apuntan a la misma tabla que el panel o evento que activa la validación. A diferencia de una tabla añadida dos veces, donde solo la primera instancia es sustituida, cada uno de esos objetos de negocio es sustituido por el registro en memoria, ya que App Builder no tiene forma de distinguir entre ellos. Si necesitas que uno de ellos siga reflejando los datos guardados reales, por ejemplo, para ejecutar el mismo tipo de verificación de duplicados, apunta a una tabla diferente a la utilizada por el panel o evento; porque no coincidirá, App Builder nunca la sustituye.

Ejemplo: Regla de validación de correo electrónico duplicado

Este ejemplo muestra una regla de validación que utiliza el enfoque "en memoria" descrito anteriormente, verificando una dirección de correo electrónico ingresada por el usuario contra los valores ya guardados en la tabla para otras cuentas. Debido a que la regla utiliza enlace implícito, todas sus columnas referenciadas deben existir en el objeto de negocio en el que está registrada para que App Builder coloque los valores en memoria en la lógica de la regla:

1. Se crea una regla de validación llamada tcAccount (Validación) (Correo Electrónico Duplicado) en la pestaña Reglas del App Workbench.

2. La regla de validación apunta a la tabla tcAccount dos veces: una como TA (el registro en memoria, que se sustituye) y otra como TA2 (los registros guardados existentes para comparar).

   

3. La cláusula WHERE de la regla de validación está configurada para comparar las columnas Email y AccountTypeID entre las dos instancias de la tabla para detectar un duplicado.

   

4. En la pestaña Uniones de la regla, las dos instancias de tcAccount se unen por AccountID, excluyendo coincidencias entre un registro y sí mismo.

   

5. Finalmente, la regla se adjunta a un evento utilizando enlace implícito, con la severidad configurada como error.