Author: fishing alone cold river snow a sword a wine a river’s lake, is this life in the heart of the map, why light. Please indicate the origin of loading

Previous portal: Flowable from entry to Ground (1)- Initial Flowable

QuickStart

Flowable- Tomcat is available in version 6.4.0 for quick startup of Flowable for demo purposes. The modules include: IDM, TASK,ADMIN, MODLER. Rest modules are not included by default.

dependencies

Flowable relies on Liquibase to generate its table structure. Therefore, you only need to introduce the corresponding dependencies to automatically generate the table structure. SpringBoot depends on the following: The current version is written based on Flowable version 6.5. According to the official website, it is also the last open source release. A separate DB Schema is recommended. Flowable provides only Engine related services. Business is king, after all. Flowable itself is still too idealistic. Why do you say that? Let’s see later.

     <! -- Mainly depend on -->
    <dependency>
        <groupId>org.flowable</groupId>
        <artifactId>flowable-spring-boot-starter-basic</artifactId>
        <version>${flowable.version}</version>
    </dependency>
    
    <! -- The following three are for the subsequent deployment of the front and back end interaction -->
    <dependency>
        <groupId>org.flowable</groupId>
        <artifactId>flowable-bpmn-converter</artifactId>
        <version>${flowable.version}</version>
    </dependency>
    
    <dependency>
        <groupId>org.flowable</groupId>
        <artifactId>flowable-json-converter</artifactId>
        <version>${flowable.version}</version>
    </dependency>
    
    <dependency>
        <groupId>org.flowable</groupId>
        <artifactId>flowable-bpmn-layout</artifactId>
        <version>${flowable.version}</version>
    </dependency>
    
Copy the code

Once started, the basic 46 tables are generated. Instead of the traditional 34 tables.

Table structure analysis

Let’s see if it’s a little familiar. That’s right. And Activity is exactly the same style. After all, it’s the same wave of core developers. Sometimes, the hero left, in another way to gas fire. Cut the bullshit.

ACT_EVT_*

  • ACT_EVT_LOG: related to event logs
  • ACT_PROCDEF_INFO: process information saved when cached

ACT_GE_*

  • ACT_GE_BYTEARRAY: Stores the BPMN XML of the process and the Image thumbnail of the process
  • ACT_GE_PROPERTY: Basic information about Flowable. Such as the version information used by each module.

ACT_RE_*

  • ACT_RE_DEPLOYMENT: Deployment object, storage process name tenant dependent
  • ACT_RE_MODEL: Process-based model information
  • ACT_RE_PROCDEF: process definition table

ACT_RU_*(Runtime相关)

  • ACT_RU_ACTINST: Active table of the running instance
  • ACT_RU_DEADLETTER_JOB: A JOB that cannot be executed for many times is recorded in this table
  • ACT_RU_ENTITYLINK: not used yet. Update this table later.
  • ACT_RU_EVENT_SUBSCR: run-time event
  • ACT_RU_EXECUTION: A list of running instances
  • ACT_RU_HISTORY_JOB; History table of running scheduled tasks
  • ACT_RU_IDENTITYLINK: information about the current task executor
  • ACT_RU_JOB: running asynchronous task
  • ACT_RU_SUSPENDED_JOB: List of suspended tasks. If an asynchronous task is running, it is suspended. It will be recorded in the word list
  • ACT_RU_TASK: running normal node task
  • ACT_RU_TIMER_JOB: indicates the scheduled job table
  • ACT_RU_VARIABLE: running process instance variable

ACT_ID_ * (IDM module. User dependent)

This is actually based on my personal opinion, do not recommend using. However, if the workflow is the core, for the business of the company, such as the company specializing in OA. I am from a manufacturing background, so THE IDM of workflow is not used. It’s all business systems making calls to WorkFlowEngine.

  • ACT_ID_BYTEARRAY:
  • ACT_ID_GROUP: indicates information about a user group
  • ACT_ID_INFO: user details
  • ACT_ID_MEMBERSHIP: Relationship between user groups and users
  • ACT_ID_PRIV: permissions
  • ACT_ID_PRIV_MAPPING: specifies the relationship between a user group and a permission
  • ACT_ID_PROPERTY: extended list of user or user group attributes
  • ACT_ID_TOKEN: logs related to login
  • ACT_ID_USER: user

ACT_HI_*(historical)

  • ACT_HI_ACTINST: process instance history
  • ACT_HI_ATTACHMENT: history attachment of the instance, which is rarely used and will increase the loading of the database
  • ACT_HI_COMMENT: historical remarks of the instance
  • ACT_HI_DETAIL: details about the instance process
  • ACT_HI_IDENTITYLINK: in the instance node, if specifiedThe target personThe history of the birth of
  • ACT_HI_PROCINST: process instance history
  • ACT_HI_TASKINST: Task history of the process instance
  • ACT_HI_VARINST: Variable history of the process instance

FLW_*

  • FLW_CHANNEL_DEFINITION: pool pipe definition table
  • FLW_EVENT_DEFINITION: event definition
  • FLW_EVENT_DEPLOYMENT: Event must be lost
  • FLW_EVENT_RESOURCE: resource required by the event
  • FLW_EV_DATABASECHANGELOG: Records of Liquibase execution
  • FLW_EV_DATABASECHANGELOGLOCK: Liquibase performs the lock
  • FLW_RU_BATCH: unknown yet
  • FLW_RU_BATCH_PART: temporarily unknown

The specific corresponding table structure will be analyzed in the following introduction, combined with examples. There is no need to say more here.

That’s the end of this issue. If there is a warrior designated, please feel free to comment… The next installment covers process definition, startup, history, and query tasks and future nodes of the process. Look forward to…