Introducción
La Librería de Componentes le permite extender la funcionalidad en Bizagi; al incluir código personalizado para ser usado en la lógica detrás de sus procesos.
A través de dicho código personalizado usted puede integrarse con otras aplicaciones, o extender cualquier procesamiento y operaciones generales que sus procesos ejecuten.
El código personalizado se incluye a través de la Librería de Componentes al registrar y cargar los ensamblajes DLL (componentes) en Bizagi.
Puedes incluir cualquier número de componentes y luego elegir usarlos directamente desde las reglas de negocio de Bizagi.
Para obtener información introductoria sobre esta característica, consulte Componentes personalizados.
Pautas
Es común que los componentes personalizados se conecten a aplicaciones y servicios externos, o a sistemas y bases de datos heredados.
Dado que la codificación de los componentes no está restringida, sino que depende de usted para producir a través del IDE instalado, considere las siguientes pautas:
1. Siga las prácticas de bajo acoplamiento
Dentro del diseño de las funciones de su componente, es importante considerar las mejores prácticas y un diseño que haga que su componente esté bajamente acoplado.
Esto implica que sus funciones deben tener entradas y salidas bien definidas que nunca actualicen la información directamente en Bizagi, sino que devuelvan la información para que cualquier actualización sea hecha dentro de las reglas de negocio por el propio Bizagi.
Un componente que está estrechamente acoplado a Bizagi no proporcionará una buena mantenibilidad a lo largo del tiempo.
2. Diseño para promover la sostenibilidad
Para evitar añadir gastos generales en las tareas administrativas, evite incluir referencias a los ensamblajes de Bizagi directamente en sus componentes.
Si incluye tales referencias, no podrá actualizar la versión de Bizagi de su proyecto sin reconstruir el componente.
Para un mejor diseño de mantenimiento, considere el uso de las reglas de la Librerías de Bizagi.
De esta manera su regla de librería utiliza su componente, y usted puede reutilizarlo como una caja negra, que puede invocar desde más de una regla de negocio.
Al hacer esto, si la función de su componente cambia, sólo necesita modificar esa regla de la Biblioteca aunque sea usada por más de un punto.
El mismo concepto se aplica si necesita aplicar transformaciones XSLT antes de que el componente envíe la información final a un sistema externo (o después de que reciba una respuesta de él), en cuyo caso puede optar por manejar las transformaciones dentro de una regla de la Biblioteca.
3. Registre los detalles sólo para el ambiente de Desarrollo
Asegúrese de que cualquier opción de registro en su componente sea aplicable sólo al ambiente de Desarrollo, para ayudarle a diagnosticar problemas al construir ese componente.
Además de asegurarse de que el componente detecta y arroja errores de forma adecuada, asegúrese de que puede tener un registro detallado siempre que el rastreo de su componente esté habilitado, el registro de detalles afecta al rendimiento y, por lo tanto, debe evitar registrar mucha información de forma temporal, cuando la necesite para investigar un problema.
Diseñe su componente de manera que pueda permitir el registro en diferentes niveles de rastreo: información, advertencias o errores.
Además de informar sobre el tipo de rastreo, debería al menos imprimir el mensaje detallado, la fecha y la hora.
Cuando realice un registro detallado, decida si desea guardar el rastro en el registro del servidor (es decir, en el visor de eventos), en una base de datos externa o en archivos. Si se registra en un registro central y se utiliza una configuración de clúster, considere la posibilidad de guardarlo en el servidor que ejecuta el componente.
Evaluar las ventajas y desventajas de cada opción, entre ellas: los derechos para iniciar la sesión en esa fuente, el consumo de recursos (gastos generales de procesamiento y uso de memoria al iniciar la sesión) y la viabilidad de vigilar esa información (es decir, producir alertas automáticas en los registros de errores -nivel crítico-).
Debería ser posible establecer el tamaño en el que se dividen los archivos de registro, si procede (rotación de los registros), o si es necesario registrar de forma asincrónica o en paralelo para evitar que el registro procese sus operaciones primarias.
|
Un registrador que maneja rastros puede ser útil como una clase reutilizable, porque si su proyecto utiliza más de un componente, todos deberían poder confiar en su utilidad. |
4. Permita la administración de parámetros
Como mejor práctica, debe hacer que su componente lea los parámetros desde una fuente de configuración central, y para ello, puede confiar en las opciones personalizadas de Bizagi.
De esta manera, a través de una regla de negocio usted envía esta información como parámetros de entrada, y su componente:
•Cumplir con las prácticas de seguridad asegurando que las credenciales (es decir, para autenticar a un servicio) no están codificadas en forma dura, sino que se manejan por separado.
•Promover la mantenibilidad presentando un conjunto de parámetros, donde pueda gestionar fácilmente la información que está sujeta a cambios, como la URL de un servicio externo o el nombre de un servicio.
•Apoyar una configuración que se adapte fácilmente a los diferentes ambientes de su proyecto (típicamente, los ambientes de Desarrollo, Prueba y Producción).
5. Realice las pruebas adecuadas antes de integrarse en Bizagi
Antes de integrar el componente en Bizagi y ejecutarlo a partir de sus reglas de negocio, realice las pruebas adecuadas para asegurarse de ello:
•Su código (las funciones de su componente) funciona en cada uno de los casos de uso predefinidos que debe soportar.
•Su código funciona, y es probado explícitamente cuando se apunta a un sistema de prueba para poder validar su desempeño (con el sistema de prueba teniendo condiciones similares a las del ambiente de Producción).
•Considere la posibilidad de realizar pruebas de carga y estrés apropiadas, si corresponde, para anticiparse a la forma en que su componente responde en condiciones de carga máxima.
Es su responsabilidad determinar, y comunicar a su equipo, los límites de uso seguro de su componente.
Evite que el componente realice operaciones que requieran muchos recursos (es decir, que utilicen mucha CPU, RAM o que impliquen mucho tiempo), ya que esto podría llevar a un deterioro del rendimiento que cause problemas para otros procesos que se ejecuten en el servidor al mismo tiempo.
Si el componente tiene que realizar operaciones que requieren muchos recursos, considere medidas para asegurarse de que puede escalar sus recursos, o manejar las operaciones de forma adecuada (utilizando tiempos de espera, cerrando conexiones o instancias del programa siempre y cuando se produzcan eventos inesperados, etc.).
Una vez que haya verificado que su componente es estable para las especificaciones previstas, puede probar el componente integrándolo en Bizagi.
6. Considere la ejecución de los componentes a través de tareas asincrónicas
Una vez que el componente esté listo para ser integrado en Bizagi, configure la ejecución de su componente en Bizagi usando tareas asíncronas (útil para la mayoría de los escenarios).
Si su componente apunta a un servicio externo y realiza un procesamiento significativo, puede haber retrasos (o incluso tiempos muertos ocasionales), y es más apropiado que el componente se ejecute como una tarea de fondo (fuera de línea en términos del Portal de Trabajo), con un tiempo muerto predefinido y un número de reintentos automáticos.
La ejecución asincrónica evita posibles bloqueos en las tablas, que pueden ser un riesgo al comprometer una transacción en cola de una actividad manual.
Cuando se utilizan tareas asíncronas, es necesario realizar pruebas de aceptación del usuario con la configuración adecuada antes de añadir el componente a un ambiente de producción.
|
Bizagi gestiona las transacciones y lleva a cabo una reducción de las tareas y la información dentro de Bizagi, si hay un fallo en algún momento. Asegúrese de tomar esto en cuenta en el diseño del flujo de trabajo de su proceso para que pueda limitar las acciones y actividades que se agrupan en una sola transacción (y el rollback si se produce un fallo). Bizagi no hará rollback de una operación que ya ha sido enviada y disparada en una aplicación externa. |
7. Los componentes deben ser autónomos
Autocontenido en este contexto significa que un componente cargado a través de la Librería de Componentes tiene todo lo que necesita para ejecutarse.
Los componentes personalizados no deben buscar otros controladores, plantillas o archivos en rutas específicas, o cualquier otro conjunto instalado localmente.
8. Rendición de cuentas y seguridad del código
Asegúrese de que los componentes se construyan de forma segura y no contengan código malicioso.
Usted, como cliente, es completamente responsable del código que desarrolle y de los componentes personalizados que suba a Bizagi.
Bizagi no es responsable del contenido inadecuado del componente, de lo que hace o de cómo funciona.
9. Rendimiento e integración cuando se utiliza una VPN
Si su componente apunta a un activo en el lugar (como un sistema, servicio o base de datos) que no ofrece un punto final público, entonces requiere el uso de una VPN.
Cuando se utiliza una VPN, es necesario evaluar de antemano (mediante pruebas de concepto) si el impacto en el rendimiento de la conexión a un activo local desde la nube es adecuado para los requisitos de sus aplicaciones empresariales.
Considere variables como el volumen de datos que se intercambian con su fuente de datos in situ.
Para obtener más información sobre una VPN y sus requisitos, consulte Integración utilizando una VPN.
10. Implementación de mejoras
Una vez que los procesos empresariales se han desplegado en el ambiente de Producción, no se pueden borrar los componentes registrados en la Librería de Componentes que utilizan estos procesos.
Por lo tanto, considere lo siguiente en caso de que necesite desplegar modificaciones en ese proceso:
•Puede optar por crear una nueva versión del proceso que utilice componentes diferentes o ningún componente personalizado.
•Edite los componentes en la Librería de Componentes en el ambiente de Desarrollo (a través de Bizagi Studio) para soportar los cambios que usted está haciendo a un proceso de negocio. Luego suba un ensamblaje DLL diferente.
Cuando se edita un componente, no se pueden cambiar los detalles principales del componente como su nombre o espacio de nombres.
Cuando usted cambia un componente personalizado, usted tiene que llevarlo a través de los ciclos de despliegue habituales a través de pruebas y puesta en escena antes de desplegarlo en el ambiente de Producción.