摘  要： 介紹了國內目前的工作流領域特點，尤其對臨時動態性需求(會簽、撤銷、任意回退等)的各種場景進行了分析，提出了基于jBPM4的解決思路及一種動態路由的方法，以解決臨時回退的問題。
關鍵詞： jBPM；臨時動態性需求；動態路由

    工作流管理技術[1-2]作為一種過程建模和過程管理的核心技術，是新興于20世紀90年代的一種信息化技術。隨著近些年國內企業、政府信息化的建設，工作流技術被越來越廣泛地應用于業務流程管理(BPM)領域。jBPM是一種輕量級的J2EE開源框架，具有良好的可擴展性。其最新版本較jBPM3.2版本，在核心引擎等方面都有較大改動，本文總結了新版本的特點。結合國內工作流領域的應用特點，本文特別針對臨時動態性需求，分析了各種場景的情況，給出了應用jBPM4的解決思路，為解決臨時回退的問題，提出了一種動態路由的方法，該方法亦可以用于解決各種臨時動態性需求的場景。
1 jBPM4特點
    jBPM是JBoss眾多開源項目中的一個工作流開源項目，也是目前應用最廣泛的工作流項目。在2009年7月10日，JBoss jBPM團隊發布了jBPM4的正式版本。jBPM4完全基于流程虛擬機(PVM)的機制，對核心引擎進行了重新設計，而PVM的引入也使jBPM4可以支持多流程語言[3]。jBPM4特點如下：
    (1)在流程定義的對象上，節點類型劃分更清晰。
    (2)基于觀察者模式的事件監聽(Event-Listener)機制。在jBPM4中活動節點對象(ActivityImpl)、轉移對象(TransitionImpl)、流程定義對象(ProcessDefinitionImpl)，全都繼承了ObservableElementImpl對象，因此，組成流程定義的3個主要元素都可作為觀察者模式中的被觀察者來觀察，而這些對象本身就直接支持注冊各種事件(Event)，然后由監聽器(Listener)來監聽這些Event。
    (3)基于ExecutionImpl、Command模式和AtomicOperation實現的內核引擎在jBPM4中用ExcutionImpl代替jBPM3中Token機制。流程的流轉依賴于ExcutionImpl調用各個AtomicOperation原子操作，如ExecuteActivity、MoveToParentActivity、TransitionTake、TransitionStartActivity、ExecuteEventListener、TransitionEndActivity進行推進，而ExecutionImpl在各個實例對象之間進行轉移。
    (4)加入了歷史庫，但還不完善。
2 國內工作流領域的特點
    目前國內在工作流領域[4]主要的應用是人工工作流，也就是以人工任務密集型的工作流為主。隨著國內企業和公共組織的信息化發展越來越快，IT系統的積累和建設經驗也越來越豐富，以自動任務密集型為主的應用將會逐漸增多。人工任務密集型工作流的應用主要集中在以下領域：電子政務，行政審批，企業協同辦公，電信、電力的工單，企業采購、合同、銷售等。
    從功能需求上，這些人工任務密集型流程的典型特點主要有：(1)用戶友好的流程定義工具。(2)表單能夠自定義。(3)靈活的臨時動態性需求，例如：任意回退、會簽、撤銷等。這些需求，存在很強的人為性因素。
    國內專注于工作流產品方面的公司起步較國外晚，其產品大多只專注于某個行業的具體需求，如：有生博大的工作流產品主要定位于“電子政務系統中的審批流”；西安協同的工作流產品偏重于“電信行業”；信雅達的工作流產品偏重于“金融行業”；上海東蘭的工作流產品則偏重于“協同領域”等等。
3 各種臨時動態性需求情況的解決思路
    jBPM4是由國外開源小組領導的項目，流程定義工具和表單設計并不是其項目的特點，但其在流程處理方面的思想有其特色，特別是流程核心引擎的架構很值得學習研究。筆者在學習研究的過程中，對國內靈活的各種臨時動態性需求的場景進行了模擬分析，提出了如何應用jBPM4來解決問題的思路。
3.1 會簽
    會簽在政府或企業都是必不可少的功能，尤其是審批流中。會簽可以分為單步會簽(只有1個審批環節)及多步會簽(每1個子審批流有多個審批環節)。單步會簽：在流程的某個環節需要由多個辦理人(多個不同部門的領導)共同辦理或者簽署意見，這是企業或政府的內部最為常見的情況。多步會簽(也稱為并聯審批)：其實質就是一個單步的審批環節變為了在部門內部一個比較復雜的審批流程，這個審批流程有多個審批環節。
    多步會簽的情況較為復雜，本文只提供應用jBPM4解決單步會簽的思路：即對TaskService進行擴展開發，實現動態任務實例的創建，參照TaskActivity類中的方法進行擴展，擴展后再調用addTaskParticipatingUser( )或addTaskParticipatingGroup( )方法實現動態增加任務辦理人，此時即實現了單步會簽功能。
3.2 撤銷
    撤銷是指任務在發送給下一個辦理人之后，發現任務發送錯誤，此時在下一個辦理人還沒有辦理之前，可以撤回當前任務，而重新選擇其他人進行辦理。串行流程如圖1所示。

    節點2的處理人(假設是王二)辦理完畢之后，將任務提交，此時任務到達了節點3(假設李三辦理)，這時李三就會收到一個待辦任務，在李三還沒有辦理之前，王二突然發現，有1個業務數據填寫錯誤，或者粘貼的附件錯誤，這時王二需要將發送給李三的任務撤銷，重新更正數據后或修改粘貼的附件后再發送給李三審批。此外，假設節點3的辦理人有2個人(李三和趙五)，那么王二需要在運行期間根據業務特性手動地選擇任務是提交給李三還是趙五，但由于王二的誤操作，把本來應該發給趙五的辦理任務錯發送給了李三，此時，在李三辦理之前，王二也可以將發送給李三的任務撤銷，然后重新發送給趙五。
    對于上述模擬的撤銷，jBPM4解決思路如下：
    (1)刪除需要撤銷的任務實例及其與此任務實例相關的所有工作流實例。在文件TaskServiceImpl.java中，jBPM4提供了級聯刪除任務實例的相關方法：
    public void deleteTaskCascade(String taskId) {
        commandService.execute(new DeleteTaskCmd(taskId，true))；
    }
    (2)修改當前任務實例的狀態。即將張三的已經辦理完畢的節點2對應的TaskInstance的狀態更改為待辦狀態：(Task.STATE_OPEN)
    task.setState(ask.STATE_OPEN)；
    taskService.saveTask(task)；
3.3 任意回退
    回退作為審批流最常見的需求，每1個審批環節都有可能會有審批通過、不通過2種情況。審批不通過時，一般是回退到上一個環節，但是在某些情況下，有可能跨環節回退，而到底回退到哪個環節，可以由用戶根據業務需求進行自定義，并且在回退環節工作完成之后，其下一步的方向也可以由用戶自定義。下面根據各種不同的回退分別模擬并給出解決思路。
3.3.1 串行流程
    串行流程，最直接的方式就是在需要回退的各個節點之間建立回退線，如圖2所示。如果需要從節點4回退到節點2，則直接在節點4之后加1個分支決策節點，連接2個分支，1個是流向節點5，1個是返回節點2。

    對于節點2，在jBPM4中，其參與模式又分為4種：task-assignee(assignee user、assignee expression)、task candidates(candidate-groups、candidate-users)、task assignment handler、task swimlanes。
    (1)task-assignee任務的辦理人的值可以直接指向1個特指的用戶的ID或者1個關聯到業務中某個特指用戶的表達式(如order.owner)。此時，如果assignee賦予了1個特指用戶的ID，回退時不用做任何處理；如果assignee賦予了1個業務表達式，在回退時，需要保證業務表達式的運算邏輯能夠正確執行。
    (2)如果task candidates任務的辦理人為幾個特定的組的集合或者用戶的集合，實際上就是俗稱的“競辦”。這樣的任務被稱為groupTask，必須被某一個組或者用戶拾取才能進行辦理，因此，如果回退到這樣的節點時，需要把任務回退給當時的拾取人。而拾取人需要到HistoryTask和HistoryDetailImpl 2個實體對應的歷史庫中取得。
       (3)task assignment handler任務的辦理人通過用戶自己編寫的代碼來實現，當回退到這樣的節點時，也不需要做特殊處理，只要保證自己的代碼(AssignmentHandler)在執行回退邏輯時同樣能夠正確執行即可。
    (4)task swimlanes任務的辦理人為“泳道”，回退到這樣的節點時，任務的辦理人可以自動取得，同樣不需要做任何處理。
    以上4種情況，在回退之后的處理又分為2種情況：一種是按照原來的路徑重新執行，即節點2→節點3→節點4；另一種是，節點2辦理完畢后，直接返回給節點4。對于第1種情況，不需要做處理。而對于第2種情況，由于在節點2和節點4之間并沒有一個轉移存在，因此jBPM4也沒有提供支持。針對這種情況可以通過動態路由(即動態創建轉移)的思路來實現(具體實現思路見第4節)，實際上回退也可以用動態創建轉移來實現，但不用畫回退線了。
3.3.2 M選N分支流程
    M選N分支流程中，N必須滿足M>N?叟1，假設回退前流程的執行路徑為節點1→節點2→節點4→節點5，如圖3所示，此時回退有2種情況：
    (1)由節點5回退到節點1，而節點1在進行業務數據的修改后，直接返回給節點5的處理人進行辦理或審批。
    (2)由節點5回退到節點1，而節點1在進行業務數據的修改后，重新按照節點1→節點2→節點4→節點5的路徑再執行1遍。
    情況(2)與情況(1)不同的是：在回退之后繼續審批時，需要考慮分支節點的決策條件，在自動決策時要保證決策邏輯正確執行；在人工決策時，需要記錄原來的執行路徑(保證重走節點1→節點2→節點4→節點5)。

3.3.3 同步分裂、“與”匯聚流程
    同步分裂、“與”匯聚流程如圖4所示，回退前執行的路徑為節點1→節點2→(節點3、節點4)→節點5→節點6。此時回退有4種不同的情況：
    (1)由節點6(或節點5)回退到節點2(或節點1)，節點2重新辦理完畢后，直接返回給節點6的處理人進行辦理或審批。
    (2)由節點6(或節點5)回退到節點2(或節點1)，節點2重新辦理完畢后，重新按照節點2→(節點3、節點4)→節點5→節點6的路徑再次執行1遍。
    (3)由節點6(或節點5)回退到節點3(或節點4)，節點3(或節點4)辦理完畢后，直接返回給節點6。
    (4)由節點6(或節點5)回退到節點3(或節點4)，節點3(或節點4)辦理完畢后，按照節點3(或節點4)→節點5→節點6的執行路徑，再次執行。

    情況(1)、(2)和(3)處理起來沒有什么問題。但情況4中，當流程由節點6回退到節點3，節點3辦理完畢后，重走路徑節點3→節點5→節點6時，在“與節點”的“與”運算邏輯就會無法執行，因為另1個“與”分支(節點4)并沒有新的實例產生，流程就會僵死此處。所以可以通過修改JoinActivity.java這個類文件中的方法：
    protected boolean isComplete(List<executionimpl> joined
Executions，Activity activity)
在此方法中加入對該情況的處理代碼即可。
3.3.4 同步分裂、“或”匯聚流程
    同步分裂、“或”匯聚流程如圖5所示，回退前執行的路徑為節點1→節點2→(節點3、節點4)→節點5→節點6。此時回退同樣有4種不同的情況：
    (1)由節點6(或節點5)回退到節點2(或節點1)，節點2重新辦理完畢后，直接返回給節點6的處理人進行辦理或審批。
    (2)由節點6(或節點5)回退到節點2(或節點1)，節點2重新辦理完畢后，重新按照節點2→(節點3、節點4)→節點5→節點6的路徑再次執行1遍。
    (3)由節點6(或節點5)回退到節點3(或節點4)，節點3(或節點4)辦理完畢后，直接返回給節點6。
    (4)由節點6(或節點5)回退到節點3(或節點4)，節點3(或節點4)辦理完畢后，按照節點3→節點5→節點6的執行路徑，再次執行。

    由于是“或”匯聚，因此在實現上不需要做任何其他處理了。
    綜合以上情況，回退本身在理論上有各種各樣的情況存在，再加上業務的回退(或者業務邏輯補償，如果需要就必須在流程的每個環節進行業務快照的備份，在回退時調用這個快照進行補償)，此時回退可以說是整個流程體系中最復雜的。但是在真實的業務情況中，有些可能是根本不會出現或者很少出現，因此要考慮的是能不能通過變通的方式處理。
4 動態路由的思路
    針對于特定的業務實例，有時需要在原本沒有轉移關系的環節之間進行特定的跳轉，例如在圖1中的串行流程中(1-2-3-4-5)，節點4與節點2之間是沒有任何轉移存在的，但是針對于某個運行期的特定業務實例，臨時要求環節直接從節點4回退跳轉到節點2(而略過了節點3)。此時就需要在節點4和節點2之間由程序動態地創建一個轉移(transition)，并設定為優先級最高，如圖6所示。

    因此在執行takeTransition( )方法時，按照優先級將優先執行動態創建的轉移，然后對外暴露1個jumpTransition(String destinationActivityName)方法給客戶端。應用jBPM4實現時可按照如下步驟進行擴展：
    (1)參照文件CompleteTaskCmd.java擴展開發用于跳轉的cmd：JumpTaskCmd。
    (2)參照文件TransitionStartActivity.java的原子操作，定制開發用于跳轉的原子操作JumpTransitionStartActivity。
    由于jBPM4中的執行動作都是基于Command模式實現的，因此在擴展開發自己的跳轉動作時，就可以做到對jBPM4本身的代碼不做侵入修改而實現。這種臨時建立動態路由的思路不僅可以用于回退，同樣可以用于重新操作后的跳轉的實現。
    jBPM作為目前應用最廣泛的開源工作流產品，其最新的第4版有著很好的架構及擴展性。但是由于國外的流程應用與國內的應用有所不同，因此要想讓jBPM4更好地滿足國內的流程應用的需求，還需要做一定的定制開發。本文針對國內的流程應用的典型特點進行了較詳細的分析，特別針對臨時動態性需求的各種情況，給出了基于jBPM4的解決思路(限于篇幅文中并沒有給出很詳細的可以運行的代碼)。本文所做的工作只是工作流應用技術研究的一小部分，還有很多方面需要繼續學習和實踐，需要進行深入的研究。
參考文獻
[1] 范玉順.工作流管理技術基礎[M].北京:清華大學出版社，2001.
[2] WfMC-TC00-1003v1. 1. The workflow reference model[S]. 1995.
[3] JBoss官方.jBPM Documentation[EB/OL].http://www.jboss.org/jbossjbpm.2009-09.
[4] 胡長城.工作流講解[EB/OL].www.javafox.org.2009-09.