<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" "http://www.springframework.org/dtd/spring-beans-2.0.dtd"><beans> <!-- Hibernate SessionFactory --> <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"> <property name="configLocation"> <value>classpath:hibernate.cfg.xml</value> </property> </bean> <!-- Transaction manager for a single Hibernate SessionFactory (alternative to JTA) --> <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager"> <property name="sessionFactory"> <ref local="sessionFactory" /> </property> </bean> <!-- jBPM configuration--> <!--bean id="hibernateConfiguration" factory-bean="sessionFactory" factory-method="getConfiguration"/--> <bean id="jbpmConfiguration" class="org.springmodules.workflow.jbpm31.LocalJbpmConfigurationFactoryBean"> <property name="sessionFactory" ref="sessionFactory" /> <property name="configuration"> <value>classpath:jbpm.cfg.xml</value> </property> </bean> <!-- jBPM template --> <bean id="jbpmTemplate" class="org.springmodules.workflow.jbpm31.JbpmTemplate"> <constructor-arg index="0" ref="jbpmConfiguration" /> </bean> <bean id="testSetUp" class="com.ivo.jpbm.test.TestSetUp"> <property name="jbpmTemplate" ref="jbpmTemplate" /> </bean> </beans>
榪欎釜鏄痵pring鐨勯厤緗紝hibernate鐨勯厤緗彲浠ョ洿鎺ヤ嬌鐢ㄥ師鏉ョ殑閭ｄ釜銆?br />
鐒跺悗榪欓噷鍙兘浼氬嚭鐜頒竴涓敊璇紝璇存壘涓嶅埌default.jbpm.context錛岄渶瑕佷慨鏀筳bpm.cfg.xml
榪欓噷鏈綆鍗曠殑鏂規硶灝辨槸瀹屽叏澶嶅埗org/jbpm/default.jbpm.cfg.xml 鍐呭錛岀劧鍚庢妸hibernate閮ㄥ垎鐨勪笢瑗挎敞閲婃帀灝卞彲浠ヤ簡銆?/p>
鐒跺悗緙栧啓涓涓猼est綾伙紝鐢ㄤ簬嫻嬭瘯銆?br />
鏁村悎鐨勬楠ゅ涓婏紝涓嬮潰灝辨槸鍦╦bpmTemplate鐨勫熀紜涓婏紝灝嗗父鐢ㄧ殑鏂規硶閲嶆柊灝佽涓涓嬨?
]]>
![[Note]](file:///E:/IVO/Library/spring-modules-0.8/docs/reference/html_single/images/admons/note.png) |
Note |
|---|---|
|
The following documentation can be used as reference documentation for Spring Modules jBPM 3.0.x support as well. |
|
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.
The main element is LocalJbpmConfigurationFactoryBean which should be familiar to users acustomed to Spring. Based on the jbpm configuration file and the given SessionFactory, it will create a jBPM configuration which can be used for working with the given process definitions. It is possible to replace jBPM xml configuration with jBPM 3.1.x newly added ObjectFactory - note that if both are present the xml configuration is preffered. LocalJbpmConfigurationFactoryBean allows the creation of the underlying schema based on the process definitions loaded automatically at startup.
Note that the sessionFactory property is not mandatory - Hibernate SessionFactory can be reused with jBPM or jBPM can work by itself without any integration with the existing infrastructure. However, in most scenarios, using LocalJbpmConfigurationFactoryBean allows one to take advantage of Spring transaction management infrastructure so it's possible without any code change to use jBPM, Hibernate and jdbc-based code inside the same transactional context, be it managed locally or globally (JTA). Moreover, it is possible to use thread-bound session or OpenSessionInView patterns with jBPM.
LocalJbpmConfigurationFactoryBean is also aware of the enclosing applicationContext lifecycle - jBPM will be initialized once the context is started (usually application startup) and will be closed properly when the context is destroyed (application is shutdown).
Note that LocalJbpmConfigurationFactoryBean can be configured programatically and can be used standalone only to build an jBPM context which can be used independently of Spring Modules jBPM support.
Another important feature of Spring Modules jBPM support is JbpmTemplate. The template offers very convient ways of working directly with process definitions as well as jBPM API taking care of handling exceptions (be it jBPM or Hibernate based) in respect to the ongoing transaction (if it's present), the underlying Hibernate session (if pesistent services are used) and the jBPM context. jBPM exceptions (and the underlying Hibernate information) are translated into Spring's DAO exception hierarchy. Everything happens in a transparent and consistent manner.This is possible, as with every Spring-style template,even when direct access to the native JbpmContext is desired, through the JbpmCallback:
public ProcessInstance findProcessInstance(final Long processInstanceId) {
return (ProcessInstance) execute(new JbpmCallback() {
public Object doInJbpm(JbpmContext context) {
// do something
...
return context.getGraphSession().loadProcessInstance(processInstanceId.longValue());
}
});
}
As well, as LocalJbpmConfigurationFactoryBean, the JbpmTemplate can be configured programatically and can be used standalone on a pre-existing jbpmContext (configured through LocalJbpmConfigurationFactoryBean or not) and can be used independently of Spring Modules jBPM support.
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. |
|
It is important to note that while our example showed LocalJbpmConfigurationFactoryBean and JbpmTemplate template inside a Spring xml, these classes do not depend on each other or on Spring application context. They can be just as well configured programatically and can
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).
]]>
framewor 錛?springmvc + spring + hibernate + jbpm
鐩殑錛?HR鐨勭鏍告祦紼嬶紙鍔犵彮銆佽鍋囥佹暀鑲茶緇冪瓑錛?
]]>
A task node represents one or more tasks that are to be performed by humans. So when execution arrives in a task node, task instances will be created in the task lists of the workflow participants. After that, the node will behave as a wait state. So when the users perform their task, the task completion will trigger the resuming of the execution. In other words, that leads to a new signal being called on the token.
浠誨姟鑺傜偣錛氫竴涓垨澶氫釜鍙互浜轟負鎵ц鐨勪換鍔°傛墍浠ュ綋鎵ц鍒頒換鍔¤妭鐐癸紝浠誨姟瀹炰緥灝嗙敱宸ヤ綔嫻佸弬涓庤呯殑浠誨姟鍒楄〃鍒涘緩銆備箣鍚庯紝榪欎釜鑺傜偣浼氳〃鐜頒負絳夊緟鐘舵併傚綋鐢ㄦ埛鎵ц浠栦滑鐨勪換鍔★紝浠誨姟瀹屾垚灝嗕細瑙﹀彂鎵ц緇х畫銆傝繕鍙ヨ瘽璇達紝鍦╰oken涓婁細璋冪敤涓涓柊鐨剆ignal
Nodetype state
A state is a bare-bones wait state. The difference with a task node is that no task instances will be created in any task list. This can be usefull if the process should wait for an external system. E.g. upon entry of the node (via an action on the node-enter event), a message could be sent to the external system. After that, the process will go into a wait state. When the external system send a response message, this can lead to a token.signal(), which triggers resuming of the process execution.
Nodetype decision
Actually there are 2 ways to model a decision. The distinction between the two is based on *who* is making the decision. Should the decision made by the process (read: specified in the process definition). Or should an external entity provide the result of the decision.
When the decision is to be taken by the process, a decision node should be used. There are basically 2 ways to specify the decision criteria. Simplest is by adding condition elements on the transitions. Conditions are beanshell script expressions that return a boolean. At runtime the decision node will loop over its leaving transitions (in the order as specified in the xml), and evaluate each condition. The first transition for which the conditions resolves to 'true' will be taken. Alternatively, an implementation of the DecisionHandler can be specified. Then the decision is calculated in a java class and the selected leaving transition is returned by the decide-method of the DecisionHandler implementation.
When the decision is taken by an external party (meaning: not part of the process definition), you should use multiple transitions leaving a state or wait state node. Then the leaving transition can be provided in the external trigger that resumes execution after the wait state is finished. E.g. Token.signal(String transitionName) and TaskInstance.end(String transitionName).
Nodetype fork
A fork splits one path of execution into multiple concurrent paths of execution. The default fork behaviour is to create a child token for each transition that leaves the fork, creating a parent-child relation between the token that arrives in the fork.
Nodetype join
The default join assumes that all tokens that arrive in the join are children of the same parent. This situation is created when using the fork as mentioned above and when all tokens created by a fork arrive in the same join. A join will end every token that enters the join. Then the join will examine the parent-child relation of the token that enters the join. When all sibling tokens have arrived in the join, the parent token will be propagated over the (unique!) leaving transition. When there are still sibling tokens active, the join will behave as a wait state.
Nodetype node
The type node serves the situation where you want to write your own code in a node. The nodetype node expects one subelement action. The action is executed when the execution arrives in the node. The code you write in the actionhandler can do anything you want but it is also responsible for propagating the execution.
This node can be used if you want to use a JavaAPI to implement some functional logic that is important for the business analyst. By using a node, the node is visible in the graphical representation of the process. For comparison, actions --covered next-- will allow you to add code that is invisible in the graphical representation of the process, in case that logic is not important for the business analyst.
]]>
public聽class聽AmountUpdate聽implements聽ActionHandler聽
{
聽聽public聽void聽execute(ExecutionContext聽ctx)聽throws聽Exception聽{
聽聽聽聽//聽business聽logic聽聽聽聽Float聽erpAmount聽=聽get聽amount聽from聽erp-system;聽聽聽聽Float聽processAmount聽=聽(Float)聽ctx.getContextInstance().getVariable("amount");聽聽聽聽float聽result聽=聽erpAmount.floatValue()聽+聽processAmount.floatValue();聽聽聽聽update聽erp-system聽with聽the聽result;聽聽聽聽聽聽聽聽//聽graph聽execution聽propagation聽聽聽聽if聽(result聽>聽5000)聽{聽聽聽聽聽聽ctx.leaveNode(ctx,聽"big聽amounts");聽聽聽聽}聽else聽{聽聽聽聽聽聽ctx.leaveNode(ctx,聽"small聽amounts");
聽聽聽聽}聽聽}
}聽聽聽聽聽聽聽聽聽聽leave this node over the given transition.
閫氳繃ctx鐨?leaveNode鏂規硶錛屾潵紜畾涓嬩竴涓猲ode錛岃繖鏍峰氨鍙互閫氳繃浠ｇ爜鍔ㄦ佹帶鍒舵祦紼嬨?img src ="http://www.tkk7.com/wuxufeng8080/aggbug/94623.html" width = "1" height = "1" />
]]>
聽
|
swimlane涓鑸槸涓轟簡task鍑嗗鐨勶紝浠誨姟鎬繪槸瑕佸垎閰嶅埌鏌愪釜浜哄ご涓婄殑銆傚鏋滃湪嫻佺▼瀹氫箟鏂囦歡涓換鍔℃病鏈夋寚瀹氬搴旂殑娉抽亾濡傦細 
<
swimlane聽name
=
"
banker
"
>
聽聽聽聽聽聽聽聽
<
assignment聽expression
=
"
user(jeffen)
"
/>
</
swimlane
>
......
<
task聽name
=
"
bank
"
聽聽swimlane
=
"
banker
"
>
榪欐牱灝卞皢浠誨姟瀹炰緥鍜屽鐞嗕漢鏉捐﹀悎浜嗭紝瀵逛簬澶氫換鍔″搴旂浉鍚岀殑澶勭悊浜猴紝榪欑鏂瑰紡鐨勫ソ澶勬樉鑰屾槗瑙併?/p> 褰撶劧榪樺彲浠ュ湪紼嬪簭涓姩鎬佹寚瀹氬鐞嗕漢錛屽涓妕askInstance.setActorId("jeffen")錛屼篃鍙互閫氳繃娉抽亾瀹炰緥swimlaneInstance.setActorId("jeffen")鎸囧畾銆?/p> |
]]>
- Deploying a process
- Starting a new execution of a process
- Continuing an execution
First deploying a process definition. Typically, this will be done directly from the graphical process designer or from the deployprocess ant task. But here you can see how this is done programmatically:
JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
try {
ProcessDefinition processDefinition = ...;
jbpmContext.deployProcessDefinition(processDefinition);
} finally {
jbpmContext.close();
}
For the creation of a new process execution, we need to specify of which process definition this execution will be an instance. The most common way to specify this is to refer to the name of the process and let jBPM find the latest version of that process in the database:
JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
try {
String processName = ...;
ProcessInstance processInstance =
jbpmContext.newProcessInstance(processName);
} finally {
jbpmContext.close();
}
For continuing a process execution, we need to fetch the process instance, the token or the taskInstance from the database, invoke some methods on the POJO jBPM objects and afterwards save the updates made to the processInstance into the database again.
JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
try {
long processInstanceId = ...;
ProcessInstance processInstance =
jbpmContext.loadProcessInstance(processInstanceId);
processInstance.signal();
jbpmContext.save(processInstance);
} finally {
jbpmContext.close();
}
Note that if you use the xxxForUpdate methods in the JbpmContext, an explicit invocation of the jbpmContext.save is not necessary any more because it will then occur automatically during the close of the jbpmContext. E.g. suppose we want to inform jBPM about a taskInstance that has been completed. Note that task instance completion can trigger execution to continue so the processInstance related to the taskInstance must be saved. The most convenient way to do this is to use the loadTaskInstanceForUpdate method:
JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
try {
long taskInstanceId = ...;
TaskInstance taskInstance =
jbpmContext.loadTaskInstanceForUpdate(taskInstanceId);
taskInstance.end();
} finally {
jbpmContext.close();
}
]]>
涓嬮潰鏄牴鎹畼鏂瑰紑鍙戝悜瀵煎強鑷繁鐨勭粡楠屽啓鐨?br />
寮鍙戝悜瀵間笂鎻愪緵鐨刪elloworld渚嬪瓙錛岃繖涓祦紼嬫槸鍗曞悜鐨勶紝娌℃湁浠諱綍鐨勫垎鏀紝涓旀病鏈夎嚜瀹氫箟actionHandler錛屼嬌鐢ㄧ殑鏄粯璁ょ殑handler
public void testHelloWorldProcess() {
// This method shows a process definition and one execution// of the process definition. The process definition has // 3 nodes: an unnamed start-state, a state 's' and an // end-state named 'end'.// The next line parses a piece of xml text into a// ProcessDefinition. A ProcessDefinition is the formal // description of a process represented as a java object.
ProcessDefinition processDefinition = ProcessDefinition.parseXmlString(
"<process-definition>" +
" <start-state>" +
" <transition to='s' />" +
" </start-state>" +
" <state name='s'>" +
" <transition to='end' />" +
" </state>" +
" <end-state name='end' />" +
"</process-definition>"
);
// The next line creates one execution of the process definition.// After construction, the process execution has one main path// of execution (=the root token) that is positioned in the// start-state.
ProcessInstance processInstance =
new ProcessInstance(processDefinition);
// After construction, the process execution has one main path// of execution (=the root token).
Token token = processInstance.getRootToken();
// Also after construction, the main path of execution is positioned// in the start-state of the process definition.
assertSame(processDefinition.getStartState(), token.getNode());
// Let's start the process execution, leaving the start-state // over its default transition.
token.signal();
// The signal method will block until the process execution // enters a wait state.// The process execution will have entered the first wait state// in state 's'. So the main path of execution is now // positioned in state 's'
assertSame(processDefinition.getNode("s"), token.getNode());
// Let's send another signal. This will resume execution by // leaving the state 's' over its default transition.
token.signal();
// Now the signal method returned because the process instance // has arrived in the end-state.
assertSame(processDefinition.getNode("end"), token.getNode());
}
鏇磋緇嗙殑渚嬪瓙鍙互鐪嬪弬鑰冿紝閲岄潰鏈夊緢璇︾粏鐨勬搷浣滆鏄庛?br />
涓嬮潰鏄牴鎹弬鑰冧緥瀛愭祴璇曟椂鍑虹幇鐨勪竴浜涢棶棰樺強璇存槑銆?br />涓銆佸叧浜庢暟鎹簱錛岄鍏堣淇敼鏁版嵁搴撹繛鎺ワ紝鐒跺悗鍒涘緩鏁版嵁搴擄紝閲岄潰鐨勮〃鏍糺BPM鎻愪緵鐩稿簲鐨凙PI鍘誨垱寤恒?br />public聽void聽testDeployProcessDefinition()聽throws聽FileNotFoundException聽{聽
聽聽聽聽聽聽聽聽//聽浠幝爅bpm.cfg.xml聽鍙栧緱聽jbpm聽鐨勯厤緗?/span>
聽聽聽聽聽聽聽聽JbpmConfiguration聽config聽=聽JbpmConfiguration.getInstance();
聽聽聽聽聽聽聽聽config.dropSchema();//鍒犻櫎鏁版嵁琛ㄧ粨鏋?br />聽聽聽聽聽聽聽聽config.createSchema();//鍒涘緩鏁版嵁琛ㄧ粨鏋?br />聽聽聽聽聽聽聽聽//聽鍒涘緩涓涓爅bpm聽瀹瑰櫒聽
聽聽聽聽聽聽聽聽JbpmContext聽jbpmContext聽=聽config.createJbpmContext();聽
聽聽聽聽聽聽聽聽//聽鐢甭爌rocessdefinition.xml聽鐢熸垚鐩稿搴旂殑嫻佺▼瀹氫箟綾宦燩rocessDefinition聽
聽聽聽聽聽聽聽聽InputStream聽is聽=聽new聽FileInputStream("processes/simple/processdefinition.xml");聽
聽聽聽聽聽聽聽聽ProcessDefinition聽processDefinition聽=聽ProcessDefinition.parseXmlInputStream(is);聽
聽聽聽聽聽聽聽聽
聽聽聽聽聽聽聽聽//聽鍒╃敤瀹瑰櫒鐨勬柟娉曞皢嫻佺▼瀹氫箟鏁版嵁閮ㄧ講鍒版暟鎹簱涓娐?/span>
聽聽聽聽聽聽聽聽jbpmContext.deployProcessDefinition(processDefinition);聽
聽聽聽聽聽聽聽聽//聽鍏抽棴聽jbpmContext聽
聽聽聽聽聽聽聽聽jbpmContext.close();聽
聽聽聽聽}
榪欎釜鏄牴鎹祦紼嬮厤緗枃浠舵渶鍚庣敓鎴愮殑鏁版嵁搴撲俊鎭殑嫻嬭瘯鏂規硶錛屽垰寮濮嬫垜榪樻湁涓涓枒闂紝鏁版嵁搴撳拰鏁版嵁琛ㄦ槸緋葷粺鑷姩鍒涘緩榪?br />鏄鎵嬪姩鍒涘緩錛屾暟鎹簱鏄鎵嬪姩鍒涘緩鐨勶紝鏁版嵁琛ㄥ彲浠ヨ嚜鍔ㄥ垱寤虹殑
]]>