Introducción
La Librería de componentes provee la posibilidad de extender la funcionalidad de Bizagi, al permitirle incluir código a la medida para usarse en la lógica detrás de sus procesos.
Usted podrá registrar dentro de la Librería de componentes, cualquier número de componentes con código personalizado que se ejecuta directamente desde las reglas de negocio de Bizagi.
Recomendaciones
Bajo la premisa anterior, es muy común que los componentes personalizados se conecten con aplicaciones externas (como sistemas legados, bases de datos, aplicaciones del sistema operativo, etc).
Por lo tanto y dado que el código del componente no es restringido, asegúrese de considerar los siguientes lineamientos para minimizar riesgos y problemas potenciales causados por la personalización de la solución:
1. Evalúe las librerías referenciadas (APIs de terceros)
Cuando se haga referencia a librerías o APIs de terceros, asegúrese de evaluar si podrá compilar el componente final de acuerdo a la arquitectura de sistema de su servidor de producción (modo 64 bits o modo 32 bits).
Considere opciones de configuración adicionales en caso de que no sea posible tener un componente compatible a la arquitectura (por ejemplo, opciones como publicar las funciones como un servicio Web, aparte de Bizagi).
Al evaluar estas librerías de terceros, se deberá tener soporte de ese fabricante para que su proyecto pueda manejar y reportar debidamente cualquier incidente de esos componentes (por ejemplo, cualquier bug o problema de rendimiento).
2. Siga las prácticas para lograr bajo acoplamiento
Desde el diseño de las funciones de su componente, considere las mejores prácticas y un diseño que promueva el bajo acoplamiento en la solución.
Esto implica que las funciones deberán tener datos de entrada y de salida bien definidos, y que el componente jamás deberá actualizar la información directamente en Bizagi. En cambio, deberá retornar la información para que sea Bizagi desde las reglas de negocio quien lleve a cabo la actualización.
Desarrollar un componente que sea altamente acoplado a Bizagi no le proveerá una buena mantenibilidad de la solución a futuro.
3. Diseñe y utilice promoviendo la mantenibilidad
Para no incurrir en tareas administrativas recurrentes, evite incluir referencias directas a ensamblados de Bizagi dentro de sus componentes.
De lo contrario, usted no podrá actualizar la versión de Bizagi de su proyecto sin tener que recompilar el componente.
De manera adicional y si desea considerar mejores opciones de mantenibilidad, considere el uso de Reglas de librería de Bizagi.
De esta manera, su Regla de librería utiliza el componente, y usted puede reutilizar esa regla como una caja negra, invocándola desde más de una regla de negocio.
Al hacerlo, la ventaja es que si la función de su componente debe cambiarse, entonces únicamente deberá modificar la regla de librería así el componente se utilice en diversos puntos en el proceso.
Este mismo concepto aplica si usted necesita aplicar transformaciones XSLT antes de que el componente envíe la información final al sistema externo (o para procesar la respuesta que recibe de vuelta), en cuyo caso podrá decidir manejar estas transformaciones dentro de una Regla de librería.
4. Incluya opciones de bitácora
Asegúrese de incluir opciones que permitan que su componente escriba una bitácora, de manera que en un ambiente de producción se pueda contar con los medios para diagnosticar inconvenientes específicos sobre ciertos escenarios y registrar trazas que le ayuden a monitorear la salud del sistema.
Aparte de manejar los errores apropiadamente (catch y throw), asegúrese de poder registrar el debido detalle cuando su componente tenga la opción de bitácora habilitada (tenga en cuenta que registrar en una bitácora sacrifica un poco el rendimiento, y por lo tanto no se debe registrar mucha información a menos de que se habilite temporalmente).
Predefina y diseñe su componente para que pueda registrar diversos niveles de detalle: información, alertas o errores.
Además del tipo de traza, debe imprimir como mínimo el mensaje detallado y la fecha/hora (timestamp).
Al registrar en un repositorio centralizado, considere imprimir el servidor que ejecuta el componente.
Evalúe las ventajas y desventajas de cada alternativa, teniendo en cuenta variables como: los permisos necesarios para escribir allí, los recursos que se consumen para ello (carga de procesamiento o manejo de memoria), y la factibilidad de monitorear esta información (para producir alertas automáticas cuando haya registros de error de nivel crítico).
Utilice lo anterior para determinar el tamaño en que debe particionar los archivos de bitácora cuando aplique (rotación de logs), y si necesita registrar de manera asíncrona o en paralelo para evitar que la bitácora retrase sus operaciones principales.
|
La funcionalidad de bitácora que pueda manejar niveles de trazas debería ser una clase reutilizable, dado que si su proyecto usa más de un componente, este utilitario será de gran ayuda para todos los componentes. |
5. Permita una administración de parámetros
Como buena práctica, su componente debe leer parámetros desde una fuente central de configuración, como por ejemplo un archivo de configuración. De esta manera, su componente podrá:
•Cumplir con prácticas de seguridad al asegurarse que las credenciales de acceso a cualquier sistema (o a una base de datos, o ruta específica) no queden quemadas en el código, sino que vayan dentro del archivo de configuración. Esto también permite a los administradores cambiar la configuración y las credenciales periódicamente, y almacenarlas de forma encriptada.
•Promover una buena mantenibilidad al presentar un conjunto de parámetros que permita administrar fácilmente todo aquello que sea sujeto a modificación frecuente, como el nombre de un servidor externo, su dirección IP, o una URL.
•Permitir a los administradores habilitar o deshabilitar la bitácora en cualquier momento, con diferentes niveles de detalle (tal como se mencionó anteriormente), para que puedan recoger mayor información únicamente cuando surja un inconveniente que requiera diagnóstico.
•Soportar una configuración fácilmente adaptable a sus diferentes ambientes del proyecto (típicamente un ambiente de Desarrollo, uno de Pruebas y uno de Producción).
6. Realice pruebas adecuadas antes de la integración con Bizagi
Antes de integrar el componente con Bizagi y ejecutarlo desde los procesos (específicamente desde reglas de negocio), asegúrese de haber llevado a cabo pruebas de aceptación donde se valide:
•Que las funciones de su componente funcionen en cada uno de los casos de uso que éste debe soportar.
•Que su código haya sido probado explícitamente en un sistema de prueba con condiciones similares a las del ambiente de producción, de manera que pueda validar su rendimiento real.
•La ejecución de pruebas de carga cuando aplique (pruebas de stress), de manera que usted se pueda anticipar a cómo su componente responderá bajo cierta exigencia de procesamiento (picos altos de carga).
También es su responsabilidad determinar y comunicar a su equipo los límites de uso seguro de su componente (cómo debe usarse).
Evite que el componente realice operaciones que consuman recursos en extremo (uso alto de CPU y RAM, o tiempos de ejecución prolongados), dado que esto puede conllevar a deterioro en el rendimiento y ocasionar problemas para otros procesos que se ejecutan paralelamente en el servidor.
En caso de que lo anterior sea estrictamente necesario, considere las medidas adecuadas para garantizar que usted pueda escalar los recursos en su infraestructura, o manejar este tipo de operaciones de la mejor manera (por ejemplo, usando tiempos de espera, cerrando conexiones o instancias de programas siempre y ante eventos inesperados, etc).
Únicamente cuando haya verificado que su componente es estable cumpliendo las especificaciones de su diseño, podrá proceder a probar el componente integrado con Bizagi.
7. Considere la ejecución a través de Tareas Asíncronas
Una vez que el componente esté listo para ser integrado en Bizagi y dado que el código personalizado en componentes usualmente termina conectándose a otras aplicaciones externas (ya sean sistemas legados, servicios web, o incluso aplicaciones como Excel), configure la ejecución del componente en Bizagi de manera ideal apoyándose en las Tareas Asíncronas (usualmente la mejor opción para la mayoría de escenarios).
Esto se debe a que la conexión con aplicaciones externas puede implicar cierta demora (o ocasionalmente agotar un tiempo de espera), y el componente debe ejecutarse como una tarea en segundo plano (fuera de línea, y no por el Portal de Trabajo), donde se puede predefinir un tiempo de espera de la ejecución, y reintentos automáticos.
Esto también evita posibles bloqueos en tablas que podrían producirse al confirmar (commit) una transacción en cola, originada por una actividad manual.
Al utilizar Tareas Asíncronas, tenga presente que igual deberá realizar pruebas de aceptación adecuadas bajo esta configuración antes de llevar estos cambios a un ambiente de producción.
|
Considere que Bizagi administra las transacciones y lleva a cabo un rollback de las tareas y la información dentro de Bizagi, en caso de que se produzca una falla en algún punto. Asegúrese de tener claro este manejo desde el diseño del flujo de sus procesos, de manera que usted pueda prever qué acciones y actividades son agrupadas bajo una misma transacción (y consideradas en un rollback ante una eventualidad). Bizagi no hará rollback de operaciones que ya se hayan enviado y disparado en una aplicación externa. |
Last Updated 19/10/2026 4:05:28 p. m.