简介面向 JNPF 软件开发平台 V3.4.2 的官方操作手册由福建引迈信息技术有限公司发布适合低代码开发人员、项目实施人员和系统管理员阅读用于快速掌握平台各功能模块的使用方法。手册按功能模块组织详细覆盖在线开发、门户设计、大屏设计、报表设计、代码生成和系统管理。在线开发部分细化到表单、列表、流程与结果展示系统管理部分涵盖系统配置、系统公告、调度、缓存、日志、监控与菜单权限等可按目录直接定位到对应步骤手册中提供了丰富的操作指引和界面说明能帮助读者从零开始配置在线表单、流程审批、数据大屏以及后台权限。资源共 1 个 PDF 文件压缩包大小约 40.01MB适合作为 JNPF 平台日常查阅的完整参考文档。目前已有 1339 人次浏览学习适合正在使用或即将部署 JNPF 的团队按需查阅表单流程搭建、大屏配置及后台权限管理等操作细节。1. 这份手册能帮你干什么从零摸清一个低代码平台的全貌如果你所在团队正在接一个“带审批流程的管理系统”项目又被业务方追着要两周出 Demo那么这份低代码开发平台的产品功能手册很值得花一个下午通读。它不是源代码而是一份面向产品功能使用的操作手册覆盖了一个低代码开发平台从在线开发、代码生成到系统管理、权限体系、工作流程、扩展应用的全部功能模块。我拿到后的第一感受是这不只是“教你怎么点按钮”更像是一张平台的架构地图。它把表单、列表、流程、菜单、权限、数据接口之间的关系都串了起来对想跑通平台、做二次开发的开发者来说是比源码更快的入门路径。无论你是实施人员、后端开发还是前端开发都能从中找到自己关心的模块。2. 平台模块地图六大板块与底层表设计推断2.1 先看全景一份手册划出的六大功能域手册的结构非常清晰按使用场景切成了六大板块在线开发、门户设计、大屏设计、报表设计、代码生成、系统管理后面又跟了系统权限、工作流程和扩展应用。把这些章节映射到平台能力上会发现它其实是一个完整的管理系统开发环境。在线开发负责生成 PC/APP 端的功能页面分成表单、列表、流程三类门户设计、大屏设计、报表设计负责非业务页面的可视化搭建代码生成把设计好的表单、流程转成工程代码系统管理负责系统配置、菜单、日志、缓存、数据源、数据建模等底座能力系统权限负责分级、组织、岗位、用户、角色、数据权限工作流程负责流程设计、待办、已办、抄送、委托、监控扩展应用则提供功能示例、电子签名、邮件、知识库、文档预览、地图等开箱即用模块。这六大板块之间有明确的依赖关系在线开发设计出的功能必须挂到系统管理的“系统菜单”下工作流程依赖在线开发里的表单系统权限控制在线开发功能里的按钮、列表、表单和数据权限。所以这份手册的正确读法不是按页翻而是先记住这张模块依赖图。你会反复看到“数据来源于 3.10.4 数据接口”“详情查看 1.1.1 表单”这类交叉引用说明模块之间是强耦合的单独读某一章节很难真正理解功能在系统中的位置。2.2 从目录反推架构谁依赖谁把目录展开我按“底层能力 → 业务设计 → 交互入口”三层来理解层次手册章节典型入口底层能力系统管理 3.10 数据应用、3.5 系统日志、3.4 系统缓存数据连接、数据建模、数据接口业务设计在线开发 1.1 功能设计、工作流程 5.1 流程设计表单、列表、流程节点交互入口系统管理 3.8 系统菜单、系统权限 4.x菜单、按钮、角色、用户这个分层关系直接决定了在平台上做事的顺序先到“数据应用”里配置数据连接和数据建模再到“在线开发”里设计表单和列表然后到“工作流程”里把流程挂到表单上最后到“系统菜单”里配置菜单并分配权限。如果顺序反了比如先建表单再补数据表就会遇到“需要自定义选择数据表”的额外步骤。手册里专门提到“未设置数据连接时在流程新建完成后会自动进行数据表创建主表以 mt功能ID 命名子表以 ct雪花ID 命名”这是一个典型的依赖陷阱后面避坑章节会细说。开发者拿到手册后最容易忽略的是“第三方设置”和“超级管理员”这两个小节。第三方设置一般在做登录对接时才会用到而超级管理员是平台默认保留的账号手册中对它的配置方式包括安全设置、锁定账户、图形验证都做了专门说明。如果二开时你不想暴露超管账号就需要在系统配置里提前调整。2.3 底层表设计推断主表 mt功能ID子表 ct雪花ID手册在 1.1.1 表单基础设置部分给了一个非常关键的信息平台自动建表时主表以“mt功能ID”命名子表以“ct雪花ID”命名。这意味着业务表的物理名不是根据业务语义生成的而是根据功能元数据生成的。常见做法是在数据连接里配置某个业务库后平台自动执行建表语句然后把表结构元数据保存到自己的系统库里。我一般会这样理解这张表结构-- 主表mt 功能ID例如 mt1001 CREATE TABLE mt1001 ( id VARCHAR(64) PRIMARY KEY COMMENT 主键雪花ID或自增长ID, apply_user VARCHAR(64) COMMENT 申请人, apply_date DATETIME COMMENT 申请日期, amount DECIMAL(18,2) COMMENT 金额 ); -- 子表ct 雪花ID例如 ct1234567890123456789 CREATE TABLE ct1234567890123456789 ( id VARCHAR(64) PRIMARY KEY, mt_id VARCHAR(64) COMMENT 关联主表外键, goods_name VARCHAR(200) COMMENT 商品名称, price DECIMAL(18,2) COMMENT 单价 );参数说明主键策略在表单属性里配置支持雪花ID和自增长ID并且流程保存后不可修改所以上线前一定要想清楚用哪种否则后面改就是给自己挖坑。子表的外键字段由多表关联时配置的主表和子表关联主键决定如果没有配置子表数据将无法正确关联到主表。2.4 代码生成模块功能表单与流程表单的区别手册第 2 章“代码生成”分了“功能表单”和“流程表单”。功能表单生成的是普通业务功能的前后端代码流程表单生成的是带工作流审批的代码。在二开时我的建议是能靠在线开发拖出来的页面就不要手写代码只有需要深度定制组件、或需要把表单嵌入到已有工程时才使用代码生成。从这个区别能看出整个平台的架构表单设计器、列表设计器、流程设计器都是元数据驱动的生成的代码只是元数据的渲染结果。所以二开的核心不是改生成的代码而是扩展设计器能序列出的元数据模型。理解了这一点再看后面的事件脚本、数据接口、权限模型思路会顺很多。3. 在线开发核心拆解一次表单加列表加流程的完整搭建3.1 表单设计拖拽控件、绑定字段与子表合计手册 1.1.1 讲了表单设计的完整链路新建表单 → 基础设置 → 表单设计 → 配置属性 → 确定。基础设置里有三个关键点数据连接、数据表、多表关联。如果不想手动建表可以不选择数据连接平台会在流程新建完成后自动建表但如果业务需要多张表就必须在数据建模里先建好表然后在基础设置里“新增一行”绑定多张表并设置子表的外键字段和关联主键。进入表单设计页面后左侧是控件区分基础控件、高级控件、系统控件右侧是属性区。每个控件要绑定“控件字段”如果表里没有对应字段可以直接在下拉菜单里“快捷新建字段”平台会同步修改表结构。多表设计时可以选择副表控件或子表控件子表控件需要先关联基础设置中添加的子表再把字段拖进子表区域。这里有一个容易被忽略的功能子表的“动作设置”。手册说开启动作设置后可以配置弹窗标题、弹窗类型居中或右侧、弹窗宽度并通过数据接口做远端数据联动。实际效果是用户在子表里点击“添加数据”会弹出一个列表列表数据来自数据接口接口返回后根据表单字段作为筛选条件再通过“关联字段”映射回子表字段。这是很典型的“从外部系统带数据回来”的场景比如选择订单号后自动带入客户、金额。我给出一个表单设计的配置片段序列化后的元数据大致长这样{ formName: 采购申请, mainTable: mt1001, fields: [ { field: applyUser, label: 申请人, control: input, required: true, event: change }, { field: applyDate, label: 申请日期, control: date } ], subTables: [ { table: ct1234567890123456789, fields: [ { field: goodsName, label: 商品名称, control: input }, { field: amount, label: 金额, control: number, summary: true } ], actionSetting: { dialogType: center, dataSource: dataApiOrder, filterField: customerId, mapping: [ { target: goodsName, source: dataField.goodsName } ] } } ], formProperty: { masterKeyStrategy: snowflakeId, concurrentLock: true, formEvents: { load: /* 表单加载脚本 */, beforeSubmit: /* 提交前脚本 */, afterSubmit: /* 提交后脚本 */ } } }参数说明masterKeyStrategy对应表单属性中的“主键策略”可选snowflakeId或autoIncrement保存后不可变concurrentLock对应“并发锁定”用于开启乐观锁机制formEvents是表单脚本事件支持 JavaScript可以在加载、提交前、提交后执行。subTables[].actionSetting就是子表动作设置dataSource指向系统管理中“数据接口”的编号filterField用于联动筛选mapping把数据接口返回的字段映射到子表字段。3.2 列表设计查询字段、列表字段与桌面/移动端切换当新建功能选择“列表”类型时它分三步基础设置、表单设计、列表设计。基础设置和表单设计与表单一致不同的只是多了一个“列表设计”。在列表设计里要配置列表字段、查询字段、按钮权限等。关键点在于“桌面端与移动端切换分别设计”也就是说同一个列表在 PC 上的查询区、列宽、按钮布局可以和手机上完全不一样。这里有一个关于“列表查询”的细节手册修订记录里提到 V3.4.2 增加了“高级查询”“行内编辑”“列表查询”。高级查询允许使用者在前端自由组合多个查询条件行内编辑则让列表页可以直接改字段值列表查询是配置在列表顶部的固定查询区。三者是不同层级的能力。配置时要注意行内编辑只对绑定了主表字段的控件生效如果列表字段来自子表通常不能直接行内编辑。列表配置片段{ listName: 采购申请列表, listFields: [ { field: applyUser, label: 申请人, width: 120px, visible: true }, { field: applyDate, label: 申请日期, width: 160px, visible: true }, { field: amount, label: 合计金额, width: 120px, visible: true } ], queryFields: [ { field: applyUser, label: 申请人, control: input }, { field: applyDate, label: 申请日期, control: dateRange } ], listActions: { edit: true, delete: true, rowEdit: true, advancedQuery: true }, deviceSetting: { desktop: { columns: 3, layout: table }, mobile: { columns: 1, layout: card } } }说明queryFields里的控件类型决定了查询区的交互日期用dateRange会自动渲染成日期范围listActions.rowEdit对应“行内编辑”开启后列表行点击即可编辑deviceSetting是 PC 与移动端分别设计的核心配置。如果你发现列表在手机上显示很挤多半是因为没有单独设置移动端布局而不是平台不支持。3.3 流程设计节点、审批人、条件与超时处理工作流程是平台的重头戏手册第 1.1.3 和第 5 章都花了大量篇幅。流程设计分基础信息、表单设计、流程设计三部分。基础信息里会关联前面做好的表单流程设计里才是核心包括节点、连线、审批人、条件、事件。V3.4.2 版本新增了很多流程能力超时提醒、异常处理、自动同意、节点变更、流程复活、子表传递。开发者要特别关注“节点事件”和“子表传递”。节点事件支持在进入节点、离开节点时执行脚本子表传递可以把主表子表的数据在节点之间按配置传递避免流程页面重复录入。一个流程节点配置示例{ processName: 采购审批, form: form1001, nodes: [ { nodeId: node_start, type: start, name: 发起 }, { nodeId: node_approve, type: approve, name: 部门经理审批, approverSetting: { candidateType: role, candidateValues: [dept_manager], timeout: { remind: true, hours: 24 }, abnormalHandling: auto_agree } }, { nodeId: node_condition, type: condition, name: 金额大于10000, condition: amount 10000, targetNode: node_finance } ], notifySetting: { nodeEnter: [message, sms] } }参数说明approverSetting.candidateType支持按角色、岗位、用户等范围选择候选人timeout对应超时提醒超过 24 小时自动提醒abnormalHandling可以配置超时后的异常处理策略例如“自动同意”。条件节点的condition是表达式平台会根据表单字段值进行分支流转。这些配置最终都会落到流程引擎里去解析执行。注意如果在流程里保存草稿后修改了表单已经发起的流程实例不会自动同步新表单元数据需要额外处理这也是常见坑之一。3.4 结果展示PC/APP 端合并与同步菜单手册在 1.1.4 结果展示里说明功能设计完成后在列表中可以预览、编辑、复制、删除、同步菜单等。因为 V3.4.1 之后 PC 端与 APP 端功能设计合并所以同一个功能可以同时生成两端页面前提是在控件样式里勾选“多端显示”。默认是全部选中如果某个控件不想在移动端展示就取消移动端勾选。同步菜单功能可以把设计好的功能直接挂到系统菜单下省去手动新建菜单再配置地址的步骤。但要注意同步后的菜单名称和路由地址是平台自动生成的如果项目要求自定义路由建议不要用自动同步而是在系统菜单里手动新建菜单并在表单属性里查看功能编码用功能编码去配置访问地址。4. 系统管理与权限模型从菜单到数据的四层权限4.1 系统管理先看这几个配置项系统管理是平台的后台底座。手册 3.1 系统配置里分了基础设置、安全设置、第三方设置、超级管理员3.8 系统菜单里又分了新建菜单、导入导出、按钮权限、列表权限、表单权限、数据权限3.10 数据应用里是数据连接、数据建模、数据字典、数据接口、接口认证、数据同步、行政区划。这一章的内容很多我建议按“配置顺序”记忆先做数据应用建库建表再做系统菜单挂功能然后配置模板消息、打印、单据最后看监控日志。基础设置里一般配置平台名称、Logo、默认语言等安全设置里配置图形验证、登录方式、锁定账户策略第三方设置主要用于对接外部认证源比如企业微信、钉钉或统一身份认证。超级管理员账号在初始化后需要及时修改密码手册特意把它列出来说明平台对超管账号有独立的保护策略。在实际项目实施中我通常会先把“安全设置”里的登录策略调好再让业务用户开始配置表单避免上线前再统一改密码造成大面积重新登录。4.2 权限模型拆解分级、组织、岗位、角色、用户系统权限这章的结构是分级管理 → 组织管理 → 岗位管理 → 用户管理 → 分组管理 → 角色管理 → 权限管理 → 在线用户。这个顺序其实就是“先建组织骨架再填人再绑角色授权”。分级管理支持多级组织架构适合集团或大型企业组织管理维护部门岗位管理定义职位用户管理把账号挂到组织和岗位上角色管理把权限集赋给一批人。权限分配关系可以这样看配置项作用范围关联对象角色管理操作权限菜单、按钮、列表字段数据权限行级数据用户/角色 数据范围规则表单权限字段级表单控件可见/可编辑列表权限列级列表字段可见性角色权限在手册 4.6.3 中配置支持勾选菜单、按钮、列表、表单、数据权限。注意“按钮权限”和“列表权限”是两个独立维度按钮权限控制页面上哪些按钮可见可点列表权限控制列表字段的展示表单权限控制打开表单时哪些字段可编辑数据权限则是控制查询结果能返回哪些行。很多新人在配置时只配了角色菜单权限结果用户能打开菜单却看不到数据原因就是数据权限漏配了。4.3 数据权限与表单权限的配置方法数据权限是平台里最容易踩坑的部分。手册里提到系统菜单支持“数据权限”配置点开后可以看到数据范围规则比如全部数据、本组织、本组织及下级、本岗位、仅本人、自定义 SQL 等。配置数据权限时要先理解当前业务的数据归属字段比如数据表里有createBy、orgId然后选择“自定义”并编写过滤条件。常见做法是-- 仅当前登录用户的数据 create_by #{currentUserId} -- 本组织及下级 org_id IN (SELECT id FROM sys_org WHERE path LIKE CONCAT(#{currentOrgPath}, %))参数说明currentUserId和currentOrgPath是平台注入的上下文变量分别表示当前登录用户和当前组织路径。如果数据表没有组织字段那么“本组织”这类规则就无效需要保证业务表里有对应的组织字段。表单权限则是在功能设计的表单属性里配置不同角色对控件的可见/可编辑状态比如申请人在提交后不可修改审批人字段在申请人角色下隐藏。系统模板里的打印模板和单据模板对二开也有用打印模板可以定义审批表单打印样式单据模板用于生成业务单据号规则。配置时要注意模板名称不能重复否则保存会失败。另外系统公告和消息中心是配套的公告可以指定发送人员范围未读消息会出现在消息中心这里的人员范围本质上也是权限数据的一个应用场景。4.4 数据应用从数据连接到数据接口的完整路径数据应用模块是平台的数据中枢。数据连接决定平台能访问哪些数据库数据建模负责建表、维护字段数据字典管理枚举值数据接口通过 SQL 或 API 暴露数据给表单的弹窗选择、动作设置以及外部系统调用接口认证则保证接口不能被随意访问。从二开角度我最常用的是“数据接口”。比如在 3.1 子表动作设置里dataSource指向的就是这里的数据接口。配置接口时先新建数据源再写 SQL 查询语句然后定义参数和返回字段。平台会把这些元数据保存起来并在前端弹窗中直接渲染成可筛选的列表。如果你有外部系统提供的 REST API也可以通过接口认证的方式让平台在请求时自动带上 token。这里的一条血泪经验是调试数据接口时先用系统自带的接口测试功能跑通返回结构再关联到表单否则在表单弹窗里排查问题会非常痛苦。5. 常见问题与避坑记录流程、表单、权限配置的五个雷区5.1 流程发起后数据没写入预期表现象设计完流程发起后打开数据表发现记录不在自己绑定的业务表里或者只写了主表子表完全没有数据。原因基础设置里没有正确选择数据连接和数据表或者选择了多表但没有配置子表外键和关联主键。手册里说“未设置数据连接时在流程新建完成后会自动进行数据表创建”很多人因此就不配置数据连接结果自动生成的表名是mt功能ID跟自己的业务表对不上。多表时如果外键缺失子表数据不会自动关联。解决在流程或表单的基础设置里先选择数据连接再通过“新增一行”绑定已经建模好的表多表选择时逐个子表配置外键字段与关联主键。建议在上线前用一条测试流程跑通数据写入再复制到正式环境。5.2 列表查询字段配了却没出现在查询区现象在列表设计里加了查询字段但前端列表页的查询区没有显示或者高级查询里能选固定查询区显示不出来。原因列表查询字段的控件类型和查询方式不匹配。比如用文本域或富文本控件作为查询字段平台默认不支持或者没有把字段加入“列表查询”只是加入了“高级查询”。V3.4.2 增加了高级查询和列表查询二者是独立配置的。解决在列表设计里确保查询字段使用单行输入、下拉选择、日期范围这类基础控件如果需要条件组合开启高级查询并把常用条件放到列表查询区。配置后刷新页面才会生效注意浏览器缓存。5.3 流程节点审批人总是选不到候选人现象节点配置了审批人发起流程时却提示“无可用审批人”或候选人为空。原因审批人设置里选择的候选人但候选人范围来自角色、岗位或表单字段。如果角色下没有成员或者表单字段对应的人员为空就取不到人。另一种常见情况是节点变更后没有重新发布流程定义旧流程实例仍使用旧配置。解决在流程设计里打开审批设置确认候选人类型为角色、岗位、用户或表单字段并检查对应对象是否有效。如果要按表单字段动态取人确保表单里绑定的用户控件已填入值。流程已发起的实例如果要使用新配置需要管理员在流程监控里做“流程复活”或重新发起。5.4 主键策略改不了导致流程无法保存现象表单属性里主键策略默认雪花 ID后来想改成自增长 ID保存时报错或提示不允许修改。原因手册明确写了“主键策略支持雪花 ID、自增长 ID流程保存后不可修改”。这是因为流程数据已经通过主键策略关联了历史记录修改策略会导致主键冲突。解决在设计阶段确定主键策略不要上线后再改。如果已经上线需要新建功能并迁移数据或者通过数据接口的方式做数据搬迁。这个属于典型的后悔药场景只能在前期多确认。5.5 并发提交导致数据互相覆盖现象多个人同时对同一条记录提交表单后提交的覆盖了先提交的且没有提示。原因表单属性里的“并发锁定”没有开启。并发锁定实际是乐观锁机制提交时平台会比较版本字段或更新时间不一致则提示冲突。解决在表单属性里开启“并发锁定”。开启后如果并发更新平台会抛出冲突提示让用户重新加载数据再提交。如果数据表中有业务上需要保留的字段建议同时做好版本字段的初始化。6. 二次开发思路把手册变成自己项目的扩展蓝图6.1 从手册提炼二次开发的切入点手册本身不是代码但它把平台的能力边界画得很清楚。二开时我的切入点有三个表单事件脚本、数据接口、代码生成。表单事件脚本是零成本扩展点不需要改平台源码只需要在控件事件或表单事件里写 JavaScript 就能实现页面联动数据接口是连接外部业务系统的桥梁手册 3.10.4 数据接口支持通过 SQL 或 API 生成接口再供表单动作设置和弹窗选择使用代码生成则适合需要把表单嵌入到现有工程的情况。6.2 一个可上手的表单联动示例以手册 1.1.1 中的事件为例下拉选择控件改变时根据值控制另一个控件隐藏或必填。在表单设计器右侧“组件事件”里选择“发生变化时触发”写入// 下拉控件字段typeSelect目标控件descField、amountField var val this.getValue(typeSelect); if (val a) { this.setValue(amountField, 1); this.setVisible(descField, true); this.setRequired(amountField, true); } else if (val b) { this.setValue(amountField, 2); this.setVisible(descField, false); }参数说明this是表单实例的上下文对象getValue获取指定控件值setValue赋值setVisible控制控件显示setRequired控制是否必填。这套 API 可以从手册 1.1.1 的示例里验证。实际项目中我经常用它做“审批类型切换后动态显示不同字段”的逻辑避免写死页面。6.3 验证方法把手册当验收清单二次开发完成后我在每次升级或调整配置时会把手册的目录当成验收清单逐个模块过一遍表单是否能在 PC 和 APP 端分别显示列表高级查询是否可用流程节点超时提醒是否触发权限里按钮、列表、表单、数据四类权限是否都生效系统日志里是否有异常记录。建议你也这样先跑通最基础的表单-列表-流程链路再逐步加权限和数据接口。如果遇到与手册描述不一致的行为优先检查版本号和“修订记录”平台在 V3.4.2 里改过不少行为比如 PC 端与 APP 端合并、去掉无表模式旧版本的手册内容可能已经失效。从那以后我每次拿到新版手册都会先做一次“模块图映射”把新增的功能点标到自己的架构图上再动手改配置。这样即使平台版本升级也不容易翻车。希望帮到你。本文还有配套的精品资源点击获取