OSWorkflow深層講解系列（二）流程執行個體的結束之二

接上一篇： OSWorkflow深層講解系列（二）流程執行個體的結束之一

       再說說OSWorkflow對Implicit Termination的支援。Osworkflow對隐性終止是很容易的，雖然現實中，我們不會去故意去創造“隐性終止”這種情況，也更不希望這種情況的發生。

       在OSWorkflow任意一次的action的執行後，如果這個action沒有造成流程執行個體的終結，那麼就會去檢測是否存在隐性終止的情況存在。

<o:p> </o:p>

public void doAction(long id, int actionId, Map inputs){<o:p></o:p>   ······<o:p></o:p>   if (!transitionWorkflow(entry, currentSteps, store, wf, action, transientVars, inputs, ps)) {<o:p></o:p>     checkImplicitFinish(id); //這個id是流程執行個體id<o:p></o:p> }}

       transitionWorkflow方法我們在第（一）篇中已經有所介紹了，再次就不再叙述。transitionWorkflow傳回的結果是這個流程執行個體是否已經結束。

       在checkImplicitFinish方法中，主要是周遊目前所有的current step節點（這些current step節點就表示目前處于運作中的活動節點）。如果這些current step都沒有被定義action，那麼整個流程執行個體就存在隐性的結束。

<o:p> </o:p>

       說道這裡就結束了嗎？當然不了，因為上面這百來字的短文太簡單了，即使我不說，大家一看代碼就會一清二楚。要說就說點讓人值得思考的：

<o:p> </o:p>

       在OSWorkflow中，幾乎所有的status都是外界定義的，就是說你可以定義自己的status，然後再workflow.xml中指明某個action的結果造成另一個step的某種status。隻有一處地方狀态是osworkflow自己所限制的，就是action中的finish狀态。

       osworkflow本身并不知道這些status本身所代表的具體含義。雖然osworkflow提供了幾個status的定義參考，比如finish,queue等等。但是這些對osworkflow引擎來說，并沒有實際的意義。

       是以在OSWorkflow的隐性終止判斷中，就存在一個值得回味的地方。

       這個時候，我們在回過頭來看看OSWorkflow的checkImplicitFinish方法：其回周遊所有的current step，并且依據每一個step的定義來判斷（注意采用的是定義，而非step執行個體）。依據每一個current step是否存在action來判斷。

       乍一看，可能很多人會認為這種判斷是存在漏洞的：如某個step還在運作怎麼辦（這個step沒有定義action）。—— 這就是值得回味的地方。

       在osworkflow中，你即使在同一個step中，想從一個status到另一種status，也必須定義action。如果這個step不存在action，那說明什麼呢？就說明這個step的狀态根本就不允許更改，既然不允許更改，那麼這個step的執行個體也就沒有任何運作的意義。—— OSWorkflow的隐性終止的判斷原則也就這麼出來了。

<o:p> </o:p>

       我一直都說OSWorkflow是遵循FSM的，那麼是在什麼地方遵循呢？就是在這些判斷規則和原則上一點一滴的遵循。對于OSWorkflow來說那些，function,conditon隻是一個外設。