应用开发平台集成工作流系列之17——流程建模功能前端设计与改造回顾

背景

对于流程设置不友好的问题，国内钉钉另行设计与实现了一套流程建模模式，跟bpmn规范无关，有人仿照实现了下，并做了开源（https://github.com/StavinLi/Workflow-Vue3），效果图如下：

实现大致原理是基于无限嵌套的子节点，输出json数据，传给后端，后端进行解析后，调用Camunda引擎的api，转换成流程模型后持久化。

该系列通过十几篇对Camunda工作流引擎集成做了相对比较详细的设计和实现说明工作，在集成过程中，对原前端Workflow-Vue3做了大量的改造，前面零零星星的也随着部分博客提及过，今天做一个全局性的回顾和整理。

节点类型

目前平台已经实现的节点有三类，发起节点、办理节点、路由节点。
发起节点与办理节点对应着Camunda中的用户任务类型，路由节点对应着Camunda中的兼容网关类型。
后续可以在此基础上进行功能扩展，使用Camunda的服务节点，构建不同用途的前端节点类型，如发送通知（邮件、短信等）、流程归档等。

节点配置

流程是有多个节点组成的，但仅有节点，以及连接节点的边还不够，每个节点需要进行必要的配置。
对于不同类型的节点，配置也有差异。

基础属性

基础属性是节点的通用公共数据结构，所有节点类型都一样，如下图所示：

{
	id:'',
	name: '填报',
	type: 'FIRST_NODE',
	config: {},
	branchList: [],
	child: {}
}

各属性含义如下

属性	类型	含义	说明
id	String	标识	唯一性标识，由前端随机生成
name	String	名称	节点名称
type	String	类型	ROOT(发起人，根节点)、HANDLE(办理)、INCLUSIVE_GATEWAY(路由)
config	Object	配置	节点的设置项内容，不同类型的节点设置内容不同，从而数据结构不同
child	Object	子节点	当前节点的子对象
branchList	Array	分支	当type 为 INCLUSIVE_GATEWAY 时，该项存在，存放分支数据

办理人设置

针对用户任务节点，设置该环节是会签还是单人处理，是否需要用户指定处理人，以及关联的用户组（角色）。
数据结构示例：

	"personConfig": {
				"mode": "NORMAL",
				"setAssigneeFlag": "YES",
				"userGroup": "99",
				"userGroupName": "系统管理员"
	}

属性说明：

属性	类型	含义	说明
mode	String	模式	COUNTERSIGN:会签；NORMAL:普通
setAssigneeFlag	String	是否指定人	YES:是；NO:否
userGroup	String	用户组（角色）	调用平台的用户组单选组件，选择一个用户组，用户组的标识
userGroupName	String	用户组（角色）的名称	用户组的名称

表单权限设置

控制该环节表单不同区域的可见性与可编辑性，对发起节点（流程首环节，通常用于填报）和用户任务节点需要设置。

数据结构示例：

	"config": {
		"permissionConfig": [{
			"areaCode": "applyArea",
			"permission": "EDITABLE"
		}, {
			"areaCode": "organizationApproval",
			"permission": "READONLY"
		}, {
			"areaCode": "hrApproval",
			"permission": "INVISIBLE"
		}]
	}

属性说明：

属性	类型	含义	说明
areaCode	String	区域编码	在平台权限项管理中定义与维护
permission	String	权限编码	INVISIBLE：不可见；READONLY:只读；EDITABLE:可编辑

回退节点设置

当前环节可回退到的节点定义。

数据结构示例：

	"backNodeList": [{
					"id": "root",
					"name": "填报"
				}, {
					"id": "node1938_8b28_c3ed_030f",
					"name": "部门审批"
	}]

属性说明：

属性	类型	含义	说明
id	String	环节标识	发起环节使用统一约定的root
name	String	环节名称

跳转节点设置

当前环节可跳转到的节点定义，与回退节点配置类似。

数据结构示例：

	"jumpNodeList": [{
					"id": "root",
					"name": "填报"
				}, {
					"id": "node1938_8b28_c3ed_030f",
					"name": "部门审批"
	}]

属性说明：

属性	类型	含义	说明
id	String	环节标识	发起环节使用统一约定的root
name	String	环节名称

监听器配置

环节监听器的配置，用于实现特定的业务逻辑

数据结构示例：

	"listenerList": [{
				"category": "TASK",
				"type": "CLASS",
				"name": "请假申请部门审批完成",
				"code": "tech.abc.platform.businessflow.listener.LeaveDepartApprovalCompleteListener",
				"event": "COMPLETE",
				"eventName": "完成"
			}, {
				"category": "TASK",
				"type": "CLASS",
				"name": "请假申请部门审批完成",
				"code": "tech.abc.platform.businessflow.listener.LeaveDepartApprovalCompleteListener",
				"event": "COMPLETE",
				"eventName": "完成"
}]

属性说明：

属性	类型	含义	说明
category	String	分类	TASK：任务监听器；EXECUTION：执行监听器
type	String	类型	CLASS：类；EXPRESSION:表达式；DELEGATE_EXPRESSION:委托表达式
name	String	名称	监听器名称
code	String	编码	取决于type，如为类，则本属性放完整的类名
event	String	事件编码	取决于category，如为任务监听器，则取值如下：
CREATE：创建；ASSIGNMENT:指派；COMPLETE:完成；DELETE:删除
eventName	String	事件名称	参见上面事件编码的枚举值定义中文部分

条件配置

设置条件，路由节点后续的分支节点需要配置。

数据结构示例：

{
	"name": "路由",
	"id": "node3278_00b0_e238_a105",
	"type": "INCLUSIVE_GATEWAY",
	"config": {},
	"child": null,
	"branchList": [{
			"name": "3天以内",
			"id": "condition5914_12fb_e783_f171",
			"type": "CONDITION",
			"config": {
				"expression": "${total<=3}"
			},
			"branchList": []
		},
		{
			"name": "超过3天",
			"id": "condition10081_fd56_1fb6_f8ed",
			"type": "CONDITION",
			"config": {
				"expression": "${total>3}"
			},
			"branchList": []
		}
	]
}

属性说明：

属性	类型	含义	说明
expression	String	表达式	示例：${total<=3}

组件改造

如上面所示，我们对前端数据结构进行了大调整，相应的，原组件也需要进行相应的调整，差不多只留了架子，内部大换血，主要实现如下：

流程建模组件nodeWrap

效果图

源码

添加节点组件addNode

效果图

源码

发起环节配置

发起环节相对比较特殊，不需要设置处理人员和回退环节，只需要设置表单权限和跳转环节。

源码

办理环节配置

办理环节要设置多项配置。

源码

条件配置

条件配置比较简单

源码

开发平台资料

平台名称：一二三开发平台
简介： 企业级通用开发平台
设计资料：csdn专栏
开源地址：Gitee
开源协议：MIT
开源不易，欢迎收藏、点赞、评论。