江日念,林 霞,許 錕
(中國石油勘探開發研究院 計算機應用技術研究所,北京 100083)
審批流程是工作流的一部分,是一類能夠完全或者部分自動執行的業務過程,它根據一系列過程規則,使得文檔、信息或任務能夠在不同的執行者之間傳遞與執行[1-3]。它通常由審批流程定義和審批流程實例兩大部分組成,在建模階段,將業務過程定義在審批流程定義里,在啟動階段,將相應的流程定義拷貝到流程實例,在運行階段,審批人在相應審批節點選擇同意或者拒絕本次審批后,將選擇一條流轉路徑,以便將審批業務對象流轉到下一節點。一般的審批流程流轉方式為按序流轉到各審批節點,直到流程終結。而在實際操作過程中,審批流程的“異常”情況非常多,其原因是流程規則具有不確定性[4]。所以,此種方式未考慮到現實情況中審批業務對象的部分參數對審批路徑選擇的影響,同時未能考慮到有子流程和分支流程的情況。
為了讓審批流程能滿足各種業務需求,具備一定的柔性,一般企業會采用開源工作流或者根據自身情況量身定制一套流程引擎。常用的開源工作流是基于BPMN2.0[5-8]協議jBPM[9]和Activiti[10],這兩者功能強大,但入門門檻較高,而且不能滿足一些使用場景,比如流程撤回、跳過某個流程節點執行等。而自主研發的工作流更適應國內審批業務現狀,出于實際業務考慮,在一種自主研發的柔性審批流程模型[11]基礎上提出了一種路徑選擇策略,將節點和路徑由常規的鏈式存儲變為基于有向圖結構的存儲[12-14],通過條件路徑、缺省路徑、默認回退路徑的定義為路徑選擇策略的實施奠定基礎,流程實例基于路徑選擇策略選擇一條合適的流轉路徑后,形成審批流程的流轉記錄,直至審批結束。在流程路徑的研究方面,當前的一些研究[15-16]以基于流程關鍵路徑的工作流調度為目標,也取得了較好的效果。
審批流程的定義是審批流程的核心部分,定義部分規定了流程運行所需要的相關信息,包括流程所屬業務、流程參數、流程可用部門、流程節點、流程路徑等信息。在流程啟動階段,根據可用部門和所屬業務找到一個可用的流程定義,將流程定義中的節點信息、流程參數信息、路徑信息、節點下崗位信息拷貝到流程實例。這樣生成的流程實例和流程定義將解耦,單個審批業務對象的流程變更,不會影響其他流程實例。為了審批流程更具柔性,在審批過程定義階段盡可能地預見各種柔性需求,為具體執行提供可選情況。當一些在創建時不能完全預見的情況出現時,需要及時地調整原有過程定義和運行中的實例,滿足業務對象的審批需求。流程定義ER圖如圖1所示。

圖1 審批流程定義ER圖
由以上ER圖可知,該審批流程定義的核心是基于有向圖存儲的。有向圖工作流模型是一種應用廣泛的流程定義模型,它是一種基于活動的IPO(輸入—處理—輸出)的模型。基于有向圖存儲流程定義為靈活的路徑定義提供了基礎,也符合目前主流工作流模型設計理念。
以下給出該審批模型幾個概念定義:
定義1:審批模型。審批模型可用一個二元組表示wf=(N,P)。其中N={nb,n2,…,nn-1,ne}是流程節點的集合,P為節點之間的路徑集合,P的形式化表示為P={pi|pi=
活動節點集合N包含三類:起始節點、活動節點、結束節點。在一個合法的流程定義中,必須包含唯一的一個起始節點nb、唯一的一個結束節點ne和至少一個活動節點,且只有活動節點才關聯到相應崗位。路徑集合P中
定義2:條件路徑。在路徑定義里流轉條件不為空的路徑。條件路徑也是路徑選擇策略中的優先路徑,它是為了將審批業務對象中的參數傳給流轉條件,以匹配滿足條件的路徑。無論審批結果是“同意”還是“拒絕”都適用條件路徑。
比如,在項目立項審批業務中,假設金額大于300萬元和部門編碼為“test”的項目將選擇一條條件路徑,這條路徑的匹配條件condition則為:@JE>300 and @ORGCODE='test',其中@JE和@ORGCODE為流程參數表定義的兩個參數:@JE的參數類型為數值型,@ORGCODE的類型為文本型。前臺界面將項目立項表單中所需參數組裝成類型為Map
①將Map中的鍵和流程參數定義表中的參數進行匹配,若找不到與鍵匹配的流程參數定義則丟棄該鍵值,否則轉到②。
②根據流程參數表中定義的參數類型,將路徑中定義的條件condition中的參數進行替換,如果參數為數值型,則直接用Map中值替換;如果參數為文本型,則Map中值加上單引號替換。假設傳遞的Map為(<@JE,200>,<@PARA,'para'>,<@ORGCODE, test>),則匹配后替換的condition為:200>300 and 'test'='test',轉到③。
③將替換后的條件作為SQL語句的一個條件,以Oracle為例,則判定'select 1 from dual where "+condtion+"'是否有返回值,如果無返回值或者SQL異常,則判定匹配該路徑失敗,否則匹配成功。
條件路徑的匹配流程如圖2所示。

圖2 條件路徑匹配流程
定義3:缺省路徑。缺省路徑是指在路徑定義里指定的缺省路徑,即路徑定義中屬性“是否為缺省路徑”取值為“true”的路徑。
缺省路徑的優先級次于條件路徑,在未設置條件路徑或條件路徑匹配失敗時,缺省路徑有效。缺省路徑的存在可以避免因條件路徑不存在或者條件路徑匹配失敗導致流程無法正常流轉。缺省路徑也可以是條件路徑,即該路徑定義中屬性“流轉條件”不為空。
定義4:默認回退路徑。審批人選擇“拒絕”時,由當前節點默認回退到第一個活動節點的路徑。
默認回退路徑未在路徑定義中明確定義,是該審批模型處理回退的默認路徑。在系統中處理流程回退時,一旦無法找到條件路徑和缺省路徑則執行默認回退路徑。該路徑的優先級次于條件路徑和缺省路徑。
以上三種路徑的優先級:條件路徑>缺省路徑>默認回退路徑。
上述審批流程模型中定義了條件路徑、缺省路徑和默認回退路徑三類路徑,在流程執行階段,審批人在選擇兩類審批結果“同意”或者“拒絕”后,都將選擇一條執行路徑,將審批業務對象傳遞到下一審批節點。根據節點下審批人選擇的審批結果,執行兩類路徑選擇策略,即“同意”時流程通過的路徑選擇策略和“拒絕”時流程回退的路徑選擇策略。
①將傳遞的Map參數與當前節點為起始點且路徑類別為“同意”的路徑進行條件匹配,匹配策略如定義2中條件路徑的匹配策略,如果匹配成功,轉到④,否則轉到②;
②尋找一條當前節點為起始點的缺省路徑,如果尋找到該路徑轉入④,否則轉到③;
③拋出“未找到一條合法審批流轉路徑”的異常;
④該路徑作為當前審批流程的執行路徑,并且路徑的終止點為審批流程的下一執行節點。
應該注意到,在第一個活動節點,即填報人節點,以填報人節點為起始點的路徑類別均為“同意”,作為第一個活動節點,因不會有流程回退情況出現,所以它只會執行“同意”時路徑選擇策略。在最后一個活動節點,當審批人“同意”流程通過時,有且只有一條這樣缺省路徑:以最后一個活動節點為起始點,流程的結束節點ne的路徑。
①將傳遞的Map參數與當前節點為起始點且路徑類別為“拒絕”的路徑進行條件匹配,匹配策略如定義2中條件路徑的匹配策略,如果匹配成功,轉到④,否則轉到②;
②尋找一條當前節點為起始點的缺省路徑,如果尋找到該路徑轉入④,否則轉到③;
③將默認回退路徑作為執行路徑,即填報人節點為審批流程的下一執行環節;
④該路徑作為當前審批流程的執行路徑,并且路徑的終止點為審批流程的下一執行節點。
流程回退時的審批策略同流程通過的審批策略基本一致,主要區別在③,即在無法尋找到缺省路徑時,“拒絕”流程可回退到填報人,而“同意”流程通過卻因為找不到缺省路徑拋出異常。所以為了規避此異常,在流程定義時必須校驗條件路徑的條件參數必須在流程參數表中定義,且任一活動節點至少要有一條指向其他節點的缺省路徑。
下面以請假流程為例,說明路徑選擇策略的使用。某部門的請假流程審批過程為:請假人提出申請,填寫請假單,提交到部門經理審批,如果部門經理審批不通過,則流程回退到請假人,如果審批通過且請假天數在3天之內,則流程直接結束,請假成功,如果請假天數大于3天,則部門經理將申請提交給老板審批,老板審批通過,則請假成功,否則流程回退到部門經理。請假流程圖見圖3,其中所有的流轉路徑的路徑類別都在圖中標識。

圖3 請假流程
在圖3中所示的7條路徑中,有6條在路徑定義表中定義,如表1所示。部門經理到請假人之間的回退路徑未在路徑定義表中定義,說明該路徑是審批模型處理流程回退的默認路徑。流轉條件中參數@day是在流程參數表中定義的數值型參數。
假設A申請請假4天,申請將提交到部門經理審批,部門經理B審批通過后,根據路徑選擇策略,將會匹配到部門經理審批到老板審批這條條件路徑,流程將會提交給老板審批這個節點,老板C審批通過,請假成功,否則回退到部門經理B重新審批。如果A請假2天,則流程不會經過老板審批的節點。

表1 請假流程的路徑定義
為了讓審批流程能更好地滿足業務需求,適應國內各種流程需要,提出一種自主研發的審批流程模型設計,并探討了流程路徑選擇策略。流程模型基于有向圖結構,并將路徑分為三類:條件路徑、缺省路徑、默認回退路徑。通過對三類路徑的定義、優先級劃分和匹配策略的制定,為審批流程運行時的路徑選擇策略的實施奠定基礎。在路徑選擇時,根據審批結果來執行不同的策略,從而保證審批流程正確流轉。最后通過一個請假流程的實例描述,說明了該路徑選擇策略能夠應用于大部分的審批業務,因為通過簡單路徑配置,它能支持條件分支流程、子流程等復雜流程。目前,采用該路徑選擇策略的審批流程模型已經在實際的系統中得到應用。實踐結果證明,該策略具有靈活、簡便、兼容性好的特點。下一步將繼續完善該模型的路徑選擇策略設計,使之能滿足“會簽”、“會商”的復雜審批需求。