Validación de datos en Dev Studio

En App Studio, puede configurar las condiciones de validación que permiten determinar si el valor de un campo es verdadero o falso al compararlo con un valor constante o con el valor de otro campo. Los escenarios de validación más complejos podrían requerir capacidades adicionales que se obtienen mediante las reglas de validación de Dev Studio.

Considere los siguientes escenarios, cada uno de los cuales requiere comportamientos que puede configurar solo en Dev Studio:

• Cuando un cliente canadiense envía su dirección, el código postal introducido debe ajustarse al formato estándar de los códigos postales canadienses.
• Cuando un inversionista abre una cuenta de inversiones, completa un cuestionario para determinar su nivel de experiencia. Solo las personas que cuenten con amplia experiencia en inversiones pueden agregar el apalancamiento financiero a su cuenta.
• Cuando alguien se inscribe en un plan de atención médica, la persona solicitante debe cargar un formulario de consentimiento para permitir la divulgación de información médica a terceros.

Reglas de validación

Las reglas de validación garantizan que los datos que proporcionan sus usuarios cumplan con las condiciones que requiere un caso a fin de avanzar. Mediante la asignación de reglas de validación a acciones de flujo, usted puede evitar que los usuarios introduzcan información que su aplicación no puede procesar y reducir el número de errores de procesamiento.

En Dev Studio, puede ampliar las reglas de validación que se crean automáticamente en App Studio. También puede crear reglas de validación nuevas en la categoría Process (Proceso).

Reglas de validación de edición

Por lo general, las reglas de validación de edición se aplican a propiedades y consisten en código Java que compara el valor de una propiedad con un patrón definido. Por ejemplo, una regla de validación de edición permite comprobar si un valor de propiedad consiste en siete números, con un espacio que separe el tercero del cuarto. Si hay coincidencia con el patrón, se considera que la entrada es válida. De lo contrario, el sistema marca la entrada con un error.

Las reglas de validación de edición se utilizan para la validación del lado del cliente, lo que significa que el valor que introducen los usuarios se valida inmediatamente sin hacer referencia al servidor. La validación tiene lugar cuando los usuarios hacen un cambio en el valor introducido. Para aplicar una regla de validación de edición a una propiedad, haga referencia a la regla de evaluación de edición en la pestaña Advanced (Avanzada) del property rule form, en el campo Use validate.

La lógica del negocio podría determinar que las entradas de los usuarios cumplan con ciertos estándares. Por ejemplo, para capturar información de contacto de un usuario, una organización necesita asegurarse de que la información sea válida. Antes de que una aplicación pueda confirmar la exactitud de un código postal, de una dirección de correo electrónico o de un número de teléfono de un usuario, la aplicación debe confirmar que lo introducido por el usuario se ajusta a un formato específico que podría variar según la ubicación.

El ejemplo a continuación demuestra la aplicación de una regla de validación de edición para garantizar que un usuario introduzca un código postal ajustado al formato de códigos postales de Estados Unidos, lo que requiere cinco dígitos numéricos.

Compruebe sus conocimientos con la siguiente actividad.

La lógica del negocio podría requerir que una aplicación valide datos de manera diferente según ciertas condiciones, como la entrada, el estado del caso o la etapa de un usuario, o según la acción de un usuario. Esto puede llevarse a cabo con una regla de validación.

Considere un tipo de caso para abrir una nueva cuenta de inversiones. Una firma de servicios financieros podría ofrecer la opción de negociar valores con apalancamiento prestándole fondos al cliente para que compre acciones o haga otras inversiones permitidas. Este préstamo, conocido como préstamo de margen, requiere que el cliente mantenga una determinada proporción del saldo de préstamo con respecto al valor de cuenta, como el 30 %. La firma quiere asegurarse de que los clientes utilicen el apalancamiento con prudencia y limiten la necesidad de un ajuste de márgenes, una solicitud de fondos adicionales o la venta automática de una inversión para restablecer la proporción entre el saldo de préstamo y el valor de cuenta. Los inversionistas con amplia experiencia en la actividad presentan un riesgo bajo de ajuste de márgenes, no así las personas con experiencia limitada, que tienen un riesgo mucho mayor. Además, las cuentas que limitan los aportes anualmente, como las de jubilación, directamente prohíben la negociación con apalancamiento. Para satisfacer este requerimiento, usted puede establecer condiciones en la lógica de validación según el tipo de cuenta y el nivel de experiencia.

Para caracterizar la lógica de validación, utilice la pestaña Input (Entrada) de la regla de validación a fin de identificar el tipo de requisito que desea aplicar seleccionando una de las opciones.

• Input property (Propiedad de entrada): caracteriza la validación según los datos proporcionados por el usuario. En el ejemplo de la nueva cuenta de inversiones, se utilizan los campos de nivel de experiencia y tipo de cuenta para especializar la lógica de validación.
• Proposed work status (Estado de trabajo propuesto): caracteriza la validación según el estado que la aplicación asigna al caso. Por ejemplo, una solicitud de tarjeta de crédito se basa, en parte, en el puntaje de crédito del cliente. Con respecto al estado de Pending-Qualification (Requisitos pendientes), el puntaje de crédito puede bajar hasta 600, mientras que para cambiar el estado a Approved (Aprobado), hace falta un puntaje de crédito mínimo de 725.
• Flow action (Acción de flujo): caracteriza la validación según la acción llevada a cabo por un usuario. Por ejemplo, un formulario que contiene información de empleados requiere una fecha de inicio de empleo. Si el usuario desea poner en marcha la incorporación de un empleado nuevo, la fecha de inicio debe ser en el futuro. Si el usuario quiere hacer la revisión anual de un empleado, la fecha de inicio debe ser en el pasado.
• Stages (Etapas): caracteriza la validación según la etapa actual del caso. Por ejemplo, para solicitar una hipoteca o un préstamo con garantía inmobiliaria, el cliente debe indicar sus ingresos anuales. Durante la etapa de envío, la solicitud requiere que el usuario indique los ingresos calculados. En la etapa de aprobación, el cálculo debe reemplazarse por un valor concreto y confirmado.

El ejemplo a continuación demuestra la validación caracterizada por la entrada. El valor que se seleccionó en la lista Experience level (Nivel de experiencia) determina la condición de validación que se aplica cuando usted envía el formulario. Si el usuario selecciona Experienced (Experimentado) o Professional (Profesional), se permite la negociación con apalancamiento y no se valida la checkbox para habilitar este método financiero. Si el usuario selecciona Limited (Experiencia limitada), aparece un error cuando el usuario selecciona la checkbox para habilitar la negociación con apalancamiento.

En el centro de la imagen a continuación, deslice la línea vertical para ver la configuración de la validación caracterizada por la entrada y el resultado.

App Studio admite comparaciones de tipo verdadero/falso entre dos valores de propiedad o entre un valor de propiedad y una constante. En los casos en que no pueda configurar este tipo de comparación, puede acceder a una biblioteca de funciones de validación en el formulario de regla de validación, en Dev Studio. Por ejemplo, puede utilizar una función para comprobar si una fecha cae en las últimas cuatro u ocho semanas, o para verificar si un usuario cargó un tipo específico de archivo adjunto al caso. Cada función presenta un conjunto personalizado de campos para configurar el comportamiento de validación.

El siguiente ejemplo demuestra el uso de una función para configurar la validación. La regla de validación emplea la función A [attachment category] is [attached/not attached] to the current case (A [categoría de archivo adjunto] está [adjunto/no adjunto] al caso actual) para garantizar que el usuario adjunte un documento a modo de prueba de identidad como parte del proceso de incorporación de un empleado nuevo.

En el centro de la imagen a continuación, deslice la línea vertical para ver la configuración de la validación del archivo adjunto y el resultado.