Restriccion de Virtualizacion
De
<keywords content="keywords"> virtualizar, virtualizacion, restricciones, restriccion </keywords>
Restricción de Virtualización
Aquí se muestran limitaciones técnicas a tener en cuenta al enfrentar un proyecto Bizagi donde se involucre virtualización.
1. Limitante de controles en la interfaz de usuario (UI). Considérese este escenario en el modelo de datos Bizagi que ha sido virtualizado contra un modelo de datos externo:
En el anterior gráfico las entidades A y B están relacionadas de tal manera que para una instancia de la entidad B se pueden tener una o más instancias de la entidad A (y A tiene una llave foránea de B) luego es el caso normal de una entidad como “Solicitud de Crédito” (A) y “Cliente” (B). Es normal que durante el funcionamiento del proceso se cree una forma para la entidad B. Por ejemplo, para seleccionar un cliente cuya llave subrogada “idCliente” deberá persistir en A como llave foránea.
Controles JoinSearch, funcionalidad de agregar a grillas, enlaces a formas, “submit” en reglas de negocio y el botón guardar, entre otros, ocasionan que el id de la entidad B deba ser grabado y creada una instancia en A para tal fin. Si en ese momento no se tiene aun la llave compuesta (llave de negocio) lista para crear el registro en A, la virtualización fallará. Este problema se debe a que si aún no existe llave de negocio, no se puede lograr insertar un registro en la entidad externa.
Work Around: dejar el modelo original en Bizagi sin virtualizar A, crear una entidad A’ virtualizada y luego de tener todos los datos listos para garantizar la inserción en A, por reglas de negocio mapear los datos de A a A’ (que está virtualizada) de manera que se pueda evitar el error.
WorkAround Issue: si esta situación se presenta en muchas tablas hay que replantear la estrategia de virtualización o el modelo de datos de virtualización porque el hecho de mantener muchas entidades paralelas puede traer problemas de complejidad en la construcción del proceso y una carga adicional al modelamiento y mantenimiento del mismo.
Caso especial, Stored Procedures en la fuente de datos: cuando los datos a actualizar en una entidad virtualizada deben ser “completos” antes de una actualización vía un Stored Procedure (que ofrece el servicio a la interface de virtualización) que por ejemplo necesita datos como “Pago” y “Tipo de Pago”, es necesario que el Stored Procedure tenga una lógica para esperar toda la información antes de ser almacenada en las entidades de la fuente de datos. Esto sucede porque para Bizagi todo POST inicia una transacción donde se ordena a la interfase de virtualización hacer persistir la información que se tiene en el momento, esto puede ocasionar como en un combo dinámico que algunos datos se intenten salvar sin estar aun “completos” a nivel de instancia de una entidad (registro de una entidad virtualizada).
2. Limitante por llaves subrogadas y autonuméricas en la entidad externa. Si la entidad externa tiene como llave primaria una llave subrogada (idEntityName) controlada por el sistema externo (e.g. un manejador de base de datos que permita definir una llave autonumérica) se deberá crear el atributo llave en la entidad Bizagi virtualizada, y cada vez que se deseen hacer inserciones sobre la entidad se deberá llamar una interfase hacia el sistema externo que permita averiguar cual es el siguiente número para la llave, así mismo se deberá “bloquear” la utilización de ese número para poder garantizar que el nuevo registro que se insertará en la entidad virtualizada es el que se averiguó.
Definitivamente no es posible solicitar ni capturar este número desde Bizagi.
Esta limitante puede traer problemas de desempeño y de complejidad en la implementación si ocurre en muchas o todas las tablas del modelo de datos externo para virtualización.
3. Consideraciones de tamaño de registros para entidades virtualizadas. Siempre que una entidad es virtualizada el flujo de información entre Bizagi y el sistema externo se incrementa para mantener la sincronización de actualizaciones, inserciones y borrado de instancias de entidad.
Cuando las entidades crecen mucho, como generalmente sucede con entidades resultantes de relaciones muchos a muchos o uno a muchos (por ejemplo una grilla de productos del cliente), hay que vigilar el desempeño en tablas con un gran número de registros (p.e desempeño general de la aplicación puede verse afectado en actualizaciones masivas de datos).
4. Entidades Virtualizadas y Paramétricas. Si se virtualiza una entidad, las entidades paramétricas relacionadas también deben estarlo. Si se virtualiza una entidad y las entidades paramétricas relacionadas no se virtualizan, se pueden tener errores como los del siguiente ejemplo: si se tiene la entidad Cliente y esta entidad tiene un tipo de documento que puede tener los valores 11, 22 y 33 (correspondientes a Cédula, TI, Cédula Extranjería), no se podría crear una entidad no virtualizada que tenga los tipos de documentos con esos códigos porque las llaves subrogadas Bizagi no corresponderían al relacionarla con la entidad virtualizada.
Se proponen a continuación 3 acciones para atacar la restricción:
Las siguientes 3 acciones han sido propuestas para lidiar con la restricción.
Acción1. Crear la entidad paramétrica en el sistema externo y virtualizarla.
Acción2. Crear una entidad paramétrica Bizagi y virtualizarla.
Acción3. Virtualizar usando formato XML para intercambiar los datos entre las peticiones de la interfaz virtualizada vía su interface de virtualización y la entidad paramétrica externa.
5. Filtros Complejos. Los filtros complejos suceden cuando se establece más de una condición para filtrar una entidad (usando conectores AND y OR), por ejemplo cuando se utiliza GetEntityList. Se presentan normalmente dos situaciones.
Cuando en el filtro sobre una entidad Virtualizada se combina filtro sobre un campo no virtualizado (sin correspondencia en la tabla externa) y filtro sobre un campo virtualizado. En estos casos se obtiene un error aparentemente porque Bizagi envía al sistema externo en la cláusula WHERE tanto el campo virtualizado como también el no virtualizado.
Acción1. Aplicar solo un filtro (por el campo virtualizado), y luego recorrer la estructura (dataset en caso .NET) resultante para aplicar los otros filtros.
Cuando en el filtro compuesto sobre la entidad virtualizada se filtra por dos o más campos que están virtualizados (con correspondencia en la entidad externa) en algunas ocasiones falla porque Bizagi no puede construir bien la cláusula WHERE que se envía al sistema externo para este tipo de situaciones.
Acción1. Aplicar solo un filtro (por el campo virtualizado), y luego recorrer la estructura (dataset en caso .NET) resultante para aplicar los otros filtros.
6. Operaciones en cadena para Entidades Virtualizadas. Es necesario tener en cuenta que las operaciones sobre entidades virtualizadas pueden generar actualizaciones o borrado en cadena sobre las entidades relacionadas; entonces, dichas operaciones deben ser cuidadosamente estudiadas para evitar actualizaciones no deseadas o muy demoradas en tiempo de ejecución. El modelo de la entidades virtuales debe estar perfectamente entendido y las implicaciones de las operaciones en cadena que pueden producirse consideradas como parte del análisis y selección de las entidades a virtualizar.
7. Preparación de datos antes de actualizaciones. Cuando el proceso necesita de la recolección de varios datos de diferentes actividades (o pantallas) antes de la actualización “definitiva” en las entidades virtualizadas, es necesario manejar un estado bien en la interfase de virtualización o bien en los servicios que provee la fuente de datos para evitar las actualizaciones automáticas que Bizagi ordena a la interfase de virtualización y “demorar” las actualizaciones hasta que los datos han sido recolectados, el caso más evidente es cuando los datos de entidades relacionadas con la entidad en cuestión no se conocen aun y son necesarios para la creación de una instancia de la entidad.
8. Utilizar replicación para entidades paramétricas. Las entidades paramétricas generalmente no son muy “dinámicas”. Si se pueden identificar con claridad aquellas que cambian muy poco, la opción de replicarlas desde la fuente de datos es una opción válida y que se puede adoptar como lineamiento general.
9. Servicios de validación de datos son responsabilidad del proceso. En general las validaciones (condiciones necesarias antes de la persistencia de datos, decisiones que permiten saber si una actividad puede finalizar o no) deben ser realizadas a nivel de proceso y no dentro de la interfase de virtualización. Cuando los datos van a persistir en una entidad virtualizada, se supone que toda validación de datos se hizo en la capa de presentación vía las facilidades Bizagi para realizar dichas validaciones.
<comments />
