1. <acronym id="pirhh"><pre id="pirhh"><dd id="pirhh"></dd></pre></acronym>
        1. <tt id="pirhh"><pre id="pirhh"><dd id="pirhh"></dd></pre></tt>
          <rt id="pirhh"></rt> <code id="pirhh"><object id="pirhh"></object></code>
            <listing id="pirhh"><object id="pirhh"><tr id="pirhh"></tr></object></listing>
            <code id="pirhh"></code>

            再談流程引擎參與人(10.6)

            對于工作流引擎,多年前就已經談過很多文章,包括PaaS平臺里面的流程引擎。今天只談下對于流程引擎中的模板配置,角色和參與人,用戶組,崗位等之間的核心關系。

            角色和用戶組

            對于國內的流程引擎設置比較靈活,一般既可以配置角色,也可以配置部門和崗位,但是對于標準的工作流配置一般都是設置角色,并在角色中配置參與人。那么首先就要搞清楚角色和用戶組之間的關系。對于角色往往是一個泛指的概念,而對于用戶組則是一個關聯到具體組織或工作組后的特指概念,即角色*組織或工作組,最終才會生成相對應的用戶組。


            1.項目經理,就是一個角色的概念

            平臺產品線+SOA項目這是一個層級結構,我們有時候會用到工作組這個概念,工作組可以是一個分級的多層結構,但是往往最多一般分三層,即產品大類,產品線,項目。某個產品線下具體哪個項目的項目經理,就是一個用戶組。為何要這樣設置?即我們在進行流程模板設置的時候,參與人只會配置到具體的角色,而實際流程啟動后才會動態去計算出具體對應到哪個用戶組計算出具體的人。


            當前一個文檔申請提交流程,里面涉及到項目經理審批,QA審批,產品經理審批等。但是對于不同的文檔可能涉及到不同的流程,這個時候有兩種方法,一個是仍然沿用工作組的設置,即將工作組和流程模板進行映射,在選擇了工作組信息后來確定具體調用兩個流程模板。即我們常說的,即使是同一個類型的表單或申請單,由于類型或工作組不同,在啟動的時候也可以調用不同的流程模板。

            在表單申請的時候,申請單必須選擇工作組信息,比如上面我們選擇 平臺產品線/SOA項目

            選擇完成后提交項目,啟動流程實例后流轉到項目經理審批。我們在設置流程模板的時候,參與人設置的是項目經理,這個時候就需要基于工作組選擇來交叉計算對應的用戶組 = 平臺產品線SOA項目項目經理,當計算到具體的用戶組后,這個用戶組里面往往就只有特定的人,而不是一堆的符合項目經理角色的都能夠收到待辦和處理。

            這個是流程引擎在啟動和計算人的時候最常見的方式,可以看到,在這種方式下必須要實現定義清楚角色,同時對用戶組進行動態計算和生成,并將收集到的用戶組成員信息導入到系統中。

            從角色到組織結構

            在流程審批的時候,最常見的業務場景就是,當前部門的領導審批,當前部門的管理經理審批,當前部門的主管副總審批,上一級部門的領導審批,同級部門的領導會簽等。這個場景是什么意思?即在流程審批的時候,我們往往會涉及到部門和組織的層級機構去找人,而不是單純的通過角色和用戶組去找人。

            比如我們有一個角色叫部門經理,按傳統的做法可能是每一個部門的部門經理都需要單獨建立一個用戶組,并把參與人放進去。但是如果當前有完整的組織結構樹,這個工作則不需要,即張三這個人,基于組織結構樹一定是能夠找到對應的部門經理,對應的測試經理,對應的部門主管副總的,只要組織結構和崗位設置正確,這個信息就能夠完全查找和精確定位到。

            這就回到了我們前面的問題,在流程模板設置的時候,我們可以設置崗位做為流程活動節點的參與人,比如崗位就是部門經理。然后在參與人計算規則那個地方來設置,具體是找同級部門經理,還是找上級部門經理。對于找同級容易理解,對于找上級本身又有規則,比如我們前面說的有上級部門經理的概念,也有主管副總的概念。

            那么如果一個企業有二級,三級多級部門的情況下,如何去找上級主管副總。你從三級查找到二級的時候可能找不到主管副總,但是從二級查找到一級的時候就能夠查到主管副總的。因此找上級的過程往往是一個逐層朝上面查找的過程,直到找到為止。

            在這種時候你就有兩種做法,在流程參與人那設置部門經理,但是里面不放人,根據組織結構和崗位樹去找部門經理。還有一種做法就是將所有的部門經理都配置進來,但是根據當前部門部門經理,上一部門部門經理等規則去精確計算出對應的人。這兩種方法本身都沒有問題。但是第2種折中方法更好些,不用完全依賴于組織機構和崗位設置。即只會用到組織結構和層級關系,而不會用到崗位人員信息。

            動態規則計算參與人

            如果上面的方式都無法處理自動計算出對應的參與人,那么就需要自己寫規則和程序來動態計算參與人,即流程引擎簡化為僅僅是一個狀態流轉機,但是狀態流轉后具體對應的處理人流程引擎不計算,而是需要調用你寫好的計算規則或接口去動態計算。

            在流程模板設置中經常會遇到這種復雜情況,比如需要由某個單據分類對應的項目經理進行審批,需要有申請人對應的系統主管項目經理審批等,這些我們都可以自己寫規則去計算對應的參與人。而要實現這種計算,重要的就是需要在業務系統里面自己去維護大量的這種對應關系和映射表,這些對應表往往是在組織機構,崗位角色中無法拿到的映射信息。

            動態計算參與人,雖然靈活,但是由于進行了硬編碼,會導致后續本身參與人的維護更加麻煩,也會導致由于審批規則出現變化的時候都不能簡單的通過配置修改,而需要修改代碼,那么這種代碼仍然是很大的。


            基于上面說的,可以看到當前國內的各種工作流引擎往往就具備了滿足上面各種場景的將需求。即流程活動節點,既可以選擇角色,也可以選擇崗位,還可以選擇具體的人。同時參與人節點配置還可以配置同級關系,還是上級關系等,這些都極大的方便了流程模板的配置。

            注意在當前系統實現過程中,往往將系統功能角色和流程角色這兩個概念分開,即專門配置流程角色供流程引擎使用。在流程角色中直接配置人,也可以是在流程角色中不配置人,而是在用戶組中配置具體的人。這兩種方式都可以。但是對于第一種方式,一定存在一種動態精確計算規則,否則就會導致待辦信息分發到多個人的情況。

            我來評幾句
            登錄后評論

            已發表評論數()

            相關站點

            熱門文章
            天辰线上娱乐

            1. <acronym id="pirhh"><pre id="pirhh"><dd id="pirhh"></dd></pre></acronym>
                  1. <tt id="pirhh"><pre id="pirhh"><dd id="pirhh"></dd></pre></tt>
                    <rt id="pirhh"></rt> <code id="pirhh"><object id="pirhh"></object></code>
                      <listing id="pirhh"><object id="pirhh"><tr id="pirhh"></tr></object></listing>
                      <code id="pirhh"></code>

                      1. <acronym id="pirhh"><pre id="pirhh"><dd id="pirhh"></dd></pre></acronym>
                            1. <tt id="pirhh"><pre id="pirhh"><dd id="pirhh"></dd></pre></tt>
                              <rt id="pirhh"></rt> <code id="pirhh"><object id="pirhh"></object></code>
                                <listing id="pirhh"><object id="pirhh"><tr id="pirhh"></tr></object></listing>
                                <code id="pirhh"></code>