摘要:   閱讀全文      摘要:   閱讀全文

作者:楊洪波
jbpm解析流程定義有三種方式:
1)par包
static ProcessDefinition auctionProcess =
      ProcessArchive.parse("org/jbpm/tdd/auction.par");
注意,必須在classes的org/jbpm/tdd/目錄下有一個auction.par文件

2)xml文件方式
static ProcessDefinition auctionProcess =
      JpdlXmlReader.parseFromResource("org/jbpm/tdd/auction.xml");
注意,必須在classes的org/jbpm/tdd/目錄下有一個auction.xml文件

3)文本方式
static ProcessDefinition auctionProcess = JpdlXmlReader.parse(
    "<process-definition>" +
    "  <start-state name='start'>" +
    "    <transition to='auction'/>" +
    "  </start-state>" +
    "  <state name='auction'>" +
    "    <transition to='end'/>" +
    "  </state>" +
    "  <end-state name='end'/>" +
    "</process-definition>");
這種方式的本質和xml文件解析方式是一樣的.

作者:楊洪波

作者:楊洪波

shark和jbpm配置文件處理方式比較

1.都使用了單例模式
我想這個是最基本的,一般的程序員寫解析程序都會這樣使用;要說明的是,AgileFlow
除了使用單例模式,還實現了配置文件的動態裝載,如果用戶修改了配置文件,它能夠在
運行中動態的獲取這些變化.
使用jbpm時,第一句話就要使用該模式:JbpmServiceFactory.getInstance()....

2.都實現了缺省配置和定制配置
Shark中,缺省配置放在一個深層次的目錄中,定制配置放在config目錄,兩個配置
文件的內容差不多;
jbpm中,缺省配置放在代碼中實現,如下:
propertyClassNames = new HashMap();
propertyClassNames.put( "default", "org.jbpm.impl.DefaultServiceFactory" );
abbreviatedClassNames.put( "jbpm.service.factory", propertyClassNames );
定制配置放在config目錄中,為jbpm.properties
比較而言,jbpm的實現方式要好,理由如下:
1)缺省配置容易找到
2)定制配置很簡單,默認是沒有配置的,比shark的要清爽很多

3.都實現了用一個單例實現多個單例
我在Shark學習系列的文章中討論過這個功能,jbpm是在JbpmConfiguration.java中實現的:
private void instantiateConfiguredObjects() {
    // instantiate configured objects
    this.fileMgr = (FileMgr) instantiate( "jbpm.file.mgr", FileMgr.class );
    this.idGenerator = (IdGenerator) instantiate( "jbpm.id.generator", IdGenerator.class );
    this.serviceFactory = (ServiceFactory) instantiate( "jbpm.service.factory", ServiceFactory.class );
}

1.都使用了單例模式
我想這個是最基本的,一般的程序員寫解析程序都會這樣使用;要說明的是,AgileFlow
除了使用單例模式,還實現了配置文件的動態裝載,如果用戶修改了配置文件,它能夠在
運行中動態的獲取這些變化.
使用jbpm時,第一句話就要使用該模式:JbpmServiceFactory.getInstance()....

2.都實現了缺省配置和定制配置
Shark中,缺省配置放在一個深層次的目錄中,定制配置放在config目錄,兩個配置
文件的內容差不多;
jbpm中,缺省配置放在代碼中實現,如下:
propertyClassNames = new HashMap();
propertyClassNames.put( "default", "org.jbpm.impl.DefaultServiceFactory" );
abbreviatedClassNames.put( "jbpm.service.factory", propertyClassNames );
定制配置放在config目錄中,為jbpm.properties
比較而言,jbpm的實現方式要好,理由如下:
1)缺省配置容易找到
2)定制配置很簡單,默認是沒有配置的,比shark的要清爽很多

3.都實現了用一個單例實現多個單例
我在Shark學習系列的文章中討論過這個功能,jbpm是在JbpmConfiguration.java中實現的:
private void instantiateConfiguredObjects() {
    // instantiate configured objects
    this.fileMgr = (FileMgr) instantiate( "jbpm.file.mgr", FileMgr.class );
    this.idGenerator = (IdGenerator) instantiate( "jbpm.id.generator", IdGenerator.class );
    this.serviceFactory = (ServiceFactory) instantiate( "jbpm.service.factory", ServiceFactory.class );
}

     摘要: 目前我看過采用JBPM的工作流有web-console (JBPM 3.2.1自帶）、RUNA WFE、SMART,就這三個我做一個比較：

RUNA WFE

RUNA WFE是上面提到的三個中，唯一可以直接部署應用的，當然也有它的缺點，下面我會提到。這個框架采用的是Struts作為表示層，流程管理和組織架構管理都做的不錯，良好的國際化，文檔很全。如果只打算研究可以看下它的permission部分，它已經實現了對流程查看、啟動、結束等的權限控制，JBPM自身在這部分基本還是TODO狀態。

  閱讀全文      摘要: 研究工作流及其相關技術的人一定知道這個組織——工作流管理聯盟（簡稱WfMC，Workflow Management Coalition），其成立于1993年。作為工作流技術標準化的工業組織，WfMC提出的工作流系統參考模型（Reference Model）無疑為各家工作流軟件廠商的系統設計規劃提供了最權威的參考，乃至標準。下面就是這個參考模型：

  閱讀全文 作者:胡長城
 
        目前主要列出了13家公司，這幾家主要是做workflow的。當然，目前國內做OA，做Platform（包含workflow）的公司很多，但是，在workflow方面非常專注的，比較少。
        還有很多公司沒有列出來，主要是個人感覺他們在workflow這一個方面并不是非常強勁（可能他們的product，platform很好），比如：BOS（金蝶），EOS（普元），GK-Workflow（北京點擊科技），iOffice.net（廣州紅帆），KA-2（北京科諾），OW4J（Oracle中國），UAP（用友），HotOA（上海華炎），ZoTn（中唐）。還有些小型的工作流產品公司，產品并不是非常有特色，也沒有列出來，比如：WiseFlow（上海維泰），aoflow（北京奧寶）

         目前我所知道的，在國內比較有名的國外workflow/BPM 廠商，主要有三家：Ultimus（較早進入中國），BusinessWare（北京麒麟，美國VITRIA）,2003年進入中國； webMethods（2003年底在北京成立辦事處)
         以下的“★”表示可workflow參考度和可研究度，越多表示產品在workflow這一方面更有特點。注：BusinessWare只給了三個“★”，是表示其所定位在解決方案和項目實施，整個產品定位在Business Process Integration層次，有些超越目前國內市場需求。

編號
I00	★★★	AWF（北京炎黃盈動）	嵌入式的工作流平臺，功能不是太完善，主要研發實力不足
I01	★★	DLFlo（上海東蘭）	2000就開始做工作流平臺，2002年推出了java版本。但整體來看，發展的不是很理想
I02	★★★★★	LiveFlow（上海東蘭）	和DLFlo定位差不多，都面向二次開發平臺。但是正個產品還是停留在“workflow”功能層次。—— 但是，吸收了DLFlo的很多經驗，所以其工作流平臺目前還是屬于國內前列
I03	★★★	BusinessWare（北京麒麟遠創）	主要方向是BPM和BPI（業務流程整合）。整個產品是一個“集成平臺”。
I04	★★	e-cology（上海泛微）	但從workflow這個層次來說，泛微沒有太多的特色。
I05	★★	eWay Platform（北京東方易維）	Eway的黃金時代已經一去不復返了，自動“馬毅”那個團隊離開以后。工作流的一些理念當時還是值得的，有些類似ofbiz。表單處里采用二次開發jsp頁面來處理。
I06	★★★	JKCFlow（四川金科成）	JFCFlow從早期的工作流產品轉移向“業務基礎軟件平臺”，但是整個產品平臺目前還只能算是，一個OA開發平臺。在workflow和model方面并不是非常的強
I07	★★★★	JoinWork（上海天際星）	Joinwork剛剛推出來，其開發者丁宏比較欣賞jBPM，joinwork很多思想也是參考了jBPM。但功能上稍微弱了點。但是其基于SWT的設計思想很值得借鑒。
I08	★★★★	Koof MetaLogic（北京世紀金政）	去年推出的workflow產品，專做工作流平臺，雖然主要定位于oa和電子政務平臺，但工作流這一快，還是有很多克參考的功能。
I09	★★★	RiseOffice（北京有生博大）	當前版本riseoffice5.1，整個工作流產品基本上為“OA審批流程”量身定做。其表單處里和權限控制很有特色，以及審批歷程的處理。整個design端時采用web的，用的 addflow控件。
I10	★★★★★	SunFlow（杭州信雅達）	sunFlow這一兩年發展很迅速，大有趕超SynchroFlow 趨勢。 其產品最大的特色是采用基于域的聯邦系統架構，對分布式管理、運行支持較好。而且也是目前國內為數不多的可以支持“仿真”的工作流系統。
I11	★★★★★	SynchroFlow（西安協同數碼）	基本上非常嚴格遵循了wfmc的規范，完全實現了interface1、interface2、interface3、interface5。 這一點上，SunFlow和SynchroFlow都有很多相像的地方，都遺留很多學院研究的特點（這兩個產品的最初原型都是在大學中誕生的）。
I12	★★★★★	Utimus（國內） 上海敏照（增值代理商），上海永信（增值代理商） Ultimus上海分公司	進入中國最早的國外工作流產品，整個產品采用邏輯的組織結構圖，工作流系統支持的功能也很強。其比較有特色的是其“事件條件表

  作者:胡長城
今天和同事chelsea 就活動實例狀態的實現思路上進行了討論。我們兩個站在了兩個不同的角度來看待，這兩個不同的角度也正好眼下最為常見到的兩種實現思路：
helsea是從狀態角度來看待，當然也完全是從state pattern的角度來思考：狀態在達到某個狀態的時候，會引起或必須引起活動實例執行什么操作。

而我是從活動實例的角度來考慮，活動實例的狀態只是活動實例的一個屬性體，是因為什么行為，造成了什么狀態的結果。


 這兩種觀點，沒有誰對誰錯，也沒有誰優誰劣，兩者是站在不同的角度來分析同一個問題。其實這兩種模式在應用中都是很普遍的，也都是能夠很好的解決問題的。不過在現有的workflow引擎實現中，基于活動實例的角度是占絕大多數的，比如obe，shark等等。所以我受這個的影響也是比較深的。


先說說基于活動活動實例的角度的思路吧：



讓我下先來看看狀態類：

public final class WMActivityInstanceState extends WMObjectState {

public static final int OPEN_NOTRUNNING_INT = 0;

public static final int OPEN_SUSPENDED_INT = 1;

}

或者也可以這么表示：

public enum WMActivityInstanceState{

NOTRUNNIN(0),

SUSPENDED(1);

private int code;

private WMActivityInstanceState(int code){this.code = code;}
public int getCode(){return this.code}

}




對于活動實例來說，狀態只是其一個屬性而已：

public class BasicActivityInstance extends BasicAttributedEntity{

private int _state;

public void setState(int state) {

_state = state; }

}

或者也可以是

Public void setState(WMActivityInstanceState state)




所以，從活動實例的角度來看，狀態之間的關系是平行的。你可以在執行完一些初始化的操作之后，將活動實例的狀態設置為Initialized：當然這個操作你必須顯示的去設置活動實例（當然，你可以用一些Event去處理），比如調用活動實例的setState方法。至于為什么調用這個方法，或者此時設置的狀態是對是錯，活動實例并不關心。



下面再來說說基于狀態角度的思路吧，這個思路大體可以說就是state pattern的應用。



     說道這兒，您可以看看這篇文檔：從工作流狀態機實踐中總結狀態模式使用心得 。當然如果您對state pattern不是很了解，那么建議你先看看這篇文檔：設計模式之state 。



    State模式的著眼點就是狀態，以狀態的變遷影響實例的行為和動作。其實這就是兩個不同的抽象體：state和stateOwner，我們可以看到，活動實例對象就表現為stateOwner。

   State模式的依據是狀態之間是有有向連接關系的，這有向連接關系其實就是狀態的轉換規則：A-B-C-D-A。

   激發狀態的變遷，是由外界的事件（Event）影響的：這個事件會告知，當前的活動實例狀態要從當前狀態往下一個狀態變遷。而活動實例并不知道下一個狀態是什么，這完全是狀態對象負責維護和告知的。



至此，我們可以看出來了，兩種方式的不同：

第一種方式（基于活動實例），其外界事件是影響到活動實例，或者說在事件中顯示的告知活動實例狀態從什么變為什么。

第二種方式（基于實例狀態），其外界事件是影響到活動實例狀態對象，至于這個狀態的下一個狀態是什么，時間并不知道，完全由活動狀態之間的關系來維護。

作者:tomkoo
以下例子中 采用了jbpm console 的幾個實例用戶

項目提交人 : ernie .

主管審批 : bert

會簽 : ernie , bert , grover

老板審批 : grover

 

正常流程: 項目金額 >= 500W RMB

提交項目 --> 主管審批 --> 會簽 --> 老板審批 --> 審批通過(結束)

正常流程: 項目金額 < 500W RMB

提交項目 --> 主管審批 --> 會簽 --> 審批通過(結束)

其中主管審批, 會簽, 老板審批 , 不通過, 全部退回給項目提交人修改.

會簽中: 所有人全通過, 則通過. 任何一人不通過, 停止其他會簽任務.退回給提交人.

流程定義如下:

 

會簽swimlane class

創建會簽任務實現類

 

 

 

結束不通過時結束其他會簽任務實現

 

 

     摘要: 是一張Ultimus為一個簡單變更定單流程開發的地圖。一個客戶申請變更一個產品或服務將啟動本流程。在收到申請以后，工程經理能拒絕申請，需要一個EMAIL提醒發送給客戶，或申請同時輸入到3個其他團隊（軟件，電子，機械）。當所有需求團隊反饋后，流程使用網絡服務申請一個包括變更所有的輸入和時間和成本的預算包。這些信息將反饋給工程經理做最終檢查和調整。此時，工程經理又一次能夠拒絕申請（如果成本或時間預估過高）。否則，信息將提交給銷售部門添加任何補充信息。然后流程將自動生成一個報價并且和提醒一起發送給客戶。  閱讀全文      摘要: JBoss jBPM is a flexible, extensible workflow management system. JBoss jBPM has an intuitive process language to express business processes graphically in terms of tasks, wait states for asynchronous communication, timers, automated actions,... To bind these operations together, JBoss jBPM has the most powerful and extensible control flow mechanism.

  閱讀全文      摘要: 在下面的例子里，我們將向您展示如何能給用戶分配任務。因為在jBPM工作流

引擎和組織機構模型之間是分離的，對計算參與者的表達語言將總是被限制的。

因此，你必須指定一個任務處理的實現，包括計算任務參與者
  閱讀全文      摘要: 城市政府寬帶網絡軟件平臺連接一個城市的市政府、黨的機關、人大、政法四大類幾十甚至上百個機關。政府部門中有大量的工作是需要部門內、部門之間的多部門、多工作崗位、多工作人員協同工作來完成的。而且其工作呈工作流狀態和事務性狀態（既工作流程的完整性）。
  閱讀全文      摘要: 工作流一直是實施BPM的重要環節，以往的開源與閉源的劃分已經不適合如今的工作流局勢，開源已經滲透到了各個領域，如今的工作流已是三分天下的大局  閱讀全文