摘要: 9月1號(hào)4.1發(fā)布了,上周將jBPM4.1的用戶手冊(cè)并提供給大家下載了,請(qǐng)見博客:http://www.tkk7.com/kaysurf168/archive/2009/09/10/294523.html,現(xiàn)在將jBPM4.1的中文開發(fā)指南也提供給大家下載,希望降低大家學(xué)習(xí)jbpm4的難度。有翻譯不當(dāng)?shù)牡胤竭€請(qǐng)指出。
閱讀全文
摘要: 這篇文章主要講述jBPM4.1的新特性和翻譯用戶手冊(cè)的內(nèi)容更新下載。
閱讀全文
摘要: 《每天一課,jBPM4》視頻教程今天推出基本應(yīng)用系列——第五課,第五課主要講了jBPM4的流程追蹤。從下一課開始,我們將進(jìn)入高級(jí)應(yīng)用系列,主要是整合Spring+Hibernate+Struts2+jBPM4,以這些框架為基礎(chǔ)實(shí)現(xiàn)報(bào)銷流程。
閱讀全文
摘要: 《每天一課,jBPM4》視頻教程今天推出基本應(yīng)用系列——第四課,第四課主要講了jBPM4的監(jiān)聽事件,jBPM4使用了Oberservable模式實(shí)現(xiàn)的事件監(jiān)聽。
閱讀全文
摘要: 這一課的內(nèi)容比較多,除了對(duì)jBPM4的身份認(rèn)證的管理的進(jìn)行講解之外,還講述了jBPM4現(xiàn)在的身份認(rèn)證還存在的一些功能缺陷和解決方法。
閱讀全文
摘要: 經(jīng)常有人問我,jBPM4視頻教程到底有多少課,能講到什么程度?這里我就放出jBPM4視頻教程系列的初期規(guī)劃,同時(shí)我們今天還推出了jBPM4視頻教程應(yīng)用系列的第二課。并提供了我們現(xiàn)有視頻教程的觀看和下載鏈接。
閱讀全文
摘要: 第一次使用工作流做項(xiàng)目或產(chǎn)品,遇到最簡單最常見的需求就是分配任務(wù),待辦任務(wù)列表以及一些簡單的流向判斷,這是基本所有的流程都要實(shí)現(xiàn)的,而我們這一課的內(nèi)容主要就是教大家在一個(gè)簡單的業(yè)務(wù)流程里實(shí)現(xiàn)這些功能。
閱讀全文
摘要: 《每天一課,jBPM4》視頻教程今天推出基本應(yīng)用系列——第一課,這個(gè)系列主要是以請(qǐng)假流程為例,請(qǐng)假流程作為OA中的一個(gè)經(jīng)典案例,覆蓋了多種流程特性,同時(shí)又兼具易讀性。主要內(nèi)容是執(zhí)行請(qǐng)假流程,實(shí)現(xiàn)流程駁回,用戶權(quán)限,任務(wù)與表單綁定以及流程追蹤等功能。
閱讀全文
摘要: 這一課主要是講解流程實(shí)例的管理和流程活動(dòng)的分類介紹,這一課的視頻也是入門系列的最后一課,因?yàn)榈竭@一課為止我們就能讓大家入門jBPM4了,對(duì)于jBPM4的一些簡單應(yīng)用已經(jīng)沒有問題了。從下一課開始,我們將進(jìn)入jBPM4系列視頻教程的基本應(yīng)用系列,正式開始接觸真正的業(yè)務(wù)場景的用例。
閱讀全文
摘要: 《每天一課,jBPM4》視頻教程今天推出第二課,主要內(nèi)容是在web工程里應(yīng)用jBPM4。
閱讀全文
摘要: 隨著jBPM4.0GA版本的發(fā)布,使用jBPM4的人也開始多起來,雖然我們已經(jīng)翻譯了jBPM-4的用戶手冊(cè)和開發(fā)指南,但jBPM4的官方文檔內(nèi)容還是不夠全面,雖然理論知識(shí)比較豐富,但是缺少實(shí)踐教授內(nèi)容。我們推出的《每天一課,jBPM4》是jBPM4第一份系列視頻教程,手把手教您學(xué)會(huì)jBPM4,并將jBPM4應(yīng)用在工作流管理平臺(tái)中,同時(shí)我們還會(huì)提供視頻課程里的源代碼。
閱讀全文
摘要: 這2天我們忙著做了下jBPM4和Spring Security的專題頁面,提供了不少關(guān)于jBPM4和Spring Security的技術(shù)資料和示例。
閱讀全文
摘要: 在oa里我們實(shí)現(xiàn)一套權(quán)限管理,包括資源管理、角色管理、用戶管理、菜單管理以及組織機(jī)構(gòu)管理,整套權(quán)限采用的是RBAC的模型。下面給大家分享下效果,同時(shí)也提供源碼下載,希望大家多提建議。
閱讀全文
摘要: 鑒于各位都非常期待PDF的版本,我便把用戶指南提供給大家下載,希望大家能夠多多反饋,這樣才能提高我們的翻譯質(zhì)量,對(duì)大家更是有好處。開發(fā)指南的內(nèi)容更豐富些,如果有感興趣幫忙校稿的朋友可以聯(lián)系我們O(∩_∩)O哈哈~
閱讀全文
開發(fā)文檔更新到了jBPM4的GA版本,這次開發(fā)文檔變更非常大,添加了好幾章,并且原來的部分章節(jié)也改了名字,具體細(xì)節(jié)可以查看修改日志。不過架構(gòu)那章更新的并不多,和jBPM4實(shí)際的架構(gòu)還有些區(qū)別,所以這部分大家最好看jBPM4的源碼。(用戶指南的翻譯見上一篇博客)
最近一直在整流程控制臺(tái),發(fā)現(xiàn)還是有不少成就感的,尤其昨天又實(shí)現(xiàn)了動(dòng)畫回放流程。這可是忽悠領(lǐng)導(dǎo)的最佳手段啊,我先給大家看一下我們控制臺(tái)的規(guī)劃和進(jìn)度(提供源碼下載地址
):
-------------------------------------------------近期
* 細(xì)化task的生命周期,重新整理task操作
* 流程實(shí)例歷史
* 表格方式查看流程歷史
------------------------------------------------- 遠(yuǎn)景
* 流程仿真
* 修改流程圖
* 細(xì)粒度權(quán)限控制
* 回退
* 會(huì)簽
* 委派
* swimlane
* BI
* BAM
* 儀表盤
-------------------------------------------------ChangeLog
* 2009-07-01
* [DONE] 實(shí)現(xiàn)動(dòng)畫方式回放流程
* [DONE] 實(shí)現(xiàn)deployment的suspend, resume(CR1顯示已暫停定義列表時(shí)出現(xiàn)問題,trunk下已修正,等待GA)
* [DONE] 實(shí)現(xiàn)processInstance的suspend, resume, end(CR1和trunk里,都沒有暴露suspend和resume方法)
* [DONE] 實(shí)現(xiàn)personalTasks, groupTasks, take task, cancel task
* 2009-06-29
* [DONE] 登陸頁面,登錄名和密碼為1/1
* [DONE] 添加start和signal,complete task時(shí),添加變量
* [DONE] 整合web流程設(shè)計(jì)器,可以直接發(fā)布流程定義
* [DONE] 國際化
* 2009-06-01 and before
* [DONE] 發(fā)布xml格式的流程定義
* [DONE] 流程定義管理(list, start, delete)
* [DONE] 顯示流程圖(只在Process Instance詳細(xì)信息中可顯示)
* [DONE] 流程實(shí)例管理(list, signal, view, delete)
* [DONE] 任務(wù)管理(list, complete)
* [DONE] 追蹤流程圖(顯示Process Instance的當(dāng)前位置)
* [DONE] 多流向選擇
* [DONE] 用戶權(quán)限(user, group, membership的CRUD功能)
* [DONE] 報(bào)表(most active process)
呵呵,現(xiàn)在實(shí)現(xiàn)的功能畢竟還是有限,我們的功能規(guī)劃在一定程度上可能有些局限,希望大家能給多提提建議,認(rèn)為控制臺(tái)里還可以加些什么功能。這可是開源的啊,大家為了自己也要多提出建議來,O(∩_∩)O哈哈~
下面是我們控制臺(tái)一些功能的視頻演示,包括流程設(shè)計(jì)和發(fā)布,動(dòng)畫回放流程等。
大家可以看看視頻:
http://www.family168.com/bbs/dispbbs.asp?boardid=6&Id=473
截圖請(qǐng)看:
http://www.family168.com/bbs/dispbbs.asp?boardid=6&Id=463
svn的下載地址:
http://jbpmside.googlecode.com/svn/trunk
摘要: 我們的控制臺(tái)現(xiàn)已實(shí)現(xiàn)了流程管理、流程監(jiān)控、流程建模和仿真以及報(bào)表等,建模和仿真是使用js做了一個(gè)web設(shè)計(jì)器jPDL整合在控制臺(tái)中。
閱讀全文
要知道如何將jBPM4與Spring整合,可以先了解jBPM4的IOC容器,如果不了解的可以先看ronghao的這篇文章
http://www.javaeye.com/topic/381607,是介紹jBPM4的IOC容器的。下面我們介紹jBPM與Spring整合的2種方式:
第一種:手工將SessionFactory放入jBPM4中。
第1步:更改jbpm.spring.default.cfg.xml配置文件,將下面的部分注釋掉
<!--
<hibernate-configuration>
<cfg resource="jbpm.hibernate.cfg.xml" />
</hibernate-configuration>
<hibernate-session-factory />
-->
注釋的部分是在jBPM4中創(chuàng)建了sessionFactory,而我們只需要一個(gè)sessionFactory。既然要將jBPM4與Spring的整
合,那就希望由Spring來統(tǒng)一管理sessionFactory和事務(wù),在Spring的配置文件中構(gòu)造一個(gè)sessionFactory。
ProcessEngine是jBPM4的Facade模式,一切由它與外部交互,
第2步:在Spring配置文件中寫一個(gè)bean:
<bean id="processEngine" class="com.family168.jbpm.ProcessEngineFactoryBean">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
第3步:在ProcessFactoryBean中注入SessionFactory:
public void setSessionFactory(SessionFactory sessionFactory) {
this.sessionFactory = sessionFactory;
}
第4步:在ProcessFactoryBean中創(chuàng)建一個(gè)SpringConfiguration,然后將sessionFactory放入
SpringConfiguration中,再從SpringConfiguration得到processEngine,代碼如下:
public void afterPropertiesSet() {
SpringConfiguration cfg = new SpringConfiguration(jbpmConfigurationLocation);
cfg.setApplicationContext(applicationContext);
cfg.setSessionFactory(sessionFactory);
this.processEngine = cfg.buildProcessEngine();
}
然后我們的工作就可以開展了,可以從processEngine得到所有的service。比如:
ProcessEngine processEngine = (ProcessEngine) ctx.getBean("processEngine");
RepositoryService repositoryService = processEngine.getRepositoryService();。
第2種:獲得Hibernate的SessionFactory。
第1步:與第一種方式的第1步一樣。
第2步:更改jbpm.tx.spring.cfg.xml配置文件:
將
<standard-transaction-interceptor/>
改成 <spring-transaction-interceptor current="true" />
然后將
<transaction/>
<hibernate-session/>
改成 <hibernate-session current="true"/>
這部分修改是將jBPM4創(chuàng)建的spring事務(wù)和hibernate的session改成從當(dāng)前的ThreadLocal中獲得session和事務(wù)。
第3步:在Spring配置文件中寫bean,processEngine和template:
<bean id="jbpmConfiguration" class="org.jbpm.pvm.internal.cfg.SpringConfiguration">
<constructor-arg value="jbpm/jbpm.cfg.xml" />
</bean>
<bean id="processEngine" factory-bean="jbpmConfiguration" factory-method="buildProcessEngine" />
<bean id="jbpmTemplate" class="com.family168.jbpm.JbpmTemplate">
<property name="processEngine" ref="processEngine"/>
<property name="dataSource" ref="dataSource"/>
</bean>
processEngine直接使用factory-bean指向jbpmConfiguration,也就是
org.jbpm.pvm.internal.cfg.SpringConfiguration,并從SpringConfiguration的
buildProcessEngine中獲得。
jbpmTemplate主要是控制事務(wù),在processEngine外面創(chuàng)建事務(wù),這樣使用的時(shí)候會(huì)先調(diào)用jbpmTemplate,再調(diào)用processEngine,否則它會(huì)說事務(wù)沒有啟動(dòng)。在jbpmTemplate中注入processEngine:
public void setProcessEngine(ProcessEngine processEngine) {
this.processEngine = processEngine;
}
這里我的理解是我們?cè)谏厦嬉呀?jīng)將事務(wù)改成從當(dāng)前的Threadlocal中獲得,所以jBPM4是必須當(dāng)前有事務(wù),如果我沒有創(chuàng)建事務(wù)的話,在使用
processEngine時(shí)就會(huì)說事務(wù)沒有啟動(dòng)。所以我們就封裝了一個(gè)jbpmTemplate,如果我的理解有誤還請(qǐng)大家指出。
第1種整合方式的例子下載
http://www.family168.com/,第2種整合方式之后可以看我們的jBPM-Side里的控制臺(tái)。
7.6. 流程同步
為了進(jìn)行流程同步建模,在執(zhí)行中這是一個(gè)父子樹形結(jié)構(gòu)。 這個(gè)想法是執(zhí)行主路徑是樹的根。 流程的主路徑也被稱作流程實(shí)例。 當(dāng)在給定流程定義上啟動(dòng)或創(chuàng)建一個(gè)新流程實(shí)例時(shí), 執(zhí)行便被創(chuàng)建。
現(xiàn)在,因?yàn)閳?zhí)行的主路徑和流程實(shí)例是相同對(duì)象, 這保證了用法的簡單, 在沒有同步情況的簡單流程下。
基本執(zhí)行結(jié)構(gòu)的UML類圖
圖 7.6. 基本執(zhí)行結(jié)構(gòu)的UML類圖
為了建立執(zhí)行的多同步路徑,活動(dòng)實(shí)現(xiàn)比如一個(gè)分支或切分 創(chuàng)建子執(zhí)行, 使用ActivityExecution.createExecution方法。 活動(dòng)實(shí)現(xiàn)比如結(jié)合或合并可以停止流程的這些同步路徑, 通過調(diào)用執(zhí)行同步的stop方法。
只有葉子執(zhí)行可以激活,非葉子執(zhí)行應(yīng)該不是激活的。 這個(gè)執(zhí)行的樹形結(jié)構(gòu)沒有堅(jiān)持一個(gè)同步或結(jié)合行為的特殊類型。 它從事著分支或和切分 和結(jié)合或和合并來使用執(zhí)行樹結(jié)構(gòu), 用任何方式,他們想定義期望的同步行為。 這里我們看一個(gè)同步執(zhí)行的例子。
執(zhí)行的同步路徑
圖 7.7. 執(zhí)行的同步路徑
這里有執(zhí)行的一個(gè)付款和一個(gè)發(fā)貨路徑。 在這種情況,水平線上的活動(dòng)展示了分支和結(jié)合。這個(gè)執(zhí)行顯示了三個(gè)執(zhí)行。 執(zhí)行的主路徑不是激活的(顯示成灰色) 執(zhí)行的付款和發(fā)貨路徑是激活的,分別指向了 bill和ship活動(dòng)。
從事活動(dòng)行為的實(shí)現(xiàn),是他們想使用的執(zhí)行結(jié)構(gòu)。 假設(shè)多個(gè)任務(wù)必須在執(zhí)行進(jìn)行之前完成。 活動(dòng)行為可以為這個(gè)產(chǎn)生一系列子執(zhí)行。
或者可以選擇,任務(wù)組件可以支持任務(wù)組, 分配給單獨(dú)的執(zhí)行。在那種情況, 任務(wù)組件成為同步任務(wù)的響應(yīng),
因此把這個(gè)責(zé)任移動(dòng)到執(zhí)行樹形結(jié)構(gòu)范圍之外。
7.7. 異常處理器
在所有分配到流程的代碼中,像 Activity,EventListeners和 Condition,可能分配給異常處理器。
這可以想成是把這些實(shí)現(xiàn)的方法實(shí)現(xiàn)包含在try-catch塊中。 但是為了構(gòu)建更多可復(fù)用的構(gòu)建塊, 為了委派類和異常處理邏輯,
異常處理器可以添加到核心流程模型中。
一個(gè)異常處理器可以分配給任何流程元素。 當(dāng)一個(gè)異常發(fā)生在一個(gè)委派類中,一個(gè)匹配的異常處理器就會(huì)被找到。 如果找到了一個(gè)這樣的異常處理器,它會(huì)有一個(gè)處理這個(gè)異常的機(jī)會(huì)。
如果一個(gè)異常處理器處理完成,沒有出現(xiàn)問題,然后這個(gè)異常會(huì) 被認(rèn)為是處理了,就會(huì)在委派代碼調(diào)用后繼續(xù)。 比如,一個(gè)轉(zhuǎn)移有三個(gè)動(dòng)作,第二個(gè)動(dòng)作拋出一個(gè)異常, 這個(gè)異常被異常處理器處理,然后
編寫自動(dòng)活動(dòng),異常處理器提醒是很容易的。 默認(rèn)是任意執(zhí)行。沒有方法需要在執(zhí)行中調(diào)用。
所以如果一個(gè)自動(dòng)活動(dòng)拋出一個(gè)異常,被異常處理器處理, 這個(gè)執(zhí)行會(huì)在這個(gè)執(zhí)行后繼續(xù)執(zhí)行。這對(duì)于控制流向活動(dòng)
就會(huì)有一個(gè)更大的困難。它們可能需要包含try-finally塊 來調(diào)用執(zhí)行中對(duì)應(yīng)的方法,在異常處理器
獲得一個(gè)機(jī)會(huì)來處理異常。比如,如果活動(dòng)是等待狀態(tài), 然后發(fā)生了一個(gè)異常,這里就會(huì)有一個(gè)風(fēng)險(xiǎn),線程會(huì)跳出
execution.waitForSignal()的調(diào)用, 導(dǎo)致執(zhí)行在這個(gè)活動(dòng)以后繼續(xù)執(zhí)行。
TODO: exceptionhandler.isRethrowMasked
TODO: transactional exception handlers
TODO: we never catch errors
7.8. 流程修改
TODO: 流程修改
7.9. 鎖定和流程狀態(tài)
一個(gè)執(zhí)行的狀態(tài)不是激活就是鎖定。 一個(gè)激活的執(zhí)行不是執(zhí)行就是等待外部觸發(fā)器。 如果一個(gè)執(zhí)行不是STATE_ACTIVE,那么它就是被鎖定。 一個(gè)鎖定的執(zhí)行是只讀的,不能接受任何外部觸發(fā)器。
當(dāng)一個(gè)新執(zhí)行被創(chuàng)建時(shí),它是STATE_ACTIVE。 為了把狀態(tài)修改成鎖定狀態(tài),使用lock(String)。一些STATE_*常量 被提供了,它們演示了最常用的鎖定狀態(tài)。 但是在圖片中的'...'狀態(tài)展示了任何字符串 都可以作為狀態(tài)提供給lock方法。
執(zhí)行的狀態(tài)
圖 7.8. 執(zhí)行的狀態(tài)
如果一個(gè)執(zhí)行被鎖定,修改執(zhí)行的方法會(huì) 拋出一個(gè)PvmException,信息會(huì)引用真實(shí)的鎖定狀態(tài)。
觸發(fā)事件,更新變量,更新優(yōu)先級(jí),添加注釋 不會(huì)當(dāng)做是修改執(zhí)行。 子節(jié)點(diǎn)的創(chuàng)建和刪除也不會(huì)檢測,
這意味著那些方法可以被外部API客戶和活動(dòng)行為調(diào)用, 即使執(zhí)行在鎖定狀態(tài)。
確保比較getState()和STATE_*常量時(shí) 使用.equals,不要使用'==',因?yàn)槿绻麍?zhí)行從持久存儲(chǔ)加載。 會(huì)創(chuàng)建一個(gè)新字符串,而不是使用常量。
一個(gè)執(zhí)行實(shí)現(xiàn)會(huì)被鎖定:
* 當(dāng)它結(jié)束
* 當(dāng)它暫停
* 在異步延續(xù)過程中
更多的,鎖定可以被活動(dòng)實(shí)現(xiàn)使用, 讓執(zhí)行在等待狀態(tài)下只讀,然后為這個(gè)執(zhí)行傳遞 的外部實(shí)例就像這樣:
* 一個(gè)人員任務(wù)
* 一個(gè)服務(wù)調(diào)用
* 一個(gè)等待狀態(tài)當(dāng)探測器檢測一個(gè)文件的出現(xiàn)時(shí)就結(jié)束
在這些情況,策略是外部實(shí)例應(yīng)該獲得 執(zhí)行的完全控制,因?yàn)樗胍刂剖裁磻?yīng)該允許,什么不應(yīng)該。 為了獲得那種控制,他們鎖定了執(zhí)行,所以所有內(nèi)部交互 必須通過外部實(shí)例傳遞。
一個(gè)創(chuàng)建外部實(shí)例的主要原因是, 它們可以在執(zhí)行已經(jīng)執(zhí)行過還存在。比如, 在服務(wù)調(diào)用的情況,定時(shí)器可以導(dǎo)致執(zhí)行獲得超時(shí)轉(zhuǎn)移。
當(dāng)響應(yīng)在超時(shí)后到達(dá),服務(wù)調(diào)用實(shí)例應(yīng)該 確認(rèn)它沒有signal這個(gè)執(zhí)行。所以服務(wù)調(diào)用可以看做 一個(gè)活動(dòng)實(shí)例(活動(dòng)實(shí)例)
是對(duì)活動(dòng)每個(gè)執(zhí)行的唯一實(shí)例。
外部實(shí)例它們自己負(fù)責(zé)管理執(zhí)行鎖定。 如果定時(shí)器和客戶端應(yīng)用結(jié)果是選擇 外部實(shí)例,而不是直接選擇執(zhí)行,然后在理論上是不必要的。 它是從事活動(dòng)行為實(shí)現(xiàn),無論它希望 執(zhí)行鎖定還是解鎖。
活動(dòng)可以實(shí)現(xiàn)循環(huán),基于轉(zhuǎn)移或活動(dòng)組合。 循環(huán)可以包含等待狀態(tài)。
為了支持多次自動(dòng)循環(huán)執(zhí)行,流程虛擬機(jī) 把執(zhí)行的傳播從尾部遞歸轉(zhuǎn)換成while循環(huán)。
7.2. 子流程
TODO: 子流程
7.3. 默認(rèn)執(zhí)行行為
當(dāng)一個(gè)Activity被用作活動(dòng)行為, 它可以使用下面的方法從外部控制流程:
* waitForSignal()
* take(Transition)
* end(*)
* execute(Activity)
* createExecution(*)
當(dāng)Activity實(shí)現(xiàn)用做活動(dòng)行為, 沒有調(diào)用任何下面的流程傳播方法,然后 在活動(dòng)執(zhí)行時(shí),執(zhí)行會(huì)使用默認(rèn)執(zhí)行行為。
默認(rèn)執(zhí)行行為定義在下面:
* 如果當(dāng)前活動(dòng)有一個(gè)默認(rèn)向外轉(zhuǎn)移,選擇它。
* 如果當(dāng)前活動(dòng)有一個(gè)父活動(dòng),回退到父活動(dòng)。
* 否則,結(jié)束這個(gè)執(zhí)行。
流程語言可以重寫默認(rèn)執(zhí)行行為, 通過重寫ExecutionImpl中的 proceed方法。
7.4. 功能活動(dòng)
活動(dòng)也可以用作事件監(jiān)聽器,被稱作功能活動(dòng)。 自動(dòng)活動(dòng)的例子是發(fā)送郵件,執(zhí)行數(shù)據(jù)庫更新, 生成pdf,計(jì)算平均數(shù),等等。 所有這些都是自動(dòng)活動(dòng),沒有改變執(zhí)行流向。 這里是這些活動(dòng)如何實(shí)現(xiàn):
public class FunctionalActivity implements Activity, EventListener {
public void execute(ActivityExecution execution) {
perform(execution);
}
public void notify(EventListenerExecution execution) {
perform(execution);
}
void perform(OpenExecution execution) {
...do functional work...
}
}
perform方法獲得一個(gè)OpenExecution, 這是ActivityExecution和
EventListenerExecution的超類。 OpenExecution沒有提供任何特定目的的方法,
但是依舊是當(dāng)前狀態(tài),流程定義可以通過變量檢驗(yàn), 這包含了環(huán)境信息 對(duì)應(yīng)流程執(zhí)行。
這些方法其實(shí)都不能調(diào)用執(zhí)行傳播方法。 所以在perform方法完成后,執(zhí)行會(huì) 執(zhí)行默認(rèn)的方式。
7.5. 執(zhí)行和線程
這一章解釋流程虛擬機(jī)如何通過客戶端的線程, 把一個(gè)執(zhí)行從一個(gè)等待狀態(tài)帶到另一個(gè)。
當(dāng)一個(gè)客戶調(diào)用一個(gè)執(zhí)行的一個(gè)方法(比如signal方法)。 默認(rèn),流程虛擬機(jī)會(huì)使用線程執(zhí)行流程
直到它到達(dá)一個(gè)等待狀態(tài)。一旦下一個(gè)等待狀態(tài)到達(dá), 這個(gè)方法會(huì)返回,客戶端的線程就會(huì)返回。 這是流程虛擬機(jī)操作的默認(rèn)方式。
兩個(gè)更多的異步執(zhí)行可以補(bǔ)充默認(rèn)行為: 異步繼續(xù) 和異步命令服務(wù)。
下一個(gè)流程會(huì)展示基本理論。 它有三個(gè)等待狀態(tài)和四個(gè)自動(dòng)活動(dòng)。
有很多順序自動(dòng)活動(dòng)的流程。
圖 7.1. 有很多順序自動(dòng)活動(dòng)的流程。
這里是如何構(gòu)建流程:
ClientProcessDefinition processDefinition = ProcessFactory.build("automatic")
.activity("wait 1").initial().behaviour(new WaitState())
.transition().to("automatic 1")
.activity("automatic 1").behaviour(new Display("one"))
.transition().to("wait 2")
.activity("wait 2").behaviour(new WaitState())
.transition().to("automatic 2")
.activity("automatic 2").behaviour(new Display("two"))
.transition().to("automatic 3")
.activity("automatic 3").behaviour(new Display("three"))
.transition().to("automatic 4")
.activity("automatic 4").behaviour(new Display("four"))
.transition().to("wait 3")
.activity("wait 3").behaviour(new WaitState())
.done();
讓我們和你一起順著流程的執(zhí)行一起走。
ClientExecution execution = processDefinition.startProcessInstance();
啟動(dòng)一個(gè)新執(zhí)行意味著初始活動(dòng)被執(zhí)行。 所以如果一個(gè)自動(dòng)活動(dòng)是初始活動(dòng),這意味著第一個(gè)未命名的向外轉(zhuǎn)移會(huì)被立刻選擇。 這些都發(fā)生在startProcessInstance調(diào)用的內(nèi)部。
然而在這種情況下,初始活動(dòng)是一個(gè)等待狀態(tài)。 所以startProcessInstance方法會(huì)立刻返回, 執(zhí)行會(huì)定位到初始活動(dòng)'wait 1'。
一個(gè)新執(zhí)行會(huì)被定為到'wait 1'。
圖 7.2. 一個(gè)新執(zhí)行會(huì)被定為到'wait 1'。
然后一個(gè)外部觸發(fā)器會(huì)執(zhí)行signal方法。
execution.signal();
像上面解釋的介紹WaitState, signal會(huì)導(dǎo)致選擇默認(rèn)的轉(zhuǎn)移。 轉(zhuǎn)移會(huì)把執(zhí)行移動(dòng)到automatic 1活動(dòng),并執(zhí)行它。
automatic 1中的Display活動(dòng)的execute方法, 向控制臺(tái)打印一行,它不會(huì)
調(diào)用execution.waitForSignal()。 因此,執(zhí)行會(huì)通過選擇automatic 1外部的默認(rèn)轉(zhuǎn)移進(jìn)行執(zhí)行。
在這種狀態(tài),signal方法一直阻塞著。另一個(gè)需要考慮的方式是執(zhí)行方法, 像signal會(huì)使用客戶端的線程
來攔截流程定義,直到到達(dá)一個(gè)等待狀態(tài)。
然后執(zhí)行到達(dá)wait 2, 執(zhí)行WaitState活動(dòng)。那個(gè)方法會(huì)調(diào)用 execution.waitForSignal(),這會(huì)導(dǎo)致signal方法返回。 線程會(huì)返回到調(diào)用signal方法 的客戶端。
所以,當(dāng)signal方法返回時(shí),執(zhí)行定義到wait 2。
一個(gè)signal會(huì)把執(zhí)行從'initial'帶到'wait 2'。
圖 7.3. 一個(gè)signal會(huì)把執(zhí)行從'initial'帶到'wait 2'。
然后執(zhí)行會(huì)等待一個(gè)外部觸發(fā)器, 像是一個(gè)對(duì)象(更準(zhǔn)確的是一個(gè)對(duì)象圖)在內(nèi)存中, 直到下一個(gè)外部觸發(fā)器執(zhí)行signal方法。
execution.signal();
第二個(gè)調(diào)用的signal會(huì)直接讓執(zhí)行進(jìn)入wait 3, 在它返回之前。
第二個(gè)signal讓執(zhí)行進(jìn)入'wait 3'。
圖 7.4. 第二個(gè)signal讓執(zhí)行進(jìn)入'wait 3'。
使用這個(gè)范例的好處是相同的流程定義可以在 客戶執(zhí)行模式中執(zhí)行 (在內(nèi)存內(nèi)不使用持久化),就像在持久化執(zhí)行模式, 依賴應(yīng)用和環(huán)境。
當(dāng)在持久化模式下執(zhí)行一個(gè)流程,你如何綁定 流程執(zhí)行到數(shù)據(jù)庫的事務(wù)上。
持久化模式下的事務(wù)超時(shí)
圖 7.5. 持久化模式下的事務(wù)超時(shí)
在大多情況下,計(jì)算工作是流程需要完成的一部分, 在外部觸發(fā)器(紅色部分)之后的部分,其實(shí)很少。
一般來說,處理流程執(zhí)行和處理UI傳遞過來的請(qǐng)求 的事務(wù)不會(huì)超過一秒。 而業(yè)務(wù)流程中的等待狀態(tài)可能超過幾小時(shí),幾天甚至幾年。
當(dāng)?shù)却隣顟B(tài)啟動(dòng)后,線索就變得很清晰, 在等待狀態(tài)啟動(dòng)之前,只有計(jì)算工作的完成包含在事務(wù)中。
考慮一下這種方式: "當(dāng)?shù)竭_(dá)審批時(shí),所有的自動(dòng)流程需要做的是什么, 在流程系統(tǒng)需要等待另一個(gè)外部觸發(fā)器之前?"。
除非pdf需要被創(chuàng)建,或大郵件需要被發(fā)送, 大部分時(shí)候,它消耗的時(shí)間都是可以忽略的。 這就是為什么在默認(rèn)的持久化執(zhí)行模式下,
流程工作在客戶端線程下執(zhí)行。
這個(gè)原因也保證著流程同步路徑的情況。 當(dāng)一個(gè)執(zhí)行的單獨(dú)路徑切分成流程同步路徑, 流程花在計(jì)算上的時(shí)間是可忽略的。
所以為什么分支或切分活動(dòng)實(shí)現(xiàn)是有意義的, 目標(biāo)持久化模式產(chǎn)生的同步路徑在同一個(gè)線程中按順序執(zhí)行。 基本上它們都只是在同一個(gè)事務(wù)中的計(jì)算工作。
因?yàn)榉种Щ蚯蟹种烂總€(gè)執(zhí)行的同步路徑會(huì)返回,所以這只能被完成, 當(dāng)出現(xiàn)一個(gè)等待狀態(tài)的時(shí)候。
因?yàn)檫@里有一個(gè)困難的概念需要掌握,我會(huì)再次使用其他詞語來解釋它。 從頭再看一次在持久化執(zhí)行模式下被流程執(zhí)行創(chuàng)建出來的它。
如果在一個(gè)事務(wù)中,一個(gè)執(zhí)行被給與一個(gè)外部觸發(fā)器, 那導(dǎo)致執(zhí)行切分成多個(gè)執(zhí)行的同步路徑。 然后執(zhí)行在計(jì)算上的部分也可以忽略。
生成SQL的部分也可以忽略。 因?yàn)樗性谕椒种贤瓿傻墓δ埽仨氃谕粋€(gè)事務(wù)中完成, 這里一般沒有指針在分支或切分實(shí)現(xiàn),
在多個(gè)線程中產(chǎn)生執(zhí)行的同步路徑。
為了創(chuàng)建可執(zhí)行流程,開發(fā)者需要確切知道什么是自動(dòng)活動(dòng), 什么是等待狀態(tài),哪些線程會(huì)被分配給流程執(zhí)行。 對(duì)于畫業(yè)務(wù)流程的業(yè)務(wù)分析人員,事件就很簡單了。 對(duì)于他們畫的活動(dòng),他們通常只要知道這是一個(gè)人或是一個(gè)系統(tǒng)響應(yīng)。 但是他們通常不知道如何轉(zhuǎn)換線程和事務(wù)。
所以對(duì)于開發(fā)者,第一個(gè)任務(wù)是分析什么是流程控制的線程中需要執(zhí)行的, 什么是外部的。 查找外部觸發(fā)器是尋找一個(gè)流程中的等待狀態(tài)的很好的開始, 就像動(dòng)詞和名詞可以在構(gòu)建UML類圖中的元素的規(guī)則。
5.5. 基本流程執(zhí)行
在下一個(gè)例子里,我們會(huì)結(jié)合自動(dòng)活動(dòng)和等待狀態(tài)。 這里例子構(gòu)建了貸款審批流程,使用WaitState 和Display活動(dòng),我們剛剛創(chuàng)建的。 貸款流程的圖形看起來像這樣:
貸款流程
圖 5.3. 貸款流程
使用Java構(gòu)建流程圖形是很乏味的事情, 因?yàn)槟惚仨氃诰植孔兞恐懈櫵械囊谩?
為了解決這個(gè)問題,流程虛擬機(jī)提供了一個(gè)ProcessFactory。
ProcessFactory是一種領(lǐng)域特定語言(DSL),可以嵌入到Java中, 簡化流程圖形的結(jié)構(gòu)。這個(gè)模型也叫做 流暢接口。
ClientProcessDefinition processDefinition = ProcessFactory.build("loan")
.activity("submit loan request").initial().behaviour(new Display("loan request submitted"))
.transition().to("evaluate")
.activity("evaluate").behaviour(new WaitState())
.transition("approve").to("wire money")
.transition("reject").to("end")
.activity("wire money").behaviour(new Display("wire the money"))
.transition().to("archive")
.activity("archive").behaviour(new WaitState())
.transition().to("end")
.activity("end").behaviour(new WaitState())
.done();
為了了解ProcessFactory的更多細(xì)節(jié),可以參考 api文檔。
ProcessFactory的另一種選擇是創(chuàng)建一個(gè)XML語言和一個(gè)XML解析器,來表示流程。 XML解析器可以直接實(shí)例化
org.jbpm.pvm.internal.model包中的類。 這種方式一般都被流程語言選擇使用。
初始化活動(dòng)submit loan request和 wire the money活動(dòng)是自動(dòng)活動(dòng)。 在這個(gè)例子中,wire the
money活動(dòng)的 Display實(shí)現(xiàn) 使用Java API來把信息輸出到控制臺(tái)上。但是讀取器可以想象一個(gè)可選的
Activity實(shí)現(xiàn),使用支付流程庫的Java API 來實(shí)現(xiàn)一個(gè)真實(shí)的自動(dòng)支付。
上述流程的一個(gè)新執(zhí)行可以像下面這樣啟動(dòng)
ClientExecution execution = processDefinition.startProcessInstance();
當(dāng)startExecution方法返回時(shí), submit loan request活動(dòng)會(huì)被執(zhí)行, 執(zhí)行會(huì)位于evaluate活動(dòng)。
位于'evaluate'活動(dòng)的執(zhí)行
圖 5.4. 位于'evaluate'活動(dòng)的執(zhí)行
現(xiàn)在,執(zhí)行處在一個(gè)很有趣的點(diǎn)。這里有兩個(gè)轉(zhuǎn)移從evaluate指向外邊。 一個(gè)轉(zhuǎn)移叫approve 一個(gè)轉(zhuǎn)移叫reject。像我們上面解釋的, WaitState實(shí)現(xiàn)會(huì)根據(jù)執(zhí)行的signal選擇轉(zhuǎn)移。 讓我們像這樣執(zhí)行'approve' signal:
execution.signal("approve");
這個(gè)approve signal會(huì)導(dǎo)致執(zhí)行選擇approve轉(zhuǎn)移 它會(huì)到達(dá)wire money活動(dòng)。
在wire money活動(dòng)中,信息會(huì)打印到控制臺(tái)里。 因?yàn)镈isplay沒有調(diào)用execution.waitForSignal(),
也沒有調(diào)用其他執(zhí)行傳播方法, 默認(rèn)流程行為只會(huì)讓執(zhí)行繼續(xù), 使用向外的轉(zhuǎn)移到達(dá)archive活動(dòng), 這也是一個(gè)WaitState。
位于'archive'活動(dòng)的執(zhí)行
圖 5.5. 位于'archive'活動(dòng)的執(zhí)行
所以只有當(dāng)archive到達(dá)時(shí), signal("approve")會(huì)返回。
另一個(gè)signal就像這樣:
execution.signal("approve");
將讓執(zhí)行最終到達(dá)結(jié)束狀態(tài)。
位于'end'活動(dòng)的執(zhí)行
圖 5.6. 位于'end'活動(dòng)的執(zhí)行
5.6. 事件
事件位于流程定義中, 一系列的EventListener可以進(jìn)行注冊(cè)。
public interface EventListener extends Serializable {
void notify(EventListenerExecution execution) throws Exception;
}
事件的目的是讓開發(fā)者可以為流程添加程序邏輯, 不必改變流程圖。 這是非常有價(jià)值的機(jī)制,可以促進(jìn)業(yè)務(wù)分析人員和開發(fā)者之間的協(xié)作。
業(yè)務(wù)分析人員負(fù)責(zé)描述需求。 當(dāng)他們使用流程圖歸檔那些需求, 開發(fā)者可以獲得這些圖形,讓它可執(zhí)行化。
事件會(huì)非常方便,向一個(gè)流程中添加技術(shù)細(xì)節(jié)(比如一些數(shù)據(jù)庫插入操作) 這些都是業(yè)務(wù)分析人員不感興趣的東西。
最常用的事件是由執(zhí)行自動(dòng)觸發(fā)的:
TODO: 在用戶手冊(cè)中解釋事件
事件是由流程元素和事件名稱結(jié)合而成。 用戶和流程語言也可以出發(fā)事件, 使用編程的方式在流程中使用fire方法。
public interface Execution extends Serializable {
...
void fire(String eventName, ProcessElement eventSource);
...
}
可以把一系列的EventListeners分配給一個(gè)事件。 但是事件監(jiān)聽器不能控制執(zhí)行的流向, 因?yàn)樗鼈儍H僅是監(jiān)聽已經(jīng)執(zhí)行了的執(zhí)行。 這與活動(dòng)處理活動(dòng)的行為是不同的。 活動(dòng)行為可以響應(yīng)執(zhí)行的傳播。
我們會(huì)創(chuàng)建一個(gè)PrintLn事件監(jiān)聽器, 這與上面的Display活動(dòng)是非常相似的。
public class PrintLn implements EventListener {
String message;
public PrintLn(String message) {
this.message = message;
}
public void notify(EventListenerExecution execution) throws Exception {
System.out.println("message");
}
}
多個(gè)PrintLn監(jiān)聽器 會(huì)在流程中注冊(cè)。
PrintLn監(jiān)聽器流程
圖 5.7. PrintLn監(jiān)聽器流程
ClientProcessDefinition processDefinition = ProcessFactory.build()
.activity("a").initial().behaviour(new AutomaticActivity())
.event("end")
.listener(new PrintLn("leaving a"))
.listener(new PrintLn("second message while leaving a"))
.transition().to("b")
.listener(new PrintLn("taking transition"))
.activity("b").behaviour(new WaitState())
.event("start")
.listener(new PrintLn("entering b"))
.done();
第一個(gè)事件演示如何為相同的事件注冊(cè)多個(gè)監(jiān)聽器。 它們會(huì)根據(jù)它們指定的順序依次執(zhí)行。
然后,在轉(zhuǎn)椅上,這里的事件只有一種類型。 所以在那種情況下,事件類型不需要指定, 監(jiān)聽器可以直接添加到轉(zhuǎn)移上。
一個(gè)監(jiān)聽器每次都會(huì)執(zhí)行,當(dāng)一個(gè)執(zhí)行觸發(fā)事件時(shí),如果這個(gè)監(jiān)聽器被注冊(cè)了。 執(zhí)行會(huì)作為一個(gè)參數(shù)提供給活動(dòng)接口, 除了控制流程傳播的方法以外, 都可以被監(jiān)聽器使用。
5.7. 事件傳播
事件會(huì)默認(rèn)傳播給最近的流程元素。 目的是允許監(jiān)聽器在流程定義或組合活動(dòng)中 可以執(zhí)行所有發(fā)生在流程元素中的事件。
比如這個(gè)功能允許為end事件在流程定義或一個(gè)組合活動(dòng)中注冊(cè)一個(gè)事件監(jiān)聽器。 這種動(dòng)作會(huì)被執(zhí)行,如果一個(gè)活動(dòng)離開。
如果事件監(jiān)聽器被注冊(cè)到一個(gè)組合活動(dòng)中, 它也會(huì)被所有活動(dòng)執(zhí)行,當(dāng)組合活動(dòng)中出現(xiàn)了離開事件。
為了清楚地顯示這個(gè),我們會(huì)創(chuàng)建一個(gè)DisplaySource事件監(jiān)聽器, 這會(huì)把leaving信息和事件源 打印到控制臺(tái)。
public class DisplaySource implements EventListener {
public void execute(EventListenerExecution execution) {
System.out.println("leaving "+execution.getEventSource());
}
}
注意事件監(jiān)聽器的目的不是可視化,這是為什么事件監(jiān)聽器本身 不應(yīng)該顯示在圖形中。一個(gè)DisplaySource事件監(jiān)聽器 會(huì)作為end事件的監(jiān)聽器添加到組合活動(dòng)中。
下一個(gè)流程展示了DisplaySource事件監(jiān)聽器如何 作為'end'事件的監(jiān)聽器注冊(cè)到composite活動(dòng):
一個(gè)在組合活動(dòng)中為end事件注冊(cè)了不可見的事件監(jiān)聽器的流程。
圖 5.8. 一個(gè)在組合活動(dòng)中為end事件注冊(cè)了不可見的事件監(jiān)聽器的流程。
TODO 更新代碼片段
下一步,我們會(huì)啟動(dòng)一個(gè)執(zhí)行。
ClientExecution execution = processDefinition.startProcessInstance();
在啟動(dòng)一個(gè)新執(zhí)行后,執(zhí)行將在a活動(dòng)中 作為初始活動(dòng)。沒有活動(dòng)離開,所以沒有信息被記錄下來。 下一個(gè)signal會(huì)給與執(zhí)行, 導(dǎo)致它選擇從a到b。
execution.signal();
當(dāng)signal方法返回,執(zhí)行會(huì)選擇轉(zhuǎn)移 然后end事件會(huì)被a活動(dòng)觸發(fā)。 那個(gè)組合活動(dòng)會(huì)被傳播到組合活動(dòng)和流程定義中。 因?yàn)槲覀兊腄isplaySource 監(jiān)聽器放到 composite活動(dòng)中, 它會(huì)接收事件,把下面的信息打印到控制臺(tái)中:
leaving activity(a)
另一個(gè)
execution.signal();
會(huì)選擇b到c的轉(zhuǎn)移。那會(huì)觸發(fā)兩個(gè)活動(dòng)離開事件。 一個(gè)在b活動(dòng),一個(gè)在組合活動(dòng)。 所以下面的幾行會(huì)添加到控制臺(tái)輸出中:
leaving activity(b)
leaving activity(composite)
事件傳播建立在流程定義的繼承組合結(jié)構(gòu)中。 頂級(jí)元素總是流程定義。 流程定義包含一系列活動(dòng)。每個(gè)活動(dòng)可以是葉子活動(dòng)或者可以是一個(gè)組合節(jié)點(diǎn), 這意味著它包含了一系列內(nèi)嵌活動(dòng)。 內(nèi)嵌活動(dòng)可以被使用,比如超級(jí)狀態(tài)或組合活動(dòng),在內(nèi)嵌流程語言中,像BPEL。
所以事件模型在組合活動(dòng)和上面的流程定義中的功能是相似的。 想象'Phase one'模型一個(gè)超級(jí)狀態(tài)作為一個(gè)狀態(tài)機(jī)。
然后事件傳播允許在超級(jí)狀態(tài)中注冊(cè)所有事件。 這個(gè)主意是繼承組合響應(yīng)圖形展示。 如果一個(gè)'e'元素畫在另一個(gè)'p'元素中,
'p'是'e'的父節(jié)點(diǎn)。一個(gè)流程定義擁有一系列定義活動(dòng)。 每個(gè)活動(dòng)可以擁有一系列內(nèi)嵌活動(dòng)。 一個(gè)轉(zhuǎn)移的父節(jié)點(diǎn)就是它的源頭和目的的第一個(gè)父節(jié)點(diǎn)。
如果一個(gè)事件監(jiān)聽器對(duì)傳播的事件沒有興趣, 可以在構(gòu)建流程使用ProcessFactory的propagationDisabled()。 下一個(gè)流程是與上面相同的流程, 除了傳播的事件會(huì)被事件監(jiān)聽器禁用。 圖形還是一樣。
注冊(cè)到'end'事件的事件監(jiān)聽器被禁用的流程。
圖 5.9. 注冊(cè)到'end'事件的事件監(jiān)聽器被禁用的流程。
使用流程工廠構(gòu)建流程:
TODO 更新代碼
所以當(dāng)?shù)谝粋€(gè)signal在流程中調(diào)用時(shí),end事件 會(huì)再次觸發(fā)在a活動(dòng)上,但是現(xiàn)在在組合活動(dòng)的事件監(jiān)聽器 不會(huì)被執(zhí)行,因?yàn)閭鞑サ氖录唤昧恕?禁用傳播是單獨(dú)的事件監(jiān)聽器的一個(gè)屬性, 不會(huì)影響其他監(jiān)聽器。事件會(huì)一直被觸發(fā), 傳播到整個(gè)父繼承結(jié)構(gòu)。
ClientExecution execution = processDefinition.startProcessInstance();
第一個(gè)signal會(huì)選擇從a到b的流程。 沒有信息會(huì)被打印到控制臺(tái)。
execution.signal();
下一步,第二個(gè)signal會(huì)選擇從b到c的轉(zhuǎn)移。
execution.signal()
還是兩個(gè)end事件被觸發(fā), 就像上面分別在b和composite活動(dòng)中。 第一個(gè)事件是b活動(dòng)上的 end事件。
那將被傳播給composite活動(dòng)。 所以事件監(jiān)聽器不會(huì)為這個(gè)事件執(zhí)行,因?yàn)樗呀?jīng)禁用了傳播。 但是事件監(jiān)聽器會(huì)在composite活動(dòng)上
為end事件執(zhí)行。 那是不傳播的,但是直接在composite活動(dòng)上觸發(fā)。 所以事件監(jiān)聽器現(xiàn)在會(huì)被執(zhí)行
一次,為組合活動(dòng),就像下面控制臺(tái)里顯示的那樣:
leaving activity(composite)
jBPM4.0中文開發(fā)指南完整版
http://family168.com/tutorial/jbpm4devguide/html/index.html
這一章解釋了流程定義的基礎(chǔ),流程虛擬機(jī)給予的功能 以及活動(dòng)實(shí)現(xiàn)是如何構(gòu)建的。 同時(shí),客戶端API被用來執(zhí)行包含了那些活動(dòng)實(shí)現(xiàn)的流程。
5.1. ActivityBehaviour
PVM庫沒有包含完整的流程結(jié)構(gòu)。 作為替代的是,活動(dòng)的運(yùn)行時(shí)行為被委派給一個(gè)ActivityBehaviour。 換句話講,ActivityBehaviour是一個(gè)接口, 它用來在純java環(huán)境實(shí)現(xiàn)流程結(jié)構(gòu)的運(yùn)行時(shí)行為。
public interface ActivityBehaviour extends Serializable {
void execute(ActivityExecution execution) throws Exception;
}
當(dāng)一個(gè)活動(dòng)行為被調(diào)用時(shí),它就處于執(zhí)行傳播的全部控制中。 換句話說,一個(gè)活動(dòng)行為可以決定下一步應(yīng)該執(zhí)行什么執(zhí)行。
比如,可以使用execution.take(Transition)獲得一個(gè)轉(zhuǎn)移,
或者使用execution.waitForSignal()進(jìn)入等待階段。 萬一活動(dòng)行為沒有調(diào)用任何上述的執(zhí)行傳播方法, 執(zhí)行將
按默認(rèn)方式執(zhí)行。
5.2. ActivityBehaviour實(shí)例
我們會(huì)啟動(dòng)一個(gè)非常原始的hello world例子。 一個(gè)Display活動(dòng)會(huì)將一條信息打印到控制臺(tái):
public class Display implements ActivityBehaviour {
String message;
public Display(String message) {
this.message = message;
}
public void execute(ActivityExecution execution) {
System.out.println(message);
}
}
讓我們使用這個(gè)活動(dòng)構(gòu)建我們第一個(gè)流程定義:
Display實(shí)例流程
圖 5.1. Display實(shí)例流程
TODO add ProcessBuilder example code
現(xiàn)在我們可以像下面這樣執(zhí)行流程:
Execution execution = processDefinition.startExecution();
startExecution的調(diào)用會(huì)在控制臺(tái)打印hello world:
hello
world
一個(gè)總是值得提醒的事情是活動(dòng)可以使用屬性進(jìn)行配置。 在Display例子中,你可以看到message屬性在兩種使用方法中配置的不同。
通過配置屬性,我們可以寫出可復(fù)用的活動(dòng)。 它們可以在以后每次使用在流程中都進(jìn)行不同的配置。 這是一個(gè)基本的部分,
將流程語言構(gòu)建在流程虛擬機(jī)之上。
其他需要解釋的部分是 這個(gè)活動(dòng)實(shí)現(xiàn)沒有包含任何執(zhí)行傳播的功能。 當(dāng)一個(gè)新流程實(shí)例啟動(dòng)時(shí), 執(zhí)行會(huì)定位到初始活動(dòng),那個(gè)活動(dòng)會(huì)被執(zhí)行。
Display.execute方法用來決定默認(rèn)的執(zhí)行傳播。 具體的,這意味著活動(dòng)自己 沒有調(diào)用任何執(zhí)行傳播的方法。
那種情況下,默認(rèn)的傳播會(huì)執(zhí)行。默認(rèn)傳播會(huì)選擇第一個(gè)轉(zhuǎn)移,如果這個(gè)轉(zhuǎn)移存在的話。 如果沒有,它會(huì)結(jié)束這個(gè)執(zhí)行。
這揭示了為什么a活動(dòng)和b活動(dòng)都被執(zhí)行, 而在b活動(dòng)執(zhí)行完執(zhí)行會(huì)停止。
關(guān)于默認(rèn)流程行為的更多細(xì)節(jié)可以 在第 7.3 節(jié) “默認(rèn)執(zhí)行行為”找到。
5.3. ExternalActivityBehaviour
外部活動(dòng)是負(fù)責(zé)流程執(zhí)行由外部轉(zhuǎn)移進(jìn)來的活動(dòng), 外部的意思是來自流程系統(tǒng)的外部。 這意味著這個(gè)執(zhí)行流程對(duì)于系統(tǒng)來說,這是一個(gè)等待狀態(tài)。 這個(gè)執(zhí)行會(huì)一直等待到外部觸發(fā)器調(diào)用。
為了處理外部觸發(fā)器,ExternalActivityBehaviour 為ActivityBehaviour添加了一個(gè)方法:
public interface ExternalActivity extends Activity {
void signal(Execution execution,
String signal,
Map<String, Object> parameters) throws Exception;
}
就像普通的活動(dòng),當(dāng)一個(gè)執(zhí)行到達(dá)一個(gè)活動(dòng), 外部活動(dòng)行為的execute方法會(huì)被調(diào)用。
在外部活動(dòng)中,execute方法會(huì)傳遞另一個(gè)系統(tǒng)的響應(yīng), 然后通過調(diào)用execution.waitForSignal() 進(jìn)入等待狀態(tài)。
比如在execute方法中,響應(yīng)可能是由一個(gè)人傳入, 通過在任務(wù)管理系統(tǒng)中創(chuàng)建一個(gè)任務(wù)入口, 然后等待到這個(gè)人完成這個(gè)任務(wù)。
一旦活動(dòng)行為已經(jīng)處于等待狀態(tài), 然后執(zhí)行會(huì)等待到調(diào)用signal方法。 執(zhí)行會(huì)委派signal給ExternalActivityBehaviour對(duì)象 分配給當(dāng)前的活動(dòng)。
所以活動(dòng)的signal方法 會(huì)在等待期間,在執(zhí)行獲得一個(gè)外部觸發(fā)器的時(shí)候調(diào)用。 signal方法中,響應(yīng)會(huì)傳遞給后面的流程執(zhí)行。 比如,當(dāng)一個(gè)人完成了一個(gè)任務(wù),任務(wù)管理系統(tǒng) 會(huì)在執(zhí)行中調(diào)用signal方法。
一個(gè)signal可選擇使用signal名字和一個(gè)參數(shù)map。 活動(dòng)行為攔截signal和參數(shù)的最常用方式是 signal對(duì)應(yīng)選擇的外出轉(zhuǎn)移, 參數(shù)作為執(zhí)行中的變量。但那些只是例子, 它一直等到活動(dòng)使用singal和它期望的參數(shù)。
5.4. ExternalActivity實(shí)例
這里是一個(gè)簡單等待狀態(tài)實(shí)現(xiàn)的第一個(gè)例子:
public class WaitState implements ExternalActivity {
public void execute(ActivityExecution execution) {
execution.waitForSignal();
}
public void signal(ActivityExecution execution,
String signalName,
Map<String, Object> parameters) {
execution.take(signalName);
}
}
execute方法調(diào)用execution.waitForSignal()。 execution.waitForSignal()的調(diào)用 會(huì)使流程執(zhí)行進(jìn)入等待狀態(tài), 直到一個(gè)外部觸發(fā)器出現(xiàn)。
signal方法使用signal參數(shù)對(duì)應(yīng)的轉(zhuǎn)移名稱 來選擇轉(zhuǎn)移。所以當(dāng)一個(gè)執(zhí)行獲得一個(gè)外部觸發(fā)器, signal名稱被攔截,作為外部轉(zhuǎn)移的名稱, 執(zhí)行會(huì)被傳播到那個(gè)轉(zhuǎn)移上。
這里是從a到b有一個(gè)轉(zhuǎn)移的相同的流程。 這時(shí)候,兩個(gè)活動(dòng)的行為都是WaitState。
外部活動(dòng)實(shí)例流程
圖 5.2. 外部活動(dòng)實(shí)例流程
ClientProcessDefinition processDefinition = ProcessFactory.build()
.activity("a").initial().behaviour(new WaitState())
.transition().to("b")
.activity("b").behaviour(new WaitState())
.done();
讓我們?yōu)榱鞒潭x啟動(dòng)一個(gè)新流程實(shí)例:
ClientExecution execution = processDefinition.startProcessInstance();
啟動(dòng)這個(gè)流程會(huì)執(zhí)行a中的WaitState活動(dòng)。 WaitState.execute會(huì)調(diào)用
ActivityExecution.waitForSignal。
所以當(dāng)processDefinition.startProcessInstance()返回, 執(zhí)行會(huì)一直處在a活動(dòng)。
assertEquals("a", execution.getActivityName());
然后我們提供了外部觸發(fā)器, 通過調(diào)用signal方法。
execution.signal();
execution.signal()會(huì)委派給當(dāng)前活動(dòng)。 所以在這種情況下就是a活動(dòng)里的
WaitState活動(dòng)。WaitState.signal會(huì)調(diào)用 ActivityExecution.take(String
transitionName)。 當(dāng)我們沒有提供一個(gè)signal名稱,第一個(gè)名字是null會(huì)被選中。
我們指定的a的唯一轉(zhuǎn)移沒有名字,所以會(huì)選中這個(gè)。 然后這個(gè)轉(zhuǎn)移指向b。 當(dāng)執(zhí)行到達(dá)b活動(dòng), b活動(dòng)中的WaitState活動(dòng)會(huì)被執(zhí)行。
就像我們上面看到的,執(zhí)行會(huì)在b一直等待, 這時(shí)signal會(huì)返回, 離開的執(zhí)行指向b活動(dòng)。
assertEquals("b", execution.getActivityName());
jBPM4.0開發(fā)指南完整版
http://family168.com/tutorial/jbpm4devguide/html/index.html
第1個(gè)示例Pay是我們family168所做的例子中我最喜歡的一個(gè),這是一個(gè)簡易的信息統(tǒng)計(jì)查詢工具,它甚至沒有服務(wù)器端的代碼,完全依靠JavaScript提供各種數(shù)據(jù),在這個(gè)小系統(tǒng)中我們可以分類查看不同客戶的信息,以及由這這些信息匯總的圖形報(bào)表。
其中包月包年的用戶情況的統(tǒng)計(jì)使用的是maven2中的cobertura里的效果,這樣哪些vip已經(jīng)過期,哪些vip快到期就一目了然,當(dāng)然最重要的是視覺效果好。
首頁效果如下圖所示:
系統(tǒng)的最后一項(xiàng)功能是統(tǒng)計(jì)報(bào)表,我們可以按照用戶類型和是否過期生成兩種統(tǒng)計(jì)報(bào)表,報(bào)表圖形并不是使用Ext
JS實(shí)現(xiàn)的,而是用svg畫的,不過我們?cè)陲@示報(bào)表頁面的時(shí)候使用了iframe,這樣做的好處是不用將所有代碼都加載到首頁中,雖然RIA宣揚(yáng)one
page one application,但是使用iframe可以在一定程度上避免一次加載過多的資源文件,在實(shí)際中依然擁有適用的場景。
顯示效果如下圖所示:
第2個(gè)示例Tracker是一個(gè)簡易的任務(wù)跟蹤系統(tǒng),它使用了最基本的ssh開發(fā)框架,通過嵌入式數(shù)據(jù)庫hsqldb保存數(shù)據(jù),依靠maven2管理項(xiàng)目流程。儼然已經(jīng)是一個(gè)小而全的企業(yè)系統(tǒng)了。
Ext JS在系統(tǒng)中負(fù)責(zé)前臺(tái)展示的部分,后臺(tái)通過struts2結(jié)合json-lib與前臺(tái)的Ext JS進(jìn)行交互,在開發(fā)過程中,我們封裝了JsonGrid和JsonTree這些基本組件,很大程度上減少了編碼的數(shù)量,提高的開發(fā)效率。
系統(tǒng)界面如下:
系統(tǒng)左側(cè)是以JsonTree為基礎(chǔ)生成的樹形菜單,顯示了所有工程的信息,我們可以直接在左側(cè)面板部分進(jìn)行添加,修改,刪除等操作。
進(jìn)行詳細(xì)配置和右鍵功能菜單效果如下圖所示:
統(tǒng)計(jì)系統(tǒng)下載:
http://www.family168.com/demo/pay.rar
任務(wù)追蹤系統(tǒng)下載:
http://www.family168.com/demo/tracker.rar
由于第2個(gè)示例是使用maven2構(gòu)建的,所以不會(huì)使用maven2的朋友可以查看我們的maven2教程
http://family168.com/oa/maven2/html/index.html。如果想知道這2個(gè)示例的詳細(xì)講解,可以上我們的論壇
http://family168.com/bbsindex.asp?boardid=13查看。
4.1. APIs
流程虛擬機(jī)包含4個(gè)集成的API,在不同的執(zhí)行模式下, 覆蓋完整的流程工作。 每個(gè)API都有特定的目的, 滿足下面的架構(gòu)。
流程虛擬機(jī)中的4個(gè)API
圖 4.1. 流程虛擬機(jī)中的4個(gè)API
服務(wù)接口用在應(yīng)用代碼中,與流程虛擬機(jī)進(jìn)行交互, 它將運(yùn)行在支持事務(wù)的持久化模式下,后端基于數(shù)據(jù)庫。 這是用戶將PVM作為一個(gè)工作流引擎使用的最常用的方式。
如果不想使用持久化方式執(zhí)行流程,可以直接使用客戶端API來處理流程和執(zhí)行對(duì)象。 客戶端API對(duì)外暴露了核心模型對(duì)象的方法。
活動(dòng)API用來實(shí)現(xiàn)活動(dòng)在運(yùn)行時(shí)的行為。 因此一個(gè)活動(dòng)類型實(shí)際上是一個(gè)組件,核心是實(shí)現(xiàn)了ActivityBehaviour接口。 活動(dòng)行為實(shí)現(xiàn)可以控制執(zhí)行的流程。
事件監(jiān)聽器API用來編寫java代碼,它可以用來處理流程事件。 它比活動(dòng)API類似, 唯一的差別是事件監(jiān)聽器不能控制執(zhí)行的流程。
4.2. 活動(dòng)API
活動(dòng)API允許使用java實(shí)現(xiàn)運(yùn)行時(shí)的活動(dòng)行為。
public interface ActivityBehaviour extends Serializable {
void execute(ActivityExecution execution) throws Exception;
}
一個(gè)活動(dòng)就是分配給活動(dòng)的一些行為。 提供的執(zhí)行就是到達(dá)這個(gè)活動(dòng)的執(zhí)行。 ActivityExecution接口 暴露了控制執(zhí)行流程的方法。
public interface ActivityExecution extends OpenExecution {
void waitForSignal();
void take(String transitionName);
void execute(String activityName);
...
}
4.3. 事件監(jiān)聽API
事件監(jiān)聽API允許使用java開發(fā)監(jiān)聽器, 并在特定的流程事件發(fā)生時(shí)調(diào)用,像進(jìn)入一個(gè)活動(dòng)或離開一個(gè)活動(dòng)。 它與活動(dòng)API類似,
不同的是不能控制執(zhí)行流程的傳播。 比如,當(dāng)一個(gè)執(zhí)行選擇了一個(gè)轉(zhuǎn)移,一個(gè)對(duì)應(yīng)的監(jiān)聽器會(huì)被激活, 但是因?yàn)檫@個(gè)轉(zhuǎn)移已經(jīng)被選擇了,
執(zhí)行的流程無法被事件監(jiān)聽器改變。
public interface EventListener extends Serializable {
void notify(EventListenerExecution execution) throws Exception;
}
4.4. 客戶端API
客戶端API是一套暴露了相關(guān)方法的接口, 它用來直接管理流程定義上的執(zhí)行和執(zhí)行對(duì)應(yīng)。
最小的需求,客戶端API和活動(dòng)API需要使用活動(dòng)創(chuàng)建 流程定義并執(zhí)行它。
4.5. 環(huán)境
在持久化執(zhí)行環(huán)境下,環(huán)境的第一目的 是讓流程在不同的事務(wù)環(huán)境下執(zhí)行, 比如Java標(biāo)準(zhǔn)版,Java企業(yè)版,SEAM和Spring。
PVM代碼自身只通過自身定義的接口來調(diào)用事務(wù)資源。 比如,PVM自身擁有一些建立在hibernate會(huì)話,異步消息會(huì)話 和定時(shí)任務(wù)會(huì)話的接口方法。
環(huán)境允許為其配置真實(shí)的實(shí)現(xiàn), 在請(qǐng)求的基礎(chǔ)上實(shí)現(xiàn)服務(wù)的延遲加載, 為事務(wù)的持續(xù)獲得服務(wù)對(duì)象。
一個(gè)環(huán)境工廠是靜態(tài)的,一個(gè)環(huán)境工廠 提供應(yīng)用中的所有線程。
EnvironmentFactory environmentFactory = new PvmEnvironmentFactory("environment.cfg.xml");
環(huán)境部分可以像這樣 圍繞在持久化流程操作周圍:
Environment environment = environmentFactory.openEnvironment();
try {
... inside the environment block...
} finally {
environment.close();
}
PVM自身會(huì)從環(huán)境中獲得所有事務(wù)資源和配置。 Activity實(shí)現(xiàn) 也可以做同樣的事情。
org.jbpm.pvm.internal.cfg.JbpmConfiguration 這個(gè)類扮演著Configuration, ProcessEngine和EnvironmentFactory三個(gè)角色。
4.6. 命令
命令封裝了將被運(yùn)行在環(huán)境塊中的操作。 命令的主要目的是獲得邏輯。
public interface Command<T> extends Serializable {
T execute(Environment environment) throws Exception;
}
4.7. 服務(wù)
這里有三個(gè)主要服務(wù):RepositoryService, ExecutionService和ManagementService。 通常來說,服務(wù)是會(huì)話外觀,用來暴露PVM持久化應(yīng)用的方法。 下一部分用例子展示 這些服務(wù)中的基本方法。
RepositoryService管理 流程定義的資源。
public interface RepositoryService {
Deployment createDeployment();
ProcessDefinitionQuery createProcessDefinitionQuery();
...
}
ExecutionService管理 運(yùn)行時(shí)的執(zhí)行。
public interface ExecutionService {
ProcessInstance startProcessInstanceById(String processDefinitionId);
ProcessInstance signalExecutionById(String executionId);
...
}
ManagementService包含了所有管理操作 來保持系統(tǒng)啟動(dòng)運(yùn)行。
public interface ManagementService {
JobQuery createJobQuery();
void executeJob(long jobDbid);
...
}
所有這些方法都封裝成Command。 這三個(gè)服務(wù)執(zhí)行的方法 都委派給一個(gè)CommandService:
public interface CommandService {
<T> T execute(Command<T> command);
}
CommandService被配置到環(huán)境中。 一個(gè)CommandService鏈可以看做環(huán)繞在一個(gè)命令周圍的一些攔截器。 這就是如何在不同的環(huán)境下 進(jìn)行持久化和事務(wù)支持的核心機(jī)制。
默認(rèn)的配置文件jbpm.default.cfg.xml 包含了下面的配置服務(wù)。
<jbpm-configuration>
<process-engine>
<repository-service />
<repository-cache />
<execution-service />
<history-service />
<management-service />
<identity-service />
<task-service />
文件 jbpm.tx.hibernate.cfg.xml包含了 下面的command service配置:
<jbpm-configuration>
<process-engine-context>
<command-service>
<retry-interceptor />
<environment-interceptor />
<standard-transaction-interceptor />
</command-service>
</process-engine-context>
...
這些服務(wù),比如repository-service,execution-service
和management-service將按照類型找到配置好的command-service。
command-service標(biāo)簽符合默認(rèn)的命令服務(wù), 基本上什么也不做, 只是在提供給它的環(huán)境上執(zhí)行命令。
配置的command-service結(jié)果, 在默認(rèn)的命令執(zhí)行期下面的三個(gè)攔截器鏈中。
CommandService攔截器
圖 4.2. CommandService攔截器
retry攔截器是鏈中的第一個(gè),它會(huì)被環(huán)境 當(dāng)做CommandService.class暴露出來。 所以retry攔截器會(huì)分別提供給repository-service, execution-service和management-service這些服務(wù)。
retry-interceptor會(huì)獲取hiberate的StaleObjectExceptions (因?yàn)闃酚^鎖失敗)并重新嘗試執(zhí)行命令。
environment-interceptor會(huì)把一個(gè)環(huán)境塊 放到命令執(zhí)行的周圍。
standard-transaction-interceptor會(huì)初始化一個(gè) StandardTransaction。hibernate會(huì)話/事務(wù)會(huì)被作為 標(biāo)準(zhǔn)事務(wù)的一個(gè)資源。
這個(gè)攔截器棧的不同配置也可以使用:
* 把執(zhí)行委派到一個(gè)本地ejb命令服務(wù), 這樣可以啟動(dòng)一個(gè)內(nèi)容管理的事務(wù)。
* 把執(zhí)行委派到一個(gè)遠(yuǎn)程ejb命令服務(wù), 這樣命令實(shí)際執(zhí)行在一個(gè)不同的JVM上。
* 把命令打包成一個(gè)異步消息, 這樣命令會(huì)異步執(zhí)行在一個(gè)不同的事務(wù)中。
完整版內(nèi)容
http://family168.com/tutorial/jbpm4devguide/html/index.html
jbpm.jar包含了一些默認(rèn)配置文件, 它們可以導(dǎo)入到用戶配置文件中。
這樣,用戶很容易選擇包含或排除哪些功能。 而且這些配置信息也包含了實(shí)現(xiàn), 所以用戶可以只導(dǎo)入那些起作用的配置文件, 當(dāng)我們發(fā)布的配置文件中出現(xiàn)了修改的時(shí)候。
配置文件可以導(dǎo)入到用戶的jbpm.cfg.xml中:
jbpm.default.cfg.xml
jbpm.identity.cfg.xml
jbpm.jbossremote.cfg.xml
jbpm.jobexecutor.cfg.xml
jbpm.tx.hibernate.cfg.xml
jbpm.tx.jta.cfg.xml
jbpm.default.cfg.xml:包含了默認(rèn)的配置, 比如服務(wù),hibernate配置(來自jbpm.hibernate.cfg.xml中的配置), hibernate會(huì)話工廠,業(yè)務(wù)日歷等等。
一個(gè)標(biāo)準(zhǔn)的java配置看起來像是這樣:
<?xml version="1.0" encoding="UTF-8"?>
<jbpm-configuration>
<import resource="jbpm.default.cfg.xml" />
<import resource="jbpm.tx.hibernate.cfg.xml" />
<import resource="jbpm.jpdl.cfg.xml" />
<import resource="jbpm.identity.cfg.xml" />
<import resource="jbpm.jobexecutor.cfg.xml" />
</jbpm-configuration>
在一個(gè)JTA環(huán)境中,使用jbpm.tx.jta.cfg.xml 替換jbpm.tx.hibernate.cfg.xml。
如果希望自定義這些配置中的任何部分,可以在jbpm.cfg.xml中 使用自定義的內(nèi)容替換引用部分。
jbpm.jar也包含了下列hibernate映射配置文件:
jbpm.execution.hbm.xml
jbpm.history.hbm.xml
jbpm.identity.hbm.xml
jbpm.repository.hbm.xml
jbpm.task.hbm.xml
jbpm.jpdl.hbm.xml
所有這些將java領(lǐng)域模型映射到一個(gè)關(guān)系數(shù)據(jù)庫中。
jbpm.jar還包含的其他配置文件:
jbpm.task.lifecycle.xml
jbpm.variable.types.xml
jbpm.wire.bindings.xml
jbpm.jpdl.activities.xml
jbpm.jpdl.eventlisteners.xml
如何從配置文件開始進(jìn)行解析,參考
* 類 org.jbpm.pvm.internal.env.JbpmConfigurationParser
* 資源 modules/pvm/src/main/resources/jbpm.wire.bindings.xml
* 包 modules/pvm/src/main/java/org/jbpm/pvm/internal/wire/binding
完整版內(nèi)容
http://family168.com/tutorial/jbpm4devguide/html/index.html