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 | info@auraportal.com | Skype: AuraPortal | Tel: +34 962 954 497 |
Internacional: +18 572 390 070

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:

Introduccion abp ms

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (10)

Similar a Introduccion abp ms

Similar a Introduccion abp ms (20)

Último

Último (15)

Introduccion abp ms