Day 4 Design Appian Records Part 1 y Part 2 que aprendiste?

¿Day 4 Design Appian Records Part 1 y Part 2 que aprendiste?

  Discussion posts and replies are publicly visible

  • Estas lecciones marcan de manera general y práctica el diseño centrado en Record Types así como buenas prácticas.

    Part 1

    De entrada es indispensable (y lo recalca en varias ocaciónes) habilitar la sincronización de datos, ya que permite almacenar en la memoria una copia de los datos y de una manera más ágil, poder realizar la consulta de acuerdo a las necesidades del usuario final.


    Podemos obtener registros de varias fuentes: Bases de Datos Relacionales (están diseñadas para almacenar datos de manera eficiente), Sitios Web y Modelos de procesos.


    Con respecto a las bases de datos habla que en Appian las BD son transaccionales por ende permite que los datos sean llamados por medio de DSE y Data Types creando queryes, por otro lado redunda en la seguridad de nuestros registros, y nos hace preguntas clave: ¿Que datos necesitamos?. ¿quién puede ver los datos?, ¿qué información quiere el usuario?. ¿cómo es que van a navegar con los datos? y ¿qué acciones deberán tener disponibles en contecto de los datos?, esta seguridad es por niveles:

    • Seguridad de objeto de tipo registro.
    • Seguridad a nivel de registro.

    Los registros cuentan con acciones, la acción de lista de registro y la acción relacionada, para poder trabajar con ellas, es necesario recordar que por medio de queries vamos a logralo, appian pone a disposición el a!queryRecordType, pero tambien es una buena práctica realizar consultas de nuestras data store a!queryEntity

    Part 2

    Cuando conocemos la mejor manera de crear y configurar las diferentes opciones con las que se puede extender las funcionalidades de un Record Type, lo que sigue son las relaciones entre Record Types. Básicamente es la conexión entre dos o más Record Types, para extender el almacenamiento de los datos en común. Primero Añadimos la Relación, seleccionamos el Record Type con el que va a relacionarse. 

    Hay varias maneras de como se establecerá la relación y el tipo de relación: 

    • Uno a uno: Registro A, con un Registro B. 
    • Uno a Muchos: Registro A, con uno o más registros B. 
    • Muchos a uno: Registro B, con uno o más registros A. 

    Por último, podemos configurar y/o editar los campos del Record Type, crear campos de registro personalizados con datos relacionados, también maneja la mejor forma de acceder a un campo de registro personalizado y en qué escenarios puede ser útil y/o utilizarlo en una interfaz, por otro lado nos ayudaran a crear operaciones matemáticas básicas como: Contar, Sumar, Promediar, Máximo, Mínimo” en nuestros datos. 

    Hecho por: Josué Quintero Silva

  • Sitios y Portales: 

    Un  factor super importante para el logro de una experiencia que enganche a los interesados en un sistema son los sitos y portales, 

    estos se distiguen: 

    • Sitio:; Maneja autenticación 
    • Portal: Es del libre acceso 

    Determinar cual es el mas adecuado para el usuario es sencillo si atendemos al requerimiento, a la ncesidad específica de tal o cual sitio o portal. Basicamente los portal son libres de acceso y los sitios cuentan con seguridad de acceso y transaccional que asegura al usuario una expenriencia confiable. 

    Configurar un sitio implica restringir los accesos al mismo a los usuarios de acuerdo a su perfil, grupo,  este se define de acuerdo a su función dentro del negocio. Estas restricciones de acceso a nivel site implican solo dar acceso a las interfases, procesos, registros, views, listas, buttons, datos que sean necesarios para el cumplimiento de sus funciones. 

    Al crear un sitio los pasos que llevaremos para su configuración son: 

    • Configurar sus páginas 
    • Definir sus capacidades 
    • Identificar los elementos que manejará 
    • aplicar las mejores prácticas al site, en especial las de seguridad 

    Al aplicar el nombres al site debemos cuidar 

    • No usar el prefijo de la aplicación  
    • Usar un nombres corto significativo 
    • Usar las iniciales con mayúscula 
    • El display name se usa como identificador en el site, este se puede editar 
    • L web address debe ser única 

    Un portal no requiere auténticación, este se usa principalmente para: 

    • Revisión de registros públicos 
    • Registrarse para un evento 
    • Requerir una cuenta 
    • Requerir una cita 
    • Reportar información 

    Permisos en un portal... 

    Que un portal sea de libre acceso no implica que no sea seguro 

    • Para controlar el acceso se crea una cuenta de servicio la cual permite que el usuario se conecte y a la información seleccionada. 
    • Esta cuenta se crea directamente dentro del objeto del portal pero hay que darle acceso en el "all users group"