工作流参考手册

工作流参考手册内容摘要：

连接线 上为“默认值“所指的后继活动“人工活动”一定会被触发；又由于满足“ num5”的条件所以“人工活动 1”也会被触发 2) 由活动射出的连线上中 没 有默认值 ，全部设置条件 如上图所示，由于“开始活动”的“分支模式”是 “ 多路分支 ” 并且在处理的过程中 “num==6” ，那么根据上面的算法说明由于 射向 “活动 B与 “ 活动 D”的连线上的条件都满足，因此“活动 B与 “ 活动 D” 在开始活动结束后被触发。 参与者设置 活动参与者实际上是指在流程实例运行过程中，流程实例 “ 流转 ” 至此时该活动实例所对应的工作项有哪些人可以执行。 在流程定义时设置 活动的参与者实际上是圈定流程实例运行至此时可以执行该活动实例所对应工作项的人员范围，可以是机构、角色或人。 EOS WorkFlow 提供了 4 种可以获取参与者的方式： 组织机构与角色 ：参与者由开发人员从机构树中获取 – 只选择一人：表示该活动所对应的工作项直接分配给该人处理 – – 超过一人：表示该活动所对应的工作项由这些人中的某个人以 “ 领取 ”的方式处理 虚拟岗位（机构 +角色） ：表示 在不设置岗位的情况下，由部门 +角色共同决定一个人工活动的参与者。 流程启动者 ：表示活动参与者为该流程的启动者 活动执行者 ：表示活动 参与者为某个已完成的活动实例所对应工作项的执行者 从相关数据获取 ：表示活动参与者由相关数据指定。 由相关数据获取参与者的规则详见 从相关数据获取参与者 从规则逻辑获取 ：表示活动参与者由某个规则逻辑的返回值 确定。 由规则逻辑获取参与者的规则详见 从规则逻辑获取参与者 特别说明 :如果要改写组织机构权限并在参与者设置的时候显示新的组织机构树，具体操作请参见知识库文档： 组织机构与工作流集成方案 .doc 虚拟岗位（机构 +角色）设置参与者 图 通过机构 +角色实现虚拟岗位设置参与者 用角色 +机构的方式设置参与者需要特别注意的是，在该活动激活以前一定要将上图中机构变量路径设置到相关数据区中。 此外，还有 一种方法设置一组机构：把多个机构 写成 如下格式 ： list id1/id / id2/id / /list 这样机构变量路径 xpath 写成： list//id 即可。 这样，工作流引擎也会找 到多个机构 id， 从而 实现 设 置一组机构 +角色的要 求。 如下 图所示： 图 设置一组机构变量 从相关数据区设置 参与 者 1）从相关数据获得一个具体的参与者 【算法说明】 从相关数据的 XPATH 中，直接指定一个参与者。 注：这种方式获得的参与者只能是个人。 相关数据必须满足下面的结构。 XXXXtiger/XXXX 2）从相关数据获得某一类型的参与者（指定一个或一组人员） 【算法说明】 从相关数据的 XPATH 中，获得某一类型的参与者。 可以是一个人，也可以是某一角色或某一机构的一组人。 相关数据必须满足 下面的结构。 XXXX id/ name/ type/ /XXXX 3）从相关数据获得一系列参与者 【算法说明】 从相关数据的 XPATH 中，获得一组参与者。 可以是一个人、一个角色、一个岗位、一个机构，也可以是机构、角色或个人的集合，还可以是岗位列表的集合。 相关数据必须满足下面的结构。 list Participant id/ name/ type/ /Participant Participant id/ name/ type/ /Participant /list id 和 type 的含义如上所示 [特别说明 ]： 在上面 XPATH 结构中如果 type 是 “ person”， 那么 id 即为用户ID； 如果 type 是 “ role”，那么 id 即为角色 ID；如果 type 是 “ anization”，那么 id 即为机构 ID； 如果 type 是 “ position”，那么 id 即为岗位 ID； 如果 type是 “ position_list”，那么 id 即 需满足如下格式： Condition type=OR // type=”OR”表示组织机构 roleIDrolea/roleID // 角色 ID ID$ID/ID // 获取机构 ID 的 XPATH（相对于相关数据的根路径）。 ”$”不可少，标识其后的串是个 XPATH。 /Condition 此外，还有一种方法设置一组机构：把多个机构写成如下格式： list id1/id / id2/id / /list 这样机构变量路径 xpath 写成： list//id 即可。 这样，工作流引擎也会找到多个机构 id，从而实现设置一组机构 +角色的要求。 从规则逻辑设置 参与者 从规则逻辑获取参与者 【算法说明】 从业务逻辑获取参与者列表，然后再按照“分配到组织机构”的模式进行分配。 从业务逻辑返回 Dom 当中找到参与者列表的方法： 1） 如果返回的结果中包括下面的结构，系统从 list 节点中获取多个参与者。 list Participant id/id name/name type/type /Participant Participant id/id name/name type/type /Participant /list 2） 如果从规则 逻辑中没有找到 list 节点，那么系统会查找 Participant 节点 .获取参与者。 格式如下所示： Participant id/id name/name type/type /Participant id 和 type 的含义同上。 [特别说明 ]： 如果如上所示的两种结构都存在于调用的规则逻辑的返回的结果中，那么系统只会从 list 节点中获取参与者。 在上面 XPATH 结构中如 果 type 是 “ person”， 那么 id 即为用户 ID； 如果 type是 “ role”，那么 id 即为角色 ID；如果 type 是 “ anization”，那么 id即为机构 ID； 如果 type 是 “ position”，那么 id 即为岗位 ID； 如果 type是 “ position_list”，那么 id 即 需满足如下格式： Condition type=OR // type=”OR” 表示组织机构 roleIDrolea/roleID // 角色 ID ID$ID/ID // 获取机构 ID 的 XPATH（相对于相关数据的根路径）。 ”$” 不可少，标识其后的串是个 XPATH。 /Condition 此外，还有 一种方法设置一组机构：把多个机构写成如下格式： list id1/id / id2/id / /list 这样机构变量路径 xpath 写成： list//id 即可。 这样，工作流引擎也会找到多个机构 id，从而实现设置一组机构 +角色的要求。 工作流 参与者设置机制说明 流程实例根据流转条件依次激活实例中的相应的活动，当活动分配给某个参与者（唯一的 userID）的时候，就在 WFWorkItem 表中形成一条工作项记录，主键为 workItemID。 在 WFWorkItem 工作项信息表里还有个很重要的字段：participant。 这个字段描述该工作项的参与者具体是谁。 在工作项参与者WFWIParticipant 表中，也有工作项 workItemID 和参与者 participant，不过，这个表里描述的是根据流程定义，活动被激活后工作项的分配情况， 根据流程定义的设置形 成相应的记录，比如，流程定义中有 3 种参与者，那么在WFWIParticipant 表中也形成 3 条记录， 所以这里的参与者有可能是具体个人（ userID），也可能是角色（ role），也可能是机构（ ID），也可能是岗位（ positionID）， 当工作项没有领取的时候，在 WFWorkItem 表中也会形成一条记录，这条记录的参与者字段 participant 是用“ |”隔开的参与者串，这个串中的参与者是在流程定义的时候定义的。 当工作项被领取以后，就会在工作项表WFWorkItem 表里出现具体的执行人信息。 此外，有时候 工作项会出现该派的情况，这个时候，改派以后具体参与者也在工作项表 WFWorkItem 表有描述，而工作项参与者 WFWIParticipant 表不会有什么变化。 时间限制 活动的时间限制表示活动实例启动启动后必须在多长时间内完成。 在活动时间限制的设置中 EOS WorkFlow 为开发人员提供了指定具体的限制时间、超时是否进行邮件通知、是否在超时前进行提醒、是否发提醒通知等功能。 活动时间限制的设置：开发人员可以根据业务需要在 “ 人工活动 ” 和 “ 子流程活动 ” 中进行设置。 活动时间限制的计时：从活动实例启动时开始计时 活动时间限制的获取：直接指定、从相关数据获取（格式： 表示时限为 3 天 5小时 20 分钟） 活动还有超时的触发事件设置，可以针对超时做具体的操作。 EOS WORKFLOW 判断流程或人工活动超时的原理 流程或人工活动的时间限制中设置的限制时间将写入表 WFProcessInst 或WFWorkItem 的 limitNum 字段中，单位为毫秒， limitNumDesc 是其描述字段；finalTime 是时间限制到达后的时间。 EOS WorkFlow 将当前时间与 startTime相减的结果与 limitNum 比较， 一旦超出时间限制就将 isTimeOut 字段置为 Y，表示超时 ； timeOutNum 表示超时了多长时间，在流程结束时写入。 如果设置了超时提醒，该字段可能出现负数，是未超时的表现，只有正数才表示超时的时间，timeOutNumDesc 是其描述字段。 多工作项 一个活动到底产生多少个工作项并且产生的这些工作项又由谁来做呢。 EOS WorkFlow 就工作项的产生和分配问题提供了 2种策略： 按参与者设置个数领取工作项： 按照此活动参与者的个数产生工作项。 每个参与者一个工作项，若参与者中包括若干人员（比如参与者的类型为机构 或角色），则这些人员可通过先 “ 领取 ” 的方式执行工作项。 例如：某活动设置了 3 个参与者： tiger，角色 B(包含 fish 和 goose 两人 )，机构 A(包含 kitty、 snoppy、 micky 三人 )，那么按照此策略将产生 3个工作项。 具体分配为： tiger 一个工作项，由其直接执行 (该参与者只有一个人所以无需先领取 )；角色 B一个工作项，由 fish 或 goose 中的一个人以领取的方式执行；同理，机构 A一个工作项，由 kitty、 snoppy 或 micky 中的一个人以领取的方式执行。 按操作员个数分配工作项 ：根据参与者中的人 员个数产生工作项，并且这些工作项将直接分配到参与者中的人员，每人一个。 例如，上面的例子若按此策略将产生 6 个工作项， tiger、 fish、 goose、 kitty、snoppy， micky 每人分配一个工作项，直接执行。 多工作项执行 不管工作项的个数如何相关人员每个人至多只能执行一个。 未完成工作项自动终止 1） 选择 “ 是 ” ： 工作流引擎在结束活动实例的同时对于那些剩余的未完成的工作项作 “ 停止 ” 处理。 2） 选择 “ 否 ” ： 那些剩余的未完成的工作项仍处于 运行 状态，尽管此时活动实例已结束。 这些工作项的拥有者此时无论 是否处理它们，已不会对运行的流程造成任何影响，只有当流程实例结束时，引擎才会将这些工作项终止 活动项与 工作项 活动项和工作项是一对多的关系， 人工活动被激活后，形成活动项实例继而有生成工作项实例，供参与者操作。 在工作项 表 WFWorkItem 中保存了活动项实力和工作项之间的关系。 通过 BL_finishActivityByDefID 结束活动的方式结束工作项 在现有工作流工作项结束调用中一般都会采用 BL_finishWorkItem这个运算逻辑调用，但是也有情况可以。