Proyectos Bizagi
Este artículo explica qué es un proyecto en Bizagi y presenta una lista de consideraciones para ayudarlo a decidir si desea automatizar en un solo proyecto o en múltiples proyectos.
Puede escuchar el término proyecto o instancia de proyecto. Ambas expresiones son iguales:
Piense en un proyecto de Bizagi como un archivo. Cada archivo es independiente entre sí; tiene derechos de acceso que se definen independientemente y sus equipos pueden trabajar de manera colaborativa. Un proyecto puede contener tantos procesos como sea necesario para llevar a cabo su iniciativa de automatización.
Los proyectos de Bizagi se automatizan en el entorno de desarrollo utilizando Bizagi Studio. Es allí donde usted define los flujos de procesos, la estructura de datos, las reglas de negocio y todos los componentes subyacentes de un proceso totalmente automatizado.
Cada proyecto requiere de su propio paquete independiente de ambientes: desarrollo, prueba y producción. Por lo tanto cada proyecto necesita de AL MENOS tres ambientes: el ambiente de desarrollo, un ambiente de pruebas y el ambiente de producción. Usted puede elegir si desea más ambientes de pruebas adicionales, como por ejemplo el llamado Staging.
Si usted está pensando en tener múltiples ambientes de Producción (y por lo tanto varios ambientes de desarrollo), usted necesita comprar un ambiente de desarrollo y un ambiente de producción INDEPENDIENTE para cada proyecto.
La siguiente imagen muestra la infraestructura de Bizagi y presenta cómo se aprovisionan múltiples proyectos.
En un solo proyecto, varios desarrolladores pueden trabajar colaborativamente, utilizando Bizagi Studio desde sus estaciones de trabajo y ejecutar el Portal de trabajo del entorno de desarrollo utilizando un navegador web. Cualquier cambio realizado por un desarrollador se ve reflejado en base de datos del proyecto, y todos los desarrolladores pueden ver los cambios reflejados.
Se usan múltiple proyectos para tener implementaciones completamente aisladas: cuando desea tener recursos en la nube independientes para cada proyecto, o un conjunto diferente de desarrolladores o se tiene un conjunto diferente de usuarios finales que acceden a cada entorno de producción.
Dado que se necesita un paquete independiente de entornos de desarrollo, prueba y producción cuando se trabaja con varios proyectos, cada de desarrollo independiente por proyecto CADA proyecto requiere sus propios entornos de prueba y producción.
Dependiendo de los escenarios de su negocio, ambos enfoques son igualmente válidos.
Tenga en cuenta que no se admite la combinación de información distribuida en varios proyectos.
Datos y metadatos compartidos
oEn un solo proyecto todos los desarrolladores comparten la misma estructura (modelo de datos), así como definiciones globales como Organización, definiciones de Seguridad, Reglas de negocio, entre otras. Todos los procesos creados comparten los metadatos y los datos. Un solo proyecto tiene entornos separados (desarrollo, pruebas y producción) con su propia URL y base de datos.
oEn múltiples proyectos, cada uno tiene su propia estructura. No se comparten datos ni metadatos entre ellos. Los equipos de desarrollo son independientes y los recursos en la nube están aislados de un equipo a otro. Cada proyecto tiene ambientes separados (un ambiente de desarrollo y su correspondiente pruebas y producción), con diferentes URLs y bases de datos segregadas por proyecto y por entorno.
Gestión de usuarios
La autenticación de Bizagi Studio para desarrolladores se configura independientemente del acceso de los usuarios finales en los ambientes de pruebas o producción (acceso al Portal de Trabajo).
Desarrolladores en Studio Cloud Services
Bizagi Studio es la herramienta utilizada por los desarrolladores para automatizar procesos. La autenticación para todos los proyectos se basa en el proveedor de identidad configurado en el Customer Portal. Más información sobre la autenticación en Customer Portal.
Puede configurar varios proveedores de identidad. Esto es útil cuando se desarrolla en un solo proyecto y los desarrolladores inician sesión con diferentes dominios. Obtenga más información sobre la autenticación múltiple en Customer Portal.
oEn un solo proyecto, hay un solo equipo de desarrollo. Los derechos de acceso para trabajar en el proyecto en Studio se otorgan a través del Customer Portal.
oEn múltiples proyectos, los derechos de acceso para cada proyecto son independientes. Si un usuario tiene acceso a un proyecto, se le debe otorgar acceso para trabajar en otro, si es necesario.
Usuarios finales en el Portal de Trabajo
El Portal de Trabajo es una aplicación web que permite a cada usuario realizar sus tareas y configuraciones correspondientes. Antes de trabajar en la aplicación, cada usuario debe identificarse ante el sistema para que solo las personas adecuadas puedan realizar dichas actividades. Lea sobre sobre el acceso al Portal de Trabajo.
Cada proyecto tiene su propia configuración de autenticación independiente. Además, cada ambiente dentro del proyecto (desarrollo-pruebas-producción) tiene su propia autenticación independiente, configurada en el Customer Portal.
El Portal de Trabajo soporta Autenticación Múltiple, para utilizar varios tipos de autenticación y dominios. Esta es común en un proyecto con usuarios de más de un dominio. Por ejemplo, si se accede a su proyecto desde diferentes ubicaciones y cada ubicación utiliza un proveedor de identidad diferente. Más información sobre la autenticación múltiple..
oMúltiples proyectos: si necesita aislar y separar todos los derechos de acceso de los usuarios finales a los procesos de un proyecto, considere la posibilidad de crear varios proyectos. Recuerda que cada proyecto tiene su propia URL y configuración de autenticación.
Administradores en el Portal de Trabajo
El Portal de Trabajo es administrado por usuarios finales con roles específicos que otorgan acceso a los diferentes menús de administración.
oCuando se trabaja en un proyecto único que contiene procesos gestionados por personas de diferentes departamentos o incluso organizaciones, es importante tener en cuenta la gestión de usuarios.
La gestión de usuarios dentro del Portal de Trabajo no está segregada por departamentos u organizaciones. Los usuarios administradores que accedan al menú de administración de usuarios podrán buscar y administrar TODOS los usuarios finales del proyecto.
Administradores de proyecto en Management Console
El Management Console (MC) es una aplicación basada en la web que le permite administrar los parámetros de cada ambiente (desarrollo, pruebas, producción), como los puntos de integración y la configuración de autenticación o autorización. No hay diferencia en este portal cuando se tiene uno o varios proyectos.
Los siguientes roles en el Customer Portal tienen acceso a ese MC, de forma independiente para cada proyecto: administrador de la compañía, dueño de la suscripción de Studio, dueño del proyecto de Studio y colaborador de Studio.
Despliegues (deployments)
oProyecto único: todos los paquetes desplegados en los ambientes de prueba o producción deben provenir siempre del mismo ambiente de desarrollo. Durante un despliegue, se muestra una ventana de mantenimiento durante unos segundos.
oMúltiples proyectos: todos los paquetes implementados en el entorno de prueba o producción siempre deben provenir del mismo entorno de desarrollo. Mientras se muestra una ventana de mantenimiento durante algunos segundos, exclusivamente en el entorno de destino, ningún otro entorno se ve afectado.
Administración de proyectos
Todos los proyectos y sus ambientes (dev-test-prod) se gestionan a través del Portal del Cliente.
Cada proyecto tiene derechos de acceso definidos que son independientes de los otros proyectos. Sin embargo, los administradores de la empresa pueden gestionar todos los proyectos.
Cuando la suscripción requiera mantenimiento o si hay una actualización de versión para cualquiera de los productos o proyectos, todos los productos y proyectos serán parte del tiempo de inactividad.
Más información sobre el Portal del cliente
Conozca los diferentes roles en el Portal del cliente.
Ejecutando el Portal de Trabajo
oProyecto único: cada vez que se inicia el Portal de trabajo desde Studio, la herramienta realiza un pequeño despliegue y la aplicación web dejará de estar disponible durante unos segundos.
oMúltiples proyectos: ejecutar el Portal de Trabajo es completamente independiente de un proyecto a otro. Si el Portal de Trabajo está no disponible, solo afecta al proyecto donde ocurre la ejecución.
VPN y Recuperación de desastres (DR)
•El Servicio de Recuperación de Desastres (DRS) es INDEPENDIENTE para cada ambiente de Producción. Por ejemplo, si un cliente tiene tres entornos de producción, puede comprar uno, dos o tres DRS.
•Una sola VPN se necesita para toda la suscripción: Studio Cloud Services y Automation Services, incluidos todos los ambientes. Sin embargo, se debe comprar una VPN adicional al adquirir el Servicio de Recuperación de Desastres.
•Una misma definición de lista blanca de IP cubre todos los servicios, proyectos y ambientes en la nube de la suscripción.
Consideraciones para configurar el desarrollo de seguridad en un solo proyecto
Bizagi ofrece una variedad de posibilidades de configuración con respecto al acceso del desarrollador a los recursos en Bizagi Studio y el acceso del usuario final en tiempo de ejecución (prueba y producción). Hay muchos niveles en los que puede configurar permisos.
Estructura del proyecto |
Para lograr mayores niveles de segregación, sugerimos desglosar y categorizar los procesos en diferentes Aplicaciones de Bizagi Studio. Use Aplicaciones cuando tenga diferentes equipos desarrollando sobre un solo proyecto, y cuando sus procesos sean independientes. Las Aplicaciones permiten una mejor organización del proyecto y facilitan la gestión de permisos para los usuarios finales en el Portal de Trabajo. Al restringir el acceso a una Aplicación, los usuarios no podrán crear nuevos casos de ningún proceso que pertenezca a esa aplicación y no podrán ver los casos relacionados con dichos procesos en su Bandeja de entrada ni Reportes. Sin embargo, esto implica que no hay reutilización entre procesos. |
Seguridad de Bizagi Studio |
Restrinja el acceso a los recursos de Studio para evitar que los desarrolladores modifiquen algo que no forma parte de sus responsabilidades. De forma predeterminada, cada proyecto permite a los desarrolladores acceder a todos los objetos del proyecto. Recomendamos habilitar la Seguridad de Bizagi Studio para asegurarse de que los usuarios correctos tengan acceso a los recursos correctos del proyecto. |
Definición de asignados |
En el quinto paso del Asistente de procesos, defina los actores (usuarios finales) de cada tarea definiendo las cualidades que se deben asignar. Solo aquellos usuarios que cumplan con los criterios de asignación tendrán la tarea disponible para actuar. |
Derechos de acceso a menús y procesos |
Establezca derechos de acceso a los elementos del Portal de Trabajo. Cuando los usuarios finales no pueden acceder a un elemento, no podrán verlo. El elemento restringido solo será visible para los usuarios finales con derechos de acceso. Estos derechos se administran a través de la definición de Seguridad en Studio o en el Management Console. |
Seguridad de casos |
Puede definir derechos de acceso para casos en el Portal de trabajo, de modo que los usuarios sin privilegios no puedan ver ninguna información sobre un caso. En un escenario sin personalización de la seguridad, cualquier usuario final puede encontrar un caso y, en la tabla de resultados, acceder a toda su información relacionada. |
Last Updated 5/6/2022 5:13:33 PM