Arquitectura técnica de Camunda del motor de proceso de código abierto
Camunda es un marco basado en Java que admite BPMN para la automatización de procesos y flujos de trabajo, CMMN para la gestión de casos y DMN para la gestión de decisiones empresariales.
En esta publicación de blog, solo consideraremos el motor de procesos BPMN y dejaremos de lado los motores CMMN y DMN por ahora. En lo que respecta a los motores de procesos, Camunda es un marco de flujo de trabajo flexible cuyo núcleo es un motor de procesos BPMN 2.0 nativo que se ejecuta en la máquina virtual Java, por lo que puede integrarse en cualquier aplicación Java o contenedor de tiempo de ejecución. Camunda está integrado con Java EE y funciona perfectamente con Spring Framework y Spring Boot.
Utilizamos el diagrama de arquitectura oficial para explicar y analizar qué funciones incluye Camunda BPMS.
1. Desde la perspectiva de la aplicación BPM
Camunda se divide en dos etapas: diseño del proceso y operación del proceso. Consulte las flechas azules en la parte inferior de la imagen, Modelo y Ejecución. Según esto En las dos etapas, Camunda se divide en dos funciones principales: las funciones correspondientes a la etapa de diseño son Modelador y las funciones correspondientes a la etapa de ejecución son Motor, Lista de tareas, Cabina y Administrador.
2. Desde la perspectiva de las funciones BPM
Camunda incluye diseñador de procesos (Modeler), motor de procesos (Engine), interfaz API (REST/Java API), lista de tareas (TaskList) , consola de gestión de procesos (Cockpit) y herramienta de gestión del sistema (Admin). Los productos comerciales de Camunda también incluyen herramientas de monitoreo y alerta temprana de procesos (Optimize) y herramientas de diseño colaborativo de procesos (Cawemo). Aquí primero nos centramos en el diseñador de procesos Camunda. Admite dos modos: uno es la herramienta de modelado de procesos del cliente enriquecido Camunda Modeler, que debe instalarse en el cliente. son de código abierto.
3. Desde la perspectiva de los roles BPM
Camunda se divide en varios roles: analistas de negocio, ingenieros de desarrollo de procesos, usuarios finales, administradores de procesos y administradores de sistemas. Cada rol corresponde. diferentes funciones del BPMS. Los analistas de negocios y los ingenieros de desarrollo de procesos usan el diseñador de procesos (Modeler) para el modelado de procesos, los usuarios finales usan la lista de tareas (TaskList) para el inicio y aprobación de procesos, y los administradores de procesos usan la consola de administración de procesos (Cockpit) para la administración de procesos, como System los administradores utilizan la herramienta de administración del sistema (Admin) para la administración del sistema, como la suspensión y recuperación de procesos, etc. Los administradores del sistema utilizan la herramienta de administración del sistema (Admin) para la administración del sistema, como la administración de usuarios organizacionales, la administración de permisos, etc.
1. Admite la integración con el marco Spring
Camunda admite la integración con el marco Spring El marco camunda-engine-spring está integrado en el módulo maven del proyecto. integrado con Spring 3 y 4 o la versión 5. El proceso de integración específico se presentará en un artículo separado más adelante.
2. Admite la integración con Spring Boot
Las características del último artículo son
3. Admite la integración con CDI y Java EE
CDI (Inyección de contexto y dependencia) es un marco Java EE.
CDI (Inyección de contexto y dependencia) es un estándar para Java EE6 y la inyección de dependencia, y Camunda se integra con el módulo camunda-engine-cdi para aprovechar la capacidad de configuración del motor camunda y la extensibilidad de cdi.
4. Admite la integración con contenedores de tiempo de ejecución
Admite la integración con contenedores de tiempo de ejecución comunes (como Tomcat y JBoss).
Camunda BPM es un marco flexible que admite modelos de implementación integrados, distribuidos, en clústeres y otros.
1. Implementación integrada
El motor de proceso se agrega a la aplicación como un paquete Jar, a través del cual el motor de proceso se puede iniciar y detener fácilmente durante el ciclo de vida de la aplicación.
2. Según el inicio de los contenedores web, se pueden disfrutar de múltiples aplicaciones
El motor de proceso se inicia en el contenedor de tiempo de ejecución (contenedor de servlet, servidor de aplicaciones, etc.) y el motor de proceso sirve como contenedor. El servicio proporciona que todas las aplicaciones implementadas en el contenedor puedan utilizar el motor de proceso. Este método no es común en escenarios de aplicaciones prácticas.
3. Implementación independiente, disfrute de múltiples aplicaciones****
En este caso, el motor de proceso se implementa de forma independiente, el servicio se proporciona a través de la red y se ejecutan diferentes aplicaciones. en la red puede ser El canal de comunicación remota interactúa con el motor de proceso. La forma más sencilla de acceder al motor de proceso de forma remota es utilizar la interfaz de servicio REST incorporada. Este es uno de los patrones de implementación más comunes en las arquitecturas de implementación centradas en procesos a nivel empresarial y también se puede adoptar en las arquitecturas de implementación de microservicios actuales.
4. Implementación del clúster
Para proporcionar capacidades de expansión o conmutación por error, el motor de procesos se puede distribuir a diferentes nodos en el clúster y cada instancia del motor de procesos debe estar conectada a * ** *-base de datos de disfrute. Camunda BPM no proporciona equilibrio de carga listo para usar, lo que requiere el uso de software de equilibrio de carga de terceros (como nginx).
Este artículo presentará bibliotecas de terceros y su uso en Camunda. Para cada componente de Camunda, se enumeran bibliotecas de terceros. Para cada biblioteca, explicamos si la biblioteca es una dependencia obligatoria o una dependencia opcional. Las dependencias requeridas son bibliotecas en las que Camunda confía para proporcionar la funcionalidad principal. Están marcados (dependencias obligatorias) en la lista siguiente. Las dependencias opcionales son bibliotecas que se pueden integrar con Camunda. Están marcados (dependencias opcionales) en la siguiente lista.
Las siguientes bibliotecas de terceros dependen de Camunda 7.15:
1.
Motor de procesos
El motor de procesos depende de lo siguiente Biblioteca de terceros:
marco de mapeo MyBatis (requiere dependencias), utilizado para mapeo relacional de objetos.
Joda Time (requiere dependencia), utilizado para analizar formatos de fecha. Consulte la documentación sobre Id-Generators
Interfaz de registro SLF4J (requiere dependencias)
Además, el motor de procesos puede integrar:
Para analizar formatos de fecha Joda Time ( requiere dependencias).
Apache Commons Email (dependencia opcional) se utiliza para soporte de tareas de correo electrónico.
Spring Framework Spring-Beans (dependencia opcional) se utiliza para la configuración mediante camunda.cfg.xml.
Spring Framework Spring-Core (dependencia opcional) se utiliza para la configuración mediante camunda.cfg.xml.
Groovy (dependencia opcional) para soporte de tareas de script groovy.
Jython (dependencia opcional) para soporte de tareas de script Python.
JRuby (dependencia opcional) para soporte de tareas de script Ruby.
Freemarker (dependencia opcional), soporta el motor de plantillas de freemarker.
Apache Velocity (dependencia opcional), soporta apache.
SAXON (dependencia opcional), soporta motores de plantillas XSLT y XQuery.
2.API REST
2.strong>
La API REST depende de las siguientes bibliotecas de terceros:
Jackson JAX- RS (requiere dependencia) Proveedor de tipo de contenido JSON
Apache Commons FileUpload (requiere dependencia)
Además, cuando se utiliza Apache Tomcat:
RESTEasy (requiere dependencia)
3. Soporte de Spring
El soporte de Spring se puede integrar con las siguientes bibliotecas de terceros:
Apache Commons DBCP (dependencia opcional)
Spring Framework Spring-Beans (dependencia opcional)
Spring Framework Spring-Core (dependencia opcional)
Spring Framework Spring-ASM (dependencia opcional)
Spring Framework Spring-Context (dependencia opcional)
Spring Framework Spring-JDBC (dependencia opcional)
Spring Framework Spring-ORM (dependencia opcional)
Spring Framework Spring -TX (dependencia opcional)
4.Camunda Spin
Camunda Spin depende de las siguientes bibliotecas de terceros:
Jackson Json (requiere dependencia), por Compatibilidad con el formato de datos Json
Además, Camunda Spin también se puede integrar con las siguientes bibliotecas:
Jayway Json Path (dependencia opcional), para compatibilidad con rutas Json
5.Camunda Connect
Camunda Connect depende de las siguientes bibliotecas de terceros:
Componente Apache Http para soporte REST y SOAP (requiere dependencias)
1 Entorno de desarrollo Java compatible
?Versión de Java: 8 / 9 / 10 / 11 / 12 / 13 / 14
?Versión de Springboot: 2.3. p> 2. Entorno de ejecución Java compatible
?Oracle JDK 8 / 9 / 10 / 11 / 12 / 13 / 14
?IBM JDK 8 (con J9 JVM)
?OpenJDK 8 / 9 / 10 / 11 / 12 / 13 / 14
3. Software de base de datos compatible
? MySQL 5.6 / 5.7
?MariaDB 10.0 / 10.2 / 10.3
?Oracle 11g / 12c / 18c / 19c
?IBM DB2 10.5 / 11.1
?PostgreSQL 9.4 / 9.6 / 10.4 / 10.7 / 11.1 / 11.2 / 12.2
?Microsoft SQL Server 2012/
2014/2016/2017
?H2 1.4
4. Servidores de aplicaciones compatibles
?Apache Tomcat 7.0 / 8.0 / 9.0
? JBoss EAP 6.4 / 7.0 / 7.1 / 7.2
?Wildfly Application Server 10.1
?IBM WebSphere Application Server 8.5 / 9.0 Enterprise Edition
?Oracle WebLogic Server 12c (12R2) Edición Enterprise
5. Navegadores compatibles
?Google Chrome
?Mozilla Firefox
Microsoft Edge
6. Sistemas operativos compatibles con Process Designer
?Windows 7 / 10
?Mac OS X 10.11
?Ubuntu LTS
?