1. Expression

When using ProcessEngineFactoryBean, by default, all expressions in the BPMN process will also see all spring beans. You can use configurable mappings to limit the beans (or even none) to be displayed in expressions. The following example discloses a single bean (printer), which can be used under the "printer" key. In order not to expose all beans, just pass an empty list on the spring process engine configuration as the beans attribute. When the bean property is not set, all spring beans in the context will be available.

<bean id="processEngineConfiguration" class="org.flowable.spring.SpringProcessEngineConfiguration">
...
<property name="beans">
<map>
<entry key="printer" value-ref="printer" />
</map>
</property>
</bean>
<bean id="printer" class="org.flowable.examples.spring.Printer" />

The exposed bean s can now be used in expressions: for example, SpringTransactionIntegrationTest hello.bpmn20.xml shows how to use a UEL method expression to call
Methods on spring beans:

<definitions id="definitions">
<process id="helloProcess">
<startEvent id="start" />
<sequenceFlow id="flow1" sourceRef="start" targetRef="print" />
<serviceTask id="print" flowable:expression="#{printer.printMessage()}" />
<sequenceFlow id="flow2" sourceRef="print" targetRef="end" />
<endEvent id="end" />
</process>
</definitions>

Where does the Printer look like this:

public class Printer {
	public void printMessage() {
		System.out.println("hello world");
	}
}

And the Spring bean configuration (as shown above) looks like this:

<beans>
	...
	<bean id="printer" class="org.flowable.examples.spring.Printer" />
</beans>

2. Automatic resource deployment

Spring integration also has special capabilities for deploying resources. In the process engine configuration, you can specify a set of resources. All of these resources will be scanned and deployed when the process engine is created. There is appropriate filtering to prevent repeated deployment. Only when the resources actually change will the new deployment be deployed to the Flowable DB. This makes sense in many use cases where the spring container is often restarted (such as testing).

Example:

<bean id="processEngineConfiguration" class="org.flowable.spring.SpringProcessEngineConfiguration">
...
<property name="deploymentResources"
value="classpath*:/org/flowable/spring/test/autodeployment/autodeploy.*.bpmn20.xml" />
</bean>
<bean id="processEngine" class="org.flowable.spring.ProcessEngineFactoryBean">
<property name="processEngineConfiguration" ref="processEngineConfiguration" />
</bean>

By default, the above configuration will group all resources matching the filter into a single deployment of the Flowable engine. Duplicate filtering prevents the redeployment of unchanged resources, which is applicable to the whole deployment. In some cases, this may not be what you want. For example, if a set of process resources is deployed in this way, and only one process definition in these resources has changed, the whole deployment will be regarded as new, and all process definitions in the deployment will be redeployed, resulting in the new version of each process definition, even if only one has actually changed.

In order to customize the method of deployment determination, you can specify an additional property spring process engine configuration and deployment mode. This attribute defines how the deployment will be determined from a set of resources that match the filter. This attribute supports three values by default:

• Default: group all resources into one deployment and apply duplicate filtering to the deployment. This is the default value and will be used if no value is specified.
• Single resource: create a separate deployment for each individual resource and apply duplicate filtering to the deployment. This is the value you will use to deploy each process definition separately and create a new process definition version only when the process definition version has changed.
• Resource parent folder: create a separate deployment for resources sharing the same parent folder and apply duplicate filtering to the deployment. You can use this value to create a separate deployment for most resources, but you can still group them by placing them in a shared folder. The following is an example deployment mode of how to specify a single resource configuration:

<bean id="processEngineConfiguration"
class="org.flowable.spring.SpringProcessEngineConfiguration">
...
<property name="deploymentResources" value="classpath*:/flowable/*.bpmn" />
<property name="deploymentMode" value="single-resource" />
</bean>

In addition to using the values listed above, you may also need custom behavior to determine deployment. If so, you can create a subclass SpringProcessEngineConfiguration and override the getAutoDeploymentStrategy(String deploymentMode) method. This method determines which deployment policy is used for a value of the deploymentMode configuration.

3. Unit test

When integrating with Spring, you can easily test business processes using standard Flowable testing tools. The following example shows how to test a business process in a typical Spring based unit test:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("classpath:org/flowable/spring/test/junit4/springTypicalUsageTest-context.xml")
public class MyBusinessProcessTest {
@Autowired
private RuntimeService runtimeService;
@Autowired
private TaskService taskService;
@Autowired
@Rule
public FlowableRule flowableSpringRule;
@Test
@Deployment
public void simpleProcessTest() {
runtimeService.startProcessInstanceByKey("simpleProcess");
Task task = taskService.createTaskQuery().singleResult();
assertEquals("My Task", task.getName());
taskService.complete(task.getId());
assertEquals(0, runtimeService.createProcessInstanceQuery().count());
}
}

Note that in order to do this, you need to define an org.flowable.engine.test.Flowable bean in the Spring configuration (in the above example, it is injected through automatic wiring).

<bean id="flowableRule" class="org.flowable.engine.test.Flowable">
<property name="processEngine" ref="processEngine" />
</bean>

4. JPA and Hibernate 4.2.x

When using Hibernate 4.2.x JPA in service task or listener logic in Flowable engine, you need to rely on Spring ORM additionally. This is not required for Hibernate 4.1.x or earlier. The following dependencies should be added:

<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-orm</artifactId>
	<version>${org.springframework.version}</version>
</dependency>

The above article is from Pangu BPM Research Institute: http://vue.pangubpm.com/
Article translation submission: https://github.com/qiudaoke/flowable-userguide
For more articles, you can focus on WeChat official account: