摘要: 9月1號4.1發布了，上周將jBPM4.1的用戶手冊并提供給大家下載了，請見博客：http://www.tkk7.com/kaysurf168/archive/2009/09/10/294523.html，現在將jBPM4.1的中文開發指南也提供給大家下載，希望降低大家學習jbpm4的難度。有翻譯不當的地方還請指出。
  閱讀全文      摘要: 這篇文章主要講述jBPM4.1的新特性和翻譯用戶手冊的內容更新下載。  閱讀全文      摘要: 《每天一課，jBPM4》視頻教程今天推出基本應用系列——第五課，第五課主要講了jBPM4的流程追蹤。從下一課開始，我們將進入高級應用系列，主要是整合Spring+Hibernate+Struts2+jBPM4，以這些框架為基礎實現報銷流程。  閱讀全文      摘要: 《每天一課，jBPM4》視頻教程今天推出基本應用系列——第四課，第四課主要講了jBPM4的監聽事件,jBPM4使用了Oberservable模式實現的事件監聽。  閱讀全文      摘要: 這一課的內容比較多，除了對jBPM4的身份認證的管理的進行講解之外，還講述了jBPM4現在的身份認證還存在的一些功能缺陷和解決方法。  閱讀全文      摘要: 經常有人問我，jBPM4視頻教程到底有多少課，能講到什么程度？這里我就放出jBPM4視頻教程系列的初期規劃，同時我們今天還推出了jBPM4視頻教程應用系列的第二課。并提供了我們現有視頻教程的觀看和下載鏈接。  閱讀全文      摘要: 第一次使用工作流做項目或產品，遇到最簡單最常見的需求就是分配任務，待辦任務列表以及一些簡單的流向判斷，這是基本所有的流程都要實現的，而我們這一課的內容主要就是教大家在一個簡單的業務流程里實現這些功能。  閱讀全文      摘要: 《每天一課，jBPM4》視頻教程今天推出基本應用系列——第一課，這個系列主要是以請假流程為例，請假流程作為OA中的一個經典案例，覆蓋了多種流程特性，同時又兼具易讀性。主要內容是執行請假流程，實現流程駁回，用戶權限，任務與表單綁定以及流程追蹤等功能。  閱讀全文      摘要: 這一課主要是講解流程實例的管理和流程活動的分類介紹，這一課的視頻也是入門系列的最后一課，因為到這一課為止我們就能讓大家入門jBPM4了，對于jBPM4的一些簡單應用已經沒有問題了。從下一課開始，我們將進入jBPM4系列視頻教程的基本應用系列，正式開始接觸真正的業務場景的用例。  閱讀全文      摘要: 《每天一課，jBPM4》視頻教程今天推出第二課，主要內容是在web工程里應用jBPM4。  閱讀全文      摘要: 隨著jBPM4.0GA版本的發布，使用jBPM4的人也開始多起來，雖然我們已經翻譯了jBPM-4的用戶手冊和開發指南，但jBPM4的官方文檔內容還是不夠全面，雖然理論知識比較豐富，但是缺少實踐教授內容。我們推出的《每天一課，jBPM4》是jBPM4第一份系列視頻教程，手把手教您學會jBPM4，并將jBPM4應用在工作流管理平臺中，同時我們還會提供視頻課程里的源代碼。  閱讀全文      摘要: 這2天我們忙著做了下jBPM4和Spring Security的專題頁面，提供了不少關于jBPM4和Spring Security的技術資料和示例。  閱讀全文      摘要: 在oa里我們實現一套權限管理，包括資源管理、角色管理、用戶管理、菜單管理以及組織機構管理，整套權限采用的是RBAC的模型。下面給大家分享下效果，同時也提供源碼下載，希望大家多提建議。  閱讀全文      摘要: 鑒于各位都非常期待PDF的版本，我便把用戶指南提供給大家下載，希望大家能夠多多反饋，這樣才能提高我們的翻譯質量，對大家更是有好處。開發指南的內容更豐富些，如果有感興趣幫忙校稿的朋友可以聯系我們O(∩_∩)O哈哈~  閱讀全文   最近一直在整流程控制臺，發現還是有不少成就感的，尤其昨天又實現了動畫回放流程。這可是忽悠領導的最佳手段啊，我先給大家看一下我們控制臺的規劃和進度（提供源碼下載地址
）：

-------------------------------------------------近期
* 細化task的生命周期，重新整理task操作
* 流程實例歷史
  * 表格方式查看流程歷史
 

------------------------------------------------- 遠景
* 流程仿真
* 修改流程圖
* 細粒度權限控制
* 回退
* 會簽
* 委派
* swimlane
* BI
* BAM
* 儀表盤


-------------------------------------------------ChangeLog

* 2009-07-01
* [DONE] 實現動畫方式回放流程

* [DONE] 實現deployment的suspend, resume（CR1顯示已暫停定義列表時出現問題，trunk下已修正，等待GA）
* [DONE] 實現processInstance的suspend, resume, end（CR1和trunk里，都沒有暴露suspend和resume方法）
* [DONE] 實現personalTasks, groupTasks, take task, cancel task

* 2009-06-29

* [DONE] 登陸頁面，登錄名和密碼為1/1
* [DONE] 添加start和signal,complete task時，添加變量
* [DONE] 整合web流程設計器，可以直接發布流程定義
* [DONE] 國際化

* 2009-06-01 and before

* [DONE] 發布xml格式的流程定義
* [DONE] 流程定義管理（list, start, delete）
* [DONE] 顯示流程圖（只在Process Instance詳細信息中可顯示）
* [DONE] 流程實例管理（list, signal, view, delete）
* [DONE] 任務管理（list, complete）
* [DONE] 追蹤流程圖（顯示Process Instance的當前位置）
* [DONE] 多流向選擇
* [DONE] 用戶權限（user, group, membership的CRUD功能）
* [DONE] 報表（most active process）

呵呵，現在實現的功能畢竟還是有限，我們的功能規劃在一定程度上可能有些局限，希望大家能給多提提建議，認為控制臺里還可以加些什么功能。這可是開源的啊，大家為了自己也要多提出建議來，O(∩_∩)O哈哈~

下面是我們控制臺一些功能的視頻演示，包括流程設計和發布，動畫回放流程等。
大家可以看看視頻：http://www.family168.com/bbs/dispbbs.asp?boardid=6&Id=473
截圖請看:http://www.family168.com/bbs/dispbbs.asp?boardid=6&Id=463
svn的下載地址：http://jbpmside.googlecode.com/svn/trunk

     摘要: 我們的控制臺現已實現了流程管理、流程監控、流程建模和仿真以及報表等，建模和仿真是使用js做了一個web設計器jPDL整合在控制臺中。  閱讀全文 要知道如何將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中創建了sessionFactory，而我們只需要一個sessionFactory。既然要將jBPM4與Spring的整 合，那就希望由Spring來統一管理sessionFactory和事務，在Spring的配置文件中構造一個sessionFactory。 ProcessEngine是jBPM4的Facade模式，一切由它與外部交互，
  第2步：在Spring配置文件中寫一個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中創建一個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創建的spring事務和hibernate的session改成從當前的ThreadLocal中獲得session和事務。
第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主要是控制事務，在processEngine外面創建事務，這樣使用的時候會先調用jbpmTemplate，再調用processEngine，否則它會說事務沒有啟動。在jbpmTemplate中注入processEngine：
    public void setProcessEngine(ProcessEngine processEngine) {
        this.processEngine = processEngine;
    }
    這里我的理解是我們在上面已經將事務改成從當前的Threadlocal中獲得，所以jBPM4是必須當前有事務，如果我沒有創建事務的話，在使用 processEngine時就會說事務沒有啟動。所以我們就封裝了一個jbpmTemplate，如果我的理解有誤還請大家指出。
   第1種整合方式的例子下載http://www.family168.com/，第2種整合方式之后可以看我們的jBPM-Side里的控制臺。

7.6. 流程同步

為了進行流程同步建模，在執行中這是一個父子樹形結構。 這個想法是執行主路徑是樹的根。 流程的主路徑也被稱作流程實例。 當在給定流程定義上啟動或創建一個新流程實例時， 執行便被創建。

現在，因為執行的主路徑和流程實例是相同對象， 這保證了用法的簡單， 在沒有同步情況的簡單流程下。
基本執行結構的UML類圖



圖 7.6. 基本執行結構的UML類圖

為了建立執行的多同步路徑，活動實現比如一個分支或切分 創建子執行， 使用ActivityExecution.createExecution方法。 活動實現比如結合或合并可以停止流程的這些同步路徑， 通過調用執行同步的stop方法。

只有葉子執行可以激活，非葉子執行應該不是激活的。 這個執行的樹形結構沒有堅持一個同步或結合行為的特殊類型。 它從事著分支或和切分 和結合或和合并來使用執行樹結構， 用任何方式，他們想定義期望的同步行為。 這里我們看一個同步執行的例子。
執行的同步路徑



圖 7.7. 執行的同步路徑

這里有執行的一個付款和一個發貨路徑。 在這種情況，水平線上的活動展示了分支和結合。這個執行顯示了三個執行。 執行的主路徑不是激活的（顯示成灰色） 執行的付款和發貨路徑是激活的，分別指向了 bill和ship活動。

從事活動行為的實現，是他們想使用的執行結構。 假設多個任務必須在執行進行之前完成。 活動行為可以為這個產生一系列子執行。 或者可以選擇，任務組件可以支持任務組， 分配給單獨的執行。在那種情況， 任務組件成為同步任務的響應， 因此把這個責任移動到執行樹形結構范圍之外。
7.7. 異常處理器

在所有分配到流程的代碼中，像 Activity，EventListeners和 Condition，可能分配給異常處理器。 這可以想成是把這些實現的方法實現包含在try-catch塊中。 但是為了構建更多可復用的構建塊， 為了委派類和異常處理邏輯， 異常處理器可以添加到核心流程模型中。

一個異常處理器可以分配給任何流程元素。 當一個異常發生在一個委派類中，一個匹配的異常處理器就會被找到。 如果找到了一個這樣的異常處理器，它會有一個處理這個異常的機會。

如果一個異常處理器處理完成，沒有出現問題，然后這個異常會 被認為是處理了，就會在委派代碼調用后繼續。 比如，一個轉移有三個動作，第二個動作拋出一個異常， 這個異常被異常處理器處理，然后

編寫自動活動，異常處理器提醒是很容易的。 默認是任意執行。沒有方法需要在執行中調用。 所以如果一個自動活動拋出一個異常，被異常處理器處理， 這個執行會在這個執行后繼續執行。這對于控制流向活動 就會有一個更大的困難。它們可能需要包含try-finally塊 來調用執行中對應的方法，在異常處理器 獲得一個機會來處理異常。比如，如果活動是等待狀態， 然后發生了一個異常，這里就會有一個風險，線程會跳出 execution.waitForSignal()的調用， 導致執行在這個活動以后繼續執行。

TODO: exceptionhandler.isRethrowMasked

TODO: transactional exception handlers

TODO: we never catch errors
7.8. 流程修改

TODO: 流程修改
7.9. 鎖定和流程狀態

一個執行的狀態不是激活就是鎖定。 一個激活的執行不是執行就是等待外部觸發器。 如果一個執行不是STATE_ACTIVE，那么它就是被鎖定。 一個鎖定的執行是只讀的，不能接受任何外部觸發器。

當一個新執行被創建時，它是STATE_ACTIVE。 為了把狀態修改成鎖定狀態，使用lock(String)。一些STATE_*常量 被提供了，它們演示了最常用的鎖定狀態。 但是在圖片中的'...'狀態展示了任何字符串 都可以作為狀態提供給lock方法。
執行的狀態



圖 7.8. 執行的狀態

如果一個執行被鎖定，修改執行的方法會 拋出一個PvmException，信息會引用真實的鎖定狀態。 觸發事件，更新變量，更新優先級，添加注釋 不會當做是修改執行。 子節點的創建和刪除也不會檢測， 這意味著那些方法可以被外部API客戶和活動行為調用， 即使執行在鎖定狀態。

確保比較getState()和STATE_*常量時 使用.equals，不要使用'=='，因為如果執行從持久存儲加載。 會創建一個新字符串，而不是使用常量。

一個執行實現會被鎖定：

    * 當它結束
    * 當它暫停
    * 在異步延續過程中

更多的，鎖定可以被活動實現使用， 讓執行在等待狀態下只讀，然后為這個執行傳遞 的外部實例就像這樣：

    * 一個人員任務
    * 一個服務調用
    * 一個等待狀態當探測器檢測一個文件的出現時就結束

在這些情況，策略是外部實例應該獲得 執行的完全控制，因為它想要控制什么應該允許，什么不應該。 為了獲得那種控制，他們鎖定了執行，所以所有內部交互 必須通過外部實例傳遞。

一個創建外部實例的主要原因是， 它們可以在執行已經執行過還存在。比如， 在服務調用的情況，定時器可以導致執行獲得超時轉移。 當響應在超時后到達，服務調用實例應該 確認它沒有signal這個執行。所以服務調用可以看做 一個活動實例（活動實例） 是對活動每個執行的唯一實例。

外部實例它們自己負責管理執行鎖定。 如果定時器和客戶端應用結果是選擇 外部實例，而不是直接選擇執行，然后在理論上是不必要的。 它是從事活動行為實現，無論它希望 執行鎖定還是解鎖。 活動可以實現循環，基于轉移或活動組合。 循環可以包含等待狀態。

為了支持多次自動循環執行，流程虛擬機 把執行的傳播從尾部遞歸轉換成while循環。
7.2. 子流程

TODO: 子流程
7.3. 默認執行行為

當一個Activity被用作活動行為， 它可以使用下面的方法從外部控制流程：

    * waitForSignal()
    * take(Transition)
    * end(*)
    * execute(Activity)
    * createExecution(*)

當Activity實現用做活動行為， 沒有調用任何下面的流程傳播方法，然后 在活動執行時，執行會使用默認執行行為。

默認執行行為定義在下面：

    * 如果當前活動有一個默認向外轉移，選擇它。
    * 如果當前活動有一個父活動，回退到父活動。
    * 否則，結束這個執行。

流程語言可以重寫默認執行行為， 通過重寫ExecutionImpl中的 proceed方法。
7.4. 功能活動

活動也可以用作事件監聽器，被稱作功能活動。 自動活動的例子是發送郵件，執行數據庫更新， 生成pdf，計算平均數，等等。 所有這些都是自動活動，沒有改變執行流向。 這里是這些活動如何實現：

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方法獲得一個OpenExecution， 這是ActivityExecution和 EventListenerExecution的超類。 OpenExecution沒有提供任何特定目的的方法， 但是依舊是當前狀態，流程定義可以通過變量檢驗， 這包含了環境信息 對應流程執行。

這些方法其實都不能調用執行傳播方法。 所以在perform方法完成后，執行會 執行默認的方式。
7.5. 執行和線程

這一章解釋流程虛擬機如何通過客戶端的線程， 把一個執行從一個等待狀態帶到另一個。

當一個客戶調用一個執行的一個方法（比如signal方法）。 默認，流程虛擬機會使用線程執行流程 直到它到達一個等待狀態。一旦下一個等待狀態到達， 這個方法會返回，客戶端的線程就會返回。 這是流程虛擬機操作的默認方式。 兩個更多的異步執行可以補充默認行為： 異步繼續 和異步命令服務。

下一個流程會展示基本理論。 它有三個等待狀態和四個自動活動。
有很多順序自動活動的流程。



圖 7.1. 有很多順序自動活動的流程。

這里是如何構建流程：

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();

讓我們和你一起順著流程的執行一起走。

ClientExecution execution = processDefinition.startProcessInstance();

啟動一個新執行意味著初始活動被執行。 所以如果一個自動活動是初始活動，這意味著第一個未命名的向外轉移會被立刻選擇。 這些都發生在startProcessInstance調用的內部。

然而在這種情況下，初始活動是一個等待狀態。 所以startProcessInstance方法會立刻返回， 執行會定位到初始活動'wait 1'。
一個新執行會被定為到'wait 1'。



圖 7.2. 一個新執行會被定為到'wait 1'。

然后一個外部觸發器會執行signal方法。

execution.signal();

像上面解釋的介紹WaitState， signal會導致選擇默認的轉移。 轉移會把執行移動到automatic 1活動，并執行它。 automatic 1中的Display活動的execute方法， 向控制臺打印一行，它不會 調用execution.waitForSignal()。 因此，執行會通過選擇automatic 1外部的默認轉移進行執行。 在這種狀態，signal方法一直阻塞著。另一個需要考慮的方式是執行方法， 像signal會使用客戶端的線程 來攔截流程定義，直到到達一個等待狀態。

然后執行到達wait 2， 執行WaitState活動。那個方法會調用 execution.waitForSignal()，這會導致signal方法返回。 線程會返回到調用signal方法 的客戶端。

所以，當signal方法返回時，執行定義到wait 2。
一個signal會把執行從'initial'帶到'wait 2'。



圖 7.3. 一個signal會把執行從'initial'帶到'wait 2'。

然后執行會等待一個外部觸發器， 像是一個對象（更準確的是一個對象圖）在內存中， 直到下一個外部觸發器執行signal方法。

execution.signal();

第二個調用的signal會直接讓執行進入wait 3， 在它返回之前。
第二個signal讓執行進入'wait 3'。



圖 7.4. 第二個signal讓執行進入'wait 3'。

使用這個范例的好處是相同的流程定義可以在 客戶執行模式中執行 （在內存內不使用持久化），就像在持久化執行模式， 依賴應用和環境。

當在持久化模式下執行一個流程，你如何綁定 流程執行到數據庫的事務上。
持久化模式下的事務超時



圖 7.5. 持久化模式下的事務超時

在大多情況下，計算工作是流程需要完成的一部分， 在外部觸發器（紅色部分）之后的部分，其實很少。 一般來說，處理流程執行和處理UI傳遞過來的請求 的事務不會超過一秒。 而業務流程中的等待狀態可能超過幾小時，幾天甚至幾年。 當等待狀態啟動后，線索就變得很清晰， 在等待狀態啟動之前，只有計算工作的完成包含在事務中。

考慮一下這種方式： "當到達審批時，所有的自動流程需要做的是什么， 在流程系統需要等待另一個外部觸發器之前？"。 除非pdf需要被創建，或大郵件需要被發送， 大部分時候，它消耗的時間都是可以忽略的。 這就是為什么在默認的持久化執行模式下， 流程工作在客戶端線程下執行。

這個原因也保證著流程同步路徑的情況。 當一個執行的單獨路徑切分成流程同步路徑， 流程花在計算上的時間是可忽略的。 所以為什么分支或切分活動實現是有意義的， 目標持久化模式產生的同步路徑在同一個線程中按順序執行。 基本上它們都只是在同一個事務中的計算工作。 因為分支或切分知道每個執行的同步路徑會返回，所以這只能被完成， 當出現一個等待狀態的時候。

因為這里有一個困難的概念需要掌握，我會再次使用其他詞語來解釋它。 從頭再看一次在持久化執行模式下被流程執行創建出來的它。 如果在一個事務中，一個執行被給與一個外部觸發器， 那導致執行切分成多個執行的同步路徑。 然后執行在計算上的部分也可以忽略。 生成SQL的部分也可以忽略。 因為所有在同步分支上完成的功能，必須在同一個事務中完成， 這里一般沒有指針在分支或切分實現， 在多個線程中產生執行的同步路徑。

為了創建可執行流程，開發者需要確切知道什么是自動活動， 什么是等待狀態，哪些線程會被分配給流程執行。 對于畫業務流程的業務分析人員，事件就很簡單了。 對于他們畫的活動，他們通常只要知道這是一個人或是一個系統響應。 但是他們通常不知道如何轉換線程和事務。

所以對于開發者，第一個任務是分析什么是流程控制的線程中需要執行的， 什么是外部的。 查找外部觸發器是尋找一個流程中的等待狀態的很好的開始， 就像動詞和名詞可以在構建UML類圖中的元素的規則。