Anda di halaman 1dari 80

Modelar Datos

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.

La manera en que defina su modelo de Datos en Bizagi, determinará específicamente cómo se


almacenan y se acceden los datos.

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.

Entidad Principal del Proceso


Cada proceso en Bizagi tiene su entidad de Proceso principal. Esta entidad provee un punto de
inicio para acceder al resto del modelo de datos, es decir, es la entidad principal por la que los
usuarios acceden al resto de las entidades del modelo de datos.
En el segundo paso del Asistente se crea la primera entidad del proceso. Esta tendrá una doble
línea que la distingue del resto de las entidades.
En Bizagi usted podrá convertir una entidad en una Entidad de Proceso.

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

Abre el asistente de las entidades para crear una nueva


entidad directamente en el diagrama. Cuando una entidad
Entidad
es creada, ésta es automáticamente incluida dentro del
Nueva diagrama.

Abra el asistente de relaciones para crear una nueva


Relación
relación entre dos entidades.

Muestra y permite agregar las entidades creadas


Agregar Entidad
anteriormente en el diagrama.

Habilita al usuario para modificar el tamaño de los


Zoom Opciones de Zoom
elementos mostrados en la pantalla.

Controla si la cuadrícula es mostrada al fondo del


Mostrar/Ocultar Mostrar cuadrícula diagrama. La cuadrícula ayuda a alinear los objetos vertical
y horizontalmente dentro del diagrama.

Muestra la lista de las entidades por tipo para facilitar la


Maestra/Paramétrica/Sistema ubicación de estas dentro del espacio del diagrama
(utilizando la funcionalidad de arrastrar y soltar).

Incluye de forma automática todas las entidades (Maestras


Menú de la lista desplegable (clic derecho Adicionar entidades
y Paramétricas) que no están presentes en el diagrama
sobre la entidad) relacionadas
pero que tienen una relación con alguna ya incluida.
NOMBRE DEL GRUPO OPCIONES DESCRIPCIÓN

Lanza el asistente para incluir atributos dentro de las


Editar lista de atributos
entidades.

Lanza el asistente para modificar la información de la


Propiedades
entidad.

Remueve la entidad del diagrama únicamente, es decir, LA


Remover del diagrama. ENTIDAD NO APARECE EN EL DIAGRAMA PERO SIGUE
DENTRO DEL MODELO DE DATOS.

•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.

Usted puede incluir tantas Entidades Maestras como su proyecto lo requiera.


En cada entidad, se recomienda que no se incluyan más de 85 atributos (aunque igualmente no sea común tener más de 30, si
se siguen lineamientos estándar de buenas prácticas de diseño de modelo de datos, como por ejemplo prácticas de
normalización).
Cuando se excede este número máximo de atributos, se puede comprometer el desempeño de su proyecto (dado que las
operaciones de acceso a datos involucrando dicha entidad podrán tardar más de lo regular).

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.

Usted puede incluir tantas Entidades Paramétricas como su proyecto lo requiera.


En cada entidad, se recomienda que no se incluyan más de 85 atributos (aunque no es común tener más de 30, si se siguen
lineamientos estándar de buenas prácticas de diseño de modelo de datos, como por ejemplo prácticas de normalización).
Cuando se excede este número máximo de atributos, se puede comprometer el desempeño de su proyecto (dado que las
operaciones de acceso a datos involucrando dicha entidad podrán tardar más de lo regular).

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).

4. Entidades del Sistema


Las Entidades del Sistema, están marcadas en Bizagi Studio con un ícono de color gris que
simboliza un piñón industrial.
Este tipo de entidad pertenece al modelo interno de Bizagi e incluye información relacionada al
usuario final.
Las Entidades del Sistema son creadas por defecto en cada proyecto; y usted no podrá crear
entidades adicionales de este tipo, ni adicionar o modificar atributos de ellas.

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).

Usted no podrá incluir atributos adicionales en las Entidades del Sistema.


Sin embargo, si usted necesita mapear o almacenar información adicional relacionada a sus usuarios finales, usted podrá definir
propiedades de usuario dentro de la definición organizacional de su proyecto.
Para mayor información sobre esta funcionalidad, consulte las propiedades de usuario.
5. Entidades de Aplicación
Las Entidades de aplicación no cuentan con un marca particular, pero se ubican fácilmente en
Bizagi Studio bajo la categoría que enseña Entidades de Aplicación con un ícono de Bizagi.
Este tipo de entidad centraliza la información de cada una de las aplicaciones de negocio.
Recuerde que un proyecto de Bizagi podrá incluir cualquier cantidad de procesos, y por ende, las
aplicaciones de negocio son el primer criterio de clasificación para agrupar procesos.
Por lo tanto, las Entidades de Aplicación representan ese punto de entrada de información del
sistema (que manejan el modelo de datos) para un grupo de procesos.

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).

Dónde administrar las entidades paramétricas


Introducción
Las Entidades Paramétricas pueden ser clasificadas de dos formas: Administrables en el ambiente
de producción, o Administrables en el ambiente de desarrollo.
Es realmente importante que usted considere esta clasificación, de manera que dentro de su
diseño de Entidades Paramétricas usted considere las mejores prácticas en términos de
mantenibilidad del sistema.
Para ver una explicación básica de las Entidades Paramétricas, consulte los Tipos de entidades.

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:

•Deployment: Sincronización inicial, luego administradas independientemente en los


ambientes.
Los valores de Entidades administrables en producción se podrá administrar directamente en cada
ambiente (desarrollo, pruebas o producción).
Estos valores se podrá llevar desde el ambiente de desarrollo hacia el de producción únicamente
para la primera vez que se haga el deployment de procesos (un cargue inicial en el deployment
inicial).
Después del primer deployment, los valores en cada ambiente no se sincronizarán y deberán ser
manejados de manera independiente.

•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:

•Deployment: Los valores de desarrollo siempre sobrescriben los de producción.


Los valores de las entidades administrables en desarrollo serán siempre llevados al ambiente de
producción por medio del deployment; y estos valores sobrescribirán aquellos que ya existan en
producción (o se ingresarán nuevos también si aplica).

•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.

Configuración y comportamiento por defecto


Por defecto, las Entidades Paramétricas se crean como Administrables en el ambiente de
desarrollo (si usted no realiza acción alguna para definir esta clasificación al momento de crear
entidades).
Como buena práctica, se recomienda definir qué se desea de la propiedad al momento de crear
una entidad y revisar que la definición sea acorde justo antes de realizar un deployment a
producción.

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:

Decidir dónde administrar las Entidades Paramétricas


Si usted tiene problemas para determinar si una entidad se debe administrar en producción o en
desarrollo, considere las siguientes recomendaciones:
Escenario Debe ser Debe ser
administrable en administrable
producción en desarrollo

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 administración constantes, porque se prevee que sus valores X


cambiarán (se actualizarán) de manera frecuente.

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.

Opciones de las entidades paramétricas


En los siguientes enlaces podrá encontrar información sobre las entidades paramétricas:
•Crear y editar las formas para las entidades paramétricas: estas formas son utilizadas en el portal
de trabajo por los usuarios finales para agregar, remover o modificar información de las entidades
paramétricas.

•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.

•Crear entidades paramétricas con relaciones padre/hijo a través de combos dinámicos: la


configuración de padre/hijo de los combos dinámicos se debe hacer entre entidades
paramétricas.

Incluir datos en entidades paramétricas


Introducción
Registros o valores pueden ser incluidos, eliminados y modificados a través de Bizagi Studio
(Ambiente de desarrollo) o en el Portal de Trabajo en el menú Admin.

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.

Paso 3: Interfaz de usuario del modelador (Modelador de formas)


Incluya registros en las entidades paramétricas a través del tercer paso del asistente.
Dé clic derecho sobre la entidad paramétrica que desea modificar y seleccione la opción Editar
Valores.
Paso 4: Reglas de negocio
Al lado izquierdo, en la ventana de expresión Booleana, se muestra el Modelo de Datos.

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.

Para cada entidad desde la vista de Experto


Cada entidad creada será mostrada en el módulo de Entidades.
Vaya a entidades Paramétricas y seleccione la entidad cuyos valores deben ser editados. Luego
seleccione Valores.
Para incluir nuevos registros, clic en el botón Agregar.
Para borrar registros, seleccione una fila dando clic sobre el registro, luego oprima el
botón Suprimir en su teclado.
Para cambiar un valor solo debe escribir en el campo que se quiere modificar.

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.

Configurar una relación padre-hijo


Imagine que tiene una solicitud de compra donde debe seleccionar un país, estado y una ciudad
para la información de entrega.
La entidad maestra principal del proceso se llama Solicitud de Compra.
Las entidades Ciudad, Estado y País deben ser creadas previamente.

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.

Un nuevo campo será mostrado para incluir la entidad padre.


3. Clic en Finalizar
Si no existe la relación entre estas dos entidades (el padre y el hijo), se le pedirá que la cree.

4. Seleccione Sí y dé clic en Finalizar.


La relación ha sido creada.

5. Siga los pasos 2 y 3 para configurar la entidad Estado como padre.

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.

Por ejemplo, en el proceso de Solicitud de Compras, el contexto es Solicitud de Compras, ya que


esta es su entidad de proceso principal y a través de ella se puede alcanzar el resto del modelo
de datos.

Contexto en las Formas


Las formas que son construidas desde el tercer paso del asistente tendrán la Entidad de Proceso
como contexto.
Las formas que son construidas desde una entidad específica, tendrán como contexto la entidad.
Este tema será mostrado en más detalle en la sección de Contexto en formas.

Contexto en Reglas de Negocio y Expresiones


Las reglas de Negocio que se crean desde el cuarto paso del asistente tendrán como contexto la
entidad de proceso principal.
Si usted esta construyendo una regla de visibilidad, el contexto será donde se evalúe la regla, es
decir, la entidad de la forma.
Este tema se discute en mayor detalle en la sección Administración de las interfaces de usuario.

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.

Contexto en Correos electrónicos


El campo Para define el contexto del correo. El contexto cambia en correos enviados en
relaciones uno a muchos, cuando el campo Para tiene direcciones que corresponden a una
colección.

•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.

•Más tipos: Otros tipos avanzados.

•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

Booleano Almacena únicamente dos valores booleanos Verdadero y Falso.

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.

Entero Almacena un entero del siguiente rango: -2,147,483,648 a 2,147,483,647.

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.

Entero largo Almacena un entero del siguiente rango: -9,223,372,036,854,775,808 a 9,223,372,036,854,775,807

Texto extendido Almacena una cadena de texto sin límite de caracteres.

Almacena y adjunta archivos dentro del caso.


Configuraciones adicionales (como el límite de tamaño de adjuntos) se realizan en
Archivo la Configuración de Entorno, en la pestaña Avanzado, bajo las Opciones de Upload.
También permite guardar Plantillas de Documento.
Para este atributo, se posibilita la integración ECM.

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.

Entero muy corto Almacena un entero del siguiente rango: 0 a 255

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

Descripción Descripción del atributo para propósitos de documentación.

Texto de Ayuda El mensaje incluido dentro del campo será mostrado


automáticamente en el Portal de Trabajo al usuario final en el
asistente de ayuda cuando el usuario dé clic sobre el campo.

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.

Carpeta ECM Para los atributos tipo Archivo. De la carpeta configurada en


el repositorio ECM seleccione el que va a ser utilizado para
guardar los archivos adjuntados al atributo.

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.

Localizable Para los atributos de las entidades paramétricas.


Habilita/deshabilita la localización (Multi-Lenguaje) para los
valores de una entidad paramétrica.

Cifrado Cifra el atributo en la base de datos. Tenga en cuenta que esta


opción está disponible únicamente en entidades paramétricas y
maestras. Para más información, por favor diríjase a Encripción
en la base de datos.
Información del atributo tipo archivo
Atributos de tipo archivo
Bizagi permite cargar fácilmente archivos al proceso, por ejemplo archivos de procesadores de
texto, hojas de cálculo, archivos de video y de audio asociándolos directamente al caso específico
de negocio. Los usuarios pueden acceder y editar los archivos durante la ejecución del proceso y
realizar seguimiento de ellos en cualquier momento.

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.

¿Dónde se guardan los archivos cargados?


Cuando se adjunta un documento al caso, ésta es guardada en una de las carpetas creadas en
Bizagi para organizar los documentos. Estas carpetas son creadas por defecto en el directorio
docs, el cual es encontrado en la carpeta del servidor de la aplicación web, cuya ruta de acceso
por defecto sería:

C:\Bizagi\Projects\ApplicationName\WebApplication\Docs

ApplicationName: Nombre de la aplicación web del proyecto.

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.

Modificar los programas predeterminados para los atributos de tipo archivo


En cada proyecto los usuarios pueden cambiar el tipo de archivos asociados a los programas por
defecto. Bizagi incluye una lista de los tipos de archivos más populares. Para cambiar o adicionar
siga los siguientes pasos:

1. En Bizagi Studio, seleccione la pestaña Configuración y abra el menú de Negocios.


Seleccione la opción Avanzado.

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

Conexiones con fuentes de datos externas


Introducción
A través de modelado de datos en Bizagi, definimos y creamos entidades, atributos y
relaciones directamente en el modelo de datos del proceso (de forma local en la base de
datos de Bizagi).
Al realizar lo anterior, Bizagi ofrece dos poderosos mecanismos de integración para directamente
relacionar fuentes de datos existentes con el modelo de datos de Bizagi.
Estos dos mecanismos son conocidos en Bizagi como Replicación y Virtualización de datos, y
ofrecen características de integración a nivel de datos que presentan beneficios importantes,
como por ejemplo la posibilidad de reutilizar un modelo de datos externo y relacionar fácilmente
su información.

El concepto principal, es que Bizagi manejará la sincronización de información y encapsulará este


manejo, de manera que esto sea transparente tanto para los usuarios de Bizagi Studio (p.e, al
momento de definir reglas de negocio o las interfaces de usuario), como para los usuarios finales.
Es decir, los usuarios no necesitan conocer cuál es la fuente de datos, o realizar pasos adicionales
o especiales cuando una fuente de datos externa está integrada a la solución.

¿Cuándo utilizar estos mecanismos?


Estas características son especialmente útiles en escenarios donde queremos integrar en Bizagi
los repositorios existentes de nuestros sistemas corporativos (por ejemplo, utilizando la
información que ya está en un CRM, ERP, en un sistema legacy, etc.) y a la vez empoderando los
objetos reusables en Bizagi que pertenecen a las definiciones de negocio de los procesos.

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.

Arquitectura en la Virtualización y Replicación de datos


A continuación se ilustra y describe brevemente la diferencia al momento de utilizar Virtualización
o Replicación de datos.
•Replicación de datos: Únicamente para sincronizar información desde una fuente de datos
externa hacia Bizagi (a modo de lectura en Bizagi), y programable como una tarea periódica que
se ejecuta fuera de línea.
Para mayor información, consulte Replicación de datos.

•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.

2. Definir un esquema de Replicación.


Bizagi creará y programara un trabajo (job) para actualizar, insertar o deshabilitar información en
Bizagi, desde una fuente de datos externa.
•El trabajo puede ser ejecutado todos los días, una vez a la semana o una vez al mes.
•Como principal ventaja, la fuente de datos externa se mantiene como el único punto para la
administración de la información (“dueño de la información”).
Una vez el trabajo ejecuta la sincronización, la información será presentada a los usuarios finales
que trabajan en el proceso como parte de la información del negocio.

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).

Clic para más información sobre Entidades Paramétricas.


Si usted desea utilizar este mecanismo de integración para tablas de tipo transaccional (entidades
maestras), visite Virtualización de datos.

•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:

Motor de Base de Versión


Datos

Microsoft SQL Server 2016

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).

•Evitar tener información aislada y mantiene el dueño del sistema de información.

Para la implementación actual de un proyecto, la Replicación de datos de Bizagi tiene los


siguientes beneficios:

•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.

Configuración de la Replicación de datos


Como se menciono anteriormente, usted puede configurar la Replicación de datos de dos formas.
En la mayoría de los escenarios el asistente gráfico será suficiente.
Para más información sobre el primer método, visite Utilizando el Asistente de replicación.

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).

Para configurar la virtualización de datos se debe definir un sistema externo y el proveedor de


datos (conexión con la fuente externa de datos).
Bizagi ofrece un asistente gráfico para minimizar las configuraciones necesarias.

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.

2. La configuración de la Virtualización de datos se realiza fácilmente a través de un asistente


gráfico.
El asistente ayuda en la definición de la conexión con el proveedor de datos, ya sea Oracle o SQL
Server (la configuración se realiza en pocos pasos sin necesidad de programación).

Las versiones de base de datos soportadas por el asistente de virtualización son (para conexiones
de Oracle y SQL Server):

Motor de base de Versión


datos

Microsoft SQL Server 2016

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.

Tenga en cuenta estas consideraciones:


•La funcionalidad para incluir una implementación personalizada, para utilizar la virtualización de datos contra cualquier otra
fuente de datos (diferente a Oracle y SQL Server), está soportada por la edición Bizagi .NET.
•Cuando se virtualizan entidades contra una fuente de datos Oracle, para utilizar el asistente gráfico de Bizagi, se
requiereinstalar 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.

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).

4. Atributos borrados en la fuente nunca se borran en Bizagi.


Cuando se sincronizan valores de entidades virtualizadas, Bizagi deshabilitará aquellos registros
que fueron borrados de la fuente (serán marcados utilizando un borrado lógico en vez de un
borrado físico). Esto se realiza para conservar la integridad de los casos existente en Bizagi.

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.

Configurar la Virtualización de datos


Como se mencionó anteriormente, la configuración de la Virtualización de datos se puede hacer
de dos formas:
En la mayoría de los escenarios el asistente gráfico será suficiente.
Para más información sobre el primer método, visite Utilizando el asistente de Virtualización.
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
Virtualización.

Tipos de datos soportados


Introducción
Cuando se configura una virtualización o Replicación a través del asistente (es decir, cuando se
utiliza los componentes y las clases por defecto que Bizagi ofrece para la Virtualización), Bizagi
soporta el mapeo de atributos de diferentes tipos.

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.

Tipo de datos SQL Server


Caracteres de Texto

CHAR String

VARCHAR String

TEXT / VARCHAR(MAX) No soportado

Números Exactos

BIGINT Big Integer

INT Integer

SMALLINT Small Integer

TINYINT Tiny 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

SMALLMONEY Currency (soporte limitado)

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

Caracteres de Texto Unicode

NCHAR String (Soporte total para unicode)

NVARCHAR String (Soporte total para unicode)

NTEXT No soportado

Otros Tipos de Dato

UNIQUEIDENTIFIER No soportado

TIMESTAMP No soportado

CURSOR No soportado

SQL_VARIANT No soportado

TABLE No soportado

XML No soportado

Tipos de Datos Oracle


Caracteres de Texto

CHAR String (soporte limitado)

NCHAR String (soporte limitado)

NVARCHAR String (soporte limitado)


Tipos de Datos Oracle
VARCHAR String.
Oracle recomienda utilizar varchar2 en su lugar.

VARCHAR2 String

LONG No soportado

RAW No soportado

LONG RAW No soportado

Numéricos

NUMBER(1) Tiny Integer

NUMBER (3) Tiny Integer

NUMBER (6) Small Integer

NUMBER(10) Integer

NUMBER (19) Big Integer

NUMBER (17,4) Float

NUMBER(18,4) Float

NUMBER (19,4) Float

NUMBER Number de Oracle (disponible solo cuando la BD de Bizagi es Oracle también)*.

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)*.

NUMERIC Big Integer

FLOAT Float

DEC Big Integer

DECIMAL Big Integer

Fecha y Hora

DATE Date-time

TIMESTAMP No soportado

INTERVAL YEAR No soportado

INTERVAL DAY No soportado

Objeto Extenso (LOB)

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.

Las mejores prácticas orientadas a cómo estructurar su modelo de datos consideran:


•La nomenclatura y estándares en el modelo de datos.
•Lineamientos orientados a la planeación de sus entidades y atributos, en cuanto a un buen diseño
y rendimiento.
•Recomendaciones para la integración de datos.

Nomenclatura y estándares en el modelo de datos


Introducción
La siguiente sección lista una nomenclatura sugerida para definir su modelo de datos de una
manera que se promueva la usabilidad, mantenibilidad y la legibilidad para usted y sus
compañeros del equipo.

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.

Nomenclatura para entidades


Al apoyarse en un estándar para nombrar sus entidades, usted ahorrará tiempo durante la
implementación de sus proyectos y al realizar cambios sobre ellos en un futuro.

1. Definición de las entidades


Los nombres de las Entidades deben describir claramente la información que contenga. Asegúrese
de utilizar nombres cortos o abreviaturas.
2. Nomenclatura sugerida para las entidades
Se recomienda utilizar una nomenclatura para las entidades que identifique claramente su tipo y
alcance.
Las entidades pueden ser clasificadas por varios criterios:

•Tipo de entidad (Maestra, Paramétricas).


Para facilitar la generación de reportes personalizados, se sugiere utilizar los siguientes prefijos
para los tipos de entidades:
oP: identifica la entidad como paramétrico.
oM: identifica la entidad como maestro.

•Tipo Alcance (Privado, Público).


oPrivado: Se utiliza dentro de un proceso.
oPúblico: Se utiliza en más de un proceso. por ejemplo. Cliente, TipoDocumento, etc.
Recomendamos el uso de prefijos para nombrar las entidades privadas utilizando 3 caracteres
basados el nombre del proceso.

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.

1. Definición de los atributos


Dé a los atributos un nombre corto y claro que permita fácilmente su mapeo en el diseño de
formas, la definición de las expresiones o la configuración de interfaces.
Se recomienda que trate de usar el mismo nombre que se mostrará en los Formularios.

2. Nomenclatura sugerida para los atributos


Se recomienda utilizar una nomenclatura que utilice prefijos en los atributos, y así identificar
claramente su tipo y alcance.

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.

La siguiente tabla muestra los prefijos sugeridos de acuerdo al tipo de atributo:

Tipo de atributo Prefijo Ejemplo

Boolean b bCustomer, bActive

Currency c cSalary, cDiscount, cPrice

Date – Time d dBirth, dCreated

Integer, Big Integer, Small Integer, Tiny Integer i iDistance

String, Extended text s sNotes

File u uPhoto, uAttachment

Float f fRate, fDiscount

Image img imgProfile

Real r rGreatDistance

Entity km, kp (km para maestra, kp para paramétrica) kmCustomer, kpCurrency

Collection x xElements, xRequests,


xMembers

Lineamientos orientados al diseño y el rendimiento


Introducción
La siguiente sección lista los lineamientos que le ayudarán a diseñar su modelo de datos.
Tales lineamientos deben ser considerados desde las etapas tempranas de su proyecto, para
lograr un modelo de datos eficiente (que promueva buen un rendimiento y usabilidad).
Tenga presente que es muy importante que las etapas tempranas de análisis y diseño se ejecuten
de manera apropiada, y así lograr que por medio de un buen análisis y diseño se ahorre tiempo
durante la implementación de sus procesos y evitar tener que rehacer y volver diseñar la
implementación.

Lograr modelos de datos eficientes


En el diseño del modelo de datos de sus procesos de Bizagi y sus proyectos en general, dedique
una cantidad adecuada de tiempo para el análisis, e involucre a los miembros y stakeholders
relevantes.
La definición adecuada de la estructura del modelo de datos del proceso, es un punto crítico en
los procesos de automatización por estas razones:
•Afecta notablemente la dificultad de acceder a la información del modelo de datos desde formas
y expresiones.
•Determina la capacidad de comunicar con claridad el modelo de datos con los miembros del
equipo y los dueños de proceso.
•Determina cómo se consulta la información.
•Determina la capacidad de reutilizar información.
•Determina la capacidad de administrar la información.
•Determina cómo se actualizará la información.

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.

1.1. Defina el modelo de datos promoviendo el diseño orientado a objetos


Con esta premisa, es posible que también desee revisar si su modelo de datos ofrece los medios
adecuados para utilizar la navegación XPath en sus otros elementos de proceso (por ejemplo, en
las formas y reglas de negocio).

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í.

1.3. Use atributos de Scope cuando aplique


Evite incluir información que se utilice de forma temporal en actividades o procesos y que no
agreguen valor al modelo de datos. Puede utilizar Atributos de Scope para mantener el Modelo
de Datos claro.

1.4. Utilice adecuadamente las entidades maestras y paramétricas


Tenga presente que Bizagi tiene un manejo diferente para los 2 tipos de entidades (p.e en el
manejo de información y heurísticas de optimización), y que también existen algunas
funcionalidades que solo aplican a cada tipo de entidad.
Por ejemplo, las entidades Maestras son consideradas como datos de negocio (no se despliegan
sus valores desde el ambiente de desarrollo a producción), mientras que las entidades
Paramétricas pueden definirse como metadata (lo contrario).
Dentro de las características que pueden ser utilizadas únicamente por entidades Paramétricas,
usted tiene la posibilidad de definir entidades padres, y así usar el combo en cascada en las
interfaces de usuario.

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.

1.5. Use la Virtualización o Replicación de datos cuando aplique.


Recuerde que tanto la Virtualización como la Replicación de datos son tecnologías excelentes
para la reutilización de información almacenada en fuentes externas.
Si la información que necesita en su proceso ya existe en una fuente externa y tiene acceso a ella,
utilice las funciones de Virtualización y Replicación.

1.6. Defina qué información puede ser modificada en ambientes de producción


Parte de la información puede requerir ser editad< por los usuarios finales en ambientes de
producción debido a las condiciones cambiantes del negocio. Asegúrese de llevar a cabo un
profundo análisis para determinar qué información puede ser modificada en ambientes de
producción, con el fin de evitar los despliegues frecuentes para adaptar la información a las
condiciones de negocio actuales.

Utilice la opción Administrar valores en producción exclusivamente que se encuentra en las


propiedades de las entidades paramétricas para definir si la información se puede editar en el
ambiente de producción o exclusivamente en el de desarrollo.
2. Lineamientos de rendimiento
Construir un modelo de datos siempre con criterios de rendimiento en mente es un aspecto
importante en las etapas tempranas de su proyecto.
La forma en que se define un modelo de datos afecta al rendimiento de la aplicación y la
experiencia del usuario. Una definición adecuada del modelo de datos mejorará la experiencia del
usuario y permitirá una escalabilidad de la solución más sencilla.
Considere estos lineamientos para evitar potenciales incidentes relacionados al rendimiento de
su aplicación.

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.

2.1. Utilice un tamaño adecuado para los atributos de tipo texto


Algunos proyectos tienden a crear atributos largos de tipo String (con más de 250 caracteres)
para todos los atributos de texto, sin tener en cuenta para qué van a ser utilizados.

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).

En el siguiente ejemplo hemos definido el número de documento (Document Number) como la


clave de negocio para la entidad Cliente en lugar de utilizar el id de la entidad.
do llaves de negocio en una entidad, asegúrese de utilizar la opción de valores por defecto de manera

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.

ciones para la integración de datos


Recomendaciones básicas
El siguiente artículo enumera las recomendaciones para las mejores prácticas durante el uso (o el
uso planeado) de la funciones de Virtualización y Replicación de Datos de Bizagi.

1. Haga un análisis adecuado y diseñe en etapas tempranas


Se recomienda tener en cuenta todas las limitaciones, las posibilidades de integración y el diseño
adecuado para el modelado de datos (en análisis y en las fases de diseño de la implementación
del proyecto).
De este modo, teniendo en cuenta que las entidades serán virtuales, es una buena práctica crear,
antes de empezar, todas las entidades y el Modelo de Datos de Bizagi.
Esto implica:

•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).

2. Siempre mapee sus atributos y relaciones de Bizagi (considerar las referencias


a las claves compuestas)
Es estrictamente requerido mapear los atributos a los campos en la fuente externa (los que usted
va a utilizar).
Tenga en cuenta que las relaciones creadas en Bizagi también deben ser mapeadas.
Para obtener más información y recomendaciones sobre esta configuración, consulte el
ejemplo Cómo configurar la Virtualización, en la que también se puede ver cómo hacer esto
cuando se incluye una referencia a una llave compuesta.

3. Tener puertos externos explícitos (aplica cuando se integra a una fuente de


datos de SQL Server)
Cuando se utiliza SQL Server como fuente de datos externa, se recomienda que la configuración
de la instancia de la base de datos tenga un puerto TCP explícito:
El uso de un puerto TCP explícito sigue las mejores prácticas (en lugar de puertos TCP dinámicos).

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.

4. La Virtualización de datos funcionando en producción


Tenga en cuenta que una vez que una fuente de datos externa (registrada como un sistema en
Bizagi) se ha implementado en un entorno de producción, no será posible convertir este modelo
virtualizado en un modelo no virtualizado.
Esto significa que debe verificar cuáles tablas deben y cuáles no deben ser virtualizadas, y esto se
debe definir previamente a la implementación de los procesos y su uso en producción.
En caso de que necesite dejar de usar la virtualización para su proyecto, usted tendrá que crear
nuevas versiones de proceso y asegurarse de que su modelo de datos de proceso considera el
uso de una entidad alternativa (que no es virtual).

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.

5. Nomenclatura de las entidades


Si su fuente de datos tiene nombres muy extensos (en los nombres de tablas o columnas),
entonces tenga presente que en Bizagi se tendrá una estructura de datos mapeada a su fuente,
soportando dicho nombre extenso, pero la estructura en Bizagi tendrá un nombre truncado.
Esto se debe a que Oracle limita el nombre de estructuras a 26 caracteres, y además de ello, Bizagi
pondrá un sufijo al nombre de la estructura cuando se use Virtualización o Replicación.
Recuerde que esto aplica a los nombres de los objetos (aquellos principalmente de uso interno),
y no aplica a los nombres para mostrar (a los que finalmente se refieren los usuarios finales).

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).

6. Utilizar los parámetros de optimización cuando sea necesario


Cuando se consulta la información de una fuente externa a través de Virtualización, Bizagi utilizará
un parámetro de optimización que se crea separado y consulta por demanda la información que
reside en las columnas de tipo texto que tengan más de 100 caracteres. (Es decir, varchar(101),
varchar2(200), etc).

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.

7. Tipos de datos adecuados en las llaves primarias


Recordemos que con el fin de utilizar los datos de Virtualización o Replicación, se requiere que la
tabla externa contenga una definición de llave primaria.
Al definir las llaves primarias en las tablas externas, recuerde que no es recomendable usar tipos
de datos string (por ejemplo, varchar, texto, etc).
La indexación de las llaves primarias y el rendimiento se ve afectado cuando se utilizan estos tipos
datos y se debe evitar.

8. Uso de las vistas cuando corresponda


La Virtualización y Replicación de datos de Bizagi soporta vistas.
Usted puede utilizar vistas cuando aplique, siempre y cuando las vistas garanticen unicidad en sus
registros (haya una columna o conjunto de columnas que lo garanticen y que puedan tomarse
como llave de negocio).

Usualmente las vistas son para propósitos de consulta.

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).

9. Usar entidades virtuales con atributos virtuales y no-virtuales cuando sea


necesario
Es importante entender que si se tiene una entidad virtual, donde hay atributos virtuales y no-
virtuales, entonces deberá diseñar sus formas y reglas en general con especial cuidado.
Tenga en cuenta que un modelo mixto (con atributos de ambos tipos) deberá usarse cuando sea
necesario, por lo que esto implica que se controle desde su diseño mismo que no se construyan
o promuevan filtros que permitan problemas de desempeño.
No se recomienda que hayan filtros combinando atributos de ambos tipos en estos escenarios.

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.

10. Incluir en la Virtualización o Replicación de datos, las entidades relacionadas


por entidades virtuales
Es importante que diseñe su modelo de datos, teniendo en cuenta que si usted tiene una entidad
virtual (o replicada) con atributos que referencien a otras entidades, entonces esas otras entidades
deben estar igualmente incluidas en la Virtualización o Replicación de datos (recomendado
enfáticamente).
Esto aplica igual recursivamente para esas entidades relacionadas, es decir, si a su vez tienen un
atributo que referencia a otras entidades.

11. Replicar primero si las Entidades virtuales se relacionan con entidades


replicadas
Al tener un modelo mixto en el que tiene tanto la virtualización y replicación, y usted tiene una
entidad virtual que tiene un atributo de referencia a una entidad replicada, asegúrese de que los
registros replicados (aquellos en la Entidad de parámetros) se han sincronizado anteriormente.
Para ello, usted puede establecer ejecuciones periódicas de replicación.

Recomendaciones Avanzadas
Las siguientes recomendaciones aplican al utilizar Virtualización Personalizada (sobrescribiendo
los métodos predeterminados en Bizagi incluyendo una aplicación propietaria):

1. Acceso a los datos y evitar bloqueos


Es posible acceder a diferentes fuentes de datos a través de Virtualización Personalizada utilizando
cualquier mecanismo de conexión y transporte (ODBC, OLEDB, acceso cliente HTTP, Sockets, etc.).
Lo que es importante, es seguir las buenas prácticas de conexión a la fuente (y otras
consideraciones especiales) con el fin de gestionar adecuadamente las conexiones y evitar
bloqueos.

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.

3. Implemente el CRUD teniendo en cuenta los tipos de datos


Al utilizar Virtualización Personalizada, la fuente de datos externa debe exponer los mecanismos
para: seleccionar, insertar, actualizar y eliminar instancias de la entidad (mediante el uso de
funciones, procedimientos almacenados, Servicios Web, etc.).

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.

+++++++++++++++++++++++++++++++++++

Mejores prácticas en modelado de procesos


El estándar de Modelo y Notación de Procesos de Negocio (BPMN; por sus siglas en inglés)
proporciona a las organizaciones la capacidad de comprensión de sus procesos internos de
negocio en una notación gráfica y la capacidad de comunicar sus procedimientos de manera
estándar. Sin embargo, el uso del estándar no garantiza que los procesos se modelen de forma
clara y eficaz; la forma en que los modeladores interpretan las condiciones de negocio y cómo
definen su estructura, es crucial para asegurar que se entienden correctamente.

Esta sección proporciona modeladores de procesos algunas pautas para construir modelos claros
y eficaces compatibles con el estándar BPMN.

Principios de modelado BPMN


Cuando se definen los diagramas de proceso que debe tomar en cuenta los siguientes principios
básicos:

•1. Mantenga una secuencia lógica y clara


•2. Utilice el estándar BPMN
•3. Utilice un etiquetado estricto
•4. Simplifique los diagramas

A continuación encontrará consejos útiles para seguir estos principios y ayudar a la definición
correcta procesos y su comunicación.

1. Mantenga una secuencia lógica y clara


Esto pareciera ser obvio, pero es uno de los errores más comunes en el modelado de procesos.
Los diagramas pueden se pueden difíciles de leer y muy confusos cuando la lógica de proceso no
es explícita y clara. Las siguientes técnicas le ayudarán a mantener una secuencia lógica y clara en
sus modelos.
Definir un comienzo y un final claro
En BPMN, comienzan y los eventos extremos son opcionales. Sin embargo, los procesos con los
eventos de inicio y fin implícitas son indeseables y podrían dar lugar a malas interpretaciones.
Utilice eventos de inicio y final de cada proceso y subproceso para representar su comienzo y
finalización.

Siga una dirección consistente del flujo


Haga visible la lógica del proceso en el diagrama. Evite las líneas cruzadas (conectores), mantenga
una secuencia de tiempo y una dirección de flujo constante. La lectura diagrama será más fácil y
su comunicación eficiente.

Mantenga claro el escenario principal


El escenario principal debe ser fácilmente identificado al leer el diagrama. Diagrame el escenario
principal primero y luego los flujos alternativos.
Mantenga claros los escenario alternativos
BPMN ofrece las herramientas necesarias para representaren el diagrama la lógica del manejo de
excepciones de forma explícita. Una vez que el escenario principal es diagramado, haga uso de
los siguientes elementos para modelar los flujos alternativos según sea necesario:

Utilice procesos transaccionales


Los procesos transaccionales permiten escenarios de negocios con transacciones. Un conjunto de
actividades debe realizarse con éxito, de lo contrario compensación o cancelación flujos son
seguidos. Para más información ver subprocesos.

Distinga los estados finales exitosos y no exitosos


Utilice eventos finales separados para identificar cuando un proceso terminó con éxito y cuando
no, para propósitos de documentación y revisión.

Mantenga un formato estándar


Mantenga un formato único a lo largo de sus diagramas y enfóquese en una apariencia limpia y
agradable. El uso de diferentes tamaños de fuente, colores, dimensiones de cajas o etiquetas
superpuestas podrían hacer que la lectura de los diagramas sea un desafío.

2. Utilice el estándar BPMN


El estándar BPMN define los lineamientos utilizados para diagramar los procesos de negocio. Sin
embargo, seguir las directrices de BPMN está completamente en sus manos. Asegúrese de que
sus modelos cumplen con la norma para asegurar su correcta comprensió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.

¿Qué verificar en Lanes?


•Cree un Lane solo si se ejecuta al menos una tarea o un evento intermedio en él.

•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.

¿Qué verificar en Actividades?


•No diagrame varias instancias de la misma tarea para representar a varios participantes. Sólo
diagrame una tarea en un área. Defina los participantes como condiciones de asignación en la
documentación y en reglas de asignación.

•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.

•Balancee las compuertas. Las divisiones deben unirse de manera equivalente.

•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.

¿Qué verificar en Eventos?


•Utilice eventos de terminación sólo cuando sea estrictamente necesario. Estos se utilizan para
modelar situaciones donde se habilitan varios caminos alternativos y todo el proceso tiene que
ser terminado cuando uno de ellos se ha completado.
Esto tiene una excepción descrita en el siguiente ítem.

•Use los Eventos de finalización terminal en vez de eventos de terminación en subprocesos


embebidos.
¿Qué verificar en Conectores?
•Use flujos de secuencia para conectar todas las actividades, eventos y compuertas. Nunca use el
flujo de mensajes para conectar las actividades del mismo Pool o deje formas sin conectar.

¿Qué verificar en Milestones?


•Siempre identifique y defina fases; estas representan un periodo de tiempo objetivo o una
transición en el proceso.

•En lo posible, evite regresar entre Milestones.


3. Utilice un etiquetado estricto
El nombramiento correcto de los diferentes elementos de los diagramas es fundamental para una
comprensión fácil y correcta de los procesos.
Al revisar los logs, es muy útil saber cómo se ejecutó el proceso. Cuando no se nombra alguna
forma en el proceso, los Logs se muestran en blanco, lo que hace que sea difícil de entender. Estas
son algunas recomendaciones que le ayudarán a hacerlo:

Etiquetas de los procesos


Los nombres de los procesos deben describir claramente su propósito principal. Asegúrese de no
utilizar nombres cortos o abreviaturas.

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_".

Etiquetas de las actividades


Dé a las actividades un nombre compuesto por un verbo y un objeto. De esta manera los lectores
puedan entender con claridad el objetivo de una tarea. Además, asegúrese de que usted no utiliza
nombres cortos o abreviaturas.

Etiquetas de los Eventos


Utilice el etiquetado cuando se utilizan múltiples eventos de inicio y fin. Nómbrelos para que el
diagrama puede explicarse por sí mismo y permitir que los usuarios sepan cómo termina el
proceso.
Etiquetas de los Milestones
Los Milestones deberían ser nombrados con un sustantivo que haga referencia a un periodo de
tiempo (verano, madurez) o a lo que suceda en un periodo de tiempo (creación, aprobación,
entrega).

Etiquetas de las Compuertas


Las compuertas de divergencia deben tener un nombre que indique claramente la decisión o
condición evaluada cuando aplique. Utilice un nombre compuesto por un verbo, un objeto, y un
signo de interrogación para identificar lo que se está evaluando. Usted puede incluso utilizar
preguntas para aclarar la decisión en cuestión.

•Si no aplica tener un nombre para la compuerta, use abreviaciones o números para diferenciarlas.
•Nombre las transiciones indicando la condición relacionada

4. Simplifique los diagramas


Los diagramas grandes no permiten dar una perspectiva de extremo a extremo para los lectores.
Son difíciles de leer y el propósito del proceso es difícil de comunicar.

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:

Reduzca el número de tareas redundantes


El nivel de detalle en un proceso a veces es un verdadero reto. En muchos casos, usted puede
enfrentar dificultades para definir el alcance de una sola tarea. Tome en cuenta que:

•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.

Utilice subprocesos embebidos cuando:


•Un conjunto de actividades consecutivas tiene un propietario diferente del propietario del
proceso principal (por ejemplo, un proceso de Solicitud de Compra se realiza el área de
Compras y el proceso de Cuentas por Pagar se realiza el área Financiera).
•Un conjunto de actividades consecutivas tiene un objetivo diferente al del proceso principal (por
ejemplo, Solicitud de Crédito se centra en la gestión de todas las actividades para aprobar una
solicitud de crédito y Verificar la información del solicitante se centra en comprobar si el
solicitante está en lista negra, así como la información presentada).

Utilice subprocesos reutilizables cuando:


•El subproceso debe ser invocado desde diferentes procesos (por ejemplo, el
subproceso Verificar la información del solicitante se puede invocar desde el proceso
de Solicitud de Crédito o desde Solicitud de Seguros).

Aplique patrones de procesos


No reinvente la rueda. los expertos de BPMN han trabajado en la definición de patrones de
modelado para diferentes situaciones de negocios. Úselos para modelar las condiciones de
negocio requeridas al tiempo que simplifica sus diagramas.

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

Documente los detalles menores


Deje los detalles a la documentación. No incluya toda la información en diagramas. La información
adicional debe ser documentada como propiedades de forma, no como objetos o texto en el
diagrama.

Anda mungkin juga menyukai