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只是一个外设。