唛盟xm:涵盖项目规划、需求管理、开发迭代、版本控制、缺陷跟踪、测试管理、工时管理、效能分析等环 节,实现项目全过程、全方位管理的一站式企业研发项目管理解决方案
快速导航
- 前端组件
- 后端服务
- 体验环境 登陆界面上选择演示账号登陆(账号密码:demo-branch-01 888888)或者直接扫码登陆,无须注册
- 相关教程b站上搜素唛盟9哥教你撸前后端代码
📢 简介唛盟xm
唛盟企业级研发管理系统简称唛盟xm,属于唛盟生态的专业子系统之一,以研发管理为核心,涵盖项目规划、需求管理、开发迭代、版本控制、缺陷跟踪、测试管理、工时管理、效能分析等环节,实现全过程、全方位的研发管理。通过该系统,企业能够优化研发流程,提高研发效率,降低研发成本,提高市场竞争力。
💪给你一个使用唛盟的理由:代码大量减少、开发so easy、前后端MIT协议、全部开源、永久免费
📢 唛盟生态
💪唛盟生态遵循 “一个底座+N个专业子系统” 的架构,基于同一个底座的各个专业子系统可以任意组合形成一个大的业务系统。👉聊聊唛盟生态1+n架构
底座 mdp-core
N个专业子系统
| 唛盟子系统 | 说明 | 版本 |
|---|---|---|
| 低代码、0代码 | 低代码、0代码框架 | 3.0.0 |
| 账户、权限、组织管理 | 账户、权限、组织管理,支持多租户 | 3.0.0 |
| 数据模型 | 表结构设计、表数据增删改查等ddl、dml操作,在线执行sql等 | 3.0.0 |
| 第三方支付登录等 | 微信支付、支付宝支付、paypal支付、第三方登录 | 3.0.0 |
| 统一认证中心 | 短信、微信、账号登录 | 3.0.0 |
| 统一流程中心 | 审批、代办、设计流程、监控流程等 | 3.0.0 |
| 短信 | 群发消息 | 3.0.0 |
| 代码生成器 | 自动生成前后端代码 | 3.0.0 |
| 研发项目管理 | 产品管理、需求管理、任务计划、迭代、测试、效能等 | 3.0.0 |
| 即时通讯 | 即时通讯、消息、聊天 | 3.0.0 |
| 财务 | 财务子系统,凭证、报销、会计记账、成本、结算 等 | 3.0.0 |
| 协同办公 | 办公用品、会议、车辆、资产、档案、用印、采购、绩效等功能 | 3.0.0 |
⚙ 技术栈
- 前端
| 框架 | 说明 | 版本 |
|---|---|---|
| Vue | Vue 框架 | 3.3.8 |
| Vite | 开发与构建工具 | 4.5.0 |
| Element Plus | Element Plus | 2.4.2 |
| TypeScript | JavaScript 的超集 | 5.2.2 |
| pinia | Vue 存储库 替代 vuex5 | 2.1.7 |
| vueuse | 常用工具集 | 10.6.1 |
| vue-i18n | 国际化 | 9.6.5 |
| vue-router | Vue 路由 | 4.2.5 |
| unocss | 原子 css | 0.57.4 |
| iconify | 在线图标库 | 3.1.1 |
| wangeditor | 富文本编辑器 | 5.1.23 |
| form-create | 表单引擎+表单设计器 | vue3版 |
- 后端
| 框架 | 说明 | 版本 |
|---|---|---|
| spring boot | spring boot 框架 | 2.6.11 |
| mybatis plus | 数据库操作框架 | 3.5.3.1 |
| spring security | 安全框架 | 2.1.7 |
| jsqlparse | sql解析引擎 | 4.7+ |
| swagger | 接口说明框架 | 2.2.8 |
| logback | 日志框架 | 1.2.3 |
| jexl13 | 表达式引擎 | 3.1 |
| flowable | 流程引擎-可换 | 6.4.2 |
| spring cloud | cloud框架-可换 | 2020.0.0 |
| spring cloud consul | cloud框架-可换 | 1.10+ |
| spring cloud consul | cloud框架-可换 | 1.10+ |
| spring oauth2 | 统一认证中心-可换 | 5.2.2 |
⚙ 开发工具
前端
推荐 VS Code 开发,配合插件如下:
| 插件名 | 功能 |
|---|---|
| node.js | node.js 建议 21.1.0 + |
| pnpm | 类似npm的构建工具 最新版即可 |
| nvm | node版本管理工具,多版本之间切换很好用 最新版即可 |
| TypeScript Vue Plugin (Volar) | 用于 TypeScript 的 Vue 插件 |
| Vue Language Features (Volar) | Vue3.0 语法支持 |
| unocss | unocss for vscode |
| Iconify IntelliSense | Iconify 预览和搜索 |
| i18n Ally | 国际化智能提示 |
| Stylelint | Css 格式化 |
| Prettier | 代码格式化 |
| ESLint | 脚本代码检查 |
| DotENV | env 文件高亮 |
后端
| 插件名 | 功能 |
|---|---|
| idea | java 开发工具 社区版、企业版都可 |
😭 日常项目管理中,您是否有以下痛点?
需求管控困难
- 需求不明确:客户提出一些模糊的需求,这可能导致开发团队对需求的理解存在偏差。
- 信息分散、杂乱:需求可能散落在多个地方,如邮件、Excel表格、即时通讯工具、不同的项目组等无法进行统一管理。
- 需求追溯困难:提出者、评审者、实施人等不明确,导致责任不清、分工不明等问题产生。
- 需求与开发脱节:无法实时跟踪需求完成情况。无法实时定位需求进度落后原因,进而无法做出补救措施。
- 需求与测试不匹配:需求文档与测试用例不匹配导致测试工作无法顺利进行
- 需求变更频发:频繁变更需求,给开发团队带来很大的困扰。
任务管理困难
- 任务分配不明确:任务通过口头或邮件形式进行分配,这可能导致任务责任不明确和任务重叠。
- 任务发布、沟通困难:由于涉及的成员和部门众多,信息同步不及时,很容易导致项目协作混乱。
- 任务进度把控难:缺乏有效的工具来跟踪任务进度,团队成员很难准确把握项目的整体完成情况,也无法针对性地进行调整。
- 任务风险管理不充分:常常忽视任务风险管理,导致项目面临较大的风险。
- 工时统计困难:手动记录工时不仅容易出错,而且难以统计和分析,这不仅影响团队成员的个人成果统计,也影响团队之间的凝聚力和协作效果。
质量管理困难
- 质量标准不明确:缺乏明确的质量标准和规范,导致团队成员对质量要求的理解存在差异,从而影响软件质量。
- 质量保证不到位:导致软件存在缺陷和漏洞,影响用户体验和产品可靠性。
- 测试不全面:缺乏缺陷登记跟踪工具、缺乏测试用例管理工具,导致一些潜在问题未被发现和解决,从而影响软件质量。
- 质量管理与开发流程不融合:质量管理与开发流程相互分离,导致质量管理与开发效率相互影响,难以实现高效的软件开发。
缺乏协作&沟通
- 沟通渠道不统一:在开发团队中,不同的成员可能有不同的沟通渠道,导致信息分散,难以统一管理。
- 沟通不够及时:在开发过程中,有时沟通不够及时,导致一些重要信息滞后的处理,影响了项目进度。
- 沟通不够清晰:由于技术术语或背景知识的不同,团队成员之间的沟通有时不够清晰,导致理解上的偏差。
- 沟通缺乏反馈机制:在沟通中,有时缺乏反馈机制,导致对问题的处理不够及时和有效。
缺乏效能分析
- 缺乏组织级、项目级、产品级、团队级、个人级、迭代级等不同组织级别的效能分析:企业在长期项目实施过程中,未构建起从组织级到个人级的效能分析体系,无法全面掌握企业的项目运作全貌,进而无法有效进行资源调配,利益最大化。
- 缺乏对不同职能部门的多维度的效能分析
- 缺乏风险预警、风险分析
- 项目报告不全面、不准确
- 质量报告不全面、不准确
- 进度计划汇总、分解困难
解决之道
系统概况
系统特点
系统功能
技术架构
应用架构
项目总体管理
需求管理
项目计划
质量管理
迭代管理
效能分析
💪 功能展示
项目立项
项目总体
组织架构
项目报告
需求管理
用户故事
项目计划
项目计划-任务
迭代概览
迭代维护
测试管理
测试报告
缺陷管理
财务费用
驾驶舱
效能分析
燃尽图
每日工作项分布
任务年龄分布
任务排行棒
测试用例规划分析
客户端展示
小程序
审批管理
测试管理
💻 样例项目
- [低代码平台] (https://maimengcloud.com/lcode/)
- [协同办公] (https://maimengcloud.com/oa)
- [项目管理] (https://maimengcloud.com/xm)
⚙ 快速开始
⚠️注意:该项目使用 element plus 版本,所以最低兼容 vue@3.0+ nodejs版本v21.1.0
⚠️注意:强烈建议一定要用pnpm
// 全局安装
npm install pnpm -g
//查看源
pnpm config get registry
//切换淘宝源
pnpm config set registry https://registry.npmmirror.com/
// 使用
pnpm install 包 // 安装依赖
前序准备
- 当前项目属于网页版前端ui项目,后端代码请移步到 xm-backend
开发
# 克隆项目
git clone https://gitee.com/maimengcloud/xm-ui-web.git
# 安装依赖
pnpm install
# 启动服务
pnpm run dev
浏览器访问 http://localhost:8067
登录相关
登录api,对接后台接口有两种方式:
- 对接统一认证中心
VITE_CTX_LOGIN=oauth2client
- 对接mdp-lcode-backend进行登录
VITE_CTX_LOGIN=lcode
图片库、素材库、标签库
内容相关接口默认打包进mdp-lcode,所以内容相关接口可以直接对接lcode即可,如果内容相关的服务使用独立的第三方开源工程,独立部署,比如直接使用 mdp-arc-backend
- 对接mdp-arc-backend
VITE_CTX_ARC=arc
# 配置附件上传的接口,如果不配使用arc内置的地址
VITE_UPLOAD_ATT_URL=
# 配置图片上传的接口,如果不配使用arc内置的地址
VITE_UPLOAD_IMAGE_URL=
- 对接mdp-lcode-backend
VITE_CTX_ARC=lcode
# 配置附件上传的接口,如果不配使用arc内置的地址
VITE_UPLOAD_ATT_URL=
# 配置图片上传的接口,如果不配使用arc内置的地址
VITE_UPLOAD_IMAGE_URL=
前后端对接
开发的时候前后端对接有两种情况:
- 本地运行前端工程、后端工程
此种情况下前端如何把请求转发到本地起的后端工程?主要修改vite.config.js中的代理实现
假设后端mdp-lcode启动,并监听7014端口
['/api/m1/lcode']: {
target: 'http://localhost:7014',
ws: false,
changeOrigin: true,
rewrite: (path) => path.replace(new RegExp(`^/api/m1/lcode`), '/'),
},
['/api/m1/xm']: {
target: 'http://localhost:7067',
ws: false,
changeOrigin: true,
rewrite: (path) => path.replace(new RegExp(`^/api/m1/xm`), '/'),
},
上述代理实现把以/api/m1/lcode 开头的请求地址(举例/api/m1/lcode/user/list)替换为/user/list,并转发到http://localhost:7014地址
上述代理实现把以/api/m1/xm 开头的请求地址(举例/api/m1/xm/user/list)替换为/user/list,并转发到http://localhost:7067地址
- 只启动前端页面工程,后端工程不启动,后端工程使用服务器上的已启动的服务 此种情况下前端如何把请求转发到服务上起的后端服务?主要修改vite.config.js中的代理实现
['/api/m1/lcode']: {
target: '服务器上的ip:7014',
ws: false,
changeOrigin: true,
rewrite: (path) => path.replace(new RegExp(`^/api/m1/lcode`), '/'),
},
['/api/m1/xm']: {
target: '服务器上的ip:7067',
ws: false,
changeOrigin: true,
rewrite: (path) => path.replace(new RegExp(`^/api/m1/xm`), '/'),
},
构建
# 构建测试环境
pnpm run build:test
# 构建生产环境
pnpm run build:prod
发布
假设:
- 应用服务器(sit1-backend),ip为192.168.0.222,端口7067
- 静态资源服务器(sit1-static),ip为192.168.0.111
- 反向代理使用nginx
- 静态资源部署到服务器sit1-static的/data/nginx/html/xm/下
- 本地*ui-web目录在C:/Users/xxx/IdeaProjects/xm-ui-web/
发布静态资源到测试\生产环境
# 1.首先登录sit1-static并进入/data/nginx/html/lcode/下
cd /data/nginx/html/lcode/
# 如果有dist.rar需要先删除
rm -rf dist.rar
# 2.执行rz命令,弹框选择本地dist文件上传到sit1-static服务器
rz
# 3.在弹出的目录选择器中进入C:\Users\xxx\IdeaProjects\xm-ui-web\dist\目录下
全选所有文件->右键->添加到dist.rar->选中dist.rar->上传到服务器商/data/nginx/html/lcode/目录下
# 4.执行解压缩命令,至此静态资源发布完成
unrar x dist.rar
解压后m1目录下一般有css、fonts、images、img、js、tinymce、favicon.icon、index.html等文件或者文件夹
nginx的配置
静态资源的访问映射
location ~*/(mk|mallm|arc|im|sms|workflow|oa|ac|audit|xm|tpa|crowd|lcode) {
root /usr/share/nginx/html;
index index.html;
expires 30d;
}
lcode相关api的映射配置(单体应用方式部署的后端)
upstream api-gate-lcode {
server 192.168.0.222:7014;
}
location /api/m1/lcode/ {
#proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://api-gate-lcode/;
proxy_connect_timeout 65s;
proxy_send_timeout 65s;
proxy_read_timeout 65s;
proxy_next_upstream_tries 1;
}
需要特别注意的是 http://api-gate-lcode/后面的这个/不能省略,带/代表将“/api/m1/lcode/”替换成“/”,再转发上送到目标服务器
同理,其它子系统的api也类似lcode一样配置,比如工作流相关的api可以按如下方式配置
upstream api-gate-workflow {
server 192.168.0.222:7080;
}
location /api/m1/workflow/ {
#proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://api-gate-workflow/;
proxy_connect_timeout 65s;
proxy_send_timeout 65s;
proxy_read_timeout 65s;
proxy_next_upstream_tries 1;
}
api的映射配置(cloud方式部署的后端)
假设 spring cloud gate部署在192.168.0.222,监听6101端口 下面的目标服务器改为cloud gate的地址端口. 注意cloud环境下不需要像单体般每个子系统api单独配置映射关系。因为所有的api都是经过gate再转发的
upstream api-gate {
server 192.168.0.222:6101;
}
location /api/m1/ {
#proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://api-gate/;
proxy_connect_timeout 65s;
proxy_send_timeout 65s;
proxy_read_timeout 65s;
proxy_next_upstream_tries 1;
}
发布后端服务
具体以xm-backend中发布描述为准
运维
日志查询
日常查询问题,主要通过查询前后端日志,分析出具体原因,再进行针对性解决。
唛盟平台具有多个子业务系统,每个子业务系统都有独立日志,一个前端请求,可能日志散落在多个日志文件,如何才能凑齐这些日志,进行统一分析交易执行情况,进而定位问题?
答复:唛盟平台在每个请求到达服务端的时候,会检测gloNo是否存在,如果不存在,则会自动创建一个gloNo,并注入到日志上下文中,并打印到每一行代码中,另外请求结束,还会把gloNo返回到前端,如果交易中间涉及调用其他子系统,同样会自动上送gloNo,对方交易子系统同样执行上诉逻辑。因此,可以看见,gloNo是能够把所有日志串联起来的。我们只需要在日志文件目录下执行grep命令即可找出对应日志
操作步骤:
1.下面是典型的唛盟接口返回的数据结果集 gloNo就存放在res.data.tips.gloNo中。
{
"total" : 1,
"data" : [ {
"bizFlowState" : null,
"deptName" : null,
"projectCnt" : 1,
"admUserid" : "4hinb8m16",
"del" : "0",
"budgetNouserAt" : null,
"productName" : "唛盟云-财务系统",
"baselineId" : "2022-01-01-base-01",
}],
"tips" : {
"msg" : "成功",
"gloNo" : "20240312200013556UWJZKV",
"isOk" : true,
"reqNo" : "20240312200013556JM3WKN",
"tipscode" : "ok"
}
}
- 通过gloNo到logs目录下执行
grep "20240312200013556UWJZKV" *.log
服务状态监控
consule 的默认控制台 http://ip:8500/
有时候微服务需要人为干预进行下架
可以调用/bin/service-deregister.sh进行
日志定时备份清理
可以在crontab中配置定时任务,定时调用bin/clear-log.sh即可完成7天循环自动清理及备份日志
使用举例:
# 打开定时任务编辑器
crontab -e
# 查看定时任务
crontab -l
# 增加定时清理备份日志任务
0 1 * * * /bin/bash /home/mall/bin/clear-log.sh
🔔️ 开发计划与进度情况
3.x.x (当前版本,已完成大部分内容)
- 后端底座提供el表达式沙箱环境,支持前端书写表达式上送后端,为0代码,ai的发展提供基础能力!
- 后端提供无服务,无dao,无实体,无控制层的四无crud通用接口,为实现应用开发部署发布0耗时提供底座能力!
- 提供数据模型子系统,为在线浏览数据,操作数据实体,构建数据集市提供底座基础!提供前端sql执行、sql结果动态展示等,支持在线修改表结构、在线预览结构信息、在线预览修改表数据等ddl、dml能力
- 进一步对ai编程提供一些底座能力
- 提供新版智能表单前后端,支持0代码设计、开发、发布一个表单功能(基于formCreate进行魔改),支持0耗时免部署
- 提供新版工作流编辑器
- 提供智能大屏,智能图表在线构造发布演示基础框架
- 提供任意接口任意字段起调ai,java,计算公式等能力
- 进一步整合lcode,将基础内容管理、数据模型、工作流、系统管理、应用超市(下单、购买、订单管理全套)整合进lcode
- 提供docker版本,免编译快速部署(方便非it人士使用)
- 提供自研单机版内存框架,本地跑不需要集成redis等第三方内存框架,提供redis的适配包,默认打包进bootstrap工程。上线内存管理自动切换到redis
- 重构mdp-ui、mdp-ui-ext各个组件
- 前端公共配置项与VITE公共配置项整合
- 提供内置的图标浏览、选用功能
- 提供图片库浏览、选择图片、管理图片等功能
- 提供附件库浏览、选用、管理等功能
- 提供路由配置导入菜单表功能。(免去手工增删改查菜单的麻烦,升级改造调整菜单不再困难)
- 每个子系统提供单体版、cloud版、oauth2版,版本之间免改代码自由切换。(免去选择困难症)
- 字典功能、平台配置功能提供配置表动态配置功能,无须改改动表结构即可任意添加配置项,彻底告别加配置犯难症
- 字典配置、平台配置支持全面覆盖,无论在ui页面、java后端等提供自动加载、自动分布式分发、同步机制,彻底告别性能忧虑、前后端编码冲突打架的问题
4.x.x (下一版本,让我们一起拥抱ai起飞吧)
- 提供接入大模型能力
- 提供前端任意字段起调ai能力
- 提供ai编程、ai测试、ai编排任务、ai需求整理能力
- 提供ai出报告能力
- 提供ai基于企业私有数字资产自训练能力
🗒️ 版本更新日志
2.0.0-RELEASE
已发布,停更
3.0.0-RELEASE
已发布,持续改进
4.0.0-BETA
预研中
📝 常见问题
本地前后端对接不上
答复:
1.请排查vite.config.ts中的代理是否配置正确,详细配置说明参考前面关于前后端对接的说明;
2.请检查后端服务是否已启动,并查看配置文件关于服务监听端口是否与代理配置的端口一致;
前端pnpm install出现各种编译错误
答复:
1.请排查node的版本是否是前面描述的指定版本;
2.请使用nvm进行node版本管理,具体请看 如何切换node.js版本
前端pnpm install时,下载缓慢如何解决
答复:设置国内镜像
//查看源
pnpm config get registry
//切换淘宝源
pnpm config set registry https://registry.npmmirror.com/
默认登录账户是什么?
答复:账户为: demo-branch-01 密码为: 888888 演示环境大家切勿自行改密码
超级管理员账户是什么?
答复: 账户为: superAdmin 密码为: 888888 演示环境大家切勿自行改密码
数据库脚本在哪?
答复: 数据库脚本一般存放在后端工程下的sql/文件夹下 低代码的xm-backend/xm/sql/lcode.sql
数据库的编码是什么?
mysql的话,建议character set: utf8mb4, collation: utf8mb4_croatian_ci mysql8以上
为什么后端下载下来cloud的相关包报错
答复:因为本地跑不需要cloud环境,cloud相关包是部署到cloud环境才需要的。您可以采取以下两种办法之一解决
办法1. 找到根目录下的pom.xm文件,把cloud的模块注释掉
<modules>
<module>mdp-arc-mate</module>
<module>mdp-arc-pub</module>
<module>mdp-sys</module>
<module>mdp-lcode</module>
<module>mdp-lcode-bootstrap</module>
<!-- <module>mdp-lcode-cloud-bootstrap</module> -->
</modules>
办法2. 下载mdp-cloud-backend工程,进行安装
我只需要研发管理系统,需要看低代码平台么?
答复:需要的,原因:1.研发管理系统采用低代码中的框架开发,各种组件的使用说明,框架的说明介绍等都是放在低代码平台中。2.研发管理系统中的账户、角色权限、组织、字典、菜单等都是直接采用低代码平台的功能,研发管理系统必须结合低代码平台才能算是一个完整的产品。
如何切换node.js版本
答复:请参考以下文章nvm介绍、安装、报错处理以及使用
注意:请用管理员身份打开cmd命令窗口
1.查看本地安装所有版本以及当前使用的版本,有可选参数available,显示所有可下载的版本
nvm list [available]
2.查看到 node 版本后,推荐使用 LTS 中任意一个版本进行安装,命令中版本自定义,例如下
nvm install 21.1.0
3.使用 nvm 进行切换 node 版本使用特定版本
nvm use 21.1.0
为什么唛盟的工程如此分散?
答复:唛盟属于企业级开发平台,企业可以用唛盟开发任何业务系统,在企业内部来讲,最终可能演变成1底座+n个专业子系统的最终形态。唛盟采用1+n架构正是由目前大部分企业的这种形态决定的,唛盟为适应1+n的架构做了最佳的工程划分实践,在很多项目实战中获得了巨大成功。1代表核心底座mdp-core,地位非常重要,任何改动有可能影响所有产品的正确运行,一般由架构师团队维护,不建议开放给各个业务组,所以mdp-core有完全独立开来的需要。n代表各个子系统,子系统之间高内聚,低耦合。每个子系统完全可以独立运行的。在管理上,可能每个子系统属于不同的产品团队或者不同的项目团队进行管理。工程包完全独立,方便管理,避免权责不清,互相交叉等问题。
我只需要某个专业子系统,我能把各个分散的工程合并起来么?
答复:可以的,唛盟设计之初就考虑到了需要具备可合可分的这种灵活性。唛盟采用1+n架构,具体体现为至少有n个jar包,jar包是可以互相引入的,可以在-bootstrap的工程中通过pom引入的方式把他们合并成一个大的发布包。最终发布到服务器的时候,发布一个jar包就可以了。
登录成功后报登录超时,请重新登录
答复:登录成功后,会对统一流程中心发起一次代办查询,如果未部署流程中心,将代办的请求发送到唛盟官网。由于开发者本地跑产生的token是由lcode颁发,对唛盟官网的请求带上的token将被唛盟官网鉴权不通过,报401.开发者需要检查以下配置:
-
vite.config.ts proxy是否配置了默认对唛盟官网请求的保底代理,如有,请删除。
-
如果不需要工作流,将VITE_WF_OPEN设为false,将不再发起代办的请求
以下是需要工作流的情况: -
如果需要工作流,请检查vite.config.ts proxy是否配置了对流程中心的请求代理,如果未配置,请查阅流程整合
-
统一流程中心启动配置项是否将 mdp.jwt.connect-oauth2-server配置为false?
mdp:
jwt:
connect-oauth2-server: false
- 统一流程中心中心的java工程启动项配置是不是未成功?(大部分初学者都是改了配置不生效,属于java工程未正确启动或者未正确编译)
以上自检查确认后未解决问题,打开浏览器控制台截取交易报送信息及返回信息,联系唛盟客服。
本地跑单体需要redis吗?
答复:唛盟底座架构及各子系统默认完全剥离redis,采用自研的CacheHKV缓存框架。如果不需要分布式缓程,理论上不需要引入任何第三方缓存框架。但是CacheHKV设计并不是要真正做缓存框架,而是为了开发调试方便,上生产的时候,建议还是引入真正的缓存框架。
引入redis缓存涉不涉及改代码?
答复:
- 如果CacheHKV提供了足够的api,不涉及改代码,只需要在*-bootstrap打包工程中的pom.xml文件引入唛盟为redis开发的适配包即可。
<dependency>
<groupId>com.mdp</groupId>
<artifactId>mdp-boot-starter-redis</artifactId>
</dependency>
- 如果CacheHKV提供的api无法满足需求,需要使用redis等第三方框架侵入式到代码中,可以在业务工程中的pom.xml引入mdp-boot-starter-redis,可以像普通的用法一样,绕过CacheHKV,直接使用redis的api.
CacheHKV的api能根redis的api混用吗?
答复:可以混用,你可以用CacheHKV put值,通过redis get值,同理,使用redis put值,通过CacheHKV取值也是一样的
菜单如何授权?
答复: 要回答这个问题,首先要理解唛盟菜单的机制。
唛盟菜单机制说明:
- 唛盟菜单是不需要手动创建的,唛盟生态每个子系统内置了菜单自动导入功能,用超级管理登录即可看见
- 唛盟菜单同时支持前端配置菜单、后端配置菜单,两者可以混用,唛盟会进行合并形成最终的展示菜单
- 当然唛盟也同时支持前端授权、后端授权,两者可以混用,唛盟也会进行交叉授权检查,形成最终展示菜单
什么是前端授权
答复: 前端授权即后台不配制任何菜单,前端也可以按自己的菜单授权逻辑控制菜单的显示也否。
前端授权的逻辑是怎么样的?
答复: 前端在路由meta.roles配置角色列表,告诉唛盟平台该菜单属于前端授权菜单。需要进行角色判断才能展示 唛盟将会获取当前登录用户的角色列表与菜单上配置的角色列表进行匹配,匹配到任何一个即放行
{
meta:{
roles:['superAdmin','hrrs']
}
}
什么是后端授权?
答复:后端授权指通过后台配置,将菜单按角色分配,达到控制不同角色能看到的菜单不同的目的 前端框架底层将会按后端返回的菜单做以下操作:
- 前端带有meta.menu=true的路由,如果后端没有返回同名路由,说明该前端路由必须隐藏
- 前端带有meta.menu=true的路由,如后端返回有同名路由,保留前端,剔除后端
- 前端没有meta.menu的路由,默认不做处理,如果后端返回同名,则将后端剔除
- 如果后端返回一个前端没有配置的路由,则需要添加到前端路由中
后端授权需要前端开发做什么?
答复:后端授权需要前端在路由配置中设置 meta.menu=true
{
meta:{
menu:true
}
}
前端授权、后端授权同时配置会如何?
答复: 如果一个菜单既配置了meta.menu=true,同时配置了meta.roles,那么唛盟底层将以后端授权为准,忽略前端授权
超级管理员的授权问题
答复: 超级管理员无视任何授权规则,一律放行
后端动态菜单返回了其它子系统的菜单,如何解决?
答复: 唛盟生态具有多个子系统,每个子系统都是可以导入各自菜单的,因此,势必造成后端菜单扎堆,那么如何进行菜单范围限制呢?
-
在前端配置全局配置项。设定本应用的模块范围,在设定范围内的动态菜单才允许放行,否则忽略
-
如果全局配置为空,则默认全部放行
VITE_MODULE_SCOPE=['模块编号1','模块编号2']
💯 实践案例
项目分支说明
| 分支 | 说明 |
|---|---|
| master | 主分支,3.0.0+,受保护分支,此分支不接受 PR。在 dev 分支后经过测试没问题后会合并到此分支。 |
| 3.0.0-RELEASE | 已发布的版本3.0。 |
| 2.0.0-RELEASE | 已发布的版本2.0。 |
🐞 交流讨论 、反馈 BUG、提出建议等
💲 打赏
感谢所有赞赏以及参与贡献的小伙伴,你们的支持是我们不断更新前进的动力!微信扫一扫,赏杯咖啡呗!

🔔商务合作
| 序号 | 合作项目 | 详细介绍 | 费用说明 |
|---|---|---|---|
| 1. | 打赏获得赞助商名额 | 在赞助商列表展示(添加微信沟通) | 不限额度 |
| 2. | 新组件开发 | 提供组件扩展、优化服务 | 视复杂程度而定 |
| 3. | 开发问题解答 | 如果使用该产品遇到棘手问题需要解决,添加微信进行沟通解决 | 免费 |
| 4. | 开发培训 | 提供开发流程介绍、技术介绍、功能介绍、部署流程介绍,仅限线上培训 | 加微信详聊 |
| 5. | 扩展问题解答 | 如果需要使用该产品进行自有业务系统研发,需要我方提供意见建议,我方收取一定费用后提供相应服务 | 加微信详聊 |
| 6. | 广告合作 | 广告位(精品项目推荐、赞助商展位) | 加微信沟通 |
📢 视频教程(2.**的视频教程)
0.1-唛盟-唛盟生态1+n架构无限扩展、丝滑部署、永不下线
8.2.唛盟-后端工程开发-控制层、服务层、dao层开发详细介绍
10.1-唛盟-复杂查询、多主键crud的实现方案、原理解析
📢工程介绍
⚠️工程分类:主体工程、基础配套工程、高级配套工程、拓展应用工程、辅助开发工具五大类。
主体工程:本系统业务工程,用于书写本系统相关的业务代码;
基础配套工程:业务工程运行所需的必要工程;如开发底座,系统管理相关功能包
高级配套工程:高级应用,比如需要将业务工程接入oauth2环境、将业务工程发布到cloud环境,才需要下载安装高级配套工程
拓展应用工程: 基于唛盟低代码平台拓展的应用工程,其后端可以单体发布,也可以以微服务方式发布,也可以打成jar被唛盟其它应用引入
辅助开发工具:指开发用到的一些工具
⚠️工程命名规范:业务名称+工程属性
工程属性如下:
-ui: 页面工程
-web: pc端运行的浏览器工程
-backend: 后端服务
-app: 安卓、ios等原生app工程
-uniapp: 基于uniapp开发的应用
-minapp: 小程序
-cloud: 微服务cloud环境
-oauth2: 统一认证中心
-bootstrap: 打包部署工程
唛盟主体工程
唛盟属于前后端严格分离的一套系统,分为前端工程、后端工程两部分
- mdp-lcode-ui-web 唛盟的前端工程,以vue.js为主
- mdp-lcode-backend 唛盟的后端工程,java语言为主
基础配套工程
- mdp-core 启动后端的话必须先安装此工程
该工程作为所有后端的公共封装,不包含任何的业务功能,仅作为后端系统的技术底座,包含一些公共工具、服务类抽象、dao层抽象等。
高级配套工程
-
mdp-cloud-backend 非必须
该工程作为spring cloud的扩展工程,如果需要将系统发布到spring cloud环境,需要下载该工程重新打包,不包含任何的业务功能,仅作为后端接入cloud环境使用 -
mdp-oauth2-backend 非必须
该工程为统一认证中心,作为spring oauth2的扩展工程,如果需要将系统接入oauth2环境,需要下载该工程重新打包,该工程实现分布式单点登陆;支持微信、支付宝、短信、账户密码等多种登陆方式
开发辅助工具
- mdp-code-generator 非必须 代码生成器
生成代码两种方式,
一、使用代码生成器本地工程,好处是代码可以直接覆盖到本地业务工程,避免复制黏贴出错。
二、如果不需要本地生成代码,也可以在低代码平台在线生成。在线生成代码
拓展应用工程
- 拓展应用工程: 基于唛盟低代码平台拓展的应用工程,其后端可以单体发布,也可以以微服务方式发布,也可以打成jar被唛盟其它应用引入






































