<< Clic para mostrar Tabla de Contenidos >> Navegación:  Automatización de Procesos con poco código > Studio Cloud -ambiente de autoría > Bizagi Studio > Integrar aplicaciones externas desde Bizagi > Componentes personalizados > Recomendaciones para la Librería de componentes

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 (p.e 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 (p.e en 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 puede manejar y reportar debidamente cualquier incidente de esos componentes (p.e, cualquier bug o problema de rendimiento).

 

2. Siga las prácticas para lograr bajo acoplamiento

Es realmente importante que desde el diseño de las funciones de su componente, usted 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 vez, deberá retornar la información para que sea Bizagi desde las reglas de negocio quien lleve a cabo la actualización al modelo de datos.

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 y librerías de Bizagi dentro de sus componentes.

De lo contrario, usted no podrá actualizar la versión de Bizagi de su proyecto sin tener que re-compilar 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, la regla de librería es quien utiliza su componente y se puede reutilizar como una caja negra, utilizada en más de una regla de negocio.

Al hacerlo, la ventaja es que si la función de su componente debe cambiarse, entonces posiblemente únicamente se deba modificar la regla de librería así el componente se utilice en diversos puntos en el proceso.

Este mismo concepto aplica 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.

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

 

Se recomienda predefinir y diseñar que se puedan contemplar diversos niveles de detalle: información, alertas o errores.  

Al registrar en un repositorio centralizado, considere que al utilizar una solución en clúster, será útil imprimir el servidor sobre el cuál se ejecutó 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 (p.e para producir alertas automáticas cuando hayan registros de tipo error -crítico).

Lo anterior también deberá permitirle determinar el manejo que debe hacer a archivos para particionarlos cuando aplique (rotación de logs), o si deberá registrar la bitácora de manera asíncrona o en procesos paralelos para evitar la contensión (que la bitácora retrase la ejecución normal de la operación).

 

 

5. Permita una administración de parámetros

Como buena práctica, deberá tener una fuente central de configuración para que su componente lea parámetros desde allí, como por ejemplo un archivo de configuración.

A través de un archivo de configuración, 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 permite a los administradores cambiar la configuración y credenciales periódicamente, y posiblemente almacenar éstas de una manera encriptada.

Promueva una buena mantenibilidad al presentar un conjunto de parámetros que permita la fácil administración de todo aquello que sea sujeto a ser modificado de manera frecuente (p.e, el nombre de un servidor externo a conectarse o su dirección IP, una URL, etc).

•Permitir habilitar o deshabilitar la bitácora desde aquí, para poder definir qué detalle de trazas se desean tener (tal como se mencionó anteriormente).

Esto permite a los administradores poder recoger mayor información para diagnosticar un inconveniente sólo cuando sea estrictamente necesario.

•Soportar una configuración fácilmente adaptable a sus diferentes ambientes del proyecto (p.e típicamente un ambiente de Desarrollo, uno de Pruebas o 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 su código (las funciones de su componente) funcionen en cada uno de los casos de uso que éste debe soportar.

•Que su código funcione, y que haya sido explícitamente probado apuntando a un sistema de prueba donde se contemplen aspectos de rendimiento (con el sistema de prueba teniendo características similares al ambiente de producción).

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

Recuerde que es su responsabilidad tanto determinar como comunicar con su equipo, las capacidades y el límite de uso seguro de su componente (qué carga se soporta y cómo se debe usar).

Se recomienda que el componente no realice operaciones que consuman recursos en extremo (p.e, uso alto de CPU y RAM, o que el tiempo de ejecución esperado sea muy alto), dado que esto puede conllevar a deterioro en el rendimiento y ocasionar problemas a 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 (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 Actividades Asíncronas

Una vez que el componente esté listo para ser integrado en Bizagi y dado que el código personalizado en componentes usualmente terminan conectándose a otras aplicaciones externas (p.e sistemas legados, servicios web, o incluso aplicaciones como Excel), configure la ejecución del componente en Bizagi de manera ideal apoyándose en las Actividades 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 es más apropiado que el componente se ejecute como una tarea fuera de línea (en background, 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 permite que su ejecución minimice la posibilidad de bloqueos en tablas, potencialmente factibles cuando una transacción completa se alarga con los cambios realizados en las tareas manuales.

Al utilizar Actividades 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.

 

Last Updated 2/28/2024 9:58:14 AM