Introducción
El segundo paso del Asistente de Bizagi es definir los datos que el proceso requiere para su
ejecución.
Bizagi provee un asistente amigable para construir un modelo estructurado de datos con
entidades definidas y sus correspondientes atributos. A diferencia de otros BPMs usted puede
estructurar la información del negocio utilizando un ambiente gráfico y lógico. El modelo de Datos
se crea una sola vez y se usa durante todo el proceso. El modelo de Datos puede ser reutilizado
en todos los procesos creados e el mismo proyecto sin restricciones.
Es muy importante que la información en su proyecto este organizada correctamente para lograr
alcanzar los objetivos del proceso.
Para proporcionar una estructura organizada y coherente, Bizagi provee cuatro tipos
de Entidades y cuatro tipos de Relaciones para construir su modelo de datos.
Entidades
•Entidades son objetos reales o abstractos (personas, lugares, eventos, etc.) que pueden ser
identificados de forma única y tiene información de interés para el negocio almacenada en el
sistema. Las entidades se nombran normalmente con sustantivos. Por ejemplo, cliente, Ciudad,
Compañía, Factura, Carro.
•Las entidades tienen Atributos. Estos son las propiedades que describen cada entidad. Por
ejemplo un cliente tiene un nombre, un número de seguridad industrial y una edad.
•Las entidades siempre deben tener un atributo o un conjunto de atributos por lo que pueden
ser identificado de forma única. Por ejemplo, un Cliente tiene un único número de seguridad
social. Ningún otro registro puede tener el mismo valor.
•Bizagi genera automáticamente para cada fila un único número consecutivo que identifica cada
registro de la entidad. Este identificador es llamado Surrogate Key. No tiene ninguna conexión
con los datos de los atributos en la fila, simplemente marca cada una de ellas como única.
Relaciones
•Las relaciones capturan cómo las entidades se relacionan entre sí a través de verbos. Por ejemplo:
Un Cliente tiene un carro. Una compañía está ubicada en una ciudad. Un cliente tiene un género.
•Con cada relación, una llave foránea es creada automáticamente. Una llave foránea es un atributo
que contiene la llave primaria de otra entidad.
Opciones del modelo de datos
El asistente del modelo de datos tiene varias opciones que pueden ayudar a los usuarios
avanzados a modelar más rápido.
NOMBRE DEL GRUPO OPCIONES DESCRIPCIÓN
•Usted no puede borrar una entidad desde el Asistente del Modelo de Datos. Esta acción debe realizarse desde la vista de Experto.
•Al borrar una Colección se borrará la relación. Sin embargo el atributo relacionado que queda en la entidad Muchos no se borra.
Si se desea, se debe ir a la entidad muchos y borrar este atributo relacionado.
Tipos de entidades
Introducción
Cuando se crea el modelo de datos, nótese que Bizagi presenta cuatro tipos diferentes de
entidades: maestras, paramétricas, del sistema y de aplicación.
Cada uno de estos cuatro tipos de entidades está orientado a un propósito específico, de manera
que usted tenga la posibilidad de aprovechar en sus procesos todas las capacidades poderosas
de las interfaces de usuario de Bizagi y otros aspectos de optimización.
Considere las características de cada uno de estos tipos, de manera que usted pueda diseñar de
la mejor manera su modelo de datos teniendo en cuenta aspectos importantes tales como: la
funcionalidad de sus interfaces de usuario, el rendimiento y usabilidad, o incluso aspectos
generales del mantenimiento de la solución y de reusabilidad.
1. Entidades Maestras
Las Entidades Maestras en Bizagi Studio se muestran de color azul.
En este tipo de entidad, Bizagi almacenará la información que se relaciona directamente a los
casos de los procesos, tales como: una fecha de la solicitud, el detalle de un cliente de la solicitud,
o cualquier cantidad de productos que están relacionados a esa solicitud.
Por lo tanto, ejemplos típicos de Entidades Maestras son: Cliente, Solicitud, o Producto (aquellas
cuya información usualmente es digitada en campos, o buscada y seleccionada a través de cajas
de textos con función de autocompletar, o con información ingresada por medio de múltiples
registros de una tabla).
La información es almacenada en Entidades Maestras de acuerdo a los datos que van ingresando
los usuarios finales, en la medida en que el proceso va avanzando (puede tomar este tipo de
entidades como entidades donde van los registros transaccionales).
La Entidad de Proceso que se define para cada uno de sus procesos es una Entidad de tipo
Maestra, y esta entidad en particular es el punto de entrada de los datos de negocio que se
conectan a su vez a otras entidades de su modelo de datos.
Vea más información sobre la Entidad de proceso.
2. Entidades Paramétricas
Las Entidades Paramétricas en Bizagi Studio se muestran de color verde.
En este tipo de entidad, Bizagi almacenará una lista de valores pre definidos (valores paramétricos
de su negocio), tales como: la ciudad donde se origina una solicitud, el género de una persona, o
el tipo o clasificación de un cliente.
Por lo tanto, ejemplos típicos de Entidades Paramétricas son: Ciudad, Género, o Tipo de cliente
(aquellas cuyos registros son usualmente seleccionados por medio de un combo o lista
desplegable).
En las Entidades Paramétricas se encontrarán valores que son independientes de un caso de
proceso específico (no es información transaccional), pero que si podrán estar relacionados a
diversos casos.
Las Entidades Paramétricas en particular, tienen estas características importantes:
•Usted tiene la posibilidad de clasificarlas en 2 grupos: Administrables en producción, y no
administrables en producción (se administran en desarrollo en vez).
Cuando son administrables en producción, los valores de esa entidad deberán ser ingresados y
modificados directamente sobre el ambiente de producción, dado que estos valores no serán
publicados desde un ambiente de desarrollo (salvo únicamente para el primer deployment en un
cargue inicial).
Cuando no son administrables en producción, los valores de esa entidad serán llevados desde el
ambiente de desarrollo hacia el de producción y BIzagi no permitirá crear nuevos registros ni
modificar los existentes en el ambiente de producción.
Para mayor información acerca de este concepto y sus lineamientos, consulte Dónde administrar
las Entidades Paramétricas.
•Usted no podrá crear nuevos registros en ellas, ni modificar los existentes durante la ejecución
de los procesos.
Dado que estas entidades contienen una lista de valores pre definidos, Bizagi se apoyará en
medidas internas de optimización para la carga de estos valores.
Nuevos valores o modificaciones a los existentes, deberán realizarse como parte de las tareas de
su administración del sistema.
3. Entidad Stakeholder
Las entidades Stakeholder se muestran en color morado en Bizagi Studio.
En este tipo de entidades, Bizagi personifica la clasificación de Stakeholders para usuarios finales,
como está definido en Diseño de Experiencia.
Por lo tanto, ejemplos típicos de entidades de Stakeholders son: Empleado, Cliente o Patrocinador
(Aquellos quienes tienen un interés en el proyecto).
Sin embargo, Bizagi presenta estas entidades para que usted tenga la posibilidad de asociarlas
desde Entidades Maestras o Paramétricas (específicamente, usando referencias a la entidad
WFUser desde Paramétricas administrables en producción, o usando referencia a las otras
Entidades del Sistema desde Paramétricas administrables desde desarrollo).
Algunas de las Entidades del Sistema que presenta Bizagi son: WFUser (donde se almacenan los
usuarios finales del proyecto), área, ubicación o rol (todas relacionadas al detalle a nivel de
organización correspondiente al usuario final).
Las entidades de aplicación son creadas de forma automática por Bizagi cuando se define la
aplicación de negocio (quedando asignadas con el nombre de la misma aplicación), de manera
que se promueva una organización estructural de los procesos.
Usted no podrá borrar estas entidades, aunque si podrá crear nuevas cuando lo necesite o
modificar sus atributos (sus atributos son principalmente referencias a las entidades de proceso).
El criterio para escoger la clasificación de una Entidad Paramétrica, depende de cómo espera
usted que esos valores se definan y se administren:
Podrán ser administrados de manera dinámica un administrador de negocio directamente en el
ambiente de producción cuando se presente ese requerimiento de negocio, o podrán ser
administrados en etapas del diseño de la solución (en el ambiente de desarrollo).
1. Administrable en el ambiente de producción
Una entidad administrable en producción significa que sus valores pueden ser ingresados y
modificados por un administrador de negocio, de manera independiente en ese ambiente de
producción.
Estos valores no son publicados desde un ambiente de desarrollo al de producción, salvo
únicamente para el primer deployment en un cargue inicial.
La administración de estos valores se lleva a cabo de manera sencilla por medio de las opciones
del Portal de trabajo, como se describe en Incluir registros en una entidad Paramétrica a través
del Portal de Trabajo.
Ejemplo
Asumamos que tenemos una Entidad Paramétrica llamada Documentos Solicitados.
Esta entidad contiene la lista de los documentos que se deben solicitar a un cliente para que éste
puede abrir una cuenta en un banco.
Esta lista de documentos requeridos puede claramente variar, teniendo la necesidad de adicionar,
modificar o deshabilitar registros (de acuerdo a regulaciones locales o requerimientos de negocio
cambiantes).
Esto implica que dicha lista puede variar con el tiempo, en momentos inesperados e intervalos de
tiempo desconocidos.
Por este motivo, esta entidad deberá ser administrable en el ambiente de producción porque se
contará con la flexibilidad de poder editar valores en cualquier momento desde las opciones del
Portal de trabajo de Bizagi.
Notas relevantes
Asegúrese de considerar estas notas al momento de decidir dónde administrar las Entidades
Paramétricas:
•Cambio en la definición.
Es posible convertir una entidad que sea administrable en el ambiente de producción para que
sea administrable en el ambiente de desarrollo, solamente si: la entidad no tiene formas asociadas
(no está en uso), no está designada para uso de la Replicación de Datos de Bizagi, no tiene
colecciones definidas, y si aún no ha sido llevada a un ambiente de producción.
Adicional a lo anterior, usted deberá garantizar que sea compatible para ser administrable en un
ambiente de desarrollo (p.e. que no tenga a su vez una relación de cualquier tipo con otra Entidad
Paramétrica que sea administrable en producción).
Para mayor información sobre la definición de compatibilidad en este aspecto, consulte la
siguiente sección sobre Decidir dónde administrar las Entidades Paramétricas.
2. Administrable en el ambiente de desarrollo
Las Entidades Paramétricas que sean administrables en desarrollo no estarán disponibles para
edición en el ambiente de producción.
Es decir, los usuarios finales podrán trabajar con la información contenida en ellas, pero no se
podrá realizar ningún cambio dinámico sin involucrar un nuevo deployment.
Este tipo de entidades son muy útiles para definir una lista finita de posibles valores que afectan
el flujo del proceso (el enrutamiento).
Estas también son utilizadas a menudo para almacenar una lista de valores pre definidos que con
certeza no cambiarán con el tiempo, como por ejemplo Género.
Las ventajas principales al utilizar este tipo de Entidad Paramétrica son: que usted optimiza la
administración de valores en su ambiente de producción. especialmente cuando identifique a
priori que no habrá necesidad de administrar estos valores (ni adicionar, modificar o deshabilitar),
y que usted tendrá mayor control sobre los valores que negocio que parametrizan el flujo de
proceso.
La administración de estos valores se lleva a cabo de manera sencilla por medio de las opciones
de Bizagi Studio, como se describe en Incluir registros en una entidad Paramétrica a través de
Bizagi Studio.
Ejemplo
Asumamos que tenemos una Entidad Paramétrica llamada Estado de solicitud.
Esta entidad contiene la lista de estados posibles de una solicitud: aprobada o rechazada.
Asumamos que de acuerdo al estado que es otorgado por un perfil revisor, el flujo de proceso
toma un camino diferente (enrutamiento) que implica realizar un conjunto de tareas diferentes
según ese estado.
De manera que: si la solicitud es aprobada, entonces el proceso continúa, mientras que si la
solicitud es rechazada, el proceso finaliza.
Dado que esta es una lista finita de valores que directamente afectan el flujo de proceso, esta
entidad deberá ser administrable en el ambiente de desarrollo.
Usted tendrá así mayor control y posibilidades sobre lo que el flujo de proceso realiza según esos
valores, y tampoco habrá mayor ventaja inmersa en la posibilidad de que un administrador de
negocio pueda acceder a estos valores.
De llegarse a necesitar un nuevo valor (por ejemplo asumamos un nuevo estado llamado "necesita
revisión"), entonces es usualmente esperado que usted realice las modificaciones a su flujo de
proceso para que sea consistente con esta nueva posibilidad de estado (p.e, que el usuario final
pueda revisar la solicitud cuando se active este estado).
Notas relevantes
Asegúrese de considerar estas notas al momento de decidir dónde administrar las Entidades
Paramétricas:
•Cambio en la definición.
Es posible convertir una entidad que sea administrable en el ambiente de desarrollo para que sea
administrable en el ambiente de producción en cualquier momento, aunque usted deberá
garantizar que ésta sea compatible para ser administrable en un ambiente de producción (p.e.
que no tenga a su vez una colección de valores de otra Entidad Paramétrica que sea administrable
en desarrollo).
Para mayor información sobre la definición de compatibilidad en este aspecto, consulte la
siguiente sección sobre Decidir dónde administrar las Entidades Paramétricas.
Para configurar esta clasificación, nótese que el asistente de creación de Entidades Paramétricas
enseña la casilla de Administrar valores en el ambiente de producción en la parte inferior de la
ventana.
Por defecto, la opción de esta configuración se encuentra sin marcar por lo que deberá planear si
desea que esa entidad sea administrable en producción:
Para una Entidad Paramétrica existente (o si no realizó acción alguna en la creación), la propiedad
podrá ser revisada desde la vista de Experto.
Una vez allí, seleccione el módulo Entidades, dé clic derecho sobre la entidad deseada y
seleccione la opción Propiedades Avanzadas.
En la pestaña de Instancia, usted podrá marcar o desmarcar esta opción de acuerdo a su criterio.
En Bizagi Studio, nótese que las Entidades Paramétricas se verán ligeramente diferentes (con una
marca adicional) dependiendo del valor de esta propiedad, como se muestra a continuación:
Los valores de la entidad serán utilizados en cualquier tipo de regla, por ejemplo una X
expresión, una asignación o incluso en formas por medio de acciones y validaciones.
Los valores de la entidad serán utilizados para definir cómo debe actuar el flujo del X
proceso (la lógica en el enrutamiento).
La entidad necesitará de una relación con la Entidad del Sistema WFUser (una referencia X
a especialmente ésta Entidad del Sistema que se administra en el ambiente de
producción).
La entidad necesitará de una relación con otras de las Entidades del Sistema como: Área, X
Rol, Ubicación, Habilidad (estas Entidades del Sistema todas tienen sus valores definidos
en el ambiente de desarrollo).
La entidad necesitará de una colección (relación 1-n) con otra Entidad Paramétrica que es X
administrada en el ambiente de desarrollo.
La entidad necesitará de una relación de cualquier tipo con otra Entidad Paramétrica que X
es administrada en el ambiente de producción.
Para una mejor ilustración de cómo podrá crear relaciones compatibles para cada una de las 4
combinaciones posibles cuando se tengan las dos clasificaciones de Entidades Paramétricas,
consulte la siguiente imagen:
Recuerde que como regla general, una Entidad Paramétrica deberá ser administrable en producción si se busca que nuevos
valores sean adicionados en ella de manera dinámica, en el ambiente de producción y de manera frecuente (si prevee esto).
Pero, ante la duda, es preferible dejar las entidades administrables en el ambiente de desarrollo.
No obstante, se recomienda revisar la definición de esta clasificación para todas las Entidades Paramétricas en conjunto con el
cliente (el concepto del dueño del proceso del departamento de negocio en su implementación) para decidir de la mejor manera.
•Incluir registros en las entidades paramétricas desde Bizagi Studio: los usuarios desarrolladores
pueden incluir registros en las entidades paramétricas desde varios sitios en Bizagi Studio.
•Incluir registros en entidades paramétricas desde el Portal de Trabajo: los usuarios finales pueden
administrar los registros de las entidades paramétricas desde el Portal de Trabajo.
Esta sección describe cómo interactuar de cuatro formas diferentes con este tipo de registros en
Bizagi Studio.
Para más información sobre cómo los usuarios finales interactúan con los registros visite
Entidades Paramétricas en el Portal de Trabajo.
Cualquiera de las siguientes opciones abrirá una ventana donde puede incluir, editar o remover
registros.
Clic en el botón Agregar en la esquina inferior derecha para incluir un nuevo registro.
Para eliminar un registro, seleccione la fila dando clic sobre el registro, luego presione la tecla
Suprimir del teclado.
Para cambiar un valor solo debe escribir en el campo que se quiere modificar.
Paso 2: Modelo de datos
Incluir registros en una entidad paramétrica a través del segundo paso del asistente.
Una vez haya incluido una entidad paramétrica en el diagrama dé clic derecho sobre ella y
seleccione la opción Valores.
Dé clic derecho sobre la entidad a modificar y seleccione la opción Editar Valores- Nombre de la
entidad.
En el editor de expresiones dé clic en la opción Modelo de Datos.
Dé clic derecho sobre la entidad paramétrica que desea modificar y seleccione la opción Modificar
Valores.
Tan pronto como el proyecto ha sido deployed, los usuarios podrán agregar registros en las entidades paramétrica a través del
Portal de trabajo solamente si la entidad es administrable en producción. De lo contrario, los valores deberán ser agregados
utilizando Bizagi Studio y luego realizar deployment a producción.
Configuración de entidades padre e hijo
Introducción
El combo dinámico se utiliza cuando se desea desplegar una lista de los valores de una Entidad
Paramétrica (Entidad Hija) filtrados automáticamente, siempre y cuando los valores dependan de
otra Entidad Paramétrica (Entidad Padre). Es decir, los valores de la entidad hija dependen del
valor seleccionado de la entidad Padre.
Normalmente, usted puede querer llegar hasta un tercer nivel de dependencia entre entidades.
Un buen ejemplo de esta situación es Ciudad – Estado – País donde se quiere mostrar las ciudades
que pertenecen a un estado y a su vez los estados que corresponden a un país especifico.
•Dos entidades paramétricas deben ser creadas para establecer la relación padre-hijo para lograr
este comportamiento.
•La entidad hija debe tener la relación con la entidad maestra que contiene la información.
1. Incluya en la entidad principal del proceso la relación con la entidad hija: Ciudad.
2. Abra el modelo de datos en el segundo paso del asistente. Dé clic derecho en la entidad Ciudad
y seleccione la opción Propiedades.
En el ultimo paso del asistente dé clic en el link Avanzado.
6. Primero agregue los valores de País. Luego incluya los valores de los Estado y relaciónelos con
País.
Finalmente incluya los valores de las ciudades y relaciónelos con Estado.
7. Cuando se incluye la entidad hija Ciudad, en la interfaz de usuario del combo dinámico, los
usuarios finales podrán ver tres entidades: País, Estado y Ciudad. Estos campos serán filtrados
automáticamente para cumplir con la opción seleccionada.
Contexto
Introducción
El contexto es el punto de inicio del modelo de dato el cual determina cómo navegará el usuario
a través de los atributos y cómo se construye la información.
Por lo cual, es muy importante observar el contexto del Proceso y los elementos que se han creado
para la elaboración de las interfaces de usuario, reglas de negocio y notificaciones.
Una de las entidades del modelo de datos es el contexto y de acuerdo a él, el usuario podrá
moverse de una entidad a otra para obtener información.
El contexto del proceso es definido por la Entidad del Proceso principal, recuerde que la Entidad
de Proceso es la entidad principal, y es el punto de inicio a través del cual los usuarios acceden al
resto del modelo de datos. El contexto depende del proceso, por lo que la información será
guardada y presentada de forma diferente para cada proceso.
Cuando se construye una expresión para validar la información de la tabla, el contexto de la regla
será la entidad de la colección o la entidad que tiene la relación de muchos en una relación uno
a muchos.
Recuerde que usted necesita una relación uno a muchos para definir una colección y crear una
tabla en la forma.
•Cuando el campo Para contiene una dirección de correo fija, o no se toma de una campo del
modelo de datos, el contexto será siempre la Entidad de proceso.
•Cuando el campo Para contiene una colección, usted podrá elegir entre la entidad del proceso
o la entidad del muchos de la relación para definirla como contexto.
Tipos de atributos
Bizagi ofrece un conjunto de tipos de atributos para que pueda crear e incluir dentro del modelo
de datos todo lo que necesite. Están separados en cuatro categorías para ayudar a encontrar
rápidamente el que usted necesita:
•Tipos básicos: los tipos más comúnmente usados. Estos atributos están listando al inicio de las
listas para su fácil acceso.
•Entidad: Da acceso a todas las entidades de Aplicación, Maestras, Paramétricas y del Sistema del
modelo. Accediendo a las entidades a través de esta categoría se crea un Atributo
Relacionado con la entidad seleccionada. Usted puede crear cualquier tipo de entidad a través de
esta opción; la relación se creará de forma automática.
•Colección: Accediendo a las entidades a través de esta opción se crea la relación Uno a
muchos con el hijo (entidad seleccionada). Usted puede crear colecciones con entidades Maestras
o de Aplicación del modelo de datos. Si necesita crear una nueva entidad, la relación será creada
automáticamente.
TIPO DE ATRIBUTO DESCRIPCIÓN
Moneda Almacena un valor entero en el formato de la moneda definida en la configuración del negocio.
Fecha-Hora Almacena un atributo que puede ser una fecha o una fecha con hora.
Almacena una cadena de texto. La longitud puede ser definida en las propiedades adicionales de
Texto
las opciones avanzadas del asistente. Por favor observe la imagen en la parte inferior.
Almacena los números decimales en formato binario de 8 bytes con 15 dígitos significativos de
Flotante
precisión.
Imagen Almacena imágenes cargadas y las muestra en el Portal de trabajo como miniaturas.
Almacena los números decimales en formato binario de 4 bytes con 7 dígitos significativos de
Real
precisión.
Entero corto Almacena un entero del siguiente rango: -32,768 a 32,767.
Todos los tipos de atributos tienen propiedades adicionales (adicionalmente al nombre visual,
nombre y tipo) que pueden ser ingresados por el usuario o pueden ser dejados en blanco.
Al final de la ventana Lista de Atributos, clic en la opción Avanzado/Ocultar. Esto mostrará una
ventana pequeña par incluir la siguiente información:
PROPIEDAD DESCRIPCIÓN
Valor por defecto Valor inicial asignado al atributo. El valor por defecto será
mostrado si no se especifica un valor para el atributo.
Longitud
Especifica la longitud máxima de caracteres que es permitida
en el campo. La longitud debe ser un número entre 1 y 1000
caracteres.
Tipo ECM Para los atributos tipo Archivo. Seleccione el tipo de contenido
para el atributo de los tipos existentes en el repositorio ECM de
la carpeta ECM.
Ya que los archivos son parte del caso, ellos deben pertenecer al modelo de datos como atributos
tipo Archivo.
Es importante recordar que en un solo atributo es posible cargar varios archivos, y pueden
contener información adicional relacionada con ellos, por ejemplo, Fecha de recepción, Fecha de
Revisión, si se ha aprobado o no, si se requiere, etc.
Por defecto, el tamaño máximo de cada uno de los archivos cargados es de 1 MB. Pero realmente
depende de la capacidad del servidor (memoria y espacio en el disco duro) de la red en la que se
carga el archivo y las necesidades del negocio. Se recomienda un tamaño de máximo 10 MB, pero
esto puede variar dependiendo de las necesidades y la configuración necesaria. La configuración
de los archivos aplica para toda la aplicación y se realiza en la Configuración de Entorno, en la
pestaña Avanzado bajo las Opciones de Upload.
C:\Bizagi\Projects\ApplicationName\WebApplication\Docs
Para cambiar la ruta por defecto, seleccione la pestaña de Configuración en Bizagi Studio y abra
la opción Entorno.
1. Seleccione la opción Avanzado del lado izquierdo de la ventana mostrada.
2. bajo la opción Uploads incluya la ruta física del directorio donde desea guardar los
documentos.
2. Al final de la ventana encontrará el tipo de contenido y las extensiones disponibles para cargar
archivos por defecto.
Para configurar alguno, dé clic en la extensión del archivo o en el tipo de contenido e ingrese el
nuevo valor.
Para borrar alguno, seleccione el tipo de contenido y dé clic en la X que encontrará al lado
derecho.
Para incluir nuevos registros, clic en el botón MÁS (+) del lado izquierdo. En la nueva línea, incluya
la nueva extensión y el programa.
Antes del primer Deployment se debe realizar la configuración de TODOS los ambientes, es decir la configuración se debe realizar
en desarrollo en Bizagi Studio. El primer deployment tomará la configuración de cada uno de los ambientes. A partir de entonces
los cambios en Configuración del entorno son locales en el entorno de producción de la consola de administración. Si usted
desea que los cambios sean permanentes y sean parte del diseño del proceso, debe realizarlos también en el ambiente de
desarrollo.
Artículos Relacionados:
Manejo de Archivos con Expresiones
Aunque dicho mecanismo es usualmente más utilizado para la integración con sistemas legado
donde no hay un diseño orientado a servicios, la siguiente imagen ilustra todos los usos para los
cuáles este mecanismo es útil.
•Virtualización de datos: Para una comunicación en ambos sentidos: tanto para obtener
información desde, como para actualizar información hacia una fuente de datos externa (lectura
y escritura).
Se realiza en momento de ejecución (por demanda).
Para mayor información, consulte Virtualización de datos.
Un aspecto importante que difiere las 2 opciones anteriores, es que cada una aplica al tipo de Entidades involucrada en particular
(entidad paramétrica o maestra, respectivamente).
Para mayor información sobre el tipo de entidades en Bizagi, consulte Tipos de entidades.
Para consultar lineamientos y mejores prácticas para el uso de Virtualización y Replicación de datos, consulte las Mejores prácticas
para la integración de datos.
Replicación de datos
Introducción
La replicación de Entidades en Bizagi es un método de integración a nivel de datos que permite
conectar el modelo de datos del proceso con una fuente de datos externa.
Asegúrese de haber leído la introducción en Conexiones con fuentes de datos externas.
Con la replicación de datos, Bizagi sincroniza sus entidades con información que reside en otras
fuentes de datos externas de forma periódica (una tarea agendada) actualizando la información
almacenada desde un sistema externo.
La actualización de la información es almacenada en tablas predefinidas con un conjunto de
valores (entidades paramétricas). Estas listas o registros se seleccionan frecuentemente desde
listas de valores desplegables (o combos).
Algunos ejemplos de información manejada a través de Replicación: Lista de ciudades y países,
tipos de productos, códigos de monedas, entre otras cosas (registros de tablas que no son
transaccionales).
Para integración de tablas transaccionales (Entidades Maestras), visite Virtualización de datos.
¿Cómo funciona?
Utilizando la Replicación de datos en Bizagi usted puede lograr:
1. Configurar un sistema externo y su proveedor de datos (conexión con fuentes de datos externa).
Bizagi ofrece un asistente gráfico para minimizar la cantidad de configuraciones necesarias.
Características importantes
•La Replicación de datos aplica para aquellos tipos de entidades de la fuente de datos externa
que son vistas en Bizagi como entidades paramétricas (entidades que tienen un conjunto
predefinido de valores para seleccionar).
•La configuración de la replicación de datos se realiza fácilmente con ayuda del asistente gráfico.
El asistente de la Replicación de datos le ayudará ha establecer el proveedor de datos de
conexión, ya sea base de datos de Oracle o SQL Server (se realiza en pocos pasos sin necesidad
de programación).
Las versiones de bases de datos soportadas por el asistente de la Replicación de datos (para
conexiones nativas de Oracle y SQL) son:
2014
2012
2008 R2
2008
2005
Oracle 12c
11g R2
11g R1
10g R2
10g R1
9i
Versiones soportadas por el asistente de Replicación (conexiones nativas).
Cuando un proyecto requiere de la Replicación de datos contra una fuente de datos diferente a
Oracle o SQL Server (por ejemplo, MySQL, archivos XML, Microsoft Access, etc), se necesita incluir
implementación personalizada y configurar la Replicación a través del Estándar de Configuración
(avanzado).
Esto significa que cualquier motor de base de datos no nombrado en la tabla anterior es
soportado para realizar Replicación en Bizagi, pero requerirá desarrollar algunos componentes
adicionales. Para más información visite Replicación Personalizada.
•Cuando se replica un entidad contra un base de datos de Oracle y se desea utilizar el Asistente, es necesario tener instalado
Oracle Data Provider para .NET.
Para más información sobre este requisito, visite Instalación de Oracle Data Provider para .NET.
•Cuando se virtualizan o replican desde bases de datos que soportan Unicode, deberá cerciorarse de que su base de datos de
Bizagi soporte Unicode igualmente.
•Cuando utilice Replicación de datos contra una base de datos Microsoft SQL Server, se recomienda asignar -1 a la
propiedad Max text Replication Size para establecer un tamaño ilimitado para los campos de texto. Esta propiedad se
encuentra en la página Avanzado (Advanced) de las propiedades de su servidor (Server Properties).
•Valores eliminados en la fuente de datos nunca se eliminan en Bizagi.
Cuando se realiza la sincronización de los valores de las entidades replicadas, Bizagi deshabilitará
aquellos registros que fueron borrados de la fuente (serán marcados, los datos no se borraran
físicamente).
Esto se realiza para conservar la integridad de los datos existentes en Bizagi.
Principales Beneficios
La replicación de datos en una solución Bizagi promueve:
•Reusabilidad ya que permite a los procesos ser integrados con fuentes de datos existentes
(aplicaciones) y sistemas heredados (legacy systems).
Esto es un requerimiento frecuente cuando se utilizan sistemas heredados que no tienen
Arquitectura Orientada al Servicio diseñada para integración a un nivel alto (integración a nivel
de datos es estrictamente requerido).
•La distribución de trabajo a través de los miembros del proyecto se deja en claro.
El trabajo es separado de acuerdo a los diferentes roles: el analista del negocio diseña y modela
los procesos y las reglas de negocio, mientras que el personal de IT configura e implementa el
modelo de datos e integra la solución.
•Ofrece al analista del negocio un modelo de datos claro para el manejo e intercambio de
información
Los analistas del negocio pueden disponer de los datos que utiliza el proceso como si estuvieran
almacenados en un repositorio de Bizagi (es decir, como datos locales).
De esa manera, ellos no tienen que entender la complejidad asociada con la ubicación real de los
datos.
•Los flujos de proceso no necesitan incluir ninguna actividad técnica para realizar la integración
(por ejemplo acceder a datos de otra fuente).
Los procesos de la organización continúan siendo legibles o entendibles para todos los
involucrados del negocio.
Las reglas de negocio no tienen que tratar con el acceso a datos o configuración de mapeo de
datos avanzadas.
•Se tiene un único componente para la gestión del acceso de datos de las actividades
El mantenimiento de la solución se realiza fácilmente, debido a que el número de interfaces con
sistemas externos se reduce considerablemente.
Sin embargo, para escenarios más complejos usted podrá utilizar la opción de configuración
Estándar.
Estos escenarios se refieren principalmente a:
•El uso de fuente de datos que no es SQL Server u Oracle (mediante replicación personalizada).
•Los requerimientos para configuración avanzada (por ejemplo, querer utilizar una columna de
Oracle que no es soportada).
•Necesidad de ajustes manuales en la configuración. Esto puede pasar en escenarios sofisticados
donde tiene todo un conjunto de tablas que están relacionadas entre ellas. Esto puede involucrar
relaciones entre entidades virtuales, por lo que la configuración requiere que todas las tablas sean
replicas y virtualizadas teniendo en cuenta algunas consideraciones.
Para más información sobre el segundo método, visite Utilizando configuración avanzada para
Replicación (opción estándar).
Virtualización de datos
Introducción
La virtualización de datos en Bizagi es un mecanismo de integración, que permite a los procesos
de Bizagi acceder a diferentes fuentes de datos, como se describe en Conexiones con fuentes de
datos externas.
Con la virtualización de datos, los procesos de Bizagi pueden acceder a información almacenada
en múltiples fuentes de datos (RDBMS, XMLs etc.) y presentar la información como parte del
proceso de negocio.
La integración se realiza transparentemente de los usuarios finales en el tiempo de ejecución
(sincronización de información), y la información de la entidad virtualizada es vista y actualizada
en el transcurso de una actividad o un proceso de negocios modelado.
Ejemplo de información manejada a través de Virtualización son: informes de clientes o
vendedores, facturas, órdenes de compra, entre otras cosas (registros de tablas que son vistas
como transaccionales).
Para integración de tablas e datos donde la actualización de la información es almacenada como
valores predefinidos (entidades paramétricas), visite Replicación de datos.
¿Cómo funciona?
Para utilizar la virtualización de datos en Bizagi, usted debe primero asegurar que la fuente de
datos externa cumpla las mejores prácticas y los requerimientos necesarios, como tener acceso
de lectura y escritura (un inicio de sesión con permisos otorgados).
Una vez la sincronización ocurre, la información será presentada a los usuarios finales como parte
del proceso de negocio en Bizagi.
Beneficios
El uso de la Virtualización de datos en una solución Bizagi promueve:
•Reusabilidad ya que permite a los procesos integrarse con fuente de datos existentes
(aplicaciones) y sistemas heredados.
Esto es un requerimiento frecuente cuando los sistema heredados no tienen un diseño de Servicio
Orientado a Arquitectura para integración en alto nivel (integración a nivel de datos es requerida).
La capacidad de Bizagi para virtualizar cualquier entidad definida en Bizagi provee los siguientes
beneficios:
•La distribución de trabajo a través de miembros del equipo de proyecto Bizagi se realiza de forma
clara.
El trabajo se separa de acuerdo a diferentes roles: el analista de diseño del negocio crea el modelo
del proceso y reglas de negocio; mientras la persona de IT diseña, configura e implementa el
modelo de datos e integra la solución.
•Ofrece a los analistas del negocio un modelo de datos limpio para el manejo y el intercambio de
información del proceso.
Los analistas del negocio tienen acceso a la información del proceso como si estuviera disponible
directamente en el repositorio de procesos de Bizagi (como datos locales).
De esta manera, no tienen que entender la complejidad asociada con la ubicación real de la
información.
•El diagrama de flujo del proceso no deberá incluir actividades técnicas (como por ejemplo de
acceso a datos).
Por esta razón los procesos organizacionales permanecen fáciles de leer y entendibles por la
audiencia de negocio. Las reglas de negocio no tienen que lidiar con acceso de datos o realizar
mapeos.
•Tener un solo componente para proveer todas las actividades de acceso a datos externos
simplifica notablemente el mantenimiento de la solución.
A través de esto, el mantenimiento de la solución se simplifica, el número de interfaces con
sistemas externos se reduce significativamente.
La siguiente imagen ilustra el poderío y los beneficios que ofrece la arquitectura de Bizagi
mediante el uso de la Virtualización de datos:
Nótese que tanto desde las formas de las actividades, las reglas de negocio (del flujo, de las tareas,
etc) o tareas automáticas, el acceso a los datos en fuentes externas será transparente ya que
mediante la Virtualización de datos, Bizagi podrá acoplarse fácilmente a la arquitectura de sus
sistemas existentes y del ESB corporativo.
Prerrequisitos
La fuente de datos externa debe cumplir los siguientes requerimientos:
1. El acceso al sistema de información externo debe estar disponible en tiempo real (para
sincronización en línea); si este no es el caso, debería ser implementada replicación de datos en
lotes. Este tipo de acceso requiere permiso de lectura y escritura en la fuente de datos.
2. Si la virtualización de datos va a acceder una base de datos, esta debería estar normalizada.
Esto es requerido para identificar claramente las llaves de negocio en cada entidad (Bizagi permite
la configuración de llaves compuestas) de tal manera que Bizagi pueda identificar sin
equivocaciones una instancia.
Adicionalmente, las relaciones entre las entidades de Bizagi (virtualizadas) deben existir entre las
entidades correspondientes de la fuente externa.
Características Importantes
1. La virtualización de datos solo aplica para entidades de tipo Maestras en Bizagi (datos
transaccionales; y cuando nuevas líneas son creadas en una nueva instancia del proceso).
Clic para más información sobre Entidades Maestras.
Si usted desea utilizar esta característica de integración para tabla con lista de valores, es decir,
entidades paramétricas, visite Replicación de datos.
Las versiones de base de datos soportadas por el asistente de virtualización son (para conexiones
de Oracle y SQL Server):
2014
2012
2008 R2
2008
2005
Oracle 12c
11g R2
11g R1
10g R2
10g R1
9i
Versiones soportadas para el asistente de virtualización (conexión nativa)
Cuando un proyecto requiere integrar una fuente de datos diferente a Oracle o SQL Server (por
ejemplo MySQL, XML files, Microsoft Access, etc.), se puede incluir una implementación
personalizada y configurar la virtualización de datosa través de la configuración Estándar
(avanzada).
Esto significa, que cualquier otro motor de base de datos no mencionado en la anterior tabla es
soportado por la Virtualización de Bizagi, pero requiere de desarrollos adicionales. Para más
información visite Virtualización Personalizada.
3. Bizagi soporta un amplio conjunto de tipos de datos de origen (en fuentes de datos Oracle o
SQL Server).
Para ver más información sobre los tipos de datos soportados por defecto, visite tipos de datos
soportados.
Otro tipo de datos no nombrado en la tabla del link anterior es soportado por la virtualización
pero con un desarrollo de un componente adicional (a través de Virtualización Personalizada).
Para ver mayor información acerca de los lineamientos y temas avanzados relacionados a la
característica de Virtualización en Bizagi y sus opciones, consulte Mejores prácticas para
Virtualización.
Para más información sobre el segundo método, visite Utilizando configuración avanzada para
Virtualización.
La siguiente información describe los tipos de datos soportados cuando se utiliza la integración
nativa de Bizagi con base de datos externas SQL Server u Oracle.
Las siguientes tablas muestras las asignaciones de las columnas de Bizagi cuando se
utiliza Replicación o Virtualización. La primera columna muestra el tipo de datos de la fuente, y la
segunda columna presenta el dato equivalente en Bizagi, si es soportado.
CHAR String
VARCHAR String
Números Exactos
INT Integer
DECIMAL Currency
NUMERIC Integer
Si el número es muy grande, luego de realizar la configuración de la replicación
o virtualización, es necesario cambiar manualmente el tipo de campo a un Big
Integer
Tipo de datos SQL Server
MONEY Currency
BIT Boolean
Números Aproximados
FLOAT Float
REAL Real
Fecha y Hora
DATE Date-time
DATETIME Date-time
SMALLDATETIME No soportado
Textos Binarios
BINARY No soportado
VARBINARY No soportado
IMAGE No soportado
NTEXT No soportado
UNIQUEIDENTIFIER No soportado
TIMESTAMP No soportado
CURSOR No soportado
SQL_VARIANT No soportado
TABLE No soportado
XML No soportado
VARCHAR2 String
LONG No soportado
RAW No soportado
Numéricos
NUMBER(10) Integer
NUMBER(18,4) Float
NUMBER (20) Number de Oracle (disponible solo cuando la BD de Bizagi es Oracle también)*.
NUMBER (38) Number de Oracle (disponible solo cuando la BD de Bizagi es Oracle también)*.
FLOAT Float
Fecha y Hora
DATE Date-time
TIMESTAMP No soportado
BFILE No soportado
BLOB No soportado
CLOB No soportado
Tipos de Datos Oracle
NCLOB No soportado
Rowid
ROWID No soportado
UROWID No soportado
XML
XMLTYPE No soportado
Cuando se utiliza CHAR, NCHAR, o NVARCHAR, no se soporta su uso en llaves primarias (Oracle
incluso no recomienda esto como una buena práctica).
*El tipo de datos Oracle Number no puede ser usado en reglas de negocio o dentro de ninguna
función XPath. No puede usarse como Vocabulario en Políticas, en Encripción de la base de datos
ni como Llave de negocio.
Importante
Al utilizar la virtualización o replicación de datos, considere que usted debe garantizar la misma
intercalación (collation en SQL Server) o set de caracteres (character set en Oracle), o por lo menos
dos que sean muy similares en la base de datos externa y la base de datos de Bizagi.
Esto es importante si los datos a integrar (principalmente de tipo cadenas) contienen información
susceptible a dicha configuración.
Por ejemplo, si usted integra una base de datos externa de Oracle que utiliza Unicode, asegúrese
de utilizar una base de datos Oracle Unicode para su proyecto de Bizagi también.
++++++
MEJORES PRACTICAS
Mejores prácticas en el Modelo de Datos
Bizagi ofrece un asistente amigable para construir un modelo de datos estructurado con
entidades definidas y sus correspondientes atributos. A diferencia de otros BPMs, usted puede
estructurar sus datos de negocio de una manera gráfica y lógica.
Bizagi ofrece todo lo necesario para construir modelos de datos adecuados y eficientes, pero
depende de usted crear uno que capture las condiciones de negocio y las refleje correctamente.
Esta sección ofrece algunos lineamientos y pautas para construir modelos de datos claros y
efectivos que describan adecuadamente sus condiciones de negocio.
Una nomenclatura clara y estándar para nombrar sus entidades y atributos es fundamental para
una construcción fácil e intuitiva (p.e para la navegación de XPath) y para su comunicación, la cual
conlleva a un mejor entendimiento de los procesos para cualquier miembro del equipo realizando
cambios sobre ellos.
Ejemplos.
Entidad: Cliente
Tipo: Maestro
Alcance: Privado (usado por el proceso Solicitud del Cliente)
Nombre: M_SC_Cliente
Entidad: Ciudad
Tipo: Paramétrica
Alcance: Privado (usado por el proceso Solicitud del Cliente)
Nombre: P_SC_Ciudad
Entidad: Firmas
Tipo: Paramétrica
Alcance: Pública (utilizado por varios procesos)
Nombre: P_Firma
Nomenclatura para atributos
Al apoyarse en un estándar para nombrar sus atributos, usted ahorrará tiempo durante la
implementación de sus proyectos y al realizar cambios sobre ellos en un futuro.
Nótese que el nombre de un atributo debe tener menos de 15 caracteres, incluyendo el prefijo
que pueda tener.
Utilice nombres en singular. Utilice nombres en plural cada vez que utilice colecciones, por
ejemplo: xSolicitudes, xClientes, xDocumentos.
Real r rGreatDistance
1. Lineamientos de diseño
A continuación encontrará lineamientos de mejores prácticas donde se siguen principios
conocidos para un buen diseño del modelo de datos.
El siguiente ejemplo es una parte del Modelo de Datos del Proceso de Solicitud de Préstamo.
Observe que en la izquierda cuán largo es el XPath que se utiliza para acceder desde la entidad
de aplicación, al nombre de la referencia del Solicitante (Applicant Reference) y lo corta que es en
el lado derecho con sólo cambiar la relación entre las entidades.
En este caso, una captura errónea de la lógica de negocio dificultará las búsquedas de información
en formas, expresiones e interfaces.
1.2. Evite conectar todas las entidades entre sí
El Modelo de datos de Bizagi está diseñado para utilizar XPath de una manera lineal (un solo
sentido). No debe construir el modelo de datos de Bizagi conectando todas las entidades entre
sí.
En la siguiente imagen, verá que hay una entidad de proceso: Travel Request. Ese es el punto de
partida de la navegación, por lo tanto, la navegación será lineal en oposición a una situación en
la que todas las entidades están conectadas entre sí.
Tenga en cuenta los diferentes escenarios de negocio en su proceso para saber cuándo una
entidad debe ser Paramétrica o Maestra. Para esto no hay una solución única. Las siguientes
preguntas pueden ser útiles para determinar qué tipo de entidad usar:
•¿La información se puede acceder y modificar desde diferentes procesos? Utilice una entidad
Maestra.
•¿La información es parametrizable? Utilice una entidad Paramétrica.
•¿Se necesita sincronizar información de Bizagi en una fuente externa y viceversa
(virtualización)? Utilice una entidad Maestra.
•¿Se necesita importar y actualizar información en Bizagi, que proviene de una fuente externa y
no cambia con tanta frecuencia (replicación)? Utilice una entidad Paramétrica.
Nótese que para un rendimiento óptimo, usted también debe considerar cómo define las formas (interfaces de usuario).
Contemplar qué acciones o cuándo se ejecutan, tanto del lado del cliente o del servidor, y qué información se presenta (y se
refresca) al usuario final, es fundamental para definir sus formas orientadas a un buen desempeño.
Es importante que utilice un tamaño adecuado para los atributos de texto de acuerdo con lo que
van a almacenar. (es decir, no crear una cadena de 500 caracteres para un atributo de texto que
almacenará los números de teléfono). Como una buena práctica orientada al rendimiento de la
base de datos, los atributos de tipo String deben reservar sólo la longitud necesaria.
2.2. Cree entidades con 30 atributos o menos
Al definir una Entidad, evite crear un gran número de atributos, ya que esto exigir más recursos
al ejecutar consultas que involucren la Entidad. Tener un gran número de atributos (más de 30)
en una sola entidad puede dar lugar a problemas de rendimiento.
Es común suponer que un conjunto de atributos pertenecen a una gran entidad única, pero le
animamos a que considere dividir las entidades más grandes en entidades relacionales más
pequeñas cuando sea posible.
Es común que este tipo de entidades en un principio parezcan necesitar muchos atributos, por
favor considere relaciones adicionales para descomponer la forma en que la información se
distribuye de una manera más adecuada.
Supongamos que tenemos el proceso Evaluación de Préstamo con un proceso entidad: Loan
Application.
Guardamos todos nuestros atributos relacionados con la evaluación de la aplicación en esa
entidad. Pero luego, nos dimos cuenta de cómo crecía, y supimos que tenía que se debía romper
para evitar problemas de rendimiento.
Por ello, hemos creado una nueva entidad llamada Solicitante (Applicant), donde colocamos toda
la información relacionada con la persona que solicita el préstamo para reducir el número de
atributos en la entidad de proceso. En la siguiente imagen, se observa cómo una entidad muy
grande se puede dividir en dos. Podríamos haber roto en más entidades relacionadas, si fuera
necesario.
2.3. Defina llaves de negocio para las entidades y promueva su uso en la
búsqueda de los registros
Como una buena práctica general para mejorar el rendimiento de las consultas y búsquedas,
defina una llave de negocio.
Una vez definida la llave de negocio para sus entidades, asegúrese de que las búsquedas se
realizan a través de esta opción para promoverla (por ejemplo, un control de búsqueda que tiene
una columna que se asocia con la llave de negocio dada).
de defecto en un control, usted asignará un valor inicial para un atributo específico de la entidad (diferente
e la llave de negocio) en un nuevo registro.
y asocia otro registro, entonces usted no habrá asegurado que el nuevo registro con la información inicial
en la llave de negocio.
enda que no use valores por defecto si usted planea asociar esa información a un registro existente.
•Definir del Modelo de Datos entidad-relación para la Virtualización y Replicación, y definir qué
entidades y atributos serán virtuales.
•Tener en cuenta que el diseño de la base de datos de la fuente externa debe utilizar la tercera
forma normal (normalización).
Para incluir esta configuración, se debe que incluir una propiedad denominada
"SQLServerDBPort" con el valor del puerto TCP de la instancia de SQL Server:
Esta configuración del atributo SQLServerDBPort solo es requerida para la edición JEE de Bizagi
en su ambiente de desarrollo.
De manera similar, no se recomienda virtualizar en una fuente de datos externa cuando las
entidades no virtualizadas ya están desplegadas en Producción (ya han almacenado valores).
Si esto es estrictamente necesario, tome las precauciones adecuadas para los valores actuales y
las llaves de negocio.
Si su fuente de datos (sea el nombre de tabla o de sus columnas) contiene espacios en blanco, entonces deberá asegurarse de
configurar y mapear el nombre de la fuente usando los caracteres de escape especfícos de dicho motor de base de datos (p.e.
utilizando [] en SQL Server).
Por lo tanto, es posible modificar este parámetro para que pueda mejorar el rendimiento en
ciertos escenarios.
Para usarlo, agregue la siguiente clave a su archivo web.config:
<add key="AttribMaxLengthThreshold" value="[column_length]"/>
Observe que se debe editar el valor de [column_length] con la longitud de la cadena que
desea que Bizagi considerare en la consulta principal.
De esta manera, su atributo virtual de más de 100 caracteres no requiere una consulta adicional.
Tenga presente que cuando se usa una vista donde se quiere actualizar información desde Bizagi (y cuando la vista sea construida
a partir de más de una tabla), el motor de base de datos como tal podrá tener restricciones.
Por ejemplo, en SQL Server, este tipo de vistas solo le permitirá actualizar información en la tabla base (para mayor información,
consultar https://msdn.microsoft.com/en-us/library/ms187956.aspx).
En caso de que considere que los requerimientos del Modelo de Datos del proceso necesitarían
atributos adicionales para una entidad virtual y usted desee no encontrar problemas potenciales
de desempeño, estos podrán ser creados en una entidad separada (que tiene un atributo de
referencia Entidad a la Entidad virtual).
En el siguiente ejemplo de Modelo de Datos de un proceso Bizagi, los atributos adicionales
"Observaciones" y "Cuentas totales" para un cliente se crean en otra entidad
("Customer_AdditionalInfo") que hace referencia a la entidad virtual Cliente:
La importancia de estas recomendaciones se centra en cómo la Virtualización de Bizagi realiza búsquedas y sincronización de los
registros en entidades virtuales (que se realiza directamente en la fuente de datos).
Por lo tanto, en un modelo con atributos mixtos, las consultas que se realicen sobre la fuente podrán no ser las óptimas.
Recomendaciones Avanzadas
Las siguientes recomendaciones aplican al utilizar Virtualización Personalizada (sobrescribiendo
los métodos predeterminados en Bizagi incluyendo una aplicación propietaria):
2. Rendimiento
Al desarrollar una aplicación personalizada para una fuente de datos diferente de Oracle o SQL
Server, tenga en cuenta las variables de rendimiento.
No está permitido el acceso a la base de datos de Bizagi desde la clase de virtualización y tener
pocas conexiones de acceso a la base de datos fuente es la mejor estrategia para alcanzar el
máximo rendimiento.
Los tipos de datos del origen de datos externo debe ser lo más parecido posible (idealmente
igual) a los tipos de datos de Bizagi.
Si los tipos de datos no se pueden asignar de forma natural a los tipos de datos de Bizagi entonces
la interfaz de virtualización debe implementar estas asignaciones.
Esto significa que si es necesario, se debe realizar la asignación de datos y las validaciones de tipo
de forma manual y en la interfaz de virtualización.
Esto se hace con el fin de evaluar las posibles transformaciones de Bizagi a la fuente de datos
externa.
+++++++++++++++++++++++++++++++++++
Esta sección proporciona modeladores de procesos algunas pautas para construir modelos claros
y eficaces compatibles con el estándar BPMN.
A continuación encontrará consejos útiles para seguir estos principios y ayudar a la definición
correcta procesos y su comunicación.
Una vez se ha definido la lógica del proceso, valide sus diagramas asegurándose de utilizar
correctamente los diferentes elementos de BPMN. El siguiente aspecto debe ser revisado para
cada elemento BMPN:
Lo que hay que revisar en Pools
•Diagrame los procesos completamente dentro de un Pool. Nunca diagrame flujos fuera de los
límites de un Pool.
•Defina tantos Pools como procesos. Debe haber siempre al menos un Pool.
•No cree Lanes para representar un área o una entidad que lleva a cabo un tarea automática o
una compuerta.
•No diagrame tareas, compuertas o eventos en medio de dos Lanes.
•No ramifique los flujos usando tareas. Siempre use las compuertas.
¿Qué verificar en compuertas?
•No use compuertas para juntar y separar al mismo tiempo. Esto producirá un error en tiempo de
ejecución.
•Siempre use el mismo tipo de compuerta para juntar los flujos que fue usado para dividirlos.
•Use sólo Eventos y/o Tareas después de una compuerta basada en eventos.
Prefijo: utilizando el nombre de proceso, cree un prefijo que se utilizará en todos los
componentes que pertenecen al proceso. Por ejemplo, si el nombre del proceso es: Solicitud del
cliente, puede usar el prefijo SC_. Los siguientes prefijos están restringidos para otros fines: "P_",
"M_".
•Si no aplica tener un nombre para la compuerta, use abreviaciones o números para diferenciarlas.
•Nombre las transiciones indicando la condición relacionada
Es fundamental definir el alcance correcto de las tareas y el nivel de detalle de los procesos para
reducir el exceso de información. Los siguientes consejos le ayudarán:
•Cuando diagrame, es útil imaginar que usted es el usuario final. Si un conjunto de actividades
consecutivas puede ser realizada por la misma persona, al mismo tiempo, entonces estas
actividades podrían integrarse en una sola actividad.
•Un conjunto de actividades consecutivas en el mismo Lane puede indicar falta de un participante,
demasiado detalle, o un desajuste el alcance de las tareas. Revise estos patrones para identificar
oportunidades de la integración de la actividad.
Agrupe las actividades
Utilice subprocesos para agrupar actividades con el mismo propósito. Después, puede ampliar los
subprocesos para exponer los detalles de los niveles inferiores de la jerarquía. Un proceso
contendrá varias páginas, pero internamente, se mantiene la integridad de un modelo único.
Para más información sobre los patrones de modelado por favor revise el documento de Patrones
de Modelado de Procesos BPMN.
No utilice antipatrones
Mientras simplificar sus modelos tenga en cuenta no utilizar Antipatrones. Estos son patrones de
modelado que se usan generalmente en la automatización, pero son malas prácticas que no son
recomendados por Bizagi