Step 3 Módulo 7

• Automatizando Procesos
• Detonando Microflows
• Microflow expressions
• Retrieving data
• Knowledge Check

Módulo 8
• Validación de información
• Regex
• Validation Microflows
• Borrando objetos
• Knowledge Check

Módulo 9
• Roles y módulos de usuario
• Reglas de acceso
• Seguridad
• Knowledge Check

Módulo 10
• Apps móviles
• Nanoflows
Restricted • Knowledge Check
Calcular la fecha de fin de curso automáticamente
La siguiente historia de usuario le va a permitir al usuario llenar automáticamente la fecha de fin de Curso.

Esto mejorará la experiencia de usuario, reduciendo algunos pasos, pero lo más importante, evitará posibles
errores en el llenado del documento.

Esto se realizara a través de un Microflow

Calcular la fecha de fin de curso automáticamente
Detonando un Microflow desde un widget
Al igual que los botones, los widgets pueden detonar lógica cuando se interactúa con ellos, sin embargo los widgets
tienen ciertas funcionalidades extras, pueden detonar la lógica cuando:

• Se entra al widget (on click)

• Cuando se cambia el valor del widget (on change)
• Al salir del widget (on leave)

En nuestro caso utilizaremos el comportamiento de “on change” ya que al cambiar el valor del widget de “no
selection” a “specific selection” este detonara el microflow.
Change object
En el menú de actividades de un microflow se encuentran actividades para trabajar con objetos
Change object nos permitirá cambiar el valor de un atributo de un objeto

En nuestro caso este cambio se esta realizando a través de una función

Microflow Expressions
Las expresiones son pequeñas secciones de código que forman parte del Low Code

• Funciones: nos permiten cambiar, comparar, extraer información

• Variables: una variable contiene información y siempre comienza con el símbolo $
• Tokens: están directamente relacionados con fechas por ejemplo el uso de la fecha y hora actual seria
‘[%CurrentDateTime%]’

Las expresiones se escriben en el editor y estas se llaman Microflow expressions.

Algunos ejemplos de estas “expressions” son:

Microflow Scope
Cuando se tiene un objeto disponible en un Microflow, se tiene acceso a la información que este contiene y se
tiene acceso a las asociaciones que este forma con otros objetos sin embargo, no se tiene acceso a los atributos de
los objetos asociados.

Para poder alcanzar un atributo en otro objeto que no se encuentra en el alcance, se tendrá que agregar una
operación llamada “retrieve”

Esta es una de las razones por la cual una entidad no se va a mostrar en el autocompletado del “Expresión
editor”
“Retrieve”
Cuando trabajamos en la edición de un texto, esta información es visible en la pantalla (1 cliente) y a su vez guardada en
memoria (2 RAM), si esta información no es guardada en disco duro (3 hard drive) esta información se elimina.

Algo similar para en Mendix, cuando se genera P.E. el usuario da click a una nueva ubicación en nuestra app, se genera
un espacio vacío en el Application Server (2) el objeto es enviado al Cliente (1) donde es visible y se puede llenar, al
llenar la información esta será visible en el cliente y grabada en memoria, sin embargo si no se da click en salvar, la
información nunca se mandara a la base de datos y se perderá.
Retrieve “by association” or “by database”
Al solicitar información directamente desde la memoria es llamado un “association retrieve” esto significa que Mendix
buscara primero en la memoria y cuando esto no es posible, buscará en la base de datos la información que
necesitamos.

Esto puede hacer una app mas dinámica, ya que no tiene que hacer una conexión a la base de datos para traer la
información.
“Debugging the application”

Mendix nos ofrece diferentes herramientas para poder buscar errores en el desarrollo de nuestra aplicación, desde una
descripción detallada de los errores hasta ejecución paso a paso para poder encontrar el origen de este error de una forma
más fácil.
Análisis del error

El error es debido a que no todos los ingredientes de la función addDays están presentes al mismo tiempo, al
intentar Mendix hacer el cálculo sobre un objeto vacío se ejecuta un error.

addDays( Startdate, Duration)

Lógica de verificación
Para lograr eliminar los errores, generamos una lógica que nos permita verificar si los campos están llenos antes
de hacer el cambio en el objeto

Importante mencionar: esta lógica incluye decisiones, estas decisiones solo pueden tener UN flujo de entrada
Commit
Una vez hemos terminado el trabajo actual haremos commit hacia nuestro team server, es decir subiremos al team
server el avance en la app hasta ahora creada

¿Qué pasaría si Mendix reporta varios errores al hacer el commit? Esto significa que la app no puede correr en el
estado actual y por consecuencia no puede enviarse al team server, deberemos solucionar todos los errores antes de
terminar el commit.
Generando automáticamente el número de reservaciones
El usuario busca poder calcular el número de reservaciones que va a tener para cada entrenamiento, esto para poder
calcular el número de recursos necesarios como podrían ser espacios en la ubicación, materiales, o incluso “coffee
brake”
Datos Almacenados (Stored) vs Datos Calculados (Calculated)
Al elegir como se debe almacenar un atributo, es importante elegir si este atributo o dato será calculado o bien,
almacenado. Esto se puede a resumir de la siguiente forma:

• Si el valor cambia más frecuente de lo que el usuario lo observa, el dato será calculado

• Si el usuario observa el dato más frecuentemente de lo que cambia, será almacenado en la base de datos

Esto reduce el número de cálculos necesarios para mantener la información lo más exacta posible a la hora de mostrarla
Event Handlers
Otra forma de detonar la lógica de un microflow es a través de los “event handlers”, esto significa que Mendix
“escuchará” cómo se comporta un objeto es decir, si este objeto es creado, borrado, almacenado o bien se da cancelar
antes de poder crearlo (Roll back).

En nuestro caso vamos a generar un conteo de registros y usaremos esta herramienta en la entidad Registros para
poder calcular el número de ellos.

• Después de ser guardado el objeto

• Después de ser borrado
7mo knowledge check
Consistencia de Datos

Validation Rules
Antes de crear cualquier validation rules, es importante tener en mente que se deben haber creado las entidades con
anterioridad.

Es por eso que existen los Validation Rules, que nos permiten verificar la información antes de guardarla en la base de
datos, estas validaciones se pueden agregar a los atributos o en el microflow.

Cuando los mensajes de validación no están conectados a un widget visible en la página, el error de validación de
mostrara en un pop up o inclusive en la pagina donde se ingresan los datos, algunas de las validaciones disponibles son
las siguientes:

La validación de datos debe ayudarnos a prevenir, campos vacíos, borrados no intencionales, o bien datos sin sentido
Agregando validaciones el Domain model
Coloquemos nuestra siguiente historia de usuario en corriendo:
Agregando validaciones el Domain Model
Nuestro usuario final solicita que las siguientes reglas sean aplicadas a los datos:
Regex = Regular expressions
Al realizar la verificación de cada uno de los atributos, nos damos cuenta que el campo de correo electrónico tiene una
particularidad: es necesario cumplir con la estructura nombre@mail.com esto nos permitirá asegurar que el dato se ha
integrado correctamente

Para esto utilizaremos regex

Validación de datos con Microflows
Como lo vimos anteriormente, es posible realizar verificaciones de la información en las entidades, sin embargo al
realizar una validación sobre “training event”, se vuelve más complicado ya que este es un evento compuesto de
diferentes entidades, por lo que es necesario hacer la verificación a través de un Microflow

Es importante tener en cuenta las siguientes consideraciones:

• Cada campo debe tener su propio mensaje de error ( a excepción de
la fecha de fin)

• Todo el feedback debe presentarse al mismo tiempo, esto para

evitar que el usuario reciba diferentes notificación

• Solo al pasar todas las validaciones se podrá salvar la información

• Cuando se termine la validación y se de salvar, se debe cerrar la

página, para evitar confusiones al usuario
Mensajes de Feedback
Estos mensajes le permitirán al usuario saber que un componente no ha pasado la prueba de verificación, estos
mensajes los integraremos dentro de nuestro “false path”
Haciendo “merge”

El “merge” nos permitirá reintegrar la lógica al flujo principal, de esta manera podremos hacer todos los checks en un
solo paso.

El comportamiento por default de salvar puede ser replicado a través de una actividad Commit + Close
page
Creando un “Flag”
Una variable flag nos permitirá identificar si una condición se ha cumplido a través del proceso
Borrando objetos
Al borrar objetos existe la posibilidad de borrar objetos que estén asociados, esto podría causar efectos no
deseados en nuestra aplicación, por ejemplo: borrar por error los registros de un evento el cual ya tiene alumnos
registrados.
Para que no pase esto, utilizaremos ciertas propiedades de las asociaciones.

Un “delete behavior” define qué pasará al objeto asociado cuando un objeto es eliminado

Por ejemplo, si queremos evitar que se elimine un vuelo que tiene pasajeros, configuraremos un “prevention of
delete”
Borrando en cascada
Otra característica que nuestro usuario busca, es la posibilidad de borrar todos los registros de un alumno cuando este se
da de baja, esto para evitar tener registros falsos dentro de un evento de entrenamiento.

Esta es la característica borrando en cascada

8vo knowledge check
Seguridad en la App
En Mendix existen tres puntos donde se enfoca la seguridad:
• En las páginas
• En los microflows
• En las entidades

Y la seguridad se divide en dos grandes tiers:

• App security: es donde se maneja el “overall” de las configuraciones de seguridad de la app

• Module security: Aquí es donde se puede configurar la seguridad de microflows, páginas y entidades

Niveles de seguridad

En Mendix existen tres niveles de seguridad:

• Apagado: no existen seguridad y cualquiera puede entrar en la app sin restricciones

• Prototipo y demo: este nivel requiere que se defina la página de acceso y el acceso a los microflows, y es
necesario definir quien visita qué página y quien detona qué microflow.
• Producción: en este punto se define el acceso a las entidades, si alguien tiene acceso a crear objetos,
borrarlos, o editarlos esta es la seguridad que se utiliza para un ambiente productivo
User Roles y Module Roles en nuestra aplicación
Para nuestra aplicación existirán tres tipos diferentes de “User Roles” los cuales serán:

• Administradores
• Profesores
• Alumnos

De esta forma cada usuario tiene su propio grupo de derechos de acceso, por ejemplo: el administrador tendrá
acceso a crear y eliminar eventos de entrenamiento, mientras que el alumno solo tendrá derecho a ver los eventos
de entramiento y su información

Mendix separa la información de esta manera para permitir que los módulos sean reusados de una manera más
sencilla
¿Cuál es la relación entre los user roles y los module roles?

Un “user roles” está definido a nivel del proyecto y tienen module roles asignados a este.

Los “user roles” pueden ser creados en el “App Security”

En el “App security” se van a definir todos los roles no importando si esto es de una PWA, de una web
app o de una app nativa.
Reglas de acceso a páginas y Microlfows

Solo el administrador, tiene derechos a ejecutar los Microflows

Conectando User Roles con Module Roles
Creando una página de home basada en un rol de usuario

Para evitar que un usuario pueda aterrizar en páginas que contienen ligas que no puede ejecutar debido a su perfil, es
necesario definir una página de inicio basada en su rol de usuario.
Creando accesos a las entidades

Para poder configurar los accesos a las entidades (objetos), es necesario activar la seguridad en modo producción,
esto nos generara varios errores, al no tener una definición de que roles de usuario podrán tener acceso a estas
entidades, esto lo solucionaremos a continuación
App Security Settings
Cuando un usuario tiene acceso a una página la cual posee un atributo al cual el usuario no tiene acceso, resulta
en un conflicto de seguridad, esto se puede resolver usando las propiedades de visibilidad condicional del atributo.
App Security settings

Existen otras opciones dentro de la sección App Security las cuales nos van a permitir:

• Administrator tab: establecer el password del administrador, este password es válido para un “local deployment”. Al
publicar la aplicación se solicitaran credenciales para cada ambiente.
• Demo users tab: esta sección permitirá cambiar rápidamente de roles para probar la seguridad dentro de nuestra app
• Anonymus users tab: se podrá habilitar usuarios de forma anónima sin embargo, es importante tener en mente que se
debe limitar el acceso para evitar perder la rastreabilidad de quien hace que.
• Password policy tab: Aquí es donde se determina que tan estrictos serán nuestros passwords y que política seguirán.
Cuando un usuario no tiene acceso a un elemento, por ejemplo: un microflow, Mendix ocultará
los elementos que muestren detonen este Microflow
9no knowledge check
Going Mobile
Existen muchas características a tomar en cuenta al pensar en una app móvil, como por ejemplo, si la navegación está
optimizada para dispositivos móviles o bien, si el layout se adapta de forma correcta a estos dispositivos, o si un widget se ve
mejor en un dispositivo que en otro.

Y hay un punto importante durante esta evaluación:

elegir entre una aplicación que será app que será desplegada en una app store o una que se desplegada en una plataforma
basada en un navegador web

Una PWA permitirá la función “add to home screen” de tal manera que lanzará la app dentro de un browser, sin la necesidad
de descargarla desde una app store
PWA
Las “Progressive Web Applications” tienen tres principales beneficios:

• Son instalables: se pueden instalar en los dispositivos móviles y funcionar dentro de una experiencia que aparenta
ser nativa (sin las barras o herramientas del browser),
• Confiables: Una PWA nos permitirá trabajar parcialmente offline o completamente offline permitiendo así más
flexibilidad
• Capacidades extendidas: se puede hacer uso de las capacidades del dispositivo móvil donde reside, como: cámaras,
gps, nfc, dispositivos biométricos, etc.
Habilitar la casilla de “Allow Add To Home Screen Promt” y “Publish as a PWA” nos permitirá generar una
PWA

Los layouts preferentes para este tipo de aplicaciones serán “Phone Specific” mientras que los templates
específicos para estas apps serán Phone (Web)
Nuestra aplicación en móvil
Nuestro usuario final busca tener una página móvil para sus alumnos, en la cual sus alumnos puedan tomar
provecho de las herramientas móviles, como la geolocalización o bien compartir la información en redes.
Nanoflows
Los Nanoflows al igual que los Microflows, nos ayudan a expresar lógica dentro de Mendix con algunas ventajas:

• Corren directo sobre el móvil o el dispositivo

• Pueden funcionar de forma offline
• Al correr en el dispositivo no es necesaria un acceso a un servidor por lo que la aplicación es más rápida
Agregando geolocalización

A través de Nanoflows:

Los nanoflows son lógica que se ejecuta directamente en el dispositivo, por lo que esta lógica puede
usarse de forma offline

Los nanoflows están basados en una notación “BPMN” (Business Process Model and
Notation)
+
Los nanoflows ejecutan las “actividades de cliente” en cada paso
Compartiendo información vía mobile social channels
Restringiendo información a través de Xpath
10mo knowledge check
Thank You
Go Make It!