简介JNPF软件开发平台V3.4.2操作手册是福建引迈信息技术有限公司发布的官方PDF文档面向JNPF平台的技术开发、项目管理和系统运维人员系统讲解在线开发、门户设计、大屏设计、代码生成和系统管理等核心功能模块。内容覆盖表单设计、列表设计、流程设计、结果展示、大屏管理、地图管理、分类管理、数据源管理、功能表单与流程表单生成等开发环节并包含系统配置、系统公告、系统调度、系统缓存、系统日志、系统监控、系统图标与系统菜单等后台管理场景操作步骤清晰可帮助读者快速上手平台并独立完成配置。资源为单个PDF文件大小40.01MB便于查阅与离线学习目前已有1339人学习使用。目录索引结构完整能帮助新手快速定位具体功能模块也能供老用户按需查漏补缺是一份覆盖JNPF各功能点的系统化操作手册。1. JNPF 零代码平台为什么表单保存一下数据库表就自动建好了用过 JNPF 的人第一次都会愣一下在线开发里拖几个控件、配一下字段、点保存一套能增删改查的应用就跑起来了甚至数据库表都是自动创建的。这不是「代码生成器帮你写好了 SQL」而是整个平台的核心机制——元数据驱动的动态建表。设计器只是元数据的编辑器保存动作触发的是数据建模引擎去解析元数据、生成物理表结构。理解这层机制才知道为什么流程表单能绑定数据表、为什么主表叫 mt 开头、为什么子表要用雪花 ID 命名。这套东西在低代码平台里不算新鲜但 JNPF 把它做成了「零代码 可视化 权限体系」的完整闭环。这篇就顺着这条链路拆表单怎么映射成表、列表查询怎么控制、流程引擎怎么跑状态机、以及几个新手最容易翻车的配置坑。2. 表单即表控件、字段与物理表的三层映射机制2.1 主表 mt 功能 ID、子表 ct 雪花 ID 的命名契约回到手册里那个容易被忽略的细节未设置数据连接时流程新建完成后会自动创建数据表主表以mt功能 ID命名子表以ct雪花 ID命名。这个命名规则不是随手定的它是一套「约定优于配置」的契约。mt是 main table 的缩写后面跟的功能 ID 是这条表单元数据在平台内部唯一的标识ct是 child table雪花 ID 保证了在分布式环境下子表名字也不会撞车。这么命名最大的好处是应用的可视化设计界面与底层的物理表之间存在一条稳定的对应关系权限模块、流程模块、列表查询模块都可以通过功能 ID 直接定位到对应的物理表而不需要额外维护一份「表单代码 → 表名」的映射表。如果你自定义数据连接去绑定表也是绑定到「数据建模」模块里已定义好的表本质上是把元数据的落库目标从默认库改成了指定库。我一般会这么理解这套设计JNPF 把「表单布局」「控件字段」「物理表结构」三者解耦但通过元数据把它们串在一起。控件在界面上负责输入控件字段决定数据写到哪一列而物理表由元数据引擎自动生成。这个解耦决定了你后续能做多端显示、能导出导入、能动态加字段因为操作的都是元数据而不是直接改数据库结构。2.2 多表关联外键字段与关联主键的配置语义手册里专门提到「选择多表时需配置子表的外键字段和关联主键使主表和子表关联若选择单表则无需此步骤」。这是很多人第一次做主子表表单时搞不懂的地方。单表时没什么可说的所有控件字段都指向同一张表。多表时JNPF 的处理方式是主表选一张子表选一张然后在子表里指定一个字段作为外键并告诉平台这个外键关联的是主表的哪个主键字段。这条配置最终会落到元数据里生成物理表时引擎会为子表的外键字段建立索引并写入关联关系运行时保存主表数据后拿到主键值再回填到子表的外键列完成主子表数据的串联。值得注意的一个设计JNPF 的手册里特意区分了「副表」和「子表」。副表本质上还是主从关系中的从表但它的字段直接落在表单主体上不需要通过子表格控件嵌套子表则是挂在「设计子表」控件下的表格形式。这两种模式对应不同的 UI 形态和不同的数据写入路径但底层都是通过外键关联到主表主键理解了外键这一层两种设计就不会混。2.3 主键策略与乐观锁并发准确性的两个底层开关表单属性里有几个值得深入看的配置主键策略支持雪花 ID、自增长 ID流程保存后不可修改和并发锁定开启后加乐观锁机制保证数据提交准确性。主键策略为什么不可修改因为流程实例一旦发起流程引擎需要通过业务主键关联流程实例 ID如果主键策略变了历史数据的关联逻辑全乱。雪花 ID 和自增长 ID 的取舍也很直接自增长在单库下性能好、可读性强但分布式或多库环境下会撞雪花 ID 是 64 位整数按时间戳 机器标识 序列号生成不用依赖数据库的自增序列就能保证全局唯一。JNPF 默认用雪花 ID是为了支撑多组织、多数据源部署的场景。并发锁定的实现是典型的乐观锁思路表里加一个版本号字段提交时带上之前读到的版本号更新时检查版本号是否变化。伪代码实现大致是这样UPDATE mt_xxx SET status approved, version version 1 WHERE id #{businessId} AND version #{oldVersion}如果影响行数为 0说明版本号对不上数据已被其他人改过这时平台会拒绝提交并提示冲突。注意这个机制是逐字段比较还是整行版本控制看具体实现但 JNPF 的并发锁定打开后最直接的表现就是「两个人同时改同一条单子后提交的人会失败」——这就是乐观锁在起作用不是系统出错。3. 列表查询的字段白名单与动态 SQL 拼接机制3.1 列表设计三段式基础设置、表单设计、列表设计的串联逻辑列表类型的功能设计手册明确说需要配置三段基础设置、表单设计和列表设计其中基础设置和表单设计与表单类型完全一致。这意味着列表本质上是一个「表单 查询 结果集」的三合一结构。表单负责录入和编辑列表负责展示和筛选基础设置则把两者钉在同一张数据表上。这里的设计要点在于列表设计是桌面端与移动端分开的字段展示、按钮布置、查询区域都可以不一样。原因是移动端屏幕窄不可能把桌面端的密集表格原样搬过去所以 JNPF 让两端各自维护一套列配置但都指向同一套表单元数据。你看到的是两套界面背后是同一份数据这就是平台说的「自动生成可视化应用」的含金量所在。3.2 列表字段、查询字段、高级查询的权限控制与 SQL 生成列表设计里三个关键概念别搞混列表字段决定结果集里展示哪些列查询字段决定顶部搜索区出现哪些条件高级查询是查询字段之外另一个独立的筛选入口。三者的权限控制逻辑各不相同但最终都会汇入同一个查询 SQL 的生成过程。列表字段的机制是字段白名单平台生成查询列表时只取配置的字段没选的字段不查、不展示这在权限上天然安全——你根本没有把敏感字段暴露到前端。查询字段和高级查询则会生成动态 WHERE 条件根据用户输入拼 SQL。常见实现思路是这样public String buildQuerySql(MapString, Object queryParams) { StringBuilder sql new StringBuilder(SELECT * FROM tableName); ListString conditions new ArrayList(); // 只遍历查询字段白名单配置的参数 for (String field : queryFieldWhitelist) { Object value queryParams.get(field); if (value ! null !.equals(value)) { conditions.add(field value ); } } if (!conditions.isEmpty()) { sql.append( WHERE ).append(String.join( AND , conditions)); } return sql.toString(); }注意几个细节查询字段白名单决定了「可被用于查询的列」不是所有列都能筛值非空判断是为了避免用户没输入条件时把所有行都筛掉拼接时用AND连接保证多个条件同时生效。这套机制配合数据权限模块就形成了「可见列 可筛列 行范围」三层过滤数据权限控制到行列权限控制到字段组合起来就是完整的按钮权限、列表权限、表单权限体系。3.3 行内编辑与批量操作的提交回写路径V3.4.2 版本新增了行内编辑能力列表里直接改单元格保存。它的实现路径和表单保存不一样表单走的是完整的数据校验 字段映射逻辑而行内编辑走的是轻量级批量更新接口只更新被修改的列。这背后的取舍值得琢磨。行内编辑的体验好但如果没有并发控制两个人同时改同一行后提交的会静默覆盖。JNPF 在做行内编辑时通常有单元格的版本比对机制如果开启并发锁定否则会出现你在编辑时没觉察到别人改了另一列保存后对方的修改丢了。手册没展开讲这部分但并发锁定在表单属性里已经出现行内编辑理论上同样受乐观锁保护。实际使用时建议开启并发锁定这是低成本换高可靠性的配置。4. 流程引擎的状态机本质从审批流到异常复活机制4.1 流程设计的节点事件与状态流转流程设计在 JNPF 里分三块基础信息、表单设计和流程设计。流程设计里的每一个审批节点本质上是状态机里的一个状态节点之间的连线是状态迁移审批动作同意、拒绝、转办是触发迁移的事件。V3.4.2 新增的「节点事件」是这个状态机的核心扩展点。JNPF 支持在节点上配置事件脚本比如进入节点时触发、离开节点时触发、超时时触发。节点通知也经过了改造通知的对象、内容、方式都可配置。所以流程引擎的职责不只是「把审批单从 A 推到 B」——每一次状态迁移前它都要先执行事件脚本再变更状态再触发后续动作。这样一个节点保存时的伪代码大致是// 节点事件配置示例平台内部逻辑 function onNodeEnter(task) { // 进入节点发通知、初始化审批人、执行前置脚本 sendNotify(task.assignee, 您有新的待办 task.businessName); } function onNodeSubmit(task, action) { // 提交节点执行后置脚本判断下一步路由 if (action agree) { routeToNext(task.nextNodeId); } else { routeTo(task.rejectNodeId); } }这个模型把所有流程控制都收敛到节点与事件上「超时提醒」「自动同意」「节点变更」「流程复活」这些高级功能都是围绕这套事件机制做扩展。理解了状态机你会更容易推断出哪些流程配置能做、哪些做不了。4.2 子表传递与远端数据联动跨流程的数据流转协议流程里有一个容易被低估的功能子表传递。手册里说得很细——开启动作设置后要配置表单在配置表单窗口设置弹窗标题、弹窗类型居中、右侧、弹窗宽度选择数据接口作为远端数据源再把接口参数映射到主表字段最后设置子表内表单字段的映射规则。这条链路做的是「在子表添加数据时从外部接口取数据按匹配条件筛选再按映射规则回填子表」。实际上它定义了一个协议远端接口返回 JSON 数组 → 平台按参数筛选 → 列表字段展示候选数据 → 用户选择一行 → 关联字段映射回子表。整个过程不写一行代码全靠数据接口和映射配置。特别注意「所设目标表单字段会根据映射来源支持接口字段、固定值对应的映射值进行数据填充」这句——映射来源不仅支持接口返回的字段还支持固定值。这意味着你可以通过子表传递实现「选择一条记录自动带上某些固定属性」的效果比如选一个供应商自动填入结算方式。这是 JNPF 从 V3.4.0 开始逐步增强的数据联动能力用好了可以大幅减少人工录入。4.3 超时提醒、自动同意、节点变更与流程复活的实现取舍这几个 V3.4.2 新增的流程能力按实现动机可以分成三组第一组是超时提醒和自动同意。超时提醒依赖定时任务去扫描待办节点超过时限就发通知自动同意是超时后直接按配置的策略同意/拒绝推进节点。这里有个容易踩的点超时计算口径是「进入节点时间」还是「最近一次催办时间」平台手册没细讲我一般建议理解为进入节点时间配置时限时要把节假日因素考虑进去。第二组是节点变更。审批过程中下一个节点是谁改变了流程实例仍然继续走。这个功能在实现上是修改流程实例的「路由表」而不是重建流程所以会同步更新后续节点的审批人。第三组是流程复活。流程实例因为异常被终止后可以重新激活继续走。实现上它依赖两个条件流程实例的状态被标记为可复活而不是彻底删除以及当前节点信息仍然完整。所以流程复活不是万能后悔药如果流程在运行中被改得面目全非复活后的事件脚本执行可能对不上数据这个后面单独讲排查。5. 常见问题排查JNPF 配置中最容易翻车的五个细节5.1 未配置数据连接时表到底建在哪里现象新建表单没有选数据连接直接走流程数据居然没丢但开发库和测试库的表结构不一样。原因JNPF 在没有选择数据连接时会把表建在平台默认的数据库中所以用起来「好像也没问题」。但这意味着你把表结构托管给了默认库后续如果要切换数据源就会涉及数据迁移。解决在基础设置里主动选择数据连接把表结构固定到目标库。表创建后主表名、子表名都已经生成如果希望表名更可读提前规划好功能 ID。注意主键策略在流程保存后不可修改务必在建表之前确认。5.2 并发锁定开启后别人的修改为什么不见了现象两个人同时编辑同一张单据后提交的人提示冲突或者看不到对方改过的内容。原因并发锁定开启后乐观锁机制会在提交时校验版本号版本不一致直接拒绝。看起来是「别人的修改不见了」其实是系统在阻止本次提交——冲突是保护机制不是数据丢失。解决提交失败后重新加载最新数据基于最新版本再做修改。如果业务上确实需要后写覆盖用「强制提交」类操作如果平台提供的话但要谨防数据覆盖的风险。5.3 多端显示不勾选移动端真的看不到这个控件现象PC 端设计好的表单移动端少了一个关键字段用户提交不了。原因控件的多端显示默认是两端都选中的但如果有人调整过取消勾选移动端该控件在移动端就不会渲染字段不在表单里自然提交不了。解决每个控件都检查「多端显示」配置不要假设「默认选中就永远选中」。这类问题排查最快的方式在移动端预览里直接看表单结构缺少哪个控件就回设计器查哪个控件的多端显示勾选状态。5.4 子表合计字段不生效合计只能选特定类型的字段现象子表开启了合计但下拉选字段时找不到想加总的字段。原因合计字段有限制——来源于子表内单行输入、数字输入、计算公式类型的字段。你选了一个下拉框或者日期控件它不会出现在合计字段候选里。解决把需要合计的业务字段设计成数字输入或计算公式控件。计算公式的维护在控件属性里计算逻辑用其他字段做运算然后合计设置里选这个计算字段。5.5 流程复活后的事件脚本执行对不上当前数据现象流程复活后某个节点的通知没有发出去或者自动同意策略没有按预期生效。原因流程复活时流程实例的当前节点已经停留在终止前的状态而后续节点的审批人、通知策略可能在流程正常运行期间被修改过复活后事件脚本按旧配置执行就和当前数据对不上了。解决复活流程之前先检查流程设计的当前版本和流程实例发起时的版本是否一致不一致则确认节点变更的影响范围。最稳的习惯先抄送相关人确认再执行流程复活。6. 设计取舍为什么 JNPF 选择元数据驱动而不是代码生成从 V3.4.1 的修订记录可以看到一个关键决策「去掉现有无表模式」。也就是说JNPF 不再支持没有物理表也能创建表单的设计了所有表单都要落表。这个取舍值得展开说。无表模式听起来更「轻」——先做界面表结构以后再说。但问题在于无表模式下表单字段没有数据来源列表查询没有对应的 SQL 生成规则流程审批的数据持久化没有落点。界面上看着正常一跑流程就报错。JNPF 去掉无表模式本质上是把「表单必须对应物理表」从潜规则变成显规则倒逼使用者在设计阶段就把数据模型想清楚。从平台维护者的角度这也大幅降低了异常数据的排查成本——每个表单都能通过功能 ID 找到表名每个字段都能找到列名出问题不再是黑匣子。另一个取舍点是主键策略的不可修改。它保证了流程引擎和历史数据之间的关联稳定代价是灵活性。如果未来主键策略需要升级或迁移就只能通过数据同步工具处理没有中间路线。这和很多正规范式化数据库设计的思路一致业务主键稳定优先扩展性让位于确定性。我的习惯是在 JNPF 里新建功能之前先画清楚数据关系草图——哪些是主表、哪些是子表、外键挂在哪、哪些字段要参与合计然后再打开设计器。这样设计出来的表单元数据结构和物理表结构基本一次成型不会在设计器里反复拖拽返工。从那以后我每次设计流程表单都强制先走一遍数据建模和字段梳理再进在线开发翻车率直线下降。希望帮到你。本文还有配套的精品资源点击获取