introduccion abp ms

1|BPMS 2|Intranet 3|Document Management 4|Content Management 5|Online Commerce 6|Business Rules

Modelización

Procesos BPM. Introducción (24 Marzo 2015)

Esta publicación pertenece al Servicio de Documentación de AuraPortal (SDAP) y todos los

derechos están reservados. La reproducción total o parcial de este documento, así como la

entrega a terceras partes sin el permiso escrito del SDAP quedan prohibidas.

www.auraportal.com | [email protected] | Skype: AuraPortal | Tel: +34 962 954 497 |

Internacional: +18 572 390 070

http://intranet.auraportal.com/

mailto:[email protected]

skype:auraportal?call

PROCESOS BPM. INTRODUCCIÓN Página 2 de 152

ÍNDICE

1. ¿QUÉ SON LOS PROCESOS DE NEGOCIO Y BPM? ............................................................................................... 4

2. CICLO DE VIDA DE LOS PROCESOS ........................................................................................................................ 7

3. CLASE DE PROCESOS ............................................................................................................................................... 9

3.1. DATOS GENERALES ......................................................................................................................................... 12

3.1.1. Barra de Acciones ..................................................................................................................................... 12

3.1.2. Sección Identidad ..................................................................................................................................... 14

3.1.3. Sección Ejecución..................................................................................................................................... 20

3.1.4. Sección Cronometría ................................................................................................................................ 23

3.2. DIAGRAMA ......................................................................................................................................................... 24

3.2.1. Estándares BPMN, BPEL y XPDL ............................................................................................................ 26

3.3. OBJETOS ........................................................................................................................................................... 27

3.3.1. Tareas ....................................................................................................................................................... 28

3.3.2. Eventos ..................................................................................................................................................... 46

3.3.3. Compuertas .............................................................................................................................................. 59

3.4. LAPSOS .............................................................................................................................................................. 62

3.5. DOCUMENTOS BASE ........................................................................................................................................ 67

4. EJEMPLO DE MODELIZACIÓN ................................................................................................................................ 68

4.1. DIAGRAMA ......................................................................................................................................................... 70

4.2. OBJETOS ........................................................................................................................................................... 72

4.2.1. Paso 1. P1. IM Inicio ................................................................................................................................. 73

4.2.2. Paso 2. Tarea P1.TP Revisión para 1ª Aprobación .................................................................................. 87

4.2.3. Paso 3. P1.DX 1ª Aprobación? ................................................................................................................. 94

4.2.4. Paso 4. P1.DX.31 Requiere 2ª Aprobación? ........................................................................................... 99

4.2.5. Paso 5. P1.ET Solo Lunes y Jueves de 10:00 a 12:00............................................................................. 99

4.2.6. Paso 6. P1.TP.38 Aprueba el Jefe de DIV. ............................................................................................. 102

4.2.7. Paso 7. P1.DX.42 2ª Aprobación? ......................................................................................................... 102

4.2.8. Paso 8. Puntos de Control P1.K y P1.K.114.......................................................................................... 102

4.2.9. Paso 9. P1.TP.24 Notifica que ha sido Aprobado................................................................................... 103

4.2.10. Paso 10. P1.DX. 91 Material Disponible? ............................................................................................. 105

4.2.11. Paso 11. P1.TS.98 Notificación de Entrega ......................................................................................... 105

4.2.12. Paso 12. P1.TP 109 Recogida del Material ......................................................................................... 106

4.2.13. Paso 13. P1.TS.125 Actualiza Stock ................................................................................................... 107

5. EJEMPLO – EJECUCIÓN ........................................................................................................................................ 108

5.1. INICIO DEL PROCESO .................................................................................................................................... 108

5.2. FUNCIONAMIENTO DEL PROCESO .............................................................................................................. 110

5.2.1. Tarea P1.TP Revisión para 1ª Aprobación_4 ......................................................................................... 110


5.2.2. Compuerta P1.DX 1ª Aprobación? ......................................................................................................... 113

5.2.3. Compuerta P1.DX.31 Requiere 2ª Aprobación? ..................................................................................... 113

5.2.4. Evento Tiempo P1.ET Solo Lunes y Jueves de 10:00 a 12:00 ............................................................... 113

5.2.5. Tarea Personal P1.TP.38 Aprueba el Jefe de División ........................................................................... 114

5.2.6. Compuerta P1.DX.42 2ª Aprobación? ................................................................................................... 115

5.2.7. Punto de Control P1.K Punto de Control ................................................................................................ 115

5.2.8. Tarea Personal P1.TP.24 Notifica que ha sido Autorizado ..................................................................... 115

5.2.9. Compuerta P1.DX.19 2ª Material Disponible? ........................................................................................ 116

5.2.10. Tarea de Sistema P1.TS.98 Notificación de Entrega ........................................................................... 116

5.2.11. Punto de Control P1.K.114 Punto de Control ....................................................................................... 117

5.2.12. Tarea Personal P1.TP.109 Recogida del Material ............................................................................... 117

6. EJEMPLO – MONITORIZACIÓN ............................................................................................................................. 119

6.1. CUADRO DE MANDOS .................................................................................................................................... 119

6.1.1. Control de Ejecución ............................................................................................................................... 120

6.1.2. Consulta de Procesos ............................................................................................................................. 122

6.1.3. Consulta de Tiempos .............................................................................................................................. 122

6.2. BUSINESS INTELLIGENCE ............................................................................................................................. 123

APÉNDICE A1 - ESTRUCTURA AURAPORTAL Y PROCESOS ............................................................................. 124

A1.1. CALENDARIOS .............................................................................................................................................. 125

A1.2. ROLES............................................................................................................................................................ 126

A1.3. DICCIONARIO DE TÉRMINOS ...................................................................................................................... 127

A1.4. SERVICIOS WEB ........................................................................................................................................... 128

A1.5. ADAPTADORES ............................................................................................................................................ 129

A1.6. MENSAJES .................................................................................................................................................... 129

A1.7. FAMILIAS ....................................................................................................................................................... 130

APÉNDICE A2 - SEGURIDAD: CONTROL DE ACCESOS ......................................................................................... 140

A2.1. PREFILTROS DE FAMILIA ............................................................................................................................ 140

A2.2. AUTORIZACIONES ........................................................................................................................................ 141

A2.3. RECINTOS SEGUROS .................................................................................................................................. 142

APÉNDICE A3 - MODELIZACIÓN BPMN: OBJETOS ................................................................................................ 143

A3.1. TAREAS ......................................................................................................................................................... 143

A3.2. SUBPROCESOS ............................................................................................................................................ 144

A3.3. EVENTOS ....................................................................................................................................................... 145

A3.4. COMPUERTAS .............................................................................................................................................. 147

A3.5. COMPUERTAS (NOTACIÓN ESPECIAL) ..................................................................................................... 149

A3.6. ARTEFACTOS ............................................................................................................................................... 150


1. ¿QUÉ SON LOS PROCESOS DE NEGOCIO Y BPM?

Los Procesos son las partes en las que se puede dividir la actividad u operativa global de cualquier empresa

u organización. Su gestión y control se lleva a cabo mediante los sistemas llamados BPM.

Acrónimo

BPM significa 'Business Process Management' y BPMS significa 'Business Process Management Suite' o ‘Busi-

ness Process Management System’.

Aunque BPMS identifica el software que se ocupa de la gestión de los procesos operativos de la empresa u

organización, está generalmente aceptado el uso del término BPM para ambos significados: la gestión en sí y

el software que facilita dicha gestión.

BPM es, sin ninguna duda, la tendencia ya consolidada e imparable que está cambiando para siempre la

forma de gestionar las operaciones de las empresas y de cualquier organización en el mundo, permitiendo

mucha mayor flexibilidad, mucha mayor automatización y mucha mayor potencia.

Definición

BPM puede ser definido como:

“Una nueva categoría de software empresarial que permite a las empresas modelizar, implementar y ejecutar

conjuntos de actividades interrelacionadas –es decir, Procesos- de cualquier naturaleza, sea dentro de un

departamento o permeando la entidad en su conjunto, con extensiones para incluir los clientes, proveedores

y otros agentes como participantes en las tareas de los procesos”.

Alcance

Con una herramienta BPM de máximo nivel como AuraPortal, la empresa puede automatizar de manera

sencilla cualquier proceso, incluyendo los relativos a Recursos Humanos, Control de Calidad, Compras, Rela-

ciones con Clientes (CRM), Cadena de Suministro, Gestión del Riesgo, Ventas, Facturación y cualquier otra

clase de proceso que sea específico y particular de la empresa.

Ventajas

Las empresas que implantan un BPM mejoran TODA la entidad, sacan a la luz los puntos débiles y fortalecen

las actividades más importantes. Por lo tanto permite que las empresas sean más: Flexibles, Competitivas y

Eficientes.

Ventajas Competitiva y Económica

La tremenda ventaja competitiva que significa trabajar con BPM es tal que un creciente número de empresas

y organizaciones están adoptando el uso de herramientas BPM para no perder la competitividad frente a

otras que ya lo están utilizando.

Ello es debido a que, además de la superior potencia y flexibilidad operacional aportadas por los BPM, se

consigue, de forma prácticamente instantánea, un ahorro de costes empresariales comprendido entre el 20%

y el 50% y un Retorno sobre la Inversión (ROI) de hasta el 400%.


Integración

Aunque los procesos diseñados dentro del BPM pueden trabajar cómodamente de manera integrada con

software de gestión previamente existente en la empresa, como ERP y CRM, es previsible que las empresas

irán gradualmente modelizando mediante procesos BPM las actividades de las aplicaciones de ERP y CRM,

para sustituir dichas aplicaciones por los procesos modelizados, consiguiendo así mayor automatización,

flexibilidad, seguridad y potencia, además de la unificación global de la operativa empresarial.

Tres Pasos en BPM

El procedimiento para trabajar con BPM comprende tres pasos fundamentales:

- Construir el diagrama del modelo de proceso.

- Definir los valores de los parámetros tales como los nombres o roles de los ejecutores de las tareas,

etc.

- Poner inmediatamente en ejecución el proceso sin tener que esperar a ningún desarrollo de progra-

mación (suponiendo que se está trabajando con AuraPortal).

Ejemplos de procesos son:

Compras.

Gestión de los circuitos de compras.

Marketing.

Gestión de actividades de marketing y generación de demanda.

Oportunidades de venta.

Gestión de las oportunidades de venta, incluido el control de las acciones comerciales y la generación auto-

mática de los pedidos y contratos en su caso.

Fabricación.

Gestión de los procesos de fabricación o transformación.

Servicios.

Gestión de las prestaciones de servicios.

Circuito de ventas.

Gestión de los circuitos de ventas, facturación, cobros y reclamaciones.

Asistencia a clientes.

Asistencia permanente (hot-line) a los clientes.

Contabilidad.

Contabilidad, incluida la asignación y control de partidas presupuestarias.

Recursos Humanos.

Gestión de los recursos humanos incluyendo: contratación, salarios y remuneraciones, permisos, vacaciones,

despidos, control y optimización de rendimientos de trabajo, etc.


Finanzas.

Gestión financiera, abarcando el control del dinero, los préstamos, créditos y débitos con optimización del

destino de las inversiones y de las aplicaciones de los flujos de tesorería.

Situación económica.

Análisis de la marcha económica de la empresa, su rentabilidad, cuellos de botella y capacidades mediante

KPI o indicadores clave.

Recursos empresariales.

Optimización integral, desde una perspectiva global, de los recursos empresariales.

Estrategias.

Diseño y seguimiento de estrategias presentes y futuras en todas las áreas de actividad.

Normas de funcionamiento.

Establecimiento y actualización permanente de las normas de funcionamiento de la organización y de sus

reglas de negocio.

Proyectos de toda índole.

Diseño, seguimiento y control de proyectos de toda índole, tanto singulares como recurrentes y tanto en sus

etapas de preparación como en las de ejecución.

Contenidos informativos.

Creación, actualización y publicación de contenidos informativos de cualquier clase, en cualquier formato y

en todos los medios seleccionados.

Gestión de documentos.

Gestión integrada e inteligente de todos los documentos de la organización mediante potentes sistemas ‘File

System’ que permitan manejar (crear, modificar, buscar, imprimir, etc.) millones de documentos con gran

rapidez.

Web corporativa.

Publicación controlada en Internet y las redes sociales en general, incluyendo newsletters periódicas y el

diseño de páginas WEB actualizables dinámicamente y el mantenimiento de blogs, chats, mensajes, etc.

Comercio electrónico.

Comercio electrónico con actualización automática de las ofertas, incluyendo las cestas de la compra y las

pasarelas de pago.

Procedimientos jurídicos.

Gestión de la interacción de la organización con el marco legal de su actuación, incluyendo los procedimien-

tos jurídicos y procesales que pudiesen aparecer.

Otras gestiones.

Las demás gestiones y controles relativos a los procedimientos específicos de propio diseño, sin límite de

complejidad, que cada empresa u organización necesita, en función de sus características particulares, para

su óptimo funcionamiento individual.

CRM.

En general, la gestión llamada CRM que se refiere al control de la relación de la empresa con sus clientes,

proveedores y demás agentes, es ventajosa y óptimamente llevada con Procesos.


Todo lo anterior asentado sólidamente en un sistema reticular de ‘workflow’ que permite la comunicación

instantánea y fluida entre todos los participantes en la actividad empresarial, incluidos, además de los em-

pleados, los agentes externos como clientes, proveedores, intermediarios, administración central, y cuales-

quiera otros.

2. CICLO DE VIDA DE LOS PROCESOS

El Ciclo de Vida de los Procesos en AuraPortal consta de 5 etapas.

Veamos brevemente cada una de ellas:

Modelización

La Modelización es la etapa donde se diseñan las Clases de Procesos y comprende dos partes o etapas:

- 1. Diagramación. Es la parte del Ciclo de Vida de los Procesos en AuraPortal en donde se diseña

gráficamente el Diagrama que recoge la secuencia, trayectoria y conexiones de todos los objetos

que componen la Clase de Procesos.

Se realiza con la herramienta AuraPortal Helium Modeler incluida en AuraPortal y que se explica

con detalle en el Manual Helium Modeler.

- 2. Asignación de Atributos. Una vez se ha diseñado el Diagrama, la segunda etapa de la Modeliza-

ción consiste en la Asignación de Atributos a cada uno de los Objetos.


Esta etapa, que abarca la configuración de los Datos Generales de la Clase de Procesos y de los Objetos se

explica más adelante en este documento, sin embargo, el diseño de los Formularios, que son parte indispen-

sable de la Modelización pues recogen los datos necesarios para el desarrollo del Proceso, se trata en otra

serie de documentos independientes que se encuentran disponibles en la Knowledge Base de AuraPortal.

Simulación

Con AuraPortal es posible realizar ‘simulaciones’ de la ejecución de los procesos, es decir, hacer trabajar los

procesos de manera virtual en escenarios imaginarios en los que pueden darse circunstancias cuya influencia

en la ejecución de dichos procesos se pretende conocer y cuantificar. Estas operaciones deben dar luz sobre

posibles cuellos de botella, sobrecargas, desigualdad en el reparto de los trabajos, excesivos tiempos, costes,

etc.

AuraPortal ofrece dos maneras complementarias, no excluyentes:

- Simulación Estadística

- Simulación Real

Aunque esta etapa se configura desde la ventana general de la Clase de Procesos, su explicación detallada se

ha incluido en el Manual Helium Modeler.

Ejecución

Una vez se han finalizado las etapas de Modelización y Simulación y se da por válido el diseño de la Clase de

Proceso, ya puede pasarse a la Ejecución, lo que en términos de AuraPortal significa el paso al Modo En-

torno Producción.

En esta etapa los usuarios trabajarán normalmente en los procesos, introduciendo y consultando datos

reales según el diseño establecido.

Monitorización

Una vez los usuarios están trabajando normalmente, la Monitorización de los procesos permite controlar y

supervisar que la ejecución de los mismos se realiza según lo previsto o bien que hay desviaciones que nece-

sitan corrección.

Se pueden consultar todos los detalles referentes a la Monitorización en la documentación disponible sobre

Análisis de la Información y KPI.

Optimización

La necesidad o no de Optimización del diseño de las Clases de Proceso surge de los datos obtenidos con la

Monitorización y en caso de que sea necesario se exige que la herramienta BPM permita modificaciones

instantáneas del diseño de los procesos y que estas modificaciones sean inmediatamente aplicadas, sin ne-

cesidad de programación alguna, tanto en los entornos reales como en los imaginarios. Esta característica no

está presente en prácticamente ninguna herramienta BPM, con la excepción de AuraPortal, porque los BPM

en general requieren la intervención mayor o menor de programadores o expertos técnicos para poner en

ejecución las modificaciones en el diseño de los procesos, lo cual hace imposible realizar gran número de

diferentes pruebas del funcionamiento de los mismos en poco tiempo y de forma sencilla ya que en cada

caso habrá que reprogramar la aplicación.


Este documento constituye el punto de partida para iniciarse en el conocimiento del BPM de AuraPortal. Se

explica el diseño de las Clases de Procesos en general y en la documentación complementaria encontrará

todos los detalles para la asignación de atributos a los objetos y completar el diseño de los procesos. Estos

documentos son:

- Manual Helium Modeler

- Formularios Dinámicos

- Ejecutores

- Tareas de Sistema

- Gestión Documental

- Grupos de Campos y Tratamientos Distribuidos y otros.

3. CLASE DE PROCESOS

El primer paso consiste en crear una Clase de Procesos para controlar una problemática concreta de la Em-

presa. En AuraPortal, cada Clase de Procesos tiene su propio Modelo.

Este modelo es aplicado subsecuentemente a todos los Procesos de la Clase.


En la vida real podemos tener, por ejemplo, una Clase de Procesos llamada Ciclo de ventas (Sales Cycle).

Con este Modelo,

los procesos de esta Clase gestionan cada una de las operaciones de venta.


Para crear la Clase de Procesos se accede a la ventana de Modelización, en Estructura – Procesos-Árbol y

Clases, similar a la de la siguiente imagen.


En esta ventana se accede a la herramienta de Modelización, AP BPM Modeler y también se suministran los

Datos Generales de la Clase de Procesos. Está estructurada en una Barra de Acciones y 3 secciones: IDENTI-

DAD, EJECUCIÓN y CRONOMETRÍA.

Los detalles se explican a continuación.

3.1. Datos Generales

Aquí se suministran los datos relacionados con la Identidad del proceso, los datos relacionados con la Cro-

nometría, como el Calendario y el Reloj. Si no se rellenan toda la información, el sistema provee por defecto

los datos requeridos.

Una vez se ha creado la Clase de Procesos, ha de construirse su modelo. La creación de modelos de Clases

de Procesos en AuraPortal se realiza en dos etapas:

- Etapa 1. DIAGRAMA. Dibujar el diagrama con los objetos y sus líneas de conexión.

- Etapa 2. OBJETOS. Asignar a cada objeto los atributos que lo definen

Una vez hecho esto, ya pueden generarse y ejecutarse automáticamente los procesos de esa clase. No es

necesaria ninguna programación.

A continuación se explican los detalles de la página de Datos Generales.

3.1.1. Barra de Acciones

La Barra de Acciones contiene los botones genéricos de Salir, Guardar y Eliminar, y se completa con los bo-

tones Modo, Versionado, Seguridad y Caché.

Modo (1)

Permite determinar el la situación de la Clase de Proceso. Se distinguen los siguientes Modos:

1. Entorno Desarrollo. Es el modo que permite el desarrollo de un proyecto de Clase de Proceso en su

correspondiente versión. En este modo se puede permitir o no la ejecución de procesos, según intere-

se al administrador.

2. Entorno Pruebas. No permite modificar la Modelización de la Clase de Proceso pero permite realizar

simulaciones del Proceso desarrollado porque el Motor de Procesos está activado. Los datos genera-

dos en la simulación, aunque se graban como si se tratase del Entorno Producción pueden ser elimi-

nados o no cuando se pasa al entorno Producción.


Cuando se cambia de Modo una Clase de Proceso, de los entornos Desarrollo o Pruebas a los estados Pro-

ducción (Restringido o no), se puede elegir si se desea:

Eliminar los datos existentes en la simulación (Entorno Pruebas).

Mantener los datos de la simulación como datos reales.

3. Entorno Producción Restringido. No permite la iniciación (creación) de nuevos Procesos de esa Cla-

se pero permite que los ya iniciados continúen.

4. Entorno Producción. Es el modo que permite la iniciación (creación) y ejecución de los Procesos en

modo real, es decir, Productivo.

5. Bloqueado. Es un caso especial. Ocurre cuando desde el Entorno Producción (Restringido o no), se

interrumpe por el Responsable de la Clase de Proceso, probablemente debido a problemas de fun-

cionamiento, la marcha de todos los Procesos iniciados de esa Clase y además no se permite la inicia-

ción de nuevos en dicha Clase.

6. Desuso. Es el modo de la Clase (o Versión) cuando ya no se utiliza. Solo puede utilizarse si no hay

Procesos de esa Clase (o versión) en marcha, no permite la iniciación de Procesos.

Nota.

Los distintos modos de Clase de Procesos están diseñados para mantenerse aislados y

protegidos de manera que no afecten al funcionamiento de los Procesos que están en

Producción, aunque convivan en la misma instalación de AuraPortal.

Versionado (2)

Se realiza cuando se modifica una Clase de proceso en Producción y con algún Proceso en ejecución. A to-

dos los efectos, una nueva Versión de una Clase de Proceso es equivalente a una nueva Clase. En realidad, lo

que el sistema hace para permitir el desarrollo de la nueva versión es considerar que se trata de una nueva

Clase, pero que tiene como base de partida la versión actual.

Nota.

Combinando el Versionado y los Modos de Clases de Proceso: Entorno Producción, En-

torno Pruebas y Entorno Desarrollo, puede haber Clases de Procesos en Producción, los

usuarios trabajando con datos y reales, y que al mismo tiempo se estén modificando o

probando otras Clases de Proceso o versión de una de ellas.

Todo ello se realiza en la misma instalación de AuraPortal y se puede combinar con la

posibilidad de hacer pruebas previas en una instalación de Backup.

Con el Complemento Tres Entornos Sincronizados, se da un paso más en el control y

la seguridad porque permite que los tres Entornos estén físicamente separados en tres

instalaciones independientes, es decir, que los cambios de diseño y pruebas de Clases

de Proceso se realicen en instalaciones distintas e independientes de la que tiene los

datos reales.

Seguridad (3)

Incluye 2 opciones:

- Blindaje. Al pulsar este botón se muestra la ventana Blindaje. Mediante la introducción de un password,

se blinda la Clase de Proceso para que no sea visible a nadie que no posea el password con el cual se

blindó.


- Permisos. De uso exclusivo para AdminPortal, permite asignar permisos de Edición o Lectura para la

Clase de Proceso a uno o varios grupos de empleados. Más información sobre Permisos en Estructura

se puede encontrar en el Manual del Administrador Delegado.

Caché (4)

Situando el cursor sobre Caché, aparece un submenú con las opciones que se muestran en la siguiente ima-

gen:

Estas opciones permiten aplicar el uso del Caché a nivel completo de todos los formularios de la Clase de

Proceso a la vez.

Activar la caché aumentará la velocidad de apertura y manejo de los formularios. Cuanto más complejos

sean éstos, mayor será el beneficio.

Nota Importante.

Hay que recordar que si se hacen cambios en la configuración de los formularios,

es necesario vaciar su caché para que los cambios se apliquen en ejecución.

También se puede aplicar Caché a nivel de todo AuraPortal, desde Estructura o in-

dividualmente a cada Formulario, desde la ventana de configuración del mismo.

3.1.2. Sección Identidad

Al acceder a la ventana de modelización por primera vez solo muestra la sección de IDENTIDAD. Para crear

una Clase de Procesos se introducen los datos y se pulsa Guardar para que aparezcan el resto de secciones.


Contiene los siguientes campos:

Clave. Es una Clave para agrupaciones de Clases de Procesos según criterios particularizados de cada enti-

dad.

Pulsando sobre el ojo se selecciona una clave de entre las creadas en el Diccionario de Términos (se explica

en otro Apartado de este documento). Esta clave puede ser modificada en cualquier momento y formará

parte de la Referencia Base del Proceso, junto con el ID de la Clase de Proceso más la Versión de la misma.

Identificación del Proceso: Referencia

Cuando se crea una Clase de Proceso, el sistema se encarga de generar un código único de identifica-

ción que comprende una Clave, un número de Clase y un número de Versión. Este código identifica la

Clase de Procesos.

Cuando se inicia un Proceso dentro de una Clase, el sistema toma el código de la Clase y le añade el nº

de orden del Proceso iniciado dentro de dicha Clase. Con ello se forma la Referencia Base del Proceso,

la cual es inmutable y servirá en el futuro para diferenciar dicho Proceso dentro de su Clase.

Esta Referencia Base es de gran utilidad. Por ejemplo, si en la empresa están en marcha simultáneamen-

te diversos Procesos de la Clase Compras de Material, y llega la factura de un proveedor, ¿Cómo saber

a cuál de los Procesos corresponde dicha factura? AuraPortal provee un mecanismo basado en la Refe-

rencia Base del Proceso que consiste en incorporar automáticamente a cada documento o actividad re-

lacionada con dicho Proceso dicha Referencia Base. Con ello, el sistema dirige cada Mensaje (Factura,

Pedido, Oferta, etc.) al Proceso correcto sin posibilidad de error y sin intervención humana.

Además, el Proceso puede recibir opcionalmente, como ampliación de la Referencia Base, más informa-

ción de ayuda que amplíe dicha Referencia, por ejemplo, el nombre del material comprado, o el del pro-

veedor, para facilitar la identificación visual del Proceso entre otros de su Clase. Esta información adicio-

nal es suministrada mediante dos campos de Formulario, que quedan etiquetados como Temas y,

cuando se suministran, se añaden automáticamente a la Referencia Base, formando así la Referencia

Ampliada.

Ejemplo

Supongamos la Clase de Procesos de nombre: Aprobación de Inversión en Obra.

- La Clave que se suministrará al crear la Clase es PE (Proceso Ejemplo)


- El nº ID que suministra el sistema es el 34

- La Versión es la nº 1

Con todo ello, el código de la Clase de Proceso es:

- Código de la Clase de Proceso = PE34.1

El primer Proceso que se inicie de esta Clase tendrá un número de orden = 1, por tanto, la Referencia

Base de este Proceso será:

- Referencia Base = PE34.1_1

Si además, en el Formulario de Mensaje que se utiliza para iniciar este Proceso, aparecen dos Temas:

‘Obra’ y ‘Objeto de la Inversión’ con los siguientes valores.

- Obra = Aeropuerto Deportivo de Jeresa

- Objeto de la Inversión = Torre de Control

La Referencia Ampliada de este Proceso será:

- Referencia Ampliada = PE34.1_1 Aeropuerto Deportivo de Jeresa_Torre de Control

Este sistema de Referencias es el que se utiliza en todos los Procesos del BPMS de AuraPortal.

Nota.

Los campos que se desea utilizar como Temas se marcan una vez añadidos al formula-

rio. Después pueden cambiarse utilizando la Tarea de Sistema correspondiente. Para

más información, consultar la documentación sobre Formularios Dinámicos y Tareas

de Sistema.

El resto de los campos se definen a continuación.

Nombre. El nombre de la Clase de Proceso.

Descripción. Opcional. Una explicación sobre su función.

Autor del Modelo. Es la persona que ha creado la Clase de Proceso.

Recinto Seguro. Gestiona la seguridad de la Clase de Proceso. Si no se selecciona ninguno, el sistema pone el

recinto _Abierto, sin limitaciones en cuanto a permisos. Para ver los detalles de aplicación del Recinto Seguro

a la Clase de Proceso, consultar la documentación sobre Recintos Seguros.

Realmente basta con introducir el Nombre de la Clase de Proceso y pulsar Guardar, ya que el resto de ele-

mentos o bien no son obligatorios o los introduce el sistema por defecto. Todos estos elementos podrán ser

introducidos o modificados en cualquier momento.

Versión. Muestra la versión de la Clase. El versionado lo realiza el sistema cuando se modifica una Clase de

Proceso en Producción y con algún Proceso en ejecución.

Botón Documentación. Permite crear un Documento Descriptivo del proceso que incluye información sobre

el diagrama y la configuración de los Objetos.


El botón Bases del Diseño permite integrar o asociar documentación que pueda ser relevante para la Clase

de Proceso. En el campo Motivación se puede incluir un texto que aparecerá en el Documento Descriptivo. Al

pulsar el botón Generar Documento Descriptivo se creará el documento en el Formato elegido.

Botón Exportar. Exportar un Diagrama o Clase de Procesos completa permite su implementación, mediante

la utilidad Importar (explicada más adelante en este documento), en otra instalación de AuraPortal. Al pulsar

el botón Exportar se abre la ventana siguiente.

La opción Exportar solo el Diagrama crea un archivo con el formato: BPM_169.2.bpmn, donde 169 es el ID

de la Clase y 2 es la versión de la misma. Este archivo, que se guarda por ejemplo en el disco local, se puede

importar posteriormente desde la opción de Estructura Procesos – Árbol y Clases – Importar.

La opción Exportar Clase de Proceso completa crea un archivo tipo GEN-218.1.IMP, con la referencia de

la Clase, en la biblioteca de SharePoint seleccionada. Este archivo se puede importar posteriormente des-

de la opción de Estructura Procesos – Árbol y Clases – Importar.

Páginas del diagrama para la Documentación. Para indicar las páginas que se desea incluir en el Documento

Descriptivo.

Número Máximo de Recurrencias de Bucle. Este campo permite evitar bucles infinitos en procesos por un

incorrecto diseño del Diagrama. El valor por defecto es 1000. Cuando el motor detecte en una compuerta

que se ha llegado al límite de recurrencias admitidas, detendrá ese proceso, se mostrará un mensaje de aviso

en el Visor de sucesos y se enviará una notificación al responsable del proceso con los datos del proceso

detenido.

Llegado este punto, desde el rastreo de ese proceso se puede pulsar Reanudar. Solo se reanudará si se ha

aumentado el límite, independientemente de que se haya corregido la configuración de la clase de proceso.

Responsable de la Clase. El Empleado o Rol que se responsabiliza de los asuntos relacionados con los Proce-

sos de esta Clase.

Responsable de cada Proceso. Es el empleado que se responsabiliza de los Procesos de esta Clase.


En las tablas siguientes se facilita una relación de las funcionalidades y el tipo de información que recibe o

encarna cada responsable.

RESPONSABLE DE LA CLASE DE PROCESOS

Participantes en Tareas Persona-

les.

EMERGENCIA (Definible). Recibirá las notificaciones gene-

radas al pulsar el botón Emer-

gencia de la Barra de Acciones

de la Tarea.

Cronometría de Tareas Persona-

les.

AVISOS (Definible). Recibirá Alertas y Alarmas cuan-

do se cumpla el tiempo especifi-

cado para la tarea.

Cronometría del Proceso. AVISOS (Definible). Recibirá Alertas y Alarmas cuan-


cado para el proceso.

Bloquear Clase de Proceso. MODOS. Puede cambiar los modos En-

torno Producción y Producción

Restringido a Bloqueado.

TS-NOTIFICADOR a Empleados. DESTINATARIO (Definible). Recibirá la notificación.

TS-CREADOR de Elementos de

Familia Propia.

CAMPO INTERNO Creador (si

no existe el Responsable del

Proceso).

Aparece como creador del ele-

mento.

Notificaciones. Inicio de Procesos con Módulos

Especiales (SO y MC) sin licen-

cia correcta.

Recibe una notificación indicán-

dole el usuario que ha intentado

iniciar un proceso de un Módulo

para el que no dispone de licen-

cia.

Procesos detenidos en TPs con

Ejecutores sin licencia correcta

en Módulos Especiales.

Recibe una notificación indicán-

dole que el proceso está deteni-

do en una Tarea Personal de

alguno de los Módulos para los

que el ejecutor no dispone de

licencia.

Procesos Atascados. Recibe una notificación indicando

el proceso que ha quedado atas-

cado.


RESPONSABLE DEL PROCESO


les.




de la Tarea.


les.



cado para la tarea.

Cronometría del Proceso. AVISOS (Definible). Recibirá Alertas y Alarmas cuan-


cado para el proceso.

TS-NOTIFICADOR a Empleados. DESTINATARIO (Definible). Recibirá la notificación.

Panel del Proceso. Es CAMPO DE SISTEMA en cada

Panel.

El campo _Responsable del Pro-

ceso.

Rastreo. MODIFICACIÓN DE DATOS del

Panel.

A partir de la versión 4.3, puede

modificar datos de los campos

del Panel de un proceso.

Monitorización o Consultas de

Procesos.

Como PERMISO ESPECIAL. Puede ver los procesos de los

que es responsable aunque no

tenga permiso en la Clase de

Proceso por el Recinto Seguro

aplicado.

TS-CREADOR de Elementos de

Familia Propia.

CAMPO INTERNO Creador. Aparece como creador del ele-

mento.

Notificaciones. No encontró Ejecutor. Recibe una notificación si una

Tarea Personal se queda sin eje-

cutor.

Problema ejecutando ingresos

de TS.

Recibe una notificación si se pro-

dujo algún problema en un in-

greso de una TS-INGRESADOR.

Comentarios realizados desde

el Estado de ‘Situación Mis

Mensajes’.

Recibe una notificación con los

comentarios añadidos desde

Situación Mis Mensajes - botón

Estado - Botón Añadir Comenta-

rios.

Procesos detenidos a la fuerza

por exceso de bucles en com-

puertas.

Recibe una notificación infor-

mando de la detención del pro-

ceso por un mal diseño que pro-

voca un exceso de bucles.


3.1.3. Sección Ejecución

Diagrama

En esta opción se puede crear o editar el Diagrama del modelo. Consultar el apartado Diagrama para más

información.

Objetos

En esta opción se dan atributos a los objetos. Consultar el apartado Objetos para más información.

Panel

Cada Clase de Procesos tiene una Clase de Panel, a la que se agregan desde el Diccionario de Términos los

campos que se necesitan para recoger o mostrar la información pertinente al Proceso. Cuando posterior-

mente se crea un Proceso de esa Clase de Procesos, automáticamente se crea un Panel para ese proceso,

con una copia de los campos agregados a la Clase de Panel. Cada proceso de una cierta Clase de Procesos

tiene su propio Panel, independiente de los otros Paneles de los otros Procesos. Pues bien, desde la opción

Panel se pueden ver, añadir o eliminar campos de la Clase de Panel sin necesidad de ir al formulario de

una Tarea Personal o Mensaje.

Al pulsar el ojo de Panel aparece una ventana como la siguiente.

Para acceder al Diccionario, al pulsar sobre el botón Agregar Campos (1) se abre esta ventana para seleccio-

nar los términos. Si los campos que se necesita no se encuentran en el Diccionario, desde allí se dan de alta.

En cualquier caso, al seleccionar en el Diccionario los campos deseados se introducirán en la Clase de Panel.


En cada línea del grid, un Visor muestra la ubicación del campo dentro de la Clase de Proceso; el Objeto, el

Formulario y la División.

El botón Limpiador de Basura (2) elimina todos los campos del Panel de la Clase de Proceso que no se están

utilizando en ningún Formulario, Objeto, Condición, Documento Automático, Párrafo Recursivo, etc...

Al pulsar el botón Ver Condiciones (1) aparece la ventana Campos en Condiciones, que muestra los Campos

de Panel que están siendo utilizados como Condiciones en la Clase de Proceso. Ver la siguiente imagen.


Al pulsar sobre el ojo configurador de uno de los campos (2), aparece el objeto en el que se está utilizando,

en la imagen anterior una compuerta (1.DX ¿Por Donde?). Al pulsar sobre el ojo configurador del objeto (3),

se muestran datos relativos al mismo (4).

Históricos

Los Históricos de un Proceso contienen quién ha participado en cada Tarea Personal, cuándo y los comen-

tarios agregados por los sucesivos participantes. Por cada Clase de Proceso pueden crearse cuantos Históri-

cos se desee, que pueden actuar en todas o solo en algunas tareas. De esta forma, la información contenida

solo estará disponible para los usuarios adecuados.

Crear Históricos es simplemente darles un Nombre. No es necesario crear desde esta opción los Históricos,

ya que AuraPortal permite ir creándolos en el mismo momento de configurar la Tarea.

Una vez creado el Histórico, el grid muestra una columna Registrar y cada registro de un Histórico en el grid

incluye una casilla en esta columna. Ver la siguiente imagen:

Si se marca esta casilla, el Histórico registra el paso de la corriente por todos los formularios del proceso que

lo incluyan, aunque el ejecutor no haga ninguna anotación. Si no se marca, solo se registran las anotaciones.

Simulación

Esta característica solo se aplica a las Clases de Proceso cuyo Diagrama se ha realizado con AuraPortal He-

lium Modeler y permite ejecutar patrones de simulación con múltiples variables (Cronometría, % salidas de

compuertas, ...) para comprobar la viabilidad y rendimiento del diseño. Permite detectar cuellos de botella e

inconsistencias en el diseño del diagrama.

Hay dos tipos de simulación: la Simulación Real y la Simulación Estadística, que es la que se configura en

esta opción. Se basa en la introducción de datos de probabilidad a los sucesos considerados críticos en el

proceso en estudio, por ejemplo, la duración estimada de una o varias tareas dentro del proceso, los recur-

sos asociados a determinadas acciones, sus costes, etc. Con estos datos imaginarios se trata de predecir

resultados del tipo ‘what if’ que permitan identificar los cuellos de botella, rendimientos, costes, cargas de

trabajo y en general los KPI considerados esenciales.


Consultar el manual Helium Modeler para una información completa y detallada de esta etapa del Ciclo de

Vida de los Procesos.

La Prioridad de Ejecución permite establecer la prioridad de ejecución de la Clase de Proceso. El valor prede-

terminado es 0,00, correspondiente a no definir ninguna prioridad. Si se define, cuanto mayor es el número,

mayor es la Prioridad en ejecución.

3.1.4. Sección Cronometría

Se encarga del control y medida de los tiempos en relación con los Procesos de esta Clase. Los Datos a su-

ministrar son:

Calendario. Aquí se selecciona el Calendario que se utiliza para los Procesos de esta Clase. Estos Calendarios

habrán sido creados desde la opción correspondiente de Estructura.

Reloj Proceso. Puede utilizarse el reloj del Servidor o uno Local, con indicación del decalaje respecto al

tiempo universal GMT. El sistema lleva sus cálculos siempre convertidos a GMT para homogeneizar sus sin-

tonías pero los traduce a los horarios seleccionados en cada caso.

Duración Proceso. Aquí se establecen los parámetros que se utilizan para medir las duraciones en relación

con los Procesos de esta Clase.

Unidad. La duración de la ejecución del Proceso puede ser determinada en Días, Horas y Minutos,

bien Naturales o Hábiles (medidos a través del Calendario indicado en la primera pregunta).

Nivel Crítico. Para seleccionar la importancia del control. Posteriormente, la Monitorización podrá

realizar los controles en función del Nivel Crítico.

Prevista / Mínima / Máxima. Para determinar el alcance del control a realizar. La duración Prevista,

Mínima o Máxima puede determinarse:

Introduciendo directamente la duración. Para ello se marca la casilla Manual y se in-

troduce un número en función de la Unidad determinada en la primera pregunta. Por

ejemplo, en la figura, para determinar la duración máxima, al marcar la casilla Manual

se ha abierto un campo en el que se ha introducido ‘5’, indicando que el proceso de-

berá ser realizado en 5 días hábiles.

Mediante un campo de la Clase de Panel. La Clase de Panel agrupa todos los Térmi-

nos (según ha sido explicado antes) que van a ser utilizados en esta Clase de Proceso,


y por tanto contiene todos los campos que se quieren controlar. Con este sistema, la

duración del proceso podrá ser determinada en función de un campo del Panel.

Alerta – Alarma. Esta pregunta solo aparece si se va a controlar duración Máxima. Si se marca Sí,

aparecen dos nuevos campos:

Umbral Alerta. Para determinar cuándo debe dispararse la Alerta.

Una Alarma se dispara cuando se alcanza la duración Máxima establecida.

Una Alerta se dispara cuando se alcanza el Umbral de Alerta establecido.

Avisar a. Para seleccionar los usuarios que deban ser avisados en caso de cumplirse. Estos usuarios

recibirán de forma automática una Tarea de Notificación cuando se disparen la Alerta y la Alarma.

3.2. Diagrama

La construcción del modelo se realiza pulsando sobre el ojo del Diagrama en la Sección EJECUCIÓN de la

página de Datos Generales. Se accede a la herramienta de crear diagramas.

Los diagramas de las Clases de Procesos se realizan con la herramienta AP BPM Modeler, incluida en Aura-

Portal, que sitúa en el lienzo de dibujo las formas que representan los Objetos. Una vez se guarda el diagra-

ma, el sistema codifica y registra automáticamente los objetos, dejándolos listos para recibir sus atributos.

Más adelante en este documento se puede ver más información sobre el diagrama y en el Manual Helium

Modeler la información completa sobre el diseño del diagrama.

Existen dos versiones de AuraPortal Modeler: AuraPortal BPM Visio-Modeler, que requiere de la instala-

ción previa del programa MS Visio de Microsoft (versiones 2003/2007/2010), y AuraPortal Helium Mode-

ler, basado en Java, que no precisa de programas de terceros.

Nota.

AuraPortal Helium Modeler está disponible a partir del Modelo Helium (versión 4.3) de

AuraPortal.

Al pulsar el icono Ojo de Diagrama, se muestra la siguiente ventana,


en la que se elige el Modeler que se desea utilizar.

Para una información detallada sobre la utilización de ambos Modeler, consultar la documentación corres-

pondiente.

No obstante, AuraPortal también permite Importar una Clase de Procesos creada en otra instalación de

AuraPortal, desde la cual fue Exportada. Esta posibilidad está especialmente diseñada para el despliegue de

Clases de Procesos en entornos distintos e independientes del original, por ejemplo para la distribución co-

mercial de un diseño determinado. Por este motivo, una vez realizada la importación hay que ajustarla a las

necesidades y características de la instalación destino.

Se puede Importar una Clase de Proceso desde Estructura – Procesos – Árbol y Clases. Ver la imagen si-

guiente.

Hay dos posibilidades:

Importar sólo el Diagrama. Se pueden importar diagramas de cualquier Clase de Proceso en mo-

do Entorno Desarrollo.

Importar la Clase de Procesos completa. Se importa un archivo .IMP generado mediante la Ex-

portación de una Clase de Procesos. Ver más adelante en este documento.

Dependiendo de los casos, se calcula que se importa entre el 80-90% de la configuración.

La funcionalidad Exportación-Importación de Clases de Proceso tiene las siguientes limitaciones:

Las instalación origen y destino son tratadas como totalmente independientes a todos los niveles

(Diccionario de Términos, Usuarios, …).

La importación solo se puede realizar una vez. No se puede volver a importar la misma Clase de

Procesos una segunda vez después de realizar nuevos cambios en el diseño, porque cada importa-

ción creará una nueva Clase de Procesos.

Después de la importación se requiere ajustar la Clase de Procesos a la nueva instalación, lo que

puede suponer realizar de nuevo un 20-30% del diseño.

Por lo tanto, no es una opción enfocada al pase periódico de nuevos diseños desde Desarrollo a Producción.

El Complemento Tres Entornos Sincronizados proporciona un paso más en el control y la seguridad porque

permite que los tres Entornos estén físicamente separados en tres instalaciones independientes, es decir, que


los cambios de diseño y pruebas de Clases de Proceso se realicen en instalaciones distintas e independientes

de la que tiene los datos reales.

3.2.1. Estándares BPMN, BPEL y XPDL

AuraPortal utiliza el Standard BPMN (Business Process Modeling Notation) para modelizar sus Procesos. Este

Standard, considerado el más moderno y aceptado, utiliza tres categorías de Objetos para dibujar los Mode-

los:

Actividades. Comprende las Tareas, tanto Personales como de Sistema, y los Subprocesos.

Eventos. En AuraPortal, gracias a su concepción flexible y a sus automatismos, los Eventos solo se activan,

bien por un Mensaje (Evento Mensaje) o por la llegada de un día y momento esperado (Evento Tiempo).

Compuertas. Su misión es redirigir las corrientes del flujo del Modelo desde las entradas a las salidas según

ciertas condiciones. Las hay Divergentes y Convergentes.

En el Apéndice correspondiente se muestran todas las formas que se utilizan en los Diagramas representan-

do los Objetos de los Modelos en AuraPortal.

La notación BPMN es un Standard de dibujo de Diagramas de BPM que fue concebido para facilitar y unificar

las representaciones gráficas de objetos y conexiones en los diagramas de Workflow. No se trata de un len-

guaje de Ejecución de Procesos sino solo de Modelización. Sin embargo, puede ser ‘mapeado’ (convertido) a

los estándares BPEL y XPDL que sí están concebidos para la Ejecución de Procesos.

Por tanto, los usuarios de AuraPortal que lo deseen, podrán convertir los modelos desarrollados en BPMN a

los lenguajes de ejecución BPEL o XPDL, siguiendo las instrucciones de ‘mapeo’ que contienen dichos len-

guajes.

Sin embargo, en el BPMS de AuraPortal no se incorporan métodos de conversión a BPEL y XPDL porque la

potencia de estos últimos es muy pobre comparativamente y por tanto sería contradictorio incluir mecánicas

para limitar, en lugar de desarrollar en toda su extensión, las funcionalidades que contiene de origen el pro-

grama.

Alcance de AuraPortal.

AuraPortal contiene una gran cantidad de opciones que permiten resolver práctica-

mente todos los casos que pueden presentarse en una empresa u organización que

quiera funcionar con BPM.

Pero la mayoría de las veces será suficiente utilizar una parte reducida (alrededor del

40%) de dichas posibilidades ya que ello cubre el 90% de los requerimientos prácticos.

Por tanto el usuario no debe sentir que está sacando poco rendimiento a la aplicación

si observa que no está utilizando todos los recursos ofrecidos por AuraPortal. Si los re-

cursos utilizados son suficientes para resolver las necesidades, el trabajo está bien he-

cho. Los recursos no utilizados son un colchón de seguridad para cubrir posibles futu-

ras demandas menos habituales y de concepción más compleja.

La construcción de un Modelo de Procesos en AuraPortal es una labor pensada para ser realizada directa-

mente por el personal de negocio, es decir, el personal ejecutivo de la Empresa que conoce las funcionali-

dades que se necesitan, sin necesidad de preparación en el campo de la programación o técnico.

El Modelo, que como ya se ha dicho, pertenece a la Clase de Procesos, contiene toda la información necesa-

ria para que los Procesos de esa Clase se ejecuten de manera automática controlados por el Motor de cada

Proceso.


Un Modelo lo constituyen sus Objetos, que son:

Clases de Actividad=Tareas + Subprocesos

Clases de Evento

Clases de Compuerta

con todos sus atributos, más las Conexiones entre ellos, que se encargan de dirigir los flujos de corriente,

tanto lineales como paralelos, dentro del Proceso.

Además el Modelo contiene información complementaria interna a la propia Clase de Procesos y canales de

comunicación con la Estructura de AuraPortal, como se ha explicado más arriba, incluyendo las conexiones

con aplicaciones externas a través de Adaptadores.

Una vez realizado satisfactoriamente el Modelo de una Clase de Procesos, el sistema queda listo para iniciar

Procesos de esa Clase sin necesidad de ninguna programación.

El sistema interpreta directamente el Modelo en todos sus detalles, genera las Tareas (tanto de Sistema

como Personales), controla los Eventos y dirige los flujos de corriente de acuerdo con lo que determinan las

Compuertas que figuran en el Modelo.

3.3. Objetos

Desde esta opción se dan los atributos a los distintos objetos que figuran en el Diagrama.

Al pulsar sobre el ojo en el título Objetos se abre una ventana, similar a la siguiente.


Todos los Objetos que aparecen dibujados en el Diagrama, que se reproduce en la parte derecha de esta

ventana, se encuentran en la parte izquierda de la misma agrupados por sus naturalezas bajo sus correspon-

dientes pestañas: Tareas, Eventos y Compuertas. Además, la pestaña Lapsos da entrada a la definición de los

Lapsos entre Puntos de Control, y desde Documentos Base se crean las plantillas que servirán para la crea-

ción automática de documentos en los procesos.

La pestaña que está activa al entrar a esta ventana es la de Tareas que muestra la lista de las que existen en

el Diagrama.

3.3.1. Tareas

Las Tareas a las que deben darse atributos pueden verse en la ventana, dispuestas en un grid. Por defecto

aparecen las Tareas de TODAS las Páginas y TODOS los subprocesos, pero se puede filtrar por Página, Sub-

proceso, Código o Nombre para limitar la salida. El icono del campo Filtro permite seleccionar los objetos a

visualizar. En la Lista, al pulsar sobre una determinada tarea se abre una ventana para darle los atributos de

configuración.

Esta ventana será diferente si se trata de una Tarea Personal (tarea que es ejecutada por un usuario) o bien

de una Tarea de Sistema (ejecutada por el propio sistema sin intervención humana).

Consultar la documentación sobre Tareas de Sistema para una información completa de sus posibilidades

de configuración.

A continuación se explica la configuración de las Tareas Personales.

Al pulsar sobre una determinada Tarea se abre una ventana en la que el Género y el Nombre que identifica el

objeto ya han sido creados por el sistema. También puede introducirse una Descripción con el Editor de

Texto Rico. Esta será la descripción de la Tarea que el sistema introduzca en el Documento Descriptivo

del Proceso para su creación automática.


Además, puede seleccionarse un color distintivo de esta tarea cuando aparezca en los Plannings. Consultar la

documentación sobre el Planning para una información detallada.

Para dar atributos a una Tarea Personal, en primer lugar se determina si la tarea debe ser ejecutada por un

Empleado, un Usuario Externo (que se comunica a través de Portales Externos) o por un Usuario Invitado

(que se comunica a través de la Web Pública y/o mediante Email u otro mecanismo similar).

Al marcar la casilla correspondiente se abre una ventana que será diferente si se trata de:

1. Tarea Personal ejecutada por un Empleado

2. Tarea Personal ejecutada por un Usuario Externo

3. Tarea Personal ejecutada por un Usuario Invitado


3.3.1.1. Tarea Personal ejecutada por un Empleado

Si la Tarea va a ser ejecutada por un empleado, para dar los atributos la ventana dispone de las siguientes

secciones: EJECUCIÓN (Participantes, Instrucciones y Zona de Trabajo) y CRONOMETRÍA.

EJECUCIÓN

En primer lugar se determina el comportamiento de la tarea en el caso en que la corriente pase más de una

vez por ella, la Clonación:


Si se marca Clonable, al pasar de nuevo la corriente por la tarea, el sistema creará una nueva tarea a todos

los efectos, y así constará en los Históricos. Si la tarea debe ser ejecutada por más de un usuario, debe de-

terminarse su comportamiento:

Tarea con Ejecución Mancomunada = Sí. La tarea no reanudará el hilo de corriente hasta que no se

hayan terminado todas las tareas de todos los ejecutores.

Tarea con Ejecución Mancomunada = No. Cada tarea terminada generará un nuevo hilo de corriente

hasta el siguiente objeto.

Si se marca No Clonable, se mantendrá siempre la misma tarea. Este caso presenta las siguientes particulari-

dades:

No acepta Cronometría. Solo acepta Fecha Llegada y Fecha Iniciada.

Si la tarea está abierta no hace nada.

Si la tarea ha sido terminada, al llegar de nuevo la corriente 'despierta' la tarea manteniendo la fe-

cha de Llegada y de Iniciada que tenía.

Si en un nuevo paso de corriente se ha cambiado el ejecutor, se comporta como Clonable, es decir,

se creará una nueva TP, con otro ID. Si en un nuevo paso de corriente, la TP volviera al primer eje-

cutor, se creará igualmente otra tarea, puesto que el ejecutor ha cambiado respecto al actual.

Participantes


Aquí se determinan los usuarios que de alguna forma van a intervenir en la tarea. Son estos:

1. Responsable. Si no se indica, el sistema tomará como Responsable el mismo que se indique como

Ejecutor.

2. Ejecutor. Empleado que debe ejecutar la tarea.

3. Emergencia. Cuando el Ejecutor se encuentra ante una situación que no sabe cómo resolver, tiene

la opción de pulsar sobre el botón Emergencia, situado en la barra de acciones de la tarea y apare-

ce una ventana con el Editor para añadir un texto. Una vez pulse Enviar en la barra de acciones, el

participante configurado en este campo recibirá una Tarea de Notificación. Si no se indica el titular

de la Emergencia el sistema toma por defecto al Responsable de la Clase de Procesos.

También pueden determinarse unos Suplentes del Ejecutor y de Emergencia.

Nota.

El Suplente del Ejecutor es el que ha de ejecutar la Tarea si el titular se encuentra Au-

sente. La ausencia ha de figurar en su ficha de empleado. El funcionamiento del Su-

plente se establece como sigue:

- Cuando un usuario empleado está Ausente, aquellas tareas de proceso (TP) que

no haya empezado (es decir que tengan el Rango = 0), estarán visibles desde la

lista de tareas de su Suplente.

- Para que el Suplente pueda gestionarlas, tendrá que pulsar el botón Reclamar

dentro de cada tarea, pasando a ser el Titular de la misma a todos los efectos.

- Mientras el Suplente no las reclame, ambos usuarios (Titular y Suplente) verán

esas tareas en sus respectivas listas. Solo desaparecerán de la lista de tareas del

Titular cuando el Suplente las Reclame.

- Aunque un empleado esté en estado Ausente, si inicia sesión en AuraPortal pue-

de gestionar sus tareas normalmente, excepto aquellas que hayan sido Reclama-

das por su Suplente.

La forma de determinar estos participantes es básicamente la misma. Aquí, como ejemplo, se explica la del

Ejecutor de la Tarea. Al pulsar sobre el ojo de cada uno de ellos, aparece la siguiente ventana:


EMPLEADO

En primer lugar permite elegir entre:

Actor - Directo. La Tarea se envía al Empleado seleccionado en las opciones expuestas a continua-

ción.

Actor - Supervisor. La Tarea se envía al Supervisor del Empleado seleccionado. Cuando se selecciona

Supervisor de debe elegir el Grado de supervisión. 1= Supervisor inmediato, 2=Supervisor de 2º

Grado (Supervisor del Supervisor), 3=Supervisor de 3er Grado, etc.

A continuación se selecciona el ejecutor entre:

Responsable Clase de Tarea. Solo si se ha determinado un responsable.

Autor Mensaje Inicio. Si se desea que el ejecutor de esta tarea sea el empleado iniciador.

Empleado. Si el ejecutor de esta tarea debe ser un determinado empleado, al marcar la casilla aparece a

la derecha el campo y al pulsar sobre el ojo, se abre una ventana para seleccionar el empleado.

Rol. Si la ejecución de la tarea debe asignarse a un determinado Rol, al marcar la casilla aparece a la de-

recha la posibilidad de determinar si el Rol es Singular o Genérico, tal como indica la figura siguiente.

- Singular. Si marca esta casilla, al pulsar sobre el ojo se abre una ventana que permite

seleccionar un Rol Singular previamente creado o crear uno nuevo. Esta ventana es si-

milar a la que aparece en el caso del Rol Genérico.

- Genérico. (1) Si marca esta casilla y se pulsa sobre el ojo, se abre la siguiente ventana,

en la que se selecciona el Rol Genérico.


Además de esta ventana para la selección del Rol, aparece un nuevo campo: Lugar de Ac-

tuación (LA) Base. Al pulsar (2) sobre el ojo se abre una ventana en la que aparecen los

campos del Panel de la Clase de Procesos. El Lugar de Actuación Base es el campo de fa-

milia del Panel que utilizará el motor para, a partir de él, determinar el Rol Genérico y, por

tanto, su Asignado.

Nota.

El tratamiento de los Roles Singulares es muy sencillo pero el de los Roles Genéricos es

más complejo. Para obtener una comprensión completa puede consultarse la informa-

ción sobre Roles, Perfiles y Grupos de Empleados.

De Panel. El ejecutor de una determinada tarea puede ser alguien que haya sido designado en alguna ta-

rea anterior mediante la selección de un empleado desde el Formulario de la Tarea.

Nota.

Por ejemplo, para diseñar una Clase de Procesos de Reclamaciones de Clientes en la

que el responsable de atención al cliente determina quién debe resolver el asunto, pue-

de actuarse de la siguiente manera:

1. En la tarea en la que el responsable debe determinar quién debe resolver el asunto,

se pondrá en el Formulario un campo de Familia de Empleados para que en la Eje-

cución de cada proceso de esta clase seleccione el (o los) que debe resolverlo.

2. En la (o las) tarea de Resolución, se marcará como Ejecutor la casilla De Panel y se

seleccionará el campo de Familia de Empleados del punto anterior.

Como esta selección se habrá podido realizar mediante un campo de tipo General o de Grupo de Campos,

al marcar la casilla aparece a la derecha la posibilidad de determinar de qué tipo se trata.

Si se trata de un campo de tipo General, al marcar esta casilla y pulsar sobre el ojo, el Panel mues-

tra los campos compatibles, que son los de Empleados, Prefijos o de Familia o campos de tipo Tex-

to. Si en un campo de Familia-Empleados se enlazan varios empleados, todos los empleados enla-

zados recibirán una tarea, tal como si fuera un Grupo de Empleados de tipo Paralelo. Si se elige

un Prefijo, solamente el empleado elegido recibirá la tarea.

Nota.

Una de las posibilidades que permite el sistema es utilizar como Ejecutores de Tareas

Personales el Sufijo Responsable de las Fichas de Elementos de Familias. De esta ma-

nera, cuando en un Proceso se haya seleccionado un elemento de Cuentas, Proyectos,

Ítems o Áreas, una Tarea posterior se puede dirigir automáticamente a su responsable.

Si se trata de un campo de tipo Grupo de Campos, al marcar esta casilla y pulsar sobre el ojo, se

abre una ventana para seleccionar, en primer lugar el contenedor que se va a utilizar (puede ser el


propio Grupo de Campos) y luego la columna que se utilizará como Destinatario (ejecutor). Al mis-

mo tiempo se puede configurar si el destinatario recibe Una Tarea por cada Línea del Grupo de

Campos o una Tarea única para todas las líneas del Ejecutor.

De Otra Tarea. Por último, el ejecutor de una determinada tarea puede ser el ejecutor de una tarea ante-

rior. En este caso, al marcar esta casilla y pulsar sobre el ojo, se abre una ventana para seleccionar esta

Tarea.

Además, puede determinarse si se trata del Ejecutor Titular de la Clase (el marcado en esta ventana al dise-

ñar el modelo) o el usuario que realmente ha ejecutado esa tarea anterior (Ejecutor Real de la Tarea), ya que

por diferentes circunstancias puede no ser el mismo (por ejemplo, puede ser el suplente).

La opción Asignación con Balanceo de Carga permite aplicar esta funcionalidad a las Tareas Personales de

Proceso a Empleados en ejecución. Solo se aplica a Grupos de Empleados de comportamiento Exclusivo

No Delegable o Delegable Discrecional. Cuando esté configurada con Sí, el Motor BPM asignará la tarea al

usuario del grupo que tenga menos tareas de esa clase pendientes de terminar en su workflow. En este es-

cenario, el usuario no tendrá que reclamar la tarea para operar con ella.

EMAIL

Enviar Tarea por Email. Esta opción permite recibir la tarea a través del correo electrónico. Si pulsa Sí, el eje-

cutor determinado en el anterior cuadro recibirá de forma automática un Email cuando le llegue una tarea a

su workflow, y desde el propio Email, podrá acceder a la tarea y ejecutarla. Al marcar Sí, se habilita el ojo

configurador, que abre la siguiente ventana para configurar el email.


A continuación se explican los diferentes campos:

Dirección de Email. Para determinar la dirección a la que AuraPortal envíe el correo. Puede ser:

Email Ejecutor. Si se marca esta casilla el sistema enviará el correo a la dirección que conste en la Fi-

cha del Empleado determinado como ejecutor de la tarea. Es lo común.

De Panel. Si la dirección de Email ha sido indicada en el Formulario de alguna tarea anterior. Al pul-

sar sobre el ojo que aparece, el Panel muestra los campos disponibles.

Manual. Si se desea indicar aquí una dirección de correo fija, que será única para todos los Procesos

de esta Clase.

Remitente. Para evitar el uso de SPAM, los actuales servidores de correo impiden que un usuario de correo

envíe correos en nombre de otro. Para evitar que esta protección afecte el envío de correos desde AuraPor-

tal, el remitente de todas aquellas opciones de envío de Emails desde Procesos y Tareas Libres, ahora es el

que esté configurado en de Estructura – GENERAL – Administradores - Correo – Tareas - Email Remiten-

te. Aquí aparece ya para su consulta.

Asunto en Email. En este campo se puede escribir el 'Asunto' que figurará en el Email que recibirá el usuario.

Referencia. Aquí se indica si debe mostrarse:

La Referencia Base. Compuesta por la Clave, el ID de la, Número de Versión y el Número de orden

del Proceso iniciado dentro de dicha Clase.

La Referencia Ampliada. Compuesta por la Referencia Base más dos Campos del Panel de los consi-

derados como Temas. Esta consideración habrá sido indicada desde la ventana Configurar Campo al

marcar sí en el campo Tema.

No mostrar ninguna de las dos.


CUERPO DE TEXTO. Mediante el Editor (ver el apartado Fuente de Datos en Tareas de Usuarios Invitados

(Emails)) se confecciona el texto de entrada que recibe el ejecutor.

Nota.

Una de las ventajas de esta opción es recibir un aviso de la recepción de una tarea a

través del email en los dispositivos móviles como PDA.

Pulsando el botón Editar se añade el texto del Email. Si se dispone del Módulo MultiIdioma, pulsando el ojo

configurador de MultiIdioma se podrá establecer un mensaje específico para cada idioma de los disponibles

en AuraPortal.

COMPLEMENTOS. Con 3 opciones.

No. El Email no incluye ningún documento.

Integrados. Permite integrar uno o varios documentos que serán incluidos como texto del Email.

De Panel. Permite seleccionar un campo de Panel de tipo Biblioteca de Documentos. Así, los docu-

mentos incluidos se seleccionan de forma dinámica, en ejecución.

Nota.

La función Enviar Tarea por Email queda bloqueada si se marcó la opción correspon-

diente en Estructura – Correo. Ver la imagen siguiente.

Enviar Aviso por SMS.

Esta opción permite dos alternativas:

Genérico (TS-INVOCADOR de Servicios Web). Al pulsar el ojo configurador, se puede configurar una

Tarea de Sistema de este tipo, que permite ejecutar un Servicio Web, por ejemplo, de Envío de SMS.

Infoe.es (www.infoe.es). Al pulsar el ojo configurador, se puede configurar el envío de un SMS de

aviso mediante el proveedor Infoe. Se puede encontrar más información en la documentación so-

bre las Tareas de Sistema.

Nota.

La función Enviar Aviso por SMS queda bloqueada si se marcó la opción correspon-

diente en Estructura – Correo. Ver la imagen siguiente.


Pulsando Guardar y Salir, queda registrado el ejecutor de esta Tarea.

Instrucciones


Las Instrucciones que verá en su pantalla el Ejecutor de la Tarea pueden ser todo lo completas que se desee,

pudiendo contener, no solo texto enriquecido, sino imágenes, fondos, tablas, vídeos con sonido, etc., y todo

ello se realiza mediante el potente Editor de AuraPortal que se describe en la documentación disponible

sobre Formularios Dinámicos.

Pueden figurar en estos formatos:

Texto. Si se marca Texto, al pulsar en el botón Editar aparece la ventana del editor AuraPortal, en la

que introducimos el texto mostrado para las Instrucciones: una explicación textual con los pasos y

acciones que ha de realizar. Lo que se escribe aquí queda integrado con la Clase de Tarea y se man-

tendrá siempre igual, aunque puede modificarse desde aquí mismo en el futuro.

Regla. Si las instrucciones no son fijas sino que dependen de ciertas circunstancias, se pueden espe-

cificar aquí las Reglas de Negocio que contienen dichas instrucciones. Estas Reglas, que serán de

naturaleza Textual, contienen las explicaciones de los pasos a seguir. En cualquier momento se

puede cambiar el contenido de las Reglas (con independencia de los Procesos) y ello afectará a to-

das las Tareas cuyas Instrucciones se basen en dicha Regla.

Panel. También puede darse el caso de que las instrucciones (o parte de las instrucciones) de reali-

zación de la tarea sean determinadas por el ejecutor de alguna tarea anterior del mismo proceso.

Estas instrucciones deberán haber sido introducidas en un campo de Texto, que es el que debe se-

leccionarse aquí.

Además, es posible que las Instrucciones se indiquen mediante combinaciones de Texto Fijo + Regla + Panel.

Nota.

Además de estas instrucciones generales (para toda la tarea), al diseñarse la tarea

pueden crearse instrucciones específicas para una determinada acción o conjunto de

acciones que deban realizarse, para una determinada fase de realización de la tarea o

acciones que deban realizarse solo si se dan ciertas circunstancias.

Estas instrucciones se crean normalmente mediante Complementos y pueden diseñar-

se para que se activen de forma automática en el momento en que el ejecutor de la ta-

rea lo necesite.


Zona de Trabajo

A continuación se determina el entorno que encontrará el ejecutor al abrir la tarea.

Si se marca Formato Predefinido (1), al pulsar el Ojo se muestra la lista de los formatos existentes, las llama-

das VET (Ventanas de Ejecución de Tarea) y también pueden crearse nuevos formatos.

Son posibles innumerables formatos de Ventanas de Ejecución a gusto del usuario, combinando las distribu-

ciones, los tamaños, las posiciones relativas y los colores da cada cajetín que contiene las Instrucciones, los

Formularios y los Históricos.


Cada registro del modelo incluye un ojo Visor que permite visualizar en modo lectura la configuración del

mismo. Pulsando sobre el modelo elegido, se selecciona. Para crear un nuevo modelo pulsar sobre el botón

Crear de la barra de acciones. En el Manual del Administrador Delegado se pueden consultar todos los

detalles sobre la creación de Formatos.

Si se marca Indicar Tamaño en Formulario (2), en lugar de elegir una VET, se utiliza solo el formulario. En la

ventana de diseño del mismo aparecerá el campo Tamaño, ver la imagen siguiente, que permite configurar el

Tamaño y la Posición que tendrá la ventana.


Formularios (3)

Si la Tarea ha de contener uno o más Formularios a ser cumplimentados por el Ejecutor, éstos se crean aquí.

Para ello, al marcar la casilla y pulsar sobre el ojo de Formularios aparece una ventana desde la que se puede

optar por crear un formulario Original o bien uno Similar a otro del que ya se disponga. En este caso, al se-

leccionar un formulario el sistema crea una copia de éste, para ser modificado.

Nota.

Para diseñar formularios debe utilizarse una resolución de pantalla mínima de

1280x1024.

El diseño de los Formularios se explica con detalle en la documentación disponible sobre Formularios Di-

námicos.

Históricos (4)

Los Históricos de un Proceso contienen quién ha participado en cada tarea, cuándo y los comentarios

agregados por los sucesivos participantes. Por cada Clase de Procesos pueden crearse cuantos Históricos se

desee para que actúen solo en algunas tareas, de esta forma, la información contenida solo estará disponible

para los usuarios adecuados. Así pues, para cada Tarea se determina desde este campo el acceso a unos u

otros históricos.

Para determinar los históricos que deben actuar en esta tarea, al marcar la casilla Sí y pulsar sobre el ojo, se

abre una ventana desde la que, pulsando sobre el botón Agregar Histórico, se abre una nueva ventana como

la siguiente:

Desde esta ventana se marcan los históricos que deben actuar en esta tarea, y que habrán sido creados en

anteriores clases de tarea de esta misma Clase de Procesos. Después de marcarlos y pulsar Aceptar Selección

quedan en la primera ventana para su posterior consulta.

Desde cualquier Clase Tarea Personal que vaya a ser ejecutada por un Empleado o por un Usuario Externo

(no así por los Usuarios Invitados) se crean los Históricos desde esta ventana pulsando el botón Crear Histó-

rico. También pueden crearse desde el título Históricos del panel EJECUCIÓN, en la ventana de configura-

ción general de la Clase de Procesos.

Crear un Histórico es simplemente darle un Nombre. Una vez creado, queda disponible para ser selecciona-

do desde las clases de tareas de esta misma Clase de Procesos.


CRONOMETRÍA

Además de la cronometría general de la Clase de Procesos, se puede determinar una cronometría para cada

Clase de Tarea Personal. La operativa es similar a la explicada anteriormente para la Clase de Procesos.

1. Calendario. Se puede elegir el mismo Calendario que se defina de forma general para la Clase de

Procesos o uno particular para esta Clase de Tarea.

2. Duración. Al pulsar el botón Sí, y luego sobre el ojo, aparece la ventana para indicar los parámetros

de la Duración: Prevista, Mínima y Máxima para las Tareas de esta Clase.


Actualizar Previsión Original Planning. Si se selecciona Sí, cuando llega la corriente a la tarea, se rellenan las

fechas del planning como sigue:

PREVISIÓN ORIGINAL INICIO. Se rellena con la fecha-hora de llegada de la tarea al workflow del

ejecutor.

PREVISIÓN ORIGINAL FIN. Se rellena con la fecha máxima de la configuración del Control de Dura-

ción de la Tarea.

3.3.1.2. Tarea Personal ejecutada por un Usuario Externo

El Usuario Externo es aquel que se comunica a través de Portales Externos. La operativa es básicamente

similar a la explicada en el punto anterior para las Tareas ejecutadas por un Empleado. A excepción de los

Participantes.


En este caso no existe la posibilidad de asignar Suplentes y permite seleccionar el ejecutor en función de

Perfiles de Cuenta y Perfiles de Roles. Con los Perfiles de Cuenta se deciden las cuentas destinatarias de la

tarea (se pueden aplicar Condiciones) y con los Perfiles de Roles se filtran los Roles de cada cuenta que reci-

birán la misma. Para más información sobre la configuración de Perfiles de Cuentas y Roles consultar la do-

cumentación sobre Perfiles, Roles y Grupos de Empleados.

3.3.1.3. Tarea Personal ejecutada por un Usuario Invitado

El Usuario Invitado es aquel que se comunica a través de la Web Pública y/o mediante Email u otro meca-

nismo similar. Contiene los siguientes campos diferenciadores:

Remitente. Para evitar el uso de SPAM, los actuales servidores de correo impiden que un usuario de correo

envíe correos en nombre de otro. Para evitar que esta protección afecte el envío de correos desde AuraPor-

tal, el remitente de todas aquellas opciones de envío de Emails desde Procesos y Tareas Libres, ahora es el

que esté configurado en Estructura – GENERAL – Administradores - Correo – Tareas - Email Remitente.

Ejecutor. Tiene las mismas opciones que el Usuario Externo: Autor Mensaje Inicio, De Panel y Perfiles de

Cuentas-Perfiles de Roles.

Formulario. El diseño de los Formularios se explica en la documentación sobre Formularios Dinámicos.

Aviso por Email. Los Usuarios Invitados pueden acceder a sus tareas mediante dos procedimientos:

A través del Portal de Invitados. Más información en la documentación sobre el Portal de Invitados.

Mediante Aviso por Email. En este caso AuraPortal crea y envía de forma automática un Email al Usua-

rio Invitado. Este Email contendrá un link y, al introducir el Login y la Contraseña accederá a sus ta-

reas.

Si se marca la opción Aviso por Email, aparecerán en la ventana los siguientes campos.

Asunto en Email. En este campo se puede escribir el ‘Asunto’ que figurará en el Email que recibirá el usuario

invitado. Se puede elegir un campo De Panel o un texto fijo, Manual, al que se le puede aplicar MultiIdioma.

Referencia. Aquí se indica si debe mostrarse:


La Referencia Base. Compuesta por la Clave, el ID de la Clase de Procesos, Número de Versión y el

Número de orden del Proceso iniciado dentro de dicha Clase.

La Referencia Ampliada. Compuesta por la Referencia Base más dos Campos del Panel de los conside-

rados como Temas. Esta consideración habrá sido indicada desde la ventana Configurar Campo al

marcar sí en el campo Tema.

No mostrar ninguna de las dos.

Cuerpo de Texto. Pulsando el botón Editar se accede al Editor AuraPortal que permite confeccionar el texto

del Email, introduciendo incluso los campos del Panel que se desee. La operativa con el Editor se explica en

la documentación sobre Formularios Dinámicos. Se puede aplicar MultiIdioma.

3.3.1.4. Funciones de los Responsables de la Tarea

Los empleados que asumen las funcionalidades de la Clase de Tarea reciben distintas comunicaciones que

son importantes para el buen funcionamiento y desarrollo del proceso. En la siguiente tabla se muestran

dichas funcionalidades.

RESPONSABLE DE LA CLASE DE TAREA


les.




de la Tarea.

SUPLENTE (Tanto como Ejecu-

tor de la TP como de la Emer-

gencia). [Definible].

Recibirá la tarea si el ejecutor está

ausente o la notificación de

emergencia si no está el titular.


les.



cado para la tarea.

TS-NOTIFICADOR a Empleados y

Usuarios Externos.

REMITENTE (como “Ejecutor

Real de la Tarea” si este fue el

Suplente = Responsable de la

Clase de Tarea). (Definible).

Aparecerá como remitente de la

notificación.

3.3.2. Eventos


Al pulsar sobre la pestaña de Eventos (1), las Clases de Evento a las que deben darse atributos pueden verse

en la ventana. Por defecto aparecen todas las clases. Hay que pulsar el icono del Filtro, y se abre una ventana

para marcar las que se desea y pulsar Proceder.

Al pulsar sobre un determinado evento (2) se abre una ventana, que será diferente si se trata de un Evento

de Inicio por Mensaje, un Evento de Mensaje Intermedio o un Evento de Inicio por Tiempo. Los eventos

de Inicio por Tiempo inician procesos cuando llega un determinado momento indicado como fecha comple-

ta o bien, año, mes, semana, día, hora o minuto. Los eventos de Inicio por Mensaje inician procesos cuando

ocurre un evento que se puede identificar con una notificación o mensaje. Este tipo de evento se activa

cuando:

1. Un formulario es ejecutado.

2. Llega determinada información vía Servicios Web.

3. Llega una orden desde el ‘Comercio Online’ de AuraPortal.

3.3.2.1. Eventos de Inicio por Mensaje

Al pulsar sobre el Mensaje de Inicio se abre la ventana con las siguientes secciones:

IDENTIDAD

COMPORTAMIENTO

En la sección IDENTIDAD aparece ya el Género de Evento de que se trate y el Nombre que ha sido dado al

evento al dibujar el Diagrama. Puede completarse con una Descripción de Texto Rico, que se utilizará en la

creación del Documento Descriptivo del Proceso.


En la sección COMPORTAMIENTO, el panel ACTIVADO POR incluye los siguientes campos:

Formulario. Si está desmarcado no se podrá activar el evento con formulario, únicamente podrá ser invoca-

do desde Tareas de Sistema de Tipo Desviador o desde programas externos.

Nota.

La combinación: Servicios Web = marcado + Formulario = no marcado implica que el

Servicio Web no estará disponible para introducción manual.

Al pulsar sobre el ojo de Formulario aparece la ventana de Crear Formularios para diseñar el formulario del

Mensaje de Inicio (MI).

El diseño de los Formularios se explica en la documentación sobre Formularios Dinámicos. El campo MultiI-

dioma que aparece en la imagen superior se refiere al nombre del Formulario.

Servicios Web. Por defecto está desmarcado. Marcarlo y pulsar Guardar para tener acceso a la ventana de

configuración del Servicio Web en el Mensaje de Inicio. Al pulsar el ojo aparece la siguiente ventana:

Configurar las opciones como sigue:

Nombre Servicio Web. Será el nombre con el que se publicará el Servicio Web. Con este nombre se

creará una página .asmx (entrada al Servicio Web) en la carpeta \WS del Sitio Web donde esté instalado

AuraPortal. No es necesario que este nombre coincida con el del Formulario del Evento de Mensaje al

que pertenece.

Descripción. La Descripción no es obligatoria.

URL. Este campo aparece bajo la descripción cuando se crea el Servicio Web y se rellena automática-

mente con su ubicación. La trayectoria siempre es, por ejemplo,

http://obtenida.portal.local/WS/NombreServicioWeb.asmx,

donde,

obtenida.portal.local depende de cada instalación y


NombreServicioWeb.asmx depende del nombre dado en Nombre Servicio Web, en este ejemplo

_Joker_MI.asmx.

Si la Impersonación para Servicios Web está configurada (en Estructura – Parámetros – Impersonación), se

crea el servicio web en la carpeta indicada, y se puede consultar desde el navegador.

En esta ventana de entrada al Servicio Web sólo se verá un método, con el mismo nombre que se le ha dado

al Servicio Web con un ‘guión_de_subrayado’ delante, en este caso _Joker_MI.

Al pulsar sobre el método se mostrará un único parámetro genérico, llamado Datos:

Si esta ventana se ha abierto desde el propio servidor de AuraPortal, el parámetro se mostrará como en la

imagen, es decir, permitiendo introducción manual para hacer pruebas. Sin embargo, si esta ventana se abre

desde otro ordenador que no sea el servidor, se mostrarán los datos de SOAP pero no estará el parámetro


Datos disponible para introducción manual. En su lugar aparecerá el mensaje: El formulario de prueba sólo

está disponible para solicitudes del equipo local.

Nota.

Una vez un Evento de Mensaje es publicado como Servicio Web, además de poder ser

utilizado desde Tareas de Sistema DESVIADOR, también puede ser invocado desde

programas externos.

Es muy fácil realizar un programa con .NET, Visual Basic, etc., que invoque estos Servi-

cios Web. (AuraPortal proporciona ejemplos de programación con el código fuente in-

cluido).

Comercio Online. Por defecto está desmarcado. Si está marcado se podrá elegir desde la opción Traspaso a

Proceso del Carrito de Compra. Toda la información acerca del Comercio Online de AuraPortal puede encon-

trarse en la documentación sobre Gestión de Contenidos y Comercio Online.

URL de acceso. Este campo aparece después de crear el Mensaje. Pulsando el ojo muestra la URL del Mensa-

je de Inicio. Así, si se desea que un Mensaje de Inicio pueda ser ejecutado desde cualquier sitio, basta venir

aquí para copiar la URL, por ejemplo, para que Usuarios Invitados o Anónimos puedan poner en marcha

Procesos desde la Web pública (o desde cualquier otro sitio).

Datos Predeterminados. Al pulsar sobre el ojo configurador, aparece una ventana vacía con una barra de

acciones como la siguiente:

Los campos que se añaden en esta ventana, con o sin valores, aparecen de forma predeterminada en todos

los Mensajes de Inicio de esta clase de procesos.

Pulsar el botón Agregar Campos para añadir campos (del panel del proceso) a la ventana. En la siguiente

imagen puede verse el campo de panel fami-cuentas.


En cada campo, el valor se añade según su identidad. En el caso de un campo de familia, como el de la ima-

gen, pulsar el ojo configurador para añadir las cuentas predeterminadas.

Añadir sucesivamente todos los campos deseados.

Pulsar después el botón Configurar Campos para eliminar (1) si procede, campos previamente añadidos o

establecer el orden (2) en el que aparecen los campos en la ventana

Pulsar el botón Integrar Doc desde Biblioteca para incluir en campos de tipo Biblioteca en Diccionario docu-

mentos integrados en bibliotecas de SharePoint. Ver la siguiente imagen.

Al pulsar el botón Agregar Ingreso desde Biblioteca, se abre la ventana inferior, donde se configurarán los

documentos a incluir como datos predeterminados.


Poner un Nombre al ingreso que se está configurando (1). Pulsar sobre el ojo buscador de la Biblioteca Ori-

gen (2), marcar la opción adecuada en el campo Ingresar (3), según se desee incluir Todos los documentos

de la biblioteca o solo una Selección de los mismos. Pulsar Guardar (4).

Se activará el botón Agregar Campo Biblioteca Destino. Al pulsarlo aparece la siguiente ventana:

En el Campo Bi. Destino (1) se puede Indicar el campo Biblioteca del panel en el que se guardarán los do-

cumentos, la única opción habilitada.

El Usuario Ingresador (2) es el que se utiliza para impersonar el ingreso. Debe tener los permisos necesarios

para acceder a la biblioteca de SharePoint configurada. Pulsar el botón Probar (4) para comprobar si el usua-

rio elegido es adecuado.

Al pulsar el botón Guardar de la barra de acciones, aparece el campo Condiciones (3), que permite configu-

rar las condiciones en las que va a realizar el ingreso.

3.3.2.2. Eventos de Inicio por Tiempo

Un Evento de Tiempo, ya sea de Inicio de proceso o Intermedio, deja pasar la corriente del proceso cuando

se cumple el tiempo (fecha y hora o duración) establecido al definir su cronometría. La IDENTIDAD es la

misma que la explicada para el MI. En este caso hay que determinar la CRONOMETRÍA del Evento.


CRONOMETRÍA

Calendario. Se puede elegir entre el mismo Calendario que se defina de forma general para la Clase de Pro-

cesos o uno particular para esta Clase de Evento.

Reloj Evento. Se puede elegir entre el Reloj del Proceso (implica que se usará el Reloj utilizado en general

para el Proceso), o directamente el Reloj del servidor o un Reloj Local.

Opciones

Control por Fecha. Elegir esta opción cuando se desea que el sistema deje pasar la corriente en un momento

determinado, que debe ser definido aquí.

Puede definirse de dos formas:


De Panel. Al marcar la casilla aparecen dos nuevas opciones:

- Dinámica (lee cada minuto la fecha en el Panel. Es más lento). Con esta opción, el Motor

BPM resuelve el valor del campo de panel cada vez que revisa los eventos, cada minuto.

- Única (lee una sola vez la fecha del Panel. Es más rápido). El Motor BPM da por válido el

valor que había en el panel cuando la corriente llegó al Evento.

Si no hay valor en el campo de panel, se comporta como Dinámica, es decir, el Motor BPM lo com-

prueba cada minuto el Panel hasta que encuentra una fecha y puede guardarla.

Al pulsar sobre el icono se abre la ventana de la Clase de Panel con los campos de tipo Fecha, para

que se seleccione el que debe marcar el momento en que deje pasar la corriente.

Modalidad. Al marcar la casilla permite seleccionar la modalidad de Fecha. Una vez seleccionada, al

pulsar sobre el ojo se abre una ventana en la que están disponibles los campos para marcar el mo-

mento en el que deje pasar la corriente.

Si se marca Sí (1) en la casilla de Control por Horas, pulsando sobre el ojo, se abre una ventana para

indicar el intervalo horario en el que debe actuar el evento.


Control por Duración. Cuando se desea que el sistema deje pasar la corriente tras un periodo de tiempo

determinado, este debe ser definido mediante los campos de la siguiente ventana.

Unidad. En primer lugar debe definirse la unidad de duración a utilizar, seleccionando entre Días, Horas

Minutos y Segundos, Naturales o Hábiles (calculados a través del Calendario seleccionado en la prime-

ra pregunta).

Contar a Partir de. A continuación, se determina el comienzo de la duración, que puede ser el momento

de la Llegada de la Corriente al propio Evento o bien Otra Posición Temporal. En este último caso, al

seleccionar entre las propuestas el sistema permite seleccionar el elemento deseado.

Control Horario. Con dos opciones:

Días de calendario (Se gana velocidad de proceso). Es la opción por defecto. El vencimiento del

Evento es al comienzo del día, es decir, no se espera las 24 horas, por lo que este tipo de eventos se

evalúa una vez al día.

Periodos de 24 horas. Los eventos se evalúan cada hora, lo que consume más recursos.

Esta selección sólo está disponible cuando las Unidades del Evento de Tiempo son Días, tanto Na-

turales como Hábiles.

Valor. Por último se determina la duración, que puede ser determinada como un campo Numérico del Panel

o bien introduciéndolo directamente de forma Manual.

Al marcar la casilla De Panel aparecen dos nuevas opciones:

o Dinámica (lee cada minuto la fecha en el Panel. Es más lento). Con esta opción, el Motor BPM

resuelve el valor del campo de panel cada vez que revisa los eventos, cada minuto.

o Única (lee una sola vez la fecha del Panel. Es más rápido). El Motor BPM da por válido el valor

que había en el panel cuando la corriente llegó al Evento.


Si no hay valor en el campo de panel, se comporta como Dinámica, es decir, el Motor BPM lo

comprueba cada minuto el Panel hasta que encuentra una fecha y puede guardarla.

3.3.2.3. Eventos de Mensaje Intermedio

Como el anterior, si se trata de un Evento de Mensaje Intermedio, la IDENTIDAD es la misma que la explica-

da para el IM. A continuación se detallan las secciones diferentes.

COMPORTAMIENTO

El panel ACTIVADO POR incluye los siguientes campos:

Patrón. En un EM se puede utilizar un Formulario (propio) o un Patrón, que es un formulario que se puede

utilizar en muchos Procesos.

Nota.

Un Patrón se da de alta desde [Estructura - Procesos – Entorno – Patrones]. Allí se

crea un patrón y se le introducen términos de diccionario igual que en cualquier formu-

lario, pero no se realiza el diseño.

Dentro del patrón hay un campo obligado que al dar de alta el Patrón ya se pone por

defecto y es '_Lista de Referencia de Procesos'. Se utiliza en estos Eventos de Mensaje

Intermedios para elegir el Proceso que tiene la corriente detenida en dicho EM.

Además, este campo, también se pueden ubicar en el formulario de una Tarea Personal

para seleccionar cualquier proceso que esté en ejecución, no sólo los que estén deteni-

dos en un EM como en el caso anterior. Esta posibilidad es útil para tener seleccionado

un proceso desde otro, por ejemplo para que en otro punto del diagrama se pueda rea-

lizar un desvío.

Si se marca Patrón = Sí, pulsando sobre el ojo que aparece se abre una ventana desde la que se puede selec-

cionar uno de los patrones creados desde la pestaña Patrones (Estructura – Procesos – Entorno).

Si marca Patrón = No aparece la casilla del campo Formulario.

Formulario. Si está desmarcado no se podrá activar el evento con formulario, únicamente podrá ser invocado

desde Tareas de Sistema de Tipo Desviador o desde programas externos.

Nota.

La combinación: Servicios Web = marcado + Formulario = no marcado implica que el

Servicio Web no estará disponible para introducción manual.


Pulsando sobre el ojo se abre una ventana desde la que se puede optar por crear un formulario Original o

bien Similar a otro que ya se disponga. En este caso, que será el más común, al seleccionar un formulario el

sistema crea una copia de éste, para ser modificado.

El diseño de los Formularios se explica en la documentación sobre Formularios Dinámicos.

Condiciones. Además, para poder filtrar los procesos que se ven desde un Evento de Mensaje Intermedio

(EM) se dispone de la opción Condiciones (cuya operativa es similar a la que se explica en la sección Com-

puertas).

Pulsando el ojo muestra la ventana para añadir Condiciones. Pulsando en el botón Crear Condiciones, en la

sección DATO REAL aparece la opción Condicionar con - Filtro por Ejecutor.

Como Fuente, solo está disponible la opción De Panel, donde se puede seleccionar un campo de Panel de

cualquier tipo donde pueda haber un Ejecutor (Prefijos y campos de familia de Empleados, Autor Mensaje

Inicio, Sufijo Responsable, etc...).

De esta manera, si en la configuración de un EM se ha seleccionado, por ejemplo, el Autor del Mensaje de

Inicio como Filtro por Ejecutor, cuando un usuario vaya a crear el EM, solo le aparecerán en el campo Lista de

Referencias los procesos en los que él fue el Autor del Mensaje de Inicio. Otro ejemplo sería que un usuario

sólo pueda ver los EM en donde haya sido seleccionado en un campo determinado de tipo Prefijo o de Fa-

milia.

Este filtro por Ejecutor está disponible para los Empleados y para los Usuarios Externos.

Servicios Web. Por defecto está desmarcado. Esta funcionalidad se ha explicado anteriormente en el aparta-

do del Mensaje de Inicio.

URL de acceso. Esta opción se muestra después de haberse creado el Servicio Web. Muestra la URL para

acceder al EM, de forma que se pueden crear mensajes desde cualquier parte.

Nota.

Se pueden pasar parámetros de filtrado a través de la URL al buscador de Eventos In-

termedios, concretamente a la página llamada BPM_ProcesosReferencia_Buscador.aspx

Los parámetros que acepta son los siguientes:

•Theme1


•Theme2

•ProcessReference

•StartDateFrom (AAAA-MM-DD HH:MM)

•StartDateTo (AAAA-MM-DD HH:MM)

En los dos últimos, la hora y minutos (HH:MM) no son necesarios.

Ejemplo de URL completa con parámetros:

http://intranet.auraportal.net/Home/BPM_ProcesosReferencia_Buscador.aspx?idg=23

&id=107&idform=2202&pag=107&Datos=[[[Theme2:::Empresa]]][[[Theme1:::Contact

o]]][[[StartDateFrom:::2015-06-27 13:56]]][[[StartDataTo:::2015-06-27]]]

MultiIdioma. Si se dispone del módulo, se puede configurar el idioma del EM.

TAMAÑO Y POSICIÓN VENTANA. Ver la imagen siguiente:

En estas secciones se puede configurar la ventana que muestra el EM, su tamaño y posición.

EVENTO. Ver la imagen siguiente:

Sin Reactivación. Cuando llega la corriente, queda activada la entrada de datos hasta que se crea el primer

Mensaje, y no vuelve a estar disponible hasta que lleguen nuevas corrientes del workflow.

Reactivación Automática. Una vez llega la corriente, se pueden crear ilimitados Mensajes para introducir

datos en el proceso. De esta manera, cuando se desea introducir continuamente nuevos datos en el proceso,

por ejemplo recibiendo sucesivos desvíos de otros procesos a través de TS-DESVIADOR, no es necesario

realizar un bucle que devuelva la corriente al EM. Así, el EM puede recibir entradas simultáneamente y se

mejora el rendimiento.

Con la opción Reactivación Automática, una vez llega la corriente al EM, éste queda activado de forma per-

manente hasta que suceda una de las siguientes opciones:


Posteriormente al EM hay una Compuerta CX que se termina por la finalización de otro objeto distinto

al EM.

El EM está dentro de un SubProceso que llega a su Fin.

Se termina el Proceso.

Nota.

Cuando el EM está configurado con Reactivación Automática, en el buscador de Even-

tos Intermedios cada usuario solo ve los EM que han sido bloqueados por él mismo y no

los de otros usuarios.

3.3.3. Compuertas

Al pulsar sobre la pestaña de Compuertas, las Compuertas a las que deben darse atributos pueden verse en

la ventana.

El marcador indica que la compuerta está configurada.

Las compuertas aparecen en el grid. Se puede filtrar por Código, Nombre, Página y Subproceso. Por defecto

se muestran las compuertas de Todas las Páginas y Todos los Subprocesos.

Solo las compuertas Divergentes DX y DO requieren configuración. Pulsar sobre una Compuerta determina-

da para configurar sus Salidas. La ventana es similar a esta.


IDENTIDAD. El Género y el Nombre que identifica la compuerta ya han sido creados por el sistema, y puede

introducirse una Descripción.

COMPORTAMIENTO. Al entrar, la ventana ya presenta las diferentes Salidas de la Compuerta con sus datos,

según se hayan determinado en el diagrama de la Clase de Procesos.

Nota.

Las Compuertas DX, como se aprecia en el ejemplo de la figura, contienen una Sali-

da Complementaria, que siempre permite el paso si las demás salidas no cumplen

condiciones. Esto garantiza que la corriente no quede bloqueada en la Compuerta.

El marcador indica que la compuerta está configurada.

Por cada Salida se puede determinar una Descripción (opcional) y las Condiciones que deben cumplirse

para que la corriente circule por las diferentes Salidas de la compuerta (se explica más abajo).

Nota.

No es obligatorio que las salidas de las Compuertas tengan Condiciones. Las Compuer-

tas sin Condiciones siempre permiten el paso de la corriente.

Además, si hay más de una salida, hay que indicar el Orden de Evaluación en el que el Motor debe evaluar

las condiciones de cada Salida, pues cuando una Salida cumple las condiciones ya no se evalúan las demás,

por lo que en los casos en los que las preferencias de las Salidas difieren, el orden de evaluación de mayor a

menor rango es muy importante.

Condiciones

Al pulsar sobre el icono se abre una ventana como la siguiente.


Mediante el botón (1) Crear Condiciones se crean las condiciones, que aparecen para su consulta en la lista

(2) inferior. Si se ha creado más de una condición se debe seleccionar (3) el Operador Lógico que debe apli-

carse: si se han de cumplir todas (AND), alguna (OR) o solo una (XOR).

En el ejemplo de la figura, el sistema enviará la corriente por la salida Sí cuando el Importe Total de la com-

pra sea Mayor o Igual de 300 €.

Pulsando el botón Crear Condiciones, se abre una nueva ventana desde la que se determina el Campo del

Panel sobre el que se determina la condición de la compuerta. El resto de la ventana, aunque siguiendo

siempre los mismos criterios y operativas, será diferente en función del campo seleccionado. En general,

sobre el Campo del Panel seleccionado se determina un Patrón de Comparación que puede estar condicio-

nado a unos criterios de Comparación.

Nota.

Los detalles sobre la configuración de Condiciones y Conjuntos se pueden consultar en

la documentación sobre Formularios Dinámicos.

Así, en el ejemplo de la imagen posterior, cuando la corriente del proceso llegue a la compuerta ‘Requiere 2ª

Aprobación?, si el campo ‘Total Importe’ de la compra es Mayor o Igual de 300 €, el sistema enviará la co-

rriente por la salida Sí.


CRONOMETRÍA. Para determinar la Cronometría se debe determinar:

Calendario. Se puede elegir entre el mismo Calendario que se defina de forma general para la Clase

de Procesos o uno particular para esta Compuerta.

Reloj Compuerta. Se puede elegir entre el Reloj del Proceso (implica que se usará el mismo Reloj que

el utilizado en general para el Proceso), o directamente el Reloj del servidor o un Reloj Local.

Al pulsar Guardar y Salir queda determinado el comportamiento de la compuerta.

3.4. Lapsos

Los Lapsos son intervalos de tiempo que se definen como la distancia temporal entre dos Puntos de Control

(que controlan el paso de la corriente por un determinado punto). El diseñador del Modelo puede intercalar

en el Diagrama tantos Puntos de Control como quiera y definir los Lapsos que desee para analizar el com-

portamiento temporal de porciones específicas de los Procesos. Los Lapsos son de gran utilidad en la Moni-

torización.

Para acceder a Lapsos hay que pulsar (1) sobre su pestaña. Desde esta ventana se configuran los Puntos de

Control y se crean los Lapsos.


El panel superior (2) contiene los siguientes datos:

Nombre. El que se le quiera dar al Lapso.

Descripción de Itinerario. Del tipo Texto Rico que incluye el icono 'palmera' para poder elegir Campos del

Panel al personalizar la descripción que se mostrará como Explicación del Lapso al pulsar el botón Estado.

Este botón está disponible para hacer el seguimiento de los procesos iniciados por:

Empleados (Botón Situación Mis Mensajes en la Barra de Acciones de Mis Tareas de Proceso),


Externos (Botón Situación Mis Mensajes en la Barra de Acciones de Mis Tareas),

e Invitados. (En el ejemplo de la imagen inferior, en el Botón Mis Peticiones, confeccionado con la Gestión

de Contenidos de AuraPortal).

MultiIdioma. Para aplicar MultiIdioma al Lapso.

De esta forma se pueden ver los Puntos de Control por donde han pasado los procesos iniciados por el

usuario y la Descripción de Itinerario de los Lapsos.

Al entrar por primera vez en la ventana aparecen (3) en el grid solo los Puntos de Control que se hayan in-

tercalado en el Diagrama.

1. Configurar los Puntos de Control

Al pulsar (3) sobre un Punto se abre la siguiente ventana.


El panel IDENTIDAD contiene un campo Nombre de tipo Texto una línea y el campo Descripción, de tipo

Texto Rico, que incluye el icono 'palmera' para poder elegir campos del panel.

En el panel sección ESTADO DEL PROCESO hay 3 campos:

Estado. Para indicar el nombre del botón Estado del Portal de Invitados.

Descripción. Texto Rico, que incluye el icono 'palmera' para poder elegir campos del panel.

MultiIdioma. Para indicar el nombre del botón en los diferentes idiomas con los que se esté trabajando.


Para determinar el COMPORTAMIENTO de un Punto de Control se debe establecer:

1. Nivel Crítico. Para seleccionar la importancia del control. Posteriormente, la Monitorización podrá

realizar los controles en función del Nivel Crítico.

2. Fecha Prevista / Mínima / Máxima. Para determinar el alcance del control a realizar. En el caso de los

Puntos de Control la duración Prevista, Mínima o Máxima solo se determina mediante un campo de

la Clase de Panel.

3. Alertas y Alarmas. Solo se activa si se va a controlar duración Máxima.

Unidad. La duración de la ejecución del Proceso puede ser determinada en Días, Horas, Minu-

tos y Segundos, bien Naturales o Hábiles (medidos a través del Calendario indicado en la pri-

mera pregunta).

Alerta – Alarma. Si se marca Sí se activan dos nuevos campos:

Umbral Alerta. Para determinar cuándo debe dispararse la Alerta.

- Una Alarma se dispara cuando se alcanza la duración Máxima establecida.

- Una Alerta se dispara cuando se alcanza el Umbral de Alerta establecido.

Para determinar la CRONOMETRÍA de un Punto de Control se debe determinar:


Procesos o uno particular para este Punto de Control.

2. Reloj. Se puede elegir entre el Reloj del Proceso (implica que se usará el mismo Reloj que el utiliza-

do en general para el Proceso), o directamente el Reloj del servidor o un Reloj Local.

2. Crear Lapsos

Todo Lapso tiene un Punto de Control Inicial y un Punto de Control Final. Para crear un Lapso pulsar sobre la

opción Crear Lapso,

en la Barra de Acciones y aparece una ventana en la que se puede introducir un Nombre y una Descripción. A

continuación se pulsa el botón Guardar, que abre una nueva ventana como la siguiente.


Ahora se debe:

Seleccionar el Punto de Control Inicial (que puede ser el Inicio del Proceso o un Punto de Control) y

un Punto de Control Final (que puede ser también el Fin del Proceso).

Determinar la Cronometría, que es similar a la ya explicada para las Tareas y otros objetos.

Los Lapsos así creados quedan en el grid de la ventana principal. Sus códigos se generan automáticamente

combinando los códigos (sin los nombres) de los Puntos de Control Inicial y Final que lo delimitan.

3.5. Documentos Base

La funcionalidad de Documentos Base de AuraPortal permite preparar documentos que servirán de plantilla

para la creación de Documentos Automáticos junto con los datos variables de cada Proceso.

Para el diseño de los Documentos Base se pueden utilizar dos editores diferentes: MS Word: Versiones

2003/2007/2010 y HTML, que al estar incluido en AuraPortal, no necesita ningún software adicional. Si se

desean documentos complejos, normalmente es recomendable utilizar MS Word.

Una vez el Documento Base está diseñado, se puede ejecutar de dos maneras:


Desde un Botón en un Formulario de una Tarea o Mensaje de Inicio o Intermedio. Los documen-

tos Automáticos se crearán cuando el usuario pulse sobre el botón. Si tiene permisos, podrá hacer

modificaciones antes de crearlos.

Desde una Tarea de Sistema. Los documentos Automáticos se crearán automáticamente cuando la

corriente del workflow pase por ella, sin intervención del usuario. Para ello hay que utilizar la Tarea

de Sistema Ingresador del tipo Crea Documento Base y configurarla.

En ambos casos el documento creado queda introducido de forma automática en los destinos que se hayan

determinado en su configuración. Estos destinos pueden ser:

Integrado en un Campo de Biblioteca.

Ingresado en una Biblioteca de AuraPortal y Asociado a un Campo de Biblioteca.

Los dos anteriores a la vez, para lo cual el documento es duplicado.

Para crear un Documento Base se pulsa sobre la pestaña Documentos Base, que muestra cinco opciones, tal

como puede verse en la imagen siguiente:

Los Documentos Base se crean desde la primera de las opciones, pueden o no incluir las otras opciones y

están disponibles para ser utilizados desde cualquier formulario dentro de la clase de procesos.

Una explicación exhaustiva sobre todas las posibilidades de creación y operativa con los Documentos Base

se encuentra en la documentación sobre Gestión Documental.

4. EJEMPLO DE MODELIZACIÓN

En este Ejemplo se presenta una Clase de Procesos llamada Autorización de Compra para una empresa

constructora. Se trata de un ejemplo simple con pocos objetos, para facilitar el seguimiento. Sin embargo las

mecánicas utilizadas son de aplicación general en otras Clases de Proceso cualquiera que sea su compleji-

dad.

Para realizar la MODELIZACIÓN, lo primero es Crear la Clase de Procesos que se pretende Modelizar. Para

ello hay que entrar en la Familia Procesos de la Estructura y elegir Procesos: Árbol y Clases.

La ventana de Árbol y Clases tiene el siguiente aspecto.


Al pulsar (1) Crear aparece la ventana básica desde la que se modeliza la Clase de Procesos.

Después de introducir los datos de IDENTIDAD (explicados en otra parte de este documento) se procede a la

modelización desde la sección de EJECUCIÓN. En este ejemplo solo se utilizan el Diagrama y los Objetos ya

que los campos del Panel y los Históricos se configuran desde las Tareas Personales.


4.1. Diagrama

Al pulsar sobre el ojo de Diagrama se entra en la herramienta para diagramar.

Existen dos versiones de AuraPortal Modeler: AuraPortal BPM Modeler-Visio, que requiere de la instala-

ción previa del programa MS Visio de Microsoft ( versiones 2003/2007/2010), y AuraPortal BPM Modeler-

Java, basado en Java, que no precisa de programas de terceros.

Para más información sobre la utilización de ambos Modelers, consultar la documentación correspondiente.

Nota.

Para comprobar la sencillez con la que se crean los Diagramas, remitimos al lector al

sitio web: www.auraportal.com. En el sidebar encontrará un Vídeo de descarga in-

mediata que lo muestra.

A continuación se muestra el Diagrama del Proceso Ejemplo una vez ha sido confeccionado.

http://intranet.auraportal.com/


Es importante recordar que, cuando se guarde el diagrama, el sistema crea los Objetos con el mismo nom-

bre que se suministre en el dibujo, al tiempo que les otorga un código que, precedido por el nombre de la

página en que se encuentran dentro del Diagrama, servirá como medio para identificarlos en todas las ope-

raciones en las que intervengan.

Dado el carácter pedagógico de este ejemplo, se ha concebido un Modelo que resulte sencillo de entender y

que al mismo tiempo contenga una variedad de ingredientes que demuestran la extraordinaria potencia de

AuraPortal. En el Modelo de este Ejemplo se pueden ver Tareas Personales, Mensajes, Roles, Subprocesos,

Eventos de Tiempo, Tareas de Sistema, etc.

Explicación

Esta Clase de Procesos ha sido concebida como un ejemplo básico para gestionar las compras indirectas,

que no son controlados por el ERP, tales como inmovilizado, material de oficina, equipos informáticos, piezas

de recambio, etc.

El proceso se inicia cuando un determinado empleado cumplimenta un Formulario de solicitud de algún

bien. Al rellenar este Formulario se genera un Mensaje que es detectado por el Motor de AuraPortal, que

inmediatamente inicia un Proceso de la Clase Autorización de Compra y le otorga un número de orden de

Proceso dentro de esa Clase.

Una vez iniciado el Proceso aparece en la cola de tareas pendientes de su Supervisor la Tarea Personal de

nombre Aprueba el Supervisor. Cuando éste la abre, examina los datos que provienen del Mensaje de Inicio

tal como indican las instrucciones de la Tarea. Cuando ha tomado su decisión de aprobar o no la compra,

rellena el Formulario en donde anota dicha decisión. Luego termina la Tarea y la corriente del Proceso llega

al objeto: Compuerta 1ª Aprobación?

1. Si la inversión no ha sido Aprobada, la Compuerta dirige la corriente a la Tarea de Sistema Informa

de No Aprobación y el Proceso termina. Esta Tarea de Sistema envía al destinatario (Solicitante) un

mensaje interno notificándole que su solicitud de inversión no ha sido aprobada.

2. Si por el contrario la Inversión ha sido aprobada por el Supervisor, la corriente llega a la Compuerta

Requiere 2ª Aprobación?. Esta Compuerta Divergente decide si la compra que ya ha sido aprobada por

el Supervisor requiere una segunda aprobación por el Jefe de División. Para tomar la decisión, la Com-

puerta debe tener en cuenta el Importe de la compra.

Si no es necesaria la segunda aprobación la corriente pasa por un Punto de Control P1.K que se

encarga de tomar nota del momento en que la corriente ha pasado por allí de cara a extraer datos

para la Monitorización.

A continuación la corriente llega a la Tarea Personal Notifica que ha sido Aprobado y prosigue su

flujo de Compra y/o Entrega de material y actualización del stock.

Si se requiere la segunda aprobación la corriente llega al Evento de Tiempo Solo Lunes y Jueves

de 10:00 a 12:00, que detiene el Proceso hasta que sea Lunes o Jueves y la hora esté entre las

10:00 y las 12:00. Cuando esto se cumple, el Evento deja pasar la corriente.

La razón por la que se ha insertado este Evento de Tiempo es que el Jefe de División solo dedica,

para revisar peticiones de aprobaciones, los Lunes y los Jueves de 10:00 a 12:00. Por tanto no es

deseable que aparezcan en su workflow, con anterioridad a estos períodos, las Tareas de revisión

mencionadas, ya que permanecerían en cola sin ser abiertas por su ejecutor hasta la llegada del

momento estipulado y esta permanencia de las Tareas en su cola sería anómala pues la Monitoriza-

ción del Proceso podría dar a entender que el Jefe de División no está atendiendo diligentemente su

workflow, lo cual no sería cierto. Además, desvirtuaría las estadísticas referentes a cargas de trabajo

y asignación óptima de recursos.


Cuando se cumple el tiempo especificado en el Evento de Tiempo la corriente pasa a la Tarea Per-

sonal Aprueba el Jefe de DIV. En esta Tarea el Jefe de División examina el expediente de la solici-

tud de inversión ya aprobada por el Supervisor y decide aprobarlo o no. La corriente del proceso si-

gue su curso en función de dicha decisión, tal como se ha descrito más arriba.

En conjunto, el Diagrama expresa lo que pretende el Modelo de esta Clase de Procesos, es decir:

Permitir la realización de una solicitud de aprobación para las compras indirectas de la empresa.

Llevar a 1ª Aprobación dicha solicitud.

Decidir si se requiere una 2ª Aprobación en función de las Reglas de Negocio internas.

Ajustar los tiempos parciales de ejecución del Proceso mediante paradas que eviten la generación

de colas engañosas de Tareas.

Que el sistema envíe automáticamente a los destinatarios los Mensajes que indican si la solicitud ha

sido aprobada o no.

Ejecutar Subprocesos con las Tareas de compra, si no hay existencias del bien solicitado.

Establecer, mediante Puntos de Control, los Lapsos que han de ser medidos para detectar cuellos

de botella y optimizar el reparto de cargas de trabajo.

Controlar a los participantes mediante sus Roles.

4.2. Objetos

Los Objetos del Modelo son Clases (Clases de Tarea, Clases de Subproceso, Clases de Evento y Clases de

Compuerta) y sus nombres son los que aparecen en el Diagrama. Así por ejemplo, el Objeto de código

P1.TP.38 que tiene por nombre Aprueba el Jefe de DIV es una Clase de Tarea y en todos los Procesos de la

misma Clase de Procesos dicho Objeto es el mismo.

Por razones de simplicidad de léxico, cuando se habla de los Objetos del Diagrama o del Modelo, que como

se sabe corresponde siempre a la Clase de Procesos, a veces se utilizan directamente, cuando no pueda dar

lugar a confusión, los nombres: Tareas, Subprocesos, Eventos y Compuertas, entendiendo que se refiere a las

respectivas Clases.

Para dar los atributos a los distintos objetos que figuran en el Diagrama, al pulsar sobre el ojo en el título

Objetos en la ventana de la Clase de Procesos aparece la siguiente ventana.


Como se aprecia en la imagen, todos los Objetos que aparecen dibujados en el Diagrama que se reproduce

en la parte derecha de esta ventana se encuentran en la parte izquierda de la misma agrupados por sus ca-

tegorías bajo sus correspondientes pestañas: Tareas, Eventos y Compuertas.

Además, la pestaña Lapsos da entrada a la definición de los Lapsos entre Puntos de Control, y desde Docu-

mentos Base se crean las plantillas que servirán para la creación automática de documentos en los procesos.

Para dar atributos a los Objetos, se sigue normalmente el mismo orden seguido por el flujo del Diagrama,

para así facilitar la construcción progresiva de la Clase de Panel con los campos según sean necesarios para

los objetos. Es el siguiente:

4.2.1. Paso 1. P1. IM Inicio

En primer lugar se crea el Mensaje de Inicio que se encuentra entre los Eventos (1).


Al pulsar sobre el Mensaje de Inicio (2) se abre la ventana como la siguiente.

El Género y el Nombre que identifica el evento ya han sido creados por el sistema, y puede introducirse una

Descripción. Al pulsar sobre el ojo de Formulario aparece la ventana de Crear Formulario.


En este tutorial solo se indican los pasos a seguir para realizar este ejemplo, dando por hecho que se cono-

ce la operativa. Si no así, la explicación de los conceptos y de la operativa de Creación de Formularios se

encuentra en la documentación sobre Formularios Dinámicos.

Nota.

Para diseñar formularios debe utilizarse una resolución de pantalla mínima de

1280x1024.

Como muestra la imagen, esta ventana contiene una Barra de Acciones y cuatro Paneles:

Barra de Acciones (1). En la parte superior. Contiene los botones que ejecutan las acciones generales de la

ventana.

IDENTIDAD (2). En la parte superior derecha. Determina la identidad del formulario.

DIVISIONES (3). En la parte central derecha. Contiene los Botones de Creación de las Divisiones Activas y el

Grid en el que aparecen todas las divisiones activas del Formulario con sus respectivas columnas para su

gestión.

LISTA DE CAMPOS SELECCIONADOS – DIVISIÓN (4). En la parte inferior. Contiene una Barra de Acciones y

el Grid de los Campos de una División (justo la que se ha seleccionado desde el Grid de Divisiones para tra-

bajar con ella). Desde aquí se determinan y configuran los Campos y Botones que contendrá cada una de

las Divisiones Activas que contendrá el Formulario.

Tapiz (o Lienzo) de la Página (5). En la parte central izquierda. Es el fondo sobre el que se diseña el Formu-

lario.

Para crear un formulario, en líneas generales, se siguen los siguientes pasos:

1. En primer lugar se introduce la Identidad.

2. A continuación, se van creando las Divisiones Activas del formulario.

3. Por cada una de estas Divisiones se agregan y configuran sus Campos y Botones desde la Lista de

Campos de la División, así como las Divisiones Pasivas y Formularios Externos.


4. Y por último, desde el Tapiz se diseña el aspecto del formulario con los campos y botones.

4.2.1.1. Barra de Acciones

En este Ejemplo solo se utiliza la Página 1, que ya viene por defecto, y no se usarán el resto de botones.

4.2.1.2. Identidad

En este Ejemplo, los datos de identidad son los que muestra la siguiente ventana:

Los Formularios se alojan en Capítulos de su Diccionario. Una vez seleccionado el Capítulo, introducir el

Nombre: Solicitud Inicial (IM).

Luego, en el campo Usuario, seleccionar Empleado como ejecutor de este IM, en detrimento de Usuario

Externo, Usuario Invitado o Anónimo. Esta diferenciación es necesaria pues los campos que pueden aparecer

en el Formulario son distintos en función de la naturaleza del usuario, y también es necesaria para realizar la

asignación de Tareas en los Procesos, cuando éstas dependen del Autor del Mensaje de Inicio.

A continuación, pulsando el ojo de Más información, se marcan los campos y se determinan las dimensiones

y posición en la pantalla de la Ventana General que se utilizará para ejecutar este Formulario. Para seguir

este ejemplo se introducen los valores que aparecen en la siguiente ventana:

Nota.

La protección de acceso a la ejecución de este Formulario se consigue mediante su in-

clusión en un Recinto Seguro (Ver la Monografía sobre Recintos Seguros para obte-

ner los detalles de esta operación).


4.2.1.3. Divisiones

Para crear Divisiones se pulsa sobre la opción Crear División Original en la barra de acciones del Grid de

Divisiones. Aparece una ventana con tres secciones: DATOS GENERALES, DISEÑO y TEXTO EN IDIOMA BASE.

En primer lugar se introducen los DATOS GENERALES:

Introducir el Nombre (Formulario Principal), Descripción (opcional) y pulsar el botón Guardar. Aparecen 3

campos más.


Presencia. Para marcar si la presencia de la División en la Página ha de ser Permanente (que siempre apare-

cerá al aparecer la página, como en este caso) o Condicional (su aparición se producirá solo bajo determina-

das condiciones). Se marca Permanente.

Excluyente. En ejecución, cuando una división marcada como Excluyente se muestra, ya sea al abrir el formu-

lario, porque es disparada o porque se cumplen sus condiciones, el resto de divisiones se ocultan y cuando

la Excluyente se oculta, se vuelven a mostrar las divisiones que ésta ocultó (siempre que sigan

cumpliendo condiciones). Se marca No.

Acceso. Esta opción hace que la división se muestre en modo Lectura o no, según se haya diseñado. Se mar-

ca Según Diseño. La división se muestra según se haya diseñado.

Además se diseña la estética de la división mediante el panel DISEÑO. En este Ejemplo se marca Personali-

zar, introduciendo los valores de la imagen.


El tercer panel, TEXTO EN IDIOMA BASE, permite escribir un texto que aparecerá en la cabecera.

Una vez escrito el texto en Idioma Base, se puede configurar el MultiIdioma, pulsando sobre el icono de la

columna correspondiente del Grid de Divisiones, ver la imagen inferior.

En este Ejemplo no se usa esta característica.

De igual modo, se crearán dos Divisiones más:

Breve Descripción. Para que contenga la descripción del elemento solicitado.

Datos de lo Solicitado. Para que contenga los datos del elemento solicitado.

En ambos casos se crearán con Presencia Permanente y los mismos atributos de Diseño pero Cabecera NO

Visible y Cuerpo de Imagen.

Con las Divisiones que se crean se genera una Lista de Campos, tal como aparece en la imagen.

Esta Lista permanece inactiva hasta que es activada. Al pulsar sobre el Nombre de la División que se quiere

gestionar se activará la lista, apareciendo el Nombre de la División.


4.2.1.4. Lista de Campos

Al pulsar sobre el Nombre de cada una de las Divisiones creadas se activa la Barra de Acciones de la Lista,

en la parte inferior de la ventana. La Barra contiene los siguientes botones:

Los botones Agregar Campos, Botones, Formulario Externo y Complementos hacen referencia a elementos

que se pueden incluir en el formulario.

Nota.

La explicación de los conceptos y de la operativa de estos elementos se encuentra en la

documentación sobre Formularios Dinámicos. Aquí solo se explica qué hay que hacer

para crear la Clase de Procesos, dando por hecho que el cómo ya se conoce. Por tanto si

no se conoce, debe tenerse a mano esta monografía.

A continuación se explican las tres Divisiones: Formulario Principal, Breve Descripción y Datos de lo Solicita-

do.

6.2.1.4.1. División Formulario Principal

Siguiendo el ejemplo, al pulsar sobre el Nombre de la División Formulario Principal, se activa la Barra de

Acciones de la Lista. Para configurar esta División se procede a:

Crear Complementos

La forma más sencilla de añadir imágenes a un formulario es mediante Complementos. En este ejemplo

vamos a añadir una cabecera con un logo y un título, como se ve en la imagen inferior.

Para ello pulsar sobre la división en la que se quiere añadir la imagen y luego sobre el botón Crear Comple-

mento Original de la barra de acciones de la Lista de Campos Seleccionados.

Aparece una ventana como la siguiente.


Después de registrar Nombre Interno y Título Mostrado (1) para identificar el complemento, marcar el radio-

button Imagen (2) en el panel CUERPO. En este ejemplo seleccionamos la pestaña Imágenes Privadas (3)

porque la imagen que queremos incluir no está en la Galería de Imágenes de AuraPortal. Si conocemos el

nombre de la imagen, en el ejemplo, cabecera, (4) lo escribimos en el campo Nombre Imagen, si no, pulsa-

mos el botón Proceder (5) para que se muestren todas las imágenes. Cuando la imagen deseada esté mar-

cada (7), pulsar Aceptar Selección (8).

Nota.

Si la imagen no existe en la galería de Imágenes Privadas, pulsar el botón Agre-

gar Nueva (6) para incorporarla.

En este ejemplo no configuramos nada más en el complemento. Pulsar Guardar y Salir. La imagen aparecerá

como se ve en la siguiente figura:

y después de expandirla al tamaño deseado, el aspecto es el de la siguiente imagen, ya situada como cabe-

cera del formulario.

Nota.

Para más información sobre la configuración de complementos, consultar la do-

cumentación sobre Formularios Dinámicos.

Agregar Campos

Al pulsar sobre el botón Agregar Campos se abre la ventana Panel (figura posterior).


Al pulsar Proceder (1), aparecen los campos disponibles (2). Antes de pulsar Proceder puede filtrarse (3)

la lista por Tipo de Término, Tipo de Dato y Nombre.

En principio, esta ventana solo contiene campos (2) de Sistema (que ya vienen por defecto). En la medida

que se necesiten otros, se irán añadiendo desde el Diccionario de Términos. Para acceder al diccionario

se pulsa el botón (4) Agregar Campos.

Nota.

Cada Proceso tiene su Panel, cuya importancia es esencial, pues en él se recibe, alber-

ga y suministra toda la información generada en el Proceso.

Cada vez que se inicia un Proceso el Motor del mismo crea un Panel específico para ese

Proceso que se confecciona a partir de una plantilla única para todos los Procesos de su

misma Clase.

Esta plantilla recibe el nombre de Clase de Panel y contiene los nombres de los Cam-

pos que han de figurar en cada Panel de Proceso de su Clase. A su vez, estos nombres

se obtienen del Diccionario de Términos de la Estructura de AuraPortal.

Aparece la siguiente ventana.

Para seleccionar, como el número de términos que contiene el Diccionario puede ser muy elevado, se

dispone del filtro (1). Al pulsar Proceder aparecen en la lista (2) los términos seleccionados.

Para crear términos se pulsan (3) los botones de la barra, según el tipo de término que a crear.


La explicación de los conceptos y de la operativa de Creación de los diferentes tipos de Términos se en-

cuentra en el Manual del Administrador Delegado.

En cualquier caso, al seleccionar en el Diccionario los campos deseados y pulsar (4) Aceptar Selección se

introducirán en el Panel.

En este ejemplo los campos que necesita el Mensaje de Inicio serán los siguientes:

1. Empleados. Es un Prefijo de la Familia de Empleados. Ya en la Lista, pulsando sobre la columna I,

se cambia el Nombre para Mostrar por: Nombre del Solicitante.

2. Empleados/DNI. Es un Sufijo del Prefijo de Empleados. Se le cambia el Nombre para Mostrar por:

DNI.

3. Empleados/TeléfonoEmpresa. Es un Sufijo del Prefijo de Empleados. Se le cambia el Nombre pa-

ra Mostrar por: Teléfono.

4. Empleados/ExtensiónCargo. Es un Sufijo del Prefijo de Empleados. Se le cambia el Nombre para

Mostrar por: Extensión.

5. Firma Empleado Solicitud. Es Término General dl tipo Firma Digital. Se le cambia el Nombre para

Mostrar por: Firma del Solicitante. Y se configura la firma pulsando sobre el ojo de la columna C

(Tamaño 100%, Pie de Firma Sí y Fuente Pie de Firma 7 Ptos.

Como se ha dicho antes, la explicación de los conceptos y de la operativa de Creación de Formularios se

encuentra en la documentación sobre Formularios Dinámicos.

Siguiendo con el Ejemplo, para configurar los campos se han realizado las siguientes acciones:

1. Se han agregado los campos Empleados, Empleados/DNI, Empleados/TeléfonoEmpresa, Em-

pleados/ExtensiónCargo y Firma Empleado Solicitud.

2. Mediante la columna I, se han cambiado los Nombres.

3. Se han marcado los campos con ‘V’ y ‘E’ que significa que funcionan en modo ‘Editar’ o solo son

para Ver (V).

4. Se han marcado como Tema el Nombre del Solicitante.

Agregar Botones

Al pulsar sobre Botones, en la barra de acciones de la LISTA DE CAMPOS SELECCIONADOS aparece la

ventana de configuración del botón, similar a la siguiente.

Poner un Nombre y una Descripción (opcional) y pulsar Guardar, se muestran entonces el resto de los

campos.

Nota.

El Nombre aquí elegido puede cambiarse posteriormente para aplicarle Multi-Idioma.

En el ejemplo le daremos el nombre Boton_Terminar, aunque finalmente tendrá Cur-


sar. Para más información, consultar la documentación sobre Formularios Dinámi-

cos.

Para agregar la acción que se desea que realice el botón, pulsar sobre Agregar Acciones (1), marcar la ac-

ción, en el ejemplo Terminar (2), y pulsar Aceptar Selección (3).

En este ejemplo se va a Personalizar el diseño del botón, utilizando una imagen, ver la figura inferior.

Nota.

Para más información sobre los botones, su configuración y sus acciones, consultar la

documentación sobre Formularios Dinámicos.


En este ejemplo los botones que necesita el Mensaje de Inicio, además de Boton_Terminar, serán los si-

guientes:

Boton_Salir. Para ser pulsado por el ejecutor del Mensaje de Inicio cuando quiera cerrar esta División

(Formulario Principal) para salir de ella.

En este ejemplo se configura dando el Nombre Cerrar y marcando Copiar de botón Cursar.

Boton_Documento Automático. Para ser pulsado por el ejecutor para que AuraPortal cree de forma

automática el documento Registro Impreso.

Para configurar este botón se introduce el Nombre Reg.Pp, los Permisos al ejecutor de Ver y Crear y

Guardar Documento, el Diseño del botón Copiar de el botón Cursar y se Agrega el Documento Base

Registro Impreso.

Al pulsar el botón Actualizar Campos y ordenar los elementos creados en su sitio del Tapiz, queda de la

siguiente forma:

4.2.1.4.2. División Breve Descripción

Siguiendo la misma operativa que la División anterior, se agrega el Campo de una Línea Breve Descripción

y dos Complementos para las figuras siguientes. Al colocarlo en el Tapiz quedaría así:

4.2.1.4.3. División Datos de lo Solicitado

Siguiendo la misma operativa, se agregan los Campos _Item, _Grado de Urgencia, _Estatus,

_Observaciones, _Documentos Adjuntos, _Unidades, _Item/ValorCoste y Total Importe.


A continuación se Configuran creando de la Lista siguiente, en la que se observa la configuración realizada.

Al pulsar el botón Actualizar Campos y ordenar los campos creados en su sitio del Tapiz, queda de la si-

guiente forma:

4.2.1.5. Tapiz de la Página

El Tapiz de la Página es el fondo sobre el que se sitúan las Divisiones Activas (con sus Campos y Botones)

y los demás complementos gráficos que constituyen la Página, tanto sueltos como incrustados en Comple-

mentos.

Los campos añadidos desde el Panel al Formulario pasan automáticamente al tapiz. Si se hace algún cambio

una vez añadidos, basta con pulsar sobre Actualizar Campos para actualizar el tapiz.

Una vez los campos en el Tapiz, deben colocarse en la posición adecuada. El formulario resultante es el si-

guiente:


4.2.2. Paso 2. Tarea P1.TP Revisión para 1ª Aprobación

La pestaña de Tareas muestra la lista de las que existen en el Diagrama.


Al pulsar sobre cada una de ellas aparece la ventana para dar atributos a esta Clase de Tarea Personal. Al

igual que en las Clases de Proceso, los datos a suministrar para cada Objeto (Tareas, Eventos y Compuertas)

se agrupan en tres secciones mostradas en sendos cajetines: IDENTIDAD, EJECUCIÓN y CRONOMETRÍA.

Recuerde que la explicación de los conceptos y de la operativa de la Ventana de Modelización se en-

cuentra otro capítulo de este Documento.

4.2.2.1. Identidad

Al entrar, el Género (TP) Tarea Personal y el Nombre que identifica la tarea Aprueba el Supervisor ya

han sido creados por el sistema, y puede introducirse una Descripción. Además, puede seleccionarse un

color distintivo de esta tarea en los Plannings.

Una información completa de la Gestión de Plannings se encuentra en la documentación sobre el Plan-

ning.

Para dar atributos a una Tarea Personal, en primer lugar se determina si la tarea debe ser ejecutada por un

Empleado, un Usuario Externo (que se comunica a través de Portales Externos) o por un Usuario Invitado

(que se comunica a través de la Web Pública y/o mediante Email u otro dispositivo similar).

Siguiendo el ejemplo, en este caso, la tarea Aprueba el Supervisor es ejecutada por un Empleado.


EJECUCIÓN

En primer lugar se configura la tarea como Clonable: comportamiento de la tarea en el caso en que la co-

rriente pase más de una vez por ella. No afecta a este ejemplo.

Participantes

Aquí se determinan los usuarios que de alguna forma van a intervenir en la tarea: Ejecutor, Responsable,

Emergencia y sus Suplentes. En este ejemplo, el Ejecutor es el Rol el Supervisor del Solicitante. Para definirlo

hay que proceder en la misma secuencia que las ventanas que siguen.


En este ejemplo se marca Supervisor (en Grado 1) del Autor del mensaje de inicio.

Instrucciones

Las Instrucciones que verá en su pantalla el Ejecutor de la Tarea pueden ser todo lo completas que se desee.

En este ejemplo, para esta Clase de Tarea se ha adoptado Texto. Al pulsar en el botón Editar aparece la

ventana de edición de texto rico, en la que introducimos el texto mostrado para las Instrucciones:


Zona de Trabajo

A continuación se determina:

1. Formato de la Ventana de Ejecución

Aquí se elige el Formato de la Ventana de Ejecución que verá el Ejecutor de la Tarea para llevarla a cabo. Los

Formatos han podido ser diseñados previamente desde la Estructura de AuraPortal en el Entorno de los

Procesos, aunque desde aquí también pueden crearse formatos.

Al pulsar sobre el ojo muestra la lista de los modelos ya dados de alta. Pulsado sobre uno de ellos se accede

a su ventana de Edición para su Consulta, Modificación. Para crear un nuevo modelo al pulsar sobre el bo-

tón Crear Modelo. Para esta Clase de Tarea, se ha confeccionado el Formato de nombre VET 1240 x 725.

80F-60I-40H con los siguientes parámetros:

2. Formularios

En este ejemplo solo se necesita un formulario. Para crearlo, al marcar la casilla y pulsar sobre el ojo de For-

mularios aparece una ventana desde la que se puede optar por crear un formulario Original o bien Similar a

otro del que ya se disponga.

En este caso, el formulario será similar al del Mensaje de Inicio. Al pulsar el botón Similar a otro se abre una

ventana de Buscar Formulario y se selecciona el Mensaje de Inicio, que queda integrado en la lista de Formu-

larios.

Al pulsar sobre el formulario el sistema crea una copia de éste en la Ventana de Creación de Formularios,

para ser modificado. Así pues, en primer lugar, se debe introducir un Nombre: Aprobación del Supervisor.

P1.TP y pulsar Guardar para que aparezcan los elementos de la ventana de creación.

Nota.

La Ventana de Creación de los Formularios de la Tareas es similar a la explicada

para los Mensajes de Inicio en el anterior apartado. Para una explicación más de-

tallada consulte la documentación sobre Formularios Dinámicos..

IDENTIDAD (en la parte superior derecha)

En este ejemplo, para configurar la Identidad, pulsar el icono de Más información para marcar los campos tal

como aparecen en la siguiente imagen:


DIVISIONES (en la parte central derecha)

Aparecen las divisiones del formulario del que se ha copiado, en este caso del Evento de Mensaje, pudiendo

ser modificadas. En este caso no se modifican, pero se crean dos nuevas Divisiones:

1. Botonera. Para albergar los botones de acciones del proceso.

2. Aprobaciones. Con los campos que utilizará el ejecutor para tomar su decisión.

LISTA DE CAMPOS SELECCIONADOS (en la parte inferior)

Para configurar el formulario de esta tarea se modificarán las divisiones del formulario de Inicio y se configu-

rarán las dos nuevas Divisiones. En cualquier caso,


De la división Formulario Principal:

Pulsando sobre el icono de la Lista, se desagregan los Botones de Terminar, Salir y Documento

Base.

A los campos que muestra la ventana (que son los que provienen del Mensaje de Inicio) se les des-

marca la casilla de E (editar) manteniendo V (ver), de forma que el ejecutor vea los campos pero no

pueda modificarlos.

De las divisiones Breve Descripción y Datos de lo Solicitado:

Se les desmarca la casilla de E (editar) manteniendo V (ver) a sus campos.

En la división Botonera:

Se agregan tres botones, tal como se ha explicado antes, como los que muestra la siguiente figura.

El botón Aprobar es un Disparador, de forma que cuando el ejecutor de la tarea lo pulse, debe aparecer

la ventana (división) de Aprobaciones. Por tanto, en la ventana de configuración además del resto de

elementos, hay que pulsar sobre el botón Crear Acciones y configurar el disparo.

En la división Aprobaciones:

Se agregan tres campos (Aprueba Supervisor?, Firma Supervisor y Motivos NO Aprobación)y el bo-

tón Cerrar para salir de la Venta. La División quedaría así:

Por último, pulsando el botón Actualizar Campos, se integran estos en el Tapiz.

3. Históricos

Los Históricos de un Proceso contienen quién ha participado cada tarea, cuándo y los comentarios agrega-

dos por los sucesivos participantes. Por cada Clase de Procesos pueden crearse cuantos Históricos se desee

para que actúen solo en algunas tareas, de esta forma, la información contenida solo estará disponible para

los usuarios adecuados. Así pues, para cada Tarea se determina desde este campo el acceso a unos u otros

históricos.

En este ejemplo, pulsando sobre el botón Agregar Histórico, se crea un Histórico Principal específico para los

aprobadores y un Histórico Secundario para todos.


CRONOMETRÍA

En este Ejemplo, sobre el Calendario del Proceso, se determinan los parámetros que aparecen en la ventana

y se introducen los siguientes valores.

De esta forma, además del control de la Duración Prevista, Mínima y Máxima, cuando falten 2 horas hábiles

(Umbral Alerta) para llegar a la Duración Máxima se producirá una Alerta que generará un aviso a quien se

indique bajo la opción Avisar a, que en este Ejemplo es el Responsable de la Clase de Procesos. (No se

muestra en la ventana este último dato porque podría haber más de un receptor del aviso, pero puede con-

sultarse pulsando sobre el ojo).

4.2.3. Paso 3. P1.DX 1ª Aprobación?

Para dar atributos a las Compuertas hay que pulsar en la pestaña Compuertas y aparece la lista de las que

figuran en el Diagrama:


La ventana de la Compuerta P1.DX es la siguiente.

COMPORTAMIENTO

1. Salida Complementaria (1). En el caso concreto de las Compuertas DX debe haber siempre una Salida

Complementaria (que siempre permite el paso si las demás salidas no cumplen condiciones), para garan-

tizar que la corriente no quede bloqueada en la Compuerta. En este Ejemplo se determina como Salida

Complementaria la que tiene por nombre (tal como consta en la línea de conexión del Diagrama que co-

rresponde a esta Salida), Aprobada.


2. Nombre Salida (2). Lo suministra automáticamente el sistema. Puesto que la Compuerta solo tiene 2 sali-

das, únicamente hay que definir las condiciones que determinan la Salida que no es Complementaria, es

decir, la Salida No Aprobada.

3. Descripción (3). Un campo opcional para ampliar la descripción de la Salida. No se utiliza aquí.

4. Orden de Evaluación (4). En las Compuertas con más de dos salidas hay que indicar el orden en el que el

Motor debe evaluar las condiciones de cada Salida pues cuando una Salida cumple condiciones ya no se

evalúan las demás, por lo que en los casos en los que las preferencia de las Salidas difieren, el orden de

evaluación de mayor a menor rango es muy importante. Cuando solo hay una Salida que evaluar, como

es este caso, no cabe especificar un orden.

5. Condiciones (5). Pulsar sobre el ojo y aparece la ventana siguiente.

Mediante el botón Crear Condiciones se crean las condiciones, que aparecen para su consulta en la lista

inferior. Si se ha creado más de una condición se debe seleccionar el Operador Lógico que debe aplicarse: si

se han de cumplir todas (AND), alguna (OR) o solo una (XOR).

Pulsando el botón Crear Condiciones, se abre una nueva ventana. El Nombre Compuerta y el Nombre Salida

lo suministra el sistema. El Nombre Condición es un Campo opcional para dar nombre a la Condición.


DATO REAL

- Fuente. En este caso, se elige Panel.

- Campo. Aquí se indica el campo del Panel cuyo valor se utilizará para evaluar la Condición. Para ello, pul-

sando sobre el ojo, aparece el Panel de la Clase de Procesos para seleccionar el campo. En este Ejemplo, el

campo seleccionado es Aprueba Supervisor?, en donde el Ejecutor de la Tarea P1.TP Aprueba Supervisor

habrá ingresado, mediante el Formulario de su Tarea, el valor correspondiente de Sí o No.

- Tipo Dato. Una vez indicado el Campo, el sistema muestra el Tipo de Dato que corresponde a este Cam-

po, según consta en el Diccionario de Términos. En este caso es Si/No.

Ahora la ventana se amplía para permitir indicar el valor de COMPARACIÓN que permite determinar el cum-

plimiento de la Condición. En este caso son las preguntas siguientes:

COMPARACIÓN

- Operador. Se puede elegir entre: Igual y Distinto. En el ejemplo, se elige Igual.

PATRÓN COMPARACIÓN

- Fuente. Se elige Manual Fijo.

- Valor. Solo puede elegirse Si o No en este tipo de campo. En nuestro ejemplo, se elige Sí.

Al pulsar Guardar y Salir se vuelve a la ventana de condiciones:


Operador Lógico solo interviene cuando hay varias Condiciones en la misma. En este caso no interviene

por haber solo una Condición.

Al pulsar Guardar y Salir se vuelve a la ventana principal.

CRONOMETRÍA


Procesos o uno particular para esta Compuerta.

2. Reloj Compuerta. A elegir entre el Reloj del Proceso (implica que se usará el mismo Reloj que el uti-

lizado en general para el Proceso), o directamente el Reloj del servidor o un Reloj Local.


En este Ejemplo la Salida llamada Aprobada es validada por el Motor y el flujo llega a la Compuerta

P1.DX.31.

4.2.4. Paso 4. P1.DX.31 Requiere 2ª Aprobación?

Esta Compuerta se encarga de analizar si se requiere o no una segunda aprobación. Se pretende que el Re-

sultado sea Sí (y por tanto necesita una segunda aprobación) cuando el Importe de la Inversión sea de ma-

yor cuantía, considerando ésta como superior a 300 €. Si la Inversión es inferior 300 € conduce al Resultado

No, y por tanto no se necesita la aprobación del Jefe de División.

Para configurarla se siguen los mismos pasos que la anterior. En este caso:

1. En primer lugar, se determina como Salida Complementaria la que tiene por nombre No (No se re-

quiere aprobación).

2. Y a continuación se define la Condición de la Salida Sí, esto es, que el campo Total Importe sea Ma-

yor o Igual de 300€.

CRONOMETRÍA

Los datos a suministrar son: el Calendario del Proceso y el Reloj Compuerta que utilice el Proceso. En este

Ejemplo la Salida llamada Sí será la validada por el Motor y el flujo llegará al Evento P1.ET.

4.2.5. Paso 5. P1.ET Solo Lunes y Jueves de 10:00 a 12:00

Esta Clase de Evento Tiempo tiene como misión impedir el paso de la corriente del Proceso cuando ésta le

llega, hasta que sea Lunes o Jueves y que, Además, la hora esté comprendida entre las 10:00 y las 12:00.

IDENTIDAD

Se muestra a continuación el cajetín de Identidad ya cumplimentado.


La Descripción se incluye en el campo de Texto Rico (1):

Detiene la corriente del proceso hasta que sea lunes o jueves, y solo permite el paso entre las 10:00 y las 12:00

de esos días.

Pulsando sobre Control por Fecha (2) se establece la condición para el ET.

CRONOMETRÍA

Calendario. En este Ejemplo se elige el Calendario del Proceso.

Reloj Evento. Se elige el Reloj del Proceso.

Opciones

Aunque se permiten diversas opciones, (lo que significa que se pueden dar diversos controles de tiempo y el

sistema dará por válido el primero que se cumpla), en este Ejemplo se considera una única opción que se

basa en un Control por Fecha (no un Control por Duración ya que no ha de controlar un retraso medido sino

unas fechas de paso: Lunes y Jueves).

Para configurar la opción, después de señalar Control por Fecha, pulsar sobre el ojo y en la ventana que

aparece, indicar los parámetros:

Aquí se selecciona la Modalidad, que en este Evento es la de Solo Días de Semana. Al pulsar sobre el ojo

aparece la ventana para elegir los días de la semana:


Puede observarse que se han marcado como Días de Semana los Lunes y Jueves. Al no indicar ninguna Se-

mana en Año se entiende que todas las semanas son válidas. Sin embargo, puesto que el Calendario elegido

ya contiene los días laborables y festivos, si el Lunes o Jueves resulta festivo, no activará el Evento.

Ahora, para determinar el intervalo de 10:00 a 12:00 se pulsa sobre el icono configurador (ojo) de Control por

Horas y aparece la ventana:

En esta ventana hemos indicado que el Margen de Validez es 120 minutos (2 horas) lo que significa que será

permitido el paso en cualquier momento que se encuentre dentro de este margen a partir de la hora que se

ha introducido en el cajetín inferior, que en este caso es las 10:00.

Una vez el flujo ha pasado por el Evento P1.ET, llega a la Tarea P1.TP.38.


4.2.6. Paso 6. P1.TP.38 Aprueba el Jefe de DIV.

Esta Clase de Tarea Personal es muy similar a la P1.TP Aprueba el Supervisor mostrada más arriba, por lo

que no es necesario repetir las explicaciones pormenorizadas que se dieron allí.

Las principales diferencias con la Clase de Tarea P1.TP son:

1. Como Ejecutor se debe marcar Rol, Singular y seleccionar Jefe de División.

2. No se utilizan las Instrucciones.

3. En el Formulario la División Aprobaciones queda de la siguiente forma:

Cuando el Ejecutor termina esta Tarea la corriente pasa a la Compuerta P1.DX.42.

4.2.7. Paso 7. P1.DX.42 2ª Aprobación?

Esta Compuerta es prácticamente igual a la P1.DX 1ª Aprobación que se ha tratado anteriormente. La única

diferencia es que el campo de Panel que la compuerta observa para ver su valor es el llamado 2ª Aproba-

ción en lugar de 1ª Aprobación.

En este ejemplo, la Salida válida de esta Compuerta es la de nombre Aprobada, y la corriente llega al Punto

de Control P1.K.

4.2.8. Paso 8. Puntos de Control P1.K y P1.K.114

Para dar atributos a los Puntos de Control y a los Lapsos hay que pulsar en la pestaña Lapsos y aparece la

lista de los Puntos que figuran en el Diagrama:


No se consideran los Puntos y Lapsos en este ejemplo.

Después de este Punto de Control la corriente llega a la Tarea de Sistema P1.TP.24.

4.2.9. Paso 9. P1.TP.24 Notifica que ha sido Aprobado

Con esta Clase de Tarea Personal se actúa de forma similar a las anteriores (P1.TP y P1.TP.38) tratadas más

arriba, por lo que no es necesario repetir las explicaciones que se dieron allí. En este caso, al tratarse de noti-

ficar la aprobación de la inversión al solicitante:

1. Como Ejecutor se debe marcar el Autor del Mensaje de Inicio.


3. El Formulario contiene es Copia Similar del anterior con las siguiente diferencias:

En todos los campos deben desmarcarse las casillas de Editar, con lo que el ejecutor no podrá

modificar sus valores.

Se elimina la División Aprobaciones.

En la División Datos de lo solicitado se añaden los campos:

Stock Disponible. Se trata del Sufijo Item. ValorNominal.

Nota.

Este campo de la ficha de Ítems se ha utilizado en este caso para registrar la canti-

dad de stock disponible para simplificar el ejemplo.

En un caso real, este campo provendría de la Gestión de Almacén del ERP con el

que trabaja la empresa o bien, en su defecto, de un Anexo de Ítems creado para el

control de stocks.


Stock Calculado. Se trata de un campo General del tipo Número Decimal y configurado como

Calculado la resta del Stock Disponible menos las Unidades Solicitadas

([0_2_Item/ValorNominal] - [0_3_Unidades]).

Se muestran a continuación.

Y se crean dos nuevas Divisiones:

- Ubicación. Con los sufijos de Item/Comentarios y Item/GridCampoResponsable.

- Aviso 01. Que se diseña de la siguiente manera:


4.2.10. Paso 10. P1.DX. 91 Material Disponible?

Con esta Compuerta se actúa de forma similar a las anteriores. En este Ejemplo la Salida llamada Sí será la

validada por el Motor y el flujo llegará a la Tarea de Sistema P1.TS.98.

4.2.11. Paso 11. P1.TS.98 Notificación de Entrega

Esta Clase de Tarea de Sistema envía al solicitante una Notificación informando de que hay material disponi-

ble y que, por tanto puede proceder a retirar el material solicitado.


En el ejemplo, para dar atributos a esta tarea:

Función. Se elige NOTIFICADOR - (Notifica a Usuarios Empleados).

Destinatario. Se marca General y se selecciona Autor del Mensaje de Inicio.

Texto. Se introduce un texto informando de que hay material disponible y que, por tanto puede proceder

a retirar el material solicitado.

Remitente. Se marca Sistema.

Documentos. Se marca Sí y se selecciona el campo Documentos Adjuntos.

Una vez el flujo ha pasado por esta TS, llega a la Tarea P1.TP.109 Recogida del Material.

4.2.12. Paso 12. P1.TP 109 Recogida del Material

Con esta Clase de Tarea Personal se actúa de forma similar a las anteriores tratadas más arriba, por lo que no

es necesario repetir las explicaciones que se dieron allí.

En este caso:

1. Como Ejecutor se debe marcar Del Panel, General y seleccionar Item/Responsable.


3. El Formulario contiene es Copia Similar del anterior con las siguiente diferencias:

En todos los campos deben desmarcarse las casillas de Editar, con lo que el ejecutor no podrá

modificar sus valores.

Se elimina la División Ubicación.

Se modifica el contenido de la División Aviso 01, quedando de la siguiente manera:


4.2.13. Paso 13. P1.TS.125 Actualiza Stock

Esta Clase de Tarea de Sistema actualiza de forma automática los stocks movidos al retirar el material solici-

tado.

En el ejemplo, para dar atributos a esta tarea:

1. Función. Se elige INGRESADOR - (Ingresa en el Panel Información o Valor Calculado).

2. Ingreso Directo. Tal como indica la figura.


Una vez el flujo ha pasado por esta TS, la corriente llega al Evento de Fin que termina el proceso.

Modelización Terminada

AuraPortal ha construido el código de programación para el Motor que conducirá la ejecución del proceso.

No hay necesidad alguna de programación, inclusive para llevar a cabo los procesos más complejos. Esta

característica es netamente diferenciadora y constituye un importante atractivo del producto.

5. EJEMPLO – EJECUCIÓN

La EJECUCIÓN de cada Proceso la realizan los Motores de Procesos (puede haber varios motores trabajan-

do juntos en un solo proceso porque cada hilo de flujo está controlado por un Motor). El Orquestador en-

ciende el Motor cuando un Evento Inicio (por Mensaje, Tiempo o Registro) es disparado.

Como ya se ha dicho, una vez se ha terminado el Modelo y se han realizado las Simulaciones pertinentes

para comprobar que el Proceso funciona correctamente (todo ello se efectúa por ejecutivos de la empresa o

por consultores de negocio sin necesidad de programar), basta poner la Clase de Procesos en el Modo Pro-

ducción y, como resultado, Procesos de esta Clase serán iniciados automáticamente cuando el Evento Inicio

se dispara.

En este ejemplo, una vez ha sido realizada la Modelización de la Clase de Procesos tal como ha sido explica-

da en el capítulo anterior, se pasa, sin realizar programación alguna, a su ejecución.

Nota.

También es posible poner en producción una Clase de Procesos en Entorno Desarrollo,

configurándola para que se puedan iniciar Procesos. Esto tiene la ventaja de que permi-

te mayor flexibilidad a la hora de hacer ajustes y modificaciones pero requiere un gran

cuidado para que los cambios no afecten a los procesos ya en ejecución.

5.1. Inicio del Proceso

Este Ejemplo maneja la Clase de Procesos Autorización de Compra que inicia sus Procesos mediante el

Evento de Mensaje P1.IM Solicitud Inicial.

El usuario (empleado) ap4 pulsa el botón Crear Mensaje desde, por ejemplo, su ventana de Mis Tareas. Se

abrirá una lista con los Formularios de Inicio e Intermedios a los que tenga acceso este empleado. Al pulsar

sobre el nombre Solicitud Inicial aparece el siguiente formulario:


Como se puede apreciar, y según ha sido diseñado, el sistema reconoce el Nombre del solicitante, lo intro-

duce y añade los campos DNI, Teléfono y Extensión que constan en su ficha.

El solicitante debe introducir una Breve Descripción (Solicito dos portátiles para mi departamento, tal como

acordamos) de la petición e indicar el elemento que desea (Ordenador Portátil Marca XXX/ Características

YYY). Para ello, pulsando el ojo de Solicitud de, lo selecciona, así como el Grado de Urgencia (Urgente) de la

petición y el Estatus. También puede escribir unas Observaciones (Debemos disponer de ellos esta misma

semana.) y/o adjuntar Documentos que crea de interés. A continuación introduce el número de Unidades (2)

que desea. El sistema introduce el Coste/Unidad del elemento, que constan en su ficha, y el Importe Total de

la solicitud.

A continuación, AP4 pulsa sobre el ojo de Firma del Solicitante e introduce su pin (1234) de firma digital para

firmar el formulario.


Por último, la pulsar el botón Reg.Pp se abre una ventana para crear el documento Registro Impreso, para

el control administrativo de la operación. Al pulsar Guardar en la ventana, el documento es creado automáti-

camente por el sistema e introducido en el campo Documentos Adjuntos, según la configuración realizada

en el capítulo anterior. A continuación, pulsa sobre el ojo de Documentos Adjuntos y Firma. El documento

queda creado y firmado, tal como se aprecia en la figura.

Una vez cumplimentados puede proceder a pulsar el botón Cursar, que pone en marcha el Motor BPM

(también podría pulsar el botón Cerrar, caso que desee guardarlo en Estado Borrador para más adelante).

La Referencia Base del Proceso recién iniciado es: C1-1.1_1, indicando que se trata de un Proceso que es la

instancia nº 1 dentro de la Clase de Procesos: C1-1.1 (el primer 1 es el de la ID de la Clase de Procesos y el

segundo 1 es el nº de versión). Esta Referencia la construye automáticamente el sistema.

5.2. Funcionamiento del Proceso

El primer Objeto que se activa es la Tarea P1.TP que se muestra a continuación.

5.2.1. Tarea P1.TP Revisión para 1ª Aprobación_4

El Supervisor del solicitante (ap1) verá en su pantalla un aviso producido por el Avisador de AuraPortal indi-

cando que tiene tareas pendientes de abrir.


Al Pulsar en Mis Tareas, el Supervisor verá su listado de tareas pendientes.

Puede verse que en la pestaña de Tareas de Proceso la Tarea P1.TP Aprueba Supervisor está en estado

Llegada ( sin abrir). Pulsando sobre la línea de la Tarea aparece la Ventana de Ejecución de Tarea (VET):

Instrucciones

En este cajetín aparecen las instrucciones que ha de seguir el Ejecutor. En los casos en que el cajetín no sea

suficiente para ver el texto completo se puede utilizar la barra de ascensor o pulsar el botón Ampliar que

presenta una ventana de mayores dimensiones.

Formularios

Al entrar en la tarea, el Formulario muestra los Datos Informativos introducidos por el solicitante. Siguiendo

las Instrucciones, después de haber estudiado el tema, pulsa el botón se abre una ventana

con los Campos a Cumplimentar.


Si en el campo Aprueba Supervisor? del Formulario el Ejecutor selecciona No, aparece entonces el campo

Motivación de No Aprobación (que al ser de tipo Condicional solo aparece si se marca No).

En este ejemplo, al marcar Sí, no aparecerá el campo Motivación de No Aprobación ya que solo es para

justificar la decisión en caso de No Aprobación. Bastará con que firme el formulario (Pin 1234). Además, pul-

sando el ojo de Documentos Adjuntos del formulario firmará igualmente el documento de Control de Ad-

ministración.

Histórico

Para agregar comentarios en el Histórico principal pulsa sobre el botón Editar. Aparece la ventana para es-

cribir un texto:

Una vez escrito el texto del comentario, pulsar Guardar y Salir. Se vuelve a la VET (Ventana de Ejecución de

Tarea):


Pulsando el botón Cursar la Tarea finaliza y el flujo llega al objeto nuevo en el Diagrama: la Compuerta

P1.DX 1ª Aprobación?.

5.2.2. Compuerta P1.DX 1ª Aprobación?

Al llegar a esta Compuerta, el Motor analiza las Condiciones y encuentra la respuesta Sí registrado en el

campo del Panel 1ª Aprobación?. Por tanto se activa la conexión de la Salida Aprobada que conduce la co-

rriente a la Compuerta P1.DX.31.

5.2.3. Compuerta P1.DX.31 Requiere 2ª Aprobación?

Esta Compuerta se encarga de analizar si se requiere o no una segunda aprobación. Se pretende que el Re-

sultado sea Sí (y por tanto necesita una segunda aprobación) si el importe de la compra es de mayor cuan-

tía, considerando ésta como superior a 300 €.

Puesto que en este caso el importe de la inversión es de 1.400 €, el Motor activa la Salida Sí (es decir, Sí se

requiere una 2ª Aprobación). El flujo pasa al Evento Tiempo P1.ET.

5.2.4. Evento Tiempo P1.ET Solo Lunes y Jueves de 10:00 a 12:00

El flujo queda detenido hasta que se cumpla que el día sea Lunes o Jueves y la hora sea a partir de las 10:00

y hasta las 12:00.

Como en este Ejemplo la Tarea anterior (P1.TP) ha sido terminada el Jueves a las 11:55, la corriente ha llega-

do al Evento P1.ET inmediatamente (después de valorar y pasar por las Compuertas P1.DX y P1.DX.23, lo

cual prácticamente no consume tiempo).

El Motor comprueba que el tiempo de llegada al Evento está dentro del intervalo permitido y deja pasar la

corriente, que llega a la Tarea P1.TP.38.

Nota.

Como en la práctica es probable que el momento de ejecutar el proceso no coincida

con este periodo, lo que debe hacerse es acceder a la ventana de configuración de la

Clase de Procesos (Estructura), cambiar a modo Desarrollo, acceder al evento de tiempo


y modificarlo para que entre dentro del intervalo permitido. A continuación ya se puede

seguir trabajando.

5.2.5. Tarea Personal P1.TP.38 Aprueba el Jefe de División

El Ejecutor de esta Tarea es el asignado al Rol Jefe de División (usuario AP3), el cual accede a su ventana de

Tareas Pendientes y al pulsar sobre la tarea la ventana se ve prácticamente igual que la del supervisor, y

como él debe estudiar la propuesta y pulsar el botón . La ventana que se abre es diferente.

Puede verse que el usuario AP3 (Jefe de División), después de leer la Tarea y examinar los documentos ad-

juntos y comentarios agregados por el Supervisor, ha decidido aprobar la compra. Para hacerlo contesta Sí

en la pregunta del campo Aprueba Jefe Div. y, a continuación firma el formulario. Además, pulsando el ojo

de Documentos Adjuntos firmará igualmente el documento de Control de Administración.


Podría además haber añadido sus comentarios al Histórico pero no lo ha considerado necesario. Al pulsar

Cerrar en el Formulario de Aprobación y Cursar en el Formulario Principal, el flujo pasa a la Compuerta

P1.DX.42.

5.2.6. Compuerta P1.DX.42 2ª Aprobación?

Al llegar a esta compuerta el Motor examina la condición de la conexión Aprobada, que consiste en compro-

bar que en el campo Aprueba Jefe Div. del Panel aparezca el valor Sí. En este caso, la condición se cumple y

la corriente pasa al Punto de Control P1.K Punto de Control.

5.2.7. Punto de Control P1.K Punto de Control

El Motor se limita a tomar nota del momento exacto en el que el flujo pasa por este punto. El flujo llega al

siguiente Objeto: P1.TP.24 Notifica que ha sido Autorizado.

5.2.8. Tarea Personal P1.TP.24 Notifica que ha sido Autorizado

El Ejecutor de esta Tarea es el Solicitante de la Compra. Al acceder a su ventana de Tareas Pendientes y al

pulsar sobre la tarea la ventana se ve así:

Y al pulsar Cerrar la Nota Informativa se observa que el formulario contiene la firma digital del Solicitante,

Supervisor y Jefe de División.


Al pulsar Cursar, el flujo pasa a la Compuerta P1.DX.19.

5.2.9. Compuerta P1.DX.19 2ª Material Disponible?

Al llegar a esta compuerta el Motor examina la condición de existencia de Stock, que consiste en comprobar

que en el campo Item/ValorNominal que como se dijo en el capítulo de Modelización es el utilizado para

controlar el Stock Existente, es Menor que 1. En este caso, la condición No se cumple y la corriente pasa al

Punto de Control P1.K Punto de Control.

5.2.10. Tarea de Sistema P1.TS.98 Notificación de Entrega

Esta Tarea le llega al solicitante creada por el propio sistema, comunicándole que puede proceder a la retira-

da de los elementos solicitados.


5.2.11. Punto de Control P1.K.114 Punto de Control

El Motor se limita a tomar nota del momento exacto en el que el flujo pasa por este punto.

El flujo llega al siguiente Objeto: P1.TP.109 Recogida del Material.

5.2.12. Tarea Personal P1.TP.109 Recogida del Material

Esta Tarea le llega al asignado al Responsable del elemento (ordenador portátil) que es el usuario AP5.

Después de leer el mensaje de Atención con las instrucciones a seguir, pulsa Cerrar para acceder al Formula-

rio Principal.


Ya en el Formulario Principal, marca las casillas correspondientes de retiro de material y pulsa Cursar.

El flujo llega al siguiente Objeto: P1.TS.125 Actualiza Stock, que realiza esta acción de forma automática.

Una vez el flujo ha pasado por esta TS, la corriente llega al Evento de Fin.

Ahora el Proceso llega a su Fin y entonces termina.

Nota.

De no haber sido Aprobada la compra o de no haber Material Disponible, el flujo hu-

biera seguido otras direcciones y llegado a otros objetos.

Estos no se presentan en este tutorial ya que, al haberse mostrado el comportamiento

de al menos una vez cada uno de los objetos, no se ha considerado necesario.


6. EJEMPLO – MONITORIZACIÓN

La MONITORIZACIÓN permite, por un lado, la posibilidad de conocer lo que realmente está pasando en

cada momento y en cualquier Proceso vivo durante la actividad empresarial con información sobre métricas

de tiempos y costes y con la opción a intervenir para corregir desviaciones, y por otro, la posibilidad de ana-

lizar con el máximo detalle lo que ha sucedido en el pasado, en Procesos ya terminados también con métri-

cas de tiempos y costes, lo que permite reformar el diseño de los Procesos con el fin de optimizar el funcio-

namiento empresarial.

Los tipos de datos obtenidos suelen denominarse Indicadores de Funcionamiento (KPI o ‘Key Performance

Indicators’). La elección de unos Indicadores u otros depende de las características de la industria y de las

necesidades específicas del usuario.

La Monitorización se lleva a cabo en tres frentes simultáneos, el primero se realiza mediante Procedimientos

Automáticos y los otros dos mediante Consultas:

1. Controles de Sistema. Mientras los Procesos están en curso, cualquier Tarea que llegue a los umbrales

de Alertas o a las Alarmas, así como cualquier error u otra causa que produzca ‘atasco’ en un objeto

del Proceso hace que el sistema genere una Notificación de aviso al responsable del Proceso para su

información y para que pueda actuar en consecuencia.

Además de la Notificación el sistema bloquea el Proceso si lo considera necesario hasta que el problema

del atasco se resuelva. Estos procedimientos no son creados por el usuario sino que vienen incluidos en

la aplicación.

2. Cuadro de Mandos. Se explica a continuación.

3. Business Intelligence. Se explica a continuación.

6.1. Cuadro de Mandos

El Cuadro de Mandos comprende el conjunto de Consultas bajo demanda (creadas por el usuario) que

permiten conocer y controlar la marcha de los Procesos para intervenir sobre ellos y corregir o ajustar aque-

llo que por su deficiente funcionamiento debe ser modificado.

Ofrece varios formatos de consulta:

Control de Ejecución

Consulta de Procesos

Consulta de Tiempos

Las Consultas, tanto de Cuadro de Mandos como de Business Intelligence pueden guardarse con un

nombre identificativo en el Árbol del Diccionario de Consultas para su uso repetitivo, asignando la seguri-

dad de acceso al colocarlo en un Recinto Seguro.

Naturalmente, lo que se guarda de una determinada Consulta no son los datos obtenidos sino la plantilla o

esquema en donde se definen los parámetros y filtros que se usan en esta Consulta.

Al guardar una Consulta Nueva, es decir, recién creada, es necesario indicar el Nombre con el que se quiere

identificar la Consulta para usos posteriores, será una Consulta Privada y solo estará accesible para su crea-

dor). Las Consultas Públicas, accesibles por cualquier usuario con suficiente permiso, se crean desde el Dic-

cionario de Consultas de Estructura.


Así pues, al entrar en esta ventana, primero debe marcarse si se desea realizar una consulta Pública, una

Privada o bien una Nueva.

Si marca Nueva, a continuación debe elegir el Tipo de Consulta que desea realizar: Ejecuciones, Vis-

tas o Tiempos. En función del tipo seleccionado aparecen campos diferentes para filtrar la consulta.

Después de cumplimentar los campos deseados, puede guardarse como una nueva consulta. Al

pulsar Proceder la lista muestra los Procesos que cumplen las condiciones del filtro.

Si marca Consulta Pública o Privada aparece un nuevo campo para seleccionar la consulta. Para

facilitar la selección se abre una ventana como la de la figura siguiente, en la que marcando el Tipo

de Consulta y/o introduciendo una porción del nombre se acota la lista de consultas.

En cualquiera de los casos, pulsando sobre un Proceso de la lista se accede a la consulta.

6.1.1. Control de Ejecución

Permite un control exhaustivo de la ejecución de cada proceso en curso o ya terminado.


Después de seleccionar la Clase de Procesos a controlar, acotar la búsqueda mediante el filtro y pulsar Pro-

ceder, se abre la lista de los Procesos que cumplen las condiciones.

Al pulsar sobre un determinado proceso se abre una ventana como la siguiente.

Está dividida en dos partes. En la parte derecha puede visualizarse el Diagrama de la Clase de Procesos, para

su consulta. En la parte izquierda aparecen las siguientes opciones:

1. Rastreo. Reproduce el flujo con todos los objetos por los que ha pasado la corriente del proceso.

Dispone de un botón de Imprimir y otro de Ampliar, que contiene la explicación de todos los signos

empleados para su correcta interpretación.

2. Además, pulsando sobre una Tarea Personal se accede a una copia de ella en modo Consulta.

Nota.

Si el usuario que consulta la tarea es su ejecutor, la tarea aparece en modo edición, se-

gún fue configurada.

3. Panel. Muestra todos los campos utilizados hasta el momento con sus valores.

4. Históricos. Cada Histórico muestra, por cada Tarea Personal su ejecutor (nombre y cargo) la tarea

realizada, la fecha y momento en que se realizó y los posibles comentarios del ejecutor.

5. Documentos. Muestra todos los documentos integrados y asociados al proceso, con la posibilidad de

ser abiertos y consultados.

6. Cronometría. Muestra los valores cronométricos del proceso.


6.1.2. Consulta de Procesos

Permite consultar los procesos según diferentes Vistas que han sido diseñadas por el propio usuario.

Estas vistas, que reproducen diferentes formatos de consulta de los procesos ejecutados según los criterios

que se desee, constan de:

Un Filtro que permitirá filtrar los procesos de la Clase de Procesos seleccionada.

La Lista que muestra todos los procesos que cumplen las condiciones del filtro y permiten seleccionar

el proceso

La Ficha con los datos deseados del proceso.

Las Vistas no se pueden guardar como Consultas Privadas, son configuradas por el usuario con el permiso

adecuado desde la correspondiente opción en Estructura, incluidos los campos que deben aparecer en el

filtro, las columnas de la lista y los campos y su situación en la ficha.

Una vez han sido configuradas, al seleccionar en la Monitorización el Tipo de Consulta ‘Consulta de Proce-

sos’ aparece el campo Vista. Pulsando sobre el ojo se selecciona la vista que se desea consultar, apareciendo

entonces el filtro para seleccionar el Proceso, tal como se ha diseñado.

6.1.3. Consulta de Tiempos

El cajetín de filtrado permite numerosas combinaciones. Después de definir los parámetros y pulsar Proceder

aparece el siguiente informe.

Cada línea representa un Objeto sometido a observación. Para cada uno se establecen las siguientes colum-

nas.

Referencia. La referencia Base del Proceso.

Clase Proceso. El nombre de la Clase de Procesos en donde se encuentra el Objeto.

Tema. Uno o dos campos rellenados como ‘Temas’ en el Formulario del Mensaje Inicio para mejor iden-

tificar el Proceso.


O=Objetos. Pueden ser: Tareas de Proceso, Puntos de Control y Lapsos.

Nombre. El nombre del Objeto.

Ojo Visor. Para poder acceder a la Tarea. Si el objeto es un Proceso, un Punto de Control o un Lapso en

lugar del ojo visor aparece un guión ‘-‘.

C= Nivel Crítico. El Nivel Crítico (0-9) se determina por cada Objeto en la Cronometría. Sirve para separar

los Objetos críticos a la hora de examinar rendimiento.

Vencimiento. La fecha (con horas, minutos y segundos) en la que el Objeto debe estar resuelto para no

sobrepasar la duración máxima o la fecha máxima estipulada.

Umb.=Umbral. El tiempo establecido anterior al Vencimiento para comenzar a generar la Alerta.

Un. Unidad de medida de tiempo en la Cronometría de este Objeto. Ejemplos: DL=Días Laborables,

ML=Minutos Laborables, DN=Días Naturales, etc.

Margen. El tiempo que falta desde el momento de la consulta hasta alcanzar el Vencimiento del Objeto.

Si el Objeto está Terminado, aparece el valor (positivo o negativo) correspondiente a la diferencia entre

el Vencimiento y el tiempo de Terminación.

Aler / Alar.=Alerta /Alarma. Si se ha alcanzado el Umbral, en esta columna se ve Alerta. Si se ha alcanza-

do el Vencimiento sin resolver el Objeto, se ve Alarma. Si el Objeto ha sido resuelto dentro del plazo

aparece Term.OK (Terminada OK). Si lo ha sido fuera de plazo, aparece Term.RET (Terminada con Re-

traso). Si está en curso dentro de plazo aparece Activa OK.

Para ver un listado de Objetos ampliado, pulsar el botón Ampliar.

Nota.

Al tratarse un control de tiempos reales, si se mantiene esta ventana abierta durante

algún tiempo, los datos quedan desactualizados. En este caso se puede provocar un re-

fresco instantáneo pulsando el botón de Proceder.

6.2. Business Intelligence

Business Intelligence comprende el conjunto de Consultas bajo demanda creadas por el usuario (informes,

reportes, imágenes, etc.) que se generan a partir de los datos almacenados en la base de datos de AuraPortal

para realizar análisis individuales y estadísticos que permiten obtener conclusiones relativas a Procesos o

conjuntos de Procesos ya terminados así como a sus Clases.

La división de Business Intelligence de la etapa de la Monitorización permite observar los datos relativos a

los Procesos ya terminados, analizando los Indicadores Clave mediante técnicas de ‘drill down’ y herramien-

tas de BI (Business Intelligence) utilizando cubos OLAP, etc.

Los formatos pueden ser: Tablas o Gráficos (tarta, barras, etc.) del estilo siguiente o de otros, a gusto del

usuario.


El alcance de la MONITORIZACIÓN en AuraPortal Business Intelligence no tiene límite. Se suministra una

herramienta de Microsoft SQL Reporting Services para usuarios con SQL 2008 o superior que permite al

usuario generar sus propios informes e invocarlos en cualquier momento. Además, se suministra un conjunto

ya confeccionado de Informes con los principales Indicadores Clave (KBPI) de disposición inmediata.

Se pueden consultar todos los detalles referentes a la Monitorización en la documentación disponible sobre

Análisis de la Información y KPI.

APÉNDICE A1 - ESTRUCTURA AURAPORTAL Y PROCESOS

La creación de un Modelo para una Clase de Procesos requiere la presencia y utilización de plataformas de

apoyo que son de uso general en AuraPortal, y por tanto no privativas del módulo BPMS, y menos de cada

Clase de Procesos, pero que son soporte indispensable para el funcionamiento de los Procesos. Los compo-

nentes de la Estructura de AuraPortal que se utilizan en la MODELIZACIÓN de los Procesos son:

1. Calendarios

2. Roles

3. Diccionario de Términos

4. Servicios Web

5. Adaptadores

6. Mensajes

7. Familias


A1.1. Calendarios

En AuraPortal se pueden definir Calendarios sin límite. Cada Calendario, que puede contener cuantos años

se quiera, se identifica por un nombre y una descripción y sirve para establecer los días de fiesta, así como

los horarios laborales de todos los días que figuran en él. Los Calendarios se aplican principalmente a las

Clases de Proceso, aunque también se pueden aplicar a los objetos si así se requiere.

La creación, consulta y edición de los Calendarios se realiza en las siguientes ventanas.

Consulta y Edición

Pulsando sobre uno, por ejemplo Calendar Zone MX.6_2, aparece la siguiente ventana:

Si se pulsa sobre el correspondiente al año 2014, aparece la ventana:


El calendario mostrado contiene no solo los días de fiesta sino también el horario laboral de todos los días

de cada año (en este ejemplo, el 2014). Esto permite que en los Procesos se puedan computar las fechas por

días naturales y hábiles así como las duraciones en horas, minutos y segundos, tanto naturales como hábiles.

Por ejemplo, si una Tarea ha de durar como máximo 5 horas hábiles y se inicia el día 13 de Abril (Jueves

santo) a las 13:00, el sistema sabe que el plazo de terminación expira el siguiente día hábil, es decir, el Mar-

tes 18 de Abril, a las 12:00.

Creación

Si se pulsa sobre la opción Crear Calendario de la barra de acciones, aparecen las ventanas arriba mostradas

sin datos, listas para recibir la información pertinente.

A1.2. Roles

Se llama Rol al nombre de la función o responsabilidad que desempeñan uno o más usuarios dentro del

sistema AuraPortal de cara a su intervención en los Procesos. Los Roles son a veces necesarios para determi-

nar los participantes en las Tareas Personales de los Procesos. Hay Roles de tres Naturalezas: Singulares,

Genéricos y De Cuenta.

Se llama Rol Singular a aquel cuyo Asignado (usuario o grupo que ostenta la titularidad del Rol)

está determinado con carácter fijo, es decir, que una vez identificado el nombre del Rol, se sabe

quién es el Asignado con independencia del contexto en el que actúa. El Asignado depende solo

del nombre del Rol.


Ejemplos de Roles Singulares: ‘Director de Calidad’, ‘Encargado de Almacén’, etc., que siempre es el

mismo Empleado o Grupo, con independencia del contexto en el que actúa.

Se llama Rol Genérico a aquel cuyo Asignado no es fijo sino que depende del lugar en el que actúa,

llamado Lugar de Actuación del Rol o simplemente, LA. Un mismo nombre de Rol Genérico pue-

de tener diferentes Asignados si el Rol puede actuar en varios LA.

Ejemplos de Roles Genéricos son: ‘Jefe del Departamento’ (el asignado depende del Departamento),

‘Responsable de Cuenta’ (el asignado depende de la Cuenta) o, en el ejemplo seguido en esta Mo-

nografía, el ‘Jefe de Obra’ (el asignado depende de la Obra en cuestión). En estos ejemplos los LA

son respectivamente el Departamento, la Cuenta y la Obra en donde se encuentra en ese momento

el Proceso.

Se llama Rol De Cuenta a aquel cuyo Asignado no es un empleado (como en los dos casos anterio-

res), sino un contacto de una determinada Cuenta (Usuario Externo o Invitado).

Por su importancia, los Conceptos Básicos y la operativa con los Roles se explican en la documentación so-

bre Roles, Perfiles y Grupos de Empleados.

A1.3. Diccionario de Términos

El Diccionario de Términos contiene los Términos creados por el usuario de AuraPortal (el diseñador de la

Clase de Procesos, por ejemplo) y que se utilizan en los Procesos para definir Campos de Formularios, Cri-

terios en las Reglas de Negocio y Adaptadores (Dispositivos de conexión entre AuraPortal y otras aplica-

ciones como ERP, etc.).

Posteriormente, la Clase de Panel de cada Clase de Procesos (que contiene todos los campos que van a

utilizarse al ejecutar los Procesos de esa Clase) se configura con los Términos de este Diccionario.

Se accede al Diccionario de Términos desde la sección GENERAL de la Estructura de AuraPortal.

El Diccionario de Términos se gestiona mediante Árboles.


Para una explicación completa y detallada del funcionamiento y posibilidades del Diccionario de Términos,

consultar el Manual del Administrador Delegado. Los distintos Términos que se pueden crear desde el

diccionario y sus posibles configuraciones se explican en la documentación sobre Formularios Dinámicos,

excepto los Grupos de Campos.

A1.4. Servicios Web

La mayoría de la información almacenada en AuraPortal está disponible a través de Web Services, tanto para

introducir como para extraer información.

Muchos programas pueden conectarse a Web Services, tanto aplicaciones estándar (MS Access, MS Excel)

como programas diseñados a propósito con cualquier sistema de programación, como Java, Visual Basic,

Delphi, Visual Studio .NET, etc.

En AuraPortal se diferencian tres tipos de Web Services:

1. Web Services genéricos, proporcionados por defecto por SharePoint (plataforma sobre la que está

desarrollada gran parte de AuraPortal) y disponibles para leer o escribir la mayoría de información

de AuraPortal.

2. Web Services de Sistema de AuraPortal, diseñados para facilitar propósitos concretos y disponi-

bles en la instalación por defecto. Están disponibles los siguientes, con los que se puede realizar la

mayoría de acciones que un usuario puede hacer desde el interface de AuraPortal:

AuraPortalProcesos: Web Service para manejar datos de Procesos de AuraPortal. Con él se

pueden obtener todos los datos de los Procesos, Iniciar Procesos, Ingresar documentos, etc.

(Ver Web Services Personalizados).

AuraPortalTareas: Web Service para manejar Tareas Libres de AuraPortal, por ejemplo Leer,

Crear, Enviar, Modificar, Terminar y Eliminar Tareas.

AuraPortalDoc: Web Service para manejar documentos y Anexos en AuraPortal, por ejemplo,

ingresar, enlazar y leer documentos, en Bibliotecas, Fichas y Anexos de cualquier elemento de

todas las Familias de AuraPortal. Este Web Service es, por ejemplo, el que utiliza AuraPortal In-

gresador (Uploader), programa incluido en las Utilidades de AuraPortal que facilita mucho el

ingreso de documentos y correos en AuraPortal desde Windows, Word, Excel y Outlook.

AuraPortalFamilias: Web Service para manejar elementos del resto de familias de AuraPortal

(Empleados, Cuentas, Proyectos, Ítems y Áreas). Con este Web Service se pueden Crear, Ver,

Modificar o Eliminar cualquier elemento.

AccionBell: Web Service que utiliza el programa Avisador (Warning Bell).

AuraPortalDiccionarioTerminos: Enfocado al manejo de los Campos de Selección Simple.

Permite Ver los términos y sus opciones, Crear nuevas opciones, Modificar o Eliminar

opciones existentes y Eliminar términos.

3. Servicios Web Personalizados de AuraPortal: Tanto los Formularios de Mensajes de Inicio de

Proceso como los de Eventos de Mensaje Intermedios que se diseñan a medida en los Procesos

de AuraPortal, pueden ser publicados como Web Services para ser invocados desde otros Procesos

de AuraPortal o desde programas externos.

La biblioteca de Programas, en el Portal de Partners, incluye ejemplos, con código fuente incluido, de pro-

gramas diseñados con Visual Basic 6 y .NET, sobre cómo realizar programas que se conecten a Web Services

de AuraPortal.


Para más información sobre Servicios Web, consultar sobre Servicios Web.

A1.5. Adaptadores

AuraPortal dispone de un sistema, llamado AuraPortal Adapters Server, con el que se pueden consultar o

modificar datos alojados en Bases de Datos externas (ERP, CRM, …) desde las tareas de los Procesos de Au-

raPortal. El esquema de utilización de AuraPortal Adapters Server es el siguiente:

Por un lado se instala AuraPortal Adapters Server en el servidor de la base de datos externa, o bien en un

ordenador en su misma red local, y se establecen los correspondientes Connectors (conexiones ODBC) a los

datos que se desea sean utilizados desde AuraPortal, por ejemplo, el Cliente, su Saldo y sus Facturas pen-

dientes de pago. Estos datos serán automáticamente publicados en un Web Service para que AuraPortal

pueda utilizarlos a través de Internet o de la red local.

Una vez configurado AuraPortal Adapters Server, desde AuraPortal se establece la conexión con su Web

Service para que desde el Diccionario de Términos se puedan crear los términos adecuados, en este ejemplo

un Prefijo para el ‘Cliente’ y los correspondientes Sufijos para su ‘Saldo’ y sus ‘Facturas pendientes de pago’.

Así, estos términos se podrán utilizar en Procesos de AuraPortal de varias maneras, como por ejemplo, mos-

trarlos en Formularios de los Procesos de AuraPortal, para que el ejecutor de la tarea pueda consultarlos (o

modificarlos, dependiendo de la configuración). En este ejemplo, el ejecutor podría ver en AuraPortal, las

facturas pendientes de pago de un determinado cliente, datos que se obtendrían directamente del ERP.

Otra funcionalidad importante de AuraPortal Adapters Server, es que los datos provenientes de Bases de

Datos externas pueden ser utilizados por las Compuertas de los Procesos de AuraPortal para tomar decisio-

nes, orientando la corriente del flujo del Proceso en un sentido u otro dependiendo de su valor. Por ejemplo,

que si el saldo del cliente que realiza un pedido es positivo se acepte el pedido directamente, pero que si

fuera negativo se requiera una aprobación específica del Director Comercial.

Para más información consultar la documentación sobre Adapters Server.

A1.6. Mensajes

En los Procesos, los Objetos que entienden los Mensajes son los Eventos de Mensaje. Estos pueden ser, bien

Eventos de Inicio, que se encargan de iniciar Procesos, o bien Eventos Intermedios, en cuyo caso, dentro del

Proceso ya en marcha, detienen la corriente a la espera de la llegada de un Mensaje.

Cuando aparece un Mensaje, bien porque ha sido generado desde dentro de la empresa o porque llega del

exterior, queda depositado en una bandeja que es consultada por el Orquestador de Procesos y éste activa

los Eventos de Mensaje que tengan relación con dicho Mensaje.


Formularios

Todo Mensaje que se relaciona con los Procesos proviene de un Formulario de Mensajes. Los Formularios

(vacíos) se crean y se guardan. Con posterioridad son accesibles por los usuarios para crear Mensajes, bien

desde el propio marco de AuraPortal o bien desde la pantalla de los distintos usuarios cuando el Motor de

un Proceso produce su aparición en una ventana de Tarea Personal dentro del workflow que genera el pro-

pio Proceso.

A1.7. Familias

Toda la estructura de AuraPortal descansa en la convivencia entrelazada de las familias de elementos, que

se muestran en la tabla siguiente:

Empleados Cuentas

Reglas Ítems

Procesos Proyectos

Tareas Libres Áreas

Documentos Familias Propias

Nota.

Las Familias Propias, a diferencia del resto (Familias de Sistema), se crean y dise-

ñan en AuraPortal según las necesidades particulares de cada organización. Son

por lo tanto Propias de cada instalación, de ahí su nombre, y se pueden crear el

número que se desee, ilimitadamente.

En cada familia, los Elementos se agrupan en Clases, las cuales se alojan en las Ramas jerarquizadas de su

Árbol. Todos son definidos por los usuarios de AuraPortal. Además, cada Familia permite la adición de

Anexos definidos por el usuario que permiten albergar cualquier información de interés para una empresa

particular y que no se haya contemplado de origen en la aplicación.

Familia: Empleados.

Los Empleados no se agrupan en clases como ocurre con las demás familias, sino que están directamente

ligados a su árbol.


Cada empleado tiene una ficha en donde figuran sus datos de carácter general. Desde esa ficha se puede

acceder a otra información dependiendo del contexto y los permisos del peticionario.

En AuraPortal cada empleado tiene dos naturalezas: una por el cargo que ocupa en la empresa y otra que

representa su persona física.

Esta doble naturaleza permite segregar las Tareas que dependen de su cargo de las que dependen de su

persona (o sea, la ejecución de un trabajo está relacionado con el cargo en la empresa, mientras que una cita

con el médico tiene carácter personal). Cuando una persona cambia de cargo en la empresa, AuraPortal

automáticamente traslada las Tareas pendientes que están enlazadas al cargo al Workflow de la nueva per-

sona en este cargo, pero deja las Tareas personales pendientes a pesar del cambio.


Familia: Reglas.

Una descripción detallada de la gestión de esta familia se encuentra en la documentación sobre Reglas de

Negocio. Aquí se presentan los conceptos básicos para facilitar su entendimiento.

Las Reglas de Negocio, o más sucintamente Reglas, son contenidos informativos individuales que permiten

ser definidos, delimitados y expresados de forma inteligible y que en su conjunto componen el marco es-

tructural, la política, la estrategia y la operativa de una empresa u organización. Por tanto abarcan todo lo

que la empresa quiera almacenar como normas y procedimientos operativos.

En AuraPortal las Reglas de Negocio se gestionan como una familia más, junto con las restantes familias. La

familia de Reglas goza por tanto de un tratamiento estructurado en Clases y Ramas de Árbol que la dota de

una potente mecánica de creación, edición, clasificación, búsqueda filtrada, recuperación, modificación, exhi-

bición, difusión, impresión, etc. de sus elementos.

En el sistema AuraPortal las Reglas de Negocio se dividen en dos grupos atendiendo a su comportamiento:

Textual y Mecánica.

Comportamiento Textual. Contienen texto explicativo con aclaraciones o instrucciones a seguir.

Cuando se utilizan en los Procesos, las Reglas Textuales aparecen como Instrucciones en la ventana

(pantalla) de ejecución de las Tareas Personales.

Comportamiento Mecánico. Estas Reglas son aplicables sin intervención humana y por tanto su

aplicación se realiza en los Procesos a través de Tareas de Sistema o para la toma automática de

decisiones en las Compuertas Divergentes. Son: de Asignación, Cálculo e Inferencia.

Reglas Textuales

Se crean mediante el potente Editor AuraPortal que permite, además de múltiples fuentes y estilos, todo tipo

de inserciones: Tablas, Imágenes, Clips de Flash, Vídeos, Emoticones, etc.

Durante la marcha normal de un Proceso, el contenido de las Reglas aparecerá en la pantalla del Ejecutor de

la Tarea indicando las instrucciones para la ejecución de la misma. Cualquier modificación futura en el con-

tenido de la Regla se reflejará en dichas instrucciones instantánea y automáticamente pero sin afectar al

diseño (Modelización) del Proceso. Ejemplo de Regla Textual:


Reglas Mecánicas

Como se ha dicho pueden ser de Asignación, Cálculo e Inferencia. Como indicación somera se muestra a

continuación un ejemplo de Regla de Inferencia.

Ejemplo

Supongamos una Cadena de Tiendas que controla tres tipos de tiendas: Propias, Franquiciadas y Abandera-

das. Diariamente se reciben muchos pedidos que deben ser analizados para determinar si deben ser servi-

dos.

Si la tienda es Propia, son siempre servidos.

Si las tiendas tienen Impagados, no deben ser servidos. Naturalmente, solo se aplica a las Franqui-

ciadas y Abanderadas.

Si las tiendas Franquiciadas y Abanderadas NO tienen Impagados, podrán ser servidos o quedarse

en espera en función de una Clave de Clasificación Interna y del Riesgo Actual que tenga la tienda.


En el ejemplo de la figura, en la Regla de Inferencia RI_CRM_54 se han considerado 4 Criterios: Tipo de

Tienda, Clave de Clasificación Interna, Riesgo Actual e Impagados, que son campos que se encuentran en la

Ficha de la tienda (Tipo y Clasificación) y en la aplicación financiera de la entidad (Riesgo Actual e Impaga-

dos).

Luego, simplemente, se han dado a cada Criterio unos Valores y, por último, en la Tabla de Calificaciones,

se han creado las combinaciones de los valores que dan lugar a los valores del Resultado.

Esta Regla de Inferencia se aplica a una Tarea de Sistema que se coloca en el Diagrama del Proceso inme-

diatamente después de la Solicitud de Pedido que realiza cada tienda desde su propia oficina, y que ejecuta

la Regla de forma automática.

De esta forma, cuando una tienda realiza un pedido, la corriente llega a la Tarea de Sistema realizará de

forma automática el análisis para determinar si los Pedidos deben ser aceptados o bien rechazados, en fun-

ción de la Regla.

Si el pedido es aceptado, continuará por el flujo hasta su completa resolución.

Si no es aceptado definitivamente, el propio sistema envía una notificación a la tienda con los moti-

vos, etc.

Si es dudoso, el sistema envía una tarea al responsable para que tome una decisión.


Familia: Procesos

Esta Familia contiene Clases de Procesos, alojados en las ramas del Árbol de la Familia. Los Procesos son

generados automáticamente cuando un Evento Inicio es disparado dentro de una Clase de Procesos. Cada

Proceso es identificado por su Referencia que también contiene la identificación de la Clase de Procesos a lo

cual pertenece.

Familia: Tareas Libres

Las Tareas Libres que constituyen el llamado Workflow Ad-hoc (llamado también libre). Estas Tareas no las

genera automáticamente el Motor del Proceso como ocurre con las que figuran en los Modelos sino que las

puede crear libremente cualquier usuario en cualquier momento para establecer una línea de comunicación

extraordinariamente rica con otros usuarios Internos (Empleados).

Estas Tareas contienen registros históricos de comentarios y enlaces con las demás familias, además de un

potente mecanismo de acciones (Enviar, Responder, Reclamar, Reasignar, etc.)

AuraPortal también permite disponer de un workflow libre desde dentro de cualquier Tarea de Proceso.

Estas tareas se llaman Tareas Integradas y se pueden crear desde una determinada Tarea de Proceso, do-

tando así a los Procesos de un mecanismo adicional de consultas para situaciones que lo requieran, bien por

el carácter del trabajo a realizar previsto o bien para manejar excepciones y emergencias de cualquier índole.

La utilidad de este mecanismo es extraordinaria y representa un complemento muy valioso que resuelve

fácilmente muchas limitaciones existentes en otras concepciones de BPM.

Familia: Documentos

Esta familia alberga toda la Gestión Documental de la Empresa.

Su explicación completa y detallada puede encontrarse en la documentación sobre Gestión Documental.

Baste aquí decir que esta Gestión Documental está basada en Microsoft SharePoint y mejorada con algunas

funciones para facilitar su manejo y ampliar sus posibilidades de enlace con otros elementos informativos

hechos por AuraPortal. Algunas funciones y aspectos de la misma se citan a continuación.

Creación automática de bibliotecas. La creación y ubicación automática de bibliotecas es una he-

rramienta exclusiva de AuraPortal.

Gran capacidad. Soporta un número prácticamente ilimitado de documentos: hasta 2 millones de

documentos por biblioteca y hasta 1.000 bibliotecas. Todo ello en un solo Sitio. Si fuese necesario

se pueden crear incluso miles de Sitios dentro de AuraPortal.


Creación, revisión e ingreso de documentos. Los documentos se pueden crear con cualquier sis-

tema. Su incorporación a las correspondientes bibliotecas es inmediata.

Multitud de formatos. Los documentos no han de ser necesariamente textos e imágenes. Se ma-

nejan igualmente las plantillas, formularios, listas, tablas, etc.

Revisión y Aprobación. Se pueden establecer circuitos de revisión y aprobación, tanto simples co-

mo múltiples y tanto en serie como en paralelo. Los sistemas que proporciona AuraPortal para esta

circulación son innovadores y ofrecen singulares ventajas.

Visados con firmas digitales en los documentos. Incorpora la mecánica de la firma digital.

Archivística. El archivo de documentos en las bibliotecas permite múltiples clasificaciones, tanto

preconfiguradas como definibles por el usuario. Ello permite utilizar diversas Vistas para localizar al

instante documentos buscados en función de características diferenciadores utilizadas.

Enlaces. Tanto los documentos a título individual como las bibliotecas se pueden enlazar con cual-

quier elemento de las Familias de AuraPortal como Procesos, Tareas, Otros Documentos, Proyectos,

Cuentas, Reglas de Negocio, Empleados, Ítems y Áreas.

Suscripción. Si un documento en una biblioteca sufre una modificación, el sistema envía un aviso

de manera automática a los usuarios incluidos en la lista de suscriptores de esa biblioteca para que

puedan revisar el nuevo documento.

Versionado. Existe un seguimiento automático de versiones si se desea.

Discusiones. También es posible mantener discusiones sobre un documento entre varios usuarios

mientras se elabora.

Búsquedas. Todo tipo de búsquedas: Por nombre o parte de él, por campos o características (autor,

fecha de creación o modificación, destinatario, tamaño, etc.) por contenido (basta indicar la porción

de texto buscada) y mediante filtrados personalizados definidos por el usuario.

Activación y vigilancia. Hay un sistema de vigilancia y registro de las acciones y responsabilidades

de los empleados involucrados en los procedimientos.

Histórico de tareas. Aunque este es una característica de las Tareas, es usada frecuentemente en el

manejo de documentos y permite conocer todo lo que ha ocurrido con cada documento aunque

esa información no figure en el texto ni características del documento.

Seguridad. El acceso a las bibliotecas está controlado y restringido a los usuarios que exhiban los

correspondientes permisos. Se establecen 5 niveles de acceso (pueden ampliarse o reducirse): Lec-

tor, Agregador, Editor, Aprobador y Responsable.

Sin embargo, la verdadera potencia, flexibilidad y sencillez de manejo de la Gestión Documental de AuraPor-

tal proviene de la sinergia que desencadena su integración con las Tareas, Empleados, Cuentas (Cliente,

Proveedor, partner, etc.), Áreas, Proyectos o Ítems (materiales e inmateriales), que son los elementos infor-

mativos que se gestionan en AuraPortal.

En el día a día, los flujos de trabajo (tareas) se encargarán de controlar las actividades que se realizan en la

empresa y, por tanto, serán los portadores naturales de la información necesaria para su óptima realización.

Como al diseñar una Tarea Personal de un determinado Proceso ya se habrá tenido en cuenta los documen-

tos que deben crearse y consultarse:

La mayoría de los documentos se crearán de forma automática mediante la utilidad de Docu-

mentos Base, que rellena una plantilla con los datos de los Procesos.


La mayoría de los documentos no deberán ser buscados, sino que estarán a disposición del ejecu-

tor de la tarea para su consulta, modificación o eliminación.

Familia: Cuentas

Cuentas son las personas jurídicas y físicas externas que mantienen relaciones comerciales o de otra índole

con la Entidad. Son cuentas típicas: Clientes, Proveedores, Agentes, Colaboradores, Organismos del Estado,

etc. Véase la imagen siguiente.

Lo mismo que las otras Familias, los registros de información de cada Cuenta pueden ser ampliados con

campos definidos por el usuario en los Anexos.

Familia: Ítems

Se llama Ítem a un artículo, un producto, una parte del inmovilizado, un recurso, un concepto de coste, etc.

Los Ítems pueden enlazarse con elementos de otras Familias, lo cual permite controlar su uso y destino y

efectuar análisis muy importantes, como los artículos que se están vendiendo a un cliente, los recursos em-

presariales (coches, PC’s, etc.) en manos de un empleado, los costes asociados a un proyecto, etc. La ficha de

un Ítem tiene el siguiente aspecto.


Hay que recordar que, lo mismo que otras Familias, la información registrado de cada Área puede ser am-

pliada usando los campos que define el usuario dentro de Anexos.

Familia: Proyectos

El concepto de Proyecto es muy evidente. Cualquier destino al que se dedican recursos empresariales se

puede calificar como Proyecto. Pero no solo eso, los Expedientes y los Centros de Coste son típicamente

Proyectos y pueden gestionarse con los recursos operativos que ofrece esta Familia de Proyectos.


Puesto que las actividades pueden llevar asociados costes e ingresos reales (que se imputan mediante la

opción Coste / Ingreso que existe en las Tareas) esta información económica se puede trasladar a los Pro-

yectos o centros de coste e ingreso. El valor acumulado de los costes e ingresos de las tareas enlazadas a un

proyecto se puede comparar con el presupuesto de coste (partida presupuestaria) o ingreso asignado ini-

cialmente a dicho proyecto y comprobar desviaciones y márgenes de maniobra. La ficha de un Proyecto

tiene el siguiente aspecto.

Familia: Áreas

Áreas son los Departamentos, Centros de Producción o simplemente conceptos de homogeneidad o simili-

tud. Así como los Proyectos representan generalmente los destinos o fines de las Tareas, las Áreas identifican

los orígenes de los recursos dedicados a los mismos. La ficha de Área tiene es la siguiente.

Familias Propias

Las Familias Propias se crean y diseñan en AuraPortal según las necesidades particulares de cada organiza-

ción. Son por lo tanto Propias de cada instalación, de ahí su nombre, y se pueden crear el número que se

desee, ilimitadamente.

La creación de Familias Propias se realiza desde Estructura – FAMILIAS – Familias Propias – Árbol y Clases.

En la siguiente imagen puede verse la ventana de creación de la Familia Propia Content Management, ne-

cesaria para el Módulo Gestión de Contenido.


Las opciones de configuración son:

- Árbol y Clases. De forma muy similar a las Familias de Sistema.

- Campos en Ficha. Permite agregar campos del Diccionario a la Ficha, que es el almacén de datos de

los elementos de la Familia.

- Formularios. Permite diseñar múltiples Formularios Dinámicos con campos de la Ficha para ser utili-

zados desde las diferentes opciones de AuraPortal.

- Configuración Grid. Permite diseñar los Filtros y Columnas del Grid para buscar elementos de la Fa-

milia.

- Campos con contenido exclusivo. Permite determinar qué campos de la Ficha tendrán un valor ex-

clusivo que no se pueda repetir en otros elementos de la misma Familia.

Consultar sobre Familias Propias para mayor detalle las diferencias que existen con las Familias de Sistema.

APÉNDICE A2 - SEGURIDAD: CONTROL DE ACCESOS

Los controles de acceso a las diferentes partes de la aplicación en función de sus características y de los

permisos ostentados por los visitantes, operan en tres frentes:

Prefiltros de Familia

Autorizaciones

Recintos Seguros

A2.1. Prefiltros de Familia

Los Prefiltros de Familia controlan la presentación de datos que verá un visitante en un Formulario de Men-

saje o de Tarea cuando tenga que seleccionar una o más opciones relativas a un campo de Familia. Estos

filtros restringen los elementos que pueden ser seleccionados, evitando así que un visitante pueda seleccio-

nar elementos ajenos a su jurisdicción.

A diferencia de las Autorizaciones y los Recintos Seguros que se explican después, los Prefiltros de Familia

no se relacionan directamente con permisos o roles de los visitantes. Solo están vinculados al nombre del

Término (siempre de Familia) y por tanto se determinan en el Diccionario de Términos (Estructura). Concre-


tamente al dar de alta un Término General del tipo Familia, se marca Prefiltro de Familia Sí y se determinan

las Clases y/o Elementos que deben aparecer en el filtro.

Por ejemplo, supongamos que en el Diccionario de Términos se crea el Término ‘Cliente’, como tipo de Fa-

milia en la Familia Cuentas. Una vez creado el término se le puede asociar un Prefiltro de Familia definido de

tal manera que únicamente muestre los elementos de la Clase Clientes de la Familia Cuentas (no mostrará

por ejemplo los elementos de la clase Proveedores). Esto significa que cuando el ejecutor del Formulario se

encuentre con el campo de nombre Cliente, al pulsar el ojo buscador solo verá la Familia de Cuentas y den-

tro de ella, solo aquellas cuentas que pertenecen a la Clase Clientes, lo cual es lógico ya que no tendría sen-

tido acceder a la lista completa de todas las cuentas, con la consecuente pérdida de tiempo, utilización exce-

siva de la memoria del servidor y eliminación de la privacidad en las cuentas que no han de ser accesibles.

Otro ejemplo. Supongamos que se crea en el Diccionario el término Artículos Menores dentro de la Familia

Ítems, y se le asocia a este término un Prefiltro de Familia que solo permite el paso de los ítems Artículo A,

Artículo B y Artículo C. Cuando el ejecutor del Formulario que contenga el campo Artículos Menores deba

seleccionar un artículo para dicho campo, el ojo buscador solo le mostrará, siguiendo el Prefiltro de Familia,

los artículos A,B y C mencionados para realizar su selección.

El sistema de Prefiltros de Familia permite que cada visitante distinto (es decir, cada ejecutor de Formulario)

solo tenga acceso a ver y seleccionar aquellos elementos de Familia que le están permitidos.

La seguridad se obtiene cuando, al diseñar la Clase de Procesos y una vez se sabe, para un determinado

objeto (Evento de Mensaje o Tarea) qué Rol es el que figura como ejecutor del Formulario, se coloque en el

Formulario el campo basado en el término que tiene el Prefiltro de Familia deseado para ese ejecutor.

Se pueden crear tantos Prefiltros como se desee en el mismo Término. Una vez incluido el término como

campo en un formulario, se puede aplicar uno u otro de los Prefiltros previamente diseñados, o no aplicar

ninguno. Un mismo campo puede utilizarse con un prefiltro en un formulario y con otro distinto en otro

formulario.

Nota.

Más información sobre los Prefiltros puede encontrarse en la documentación sobre

Formularios Dinámicos.

A2.2. Autorizaciones

El acceso a los elementos de las Familias de AuraPortal está controlado mediante las Autorizaciones, tal

como se describe en el Manual Administrador Delegado.

Las Autorizaciones se determinan desde la opción de Empleados: Árbol y Empleados de Estructura. Pulsando

sobre el botón Grupos se crean grupos de empleados para diversas utilidades, entre las que se encuentran la

adjudicación los permisos para Crear, Editar (modificar) y/o Ver los elementos de las familias de Emplea-

dos, Tareas Libres, Cuentas, Ítems, Proyectos y Áreas.


A2.3. Recintos Seguros

Los controles de acceso a las diferentes partes de la aplicación en función de sus características y de los

permisos ostentados por los visitantes, operan siguiendo el sistema de Control de Accesos por Recintos

Seguros que se explica en esta Monografía.

A grandes rasgos, el sistema se basa en las siguientes definiciones.

Elementos Protegidos. Son las partes de la aplicación que realizan operaciones cuyo acceso por los

usuarios se desea controlar mediante un sistema de seguridad. Los Elementos Protegidos obtienen su

protección al alojarse virtualmente en Recintos Seguros.

Recinto Seguro. Sitio que alberga virtualmente un número indeterminado de Elementos Protegidos.

Seguridad. Conjunto de requisitos de un Recinto Seguro que concede la entrada al mismo para efectuar

operaciones en los modos de LECTURA, EDICIÓN, ADICIÓN y CANCELACIÓN en los Elementos Protegi-

dos alojados en dicho sitio.

Visitante. Usuario que pretende realizar operaciones de Lectura, Edición, Adición o Cancelación en un

Elemento Protegido, lo que significa que pretende entrar en el Recinto Seguro que lo alberga. Los posi-

bles visitantes son Empleados, Usuarios Externos y Usuarios Invitados.

Permiso. Conjunto de títulos que ostenta un Visitante para vencer la Seguridad del Recinto Seguro.

Guardián. Función del sistema que se encarga de comparar la Seguridad de un Recinto Seguro con el

Permiso del Visitante y en consecuencia permitir o no la entrada y la consiguiente operación de Lectura,

Edición, Adición o Cancelación de sus Elementos Protegidos.

Cuando un Visitante pretende realizar una operación en un Elemento Protegido que se encuentra en un

Recinto Seguro, el Guardián busca dicho Recinto Seguro y después de asegurarse de que el Período de

Validez se cumple, examina el Permiso del Visitante y lo compara con la Seguridad del Recinto Segu-

ro para determinar si concede o no el acceso.

_Abierto. Recinto Seguro predeterminado sin ninguna restricción. Se aplica automáticamente a todas las

opciones para cuya configuración sea necesario un Recinto Seguro y no se haya aplicado ninguno.

Los Recintos Seguros se crean desde el Diccionario de Recintos Seguros (Estructura).

Para obtener una información completa de los Recintos Seguros, consultar la documentación sobre Recintos

Seguros.


APÉNDICE A3 - MODELIZACIÓN BPMN: OBJETOS

Los Objetos de la Modelización en el Standard BPMN 1.1 tal como se aplica en AuraPortal se enumeran y

muestran a continuación agrupados por sus categorías: Tareas, Subprocesos, Eventos y Compuertas. Tam-

bién son Objetos, aunque no intervienen en el flujo de los Procesos, los Artefactos.

A3.1. Tareas

Las Tareas realizan las actividades del Proceso, bien mediante intervención humana (Tareas Personales) o

por el sistema (Tareas de Sistema). Una Tarea puede tener varias conexiones de entrada pero solo una de

salida, excepto las Tareas con Evento Incrustado que pueden tener dos salidas: Una, la normal de la Tarea

(no siempre requerida) y la otra desde el Evento incrustado (esta última, obligatoria).

SÍMBOLO FUNCIÓN

Simples

TP.33

Tarea Personal

Tarea realizada por un Usuario del Sistema. Hay tres tipos de usuarios:

Usuarios Internos, Usuarios Externos y Usuarios Invitados. Código: TP

TS

Tarea de Sistema

Tarea realizada por el sistema. Hay una Tarea de Sistema por cada función

a realizar (Enviar una Notificación a uno o varios destinatarios, Iniciar un

Proceso, Ejecutar un Procedimiento Almacenado, etc.). Código: TS

TC.37

TPC.47

Tarea de Compensación

Tarea personal que compensa o cancela los efectos de la Tarea con Evento

de Compensación (TPC) a la que está asociada dentro de una Transacción.

(Las Transacciones son siempre Subprocesos de código SPC).

La Tarea de Compensación solo se activa cuando la Tarea con Evento de

Compensación incrustado (TPC) ha sido terminada con éxito y sin embargo

la Transacción a la que pertenece no se puede completar y ha de cancelar-

se, con lo que hay que volver atrás (compensar) las acciones ya realizadas

en la Tarea TPC. Código: TC

Con Evento Incrustado

TPM

Tarea con Evento de Mensaje Incrustado

Lleva incrustado un Evento de Mensaje. Si llega el Mensaje antes de que el

ejecutor de la Tarea la termine, ésta queda abortada y la corriente del Pro-

ceso sigue por la salida del Evento de Mensaje incrustado. Código: TPM


TPT

Tarea con Evento de Tiempo Incrustado

Lleva incrustado un Evento de Tiempo. Si el Tiempo previsto llega antes de

que el ejecutor de la Tarea la termine, ésta queda abortada y la corriente

del Proceso sigue por la salida del Evento de Tiempo incrustado.

Código: TPT

TPX.61

Tarea con Evento Múltiple Incrustado

Lleva incrustado un Evento Múltiple (combinación de Eventos de Mensaje

y de Tiempo). Si se cumple uno de los Eventos antes de que el ejecutor de

la Tarea la termine, ésta queda abortada y la corriente del Proceso sigue

por la salida del Evento Múltiple incrustado. Código: TPX

Tarea con Evento de Compensación Incrustado

Esta Tarea, que necesariamente ha de figurar dentro de una Transacción,

es decir, en la notación desarrollada de un Subproceso SPC, lleva incrusta-

do un Evento de Compensación que está asociado a una Tarea de Com-

pensación (TC). Si, una vez terminada con éxito la Tarea con Evento de

Compensación incrustado (TPC), la Transacción no se puede completar, el

sistema activa la Tarea de Compensación (TC) asociada para compensar

(cancelar o retroceder) las acciones ya realizadas en la Tarea con Evento de

Compensación (TPC) a la que está asociada. Código: TPC

A3.2. Subprocesos

Todos los Subprocesos en Notación Comprimida han de contener un hipervínculo que enlace cada uno de

ellos con el Evento de Inicio de su Notación Desarrollada correspondiente. La Notación Desarrollada, que se

ha de dibujar en otra parte del Diagrama, muestra el detalle de los objetos y conexiones del Subproceso.

SÍMBOLO FUNCIÓN

Simples

SP

Subproceso

Conjunto de Objetos (Tareas, Otros Subprocesos, Eventos y Compuertas),

que constituyen una unidad operativa independiente dentro del Proceso.

Código: SP

SC

TPC.47

Subproceso de Compensación

Subproceso que ‘compensa’ los efectos de la Tarea con Evento de Com-

pensación incrustado (TPC) a la que está asociado en una Transacción.

Solo se activa cuando la Tarea con Evento Compensación incrustado

(TPC) ha sido terminada con éxito y sin embargo la Transacción (es decir

el Subproceso SC) a la que pertenece no se puede completar y ha de

cancelarse, con lo que hay que volver atrás (compensar) mediante este

Subproceso de Compensación las acciones realizadas mediante la Tarea

TPC. Código: SC


Con Evento Incrustado

SPM

Subproceso con Evento de Mensaje Incrustado

Si llega el Mensaje definido en el Evento incrustado antes de que Subpro-

ceso finalice de forma natural, se fuerza la terminación inmediata del mis-

mo y la corriente sigue por la salida del Evento de Mensaje incrustado. La

notación Desarrollada del Subproceso ha de diseñarse de manera que

contenga la lógica necesaria para que se cumpla la mecánica descrita aquí.

Código: SPM

SPT

Subproceso con Evento de Tiempo Incrustado

Si se cumple el tiempo definido en el Evento incrustado antes de que

Subproceso finalice de forma natural, se fuerza la terminación inmediata

del mismo y la corriente sigue por la salida del Evento de Tiempo incrus-

tado. La notación Desarrollada del Subproceso ha de diseñarse de mane-

ra que contenga la lógica necesaria para que se cumpla la mecánica des-

crita aquí. Código: SPT

SPX

Subproceso con Evento Múltiple Incrustado

Lleva incrustado un Evento Múltiple que combina Eventos de Mensaje y

de Tiempo. Su funcionamiento es el mismo descrito más arriba para los

Eventos sueltos de Mensaje y de Tiempo incrustados. Código: SPX

SPC

Transacción

Este Subproceso, que siempre lleva incrustado un Evento de Compensa-

ción, comprende los Objetos y Conexiones que configuran una Transac-

ción. Si ésta no puede completarse con éxito, hay que realizar las compen-

saciones oportunas y activar la salida por el Evento de Compensación in-

crustado. Código: SPC

NOTA. La notación desarrollada de este Subproceso ha de construirse

adecuadamente para que las compensaciones tengan lugar.

A3.3. Eventos

Los Eventos controlan los arranques y detenciones de las corrientes en los Procesos.

Los Eventos de Inicio inician los Procesos o Subprocesos. (No tienen conexión de entrada y solo

una de salida).

Los Eventos Intermedios detienen la corriente en su posición hasta que se cumplan las condiciones

establecidas al definir los atributos de los mismos. (Pueden tener varias conexiones de entrada pero

solo una de salida).

Los Eventos de Fin, terminan Procesos, Subprocesos o detienen las Corrientes de hilos particulares

dentro de los Procesos y Subprocesos. Pueden tener varias conexiones de entrada pero ninguna de

salida.


Un Proceso o Subproceso puede contener varios Eventos de Fin y varios Eventos Intermedios. Pero solo

puede contener un Evento de Inicio.

SÍMBOLO FUNCIÓN

Inicio

Evento de Inicio por Mensaje

Inicia el Proceso al recibirse el Mensaje editado con el Formulario que se es-

pecifica en los atributos de este Evento o bien por una Tarea de Sistema de

Inicio de Proceso. Código: IM (Invisible)

Evento de Inicio por Tiempo

Inicia el Proceso al cumplirse el tiempo (cualquier forma de definición: Día del

mes, de la semana, fecha, hora, minuto, etc.) indicado en las condiciones es-

pecificadas para este Evento. Código: IT (Invisible).

Evento de Inicio Múltiple

Contiene cualquier combinación de Eventos de Mensaje y Tiempo. Inicia el

Proceso cuando se cumplen las condiciones especificadas para uno de los

Eventos que contiene. Código: IX (Invisible)

IS.60

Evento de Inicio de Subproceso

Evento de Inicio dentro de la Notación Desarrollada de un Subproceso. Se

activa como hipervínculo de su correspondiente Notación Comprimida cuan-

do la corriente del Proceso principal alcanza esta última. Código: IS

Intermedios

EM

Evento Intermedio de Mensaje

Detiene la corriente hasta que se reciba el Mensaje editado con el Formulario

que se ha especificado para este Evento o mediante una Tarea de Sistema de

activación de Mensaje, generalmente desde otro Proceso. Código: EM

ET

Evento Intermedio de Tiempo

Detiene la corriente de su hilo hasta que se cumpla el tiempo que se ha espe-

cificado para este Evento. Código: ET

EX

Evento Intermedio Múltiple

Contiene una combinación de Eventos de Mensaje y Tiempo. Detiene la co-

rriente en su hilo hasta que se cumpla uno de los Eventos. Código: EX


EL

Evento de Enlace (Link)

Envía o recibe la corriente hacia o desde otro Enlace con el que mantiene un

hipervínculo. Código: EL

Fin

FC.32

Evento de Fin de Corriente

Indica el Fin de una Corriente de un Proceso o de un Subproceso. Cuando se

alcanza este Evento, la corriente de este hilo queda detenida definitivamente

pero las corrientes de los demás hilos siguen su curso. Código: FC

FN.73

Evento de Fin de Proceso o Subproceso

Si el evento está situado dentro del Proceso general fuerza la terminación

completa del mismo y la cancelación definitiva de todos los objetos, incluidas

las Tareas inconclusas y los Subprocesos que contiene.

Si este evento se encuentra dentro de la notación desarrollada de un Subpro-

ceso, éste queda terminado y sus objetos cancelados. Sin embargo, el Proceso

general que contiene el Subproceso sigue activo hasta alcanzar su propio Fin

de Proceso. Código: FN

Otros

Punto de Control

Toma muestras (de Tiempo y otras) en el momento en que pasa por él la co-

rriente. Se utilizan en la Monitorización. Código: K

A3.4. Compuertas

Las Compuertas redirigen las corrientes del Proceso desviándolas a unos u otros hilos.

Las Compuertas Divergentes (solo admiten una Entrada), redirigen la corriente de su hilo de Entrada a uno

varios de sus hilos de Salida. Las Compuertas Convergentes (solo admiten una Salida), agrupan todas o

algunas de las corrientes de sus hilos de Entrada en su único hilo de Salida.


SÍMBOLO FUNCIÓN

Divergentes

Compuerta Divergente Exclusiva (XOR)

Tiene una Entrada y varias Salidas. Las Salidas han de estar numeradas para

establecer el orden en el que han de ser examinadas, ya que la primera que

cumpla las condiciones establecidas será la que conduzca la corriente del Pro-

ceso. Las demás Salidas serán inhabilitadas. Código: DX

Compuerta Divergente Inclusiva (OR)

Tiene una Entrada y varias Salidas de las cuales una o varias serán válidas. Las

Salidas válidas generarán corrientes paralelas en sus respectivos hilos y los

demás hilos serán deshabilitados (no contendrán corriente). Código: DO

Compuerta Divergente Paralela (AND)

Tiene una Entrada y varias Salidas siendo todas ellas válidas. Cada Salida gene-

rará corriente paralela en su respectivo hilo. Código: DA

Convergentes

Compuerta Convergente Exclusiva (XOR)

Tiene varias Entradas y una Salida. Cuando se produce la primera Entrada con-

duce la corriente a la Salida y las demás Entradas quedan invalidadas. Código:

CX

Compuerta Convergente Inclusiva (OR)

Tiene varias Entradas y una Salida. La Compuerta, que conoce cuales de los

hilos de Entrada llevan corriente y cuales no, (depende de lo ocurrido en el

Proceso aguas arriba), espera a que lleguen todas las que llevan corriente para

permitir la única Salida.

Código: CO

Compuerta Convergente Paralela (AND)

Tiene varias Entradas y una Salida. Todas las Entradas han de ser de hilos con

corriente pues la Compuerta esperará a que se hayan producido todas las En-

tradas para permitir la única Salida.

Código: CA


Colector (OR)

Esta Compuerta está siempre abierta. Su misión es redirigir cualquier Entrada a

su única Salida en el momento en que pasa por ella la corriente y puede utili-

zarse para simplificar la lectura del Diagrama. Su uso es necesario como con-

centrador previo cuando han de llegar varios hilos a un Objeto que solo acepta

una Entrada (como sucede con las Compuertas Divergentes DX y DO).

Código: CL

A3.5. Compuertas (Notación Especial)

Esta notación es aplicable a todas las Compuertas cuando el número de Salidas en las Divergentes o de En-

tradas en las Convergentes es mayor que 3. Como se aprecia en la figura pueden utilizarse hasta 7 Entra-

das/Salidas y, desde cada una de ellas, pueden Entrar/Salir todos los hilos de corriente que se desee. Los

círculos se han incluido para significar cualquier objeto, sea Tarea, Subproceso, Evento o Compuerta.


A3.6. Artefactos

Los Artefactos son elementos complementarios que ayudan a mejorar la comprensión del Diagrama. Su

función es ilustrativa y no ejecutiva, por tanto el Motor no los tiene en cuenta al ejecutar los Procesos.

Además de los símbolos que se describen en la tabla siguiente, se puede insertar (pegar) en el lienzo cual-

quier imagen creada externamente

Nota.

Los símbolos de la imagen siguiente son los que aparecen en AuraPortal Helium Mode-

ler y pueden variar ligeramente en el caso del Modeler de Visio.


FUNCIÓN

Bandas (1)

Se utilizan para enmarcar partes del diagrama, por ejemplo el conjunto de objetos que afectan a un deter-

minado departamento, etc.

Reglas de Negocio (2)

Permite insertar los iconos representativos de las Reglas de cualquier naturaleza (Textual, Asignación, Cálculo

e Inferencia). No tiene influencia en la ejecución del Proceso.

Adaptador (3)

Conecta con aplicaciones externas ERP, CRM, etc. para leer, importar o exportar información desde el Proce-

so. Las conexiones con este Objeto se muestran mediante líneas de trazos.

Título (4)

Inserta un título enmarcado en una pequeña orla.

Anotación (5)

Texto explicativo en semi-cuadro con puntero. Se puede conectar a otro Objeto por el extremo del puntero.

Texto en Post-it (6)

Texto que se muestra como si se tratase de una nota post-it. Las dimensiones del cuadro se regulan a volun-

tad. Puede conectarse a otros ojetos si se desea.

Texto Libre (7)

Permite la inserción de texto libre en el Modelo. Como en los demás textos de los Artefactos, tanto el tipo de

letra como su tamaño y atributos pueden cambiarse. No puede conectarse con otros Objetos.

Texto en Cuadro (8)

Texto que aparece dentro de un cuadro con fondo sólido del color deseado. La anchura del cuadro se elige y

la altura se adapta automáticamente al tamaño del texto contenido. Puede conectarse a otros objetos si se

desea.

Diálogo (9)

Inserta una figura sin relleno, solo el borde, redonda que puede enmarcar texto u otros artefactos.

Logo AuraPortal (10)

Inserta el logo corporativo del programa.

Tiralíneas (11)

Permite trazar líneas rectas dentro del Modelo. Se trata de líneas auxiliares independientes sin posible cone-

xión con Objetos.

introduccion abp ms

Technology