【转载】工作流模式与K2实现(2)

  1. 结构化过程
  2.  

    这两个模式的共同点在于:模式所涉及流程的执行路径是由运行时决定的,而非设计时确定。包括:Arbitrary cycles(强制循环模式) 、Implicit termination(隐式终止模式)。

    ²  11  任意循环(Arbitrary Cycles 

    l  描述: 

    工作流中的一个点可以让一个或多个活动反复的执行。 

    l  案例: 

    “修改提交”后进入“经理审批”,但未通过,又回到“修改提交”。 

    l  K2实现:

     

     

     

    ²  12  隐式终止(Implicit Termination 

    l  描述: 

    在一个流程中,如果没有活动可执行了那么流程就会终止。换句话说,在工作流中没有active 状态的活动了,而且也没有活动会被激活,这就是隐式终止。(前提:工作流不能处于死锁状态)。 

    有的工作流引擎不支持。

    l  案例:

    “主管审批”通过后进入“经理审批”,未通过则无下一个活动。

    l  K2实现: 

    如果“主管审批”的输入为“不同意”,流程将终止。

    一般都会采用显示终止,因为隐式终止可能会引起不被察觉的错误,例如意外的输入可能导致流程的结束。

     

     

  3. 多实例过程
  4.  

    “多实例”是指在流程图中,一个活动在同一时刻拥有多个可运行的、处于活动状态的实例。 

    ²  13  非同步的多实例(Multiple Instances Without Synchronization 

    l  描述:

    在流程中,一个活动可以激活多个实例,也就是说可以把一个活动分发成几个控制线程。每个控制线程之间都是相互独立的,并不需要同步它们。 

    l  案例:在网上订购书籍,以书为单位,每一本都会独立产生一个购书实例,并且每个实例之间不需要同步数据。

    l  K2实现: 

    IPC Event调用方式需要选择为Asynchronous

     

     

    ²  14 在设计期间预先确定的多实例(Multiple Instances With a Priori Design Time Knowledge 

    l  描述:

    一个活动可以激活多次产生多个实例。而产生的实例的个数在流程设计时就事先知道了。一旦所有的实例都执行完成,就会激活其他活动。

    l  案例:

    有关某些特定资源的请求需要完成固定几个不同的审核流程。

    l  K2实现 

    主流程结构为模式2平行拆分 模式3同步,IPC Event中调用方式需要选择为Synchronous

     

     

     

    ²  15  在运行期预先确定的多实例(Multiple Instances With a Priori Runtime Knowledge 

    l  描述:

    一个活动可以激活多次产生多个实例。而产生的实例的个数是变化的,取决于实例的特点或者可用资源数目,但是在流程执行过程的某个时期,在这个活动的实例产生以前,要产生的实例个数是能确定的。所有的实例都运行完成后,激活后续活动。

    l  案例

    处理一个订单,订单中有多本书,要分别检查每一本都有库存,所有的书都检查完成后才开始进入送货。

    l  K2实现: 

    主要结构为模式6多路选择 模式7同步合并,IPC Event中调用方式需要选择为Synchronous

     

     

    ²  16 无法在运行期预先确定的多实例(Multiple Instances With a Priori Runtime Knowledge 

    l  描述:

    在一个活动能够被多次激活的这种情况下,在指定情况下的指定活动的实例数量无论是在设计时或者运行时都不能在活动的实例被创建之前预先确定。但是,在活动被创建之前,在运行中的某个阶段,这个数量是可以预知的。一旦所有的实例都完成了,其它的活动应该被启动。这个模式和模式14的区别在于,在某些实例运行结束之后,新的实例仍能被创建。

    l  案例:

    订购100 台电脑,涉及多个供应商,但是每个供应商供应多少台电脑是不知道的,因此供应商的数量事先也不确定。但是当每次供应商送货后,就会将现在所拥有的电脑数量和所需的100 台进行比较,来决定是否要下一个供应商继续送货。

    l  K2实现:

    比较复杂,可以利用模式11任意循环实现。

     

  5.  

    这三个模式的共同点是:模式所涉及根据当前运行的流程状态来改变流程里的执行路径,包括:Deferred choice(延迟选择模式) Interleaved parallel routing(交替平行路由模式) Milestone(里程碑模式)。

    ²  17 延迟选择(Deferred Choice

    l  描述:

    工作流中的一个点,有一个或多个分支已经被选择。与XOR拆分相比,并没有明确的选择,但是,选择是取决于环境的。与AND拆分相比,两者中只有一个被执行。这意味着一旦环境启动了其中的一个,另一个就被取消。要注意,选择是被延迟到两个分支中的一个真正开始执行时,也就是说,选择是可以尽可能的推后的。

    l  案例:

    在收到货物之后,可选择两种方法将其送到。选择取决于相关资源的可用性。如果资源均不可用,选择会被推迟到直到其中一个资源可用为止。

    l  K2实现: 

    “监听资源状况”的Destination Rules是一个Robot帐号,只实现监听作用。

     

     

     

    ²  18 交替平行路由(Interleaved Parallel Routing

    l  描述:

    一组活动以任意的顺序执行,每个活动都被执行,他们的顺序是在运行时决定的,并且在任意一个时刻都不会有两个活动在执行。

    l  案例:

    体检流程中的活动有各种常规检查和血液检查,哪个在先哪个在后都可以,但是不可能同时检查。

    l  K2实现:

    K2并无直接实现方法,需要编码,变通解决。 

     

    ²  19 里程碑(Milestone

    l  描述:

    一个活动能否执行取决于一个指定的状态。也就是说,只有在到达一个特定的未过期的里程碑时,活动才被执行。

    l  案例:

    客户在确定交付的前两天是可以取消订单的

    l  K2实现:

    时间上的一些状态可以在Start Rule Activity Escalations中实现,其他的复杂逻辑需要编程实现。

     

  6. 取消模式
  7.  

    这两个模式的共同点在于:模式所涉及的流程在运行时disables一个活动或者整个流程,包括:Cancel activity(活动取消模式)、Cancel case(实例取消模式)。

    ²  20  取消活动(Cancel Activity

    l  描述:

    一个可执行的活动被强制失效了,也就是说,一个正在等待执行的活动所在线程被移除了。

    l  案例:

    网上购书时已经下了订单,“支付货款”活动激活,这时如果取消了订单,那么相应的“支付货款”活动也要取消。

    l  K2实现:

    利用K2 API实现。

     

     

    ²  21  取消实例(Cancel Case

    l  描述:

    如果一个活动产生了多实例,那么仅仅撤消这个活动是不行的,要将这个活动的所有后代(实例)都移除才行。

    l  案例:

    网上购书时如果取消了购书的活动,所有因订单激活的购书流程实例都要取消。

    l  K2实现:

    利用K2 API实现。

     

  8. 其他扩展模式
  9.  

    21个工作流模式并不能囊括所有情况,还有其他的一些扩展模式,例如:流程启动、回退、转发、通知、代理、催办、回收、任务批处理、任务分组处理、流程合并、子流程等等。

     

原文地址:https://www.cnblogs.com/voidxy/p/2376476.html