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).
4. La Virtualización de datos funcionando en producción
Tenga en cuenta que una vez que una entidad virtual está operativa en un ambiente de producción, no puede convertirla en una entidad no virtual.
Una vez que una fuente de datos externa (registrada como un sistema en Bizagi) ha sido implementada en un Ambiente de Producción, no será posible editar su configuración para que no sea utilizada por entidades virtuales.
Esto significa asegurar qué tablas deben y cuáles no deben ser virtuales, y esto debe estar definido previamente para implementar los Procesos y usarlos en producción.
En caso de que necesite dejar de usar la virtualización de datos para su proyecto, deberá crear una nueva versión de proceso y asegurarse de que su modelo de datos de proceso considere una entidad alternativa (que no está configurada como virtual).
De manera similar, no puede convertir una entidad no virtual en una entidad virtual una vez que esté configurada en un ambiente de producción, por lo que necesitará una nueva entidad.
Se deben tener en cuenta las precauciones adecuadas para los valores existentes 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 específicos de dicho motor de base de datos (p.e. utilizando [] en SQL Server). |
6. Llaves primarias o índices adecuados
Recordemos que con el fin de utilizar los datos de Virtualización o Replicación, se requiere que la tabla externa cumpla con lo siguiente:
•Debe contener una definición de llave primaria si es una tabla. En caso de ser una vista, entonces debe tener un índice único por lo menos.
•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.
7. 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). |
8. 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. |
9. 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.
10. 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.
11. Alternativas para Virtualizaciones en PaaS
1. El enfoque preferido es crear una API REST que se ejecute en el entorno local y encapsule el acceso al sistema externo.
Después, se debe generar o construir un conector personalizado que consuma la API. Este conector será utilizado desde los procesos de Bizagi para actuar sobre el sistema externo.
a. En cuanto a la replicación/virtualización, usualmente no se utilizan todos los datos de una entidad replicada o virtualizada a la vez, sino que se realiza una consulta específica y luego se actualizan los datos en base a esa consulta. Ambos casos se pueden lograr con una API.
b. Además, es más seguro identificar algunas acciones que operan en el sistema externo, en lugar de otorgar acceso completo a los datos replicados o virtualizados. Esta es otra ventaja de la API.
c. Finalmente, las API son más fáciles de mantener y monitorear, y se adaptan completamente a las características de tiempo de ejecución de un entorno de nube.
2. Si el enfoque anterior no es posible, se puede hacer un conector personalizado. Debe aislar el acceso al sistema externo y manejar los problemas de latencia, reintentos y otros que puedan surgir al acceder al sistema externo.
a. En el caso de un sistema externo, depende de la existencia de librerías Node.js.
b. El desempeño del conector y de Bizagi depende completamente de la conectividad del sistema externo, y de la posible latencia que se presente. Este no es el caso de la opción 1.
3. Si lo anterior no es posible, sería necesario crear una librería de componentes que aísle el acceso al sistema externo. Este no es un enfoque ideal, ya que podría traer problemas de compatibilidad adicionales: la librería puede tener dependencias incompatibles con las aplicaciones web, la actualización de la librería requiere procedimientos logísticamente complejos y la resolución de problemas también pueden volverse complejos.
Last Updated 1/26/2022 3:39:38 PM