風(fēng)人園

jBPM module offers integration between the Spring and jBPM allowing for reuse of Spring's Hibernate support along with the IoC container. The module allows jBPM's underlying Hibernate sessionFactory to be configured through Spring and jBPM actions to access Spring's context.

Users familiar with Spring will see that the jBPM module structure resembles with the orm package from the main Spring distribution. The module offers a central template class for working with jBPM, a callback to access the native JbpmContext and a local factory bean for configuration and creating a jBPM instance.

<beans>
<!-- DataSource definition -->
<bean id="dataSource" class="...">
...
</bean>
<!-- Hibernate SessionFactory definition -->
<bean id="hibernateSessionFactory"
class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
...
</bean>
<!-- helper for reading jBPM process definitions -->
<bean id="simpleWorkflow"
class="org.springmodules.workflow.jbpm31.definition.ProcessDefinitionFactoryBean">
<property name="definitionLocation"
value="classpath:org/springmodules/workflow/jbpm31/simpleWorkflow.xml"/>
</bean>
<!-- jBPM configuration -->
<bean id="jbpmConfiguration"
class="org.springmodules.workflow.jbpm31.LocalJbpmConfigurationFactoryBean">
<property name="sessionFactory" ref="hibernateSessionFactory"/>
<property name="configuration" value="classpath:jbpm.cfg.xml"/>
<property name="processDefinitions">
<list>
<ref local="simpleWorkflow"/>
</list>
</property>
<property name="createSchema" value="true"/>
<property name="processDefinitionsResources">
<list>
<value>classpath:/org/springmodules/workflow/jbpm31/someOtherWorkflow.xml</value>
</list>
</property>
</bean>
<!-- jBPM template -->
<bean id="jbpmTemplate" class="org.springmodules.workflow.jbpm31.JbpmTemplate">
<constructor-arg index="0" ref="jbpmConfiguration"/>
<constructor-arg index="1" ref="simpleWorkflow"/>
</bean>
set
</beans>

The example above shows how (existing) Spring-managed Hibernate SessionFactories and transaction management can be reused with jBPM.

public ProcessInstance findProcessInstance(final Long processInstanceId) {
return (ProcessInstance) execute(new JbpmCallback() {
public Object doInJbpm(JbpmContext context) {
// do something
...
return context.getGraphSession().loadProcessInstance(processInstanceId.longValue());
}
});
}

9.2.3. ProcessDefinitionFactoryBean

ProcessDefinitionFactoryBean is a simple reader that loads jBPM process definition using Spring's ResourceLoaders. Thus, the xml files can be load using the classpath, relative or absolute file path or even from the Servlet Context. See the official documentation for more information.

	Note
	As reported on the forums, using ProcessDefinitionFactoryBean jBPM 3.1.1will trigger a new process definition to be persisted(through deployProcessDefinition) at each startup. While this is useful in development when the database is created on application startup and destroyed on closing, for cases where the definition doesn't change, the process should not be declared inside Spring XML files.

	Note
	As reported here, due to the static nature of jBPM, process definitions which include sub processes are not loaded properly if a JbpmContext does not exist at the time of the loading (no exception is thrown whatsoever). As a workaround consider using the LocalJbpmConfigurationFactoryBean's processDefinitionsResources property.

Another important feature of Spring Modules jBPM integration is allowing Spring configured beans to be reused inside jBPM actions. This allows one to leverage Spring container capabilities (bean lifecycles, scoping, injection, proxying just to name a few) in a transparent way with jBPM. Consider the following Spring application context:

<beans>
<!-- Spring bean visible inside jBPM processed -->
<bean id="jbpmAction" class="org.MyJbpmActionHandler" singleton="true">
<property name="someProp" ref="anotherBean"/>
...
</bean>
..
</beans>

and jBPM process definition:

<?xml version="1.0" encoding="UTF-8"?>
<process-definition name="simpleWorkflow">
<start-state>
<transition to="myState">
</transition>
</start-state>
<state name="myState">
<transition to="end">
<action name="myAction" config-type="bean"
class="org.springmodules.workflow.jbpm31.JbpmHandlerProxy">
<targetBean>jbpmAction</targetBean>
<factoryKey>jbpmConfiguration</factoryKey>
</action>
</transition>
</state>
<end-state name="end"/>
</process-definition>

JbpmHandlerProxy transparently locates Spring applicationContext and searches the bean identified by the targetBean parameter (in this case jbpmAction) and delegate all calls to the jBPM action. This way, one is not limited only to the injection offered by jBPM container and can integrate and communicate in a very easy manner with other Spring managed beans. Moreover, your action lifecycle can be sigleton (one shared instance) or prototype (every call gets a new instance) or in Spring 2.0 scoped to a certain application component (like one instance per http session).

The optional factoryKey parameter specified in this example should be used when one is dealing with more then one jBPM configuration inside the same classloader (not common in practice). The factoryKey should be the same as the bean name of the LocalJbpmConfigurationFactoryBean to be used (in our case jbpmConfiguration).