本發(fā)明涉及計算機和計算機軟件技術領域，特別地涉及一種動態(tài)產生和執(zhí)行工作流流程的方法和裝置。

背景技術：

工作流，是指業(yè)務過程的部分或整體在計算機應用環(huán)境下的自動化。在業(yè)務的自動化過程中，文檔、信息或任務按照一定的過程規(guī)則流轉，實現(xiàn)組織成員間的協(xié)同工作，以達到業(yè)務的整體目標。典型的工作流管理系統(tǒng)wfms(workflowmanagementsystem)至少由如下幾個模塊組成：業(yè)務流程建模定義工具、過程定義模塊、工作流執(zhí)行環(huán)境(引擎)、任務管理模塊等。其基本原理是：按照業(yè)務預先定義好業(yè)務規(guī)則和流程，再通過工作流流程引擎進行業(yè)務的流轉，并且可以清晰看到每個流程步驟。

工作流在企業(yè)應用中非常廣泛，例如：辦公自動化(officeautomation，簡稱oa)系統(tǒng)中的加班申請、請假申請、調休申請等等；財務系統(tǒng)中的出差申請、費用報銷申請等等。在目前的企業(yè)應用中，通常是將每種業(yè)務的流程預先定義，然后根據(jù)企業(yè)的業(yè)務流程，采用開源的工作流引擎activiti，繪制公司的流程，生成流程定義文件，上傳流程定義文件，并通過activiti引擎相關的應用程序編程接口api(applicationprogramminginterface)驅動流程的流轉，例如：部署服務、運行時服務、任務服務、歷史服務等等。

隨著企業(yè)公司規(guī)模的不斷壯大，企業(yè)的組織架構的升級，除了部門與部門之間有流程的協(xié)同，在上級公司和下級公司也有流程的協(xié)同，例如：費用報銷一般會通過自己部門領導的審核，再到財務部門審核， 并且，每個部門之間，都有自己的流程；如果新成立一個公司，在采購費用上，只要超出一定金額就需要到總部流程上進行審核，等等。這樣在新增部門和成立子公司時，必然要重新定義流程規(guī)則，這樣就會帶來流程規(guī)則的變更。

在現(xiàn)有常見的工作流運轉過程中：業(yè)務流程需要預先定義好，并且整個過程都需要靠activiti引擎驅動業(yè)務的流轉。對于公司的流程變更，需要研發(fā)人員或者運營人員重新繪制流程定義文件，難度相對比較高。在整個流程驅動環(huán)節(jié)，靠activiti流程引擎的api很難滿足某些中國特色的流程需求，比如：父流程掛接子流程、子流程掛接父流程，動態(tài)加簽、補簽等等。

由此可以看出，現(xiàn)有的工作流實現(xiàn)方式具有以下的缺陷：

1、流程變更對于使用人員要求高；

2、流程定義文件不夠靈活，每次業(yè)務流程變更都需要研發(fā)或者運營人員完成；

3、利用現(xiàn)有的工作流引擎很難滿足個性化流程需求。

如果企業(yè)的組織結構復雜，那么流程定義也會很復雜。試想，如果我們將流程定義直接交給用戶，用戶直接控制流程，將一個復雜的流程拆分，按照部門或者按照分公司去拆分，部門和分公司去控制自己的流程，最后通過流程引擎去將部門、分公司、總公司的流程串連起來，這樣，就會降低業(yè)務流程設計的復雜度，更能適應企業(yè)的發(fā)展需求。

技術實現(xiàn)要素：

有鑒于此，本發(fā)明提供一種動態(tài)產生和執(zhí)行工作流流程的方法和裝置，能夠解決企業(yè)業(yè)務流程頻繁變更以及企業(yè)不斷壯大導致的流程規(guī)劃越來越復雜的問題。通過將業(yè)務流程按照組織結構拆解，部門或分公司和公司可隨意修改自己的流程，從而大大降低了流程復雜度， 內部流程和上級流程耦合性更低。

為實現(xiàn)上述目的，根據(jù)本發(fā)明的一個方面，提供了一種動態(tài)產生和執(zhí)行工作流流程的方法。

一種動態(tài)產生和執(zhí)行工作流流程的方法，包括：定義多個工作流子流程，所述子流程具有指定的執(zhí)行順序；由流程發(fā)起者指定初始子流程；通過流程引擎啟動所述初始子流程，使得按照所述順序執(zhí)行所述子流程，其中，每個所述子流程在執(zhí)行中，能夠觸發(fā)指定的另外子流程的執(zhí)行。

可選地，每個所述子流程開始執(zhí)行時，通過相應的觸發(fā)器監(jiān)視該子流程的規(guī)則的條件是否滿足，當滿足時，觸發(fā)該規(guī)則中規(guī)定的另外子流程的執(zhí)行。

可選地，每個所述子流程在執(zhí)行中，該子流程的執(zhí)行者能夠自主觸發(fā)另外子流程的執(zhí)行。

可選地，所述另外子流程是加簽子流程，即該另外子流程在觸發(fā)該另外子流程的子流程之前執(zhí)行。

可選地，所述另外子流程是補簽子流程，即該另外子流程在觸發(fā)該另外子流程的子流程之后執(zhí)行。

可選地，所述另外子流程是協(xié)辦子流程，即該另外子流程與觸發(fā)該另外子流程的子流程并行執(zhí)行，并且這兩個子流程都完成后，才開始原定的所述順序的下一個子流程的執(zhí)行。

可選地，所述協(xié)辦子流程能夠是并行執(zhí)行的多個子流程。

可選地，通過所述流程引擎記錄所述流程的實際執(zhí)行軌跡。

根據(jù)本發(fā)明的另一方面，提供了一種動態(tài)產生和執(zhí)行工作流流程的裝置。

一種動態(tài)產生和執(zhí)行工作流流程的裝置，包括：流程定義模塊，用于定義多個工作流子流程，所述子流程具有指定的執(zhí)行順序；流程發(fā)起模塊，用于由流程發(fā)起者指定初始子流程；流程執(zhí)行模塊，用于通過流程引擎啟動所述初始子流程，使得按照所述順序執(zhí)行所述子流程，其中，每個所述子流程在執(zhí)行中，能夠觸發(fā)指定的另外子流程的執(zhí)行。

根據(jù)本發(fā)明的又一方面，提供了一種動態(tài)產生和執(zhí)行工作流流程的裝置。

一種動態(tài)產生和執(zhí)行工作流流程的裝置，包括：存儲器和處理器，其中，所述存儲器存儲指令；所述處理器執(zhí)行所述指令用于：定義多個工作流子流程，所述子流程具有指定的執(zhí)行順序；由流程發(fā)起者指定初始子流程；通過流程引擎啟動所述初始子流程，使得按照所述順序執(zhí)行所述子流程，其中，每個所述子流程在執(zhí)行中，能夠觸發(fā)指定的另外子流程的執(zhí)行。

可選地，所述處理器還用于：每個所述子流程開始執(zhí)行時，通過相應的觸發(fā)器監(jiān)視該子流程的規(guī)則的條件是否滿足，當滿足時，觸發(fā)該規(guī)則中規(guī)定的另外子流程的執(zhí)行。

可選地，所述處理器還用于：每個所述子流程在執(zhí)行中，該子流程的執(zhí)行者能夠自主觸發(fā)另外子流程的執(zhí)行。

根據(jù)本發(fā)明的技術方案，通過流程引擎控制流程的執(zhí)行，流程引 擎根據(jù)當前任務節(jié)點配置的規(guī)則和當前任務的執(zhí)行者是否自主觸發(fā)另外任務，來決定是否啟動一個新的子流程，并且可以將多個子流程進行靈活串接，從而能夠支持流程定義多樣化，以便更好的適應企業(yè)的個性化流程定制需求；并且，通過將復雜的跨部門、跨層級的流程分解后進行定義，從而降低了流程設計的復雜度和實施運維難度。

附圖說明

附圖用于更好地理解本發(fā)明，不構成對本發(fā)明的不當限定。其中：

圖1是本發(fā)明實施例的動態(tài)產生和執(zhí)行工作流流程的系統(tǒng)的總體框架示意圖；

圖2是根據(jù)本發(fā)明實施方式的動態(tài)產生和執(zhí)行工作流流程的方法的主要步驟示意圖；

圖3是本發(fā)明實施例的工作流流程在不同業(yè)務場景的執(zhí)行過程示意圖；

圖4是根據(jù)本發(fā)明實施方式的一種動態(tài)產生和執(zhí)行工作流流程的裝置的主要模塊示意圖；

圖5是根據(jù)本發(fā)明實施方式的另一種動態(tài)產生和執(zhí)行工作流流程的裝置的主要模塊示意圖。

具體實施方式

以下結合附圖對本發(fā)明的示范性實施例做出說明，其中包括本發(fā)明實施例的各種細節(jié)以助于理解，應當將它們認為僅僅是示范性的。因此，本領域普通技術人員應當認識到，可以對這里描述的實施例做出各種改變和修改，而不會背離本發(fā)明的范圍和精神。同樣，為了清楚和簡明，以下的描述中省略了對公知功能和結構的描述。

根據(jù)本發(fā)明，將企業(yè)流程進行最小粒度的拆分(例如按照部門或分公司進行拆分)，以降低企業(yè)流程的復雜度。流程定義可通過流程模板設計器(例如：通過flash等易編輯的圖形用戶界面等)來進行，流程發(fā)起者可根據(jù)部門或公司的業(yè)務規(guī)則，自定義流程定義文件。

根據(jù)本發(fā)明，在每個子流程節(jié)點上可配置相應的流程規(guī)則，例如，當規(guī)則的條件滿足時，可觸發(fā)另外的子流程，并且，每個子流程的執(zhí)行者可以自主觸發(fā)另外的子流程，從而達到業(yè)務的流轉。在流程引擎啟動流程實例之后，記錄整個流程實例的步驟詳細信息。

下面舉例幾種典型的業(yè)務場景，其中包括規(guī)則觸發(fā)和自主觸發(fā)的情況：

場景1：在項目費用報銷申請中，設置規(guī)則，規(guī)定金額超過一定數(shù)額(例如：2萬元)時，需要通過上級公司的流程進行審核。因此，審核過程中，當滿足該規(guī)則規(guī)定的金額超過2萬元的條件時，會自動啟動上級公司的審核流程。上級公司的審核流程通過之后，則返回到當前流程中的任務節(jié)點。并且，在整個過程中，流程引擎會記錄整個流程執(zhí)行的結果及先后順序等。

場景2：一個流程實例已經(jīng)啟動，但是當前審核人，想要讓其他部門或其他人一起協(xié)助審核，即協(xié)辦。在通常的情況下，現(xiàn)有常見的工作流程引擎是做不到的。本發(fā)明的工作流程中，當前審核人可以選擇需要協(xié)辦的任務以及協(xié)辦任務執(zhí)行者，并啟動協(xié)辦任務。其中，協(xié)辦執(zhí)行者可以是人、崗位、部門等。在協(xié)辦任務執(zhí)行者和當前審核人都通過后，流程流轉至原定的下個任務節(jié)點。在這里，如果協(xié)辦任務者是部門，則需啟動一個部門的子流程，并待該子流程結束后，協(xié)辦任務才算結束。

場景3：一個流程實例已經(jīng)啟動，當前審核人審核時，想要有一個很重要的人在他審核之前做審核，即加簽。加簽任務結束之后，則回到當前節(jié)點。

場景4：增加任務環(huán)節(jié)。即在這個環(huán)節(jié)，審核人可以動態(tài)增加一個任務待辦，任務待辦者可以是一個普通節(jié)點(即：一個審核人)， 也可以是一個部門等的子流程節(jié)點。比如：財務報銷中，企業(yè)資源計劃erp事業(yè)部，審核人在審核時，希望財務部門的人看看發(fā)票格式是否合格，這時在這個節(jié)點上可以增加一個財務部門的流程，那么財務部門的流程走完之后，才能完成業(yè)務的流轉。

根據(jù)上述內容，本發(fā)明提出了一種動態(tài)產生和執(zhí)行工作流流程的方法和系統(tǒng)。本發(fā)明是將復雜流程按照組織結構，即公司、分公司、部門等的維度進行拆分，根據(jù)實際應用，定義部門與部門之間、公司與部門之間、公司與公司之間的工作流流程，在執(zhí)行流程的各任務時，每個任務可按照預定規(guī)則來觸發(fā)另外任務或由任務執(zhí)行者自主觸發(fā)另外任務，以實現(xiàn)任務的動態(tài)串接。例如：假設一個工作流流程需要包含a公司總部、a公司下屬的分公司a1、分公司a1的銷售部和財務部共計3個層次維度。以分公司a1的銷售部進行報銷申請的流程為例，其中，若報銷申請的金額超過2萬元需要匯報到a公司總部。根據(jù)本發(fā)明，可定義包括三個任務的流程：銷售部提交報銷申請------財務部審核流程------分公司a1審核流程。并且當滿足“金額超過2萬元”的條件是，觸發(fā)a公司總部審核任務。并且，在整個工作流流程的運行過程中，需要動態(tài)地將這四個任務節(jié)點串接起來。

下面將詳細地描述本發(fā)明的技術實現(xiàn)。如圖1所示，是本發(fā)明實施例的動態(tài)產生和執(zhí)行工作流流程的系統(tǒng)的總體框架示意圖。本發(fā)明的動態(tài)產生和執(zhí)行工作流流程的系統(tǒng)主要包括：基礎信息管理模塊、流程定義管理模塊和流程驅動執(zhí)行模塊。

基礎信息管理模塊主要用于按照企業(yè)或者公司的組織結構將不同業(yè)務的流程進行拆分。不同業(yè)務的流程在進行分類時，是根據(jù)業(yè)務內容的不同進行細粒度區(qū)分，比如：差旅報銷、加班費用申請等。相應地，一個部門的業(yè)務流程即可分類為例如：銷售部的差旅報銷流程、銷售部的加班費申請流程、銷售部的項目經(jīng)費申請等等。

流程定義管理模塊主要用于通過流程模板設計器(可視化圖形界面)，將部門或分公司流程按照業(yè)務流程建模與標注bpmn(businessprocessmodelingnotation)2.0規(guī)范，生成xml字符串，并且還可以用版本來進行控制。流程模板設計器是客戶自定義流程的客戶端，可根據(jù)各個部門的業(yè)務定義流程。在進行流程定義時，可以編寫該流程的流程觸發(fā)規(guī)則和選擇流程節(jié)點上的審核人員(根據(jù)需要，可以是一個或者多個人員)。其中，流程觸發(fā)規(guī)則是在任務節(jié)點上配置的業(yè)務流轉的一種規(guī)則，在工作流流程實例運行期間，會根據(jù)該規(guī)則的條件是否滿足而決定是否要啟動一個新的流程實例。例如：假設項目費用申請金額大于20萬元時，需要總公司的相關人員進行審核，那么此時會根據(jù)該流程觸發(fā)規(guī)則自動生成下一個審核任務，即：一個公司的子流程。

流程驅動執(zhí)行模塊，是系統(tǒng)的核心，主要用于驅動整個業(yè)務流程的運轉。該模塊會提供審核流的流轉，通過讀取流程上任務節(jié)點的配置的節(jié)點信息和流程規(guī)則，動態(tài)創(chuàng)建待辦任務，并根據(jù)流程規(guī)則是否是部門流程或者公司流程，比如下達、上報等，也會包含任務追回、加簽、補簽、分發(fā)、協(xié)辦等功能。其中，上報的規(guī)則例如：銷售部提交一個項目經(jīng)費申請，公司規(guī)定，當申請金額超過2萬元時需要經(jīng)過總公司審核才能通過，那么在當前流程執(zhí)行結束之后，根據(jù)規(guī)則，會自動啟動總公司的審核流程；下達的規(guī)則例如是總部發(fā)起的流程，根據(jù)規(guī)則判斷是否要發(fā)起一個部門或者分公司的流程等。

在流程驅動執(zhí)行的過程中，本發(fā)明的流程引擎會記錄整個業(yè)務流轉過程及結果。并且，本發(fā)明還可以提供查看流程實例歷史、實例歸檔、歸檔歷史信息等功能。

圖2是根據(jù)本發(fā)明實施方式的動態(tài)產生和執(zhí)行工作流流程的方法的主要步驟示意圖。如圖2所示，本發(fā)明的動態(tài)產生和執(zhí)行工作流流程的方法主要包括如下的步驟s21至步驟s23。

步驟s21：定義多個工作流子流程，所述子流程具有指定的執(zhí)行順序；

步驟s22：由流程發(fā)起者指定初始流子程；

步驟s23：通過流程引擎啟動初始子流程，使得按照順序執(zhí)行子流程，其中，每個子流程在執(zhí)行中，能夠觸發(fā)指定的另外子流程的執(zhí)行。

根據(jù)本發(fā)明的技術方案，每個子流程開始執(zhí)行時，通過相應的觸發(fā)器監(jiān)視該子流程的規(guī)則的條件是否滿足，當滿足時，觸發(fā)該規(guī)則中規(guī)定的另外子流程的執(zhí)行。

每個子流程在執(zhí)行中，該子流程的執(zhí)行者能夠自主觸發(fā)另外子流程的執(zhí)行。其中，另外子流程例如是加簽子流程，即該另外子流程在觸發(fā)該另外子流程的子流程之前執(zhí)行?；蛘?，另外子流程是補簽子流程，即該另外子流程在觸發(fā)該另外子流程的子流程之后執(zhí)行。又或者，另外子流程是協(xié)辦子流程，即該另外子流程與觸發(fā)該另外子流程的子流程并行執(zhí)行，并且這兩個子流程都完成后，才開始原定順序的下一個子流程的執(zhí)行。并且，協(xié)辦子流程能夠是并行執(zhí)行的多個子流程。

另外，本發(fā)明還可以通過流程引擎記錄流程的實際執(zhí)行軌跡。

圖3是本發(fā)明實施例的工作流流程在不同業(yè)務場景的執(zhí)行過程示意圖。本發(fā)明的工作流流程執(zhí)行是通過activiti的api啟動流程實例，但在執(zhí)行過程中，是通過流程引擎來驅動流程，并且，整個流程執(zhí)行過程，流程引擎會記錄這個流程實例的流程軌跡，可以達到如下所列業(yè)務場景時更為靈活的處理方式。

如圖3所示，申請人啟動初始流程后，在流程執(zhí)行過程中，如果當前審核人的審核結果為“同意”，則業(yè)務正常流轉，在流程引擎的 驅動過程中，流程引擎會查詢該流程配置的流程規(guī)則中是否存在上報下達的規(guī)則，如果存在，則啟動部門或者公司的子流程，并在子流程執(zhí)行完后，到達下一個審核人。

當當前審核人的審核結果為“拒絕”時，由于流程待辦任務是通過本發(fā)明的流程引擎來進行驅動的，每一個流程實例的步驟，流程引擎都會記錄，因此，如果當前審核人的審核結果為“拒絕”，那么該流程可以退回到已經(jīng)執(zhí)行的流程步驟的任何一個環(huán)節(jié)。本發(fā)明中主要可以分為打回、終止、駁回三種情況。其中，“打回”指的是退回到上一個任務節(jié)點，即如果上個任務節(jié)點是普通節(jié)點，則直接將上個任務節(jié)點的狀態(tài)激活，如果上個任務節(jié)點是觸發(fā)一個子流程，則退回到該子流程的開始節(jié)點；“終止”指的是流程直接結束，流程實例結束，且不可以重新申請；“駁回”指的是流程直接結束，但是流程實例未結束，故可以重新申請。在使用過程中，用戶可以根據(jù)自己的需要設置不同的拒絕狀態(tài)。

另外，當前審核人，還可以將任務“分發(fā)”給其指定的人，在當前審核人指定人時可以自定義流轉后任務節(jié)點的操作人員，被分發(fā)任務的操作人員在拿到待辦任務之后進行審核，若審核通過，則正常流轉到下個審核人?！胺职l(fā)”功能在實現(xiàn)時是通過在當前審核人任務之后動態(tài)添加任務待辦，并指定添加的待辦任務的審核人即可。

比較常用的業(yè)務場景還包括對審核信息的“撤銷”，即：在當前審核人審核之后，發(fā)現(xiàn)審核信息有些問題，需要撤回剛才的審核信息，那么在下個審核人沒有審核之前，該審核人，可以撤回審核的信息。一般是在下一個審核人還沒有審核之前，將下一個待辦任務失效，并將上一個待辦任務激活，如果上一個待辦任務是一個子流程，則將子流程的最后一個審核任務激活。

根據(jù)本發(fā)明的工作流流程可以實現(xiàn)一些現(xiàn)有的工作流技術無法實 現(xiàn)的功能，例如以下介紹的協(xié)辦、加簽、補簽等業(yè)務場景。

協(xié)辦：協(xié)辦者的角色可以是人員、部門、崗位等，即當前審核人審核的時候可以向另外的人員、部門、崗位等發(fā)起發(fā)送任務，請求其公共審核該待辦?！皡f(xié)辦”功能在實現(xiàn)時，：在選取協(xié)辦者的時候，如果協(xié)辦者是人員，則在當前任務動態(tài)插入一個人員的待辦任務；如果協(xié)辦者是部門，則是啟動該部門的流程實例；如果協(xié)辦者是人員或崗位，則是插入多條任務待辦，當添加的協(xié)辦任務(包含子流程結束)都執(zhí)行完畢之后，再正常流轉到下一個審核人。

加簽：當前審核人在審核該任務的時候，希望有一個人員希望能在他之前審核一下，這時候可以加簽。加簽之后，該加簽的人員先進行審核，之后任務待辦再次到達當前審核人。這是在企業(yè)中常見的業(yè)務場景，例如，流程已到當前審核人，但是有領導想看看該申請，則當前審核人就可以將該申請送給該領導。常見流程引擎，是不能處理這個需求的，因為流程已經(jīng)到達當前審核人，當前的任務待辦之前是不能再有新的待辦任務產生的。而本發(fā)明對“加簽”情況的處理方式，是在當前的任務待辦之前，動態(tài)插入加簽任務，并將當前審核人的待辦任務狀態(tài)失效。

補簽：指的是增加新的任務流程。對于需要補簽的情況，當前審核人可以動態(tài)增加一個任務待辦，任務待辦可以是一個審核人，也可以是一個部門或者公司的子流程。比如：財務報銷中，企業(yè)資源計劃erp事業(yè)部，審核人在審核時，希望財務部門的人看看發(fā)票類型是否合格，此時在這個任務節(jié)點上可以增加一個財務部門的子流程，且在財務部門的子流程走完之后，才能完成業(yè)務的流轉?！把a簽”功能與加簽、協(xié)辦的處理方式基本上一樣，也是動態(tài)添加任務節(jié)點，且任務節(jié)點可以是普通節(jié)點也可以是子流程節(jié)點。

然而，協(xié)辦、加簽和補簽這三種不同業(yè)務場景在使用過程中還有 一些不同之處，主要表現(xiàn)在：

“協(xié)辦”：是在當前任務添加，即當前任務和協(xié)辦任務同時審核完成之后，才能到達下一個審核人；

“加簽”：是在當前任務之前添加，并將當前任務狀態(tài)失效，加簽步驟執(zhí)行完之后，重新回到當前節(jié)點；

“補簽”：是在當前任務執(zhí)行完畢之后，添加新的任務節(jié)點。

另外，本發(fā)明還提供了一種動態(tài)產生和執(zhí)行工作流流程的裝置。如圖4所示，是根據(jù)本發(fā)明實施方式的一種動態(tài)產生和執(zhí)行工作流流程的裝置的主要模塊示意圖。本發(fā)明的一種動態(tài)產生和執(zhí)行工作流流程的裝置40主要包括流程定義模塊41、流程發(fā)起模塊42和流程執(zhí)行模塊43。

流程定義模塊41用于定義多個工作流子流程，所述子流程具有指定的執(zhí)行順序；流程發(fā)起模塊42用于由流程發(fā)起者指定初始子流程；流程執(zhí)行模塊43用于通過流程引擎啟動所述初始子流程，使得按照所述順序執(zhí)行所述子流程，其中，每個所述子流程在執(zhí)行中，能夠觸發(fā)指定的另外子流程的執(zhí)行。

如圖5所示，是根據(jù)本發(fā)明實施方式的另一種動態(tài)產生和執(zhí)行工作流流程的裝置的主要模塊示意圖。本發(fā)明的另一種動態(tài)產生和執(zhí)行工作流流程的裝置50主要包括存儲器51和處理器52。

其中，存儲器51存儲指令；處理器52執(zhí)行所述指令用于：定義多個工作流子流程，所述子流程具有指定的執(zhí)行順序；由流程發(fā)起者指定初始子流程；通過流程引擎啟動所述初始子流程，使得按照所述順序執(zhí)行所述子流程，其中，每個所述子流程在執(zhí)行中，能夠觸發(fā)指定的另外子流程的執(zhí)行。

另外，處理器52還可以用于：每個所述子流程開始執(zhí)行時，通過 相應的觸發(fā)器監(jiān)視該子流程的規(guī)則的條件是否滿足，當滿足時，觸發(fā)該規(guī)則中規(guī)定的另外子流程的執(zhí)行。

處理器52還可以用于：每個所述子流程在執(zhí)行中，該子流程的執(zhí)行者能夠自主觸發(fā)另外子流程的執(zhí)行。

根據(jù)本發(fā)明實施例的技術方案，通過流程引擎控制流程的執(zhí)行，流程引擎根據(jù)當前任務節(jié)點配置的規(guī)則和當前任務的執(zhí)行者是否自主觸發(fā)另外任務，來決定是否啟動一個新的子流程，并且可以將多個子流程進行靈活串接，從而能夠支持流程定義多樣化，以便更好的適應企業(yè)的個性化流程定制需求；并且，通過將復雜的跨部門、跨層級的流程分解后進行定義，從而降低了流程設計的復雜度和實施運維難度。

上述具體實施方式，并不構成對本發(fā)明保護范圍的限制。本領域技術人員應該明白的是，取決于設計要求和其他因素，可以發(fā)生各種各樣的修改、組合、子組合和替代。任何在本發(fā)明的精神和原則之內所作的修改、等同替換和改進等，均應包含在本發(fā)明保護范圍之內。