插件整体介绍

1 功能介绍
1.1 为什么要开发插件
使用应用开发平台的设计器开发业务对象,全程配置,简单易学,但不够灵活。
配置业务对象时使用的业务语意,需要预先定义,遇到未考虑的业务场景时,则无法处理。
因此,我们通常用业务对象设计器实现80%业务语意,再利用开放的插件开发承担剩余20%的工作。
1.2 插件能做什么
插件可以在适当的时机,根据接收到的上下文信息,对系统功能进行控制。适当的时机,是指插件只会在系统功能运行到了特定时刻,才能收到系统通知,进行功能处理;并不能对系统功能的全过程进行干预。
插件拿到的上下文信息,能够调用的控制方法,也是经过系统封装,有所限制;
插件可以在系统约束的框架之内,对系统进行适度的干预,平衡灵活性与安全性。
表单界面在加载、展示期间,关键功能执行时,调用插件接口方法,触发插件事件,通知插件工作;而插件能够在被调用的事件方法中,调用表单视图、控件模型、表单数据模型,对表单界面进行控制。

2 应用场景
插件需要根据不同的业务对象类型,提供特定的业务功能,适用对应的应用场景。系统为各种业务对象类型、各种应用场景,封装了相应的插件接口、事件方法,定义了抽象插件基类,实现最基本的插件接口。
| 插件名称 | 应用对象 | 插件注册入口 |
| 动态表单插件 | 动态表单 | 【动态表单】→【表单主实体】→【插件】控件属性 |
| 移动端表单插件 | 移动端表单 | 【移动表单】→【表单主实体】→【插件】控件属性 |
| 单据界面插件 | 单据 | 【单据】→【表单主实体】→【插件】控件属性 |
| 基础资料界面插件 | 基础资料 | 【基础资料】→【表单主实体】→【插件】控件属性 |
| 移动端基础资料插件 | 移动端基础资料 | 【基础资料】→【移动表单】→【表单根节点】→【插件】控件属性 |
| 标准单据列表插件 | 单据列表 | 【列表】→【表单根节点】→【列表插件】控件属性 |
| 左树右表单据列表插件 | 左树右表单据列表 | 和标准单据插在一致,参考: 【列表】→【表单根节点】→【列表插件】控件属性 |
| 树形基础资料列表插件 | 树形基础资料列表 | 【基础资料(树形基础资料模板)】→【列表】→【表单根节点】→【列表插件】控件属性 |
| 移动端单据插件 | 移动端单据 | 【单据】→【移动表单】→【表单根节点】→【插件】控件属性 |
| 移动端单据列表插件 | 移动端单据列表 | 【单据】→【移动列表】→【表单根节点】→【列表插件】控件属性 |
| 单据操作插件 | 操作 | 【单据】→【操作】→【修改】或【新增】→【其他控制】→【服务插件】 |
| 单据转换插件 | 转换路线 | 【业务流开发】→新增或修改一条【转换路线】→【插件】 |
| 单据反写插件 | 反写规则 | 【单据】→【关联配置】→【反写插件】 |
| 打印插件 | 打印页面 | 【打印页面】→【表单根节点】→【插件】控件属性 |
| 新打印插件 | 新打印页面 | 【新打印页面】→【插件】 |
| 报表取数插件 | 报表列表 | 【报表】→【报表列表】→【查询插件】控件属性 |
| 报表界面插件 | 报表页面 | 【报表】→【表单根节点】→【插件】控件属性 |
| 工作流插件 | 工作流 | 【工作流设计器】→【流程控制】→【流程插件】 |
| 引入引出插件 | 表单数据引入引出 | 和标准单据插件一致,参考: 【列表】→【表单根节点】→【列表插件】控件属性 |
| 开放API插件 | API服务 | 【开放平台】→【API服务】→【插件】 |
| 后台任务插件 | 后台任务 | 【系统管理】→【调度作业】→【执行程序】 |
3 重要概念
3.1 表单视图模型、控件编程模型
金蝶云苍穹,是B/S结构的,使用不同的客户端(PC端、移动端),通过网络连接到统一的服务端,因此:
用户看到的交互界面,是运行在客户端的,而业务逻辑和业务插件,则运行在服务端;
业务插件运行在服务端,没办法直接获取到客户端界面上控件句柄,不能直接控制前端控件。
但是,插件可以通过系统封装的视图模型接口IFormView,间接的访问、控制前端界面,通过系统封装的各种控件代理对象,间接的访问、控制前端界面上的控件;这些运行在服务端的控件代理对象,称为控件编程模型,或简称为控件、编程模型等。
插件可以通过this.getView()方法,获取表单的视图模型接口实例;也可以通过this.getView().getControl(String key)方法,获取到控件编程模型实例。
3.2 表单数据模型
表单的界面与数据是分离的:
界面显示在客户端浏览器或者移动端,在服务端,系统封装了视图模型及控件编程模型来间接控制前端界面及前端控件;
数据存储在服务端,在服务端,系统封装了数据模型,来控制界面上的数据;
表单的数据模型,提供各种方法访问界面数据,并且持有:
主实体模型:MainEntityType,表单运行时元数据对象,包含:
子实体:EntityType,对应单据体、子单据体等;
属性:DynamicProperty,对应字段;
界面数据包:DynamicObject,基于主实体模型构建的一个数据字典,存储单据体、字段值。
4 主要操作
4.1确定应用场景,选择插件基类
进行业务功能设计时,首先需要根据业务需求特点,分析业务应用场景,选择业务对象类型。如果需要进行插件开发,则根据前面确定好的业务对象类型及应用场景,选择对应插件。
4.2 确定事件源与控件
有交互界面的应用场景(如表单、单据列表等),在界面加载、关闭时,会触发相应的插件事件;另外,用户与界面,以及界面上的控件交互时,也会触发插件事件。各种控件有自己的功能特点,适用不同的业务需求,提供相应的插件事件。
在进行功能设计时,需要根据业务需求,选用合适的控件,确定需要重写的插件接口方法,响应插件事件。后面的控件与字段章节,将详细列出各种控件的功能特定及支持的插件事件供参考。
注意:没有交互界面的应用场景(如单据操作、单据转换、关联反写、生产凭证等),不会与用户发生交互,其插件事件是由服务引擎按顺序触发的。这些应用场景,不需要关注事件源、控件;只需要根据业务需求,捕获合适的插件事件即可。
4.3响应(捕捉)插件事件
系统封装了各种插件事件接口;表单、控件、字段等事件源,各自有选择的支持了部分插件事件接口。
系统会在适当的时机,调用插件事件接口的方法,传入上下文参数,触发插件事件。比如:用户与前端界面、控件交互时,系统会把交互请求传递给表单、控件;表单、控件调用其下的插件事件接口实例(即插件)的方法,触发插件事件。
不同的插件事件,触发的时机、传入的上下文参数、可以控制的功能,差异非常大。因此,必须根据业务需求,选择合适的插件事件响应,参考以下两种场景的响应(捕捉)插件事件:
无交互界面的场景
没有交互界面的应用场景,插件基类已经实现了必要的插件接口,插件只需要扩展插件基类,重写事件方法即可完成事件的捕捉:
package kd.bos.metadata.botp;
import kd.bos.entity.plugin.AbstractOperationServicePlugIn;
import kd.bos.entity.plugin.args.BeforeOperationArgs;
public class WriteBackRuleOpPlug extends AbstractOperationServicePlugIn {
@Override
public void beforeExecuteOp插件整体介绍
声明:除非特别标注,否则均为本站原创文章,转载时请以链接形式注明文章出处。如若本站内容侵犯了原著者的合法权益,可联系本站删除。



