clay commit : workflow查看
continuous-integration/drone/push Build is failing
Details
|
|
@ -61,6 +61,7 @@ module.exports = {
|
||||||
'/module/gateway/',
|
'/module/gateway/',
|
||||||
'/module/auth/',
|
'/module/auth/',
|
||||||
'/module/umps/',
|
'/module/umps/',
|
||||||
|
'/module/notice/',
|
||||||
'/module/visual/',
|
'/module/visual/',
|
||||||
] // 根据自己的需求来订,对应自己在docs下的文件夹名,默认首页是README.md
|
] // 根据自己的需求来订,对应自己在docs下的文件夹名,默认首页是README.md
|
||||||
},
|
},
|
||||||
|
|
|
||||||
|
|
@ -332,6 +332,9 @@ email:
|
||||||
### 防重复提交
|
### 防重复提交
|
||||||
防重复提交是指在进行数据提交的过程中,防止用户重复提交相同的数据或者重复执行同一操作的一种技术手段。这种技术手段的主要目的是避免数据的重复录入或者重复操作所带来的不必要的麻烦和风险,同时也可以提高应用程序的稳定性和可靠性。系统使用后端校验+分布式锁的方式实现
|
防重复提交是指在进行数据提交的过程中,防止用户重复提交相同的数据或者重复执行同一操作的一种技术手段。这种技术手段的主要目的是避免数据的重复录入或者重复操作所带来的不必要的麻烦和风险,同时也可以提高应用程序的稳定性和可靠性。系统使用后端校验+分布式锁的方式实现
|
||||||
|
|
||||||
|
### 锁的唯一性
|
||||||
|
锁的唯一性保证是通过用户登录后的token(匿名用户则使用客户端ip)+加上uri+方法请求类型+需要使用的请求参数组成的key保证锁的唯一性
|
||||||
|
|
||||||
### 使用
|
### 使用
|
||||||
1. 引入依赖
|
1. 引入依赖
|
||||||
```xml
|
```xml
|
||||||
|
|
@ -350,8 +353,33 @@ public Result<String> login(@Validated @RequestBody LoginBody login) {
|
||||||
```
|
```
|
||||||
|
|
||||||
3. 拦截效果
|
3. 拦截效果
|
||||||

|

|
||||||
|
|
||||||
### 通用分布式锁
|
### 通用分布式锁
|
||||||
通用分布式锁主要通过
|
通用分布式锁主要通过
|
||||||
|
|
||||||
|
### 分布式锁
|
||||||
|
分布式锁的实现与防重复提交实现原理相似,也是采用注解+aop+反射实现
|
||||||
|
|
||||||
|
|
||||||
|
## common-websocket
|
||||||
|
### 简介
|
||||||
|
该模块使用Netty搭建websocket服务,并将websocket服务注册到nacos实现Netty集群,之后可以使用Gateway实现代理和负载均衡
|
||||||
|
|
||||||
|
### 使用
|
||||||
|
1. 引入依赖
|
||||||
|
```xml
|
||||||
|
<dependency>
|
||||||
|
<groupId>cn.odliken</groupId>
|
||||||
|
<artifactId>common-websocket</artifactId>
|
||||||
|
</dependency>
|
||||||
|
```
|
||||||
|
2. 配置yml文件
|
||||||
|
```yaml
|
||||||
|
websocket:
|
||||||
|
application-name: netty-application-name
|
||||||
|
port: 8080
|
||||||
|
path: /websocket
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1 +1,32 @@
|
||||||
# 通用消息公告模块
|
# 通用消息公告模块
|
||||||
|
## 简介
|
||||||
|
痛用消息模块使用netty实现的websocket,引入common-websocket模块进行实现,基于netty集群+rabbitmq实现集群模式下的消息精准推送功能。
|
||||||
|
|
||||||
|
通用消息模块可为系统任意模块提供消息发布和websocket消息推送功能,并对外提供rpc消息发送功能。
|
||||||
|
|
||||||
|
消息推送时可以指定发送到指定用户,发送到指定角色,发送到指定部门或者全部发送四大模式。
|
||||||
|
|
||||||
|
在用户侧websocket不作为用户与service进行消息发送的桥梁,websocket只会进行消息的推送和授权,消息的发送则是使用消息发送接口进行。
|
||||||
|
|
||||||
|
## 消息推送时序图
|
||||||
|

|
||||||
|
|
||||||
|
## 消息发送确认机制
|
||||||
|
|
||||||
|

|
||||||
|
- 当用户发送消息后,消息首选会数据库进行持久化,持久化成功推送至mq,若消息推送失败则发生数据库回滚。
|
||||||
|
- mq接受到消息之后,向netty的监听服务发起事件,netty进行消费,消费成功手动ack确认,若3次消费失败,则认为当前服务消费失败,手动ack确认消息消费失败,并删除mq中的消息。
|
||||||
|
|
||||||
|
## websocket连接与授权
|
||||||
|
连接: websocket请求url为http://gateway-service/notice-ws/notice。
|
||||||
|
|
||||||
|
授权: 授权需要获取到用户登录时获取到的token,并按照规定数据格式在连接成功websocket之后发送授权信息。
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"token": "用户令牌",
|
||||||
|
"cluster": "消息群组"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## notice服务实现模块分离
|
||||||
|
在notice服务中,消息体或者websocket连接用户授权是都需要指定到消息群组(cluster),notice服务则通过cluster区分消息群组,并对其用户的websocket连接进行隔离。
|
||||||
|
|
|
||||||
|
After Width: | Height: | Size: 83 KiB |
|
After Width: | Height: | Size: 14 KiB |
|
|
@ -17,10 +17,71 @@
|
||||||
## custom-query(正在规划)
|
## custom-query(正在规划)
|
||||||
将ebts中的自定义查询和er可视化查询集群化,ebts网站:https://demo.ebts.top/
|
将ebts中的自定义查询和er可视化查询集群化,ebts网站:https://demo.ebts.top/
|
||||||
|
|
||||||
## flowable(收尾中)
|
## flowable
|
||||||
使用flowable实现workflow的开发,新阶段实现了json转bnpm,流程发布,流程流转,流程流转的位置等
|
### 简介
|
||||||
|
flowable模块为系统提供工作流的服务支撑,前端采用开源的防钉钉bpmn编辑器,并对前端编辑器进行升级和自定义功能的开发
|
||||||
|
|
||||||
demo(访问时提示无权限时请刷新,刷新后正常使用): http://workflow.mytwins.top/
|
### 实现功能
|
||||||
|
- 流程发布
|
||||||
|
- 自定义表单
|
||||||
|
- 表单节点权限控制
|
||||||
|
- 流程流转
|
||||||
|
- 全新的日志记录
|
||||||
|
- 发起流程时全新的全局流程
|
||||||
|
- 流程流转是邮件提醒
|
||||||
|
- 自定义监听器
|
||||||
|
- 触发器http请求js可编程影响流程流转结果
|
||||||
|
- 流程自定义任意节点回滚
|
||||||
|
- 表单编辑器可自定义组件开发
|
||||||
|
|
||||||
|
### 1. 流程发布
|
||||||
|
流程发布为workflow第一个步骤,需要用户自定义流程,配置审批表单,并且可以对表单权限与节点权限进行控制
|
||||||
|
|
||||||
|
#### 审批流程
|
||||||
|
审批流程共实现如下节点
|
||||||
|
|
||||||
|
- 审批人:审批节点,可以选择指定用户对本次流程进行审批
|
||||||
|
- 抄送人:将当前流程抄送给设置的用户进行查看
|
||||||
|
- 条件分支:可以设置对条件影响流程的执行,其中可使用表单中的参数
|
||||||
|
- 并行分支:可以同时执行两条或多条审批路线
|
||||||
|
- 延时等待:可以让流程在指定时间或者指定等待时间执行
|
||||||
|
- 触发器:可以发起http请求或者邮件
|
||||||
|
|
||||||
|
#### 审批人
|
||||||
|
审批人实现多种方式指定审批人,配置下图所示:
|
||||||
|

|
||||||
|
|
||||||
|
当用户选择了对应的审批对象后,系统则会根据对应的审批对象去获取对应的审批人,加入到审批流程中,并且还对其审批人为和审批期限进行辅助
|
||||||
|
|
||||||
|
#### 抄送人
|
||||||
|
抄送人节点只需要选择对应的抄送人即可,后续可扩展和审批人相同的选择审批对象
|
||||||
|
|
||||||
|
#### 条件分支
|
||||||
|
条件分支节点下可以设置多种条件,条件可以进行多种自定义组合,实现用户指定的流程流转方向
|
||||||
|
|
||||||
|
#### 触发器
|
||||||
|
触发器可以发起http请求或者email邮件,发起http请求的时候可以编写自定义脚本来处理http的响应结果,并可以影响到整个流程的流程
|
||||||
|
|
||||||
|
#### 流程简单demo
|
||||||
|

|
||||||
|
|
||||||
|
### 自定义表单
|
||||||
|
自定义表单实现为拖拽的方式进行表单的自定义设计,这样用户就可以制作任意业务需求的表单满足所以的业务场景
|
||||||
|

|
||||||
|
|
||||||
|
### 发起流程
|
||||||
|
流程发起提供左右两个区域,左侧区域为表单输入位置,右侧为流程的预览,此处可以看到流程执行情况以及当前流程对应的审批人
|
||||||
|

|
||||||
|
|
||||||
|
### 查看流程
|
||||||
|
到我的处理页面即可查看到需要当前登录用户处理的流,点击之后就可以看到流程的信息,此处定制开发流程的日志信息
|
||||||
|

|
||||||
|
|
||||||
|
### 我发起的流程
|
||||||
|
登录用户查看我发起的,当前页面可以查看到流程当前的节点,当前的审批人,流程状态等,点击流程就可以查看到流程的详细情况,详细情况和查看流程完全一样,并且新增全局的流程信息
|
||||||
|

|
||||||
|

|
||||||
|
流程全局预览和日志记录可以记录每个操作的情况,列如那些用户没有审批,那些节点处于审批状态,那个节点被拒绝,并且拒绝的用户是谁等都可以记录下来,方便后续精准的定位人员
|
||||||
|
|
||||||
## sentinel-dashboard
|
## sentinel-dashboard
|
||||||
sentinel的控制面板
|
sentinel的控制面板
|
||||||
|
|
|
||||||
|
After Width: | Height: | Size: 25 KiB |
|
After Width: | Height: | Size: 56 KiB |
|
After Width: | Height: | Size: 55 KiB |
|
After Width: | Height: | Size: 62 KiB |
|
After Width: | Height: | Size: 79 KiB |
|
After Width: | Height: | Size: 74 KiB |
|
After Width: | Height: | Size: 66 KiB |