组件
# 文件服务器(上传组件,图片服务器)
# 功能特点
- 支持独立部署模式
- 支持lib包嵌入式的模式
- 支持插件扩展处理上传的文件
- 支持不同的存储位置
- 本地目录
- 阿里oss
- 七牛
- 腾讯
- amazon
# 设计思路及业务流程
- 每个系统每个业务可新增不同的bucket,bucket可指定扩展,存储位置等,可配置key和secret
- 使用key和secret和时间,once等来生成token,token可分为查看token和操作token
- 上传文件时的json
- 上传文件的json参数如下,返回fileId,fileUrl
{
token: '',
bucket: '',
formId: '',//业务功能id
type:'',//类型，由业务定义和使用
type2:'',//类型2，由业务定义和使用
fileName:''//原始文件名
}
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
- bucketId
# 状态流
# 功能特点
- 简单的状态流管理
有些功能没必要用到复杂的工作流,但又有工作流类似的功能需求,这时可使用状态流,可认为是简化版的工作流 - 状态历史记录
- 操作人的数据权限
- 待办消息提醒
- 待办统计
# 数据权限方案
# 方案一:先通过personId查状态历史记录表,得到formIds,再通过formIds取得业务数据
- 支持nosql
- 支持微服务
- 业务无法加查询条件
# 方案二:业务表与状态历史记录表关联查询
- 不支持nosql
- 不支持微服务
# 方案三:业务表加一个处理人属性来存放personIds
- 支持nosql
- 支持微服务
- 数据多时性能稍微差(因为用like),如果不取select count记录总数(分页只显示下一页,不显示一共多少页),在不多记录数就扫描够一页数据时，性能应该不会太差
# 方案的选择
- 方案一因功能满足不了需求，不采用
- 在不需要nosql时优先考虑方案二,方案二理论也能实现微服务(每个微服务都有一张状态历史记录表)
- 在需要nosql时采用方案三
- 组件支持方案二与方案三，使用者使用方式是一样的，没使用上的区别(只有配置上的区别)
# 定时任务
# 功能特点
- 可嵌入式运行,可独立运行
- 支持页面管理定时任务
- 支持集群(第一版不实现)
- 支持分布式并行处理(第一版不实现)
- 可查看执行日志和执行历史记录
- 支持是否从执行完成开始算(第一版不实现)
- 支持内置定时器(用@Scheduler注解)，可在页面管理，但不能删除和修改名称,code等属性
- 不用页面管理时，可以不依赖mtbase,直接引入jar(第一版不实现)