開始接觸工作流是兩年前，那時剛進公司，自己也算是個新手，到公司后被分配到做IT網(wǎng)管的項目組，做了些東西，后來成立了個新的項目組，我被分配到這個新組成的項目組，也就是從這以后開始接觸工作流的。當時對工作流是一點概念都沒有，慢慢從公司開發(fā)的基于db的工作流平臺開始接觸工作流，并基于此工作流平臺結合業(yè)務開發(fā)了幾個模塊。
    公司的這個基于db的工作流平臺還是實現(xiàn)了許多功能：
        1、基于web的流程設計器，主要是基于IE的vml語言開發(fā)的，可以設計出如下圖的流程模板。

    此流程模板包括開始環(huán)節(jié)，結束環(huán)節(jié)以及人工處理的兩個環(huán)節(jié)（專家組處理和發(fā)起人確認），實現(xiàn)環(huán)節(jié)的自循環(huán)以及回朔，分別在“專家組處理”環(huán)節(jié)和“發(fā)起人確認”環(huán)節(jié)上實現(xiàn)。基于此流程運行中的實例圖如下：

如圖

    C、多實例（即平常所說的會簽）
    實現(xiàn)了包括所有會簽都完成后才往下個環(huán)節(jié)走和幾個會簽后就可往下個環(huán)節(jié)走的功能，流程的模板如圖：

    其中環(huán)節(jié)模板上帶“M”的環(huán)節(jié)就表示是多實例的環(huán)節(jié)。
    運行中的實例如圖：

    D、子流程子流程是在一個虛擬環(huán)節(jié)中實現(xiàn)的，即該環(huán)節(jié)不是人工環(huán)節(jié)。如圖：

    基本上一個簡單的工作流平臺的功能都差不多實現(xiàn)了，不過在使用過程中還是發(fā)現(xiàn)了許多的弊端，畢竟系統(tǒng)的邏輯大部分是基于數(shù)據(jù)庫函數(shù)實現(xiàn)的，這使得大部分的邏輯都要依賴于數(shù)據(jù)庫，而外圍的一些基于java的邏輯實現(xiàn)就比較難實現(xiàn)了，舉個例子：在和外系統(tǒng)做接口時，當某個環(huán)節(jié)竣工后要向外系統(tǒng)發(fā)信息，而信息是通過url的方式傳遞的，這個用java實現(xiàn)是很容易的，而用數(shù)據(jù)庫函數(shù)就無法直接實現(xiàn)了（據(jù)目前自己掌握的技術判斷，不知是否有辦法實現(xiàn)，望知道者告知），現(xiàn)在變通的一個做法是在數(shù)據(jù)庫里保存信息，然后通過quartz定時的掃描該表，有數(shù)據(jù)則通過httpclient給外系統(tǒng)發(fā)送信息。還有模型本身只有開始環(huán)節(jié)，結束環(huán)節(jié)，虛擬環(huán)節(jié)和人工執(zhí)行環(huán)節(jié)，使得客戶提的要按業(yè)務路由的功能就無法實現(xiàn)了，因為缺少個判斷環(huán)節(jié)模板，就是jbpm中的decision環(huán)節(jié)模板，所以在創(chuàng)建下個環(huán)節(jié)的時候大部分都是人為的主觀去判斷到底是走上圖中的“方案審核”還是“任務分配”環(huán)節(jié)。這使得運用流程整合業(yè)務邏輯時并沒有完全的實現(xiàn)流程的自動化。
    其實還有很多的缺陷，只是我們都是通過變相的方式給予了實現(xiàn)，可是客戶有些需求在該平臺上還是無法實現(xiàn)的。鑒于此，就開始尋找開源的工作流引擎，在osworkflow、jbpm、shark等的開源工作流引擎中選擇了jbpm。為什么會選擇jbpm呢？原因還是蠻多的，具體列出幾條如下幾條：
    1、 基于petri net理論實現(xiàn)的工作流。
    2、 引擎核心以微內(nèi)核的方式實現(xiàn)（主要邏輯都在graph包下）。
    3、 基于hibernate實現(xiàn)持久化。
    4、 很容易的和spring實現(xiàn)整合，通過spring-modules實現(xiàn)整合。
等。最后附上一個最復雜的流程圖（像蜘蛛網(wǎng)更貼切^_^）