尧图网页设计 
简介基于 QCADOO 的开源 MES 生产制造管理系统聚焦制造执行与车间数字化管理适用于机加工、食品包装、制鞋、服装及离散制造等企业场景既可作为企业信息化选型参考也适合 MES 二次开发工程师、Java 后端开发者研读其模块划分与业务设计。压缩包内共约 2000 个文件主体为约 1090 个 Java 源码、595 个 XML 配置、118 个 JavaScript 逻辑、88 个 properties 配置另有 54 个 JSP 页面、40 个 CSS 样式及少量 SQL、Shell 脚本Java 部分对应业务服务与实体层XML 多用于 Spring/QCADOO 模块装配前后端与部署脚本齐备整体约 37.7MB目录层级完整便于按功能模块检索。前端资源覆盖 Bootstrap、QCadOO 主题等样式文件适合从界面交互到后端服务做系统性阅读。当前已有 150 人学习浏览借助该资源可快速形成对 QCADOO 技术栈与 MES 常见业务模块的认识也能为搭建测试环境、梳理生产工单、排产、报工等核心流程提供直接代码参考。1. QCADOO 与开源 MES这套生产制造管理系统能解决什么QCADOO 是一套能直接部署的 Java 开源 MES制造执行系统。我最早盯上它是因为手头接了条第三方机械加工线的排产改造上 ERP 太重Excel 又压不住车间里的纸质工单和补料流程而 QCADOO 恰好把生产订单、工艺路线、BOM、报工、质检这些离散制造最常见的场景都做成了开箱即用的模块。它的名字在源码包和部署文档里常写作小写 qcadoo检索时两种拼写都能命中不影响下载和编译。这套资源适合三类人刚接手工厂信息化、想用一个真实 MES 源码做基线而不是从零造轮子的实施工程师需要研究生产模块数据结构的开发以及要在开源基线之上做二次开发的团队。正文按我实际拆机的顺序展开先讲选型理由再给部署步骤和二次开发的最小改动最后是排查清单和一条验证数据打通的技巧。2. 选型理由为什么把 QCADOO 当 MES 底座而不是从零搭建选型我不看框架热不热只看两件事业务模型是不是现成的改动有没有边界。QCADOO 这两点都占——它不是一个后台脚手架而是一套把制造执行逻辑做进数据模型的开源 MES。下面从技术骨架、业务模块、以及和若依风格 MES 的差异三个角度说清楚。2.1 技术骨架Spring MVC Hibernate 模块化插件QCADOO 的整体结构是经典 Java EE 那套打法Spring MVC 处理请求Hibernate 管理 ORM前端以服务端渲染为主工程用 Maven 做多模块构建。核心包负责用户、权限、菜单和插件注册业务功能全部挂在独立插件里这种组织方式和很多后台管理脚手架完全不同——它从一开始就把「业务怎么扩展」设计成了主线。我一般会把这种技术栈理解为「稳」而不是「旧」。车间现场的部署环境往往相当保守JDK 8、Tomcat 8.5、MySQL 5.7 的组合在工厂里大量存在QCADOO 就正好跑在这套组合上。生产环境里要观察服务性能SkyWalking 这类 APM 也可以按 javaagent 方式挂到 Tomcat 进程中不需要改业务代码这说明它的部署模型和主流 Java 监控体系是兼容的。对实施方来说这意味着你招到的普通 Java 工程师就能维护不用养一支专门的前端团队。插件机制是另一个值得细看的点。QCADOO 的每个业务域都是一个独立插件插件之间通过声明依赖来协作而不是互相硬编码调用。这意味着你替换某个模块时影响面被限制在插件边界内不至于动一处崩全局。我见过不少团队因为业务代码耦合太重改个报工逻辑连带把订单查询弄挂了在 QCADOO 的插件结构下这种翻车概率会低很多。2.2 核心业务模块从订单到报工的主链路QCADOO 覆盖的业务域并不追求大而全而是把离散制造最核心的几件事做扎实。下表是我拆包后整理的主链路模块对应关系模块核心数据对象解决什么生产订单Orders订单号、数量、交期、状态把计划指令转成车间可执行任务技术工艺Technology工序序列、操作工时、工作中心定义一件东西怎么做物料与 BOM物料档案、子件清单、替代料做之前先判断料齐不齐工作中心与机器设备档案、班次、产能知道活该派给哪台机器报工登记工单、数量、操作工、时间采集真实生产进度质量检验检验计划、检验结果、不合格品拦截不良品流出这条主链路是 MES 的命根子创建生产订单绑定技术工艺判断物料齐套把订单派发到具体工作中心操作工执行后报工最后完工入库。每一步在前一个环节没走完之前是走不下去的比如订单没绑工艺报工时就拿不到标准工时物料不齐套派工就会被卡住。数据模型这样设计的好处是你在界面上看到的状态流转背后数据库里每一步都有对应记录后续做报表或者追溯都有据可查。我拆包时最看重的是报工这一环。很多 MES 系统排产做得花哨但车间根本不报工系统里的进度全是假的。QCADOO 把报工作为独立模块并且出现在操作工桌面上这决定了它是个能落地的系统而不只是计划员的电子表格。2.3 与若依框架 MES 这类国内方案的差别最近检索「若依框架 MES」的开发者和实施方特别多这里客观做个对比方便你判断选哪条路。若依框架在国内流行是因为 Spring Boot MyBatis Vue 的组合开发效率高社区里也涌现了大量基于若依的 MES 项目页面风格统一、CRUD 上手快、权限体系完整如果你要快速搭一个内部工具原型若依系确实是最省力的选择。但两者的定位有本质差异。若依系 MES 是从「后台管理系统」长出来的技术底座是通用管理功能业务模型比如工艺路线、工序、报工记录、物料齐套这些大多需要二次开发自己设计QCADOO 反过来技术底座是老的但制造业务模型是现成的工序、技术、报工、质检之间的关联已经建模好了。对比维度QCADOO若依框架 MES技术栈Spring MVC Hibernate JSPSpring Boot MyBatis Vue页面形态服务端渲染适合内网老环境前后端分离前端工程自成一套业务模型工序/工艺/报工/质检预置通常只有基础管理功能业务需自建上手路径先理解既有模型再按插件扩展先搭页面再设计数据表适合场景机械加工、电子装配等离散制造快速内部系统、中小型工厂管理我的判断是如果你要的是一套能直接演示业务闭环的 MES 源码QCADOO 的基线价值更高如果你主要任务是给客户快速做定制界面若依系更顺手。两条路我都走过没有谁碾压谁只有谁更贴合你手上的项目阶段。3. 本地部署把源码包跑成一套能点开界面的 MES 环境拿到源码包后我习惯先把三件事做在前面数据库建库、编译配置、权限初始化。顺序别乱否则后面报错时你会分不清是环境问题还是代码问题。这一章按实际操作的顺序来每一步都给命令和参数说明。3.1 环境准备与数据库初始化我部署时用的环境组合是 JDK 8 Maven 3.6 Tomcat 8.5 MySQL 5.7这套组合兼容性最省心。如果你手上是 MySQL 8.0也能跑但驱动和账号认证要额外处理这在第 5 章避坑清单里会展开。环境版本建议如下表环境项建议版本备注JDK1.8高版本 JDK 可能遇到反射权限问题Maven3.6 及以上依赖下载需要能访问中央仓库Tomcat8.5 或 9.08.5 最稳9.0 也能用MySQL5.7 优先8.0 需处理认证插件兼容数据库初始化是关键的第一步。我一般先在 MySQL 里建一个独立库和独立账号不跟其他系统共用方便后续排查和备份# 创建数据库字符集用 utf8mb4避免中文乱码 mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS qcadoo_mes DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 创建专用账号密码按项目规范设置 mysql -uroot -p -e CREATE USER mes_userlocalhost IDENTIFIED BY Mes2024; GRANT ALL PRIVILEGES ON qcadoo_mes.* TO mes_userlocalhost; FLUSH PRIVILEGES; # 导入源码包自带初始化脚本具体路径以包内 README 为准 mysql -umes_user -p qcadoo_mes ./doc/sql/init.sql第一句是把库的默认字符集钉死成 utf8mb4这一步不做后面界面和报表全是问号。第二句是权限最小化只给一个库的全权限不授予全局权限。第三句导入初始化脚本脚本里会建表、插入默认菜单和初始账号不同版本脚本路径不一样我见过放在 doc/sql 下的也见过放在 db 目录下的解压后先花两分钟找一下。初始化脚本执行完用SHOW TABLES;随便确认几张核心表是否生成比如订单表、用户表。这一步能帮你区分后续启动报错到底是脚本没跑成功还是启动过程本身有问题。3.2 Maven 打包与运行参数说明数据库就绪后进入源码目录做编译打包。注意先看根目录有没有build.properties或jdbc.properties这类配置文件QCADOO 不同分支的配置位置有差异找到后确认数据库连接指向jdbc.drivercom.mysql.jdbc.Driver jdbc.urljdbc:mysql://127.0.0.1:3306/qcadoo_mes?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai jdbc.usernamemes_user jdbc.passwordMes2024 hibernate.dialectorg.hibernate.dialect.MySQL5InnoDBDialect hibernate.hbm2ddl.autovalidate连接串里serverTimezoneAsia/Shanghai必须显式写MySQL 8 驱动对时区敏感不写会直接报时间戳异常characterEncodingutf8配合建库时的 utf8mb4保证中文在传输层不乱码。hibernate.hbm2ddl.autovalidate这行我先设置为 validate意思是启动时只校验表结构和实体是否匹配不动已有表结构不加任何 create 行为这一步能避免不少数据丢失的风险。配置没问题后开始编译打包# 跳过测试打包测试用例在网络不通的环境下经常卡住 mvn clean install -DskipTests # 打出来的 war 包一般在各模块 target 目录下 # 找到核心 Web 模块的 war 包后复制到 Tomcat 的 webapps 目录 cp qcadoo-web/target/qcadoo-web.war /opt/tomcat8.5/webapps/clean install会先把旧的编译产物清掉再重新构建-DskipTests跳过测试执行但保留测试代码编译这个参数在离线环境几乎必用。依赖下载慢时把 Maven 的settings.xml镜像换成阿里云的公共仓库速度会快很多。war 包放进webapps后启动 Tomcat日志里出现Server startup in [xxxx] milliseconds就说明部署成功然后按http://服务器IP:8080/qcadoo-web访问。启动日志建议从头到尾扫一遍 WARN 和 ERROR尤其是 Hibernate 打印的建表或校验错误。如果卡在数据库连接上优先回看 3.1 的账号权限和 3.2 连接串两个点不要急着翻代码。3.3 第一次登录与角色权限配置系统跑起来后第一件事是找默认管理员账号。这个账号通常在初始化 SQL 里有对应的插入语句在sql或db目录下执行grep -i admin init.sql就能看到初始密码部分发行版在 README 里直接写明。拿到后登录立刻去用户管理里把默认密码改掉。QCADOO 的权限控制到菜单级和操作按钮级角色是权限分配的单位。我按常见工厂组织方式维护四个角色角色典型职责开放菜单建议管理员系统配置、插件管理、用户权限全部菜单计划员建生产订单、维护工艺、排产订单、工艺、物料、工作中心车间操作工报工、看任务报工登记、我的任务质检员检验、不合格处理质量检验、不合格品建议先配一个计划员和一个操作工账号把订单到报工的流程在界面里完整走一遍验收部署是否正确。很多部署问题直到做业务单据时才会暴露比如某张表没初始化成功或者某个插件没启用提前走通主链路能节省后面大量的排查时间。提示不要用默认管理员账号直接在车间终端上登记业务单据管理账号和操作账号混用会导致后期数据追溯混乱。4. 二次开发新增一个物料扩展模块并接进订单流程部署只是入场二次开发才是把 MES 用顺的关键。开发前要先理解它的扩展规则而不是直接在核心包里加页面。这一章按我实际做过的一个物料档案扩展为例讲插件声明、页面挂载、数据打通三个层面每一步给最小可运行的结构。4.1 插件机制先搞清 QCADOO 的扩展点QCADOO 的插件本身是一个带声明文件的模块核心包里有一个插件注册器启动时扫描各插件的声明文件把插件暴露的扩展点挂到系统里。新增业务模块时我会先建一个独立模块目录然后在src/main/resources下放插件声明文件结构示意如下!-- plugin.xml插件声明描述插件身份和依赖 -- plugin namemes-material-extension/name authoryour-team/author version1.0.0/version description物料档案扩展插件/description dependencies !-- 依赖订单插件因为后面要读取生产订单数据 -- dependency pluginqcadoo-mes-orders/plugin version1.0.0/version /dependency /dependencies /pluginname是插件唯一标识后续在插件管理界面里看到的就是这个名字dependencies声明依赖的其他插件系统启动时会先加载被依赖的插件保证你调用的 service 已经存在。依赖关系写清楚能避免模块加载顺序不确定导致的空指针。插件机制的意义在升级时体现得最明显核心包升级时你的扩展插件只要不越过依赖声明的接口边界理论上不需要改动。这就是前面说的「改动有边界」在工厂项目里非常重要——客户生产不能停升级不能靠赌。4.2 自定义页面Controller 模板的最小改动页面部分还是顺着 Spring MVC 的老路子走。我一般在一个插件包里新建 Controller用它处理列表查询和页面跳转。最小结构的代码如下// MaterialController.java物料列表页面的入口 Controller public class MaterialController { // 业务处理放到 service 层不在 Controller 里写 SQL Autowired private MaterialService materialService; // 映射 URL/material/list RequestMapping(/material/list) public String list(Model model) { // 查询所有物料塞进 Model 供页面渲染 ListMaterialVO materials materialService.listAll(); model.addAttribute(materials, materials); return material/list; } }RequestMapping定义访问路径返回值material/list对应模板目录下的material/list.jsp文件Model是 Spring MVC 向页面传数据的标准方式页面里直接用 EL 表达式读取。这里的关键是把所有数据查询放在 service 层不要直接在 Controller 里操作 Hibernate 的 Session否则事务边界不好控制。对应的 JSP 模板写一个简单的遍历渲染% page languagejava contentTypetext/html; charsetUTF-8 pageEncodingUTF-8% !-- 引入 JSTL 标签库用于循环和条件判断 -- % taglib prefixc urihttp://java.sun.com/jsp/jstl/core % ul !-- 遍历 Controller 传过来的 materials 集合 -- c:forEach varm items${materials} li${m.code} - ${m.name} - ${m.spec}/li /c:forEach /ul页面渲染完成之后要到系统菜单管理里给这个页面挂一个菜单项权限才能落到角色头上。这一步很多第一次做二次开发的人会漏结果页面能直接访问 URL但在菜单里看不到车间操作工就认为功能没做。4.3 与订单工艺数据打通调用既有 Service物料扩展插件最终要接进业务主链路才能发挥作用。QCADOO 的数据模型里生产订单、技术工艺、工作中心是关联实体通过 service 接口就能串起来。我写过一段读取订单、工艺、工作中心的逻辑结构如下// 1. 按生产订单号查询订单 ProductionOrder order productionOrderService.getForField(number, MO-2024-0001); // 2. 通过订单关联的技术工艺拿到工序列表 Technology technology order.getTechnology(); // 3. 遍历每个工序取出工作中心和标准工时 for (Operation op : technology.getOperations()) { Workstation workstation op.getWorkstation(); BigDecimal standardHours op.getOperationTime(); // 这里可以做物料齐套判断或者按产能计算计划排到哪台机器 }这段代码展示了数据怎么在业务对象之间跳转先按订单号定位订单订单对象内部关联了技术工艺工艺对象又关联了工序列表每个工序指向一台工作中心。这种关联是 Hibernate 实体关系在起做作省掉了大量手写 JOIN。实际开发时要注意事务边界。getOperations()这类关联对象通常是懒加载的只有在事务内访问才会正常初始化如果事务已经提交你再取关联集合会抛 LazyInitializationException。我一般的做法是在 service 层把要用的数据都在事务内取出来封装成 VO 再返回给 Controller不要等数据出了 service 再访问关联属性。5. 避坑清单部署和二次开发中反复出现的五个问题这一章是我在 QCADOO 上实际踩过的坑每条都是现象、原因、解决三件套。提前看完能省至少两天现场调试时间。五条里前三条属于部署必踩后两条属于二次开发和数据管理的高频问题。5.1 数据库连接失败多数是老驱动撞上 MySQL 8现象启动时报Communications link failure或者登录界面的数据库认证直接Access denied for user。原因QCADOO 部分源码包自带的老版 MySQL 驱动对 MySQL 8 的默认认证插件caching_sha2_password不兼容老驱动不认新认证方式另外 MySQL 8 对时区敏感连接串里没写serverTimezone也会报连接异常。解决先把驱动升级到 8.x 的mysql-connector-java再把数据库账号的认证方式改掉-- 把 mes_user 的认证方式改成老驱动能识别的 mysql_native_password ALTER USER mes_userlocalhost IDENTIFIED WITH mysql_native_password BY Mes2024; FLUSH PRIVILEGES;同时确认连接串里已经带serverTimezoneAsia/Shanghai。这三个动作按顺序做前两个解决认证问题第三个解决时区问题。我见过有人只改认证没改连接串结果报错从 Access denied 变成了 SQLException 时区异常其实就是没改全。5.2 登录后左侧菜单空白插件注册流程没走完现象管理员账号能正常登录但左侧菜单缺模块或者某个业务页面访问时提示找不到。原因插件在启动时没有完成注册。常见场景是初始化脚本执行后数据库里的菜单表没有同步插入对应记录或者插件市场的启用状态是关闭的业务模块压根没挂载到系统里。解决先去插件管理界面看一眼对应插件的状态如果是停用状态直接启用如果是启用状态但菜单还是缺去数据库对比初始化脚本里的菜单插入语句确认目标表确实有数据。排查完还要重启一次服务让插件注册过程完整跑一遍启动日志里出现插件名称的加载记录才算真正注册成功。这一步没有任何捷径只能按插件加载日志逐条核对。5.3 报工保存报乐观锁冲突事务太长是元凶现象多个车间终端同时报工时偶发性出现ObjectOptimisticLockingFailureException重试一次就成功但频率上来之后影响操作工体验。原因报工不只是写一条记录它同时更新订单进度、库存数量、工时统计甚至质量状态一个事务里持锁时间太长两个事务同时操作同一张订单就容易撞版本号。解决把报工的写操作拆分成两个短事务主事务只写报工记录和订单状态库存更新放到后续异步任务或者独立事务里执行在业务层加失败重试机制捕获乐观锁异常后重放当前请求而不是直接报错。我习惯给报工接口加最多三次重试对车间操作工来说感知不到中间发生了什么但对数据库而言锁竞争压力大幅下降。5.4 中文全变问号三个环节各查一次现象界面上中文正常但数据库存进去变成??或者反过来数据库正常、页面显示乱码。原因字符集问题在 Java Web 应用里通常是三个环节之一断了Tomcat 接收请求时的编码、JDBC 连接传输编码、数据库表自身的字符集。这三个环节没有全部统一成 UTF-8就会出现乱码。解决三处都检查一遍。Tomcat 的server.xml里给 Connector 加上URIEncodingUTF-8JDBC 连接串里已经写了characterEncodingutf8就说明传输层没问题数据库表和字段的字符集统一为utf8mb4。排查顺序我建议从数据库往上游走先用 SQL 客户端直接插入中文测试如果库里正常问题就在 Tomcat 或应用层如果库里就是问号回退查建库脚本。5.5 重启后业务数据被「重建」Hibernate 自动建表背锅现象重启服务后某些表的数据被清空或者表结构被改回初始状态看起来像数据丢失。原因开发环境里有人把 Hibernate 的建表策略配置成了create或create-drop这个配置在测试时很省事每次启动都重建表结构但放生产环境就是灾难——业务数据会随着重启被清得干干净净。解决把配置文件里的hibernate.hbm2ddl.auto改成validate或none新增字段或表一律通过独立的 SQL 变更脚本来管理而不是依赖 Hibernate 自动同步。这个坑我唯一一次遇到就是客户重启了 Tomcat 后一周的报工记录全部消失从那以后我接手任何 Java 项目第一件事就是检查这个参数。6. 收尾技巧用一条查询验证报工数据是否真正打通MES 项目验收的第一关不是界面好不好看而是订单计划数、报工数、入库数对得上对不上。很多系统上线时说好了数据打通结果车间操作工报工走的是另一个流程系统里数字全是摆设。我每次做完二次开发都会用一条 SQL 直接到业务库里核对数据不依赖界面避免被页面上的假状态骗过去。查询思路是把生产订单主表和报工明细表做 LEFT JOIN按订单号聚合报工数量然后拿报工总量减去订单计划量。差值为零说明这个订单的报工和计划是一致的差值不为零说明存在漏报、多报或者未完工需要点开明细看具体是哪台机器、哪个操作工在哪个时间点出了问题-- 表名以你初始化 SQL 生成的实际结构为准这里是逻辑示意 SELECT o.number AS order_no, o.planned_qty AS plan_qty, COALESCE(SUM(r.quantity), 0) AS reported_qty, COALESCE(SUM(r.quantity), 0) - o.planned_qty AS diff_qty FROM orders o LEFT JOIN production_reports r ON r.order_id o.id GROUP BY o.number, o.planned_qty HAVING diff_qty 0;这条查询的价值在于把「超产」和「漏报」同时暴露出来。计划 100 件报了 120 件说明报工逻辑里有漏洞比如退货或者报废没扣减计划 100 件只报了 80 件说明这个订单还卡在生产中可以去报工明细里看最后一条记录停在哪个工序。验证通过的标准是任意随机抽三个订单界面上显示的订单状态和这条 SQL 的结果完全一致才算真正的数据打通。我第一次交付 QCADOO 项目时就跳过了这个验证结果车间实际做了 148 件系统还显示完工状态客户在周会上直接拿纸质工单对数据场面相当难看。从那以后我每次交付前都强制自己走一遍这个核对抽单、对数量、查状态三项对上才算完。这个习惯帮我挡住了至少三次潜在的验收翻车希望帮到你。本文还有配套的精品资源点击获取 QCADOO开源MES实战指南：Java制造执行系统的部署与二次开发
简介基于 QCADOO 的开源 MES 生产制造管理系统聚焦制造执行与车间数字化管理适用于机加工、食品包装、制鞋、服装及离散制造等企业场景既可作为企业信息化选型参考也适合 MES 二次开发工程师、Java 后端开发者研读其模块划分与业务设计。压缩包内共约 2000 个文件主体为约 1090 个 Java 源码、595 个 XML 配置、118 个 JavaScript 逻辑、88 个 properties 配置另有 54 个 JSP 页面、40 个 CSS 样式及少量 SQL、Shell 脚本Java 部分对应业务服务与实体层XML 多用于 Spring/QCADOO 模块装配前后端与部署脚本齐备整体约 37.7MB目录层级完整便于按功能模块检索。前端资源覆盖 Bootstrap、QCadOO 主题等样式文件适合从界面交互到后端服务做系统性阅读。当前已有 150 人学习浏览借助该资源可快速形成对 QCADOO 技术栈与 MES 常见业务模块的认识也能为搭建测试环境、梳理生产工单、排产、报工等核心流程提供直接代码参考。1. QCADOO 与开源 MES这套生产制造管理系统能解决什么QCADOO 是一套能直接部署的 Java 开源 MES制造执行系统。我最早盯上它是因为手头接了条第三方机械加工线的排产改造上 ERP 太重Excel 又压不住车间里的纸质工单和补料流程而 QCADOO 恰好把生产订单、工艺路线、BOM、报工、质检这些离散制造最常见的场景都做成了开箱即用的模块。它的名字在源码包和部署文档里常写作小写 qcadoo检索时两种拼写都能命中不影响下载和编译。这套资源适合三类人刚接手工厂信息化、想用一个真实 MES 源码做基线而不是从零造轮子的实施工程师需要研究生产模块数据结构的开发以及要在开源基线之上做二次开发的团队。正文按我实际拆机的顺序展开先讲选型理由再给部署步骤和二次开发的最小改动最后是排查清单和一条验证数据打通的技巧。2. 选型理由为什么把 QCADOO 当 MES 底座而不是从零搭建选型我不看框架热不热只看两件事业务模型是不是现成的改动有没有边界。QCADOO 这两点都占——它不是一个后台脚手架而是一套把制造执行逻辑做进数据模型的开源 MES。下面从技术骨架、业务模块、以及和若依风格 MES 的差异三个角度说清楚。2.1 技术骨架Spring MVC Hibernate 模块化插件QCADOO 的整体结构是经典 Java EE 那套打法Spring MVC 处理请求Hibernate 管理 ORM前端以服务端渲染为主工程用 Maven 做多模块构建。核心包负责用户、权限、菜单和插件注册业务功能全部挂在独立插件里这种组织方式和很多后台管理脚手架完全不同——它从一开始就把「业务怎么扩展」设计成了主线。我一般会把这种技术栈理解为「稳」而不是「旧」。车间现场的部署环境往往相当保守JDK 8、Tomcat 8.5、MySQL 5.7 的组合在工厂里大量存在QCADOO 就正好跑在这套组合上。生产环境里要观察服务性能SkyWalking 这类 APM 也可以按 javaagent 方式挂到 Tomcat 进程中不需要改业务代码这说明它的部署模型和主流 Java 监控体系是兼容的。对实施方来说这意味着你招到的普通 Java 工程师就能维护不用养一支专门的前端团队。插件机制是另一个值得细看的点。QCADOO 的每个业务域都是一个独立插件插件之间通过声明依赖来协作而不是互相硬编码调用。这意味着你替换某个模块时影响面被限制在插件边界内不至于动一处崩全局。我见过不少团队因为业务代码耦合太重改个报工逻辑连带把订单查询弄挂了在 QCADOO 的插件结构下这种翻车概率会低很多。2.2 核心业务模块从订单到报工的主链路QCADOO 覆盖的业务域并不追求大而全而是把离散制造最核心的几件事做扎实。下表是我拆包后整理的主链路模块对应关系模块核心数据对象解决什么生产订单Orders订单号、数量、交期、状态把计划指令转成车间可执行任务技术工艺Technology工序序列、操作工时、工作中心定义一件东西怎么做物料与 BOM物料档案、子件清单、替代料做之前先判断料齐不齐工作中心与机器设备档案、班次、产能知道活该派给哪台机器报工登记工单、数量、操作工、时间采集真实生产进度质量检验检验计划、检验结果、不合格品拦截不良品流出这条主链路是 MES 的命根子创建生产订单绑定技术工艺判断物料齐套把订单派发到具体工作中心操作工执行后报工最后完工入库。每一步在前一个环节没走完之前是走不下去的比如订单没绑工艺报工时就拿不到标准工时物料不齐套派工就会被卡住。数据模型这样设计的好处是你在界面上看到的状态流转背后数据库里每一步都有对应记录后续做报表或者追溯都有据可查。我拆包时最看重的是报工这一环。很多 MES 系统排产做得花哨但车间根本不报工系统里的进度全是假的。QCADOO 把报工作为独立模块并且出现在操作工桌面上这决定了它是个能落地的系统而不只是计划员的电子表格。2.3 与若依框架 MES 这类国内方案的差别最近检索「若依框架 MES」的开发者和实施方特别多这里客观做个对比方便你判断选哪条路。若依框架在国内流行是因为 Spring Boot MyBatis Vue 的组合开发效率高社区里也涌现了大量基于若依的 MES 项目页面风格统一、CRUD 上手快、权限体系完整如果你要快速搭一个内部工具原型若依系确实是最省力的选择。但两者的定位有本质差异。若依系 MES 是从「后台管理系统」长出来的技术底座是通用管理功能业务模型比如工艺路线、工序、报工记录、物料齐套这些大多需要二次开发自己设计QCADOO 反过来技术底座是老的但制造业务模型是现成的工序、技术、报工、质检之间的关联已经建模好了。对比维度QCADOO若依框架 MES技术栈Spring MVC Hibernate JSPSpring Boot MyBatis Vue页面形态服务端渲染适合内网老环境前后端分离前端工程自成一套业务模型工序/工艺/报工/质检预置通常只有基础管理功能业务需自建上手路径先理解既有模型再按插件扩展先搭页面再设计数据表适合场景机械加工、电子装配等离散制造快速内部系统、中小型工厂管理我的判断是如果你要的是一套能直接演示业务闭环的 MES 源码QCADOO 的基线价值更高如果你主要任务是给客户快速做定制界面若依系更顺手。两条路我都走过没有谁碾压谁只有谁更贴合你手上的项目阶段。3. 本地部署把源码包跑成一套能点开界面的 MES 环境拿到源码包后我习惯先把三件事做在前面数据库建库、编译配置、权限初始化。顺序别乱否则后面报错时你会分不清是环境问题还是代码问题。这一章按实际操作的顺序来每一步都给命令和参数说明。3.1 环境准备与数据库初始化我部署时用的环境组合是 JDK 8 Maven 3.6 Tomcat 8.5 MySQL 5.7这套组合兼容性最省心。如果你手上是 MySQL 8.0也能跑但驱动和账号认证要额外处理这在第 5 章避坑清单里会展开。环境版本建议如下表环境项建议版本备注JDK1.8高版本 JDK 可能遇到反射权限问题Maven3.6 及以上依赖下载需要能访问中央仓库Tomcat8.5 或 9.08.5 最稳9.0 也能用MySQL5.7 优先8.0 需处理认证插件兼容数据库初始化是关键的第一步。我一般先在 MySQL 里建一个独立库和独立账号不跟其他系统共用方便后续排查和备份# 创建数据库字符集用 utf8mb4避免中文乱码 mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS qcadoo_mes DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 创建专用账号密码按项目规范设置 mysql -uroot -p -e CREATE USER mes_userlocalhost IDENTIFIED BY Mes2024; GRANT ALL PRIVILEGES ON qcadoo_mes.* TO mes_userlocalhost; FLUSH PRIVILEGES; # 导入源码包自带初始化脚本具体路径以包内 README 为准 mysql -umes_user -p qcadoo_mes ./doc/sql/init.sql第一句是把库的默认字符集钉死成 utf8mb4这一步不做后面界面和报表全是问号。第二句是权限最小化只给一个库的全权限不授予全局权限。第三句导入初始化脚本脚本里会建表、插入默认菜单和初始账号不同版本脚本路径不一样我见过放在 doc/sql 下的也见过放在 db 目录下的解压后先花两分钟找一下。初始化脚本执行完用SHOW TABLES;随便确认几张核心表是否生成比如订单表、用户表。这一步能帮你区分后续启动报错到底是脚本没跑成功还是启动过程本身有问题。3.2 Maven 打包与运行参数说明数据库就绪后进入源码目录做编译打包。注意先看根目录有没有build.properties或jdbc.properties这类配置文件QCADOO 不同分支的配置位置有差异找到后确认数据库连接指向jdbc.drivercom.mysql.jdbc.Driver jdbc.urljdbc:mysql://127.0.0.1:3306/qcadoo_mes?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai jdbc.usernamemes_user jdbc.passwordMes2024 hibernate.dialectorg.hibernate.dialect.MySQL5InnoDBDialect hibernate.hbm2ddl.autovalidate连接串里serverTimezoneAsia/Shanghai必须显式写MySQL 8 驱动对时区敏感不写会直接报时间戳异常characterEncodingutf8配合建库时的 utf8mb4保证中文在传输层不乱码。hibernate.hbm2ddl.autovalidate这行我先设置为 validate意思是启动时只校验表结构和实体是否匹配不动已有表结构不加任何 create 行为这一步能避免不少数据丢失的风险。配置没问题后开始编译打包# 跳过测试打包测试用例在网络不通的环境下经常卡住 mvn clean install -DskipTests # 打出来的 war 包一般在各模块 target 目录下 # 找到核心 Web 模块的 war 包后复制到 Tomcat 的 webapps 目录 cp qcadoo-web/target/qcadoo-web.war /opt/tomcat8.5/webapps/clean install会先把旧的编译产物清掉再重新构建-DskipTests跳过测试执行但保留测试代码编译这个参数在离线环境几乎必用。依赖下载慢时把 Maven 的settings.xml镜像换成阿里云的公共仓库速度会快很多。war 包放进webapps后启动 Tomcat日志里出现Server startup in [xxxx] milliseconds就说明部署成功然后按http://服务器IP:8080/qcadoo-web访问。启动日志建议从头到尾扫一遍 WARN 和 ERROR尤其是 Hibernate 打印的建表或校验错误。如果卡在数据库连接上优先回看 3.1 的账号权限和 3.2 连接串两个点不要急着翻代码。3.3 第一次登录与角色权限配置系统跑起来后第一件事是找默认管理员账号。这个账号通常在初始化 SQL 里有对应的插入语句在sql或db目录下执行grep -i admin init.sql就能看到初始密码部分发行版在 README 里直接写明。拿到后登录立刻去用户管理里把默认密码改掉。QCADOO 的权限控制到菜单级和操作按钮级角色是权限分配的单位。我按常见工厂组织方式维护四个角色角色典型职责开放菜单建议管理员系统配置、插件管理、用户权限全部菜单计划员建生产订单、维护工艺、排产订单、工艺、物料、工作中心车间操作工报工、看任务报工登记、我的任务质检员检验、不合格处理质量检验、不合格品建议先配一个计划员和一个操作工账号把订单到报工的流程在界面里完整走一遍验收部署是否正确。很多部署问题直到做业务单据时才会暴露比如某张表没初始化成功或者某个插件没启用提前走通主链路能节省后面大量的排查时间。提示不要用默认管理员账号直接在车间终端上登记业务单据管理账号和操作账号混用会导致后期数据追溯混乱。4. 二次开发新增一个物料扩展模块并接进订单流程部署只是入场二次开发才是把 MES 用顺的关键。开发前要先理解它的扩展规则而不是直接在核心包里加页面。这一章按我实际做过的一个物料档案扩展为例讲插件声明、页面挂载、数据打通三个层面每一步给最小可运行的结构。4.1 插件机制先搞清 QCADOO 的扩展点QCADOO 的插件本身是一个带声明文件的模块核心包里有一个插件注册器启动时扫描各插件的声明文件把插件暴露的扩展点挂到系统里。新增业务模块时我会先建一个独立模块目录然后在src/main/resources下放插件声明文件结构示意如下!-- plugin.xml插件声明描述插件身份和依赖 -- plugin namemes-material-extension/name authoryour-team/author version1.0.0/version description物料档案扩展插件/description dependencies !-- 依赖订单插件因为后面要读取生产订单数据 -- dependency pluginqcadoo-mes-orders/plugin version1.0.0/version /dependency /dependencies /pluginname是插件唯一标识后续在插件管理界面里看到的就是这个名字dependencies声明依赖的其他插件系统启动时会先加载被依赖的插件保证你调用的 service 已经存在。依赖关系写清楚能避免模块加载顺序不确定导致的空指针。插件机制的意义在升级时体现得最明显核心包升级时你的扩展插件只要不越过依赖声明的接口边界理论上不需要改动。这就是前面说的「改动有边界」在工厂项目里非常重要——客户生产不能停升级不能靠赌。4.2 自定义页面Controller 模板的最小改动页面部分还是顺着 Spring MVC 的老路子走。我一般在一个插件包里新建 Controller用它处理列表查询和页面跳转。最小结构的代码如下// MaterialController.java物料列表页面的入口 Controller public class MaterialController { // 业务处理放到 service 层不在 Controller 里写 SQL Autowired private MaterialService materialService; // 映射 URL/material/list RequestMapping(/material/list) public String list(Model model) { // 查询所有物料塞进 Model 供页面渲染 ListMaterialVO materials materialService.listAll(); model.addAttribute(materials, materials); return material/list; } }RequestMapping定义访问路径返回值material/list对应模板目录下的material/list.jsp文件Model是 Spring MVC 向页面传数据的标准方式页面里直接用 EL 表达式读取。这里的关键是把所有数据查询放在 service 层不要直接在 Controller 里操作 Hibernate 的 Session否则事务边界不好控制。对应的 JSP 模板写一个简单的遍历渲染% page languagejava contentTypetext/html; charsetUTF-8 pageEncodingUTF-8% !-- 引入 JSTL 标签库用于循环和条件判断 -- % taglib prefixc urihttp://java.sun.com/jsp/jstl/core % ul !-- 遍历 Controller 传过来的 materials 集合 -- c:forEach varm items${materials} li${m.code} - ${m.name} - ${m.spec}/li /c:forEach /ul页面渲染完成之后要到系统菜单管理里给这个页面挂一个菜单项权限才能落到角色头上。这一步很多第一次做二次开发的人会漏结果页面能直接访问 URL但在菜单里看不到车间操作工就认为功能没做。4.3 与订单工艺数据打通调用既有 Service物料扩展插件最终要接进业务主链路才能发挥作用。QCADOO 的数据模型里生产订单、技术工艺、工作中心是关联实体通过 service 接口就能串起来。我写过一段读取订单、工艺、工作中心的逻辑结构如下// 1. 按生产订单号查询订单 ProductionOrder order productionOrderService.getForField(number, MO-2024-0001); // 2. 通过订单关联的技术工艺拿到工序列表 Technology technology order.getTechnology(); // 3. 遍历每个工序取出工作中心和标准工时 for (Operation op : technology.getOperations()) { Workstation workstation op.getWorkstation(); BigDecimal standardHours op.getOperationTime(); // 这里可以做物料齐套判断或者按产能计算计划排到哪台机器 }这段代码展示了数据怎么在业务对象之间跳转先按订单号定位订单订单对象内部关联了技术工艺工艺对象又关联了工序列表每个工序指向一台工作中心。这种关联是 Hibernate 实体关系在起做作省掉了大量手写 JOIN。实际开发时要注意事务边界。getOperations()这类关联对象通常是懒加载的只有在事务内访问才会正常初始化如果事务已经提交你再取关联集合会抛 LazyInitializationException。我一般的做法是在 service 层把要用的数据都在事务内取出来封装成 VO 再返回给 Controller不要等数据出了 service 再访问关联属性。5. 避坑清单部署和二次开发中反复出现的五个问题这一章是我在 QCADOO 上实际踩过的坑每条都是现象、原因、解决三件套。提前看完能省至少两天现场调试时间。五条里前三条属于部署必踩后两条属于二次开发和数据管理的高频问题。5.1 数据库连接失败多数是老驱动撞上 MySQL 8现象启动时报Communications link failure或者登录界面的数据库认证直接Access denied for user。原因QCADOO 部分源码包自带的老版 MySQL 驱动对 MySQL 8 的默认认证插件caching_sha2_password不兼容老驱动不认新认证方式另外 MySQL 8 对时区敏感连接串里没写serverTimezone也会报连接异常。解决先把驱动升级到 8.x 的mysql-connector-java再把数据库账号的认证方式改掉-- 把 mes_user 的认证方式改成老驱动能识别的 mysql_native_password ALTER USER mes_userlocalhost IDENTIFIED WITH mysql_native_password BY Mes2024; FLUSH PRIVILEGES;同时确认连接串里已经带serverTimezoneAsia/Shanghai。这三个动作按顺序做前两个解决认证问题第三个解决时区问题。我见过有人只改认证没改连接串结果报错从 Access denied 变成了 SQLException 时区异常其实就是没改全。5.2 登录后左侧菜单空白插件注册流程没走完现象管理员账号能正常登录但左侧菜单缺模块或者某个业务页面访问时提示找不到。原因插件在启动时没有完成注册。常见场景是初始化脚本执行后数据库里的菜单表没有同步插入对应记录或者插件市场的启用状态是关闭的业务模块压根没挂载到系统里。解决先去插件管理界面看一眼对应插件的状态如果是停用状态直接启用如果是启用状态但菜单还是缺去数据库对比初始化脚本里的菜单插入语句确认目标表确实有数据。排查完还要重启一次服务让插件注册过程完整跑一遍启动日志里出现插件名称的加载记录才算真正注册成功。这一步没有任何捷径只能按插件加载日志逐条核对。5.3 报工保存报乐观锁冲突事务太长是元凶现象多个车间终端同时报工时偶发性出现ObjectOptimisticLockingFailureException重试一次就成功但频率上来之后影响操作工体验。原因报工不只是写一条记录它同时更新订单进度、库存数量、工时统计甚至质量状态一个事务里持锁时间太长两个事务同时操作同一张订单就容易撞版本号。解决把报工的写操作拆分成两个短事务主事务只写报工记录和订单状态库存更新放到后续异步任务或者独立事务里执行在业务层加失败重试机制捕获乐观锁异常后重放当前请求而不是直接报错。我习惯给报工接口加最多三次重试对车间操作工来说感知不到中间发生了什么但对数据库而言锁竞争压力大幅下降。5.4 中文全变问号三个环节各查一次现象界面上中文正常但数据库存进去变成??或者反过来数据库正常、页面显示乱码。原因字符集问题在 Java Web 应用里通常是三个环节之一断了Tomcat 接收请求时的编码、JDBC 连接传输编码、数据库表自身的字符集。这三个环节没有全部统一成 UTF-8就会出现乱码。解决三处都检查一遍。Tomcat 的server.xml里给 Connector 加上URIEncodingUTF-8JDBC 连接串里已经写了characterEncodingutf8就说明传输层没问题数据库表和字段的字符集统一为utf8mb4。排查顺序我建议从数据库往上游走先用 SQL 客户端直接插入中文测试如果库里正常问题就在 Tomcat 或应用层如果库里就是问号回退查建库脚本。5.5 重启后业务数据被「重建」Hibernate 自动建表背锅现象重启服务后某些表的数据被清空或者表结构被改回初始状态看起来像数据丢失。原因开发环境里有人把 Hibernate 的建表策略配置成了create或create-drop这个配置在测试时很省事每次启动都重建表结构但放生产环境就是灾难——业务数据会随着重启被清得干干净净。解决把配置文件里的hibernate.hbm2ddl.auto改成validate或none新增字段或表一律通过独立的 SQL 变更脚本来管理而不是依赖 Hibernate 自动同步。这个坑我唯一一次遇到就是客户重启了 Tomcat 后一周的报工记录全部消失从那以后我接手任何 Java 项目第一件事就是检查这个参数。6. 收尾技巧用一条查询验证报工数据是否真正打通MES 项目验收的第一关不是界面好不好看而是订单计划数、报工数、入库数对得上对不上。很多系统上线时说好了数据打通结果车间操作工报工走的是另一个流程系统里数字全是摆设。我每次做完二次开发都会用一条 SQL 直接到业务库里核对数据不依赖界面避免被页面上的假状态骗过去。查询思路是把生产订单主表和报工明细表做 LEFT JOIN按订单号聚合报工数量然后拿报工总量减去订单计划量。差值为零说明这个订单的报工和计划是一致的差值不为零说明存在漏报、多报或者未完工需要点开明细看具体是哪台机器、哪个操作工在哪个时间点出了问题-- 表名以你初始化 SQL 生成的实际结构为准这里是逻辑示意 SELECT o.number AS order_no, o.planned_qty AS plan_qty, COALESCE(SUM(r.quantity), 0) AS reported_qty, COALESCE(SUM(r.quantity), 0) - o.planned_qty AS diff_qty FROM orders o LEFT JOIN production_reports r ON r.order_id o.id GROUP BY o.number, o.planned_qty HAVING diff_qty 0;这条查询的价值在于把「超产」和「漏报」同时暴露出来。计划 100 件报了 120 件说明报工逻辑里有漏洞比如退货或者报废没扣减计划 100 件只报了 80 件说明这个订单还卡在生产中可以去报工明细里看最后一条记录停在哪个工序。验证通过的标准是任意随机抽三个订单界面上显示的订单状态和这条 SQL 的结果完全一致才算真正的数据打通。我第一次交付 QCADOO 项目时就跳过了这个验证结果车间实际做了 148 件系统还显示完工状态客户在周会上直接拿纸质工单对数据场面相当难看。从那以后我每次交付前都强制自己走一遍这个核对抽单、对数量、查状态三项对上才算完。这个习惯帮我挡住了至少三次潜在的验收翻车希望帮到你。本文还有配套的精品资源点击获取