Automate your business processes

 

Plan an Appian Process

 

• Se recomienda crear procesos cortos, de manera que se incrementa la rapidez al añadir datos a una BD
• Un proceso debe contener una cantidad razonable de nodos

 

Appian auto genera default process models. Podemos ocupar estos procesos y extenderlos o podemos crearlos manualmente.

 

Create and secure process models

 

Process models no heredan la seguridad del folder padre

Debe aplicarse la seguridad por individual usando grupos

Administrator es el grupo con la mayor cantidad de permisos, es decir está en el más alto nivel

 

The process modeler and configure properties

 

Puedes añadir smart devices al canvas para:

 

Enviar un E-mail

Integrar un servicio web

Ejecutar un proceso robotico

 

Para generar documentacion de nuestro process models podemos ir a tools -> generate documentation

 

Una vez que generamos un nuevo process model debemos dirigirnos a la configuracion de alerts y data management, Alerts nos determina quien recibe una alerta en caso de que ocurra un error en una instancia.

 

Data management la ocupamos para archivar o eliminar procesos, esto debido a que los procesos guardados ocupan espacio de memoria y pueden afectar el performance de la aplicación. El manejo del mismo dependera del data retention policy de la compañía.

 

Deadlines -> se ocupa para realizar un "trigger" y escalar a cierto usuario en caso de que una tarea no sea completada

 

Configure a Start Form and process variables

 

Rule inputs pueden facilmente pasar datos entre process models e interfaces, ademas puedes ocuparlos como variables para capturar datos de formularios. Para hacer esto las rule inputs deben estar mapeadas a process parameters y estos a process variables las cuales capturan datos a traves de todo el proceso.

 

Node Inputs and outputs -> Son conocidos tambien como activity class parameters

 

Node output -> variables que son únicas a un nodo especifico

 

Node inputs, outputs deben de ser guardadas en process variables para que puedan pasar al siguiente nodo en el proceso

 

Para arreglar issues debemos "save and publish" antes de hacer nuestro debug

 

Configure a user input task

 

Se configuran user input task cuando necesitamos asignar una tarea a usuarios

 

Al configurar una tarea podemos configurar una escalacion o excepcion

 

La escalacion permite que la tarea pueda ser reasignada o recordada al dueño de la tarea

 

Caso contrario al configurar una excepcion la tarea no permanecera activa despues de que el timer especifico expirec

 

Configure Gateways

 

Controlan el workflow en un process model, basandose en decisiones que podemos establecer

 

Para configurarlos podemos ocupar el decisión tab

 

Hay cuatro gateways en Appian

 

XOR(el mas común): separa un solo camino entre muchos y se basa en una condicion

 

AND : separa un solo camino entre muchos en donde todos los caminos que deriven del principal serán ejecutados, generalmente es usado si necesitamos ejecutar muchas actividades en paralelo

 

COMPLEX Selectivamente acepta los flujos entrantes y evalúa cuales de ellos continuan

 

OR divide un camino entre muchos, pero únicamente se ejecutaran aquellos que cumplan la condicion

 

Configure a Script Task and Write Record Smart Service

 

Configuramos scripts con la intención de :

 

Llevar a cabo una actividad automatizada

Usan una expression para manipular datos

Evaluar una decisión para determinar el flujo

 

Usualmente son configurados a traves de node outputs

 

Para asegurarnos que este nodo siempre se ejecute debemos seleccionar "Run as whoever designed this process model" en el assigment tab

 

Unicamente podemos ocupar Write records smart services con record types quie cumplan la siguiente condicion

 

• Tengan data sync enabled
• Obtengan datos de una tabla de base de datos

 

 

Modularize with start processes and subprocesses

 

La principal diferencia entre estos procesos es el uso de memoria

 

Start process

• Un start process se ejecuta en el engine con el menor uso de memoria
• El start process puede solo ejecutarse asincronamente
• Generalmente el start process es la mejor opcion por que tiene un mejor performance

 

Subprocess

• Un subproceso se ejecuta en el mismo engine como "parent process"
• Un subproceso puede ejecutarse síncronamente o asíncronamente
• Con funcionalidades "tricky" es mejor un subproceso

 

Common use cases

 

• Multiple touches or approvals
• Integrations
• Timers or rule events
• Reusable generic steps

 

Trouble shooting your process model

 

Publish errors: automaticamente valida que este configurado correctamente, podemos guiarnos con el mensaje de error

 

Common errors

 

Datos no capturados, significa que los datos no fueron mapeados correctamente, debemos asegurar que display value y save input to esten configurados correctamente

Datos no escritos en la database table: Debemos checar los inputs y configuracion.

Monitor view

Aquí se encuentran process instances con errores facilmente

Process Details

Aquí podemos investigar variables y errores en sus respectivos tans

 

Surface a Process to Business Users

• Navegar desde dentro de un record type: Process model para crear un record action, record list action, etc
• Navegar como una standalone action page

Record action

Añadir un record

Actualizar un record

Eliminar un record

Step by step 10 y 11

PDF

 

 

 

 

 

 

Apply Security

Learning Objectives

After completing this lesson, you should be able to:

• Apply security to record type objects, record actions, and records

 

 

Create Security Rules

You can create security rules for different users in your application. You will learn how to set up these rules based on 

• who is part of the rule? 
• which records they can see?

 

Note that users must have at least Initiator permissions to the action's underlying process model.

 

Lesson Summary

In this lesson, you learned that you need to set up security for the record type and other objects it is related to, such as a process model, to ensure users can view intended data. Finally, you learned how security can be applied to show or hide sections of your record. 

Course Summary

You have now completed the Records course. You should be able to:

• Explain the benefits of using Appian Records
• Plan and design effective records
• Create and configure record type objects
• Apply security on your record type and record data
• Create record type relationships

 

Course Objectives

After completing this course, you should be able to:

 

• Create record type relationships in Appian
• Create custom record fields using related data
• Reference related data throughout an application

 

Lesson Objectives

After completing this lesson, you should be able to:

• Define record type relationships
• Summarize the value of record type relationships

 

Learning Objectives

After completing this lesson, you should be able to:

• Create a record type relationship
• Edit a record type relationship
• Create an interface referencing data from two record types

 

 

 

Lesson Summary

In this lesson, you learned how to create your first record type relationship inside a record type object. You learned how to review your relationships with the record type relationship diagram. Then you learned how to edit relationships and add suggested relationships. You also learned how to use two record types in the same interface to show an enterprise view of your data. Finally, you learned how to customize your record search.

 

 

Lesson Summary

In this lesson, you learned several ways to set up the aggregate related record fields, custom record field.  You also learned how to filter a custom record field, and in what scenarios it may be useful. Finally, you learned how to add a custom record field to an interface.

 

Learning Objectives

After completing this lesson, you should be able to:

• Apply source filters to your record
• Apply default filters to your record list
• Apply user filters to your record list

 

• Lesson Summary
• In this lesson, you learned that a user filter is auto generated when establishing a many-to-one relationship. You also learned how to create a record type query expression user filter.

 

 

Learning Objectives

After completing this lesson, you should be able to:

• Create several record types to manage data from a reference table
• Apply a records-powered grid using related record type data

DEFAULT FILTER: To display a subset of records from the data source, based on filter criterio, ES UNA PRESELECCIÓN…

Save

Next, save your record type. This will prompt the first sync of your record type data which means it is creating a cache of data from your database.

 

Lesson Summary

In this lesson, you learned how to use a reference table from Acme Auto’s relational database and apply source filters to create several new record types. You also learned how to reference the related data in a read-only grid.

 

 

• Create Record Type Relationships in Appian
• Create custom record fields using related data
• Reference related data throughout an application

 

 

 

 

 

Course Objectives

After you complete this course, you’ll be able to:

• bullet

Explain what sites and portals can do for your app users

• bullet

Determine which one is the right fit for your business use case

• bullet

Create, configure, and secure a site

• bullet

Create, configure, and publish a portal

DIA 5!!!!!!!!!!!!!!!!!!!!!!!

 

There are three primary elements that make up the record type object: record data, records, and the record list. Each of these elements contribute to how users will eventually see and interact with the data.

 

 

Skip Failed Syncs

If there is an issue syncing your data, you can configure Appian to skip a failed sync, and to instead use data from the last successful sync. Access the Sync Options tab, and ensure that the Skip Failed Syncs is turned on. This way, your application users will be able continue viewing and acting on data from the last successful sync, without experiencing any disruptions.

 

Lesson Summary

In this lesson, you learned how to create a new record type object sourced from an existing database and how to generate a database table from within the record type object. You also learned how to enable data sync on a record type so the vehicle data is cached in Appian, and how to configure Appian to skip a failed sync and to use data from the last successful sync instead. Next, you learned how to initially configure the fields you would like to include in the record type. Finally, you learned about the data model overview screen that shows you the current data structure of your record as well as related record types. 

 

 

 

 

Query a Record Type

Learning Objectives

After completing this lesson, you should be able to:

• Explain how queried record data can be used in your application
• Query a record type using the Query Editor

 

 

a!queryRecordType( )

Before we walk through how to return a single row of data, let’s briefly discuss how else you might use queries in your applications. First, you may be familiar with the function a!queryEntity(). This function queries your database and returns the requested data. In this lesson you will learn about a similar function called a!queryRecordType( ). Instead of querying a database, it looks up and returns data from your record type object. 

You can use this function to return:

 

• a list of values for a single record field 
• a list of records with a subset of the fields
• aggregate data
• a single row of data

 

Query a Record Type

In this lesson, you will learn how to generate an expression using the query editor. That expression will query the vehicle record type and return a row of data.

You’ll see this query used for testing, but record data can be used in any interface within an app. Note that this work is being done in the expression rule object and not in the record type.

 

Lesson Summary

In this lesson, you learned how to create a new expression rule to pass in a record id and have that expression query the record data to retrieve a single row of data. 

 

Configure the Record List

Learning Objectives

After completing this lesson, you should be able to:

• Configure a record list
• Identify additional objects where record data can be displayed

 

Apply Filters

Learning Objectives

After completing this lesson, you should be able to:

• Apply source filters to your record
• Apply default filters to your record list
• Apply user filters to your record list

 

 

• Lesson Summary
• In this lesson, you learned how default filters determine which records appear in the record list and views, based on the conditions you specify. Then you learned how to create interactive filters so users can determine which records appear in their record list or grids that use record data. You learned the difference between static and expression-based filters. You also learned how users can save filters and use the search field in a record list. 

Create Record Views

Learning Objectives

After completing this lesson, you should be able to:

• Define the purpose of a record view
• Create a record summary view
• Create and link an interface used to display a record view

 

Record Actions

After completing this lesson, you should be able to:

 

• Contrast a record action and related action
• Generate a record list action
• Create a related action

 

This lesson is all about record actions. There are two types: record list actions and related actions. In this lesson, we’ll go over the differences between the two and have Appian generate each.

RECORD LIST ACTION

A record list action is a link to a process model that a user can start directly from the record list. The most common type of action to configure here is for users to create a new record for that record type. For example, we’re going to configure a record list action to add a new vehicle.

RELATED ACTION

A related action is also a link to a process model. This differs from a record list action because these process models are started directly from a record view and use data from that record.

 

 

 

 

 

 

 

Apply Security

Learning Objectives

After completing this lesson, you should be able to:

• Apply security to record type objects, record actions, and records

 

 

Create Security Rules

You can create security rules for different users in your application. You will learn how to set up these rules based on 

• who is part of the rule? 
• which records they can see?

 

Note that users must have at least Initiator permissions to the action's underlying process model.

 

Lesson Summary

In this lesson, you learned that you need to set up security for the record type and other objects it is related to, such as a process model, to ensure users can view intended data. Finally, you learned how security can be applied to show or hide sections of your record. 

Course Summary

You have now completed the Records course. You should be able to:

• Explain the benefits of using Appian Records
• Plan and design effective records
• Create and configure record type objects
• Apply security on your record type and record data
• Create record type relationships

 

Course Objectives

After completing this course, you should be able to:

 

• Create record type relationships in Appian
• Create custom record fields using related data
• Reference related data throughout an application

 

Lesson Objectives

After completing this lesson, you should be able to:

• Define record type relationships
• Summarize the value of record type relationships

 

Learning Objectives

After completing this lesson, you should be able to:

• Create a record type relationship
• Edit a record type relationship
• Create an interface referencing data from two record types

 

 

 

Lesson Summary

In this lesson, you learned how to create your first record type relationship inside a record type object. You learned how to review your relationships with the record type relationship diagram. Then you learned how to edit relationships and add suggested relationships. You also learned how to use two record types in the same interface to show an enterprise view of your data. Finally, you learned how to customize your record search.

 

 

Lesson Summary

In this lesson, you learned several ways to set up the aggregate related record fields, custom record field.  You also learned how to filter a custom record field, and in what scenarios it may be useful. Finally, you learned how to add a custom record field to an interface.

 

Learning Objectives

After completing this lesson, you should be able to:

• Apply source filters to your record
• Apply default filters to your record list
• Apply user filters to your record list

Día 5
Es importante tener en cuenta los medios necesarios para conocer lo mejor posible los procesos de negocio que buscaremos representar a través de nuestra aplicación, con la finalidad de crear un process model en Appian de la manera más eficiente posible, para ello nos apoyaremos de la planificación de procesos en Appian, dentro de las principales buenas practicar encontramos:

• Crear records (el equivalente de entidades en Appian) que representen la esencia del trabajo de la organización o sector de donde se esté realizando la aplicación.
• Los modelos de proceso no deben ser diseñados/construidos para mantener datos, estos deben ser almacenados lo antes posible, su finalidad es realizar tareas con una secuencia
  logica, utilizar variables de proceso, metadatos adicionales, etc., debido a que en Appian poseemos memorias finitas, es importante hacer un uso eficiente de la misma.
• Es recomendable construir modelos de procesos pequeños, que requieran la menor cantidad de variables posible y no adquieran complejidad, en caso de no ser posible se recomienda
  hacer uso de subprocesos o arreglos modulares, esto con la finalidad de crear workflows cortos que no se ejecuten durante un lapso de tiempo prolongado, reduciendo el uso de memoria.
• Adicional al punto anterior, como excepción se recomienda agregar un limite de tiempo a las tareas de los procesos, esto evita la larga vida de los pocesos, logrando que se
  haga un uso eficiente de los recursos.
• Al momento de crear un process model se puede crear uno desde cero o duplicar uno, cada que se crea uno nuevo se recomienda incluir al inicio del nombre el prefijo de la aplicación
  y agregar descripciones cortas.
• Es importante tener en cuenta que los objetos de tipo process model no heredan la seguridad de los directorios, por lo tanto, es importante crear sus respectivas reglas de seguridad.
• Como buena práctica global dentro de Appian se recomienda manejar grupos en lugar de usuarios durante la creación de reglas de seguridad.

Al crear un nuevo proceso, una vez realizados los pasos anteriores, tendremos como nodos iniciales un inicio y final ya creados en nuestro canvas, a la izquierda tendremos nuestra paleta de componentes y en el lado superior tendremos el menú y nuestra barra de herramientas, haciendo énfasis al canvas, el cuál es el componente principal sobre el que estaremos trabajando ya que ahí elaboraremos nuestro workflow, dentro de nuestra paleta de componentes Appian nos proporciona una barra de busqueda y tres secciones:

• Sugerencias: Appian nos sugerirá con base a nuestro workflow, que smart service podemos integrar a alguno de nuestros nodos
• Workflow: Dentro de esta sección tendremos 4 tipos de componentes:

1. Human tasks
2. Activities
3. Events
4. Gateways

• Automation smart services: Cada smart service dentro de esta sección se considera una mini aplicación que le proporciona una funcionalidad diferente y sofisticada a nuestro
  proceso, como, por ejemplo:

1. Invocar un web service
2. Envíar un email
3. Ejecutar procesos robotizados.

Dentro de nuestro Canvas podemos dividir nuestra área de trabajo o crear secciones para los grupos que hemos asignado durante la etapa de configuración de seguridad de nuestro process model, es en estas secciones donde podemos crear workflows específicos para cada uno de ellos, dentro de las propiedades globales de nuestro process model tenemos múltiples pestañas, las cuales son:

• General: Modificar parámetros generales de nuestro objeto.
• Variables: Modificar/crear variables para nuestro process model.
• Process start form: Modificar desde cual interfaz queremos iniciar nuestro process model.
• Deadlines: En esta tab podemos modificar la fecha de deadline para nuestro proceso, los deadlines estan enfocados a tareas que sean asignadas en nuestro proceso.
• Alerts: Crear alertas en caso de expresiones las cuales podemos especificarle a Appian a que grupo deseamos que le lleguen las alertas.
• Data management: Desde esta tab podemos especificar el lapso dentro del cual podremos archivar o borrar la instancia de nuestro proceso.

Para relacionar nuestros procesos con interfaces visuales tenemos que linkearlos a través de las propiedades de nuestro process model y especificar que interfaz queremos conectar, para
el intercambio de variables Appian nos dará la opción de asginarlas de manera automática, si este fuera el caso, al dirigirnos a nuestra interfaz, observaremos en el panel derecho reglas
creadas para nuestras variables de intercambio, estas reglas nos sirven para realizar un intercambio más rapido y eficaz entre proceso e interfaz, estos parametros pueden ser usados también
como variables que guardan valores de entrada de nuestros formularios, estas variables también pueden ser creadas de forma manual, otros tipos de variables que se manejan en Appian son:

• Node inputs
• Node outputs

Estas variables son únicas y especificas por cada nodo, como buena práctica se recomienda debuguear cada vez que un nuevo nodo es añadido,entro de los componentes que podemos incluir en nuestro
Canvas nos encontramos con los input tasks los cuáles sirven para asginar tareas especificas por tipo de grupo asignado, dentro de las propiedades que poseen nuestros input tasks
tenemos las pestañas:

• General: Dentro de esta pestaña podemos modificar los atributos generales como el nombre y la de nuestra user task, cabe resaltar que podemos modificar el nombre a desplegar en nuestra lista
  de procesos, otra gran ventaja que nos otorga Appian es la concatenación de variables en los nombres, facilitando así tareas de supervisión.
• Data: Es en esta sección donde haremos el mapeo de nuestros parametros con nuestras varables del proceso.
• Forms: En esta pestaña le indicamos a nuestra user task que interfaz queremos usar para completar la tarea.
• Scheduling:
• Assignment: En esta pestaña indicaremos hacía que grupo queremos que se designe la tarea.
• Escalations y Exceptions: Aquí podremos aplicar configuraciones como limite de tiempo, escalar la tarea, entre otras en caso de que las tarea falle en completarse.

GATEWAYS
Controlan el workflow en un process model, son puntos de decisión que controlan la ruta del proceso acorde a los puntos de decisión asignados, los tipos de gateways manejados en Appian son:

• XOR: Convierte la ruta en multiples opciones de ruta de salida, basadas en una condicion.
• AND: Convierte la ruta en multiples opciones de ruta de salida, en este caso todas las salidas se ejecutarán ya que no existen salidas condicionadas en este componente.
• Complex: Acepta selectivamente rutas entrantes y evalua la ruta correspondiente.
• OR: Convierte la ruta en multiples opciones de ruta de salida, basadas en condiciones, solo se ejecutarán las que sean verdaderas.

Scrip tasks
Se utilizan para realizar tareas que no se requiera la intervención de un actor o usuario, como por ejemplo agregar la fecha de captura de un record de un vehículo o el usuario que realizó
el registro (para este último se utiliza la propiedad pp!Initiator).

Write records
Los smart services para realizar operaciones en la base de datos como registrar, borrar y actualizar se usan unicamente para registros que provengan de base de datos, no funcionan con registros
que provengan de servicios web u otra fuente, para esos casos existen otras alternativas, así mismo la información debe estar en modo de sincronización y debemos elevar los permisos.

Procesos y subprocesos
Como mencionábamos anteriormente, es importante hacer un uso eficiente de la memoria que disponemos en la plataforma para ello podemos utilizar procesos y subprocesos dentro de nuestro process model, para ello existen importantes diferencias las cuáles debemos considerar para saber cuál usar apropiadamente:

• Subprocess
  -Corre en el mismo entorno que el proceso padre.
  -Corre de manera sincrona o asincrona.
  -Mejor para funcionalidades difíciles.
• Start process
  -Corre en el mismo entorno con menor uso de recursos.
  -Tiene un mejor performance.
  -Corre de manera asincrona.

Es importante tener en cuenta que para tareas de investigación en caso de escpeciones podemos ir a Monitoring -> process y con los titulos correctos identificaremos el evento que detonó una expeción.

DIA 6

Lesson Objectives

After you complete this lesson, you'll be able to:

 

• Create a site
• Configure a page
• Define page capabilities
• Identify what branding elements can be managed
• Discuss best practices when customizing site branding

 When you assign a display name to a new site, consider the following guidelines.

• Do not start the display name with the application prefix, because end users will see the entire display name.
• Use a short name that is meaningful to your end users.
• Use title case.
• Appian uses the display name to construct a default web address identifier for the site. To refine the site URL, edit the default web address identifier.
• The display name can duplicate another object name in the Appian environment, but the web address identifier must be unique.

 

 

 

 

 

 

Watch: Customize Site Branding!!!!!!!!!!!

 

 

 

Lesson Objectives

After you complete this lesson, you'll be able to:

 

• Describe how to ensure a user is able to view the site
• Discuss how a user’s access can be controlled across pages

 

 

 

 

 

 

 

 

Lesson Objectives

After you complete this lesson, you’ll be able to:

 

 

• Explain what a portal is, and recall common use cases
• Describe the high-level steps for designing a portal

 

 

Common Use Cases

 

In its simplest form, a portal is one or more interfaces created in Appian and published at a public URL, but it can also include a number of additional design objects. For example, if you want a user to fill out a form, and then launch an Appian process, you'll build an interface and a process model, along with any other necessary objects. 

 

Interfaces added as pages in a portal can't use rule inputs, so you'll use local variables instead. 

 

Configure Permissions

Portals are publicly accessible, but that doesn't mean they aren't secure.

To control access to your Appian environment, you'll create a service account. A service account acts on behalf of portal users, providing the portal with permissions to connect to selected information and processes in Appian. 

You can create the service account directly from within the portal object, but then you'll need to add this account as a user to your app’s All Users group (or any other group that you want to use for your portal’s security).

 

After you implement all configurations, it's time to publish, test your published portal, and prepare for deployment. Keep a few details in mind:

• You only need to publish the portal once. Appian will automatically republish the portal upon deployment, or if you update the portal object or its precedents. 
• For a portal to auto-publish in a new environment, set up a service account with the same name as the service account in your source environment.
• To test, navigate to the published portal and use it the way the end user would.
• To deploy a portal to another environment, add it and all precedents to the deployment package.

 

Before creating a portal form you could need:  

 

• Interface
• Process

OJO el usuario genérico se crea en otro lado!!!

 

 

Display Data with a!queryRecordType

If your app uses record types and you want your portal to display data from Appian, configure the underlying interface using the a!queryRecordType function. This is what our developer did in the interface for the Acme Automobile’s Auditor Validation Portal. She added a local variable - local!maintenanceData - and then used the a!queryRecordType function to query the Maintenance record type. 

 

Tip: You can review this example in the Appian Community Edition environment. Request your instance, and navigate to the Acme Automobile Reference Application. Review the interface used in this app's portal (AA_PRTL_DSH_AuditorDashboard).  

 

Día 6
Las interfaces dinámicas se adaptan a las necesidades y preferencias del usuario, muestran lo que el usuario necesita cuando lo necesita, esto reduce el desorden y evita confusión por parte del usuario, Appian nos proporciona plantillas predefinidas con las que podremos modificar y empezar
a trabajar, dentro de nuestro entorno de desarrollo de interfaces tendremos dos vistas para trabajar:

• Design mode: En este modo encontraremos una paleta de componentes y nuestra interfaz sobre la que podremos arrastrar los elementos a usar.
• Expression mode: En lugar de mostrarnos la paleta de componentes nos mostrará la interfaz para expresiones.

Dynamic links
Es un componente visual de las interfaces en Appian el cuál convierte una etiqueta de texto, icono, card, etc., en un componente que nos permite
ocultar o mostrar otros componentes visuales dentro de nuestra interfaz.

En Appian es importante considerar que la información desde etapas tempranas del flujo de trabajo se maneja de forma local, antes de esto debemos
tener importadas nuestras entidades necesarias desde nuestra base de datos, con nuestras entidades manejadas de manera local podremos hacer uso de nuestra información a través de Grids, listas, formularios, etc.

Las variables en las interfaces serán guardadas de manera local, podremos encontrar 2 propiedades en nuestros componentes para almacenar nuestros valores:

• Value: valor a guardar.
• saveInto: la variable a guardar el valor

DIA 5

Un process Model sólido debe ante todo tener un número razonable de nodos y variables de proceso,  debe estar configurado para expirar o ser reasignado después de un tiempo de inactividad. Un proceso largo debe dividirse en start processes o subprocesses.

 

Un proceso …

• Puede crearse de inicio o duplicar alguno.
• Debe usar grupos para su seguridad
• Debe usar niveles de seguridad de administrador y viewer
• El administrador es el nivel mas alto
• Viewers pueden ver e iniciar un proceso pero no puede modificarlo.

Los Smart services son

• Send E-mail
• Integrate with web services
• Excecute robotic processes

Un proceso se debe archivar por tres días, y se debe establecer un deadline por cada nodo para que nunca se quede atorado, siempre debemos preveer que el procesos de terminarse.

 

Para los modelos de proceso:

• Para diseñar un modelo de procesos ejecutable podemos usar el designer view.
• Use the analytic view para crear diagramas de alto nivel  de procesos
• Appian provee a los desarrolladores con nodos de flujo, y procesos inteligentes de automatización.
• No olvide configurar alertas y data management en los procesos.

Día 6

Interfases 101

En este curso aprendí:

• Para que se usan las interfases
• Como usar rule inputs y local variables
• Como crear y configurar una interfase sencilla
• Cuales son las mejores prácticas de diseño de interfases
• Como probar una interfase

 

Para construir interfases tenemos múltiples herramientas entra las cuales destacan:

• Tipos de campos
• Variedad de diseños
• Forms
• Grids
• Reports

Para crear una interfase:

• Debemos reconocer las principales áreas del objeto interfase
• Dominar el uso de templates, layouts, Components y patterns
• Distinguir entre modo diseño y modo expresión

Al crear una interfase tengo claro como

• Crear un objeto interfase
• Como usar rule!inputs
• El propósito de rule!inputs

El uso de variables locales requiere comprender perfectamente su entre lo cual los conceptos mas importantes son:

• Esta almacenan información localmente dentro de una expresión
• Solo existen en el ámbito de una expresión, no necesariamente dentro de una interfase
• No se pueden referencia fuera de la expresión donde fueron declaradas

Los usos principales de las variables locales son:

• Almacenar data de un query
• Desplegar información condicional
• Capturar data de un usuario para modificar la interase

Dia 7

Día 7

Para nuestra aplicaciones contamos con la posibilidad del uso de CDT’s  para el manejo de la información de los record types.

En general el manejo de los record type es el ideal para el control de información,  pero habrá ocasiones en que  el manejo del CDT será ideal para almacenar su información.

Un record type al no estar sincronizado requerirá conectarse con los datos a través de un “data store entity”.

Se usará un data-plugin  para definir un CDT como un objeto java.

Al crea un custom document type para la extracción de documentos los campos son representados a través de un CDT.

El modelo de procesos incluye un export del “Data store entity” a “Excel” o a “CVS”,  para esto se requiere un CDT como parte de la configuración.

Los CDT tiene como recomendación diseñ*** como se muestra abajo, esto se basa en el tipo de relación que tenga el CDT.

Los tipos de CDT son

• Anidados
• Planos

Marco Polo Martínez Badillo

En resumen, los modelos de proceso en Appian son representaciones visuales de los flujos de trabajo empresariales que se crean utilizando la vista de analista y diseñador. Estos modelos permiten diseñar, automatizar y gestionar los procesos de negocio de manera eficiente.

Con esta notación, puedes definir las tareas, los eventos, las decisiones y las condiciones de un proceso, y luego conectarlos en un flujo lógico para mostrar cómo se ejecuta el proceso en la realidad, pueden incluir reglas de negocio, formularios, integraciones con sistemas externos y otras capacidades avanzadas para gestionar y controlar los procesos.

Entiendo que dentro de los beneficios clave se encuentran, la supervisión y control que nos va a permitir monitorear el progreso de los procesos en tiempo real, visualización clara con una representación visual de los flujos de trabajo, lo que permite a compañeros comprender fácilmente el proceso, automatización y optimización, pues nos ayudan a automatizar tareas repetitivas, eliminar cuellos de botella y optimizar los flujos de trabajo para mejorar la eficiencia y flexibilidad y escalabilidad, nos ofrece una plataforma flexible y escalable que permite adaptar los modelos de proceso a medida que evolucionan las necesidades de la organización.

Hecho por: Josué Quintero SIlva