integrated mode
Camunda supports three engine modes with the following characteristics:
- Container-managed Engine: The process engine will run in the JVM as an independent component, managed by the CAMUNDA container, that is, the official management system comes with it.
- Embedded Engine: The process engine will be embedded in your application and managed directly by the application, so you can get better control and performance.
- Remote Engine: The process engine will run in another JVM as an independent component, run as a remote BPM server, and interact with the remote engine through RMI or HTTP communication.
The first method is actually a general practice of large-scale functional components, that is, it not only has core functions, but also has auxiliary functions such as management and monitoring to form a system that can run independently and achieve the purpose of out-of-the-box.
The third way is to run as an independent service, which is equivalent to shallow integration and is only called through the rest api. It is suitable for non-java technology stacks (such as c#) or micro-service architectures and remains relatively independent.
The second method is often called deep integration, which embeds the engine into the application program, so that the performance is the best, the control is stronger, and the local java method can be directly called, and the library table of Camunda can be directly accessed, which is suitable for some complex In the case of business, write sql statements to query or write data into tables.
To sum up, platform integration adopts the second mode, deep integration.
initialization
new module
First create a new functional module, follow the unified naming rules of the platform, name it platform-workflow, and inherit from the platform
<parent>
<groupId>tech.abc</groupId>
<artifactId>abc-development-platform</artifactId>
<version>2.0.0</version>
</parent>
<groupId>tech.abc</groupId>
<artifactId>platform-workflow</artifactId>
<packaging>jar</packaging>
<version>2.0.0</version>
<name>platform-workflow</name>
<description>工作流</description>
Modify the pom file of the project and include the module into the project
<modules>
<module>platform-common</module>
<module>platform-system</module>
<module>platform-framework</module>
……
<!--本次新增-->
<module>platform-workflow</module>
……
<module>platform-boot-starter</module>
</modules>
add dependencies
Check the current latest version, which is 7.19. The 7.13 used in the integration three years ago, the version difference is not big, use the latest version, add the dependency on Camunda,
<!-- 工作流 -->
<dependency>
<groupId>org.camunda.bpm.springboot</groupId>
<artifactId>camunda-bpm-spring-boot-starter</artifactId>
<version>7.19.0</version>
</dependency>
The workflow will involve department personnel, user groups, etc., and add a dependency on the platform-system module
<dependency>
<groupId>tech.abc</groupId>
<artifactId>platform-system</artifactId>
</dependency>
resolve conflict
Analyze the pom and find jar package conflicts
Considering that on the one hand, the updated version is used first, and on the other hand, mybatis-plus has a wider impact, so exclusions are used
<!-- 工作流 -->
<dependency>
<groupId>org.camunda.bpm.springboot</groupId>
<artifactId>camunda-bpm-spring-boot-starter</artifactId>
<version>7.19.0</version>
<exclusions>
<exclusion>
<artifactId>mybatis</artifactId>
<groupId>org.mybatis</groupId>
</exclusion>
</exclusions>
</dependency>
Incorporate start
Modify the pom file of the aggregation project platform-boot-starter, and add the workflow module, so that the workflow engine starts running with the system startup.
<dependencies>
<dependency>
<groupId>tech.abc</groupId>
<artifactId>platform-framework</artifactId>
</dependency>
<dependency>
<groupId>tech.abc</groupId>
<artifactId>platform-entity-config</artifactId>
</dependency>
<dependency>
<groupId>tech.abc</groupId>
<artifactId>platform-cip-api</artifactId>
</dependency>
<dependency>
<groupId>tech.abc</groupId>
<artifactId>platform-cip-message</artifactId>
</dependency>
<dependency>
<groupId>tech.abc</groupId>
<artifactId>platform-workflow</artifactId>
</dependency>
</dependencies>
add configuration
Modify the configuration file application-platform.yml of platform-boot-starter
#工作流配置
camunda:
bpm:
database:
type: mysql
schema-update: true
The focus is on the database node, type specifies that the database type is mysql, and schema-update has four values:
- false: default value, compare the version saved in the database table at startup, if there is no table or the version does not match, an exception will be thrown.
- true: All tables in the database will be updated. If the table does not exist, it is automatically created.
- create_drop: Create a table when activiti starts, and delete the table when it is closed (the engine must be manually shut down to delete the table).
- drop-create: Delete the original old table when activiti starts, and then create a new table (no need to manually shut down the engine).
The first type is only for inspection and no processing, and is usually used in the production environment; the latter three are used for the development environment, and 3 and 4 are equivalent to automatically returning to the initial environment state.
Usually, when running for the first time, set this value to true to automatically generate the library table, and then adjust the value to false to remove the check and speed up the startup.
run
Start springboot, you can see from the output log that camunda has been loaded, and the red box part is also displayed, the initialization sql script is called, the database table is created to view the database, and
49 tables are automatically created (the following figure is part of the database table, incomplete )
Development platform information
Platform name: One Two Three Development Platform
Introduction: Enterprise-level general development platform
Design information: csdn column
Open source address: Gitee
open source protocol: MIT
open source is not easy, welcome to favorite, like, comment.