deploy deploy
Deployment will store ① configuration files in the repository. ② The process is transformed into an executable object model.
Store the existing BPMN20.XML into the database, and convert the process definition into an internal, executable object model.
RepositoryService
RepositoryService repositoryService = processEngine.getRepositoryService();
Deployment deployment = repositoryService.createDeployment()
.addClasspathResource("holiday-request.bpmn20.xml")
.deploy();
Find the process RepositoryService according to api
ProcessDefinition processDefinition = repositoryService.createProcessDefinitionQuery()
.deploymentId(deployment.getId())
.singleResult();
System.out.println("Found process definition : " + processDefinition.getName());
Task
Get the Task object
xml according to the binding of xml
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
xmlns:omgdc="http://www.omg.org/spec/DD/20100524/DC"
xmlns:omgdi="http://www.omg.org/spec/DD/20100524/DI"
xmlns:flowable="http://flowable.org/bpmn"
typeLanguage="http://www.w3.org/2001/XMLSchema"
expressionLanguage="http://www.w3.org/1999/XPath"
targetNamespace="http://www.flowable.org/processdef">
<process id="holidayRequest" name="Holiday Request" isExecutable="true">
<startEvent id="startEvent"/>
<sequenceFlow sourceRef="startEvent" targetRef="approveTask"/>
<userTask id="approveTask" name="Approve or reject request"/>
<sequenceFlow sourceRef="approveTask" targetRef="decision"/>
<exclusiveGateway id="decision"/>
<sequenceFlow sourceRef="decision" targetRef="externalSystemCall">
<conditionExpression xsi:type="tFormalExpression">
<![CDATA[
${
approved}
]]>
</conditionExpression>
</sequenceFlow>
<sequenceFlow sourceRef="decision" targetRef="sendRejectionMail">
<conditionExpression xsi:type="tFormalExpression">
<![CDATA[
${
!approved}
]]>
</conditionExpression>
</sequenceFlow>
<serviceTask id="externalSystemCall" name="Enter holidays in external system"
flowable:class="org.flowable.CallExternalSystemDelegate"/>
<sequenceFlow sourceRef="externalSystemCall" targetRef="holidayApprovedTask"/>
<userTask id="holidayApprovedTask" name="Holiday approved"/>
<sequenceFlow sourceRef="holidayApprovedTask" targetRef="approveEnd"/>
<serviceTask id="sendRejectionMail" name="Send out rejection email"
flowable:class="org.flowable.SendRejectionMail"/>
<sequenceFlow sourceRef="sendRejectionMail" targetRef="rejectEnd"/>
<endEvent id="approveEnd"/>
<endEvent id="rejectEnd"/>
</process>
</definitions>
TaskService
TaskService taskService = processEngine.getTaskService();
List<Task> tasks = taskService.createTaskQuery().taskCandidateGroup("managers").list();
System.out.println("You have " + tasks.size() + " tasks:");
for (int i=0; i<tasks.size(); i++) {
System.out.println((i+1) + ") " + tasks.get(i).getName());
}
Map<String, Object> processVariables = taskService.getVariables(task.getId());
System.out.println(processVariables.get("employee") + " wants " +
processVariables.get("nrOfHolidays") + " of holidays. Do you approve this?");
Process variable (process variable) is approved
sequence flow (sequence flow) is sequenceFlow
activity (activity) is id in xml is a unique identifier
flowable:class
<serviceTask id="externalSystemCall" name="Enter holidays in external system"
flowable:class="org.flowable.CallExternalSystemDelegate"/>
Let this class implement the org.flowable.engine.delegate.JavaDelegate interface, and implement the execute method:
package org.flowable;
import org.flowable.engine.delegate.DelegateExecution;
import org.flowable.engine.delegate.JavaDelegate;
public class CallExternalSystemDelegate implements JavaDelegate {
public void execute(DelegateExecution execution) {
System.out.println("Calling the external system for employee "
+ execution.getVariable("employee"));
}
}
HistoryHistorical data
HistoryService historyService = processEngine.getHistoryService();
List<HistoricActivityInstance> activities =
historyService.createHistoricActivityInstanceQuery()
.processInstanceId(processInstance.getId())
.finished()
.orderByHistoricActivityInstanceEndTime().asc()
.list();
for (HistoricActivityInstance activity : activities) {
System.out.println(activity.getActivityId() + " took "
+ activity.getDurationInMillis() + " milliseconds");
}
Create database tables
Mysql version
< 5.6: does not support millisecond precision. DDL files can be used (use the one containing mysql55). Automatic creation/upgrade can be used.
5.6.0 - 5.6.3: Does not support millisecond precision. Automatic creation/upgrade cannot be used. It is recommended to upgrade to a newer version of the database. If you really need to, you can use a DDL file that includes mysql55.
5.6.4+: Support millisecond precision. A DDL file can be used (the default one contains mysql). Automatic creation/upgrade can be used.
Database Naming Rules
All of Flowable's database tables start with ACT_. The second part is a two-character identifier that describes the purpose of the table. The naming of the service API roughly conforms to this rule.
ACT_RE_*: 'RE' stands for repository. Tables with this prefix contain "static" information such as process definitions and process resources (images, rules, etc.).
ACT_RU_*: 'RU' stands for runtime. These tables store runtime information such as process instances, user tasks, variables, jobs, etc. Flowable only saves runtime data while the process instance is running, and deletes the records when the process instance ends. This keeps the table small and fast at runtime.
ACT_HI_*: 'HI' stands for history. These tables store historical data such as completed process instances, variables, tasks, etc.
ACT_GE_*: General data. Used in multiple places.
configuration history
none (none): Skip archiving of all history. This is the configuration with the highest process execution performance, but no historical information will be saved.
activity: Archives all process instances and activity instances. At the end of the process instance, copy the latest value of the top-level process instance variable as a history variable instance. But details will not be archived.
audit: The default level. All process instances and activity instances will be archived, and variable values and submitted form parameters will be synchronized to ensure that all user operations through the form are traceable and auditable.
full: The highest level of history archiving, and therefore the slowest. This level stores all the information stored at the audit level, plus all other details (mainly updates to process variables).
flowable:
#关闭定时任务JOB
async-executor-activate: false
#将databaseSchemaUpdate设置为true。当flowable发现库与数据库表结构不一致时，会自动将数据库表结构升级至新版本。
database-schema-update: true
#设置流程图的字体，配置类的优先级>配置文件
activity-font-name: '楷体'
#以编程方式配置历史级别
history-level: none