Favor de subir sus apuntes
Discussion posts and replies are publicly visible
Buena noche Marco, comparto mis apuntes de los cursos de hoy.
NOTA: Sigo sin tener acceso al Site de Appian.
* Manage Users and Groups
Los usuarios se encuentran entre los primeros objetos que se crearán al crear la aplicación, estos proveerán la forma organizacional así como la seguridad dentro de la aplicación.
Al crear la aplicación dos objetos básicos que se crean son los grupos de Administradores y (resto de) Usuarios. Tipos de usuarios:
Usuarios Básicos. No tienen acceso a nada dentro de la aplicación hasta que se les brinda el permiso/acceso, para darles dicho acceso es necesario agregarlos a un Grupo.
Administradores de Sistema. Tienen acceso administrativo por defecto, pueden diseñar y administrar objetos, pueden acceder a la consola de administración, en dicha consola puede crear nuevos usuarios, al crear uno nuevo, si se deja en blanco el campo de contraseña se genera y envía una contraseña temporal por correo al nuevo usuario, el cual deberá cambiar en su siguiente inicio de sesión.
En Appian no puedes eliminar usuarios, solo puedes Desactivarlos o Reactivarlos.
Para acceder a la parte de los grupos, será necesario que en Appian Designer seleccionemos la opción de OBJECTS, y en la opción de búsqueda escribamos el nombre del grupo, u otra opción es que se active el checkbox de Group y seleccionar el deseado, una vez dentro del objeto (dándole clic sobre él) aparece la opción de ADD MEMBERS y en la opción de Users to Add se puede buscar y elegir el usuario deseado, en su siguiente inicio de sesión, los permisos serán aplicados y tendrá los accesos estipulados por el grupo.
Los usuarios pueden ser creados con el uso de las siguientes 3 opciones: Autenticación LDAP & SAML desde la consola de administración, Herramientas de aplicación LDAP o desde la Aplicación de Gestión de Grupos (las últimas dos están disponibles en el Appian Appmarket).
Grupos. Se usan para asegurar la edición de objetos, y se usan para definir quién puede ver qué dentro de la aplicación. Las principales razones por las que se usan los grupos son:
Como la mejor práctica, todas las aplicaciones deberían tener los siguientes grupos:
All Users, primer grupo que debe crearse en la aplicación, grupo padre de todos los grupos, por lo que contiene a todos los otros grupos y a todos los usuarios ya por defecto, a raíz de esto, no es necesario agregarle usuarios ya que los hereda de sus hijos.
Administrators, segundo grupo que debe crearse en la aplicación, este debe de usarse para dar seguridad al grupo de All Users, los miembros de este grupo pueden crear, modificar, eliminar y asegurar objetos de la aplicación.
Functional & Role-Based (grupo funcional y basado en rol), este último son los creados para usuarios empresariales y varían de aplicación a aplicación. Los grupos funcionales se generan con base a la tarea realizada por el usuario.
Una vez que se agregan los usuarios a los grupos correspondientes, se tiene que asignar seguridad a la aplicación, para ello desde el Appian Designer en APPLICATIONS seleccionamos el checkbox de la aplicación y esto devela el botón de SECURITY, dando clic en él despliega una nueva ventana donde podemos agregar los grupos y designar el permiso que se adecua a éste (Administrator, Editor, Viewer o Deny)
* Expressions: Transformers Your Data
Es recomendado una carpeta principal donde se almacenen otras subcarpetas para los diferentes objetos. Existen 4 tipos de carpetas al momento de crear una nueva: Rule Folder, Process Model Folder, Document Folder y Knowledge Center.
Las reglas de expresión, consultas (queries), interfaces, decisiones y constantes se almacenan en subcarpetas para mantenerlas organizadas y proveer herencia de permisos (seguridad) desde su carpeta padre.
El editor de expresiones. Consta de 4 secciones principales: En la esquina superior izquierda, el cuadro blanco con líneas numeradas es el editor, es donde se define la regla (de expresión, un objeto de la aplicación), se tiene acceso a las funciones propias de Appian, variables, reglas, constantes y operadores. Cuando se usan funciones, el cuadro blanco de la esquina inferior izquierda denominado sección de documentación se activa y provee información guía de cómo usar dicha función, en la derecha está la sección de entrada de reglas (RULE INPUTS), en esta zona al darle clic en el botón de + de la esquina superior derecha (también sirve la combinación de teclas CTRL + “I”, letra i) te permite crear variables en la regla que representa información dinámica. En la zona de enmedio, está la zona de pruebas de entrada (Test Inputs), en esta sección podemos verificar si la regla definida es correcta o no. Para mandar a llamar una variable, por ejemplo ticketID, se realiza con el ampersand (&) para unir las cadenas (strings) de mensaje con el valor numérico, se usa una concatenación y conversión de tipos (char e integer para desplegarlos como caracteres) con la expresión (prefijo) de rule input (ri!)
CDT (Custom Data Type). Es un objeto que contiene campos definidos por el usuario, emparejados con sus tipos de datos asociados. Se utiliza para agrupar puntos de datos relacionados que se utilizarán como referencia durante el desarrollo de la aplicación. Para llamarlo se usa la expresión type! y el nombre del objeto.
Funciones de Appian. En el editor de expresiones, al seleccionar el botón de fx se desplegará un listado de carpetas con nombres de tipos de funciones los cuales contendrán un conjunto de funciones relacionadas por su categoría, esto también se puede hacer si en lugar de dar clic se escribe la palabra fun de función dentro del editor de expresiones.
Algunas funciones comienzan con el prefijo a!, estas son definidas como funciones Appian SAIL (Self-Assembling Interface Layer) la mayoría de las veces trabajan como las funciones que no usan prefijo, se verán bastante en las interfaces ya que todo en una interfaz está respaldado por este tipo de funciones.
Variables. Las variables pueden ser definidas con algún tipo de dato primitivo. El trato con los valores NULL, si se desea limitar a que no se usen estos se recomienda el uso de la función isnull() que realiza una prueba para verificar si el valor es un NULL y si así fuese, regresa un mensaje de texto (“Unassigned”) evitando que la prueba fracase o genere un error. Si el valor almacenado en una variable cambiará rara vez o puede que no cambie nunca, se puede guardar como una constante, y así lo puedes referenciar en una expresión (lo puedes referenciar con el prefijo cons!), si lo deseas modificar en la lista de objetos lo puedes buscar o filtrar su búsqueda con el checkbox de Constant. Variables locales, sólo pueden ser accedidas a ellas dentro de la función que las define, se pueden estructurar de la siguiente forma donde como ejemplo se definen dos variables locales y se realiza la suma de ellas:
Arreglos. Una colección de información que tienen relación. Se usan llaves para definir el arreglo y los elementos son separados por comas. Los índices de una lista de Appian comienzan desde el 1 y no desde el 0 como en algunos lenguajes de programación. Diccionarios, compuestos por llave y valor (key:value), para conseguir datos de un diccionario, es un poco común usar la función index() para obtener el valor, por ejemplo:
El detalle con este tipo de arreglo es que puede que su resultado sea considerado como de tipo Any Type (Text) y esto puede causar inconvenientes en un futuro si se desea buscar un contenido de tipo Text cuando el resultado que tenemos difiere de lo requerido.
El caso anterior se puede solventar si se hace uso de la función map() el cual asocia el tipo de dato correcto de cada elemento que forma parte del arreglo, adicionalmente elimina el uso de llaves a la hora de la definición del arreglo.
Conversiones. Algunos elementos requieren que sean referidos a su tipo de dato de manera correcta, en ocasiones es interpretado por un tipo erróneo y para ello se pueden usar funciones para corregir esto, incluso dentro de la declaración del arreglo.
Si tenemos declarado un arreglo tipo diccionario multi-tipo de datos como un index() se puede hacer uso de la función tostring() y dentro de ella meter el arreglo generado con la función de índice y con esto convertir su tipo a Texto, pero si se tiene un arreglo simple al usar esta función genera una sola cadena con los datos y no una lista, para ello se puede hacer uso de la función touniformstring() en lugar de tostring().
Los comentarios dentro del editor de expresiones se hacen con /* */
Llamada a objetos. Todos los objetos que son considerados reglas de negocio pueden ser referenciados por otras reglas de negocios usando expresiones. Reglas de negocio (Business Rules): Reglas de expresión, Interfaces, Integraciones, Objetos de decisión y Constantes. Todas las reglas de negocio, a excepción de las constantes, pueden ser llamadas usando el prefijo rule! y el nombre del objeto, las constantes se pueden llamar con el prefijo cons! y el nombre de la constante.
Pruebas y resolución de problemas de expresiones. Un error de sintaxis es reconocido con un ícono de un triángulo rojo con un signo de exclamación dentro de él. Error “Target is missing” es probable que el error sea causado por una coma faltante. La creación de los casos de pruebas tiene como objetivo asegurarse de que exista una posibilidad limitada de que la aplicación produzca un error o no funcione como se esperaba, estos se pueden crear en la sección de pruebas de reglas, dando clic en la opción de Save as Test Case, se le asigna un nombre y se procede a crear. El historial de control de versiones de la aplicación se puede localizar en el ícono del engrane, durante la edición del objeto, se puede comparar lo que se modificó entre versiones y en caso de requerir regresar a una versión anterior y salvarla como la versión actual.
* Data Design in Appian.
El diseño de datos integral simplifica el proceso de desarrollo de aplicaciones. Estrategias para el diseño de datos de Appian:
Algunas funciones poderosas de Appian que se pueden considerar durante el diseño de datos:
Seguridad. Es crucial el manejo de seguridad, en particular por la información sensible que puede residir en la aplicación.
Transformación de datos. Extender la información o saber cómo presentarla. Pensar en qué datos deben estar en la fuente y qué se puede derivar de esa información.
Seguimiento de eventos comerciales. Hacer un seguimiento de quién hace qué y cuándo, puede ayudarte a comprender mejor el negocio y mejorar su funcionamiento, con los eventos de registro se puede capturar esta información.
Campos de registro personalizados. Te permiten calcular, simplificar o transformar los datos existentes, por ejemplo, al tener un par de fechas y un empleado que realizó una orden, podemos calcular el tiempo transcurrido en el envío de la orden.
Crear un modelo de datos a partir de los requisitos comerciales. Tener un modelo de datos preciso ayudará a garantizar que su equipo comprenda la organización de los datos de la aplicación. El modelado de datos es un proceso iterativo.
Identificar las fuentes (de donde provienen los datos) es importante durante el diseño de datos porque afectará las decisiones de diseño que tome durante el desarrollo, como el cómo y cuándo se actualizarán los datos.
El rendimiento de la base de datos se refiere a la rapidez con la que el sistema de gestión de bases de datos entrega información a los usuarios. Las consultas lentas pueden causar retrasos para los usuarios finales, como una carga lenta de la interfaz o la ejecución del proceso. El uso de tipos de registros con sincronización de datos habilitada (data sync) evita estos problemas comunes porque manejan automáticamente el ajuste del rendimiento por usted.
Un índice es un puntero a los datos de una tabla, como un índice de un libro. No hay que crear muchos índices diferentes para una tabla con muchas inserciones. Cuantos más índices tenga, más lentas serán las inserciones.
Utilizar estas tres estrategias para ayudar a que el modelo de datos sea más escalable:
Durante la planificación de la aplicación, además de identificar qué datos tendrá su aplicación, también debe pensar en cuántos datos se crearán.