集成简介

相比上一版本，引擎内部结构和交互方式作了重新设计，由原来的辅助角色转变为主导角色。因此业务集成方式也需要相应变化。下面先介绍一些显著差异。

差异说明

流程权限

用户可以发起哪些流程，不再使用系统级人员-角色控制，仅由流程起始节点的操作人配置决定。

流程发起

用户所有被授权的流程在流程中心页面展示，在这里发起流程。不再需要按业务模块分别设置入口。

操作人

流程各节点操作人不再使用人员角色与用户数据维度配置，现直接配置在流程节点上。

办理权限

办理权限判断不再使用角色-菜单与用户数据维度，现仅能由工作任务创建时匹配规则的操作人办理。

工作办理

不再使用按业务模块组织的独立页面办理工作。现在用户将从工作台跳转至统一的办理页面，即用户所有操作仅使用工作台、工作办理两个页面。

提示

开发人员需要实现业务表单组件，交由办理页面调用。

当前节点

引擎不再保存及对外提供当前节点字段，也不再推荐业务侧基于当前节点筛选数据。

用户操作

现在起，用户操作完全由流程引擎驱动。

1. 用户可以发起的事项在流程中心。
2. 用户需要办理的事项在工作台待办列表。
3. 用户办理工作使用统一的办理组件。

以上三个界面实际上涵盖了普通用户所有操作，开发人员不再需要单独开发入口页、列表页。

引擎与业务

引擎仅负责处理流程相关内容——流程管理、工作创建、工作办理等，不负责具体业务。但在工作办理时必须与业务打交道。比如用户打开一项请假待办，业务侧如何知道该加载哪一条数据呢？

这时必须由工作信息得到业务信息，因此我们提供了 getBizInfo 方法，用来获取创建工作时传入的 bizId。有了 bizId，业务侧就可以确定要操作的数据了。

提示

getBizInfo 方法不仅用来获取业务标识，也会进行任务权限与状态验证。因此推荐在业务方法中优先调用。

集成过程

业务集成的大致过程如下：

1. 创建流程，配置节点
2. 开发前端业务组件
3. 后端实现，调用引擎 API 驱动流程

其中业务组件与引擎调用开发是核心，前者负责表单界面实现，后者负责与引擎交互。详情请查看工作组件 与 引擎API。