• 驰骋工作流引擎设计系列10时效考核规则设计


     

     

    第1节. 关键字

    驰骋工作流引擎 流程快速开发平台 workflow ccflow jflow

    第1节. 时效考核规则设计

    考核是流程运行的副产品,业务搬到了计算机上,整个运行轨迹就会被有效的记录下来。CCBPM的考核分为时效考核、质量考核。时效考核是对工作及时程度的一种考核,而质量考核是一个节点对上一个节点工作完成好坏的一个考核。

    1.1.1: 时效考核的系统配置

    系统配置分为工作日信息设置,节假日信息设置。

    上下班&午休时间配置,该设置在全局变量里:JFlow的配置:

    image

    CCFlow的配置:

    image

    时间点的计算方式:

    image

    B与D才是有效的时效区间,A,C,E的区间是需要扣除的。

    节假日配置:

    image

    如果是节假日,打上对勾,点击保存,就是告诉系统这几天是节假日,在计算时间的时候要扣除。

    说明:该配置的信息写入了Sys_GloVer 表里。Ccbpm的计算方式:系统是按照分钟来计算的。

    1.1.2: 时效基本设置

    下图是考核设置部分:

    image

    时效的设置:

    限期(天)与小时,两个字段决定了考核的时长。

    如果限期是一天半,那末在限期天字段设置为1,在小时里设置为4就可以了。按照通常的计算,如果是周5下班的时间发送的一件工作,那末该工作在下周2个上午午休时间之前完成都没有预期。

    如果一件工作需要3.5个小时完成,直接在限期(天)字段里设置为0,在小时字段里设置为3.5,在计算时间的时候,系统就会考虑午休的时间来合理的计算出来应该完成时间。

    工作的三个状态:

    一个任务分配下去后,它有三个状态,分别是:正常、预警、逾期。

    警告期限,就是提前多少天预警。限期,就是该工作需要多少天完成。比如:设置限期3天完成,警告期限是1天。

    那么,周1接受到的任务,应该是周4完成,如果周3还没有完成,就成警告状态了。

    image

    应完成时间的计算场景:

    场景1:如果一个人在节假期发送了一件工作,那末下一个时间点的计算方式就是,就是下次上班的开始时间。

    场景2:如果一个人处理工作的时间点是,节假日时间,那么他的实际完成时间的计算点是,下次上班的开始时间。

    场景3:如果一个人在工作日的午休时间发送的一件工作,那末他的计算时间点是,下午上班的时间。

    工作退回的时效考核计算方式:

    现在有ABC三个节点,他们的时限期限都是1天。

    一个流程实例A节点上的张三在周1的一上班发个给了B节点上的李四,李四的应完成时间是当天的下午下班之前,李四在下班之前提交给C节点上的王五了。王五,在次日接到该工作后又退回给李四,这个时间李四就预期了。

    解析:之所以李四预期是因为李四的工作错误,导致的王五退回给他,在王五接受工作的时间点内,仍然算李四的工作量。

    1.1.3: 关于会签主持人与会签人的时效考核计算规则

    关键字: ccflow 时效考核时效考核的配置规则会签主持人会签主持人的时间计算方式.

    应用场景:如果当前节点配置了时效考核,并且如果配置了启用会签按钮,如何计算会签人、主持人的时效.

    会签主持人定义:一个节点的处理人发送给该人,该工作人员启用了会签,他就是会签主持人。比如:一个出纳发起请假申请给财务经理,财务经理请求人力资源进行会签。那么财务经理是该工作的主持人,人力资源就是会签人。

    对主持人考核:

    时间段:当财务经理接收到工作就开始计算时间,到他选择会签人,点确定按钮为第一时间段。从当所有会签人都执行完会签完毕后到主持人发送到下一个节点为第2时间段。两个时间段之和就是主持人所用的时间,作为考核依据。

    对会签人的考核:

    从主持人把会签人选择列表后,点确定按钮该操作人员都已经出现待办,就执行计算,到他会签时间点止。

    事例说明1

    张三,在周1接受到一个工作,周2他让李四,王五执行会签。周4两个人会签完毕转到了张三身上,周5张三发送给下一个节点。

    这个案例中张三第1个时间段从周1到周2用了一天。第2个时间段,所有人会签完毕后返回到他身上起(周4)到他发送到下一个节点止(周5)用了1天。

    所以张三在这次会签过程中用去了1+1=2天时间。

    事例说明2

    接上一个事例,如果张三在周3又邀请了孙钱做了会签,周4所有的会签人都执行完毕回到了张三身上。那么张三在第一个时间段(周1到周3)用了两天,第2个时间段(周4到周5)用了1天。

    所以张三用了 2+1=3天。

    1.1.4: 时效考核的存储

    在节点发送后,系统就会自动计算时效的时间,就会产生一条数据,下面是数据存储表的数据结构。

    image

    数据存储:

    image

    数据说明:

    MyPK是一个组合的主键,它保障了业务数据的唯一性,格式为:从节点ID_工作ID_FID_到达的节点ID

    DTFrom时间从,DTTo时间到,SDT应该完成时间(现在是系统调度过来的所以没有)。

    TSpan相隔的天数,

    l UseTime字段是系统生成出来的对于时间的文字描述。

    l UseMinutes就是该工作使用的分钟数,系统是按照分钟为计算单位,如果为负数,就是提前完成的时间。

    l FK_NY年月,格式为yyyy_MM ,方便统计与分析。

    l Week是周,就是1年的第几周,他是自动计算的也是为了方便分析的需要。

    l MyNum始终等于1,也是为了分析所需要。

    1.1.5: 时效考核的二次开发

    因为考核的需求很难被抽象出来,以适应各种单位的考核需要,但是ccbpm提供了基础的数据,让其在此基础上进行二次开发。

    这些数据可以从两个方面WF_CH与NDxxxTrack 轨迹表,ccbpm为每个流程都生成一个NDxxxTauck表,xxx标识流程编号转化的int类型,比如:流程编号为001的就会产生一个ND1Truck, 流程编号为201的就产生一个ND201Tauck表,如下表:

    image

    该表的红色方框里是活动类型,ccbpm会把每一个对流程的操作记录到这里个表里,它是一个流程轨迹表,也叫流程日志表,开发人员可以根据这个表的数据完成个性化的考核。

    第2个数据来源,就是WF_CH,该表的表结构不再赘述。

  • 相关阅读:
    Git简介
    Git之 git status、git diff 的基本使用
    Git之撤销修改 git checkout file、git reset HEAD file 的使用
    git连接gitlab远程仓库
    Git版本回退及 git log 、 git reset hard commit_id 的基本使用
    Git创建版本库及git init 、add 和 commit m 的基本使用
    Git之工作区和暂存区
    Git的由来及分布式版本控制和集中式版本控制的区别
    MariaDB 主从同步与热备
    MariaDB 用户与权限管理
  • 原文地址:https://www.cnblogs.com/mengjuan/p/10283028.html
Copyright © 2020-2023  润新知