摘要: 隨著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這個執行。所以服務調用可以看做 一個活動實例（活動實例） 是對活動每個執行的唯一實例。

外部實例它們自己負責管理執行鎖定。 如果定時器和客戶端應用結果是選擇 外部實例，而不是直接選擇執行，然后在理論上是不必要的。 它是從事活動行為實現，無論它希望 執行鎖定還是解鎖。