简介JNPF软件开发平台V3.4.2操作手册面向使用该低代码平台进行应用搭建的开发人员与实施人员帮助其系统掌握从在线开发到系统管理的完整功能链路。手册围绕功能设计展开涵盖表单、列表、流程与结果展示的配置方法并延伸至门户新建、大屏管理、地图与数据源管理、报表设计等模块代码生成部分则讲解功能表单与流程表单的生成路径系统管理部分涉及基础设置、安全设置、第三方设置、系统公告、调度、缓存、日志、监控及菜单权限等内容目录层级清晰便于按模块查阅。资源包共1个PDF文件约40.01MB适合作为日常开发与配置时的案头参考。目前已有1341人学习可作为快速上手与功能查漏的实用依据。1. 拿到一份 260 多页的平台手册先别急着翻目录上周有个做外包的朋友发来一份 PDF说客户甩给他一套低代码平台的部署包附带的操作手册两百多页他翻了一晚上还是不知道从哪下手。我拿过来看了半小时发现问题的关键不在手册厚而在于它是一份“功能字典”而不是“上手路线图”——每个菜单都讲了但没告诉你先配什么、后配什么、哪些配置一旦定下就改不了。这份《JNPF 产品功能使用手册 v3.4.2》就是典型在线开发、代码生成、系统管理、系统权限、工作流程、扩展应用六大块覆盖表单、列表、流程、门户、大屏、报表、数据建模、接口认证、分级管理、流程监控等一整套低代码平台能力。它适合两类人一是拿到平台要做交付的实施和开发二是想基于这套平台做二次开发、把在线设计出来的东西落到代码层的人。下面按“这平台怎么运转 → 怎么跑通第一条业务 → 怎么改”的顺序拆。2. 平台骨架拆解六大模块怎么串成一条业务链2.1 从目录看架构在线开发是入口系统管理是地基把手册目录摊开看六个一级章节其实不是并列关系而是一条有依赖的链路。在线开发第 1 章是业务人员直接接触的入口表单、列表、流程、门户、大屏、报表都在这里拖拽生成代码生成第 2 章是把在线设计的结果导出成可维护的工程代码系统管理第 3 章和系统权限第 4 章是底座数据连接、数据建模、数据字典、菜单权限、组织角色都在这里配工作流程第 5 章是横切能力流程设计器、待办已办、流程监控独立成章扩展应用第 6 章则是官方给的示例集电子签章、邮件、知识管理、订单项目这些现成模板可以直接拿来对照。这个结构透露了一个重要信息在线开发和系统管理是强耦合的。手册 1.1.1 里写得很清楚新建表单时如果没设置数据连接流程新建完成后会自动建表主表以mt功能ID命名子表以ct雪花ID命名。也就是说平台的默认行为是“设计即建表”你拖一个控件、绑一个字段背后就有一张物理表在等你。想自定义表结构就得先去 3.10.2 数据建模里把表建好再回到表单设计里下拉选择。这条依赖关系如果没理清后面全是坑。从技术选型角度看这类平台常见做法是 Java 后端 Vue 前端 MyBatis 持久层数据库支持 MySQL、Oracle、SQL Server 等主流库缓存走 Redis定时调度走 Quartz 或类似方案。手册里 3.4 系统缓存、3.3 系统调度、3.6 系统监控这几节的存在基本印证了这套组合。具体版本手册没写部署前以实际安装包里的依赖清单为准别照搬网上的版本号。2.2 目录结构映射手册章节对应到实际工程虽然这是一份 PDF 手册而不是源码包但它的章节划分和平台工程结构是对应的理解这层映射对二次开发很关键。我按经验把手册章节和典型工程目录对一下手册章节对应工程位置常见做法作用1.1 功能设计前端设计器模块 后端元数据服务表单/列表/流程的在线设计1.2 门户设计门户渲染引擎工作台、首页布局1.3 大屏设计大屏可视化模块数据大屏、地图、数据源1.4 报表设计报表引擎统计报表2 代码生成代码生成器模块在线设计转工程代码3.10 数据应用数据中台模块数据连接、建模、字典、接口4 系统权限权限服务分级、组织、角色、数据权限5 工作流程流程引擎流程设计、待办、监控这张表的价值在于当你在界面上点“新建表单”没反应或者流程发起后数据没写进表你能快速判断问题出在元数据服务、流程引擎还是数据连接层而不是对着两百页目录干瞪眼。2.3 数据建模先行把“自动建表”换成“可控建表”手册默认路径是让平台自动建表但真实项目里我一般建议先走数据建模。原因很直接自动建的表名是mt功能ID、ct雪花ID字段名也是平台生成的后期做报表、做接口、做数据同步时这些名字对人不友好排查问题像看黑匣子。正确顺序是先在 3.10.1 数据连接里配好数据库再到 3.10.2 数据建模里把主表子表建好字段名用业务语义命名然后回 1.1.1 表单设计的基础设置里下拉选择数据连接和表。选择多表时有个必须做的动作配置子表的外键字段和关联主键让主表和子表关联起来。手册图 1-1-6 专门标了这一步单表则跳过。这一步漏了子表数据就挂不到主表上流程发起后主表有记录、子表空着现象很迷惑。-- 数据建模时主表子表的典型结构字段名按业务语义命名 CREATE TABLE biz_order ( id BIGINT NOT NULL COMMENT 主键雪花ID, order_no VARCHAR(32) NOT NULL COMMENT 订单编号, customer_name VARCHAR(64) COMMENT 客户名称, total_amount DECIMAL(12,2) COMMENT 订单总额, status TINYINT DEFAULT 0 COMMENT 状态, PRIMARY KEY (id) ); CREATE TABLE biz_order_item ( id BIGINT NOT NULL COMMENT 子表主键, order_id BIGINT NOT NULL COMMENT 外键关联 biz_order.id, product VARCHAR(64) COMMENT 产品名称, qty INT COMMENT 数量, price DECIMAL(10,2) COMMENT 单价, PRIMARY KEY (id), KEY idx_order_id (order_id) -- 外键必须建索引否则子表查询会拖慢 );上面这段 SQL 不是平台生成的而是我建议在数据建模里手工建的结构。order_id就是手册里说的“子表外键字段”biz_order.id是“关联主键”。建索引这一步手册没强调但子表数据量一上来没索引的关联查询会明显变慢这是血泪经验。字段类型上金额用DECIMAL不用FLOAT主键用BIGINT存雪花 ID都是这类业务系统的常规做法。3. 跑通第一条业务从表单设计到流程发起3.1 表单设计控件、字段绑定和主键策略表单设计是整个平台的起点。进入 1.1 功能设计点左上角“新建表单”先选类型——表单、列表、流程三选一。选“表单”后要配两块基础设置和表单设计。基础设置里填功能名称、选数据连接和表表单设计里从左侧控件区拖控件到画布选中控件后在右侧配属性。关键动作是“控件字段”绑定。手册图 1-1-7 说明有表设计时必须下拉选择关联表的字段名也支持在控件字段里快捷新建字段——点添加弹出字段设置窗口已有字段只读点“新建字段”新增空白行自定义配置。这个设计的好处是不用切到数据库客户端加字段坏处是新建字段的类型和长度如果配错后面改起来要动表结构所以建字段时想清楚。表单属性里有两个配置一旦定下就改不了必须提前决策主键策略雪花 ID 或自增长 ID流程保存后不可修改和并发锁定开启后并发提交走乐观锁。主键策略选错后期数据迁移非常痛苦并发锁定不开多人同时提交同一张单子可能出现覆盖。我的习惯是新项目一律雪花 ID 开启并发锁定前者避免自增 ID 在分库分表时的冲突后者是花小成本买后悔药。// 控件事件脚本示例下拉选择变化时联动其他控件手册图 1-1-15 的场景 // 触发时机控件属性 - 自定义组件事件 - 发生变化时触发 function onChange(value) { if (value a) { // 赋值 a 控件为 1 form.setValue(field_a, 1); } else if (value b) { form.setValue(field_b, 2); } else if (value c) { // c 控件隐藏 form.setControlVisible(field_c, false); } else if (value d) { // d 控件设为必填 form.setControlRequired(field_d, true); } }这段脚本对应手册 1.1.1 第4点的示例平台支持 JavaScript 脚本挂在控件事件上触发时机有“发生变化时”和“失去焦点时”两种。form.setValue、setControlVisible、setControlRequired是这类低代码平台表单 API 的常见命名实际方法名以平台文档为准但逻辑结构一致拿到当前值按分支改其他控件的值、可见性、必填性。表单级事件还有三个钩子——表单加载触发、提交前置触发、提交后置触发提交前置适合做校验拦截提交后置适合做通知或写日志。3.2 列表设计桌面端和移动端分开配新建类型选“列表”时流程是基础设置 → 表单设计 → 列表设计三步前两步和表单一致。列表设计的特殊之处在于桌面端与移动端切换分别设计手册 1.1.2 开头就点明了这一点。同一个功能PC 上要展示的列和手机上要展示的列往往不一样平台允许你分别配列表属性、列表字段、查询字段这个设计很务实。列表这块容易翻车的地方是查询字段和列表字段的对应关系。列表字段决定表格显示哪些列查询字段决定顶部筛选区有哪些条件两者是独立的。常见误操作是只配了列表字段没配查询字段结果用户抱怨“没法按订单号搜”。另外手册 v3.4.2 修订记录里提到“功能设计增加高级查询、行内编辑、列表查询”说明这个版本在列表交互上做了增强行内编辑适合做批量改状态的场景高级查询适合多条件组合筛选。3.3 流程设计节点、审批设置和超时提醒流程类型的功能在表单和列表之外多一层流程设计。手册第 5 章把流程拆成基础信息、表单设计、流程设计三块流程设计器里配节点、连线、审批人、条件分支。v3.4.2 版本新增了超时提醒、异常处理、自动同意、节点变更、流程复活、子表传递这些能力修订记录里写得很明确。流程发起后的数据写入逻辑要特别注意如果表单绑定了数据表流程字段的数据会写入关联表对应字段如果没绑平台自动建表。流程设计里配的审批人支持候选人设置节点事件可以挂脚本子流程支持同步和异步两种模式。异步子流程适合耗时操作比如调外部接口同步子流程适合必须等结果才能继续的场景选错模式会导致主流程卡住或者数据不一致。// 流程节点事件脚本示例审批通过后同步子表合计到主表 // 挂在流程节点的“节点事件”上常见于审批完成后触发 function afterApprove(context) { var orderId context.businessId; // 当前业务主键 var items context.queryList( // 查询子表数据 biz_order_item, { order_id: orderId } ); var total 0; for (var i 0; i items.length; i) { total items[i].qty * items[i].price; // 数量乘单价累加 } context.update(biz_order, orderId, { // 回写主表总额 total_amount: total }); }这段脚本演示的是“子表合计回写主表”的典型场景对应手册里子表合计设置和节点事件的组合用法。context.businessId拿当前流程的业务主键queryList查子表update回写主表。实际 API 名称以平台为准但思路是通用的流程节点事件是业务逻辑的挂载点凡是“审批完要顺手做点什么”的需求优先考虑挂这里而不是改源码。4. 系统管理与权限分级、角色和数据权限怎么配4.1 分级管理 组织架构多租户场景的底座第 4 章系统权限是很多实施人员容易跳过、但后期一定回来补的章节。4.1 分级管理、4.2 组织管理、4.3 岗位管理、4.4 用户管理、4.5 分组管理、4.6 角色管理、4.7 权限管理、4.8 在线用户这一串不是让你全配一遍而是按项目规模选配。单组织项目组织管理 用户管理 角色管理三件套够了。多组织或多租户项目分级管理必须先配它决定数据隔离的边界。手册 v3.3.2 修订记录专门写了“多组织内容的补充更新”v3.4.2 又加了分级管理说明这块是平台重点演进的方向。分级管理的逻辑是上级组织能看到下级组织的数据配错了会出现“A 分公司看到 B 分公司订单”的事故所以配完一定要用不同组织的账号交叉验证。角色管理里有个细节角色成员和角色权限是分开配的。先建角色再往角色里加成员最后给角色配权限。顺序反了不报错但权限不生效排查起来很费时间。4.2 菜单权限四层按钮、列表、表单、数据3.8 系统菜单这一节信息密度很高因为它把权限拆成了四层按钮权限、列表权限、表单权限、数据权限。这四层的粒度是从粗到细的按钮权限控制页面上哪些按钮可见可点比如“删除”按钮只给管理员。列表权限控制列表能看到哪些列比如普通员工看不到“成本价”列。表单权限控制表单里哪些字段可编辑、只读、隐藏v3.4.1 修订记录提到“子表字段权限配置”说明子表字段也能单独控。数据权限控制能查到哪些行比如销售只能看自己跟进的客户。这四层如果只配了菜单可见性而没配数据权限用户能进页面但看到全量数据是权限配置里最常见的漏洞。我的做法是新功能上线前用一个最小权限账号走一遍确认按钮、列、字段、行四个维度都符合预期再放给真实用户。4.3 数据应用连接、建模、字典、接口、认证、同步3.10 数据应用是平台和外部系统打通的枢纽七个子节各有分工数据连接3.10.1配数据库连接数据建模3.10.2建表和管理表结构数据字典3.10.3维护枚举值数据接口3.10.4定义对外接口接口认证3.10.5管接口的鉴权数据同步3.10.6做数据搬运行政区划3.10.7是内置的省市区数据。接口认证是 v3.4.2 新增的说明平台开始重视接口安全。常见做法是给每个外部调用方分配 appKey/appSecret调接口时带签名平台侧校验签名和时间戳防重放。配接口认证时注意密钥不要硬编码在前端走服务端转发。# 数据接口调用示例接口认证开启后的典型请求形态 curl -X POST http://your-host/api/data/order/list \ -H Content-Type: application/json \ -H X-App-Key: your-app-key \ -H X-Timestamp: 1720000000 \ -H X-Sign: computed-signature \ -d {pageNo:1,pageSize:20,status:1}上面是接口认证开启后的请求形态X-App-Key、X-Timestamp、X-Sign是常见的三件套签名一般是对参数排序后拼 appSecret 做哈希。具体头名称和签名算法以平台 3.10.5 的配置为准这里给的是结构参考。调试阶段可以先用平台自带的接口测试工具验证通了再接外部系统。5. 避坑排查五个真实会卡住你的问题5.1 流程发起后数据没进表现象流程能发起、能审批但去数据库查业务表是空的。原因基础设置里没选数据连接平台走了自动建表表名是mt功能ID你以为数据没写其实写进了另一张表或者选了表但控件字段没绑定字段值落不下去。解决先查平台自动建的表mt开头确认数据在不在在的话说明是表选择问题回基础设置改成自定义表并重新绑定控件字段。养成习惯建完表单先去数据库确认表结构和字段映射再往下配流程。5.2 子表数据挂不上主表现象主表有记录子表设计器里也填了数据但保存后子表为空。原因多表设计时没配子表外键字段和关联主键或者配了但字段类型不一致主表主键BIGINT子表外键配成VARCHAR。解决回基础设置检查子表关联配置外键字段类型必须和主键一致数据建模里给外键字段建索引。这个坑我在两个项目里都遇到过第二次是因为复制了旧表结构类型没改。5.3 权限配了但用户还是看不到菜单现象角色权限里勾了菜单用户登录后左侧导航没有。原因菜单权限之外还有“列表权限/表单权限/数据权限”没配或者用户所属组织不在分级管理的可见范围内也可能是角色成员没加对用户实际不在该角色里。解决按“角色成员 → 菜单权限 → 数据权限 → 组织范围”顺序逐层核对。用 4.8 在线用户确认用户当前登录状态退出重登刷新权限缓存。权限缓存不刷新是玄学问题的常见来源。5.4 并发提交出现数据覆盖现象两个人同时编辑同一张单子后保存的把先保存的覆盖了。原因表单属性里并发锁定没开平台没走乐观锁。解决表单属性开启并发锁定。注意这个配置在流程保存后部分属性不可改所以建表单时就要定。已经上线的功能要补只能改表加版本号字段再改配置属于返工。5.5 代码生成出来的工程跑不起来现象第 2 章代码生成导出的工程本地启动报错。原因生成时选的数据库类型、包名、模块名和实际环境不一致或者生成后没改数据库连接配置还指着平台的库。解决生成前把包名、模块名、数据库类型核对一遍生成后先改application配置文件里的数据源再跑。代码生成是“半成品”不是“成品”生成完必须人工过一遍配置和依赖。6. 二次开发从在线设计到可维护代码的落地技巧二次开发的核心矛盾是在线设计出来的东西灵活但难维护手写代码可控但慢。我的经验是分层处理——稳定的基础能力用平台易变的业务逻辑用代码。具体做法上第一步是把代码生成第 2 章当起点而不是终点。功能表单和流程表单生成出来的工程先跑通再按业务拆 service。生成代码里的实体类、Mapper、Controller 是骨架业务校验、复杂计算、外部调用这些往里填。第二步是把在线脚本控件事件、表单事件、节点事件控制在“轻逻辑”范围内超过二十行的脚本就该挪到后端接口前端脚本只做展示联动。第三步是数据接口3.10.4和接口认证3.10.5配合用把平台当 BFF 层外部系统统一走认证接口进来别让外部系统直连数据库。验证方法上我一般做三件事一是用最小权限账号走一遍全流程确认权限四层都生效二是造一批边界数据空值、超长字符串、并发提交压一遍表单和流程三是把代码生成出来的工程在干净环境里部署一次确认不依赖平台运行时的隐式配置。第三件事最能暴露问题很多“本地能跑、服务器报错”都是隐式依赖没剥离。改造场景推荐做法不推荐做法复杂业务校验后端 service 实现表单只做基础必填全塞进表单提交前置脚本外部系统对接数据接口 接口认证外部系统直连数据库报表统计数据建模建视图 报表设计在线脚本里写聚合 SQL流程审批后动作节点事件调后端接口节点事件里写大段脚本有个教训我记了很久早期做项目时图省事把一堆业务逻辑写进表单提交后置脚本结果平台升级后脚本 API 变了几十个表单挨个改改到怀疑人生。从那以后我每次做在线设计都强制自己走一遍“这段逻辑三个月后谁来维护”的检查能落到后端的绝不留在脚本里。希望这份拆解能帮你少走几步弯路手册在手边的时候先看第 2 章和第 3 章把地基摸清再回头玩在线设计顺序对了两百页也没那么吓人。本文还有配套的精品资源点击获取