参与者
一个公司的组织模型中，参与者是可以区分出类型的，所有参与者可以按照类型分成若干类。如：机构类型、员工类型等。并且，参与者之间存在"父子"关系。每一个参与者可以包含多个不同类型的子参与者，同时也可以从属于多个不同类型的父参与者。比如：员工类型的参与者就是机构类型参与者的子参与者。在多种参与者中，必定存在一个叶子参与者（基本参与者），叶子参与者不再包含其他的子参与者。我们的参与者类型目前支持如下几种类型:
| 参与者类型 | 参与者编码 |
|---|---|
| 员工 | emp |
| 角色 | role |
| 机构 | org |
| 工作组 | group |
注:员工(emp)类型的参与者为叶子参与者即基本参与者。 员工类型的参与者是机构类型参与者、角色类型参与者和工作组类型参与者的子参与者。
# 1 指定参与者
在参与者配置tab页进行设置，也可以在BFP中的业务配置进行设置。
# 1.1 流程启动者
人工活动图元默认的参与者就是流程启动者，就是发起流程的人。例如：张三是某个流程的发起人，某个环节设置的参与者是流程启动者，则流程在流转到这个活动时，张三就是这个活动参与者。
注：开始活动后的第一个人工活动的参与者只能设置成为流程启动者，因为发起流程时会直接完成第一个人工活动。
# 1.2 指定参与者
指定参与者可以直接指定员工、角色、工作组和机构这几种参与者类型。可以指定多个参与者(多种类型)。
# 1.2.1 员工
参与者为员工时，就是指组织机构中的员工。
# 1.2.2 角色
参与者为角色时，这个角色下的所有员工都能收到待办任务，只要一个员工完成了这个任务则此环节完成。
# 1.2.3 机构
参与者为机构时，这个机构下的所有员工都能收到待办任务，只要一个员工完成了这个任务则此环节完成。
# 1.2.4 工作组
参与者为工作组时，这个工作组下的所有员工都能收到待办任务，只要一个员工完成了这个任务则此环节完成。
# 1.3 复合参与者规则
复合参与者规则是通过机构+岗位和机构+角色共同来决定最终参与者的一种方式，最终的参与者会取两者员工的交集。
# 1.3.1 机构+岗位
此类规则是分别选择部门和岗位来确定参与者的，其中部门可以选择指定机构、发起人所在机构或者上一环节处理人所在机构。
# 1.3.2 机构+角色
此类规则是分别选择部门和角色来确定参与者的，其中部门可以选择指定机构、发起人所在机构或者上一环节处理人所在机构。
# 2 业务参与者规则
业务参与者规则分为平台提供的上一环节处理人默认参与者规则和流程发起人默认参与者规则，以及流程定义中的业务规则中的参与者规则，以及逻辑流。对这些规则如下分别介绍。
# 2.1 内置参与者规则
平台默认提供了两种规则，分别为上一环节处理人默认参与者规则和流程发起人默认参与者规则
这里对默认规则中的名词做一个解释
分管领导：机构指定的分管领导对应的员工
直属上级：员工所属机构的机构负责人对应的员工
一级部门负责人：员工所属机构的一级机构部门负责人对应的员工
# 2.1.1 上一环节处理人默认参与者规则
| 规则 | 描述 | 规则说明 |
|---|---|---|
| 上一环节处理人分管领导 | 上一环节处理人的分管领导 | 处理人所属机构不存在或者分管领导不存在抛出异常 |
| 上一环节处理人所在一级部门负责人 | 上一环节处理人的所在一级部门的负责人 | 一级部门不存在或者一级部门负责人不存在抛出异常 |
| 上一环节处理人 | 上一环节的处理人 | 处理人不存在抛出异常 |
| 上一环节处理人直属上级 | 上一环节处理人的直属上级 | 处理人所属机构不存在或者直属上级不存在抛出异常 |
| 上一环节处理人所属机构 | 该规则指上一环节处理人所属机构下的所有员工 | 处理人所属机构不存在抛出异常 |
| 上一环节处理人上级部门负责人 | 上一环节处理人所在部门的上级部门的负责人 | 上级部门不存在时返回当前部门，上级部门和当前部门都不存在或者当前部门和上级部门负责人不存在抛出异常 |
| 上一环节处理人上级部门 | 上一环节处理人所在部门的上级部门下的员工 | 上级部门不存在时返回当前部门，上级部门和当前部门都不存在抛出异常 |
| 上一环节处理人所在一级部门 | 上一环节处理人所在部门的一级部门下的员工 | 一级部门不存在抛出异常 |
# 2.1.2 流程发起人默认参与者规则
| 规则 | 描述 | 规则说明 |
|---|---|---|
| 流程发起人上级部门 | 流程发起人所在部门的上级部门下的员工 | 流程发起人上级部门不存在抛出异常 |
| 流程发起人所在一级部门 | 流程发起人所在部门的一级部门下的员工 | 流程发起人一级部门不存在抛出异常 |
| 流程发起人分管领导 | 流程发起人的分管领导 | 流程发起人不存在或者发起人所属部门不存在或者发起人部门分管领导不存在抛出异常 |
| 流程发起人 | 流程开始时的发起人 | |
| 流程发起人所在部门 | 流程发起人所在部门下的员工 | 流程发起人不存在或者发起人部门不存在抛出异常 |
| 流程发起人直属领导 | 流程发起人的直属领导 | 流程发起人不存在或者发起人部门不存在或者发起人直属领导不存在抛出异常 |
| 流程发起人所在一级部门负责人 | 流程发起人所在部门的一级部门的负责人 | 流程发起人一级部门不存在或者一级部门负责人不存在抛出异常 |
| 流程发起人上级部门负责人 | 流程发起人所在部门的上级部门的负责人 | 流程发起人上级部门不存在或者上级部门负责人不存在抛出异常 |
# 2.2 参与者规则扩展
# 2.2.1 自定义参与者规则
如果默认提供的参与者规则不满足需求，可参考自定义参与者规则使用
注：编写完成后，需要打包放置在afcenter的lib下才能使用，并且如果是自己新创建的包，参考 spring.factories扩展机制，将该jar包进行自动装配来识别定义扩展实现，或者参考bfp中的com.primeton.gocom.bfp.framework.rule.logic.impl.DefaultCurrentParticipantFunctions类，将自定义类的全路径更改为这个路径后打包，放置在afcenter的lib下重启后也可使用。
# 2.2.2 逻辑流
使用逻辑流，用户可以根据相关数据和流程上下文信息进行自定义参与者获取逻辑。在IDE中新建一个逻辑流。开发获取参与者逻辑，完成后保存逻辑流即可。最后，在流程中配置业务参与者规则，选择逻辑流，然后保存即可(具体的逻辑流开发请参考服务设计)
创建的逻辑流入参如下图：
其中逻辑流的入参出参必须严格按照如下配置：
| 类型 | 名称 | 数据类型 |
|---|---|---|
| 参数 | relativeData | Map |
| 参数 | processContext | ProcessContext |
| 返回值 | out | WFParticipant |
其中relativeData是流程的相关数据，processContext是流程实例基本信息，返回值是WFParticipant的数组。
注:使用逻辑流时只能使用当前应用下的逻辑流，否则不能使用！如果是微服务模式需要使用nacos。
其中WFParticipant 的类全名是com.eos.workflow.omservice.WFParticipant。
# 2.2.3 业务规则中的参与者规则
流程定义本身可以创建分支规则和参与者规则两种业务规则，在流程参与者配置处可以配置使用业务规则中的参与者规则。
流程定义属性配置页面新增参与者规则
业务规则中的参与者规则中可以使用业务资源(业务实体)、上下文数据和业务参数(自定义参数)，右侧编辑栏为规则的表达式栏，如果为条件，那么为结果（结果可以直接选择人员、机构和角色，同时也可以结合业务）。
在编写如果条件时，可以使用左侧业务资源、上下文数据和业务参数进行条件判断，如果条件是真则返回那么的结果，同时可以添加多个条件分支类似于编程语言中的if-else。
# 3 来自表单数据
表单数据中可以设置人员选择组件来设置参与者。
首先，先在表单设计页面，将对应参与者的属性字段的组件类型选择为人员选择组件
然后再高级设置中，勾选流程参与者配置
在活动中设置参与者为表单数据人员选择组件字段即可
# 4 来自相关数据
先在活动的参与者配置处填写变量名称，后调用相关数据接口在业务中进行具体数据值的指定(参与者的指定)。
注：相关数据的key可以是任意值，相关数据的值可以是WFParticipant对象或者List
对象，也可以是String类型的字符串。
| 格式 | 描述 |
|---|---|
| 字符串 | 必须按照如下格式编写: __participant:+参与者id+,+参与者名称+,+参与者类型，例如："__participant:3,test,emp"，多个参与者用 | 分隔。 |
| WFParticipant对象 | {"id":"1","name":"test","typeCode":"emp"<br/>} |
| List | [{"id":"1","name":"test","typeCode":"emp"},{"id":"2","name":"test2", "typeCode":"emp"}] |
参与者类型编码分为emp(员工)，role(角色)，org(机构)这三种，如果相关数据是WFParticipant对象或者List
# 5 活动执行者
可以设置后续活动的参与者为其他前序活动的执行者。
注： 如果指定的活动开启了多工作项，则本活动也必须开启多工作项配置。