简介面向JNPF软件开发平台V3.4.2使用者的操作手册由福建引迈信息技术有限公司发布适合初中级开发、实施与运维人员按功能模块查阅。内容覆盖在线开发中的表单、列表、流程与结果展示门户与可视化大屏的新建展示、地图管理、分类管理和数据源管理并延伸至报表设计、功能表单与流程表单代码生成、系统配置、公告、调度、缓存、日志、监控及菜单权限等后台模块能帮助读者理解平台各功能入口与配置逻辑快速完成应用搭建和日常维护。资源包仅含1个PDF文件大小约40.01MB目录层级清晰、章节编排完整便于按关键词或页码定位具体操作说明也适合打印后作为随查随用的工具书。目前已有1343人学习可作为平台入门、功能对照、团队培训与实施排错的参考材料。1. 一份 240 多页的低代码平台功能使用手册能省掉多少试错接手一套低代码平台的交付项目我最怕的不是不会拖控件而是不清楚它的能力边界哪些需求靠拖拽和配置就能支撑哪些必须写脚本甚至要绕过平台来处理。这份 v3.4.2 的产品功能使用手册正好把边界画了出来在线开发、门户与大屏、报表、代码生成、系统管理、系统权限、工作流程、扩展应用按后台菜单顺序一路铺到 240 多页连修订记录都列了从 V3.2 到 V3.4.2 每一项新增功能。它适合三类人拿到平台要落业务系统的开发、被派去评估低代码能否支撑需求的架构以及准备在平台之上做二次开发的团队。它不教你怎么写代码教的是怎么少走弯路。2. 模块全景拆解六大块能力如何拼成一条交付链路拆开目录看这份手册的组织方式其实非常“产品化”它没有按技术分层去讲数据访问、渲染、鉴权而是按用户在后台里能点到的一级菜单来编排。对开发者来说这种编排反而更好用打开手册基本能对应到界面再点哪里。整本手册实质上是九个大章节但落到交付链路里可以归并成六块能力在线开发建模型、代码生成沉淀成工程、系统管理与系统权限管住人和数据、工作流程把单据串起来、门户、大屏与报表出口、扩展应用补齐邮件、签章、日程、知识库这类非核心但无法绕开的边角。先建立这个全景再看每个模块的细节阅读顺序就不会乱。手册章节在交付链路里的位置主要使用角色1 在线开发表单、列表、流程的模型搭建实施、业务配置人员2 代码生成功能表单、流程表单转成工程代码后端开发3 系统管理配置、调度、缓存、日志、菜单、模板、数据应用运维、平台管理员4 系统权限分级、组织、岗位、用户、分组、角色平台管理员5 工作流程流程设计、我发起的、待办、已办、抄送、委托、监控实施、业务方6 扩展应用签章、邮件、日程、知识管理、条码、订单示例等全栈开发2.1 在线开发拖拽出表单、列表、流程三段式在线开发是整本手册篇幅最大的一块从第 1 页一直写到第 66 页核心是“功能设计”这一个入口。新建时先选表单类型表单、列表、流程三者共用同一套基础设置区别在于后面要不要走列表设计和流程设计。配置顺序是“基础设置 → 表单设计 →列表设计→ 结果展示”每一步都有一个确定需要满足的条件基础设置定数据落到哪张表、主键怎么生成表单设计定控件和字段的映射列表设计定查询字段、列表字段和操作列结果展示才是给最终用户看的入口。控件体系分了三档基础控件、高级控件、系统控件拖进去之后在右侧分别配组件属性、组件样式、表单属性。这个三层属性拆法是比较标准的低代码做法有心的地方在于“组件样式”里单独提供了多端显示开关桌面端和移动端可以分别勾选某个控件是否出现。V3.4.1 的修订记录里写了“功能设计 PC 端与 App 端合并”意味着早期是两套设计器后来合成一个靠的就是这个多端显示勾选项来区分差异而不是维护两套模型。这一点对后续改造影响很大同一份表单移动端少几个字段、换个栅格都不需要复制一份。另外一个容易被忽略的设计是“无表模式被移除”。V3.4.1 的修订记录里明确写了去掉现有无表模式也就是所有功能都必须锁定到一张物理表或数据建模里的表上。这看起来是限制实际是好事数据落地明确后面做数据权限、做数据同步、做报表取数才有稳定的表名可用。2.2 门户、大屏、报表三套彼此独立的数据出口门户设计章节很薄只有新建和结果展示两节定位是把做好的功能、图表按门户布局拼成一个工作台。大屏设计稍厚拆成大屏管理、地图管理、分类管理、数据源管理四节其中数据源管理是关键它说明大屏上的图表不是写死的静态配置而是挂在一个数据集上的数据更新靠数据源刷新。报表设计独立成一章说明在这套平台里报表并没有被大屏吞掉两者服务于不同场景大屏偏展示报表偏查阅和导出。这三块放在一起看你会发现平台的思路是数据建模只做一次门户、大屏、报表都是对同一批数据的再呈现。所以实施阶段最值得先做扎实的不是大屏的酷炫效果而是数据建模和数据字典这两节。数据建模3.10.2定义了可被表单绑定、被大屏引用、被报表取数的逻辑表数据字典3.10.3定义了枚举值的统一来源凡是下拉框、单选组都应该挂字典而不是手写选项否则同一个“订单状态”在三个地方出现三种写法后续数据同步和报表统计就会踩坑。2.3 系统管理与系统权限交付前最后需要打通的一环系统管理这一章看着杂其实是交付前必须全部过一遍的清单系统配置基础设置、安全设置、第三方设置、超级管理员、系统公告、系统调度、系统缓存、系统日志、系统监控、系统图标、系统菜单、系统模板、数据应用。里面有几项是新手最容易漏的——系统调度是平台内置的定时任务系统缓存决定了你改完菜单或字典后要不要手动清一次系统日志里 V3.3.3 增加了操作日志排查“谁把这条数据改了”靠的就是它。系统菜单这一节是权限体系的基础拆得非常细新建菜单、导入导出、按钮权限、列表权限、表单权限、数据权限五层。V3.4.2 又给菜单加了子系统说明菜单层级从两级变成了可嵌套结构。权限体系里还有独立一章讲分级管理、组织管理、岗位管理、用户管理、分组管理、角色管理、权限管理、在线用户。分级管理是 V3.4.2 新增的配合 V3.3.2 补充的多组织内容意图很清楚支持集团—分公司这种层级化的数据隔离而不是只有一个平铺的组织树。3. 在线开发实操从新建表单到数据落表的完整链路这一章按真实操作顺序拆一遍。我会假设一个最常见的需求做一张带明细行的采购申请单主表存申请头子表存明细提交后走审批。这条链路把基础设置、表单设计、子表、列表设计和结果展示都串上了走通一次其余功能基本是同一套动作的变体。3.1 基础设置表从哪来、主键怎么定基础设置里第一个要决定的事是“要不要绑数据连接”。不绑的话平台在流程新建完成后自动建表命名规则是主表mt 功能 ID子表ct 雪花 ID。绑了数据连接就可以在下方“新增一行”进入数据选择页绑定来自数据建模的表单表或多表都行选多表时必须配子表的外键字段和关联主键选单表则跳过。这个顺序不能反先定表再拖控件因为控件字段下拉里能选的字段取决于你在基础设置里绑了哪些表。自动建表的命名规则值得记一下因为后续写接口、写同步任务、写报表 SQL 都要用到这两个前缀。-- 平台未指定数据连接时的自动建表约定字段随控件生成此处只表达结构与命名 -- 主表mt 功能ID CREATE TABLE mt_837412 ( id BIGINT NOT NULL COMMENT 主键雪花ID 或 自增长ID流程保存后不可修改, f_version INT DEFAULT 0 COMMENT 并发锁定开启后的乐观锁版本号, PRIMARY KEY (id) ); -- 子表ct 雪花ID CREATE TABLE ct_1827364510293847561 ( id BIGINT NOT NULL COMMENT 子表主键, parent_id BIGINT NOT NULL COMMENT 外键指向 mt_837412.id, PRIMARY KEY (id) );这三个参数的取舍需要提前想清楚。mt_与ct_前缀是平台识别主表和子表的约定改造时如果手动建表又想起个别的名字最好在数据建模里建别绕开这套约定。主键策略在表单属性里选雪花 ID 或自增长 ID关键限制是“流程保存后不可修改”——这不是提示是硬性限制一旦单据已经产生数据再想换主键策略只能新建一个功能重做。并发锁定开启后提交时会走乐观锁f_version这类版本字段就是给并发提交用的两人同时打开一张单、几乎同时点提交时后提交的会失败而不是静默覆盖。3.2 表单设计控件与字段的绑定关系决定了后续一切进入表单设计页左侧是控件区中间是画布右侧是属性区。选一个控件后右侧“控件字段”下拉里选它对应的表字段如果表里还没有这个字段下拉里可以直接快捷新建弹出的字段设置窗口会先列出当前表已有字段只读不可改点新建字段则新增一行空白配置。这个“边设计表单边建字段”的交互是低代码平台的典型做法好处是建表不用先去数据库里跑 DDL坏处是字段名起得随意后面做接口和报表会难受。我的习惯是在拖控件之前先在数据字典和数据建模里把字段名规划好控件字段只做选择不做新建。多表设计是这一节的重点。手册里分得清楚主表 副表、主表 两个副表、主表 两个子表都在支持范围内。设计副表的方式很直接——拖一个普通控件上去右侧在数据库表里选关联副表再关联对应控件字段即可因为副表和主表是一对一或一对多但单行呈现的关系控件直接落在画布上就行。子表不一样必须先拖一个“设计子表控件”到画布在它的组件属性里选中基础设置里添加过的子表之后才能往这个区域里拖控件。这一步是新手最容易卡住的地方没关联子表之前往区域里拖任何控件都不会成功。子表内的控件同样要在右侧关联控件字段同样支持下拉快捷新建。这里有个细节值得提前规划V3.4.1 增加的“子表字段权限配置”意味着子表里的每个字段都能单独配权限所以子表字段不要图省事全塞进一个大文本该拆开的拆开不然后面配权限时只能一刀切。3.3 子表合计与动作设置把明细行变成能算的明细行子表控件自带两个开关合计设置和动作设置。合计设置开启后流程使用时子表下方会出现合计栏合计字段从子表内的单行输入、数字输入、计算公式这三类字段里选可以多选。这个限制很关键金额字段如果当初拖的是文本控件合计栏里根本选不到它。计算公式类型的字段本身是子表内的计算列可以参与合计等于支持“行内先算、再纵向汇总”这种两层计算。动作设置是 V3.4.2 新增的子表传递能力配置链路长但逻辑清楚先点“配置表单”打开配置窗口设弹窗标题、弹窗类型居中或右侧、弹窗宽度再点“远端数据联动”选数据接口来源是 3.10.4 的数据接口选中后接口里的参数会自动列到参数设置区每个参数下拉选一个主表字段做筛选值——这就是控件联动弹窗打开时按主表当前值去查接口然后在设置列表字段里新增行定义弹窗里显示哪几列、列名对应接口的哪个字段最后在设置关联字段里新增行定义选中数据后往子表哪些字段里填映射来源支持接口字段和固定值两种。整条链路的实质是子表的行数据不是手敲的而是从外部接口查出来、挑一条、回填进来的。比如采购申请里选商品弹窗按供应商和仓库筛出可选商品列表选中一行商品编码、名称、单价自动填进明细行数量手填。这套设计比让用户复制粘贴靠谱得多也是低代码平台能不能真的用于业务的关键分界线。3.4 列表设计与结果展示查询、行内编辑这些细节决定好不好用如果新建时选的是列表类型基础设置和表单设计走完之后还要多一步列表设计桌面端和移动端分别设计。列表设计里要配三样列表属性、列表字段、查询字段。V3.4.2 这一版在列表上补了高级查询、行内编辑和列表查询这三个功能直接影响用户上手的第一印象配置时不要跳过去。高级查询一般是把多个条件组合成一个可保存的查询方案适合数据量大、筛选维度多的列表行内编辑允许在列表里直接改某个字段而不进表单适合状态标记、备注这类轻量修改列表查询则是把查询条件面板本身做成可配置的。配置完成后点确定功能就出现在功能设计列表里后面的操作在“结果展示”一节。这里还有两个和交付强相关的动作同步菜单V3.4.1 加的功能改完后菜单项要同步过去否则入口还是旧的以及子系统V3.4.2 给系统菜单加了子系统层级功能多了之后建议按业务域分子系统挂不然后台左侧菜单会长到无法使用。4. 表单脚本与流程引擎给零代码补上可编程的那一层纯配置能覆盖的需求大概到七八成剩下两三成一定需要写点逻辑。这套平台给了两个扩展点表单侧的事件脚本和流程侧的节点配置。前者处理“表单内联动”后者处理“单据怎么流转”。把这两个口子摸透很多原本要改代码的需求就能在平台内消化掉。4.1 控件事件与表单事件五个钩子的分工控件事件有两个触发时机发生变化时触发、失去焦点时触发。表单事件有三个表单加载触发、提交前置触发、提交后置触发。这五个钩子基本覆盖了表单生命周期的关键点选哪个取决于你要做什么——输入即反馈的用“变化时”需要等用户填完再校验的用“失焦”初始化下拉选项或回填默认值用“加载”提交前统一校验或补字段用“提交前置”提交后发通知、调外部接口用“提交后置”。手册给了一个很典型的示例配置一个下拉选择控件的变化事件值为 a 时给 a 控件赋值 1值为 b 时给 b 控件赋值 2值为 c 时把 c 控件隐藏值为 d 时把 d 控件设为必填。这四种操作正好对应脚本能干的四件事赋值、显隐、必填、以及组合条件。写成代码大致是这个形状// 控件事件下拉选择控件 type 发生变化时触发 // 手册只描述了行为具体 API 名以编辑器内的代码补全为准 var v this.value; // 当前触发控件的值 switch (v) { case a: form.setValue(fieldA, 1); // 赋值把 1 写进 fieldA break; case b: form.setValue(fieldB, 2); // 赋值把 2 写进 fieldB break; case c: form.setVisible(fieldC, false); // 显隐隐藏 fieldC break; case d: form.setRequired(fieldD, true); // 必填fieldD 设为必填 break; default: form.setVisible(fieldC, true); // 兜底其它值恢复显示 form.setRequired(fieldD, false); }这段逻辑本身没什么难度难的是几个隐性约束。第一this.value拿到的是当前控件的原始值还是显示值不同控件类型可能不一样下拉选择和多选、日期区间这种复合控件尤其要试。第二脚本里改控件值会不会反过来触发它自己的变化事件如果会就容易形成循环触发写赋值逻辑时一定要加条件判断确认值真的变了再写。第三隐藏和必填是两回事隐藏的必填控件在某些表单里依然会拦住提交配“c 隐藏”这类需求时要顺手把必填也关掉否则用户会遇到“什么都填了但提交不了”的情况。这类问题排查起来很费劲因为界面上看不见任何报错。表单事件里的“提交前置”是最值得重点使用的一个钩子。所有跨控件的校验——比如明细行合计必须等于主表金额、结束日期不能早于开始日期、选了某个类型就必须填备注——都放这里统一处理比在每个控件的失焦事件里各写一遍要稳得多也不用担心用户用鼠标点提交时跳过某个控件的失焦。4.2 流程设计三个配置区与 V3.4.2 补的几块拼图流程设计分三块基础信息、表单设计、流程设计。基础信息和表单设计跟前面表单类型的功能基本一致真正不同的是流程设计区也就是画流程图那一块。节点上的配置项从修订记录能看出演进的痕迹V3.3.1 加了审批设置候选人、保存草稿、节点事件、审批汇总、流程评论、子流程同步异步V3.4.2 又加了超时提醒、异常处理、自动同意、节点变更、流程复活、子表传递。把这两版加起来看这套流程引擎已经不只是“画个审批链”那么简单了。几个配置项的实际用途值得说明。候选人是节点审批人的选择方式除了指定角色和指定人通常还支持按表单字段取人、按组织层级取上级配的时候注意候选人范围不要开太大否则待办会变成“人人可见、人人不办”。保存草稿让发起人可以先把单子存下来再提交但这个开关和必填校验是冲突的开了草稿就要允许必填项为空配置时要成对考虑。节点事件是流程里的脚本钩子和表单事件一样用来做业务逻辑区别在于它跑在服务端流转过程中。子流程的同步异步是个典型的性能与一致性权衡同步子流程会等子流程走完再继续主流程状态和子流程强一致但耗时长异步子流程发起后立刻返回主流程不阻塞但要在业务上容忍一段时间的状态不一致。V3.4.2 新增的几项里超时提醒和自动同意是配合使用的节点配了超时提醒后到点会给审批人发消息消息模板在系统模板里配如果同时开了自动同意超时后会按预设规则自动通过。这两个开关在真实项目里要慎开尤其涉及金额审批的节点自动同意等于把风控让位给时间。异常处理解决的是节点执行出错后的走向流程复活则是给已经终止或结束的流程一次重新流转的机会这两个功能在测试阶段特别有用能省掉大量重走流程的时间。节点变更处理的是审批人调整人员离职或岗位调动时不用重新发起。4.3 数据接口与接口认证外部系统如何接进来数据应用这一节是整个平台对外联通的总出口包含数据连接、数据建模、数据字典、数据接口、接口认证、数据同步、行政区划七块。数据连接管的是数据库连接数据建模在上面建逻辑表数据字典管枚举数据接口把查询或写入封装成可被表单联动、大屏、外部系统调用的服务接口认证是 V3.4.2 新增的给接口加令牌校验数据同步做库表之间的数据搬运行政区划提供省市区数据源。接口认证这块单独拿出来说因为它决定了这套平台能不能安心放到公网上。新增认证意味着数据接口可以要求调用方带令牌而不是裸奔一个 URL。调用侧大致是这个形状import requests # 数据接口3.10.4发布后得到的地址令牌由接口认证3.10.5配置后下发 resp requests.post( http://your-host/api/interface/purchaseList, headers{ Authorization: Bearer token, # 接口认证开启后必带 Content-Type: application/json, }, json{ pageNo: 1, # 页码从 1 开始 pageSize: 20, # 每页条数建议不超过 100 supplierCode: S001, # 业务筛选参数对应接口定义里的入参 }, timeout10, # 超时时间外部调用建议 10s 以内 ) data resp.json()三个参数要留意。pageSize不要贪大百万数据量级的表扩展应用里专门有一个“百万数据”示例一次拉太多会直接把接口拖慢分页拉更稳。业务筛选参数的名称必须和接口定义里的入参严格一致大小写错了不会报“参数不存在”而是静默返回全量数据这种问题非常隐蔽。timeout必须显式设置尤其是这个接口被表单联动调用的时候没有超时会导致弹窗一直转圈。数据同步这一块在实施项目里用得比想象中多。很多客户的既有系统不能立刻下线需要平台和旧系统并行跑一段时间数据同步就是这段并行期的桥。配同步时的经验是优先做单表、单向、按时间戳增量同步别一上来就搞多表关联全量同步一旦失败很难定位是哪张表哪条数据卡住的。5. 避坑排查手册里没写但你一定会踩的 5 个点手册是按功能顺序写的它告诉你每个按钮在哪、每个字段什么意思但不会告诉你哪些操作是不可逆的、哪些配置组合会互相冲突。下面五条都是我在实际配置里遇到过或者见别人遇到过的问题按“现象 → 原因 → 解决”写能省一点算一点。现象一功能已经跑了一段时间想改主键策略发现下拉是灰的。原因很明确表单属性里的主键策略在流程保存后不可修改因为主键一旦落到数据表上历史数据全是这个规则生成的换策略等于让新旧数据混在两套 ID 体系里。解决办法只有两个要么新建一个功能重做要么在数据库层面做数据迁移再改后者必须停业务。血泪经验是新建功能时先把主键策略想清楚。内部系统、数据量可控的用自增长 ID 更直观好排查要跨库同步、要合并多来源数据的老老实实雪花 ID别图省事。现象二子表控件拖到画布上了但往里拖任何控件都拖不进去。原因不是拖拽失灵是子表控件没有在组件属性里关联子表。这个控件本身只是一个容器容器不知道装哪个子表的数据就不允许往里放字段。解决顺序是先回基础设置确认已经添加了子表、配好了外键字段和关联主键再回到表单设计选中设计子表控件在右侧组件属性里选关联子表之后往里拖控件就正常了。现象三子表配了合计设置但运行起来下方没有出现合计栏。原因通常是合计字段的下拉是空的或者选不全而合计只支持子表内的单行输入、数字输入、计算公式这三类字段。如果金额字段当初拖的是普通文本控件它压根不在候选范围里。解决办法是把字段类型改对文本改数字输入改完记得同步检查列表设计和打印模板里引用这个字段的地方字段类型变了会影响格式化。现象四PC 端一切正常移动端打开发现有些字段不见了。这是多端显示开关被改过。默认全选但只要有人为了“移动端简洁一点”取消勾选过某个控件这个设置会一直保留而且不会在 PC 端有任何提示。排查方法是打开表单设计逐个控件看右侧组件样式里的多端显示勾选状态切到移动端预览逐屏过一遍。规范做法是涉及移动端的需求设计阶段就把移动端预览打开边配边看别等交付前才想起来切。现象五数据权限配完了用户还是能看到不属于自己的数据。这类问题九成出在权限分层没对齐。系统菜单里按钮权限、列表权限、表单权限、数据权限是四层独立配置加上角色和角色成员一共六个地方要一一对上。常见组合错误是给角色加了数据权限规则但用户是通过分组或组织继承的角色实际生效的角色里没这条规则或者菜单本身没开列表权限用户是靠另一个菜单看到的同一批数据。排查时用在线用户功能看当前用户实际生效的角色集合再逐个角色核对权限比在用户管理里猜要快得多。除了这五条还有一条不算坑但很费时间的习惯改完菜单、字典、模板这类基础配置后如果不生效先去系统缓存清一次再判断。缓存这一层平时是性能优化排查阶段就是干扰项不确认缓存状态就去查代码容易在一个并不存在的问题上耗掉一下午。6. 二次开发把手册沉淀成可复用的交付模板做到第三个项目的时候我基本不再从零配置了而是先把上一版沉淀成模板靠的就是平台里那几个“系统模板”入口。系统模板这一节包含短信模板、消息模板、打印模板、单据模板四类其中打印模板和单据模板的复用价值最高一套采购单的打印格式换个客户改个抬头就能用比每次重新拖一遍控件快得多。我的做法是每交付完一个项目把该项目里打印模板、单据模板、数据字典、数据建模这四样导出留档下一个项目开工时先导入再改能省掉一半以上的前期配置时间。可以复用的对象复用方式迁移时要确认的事数据建模 / 数据字典导入导出V3.2 起支持字段类型与目标库兼容性打印模板 / 单据模板系统模板导出模板里绑定的字段在新功能里是否存在系统菜单与权限菜单导入导出角色在新环境的 ID 是否一致表单与流程功能设计导出后重绑表主键策略、数据连接必须重新确认二次开发真正需要动手改代码的地方通常集中在这几块控件事件脚本、表单事件脚本、节点事件脚本以及数据接口。脚本这块最容易出问题的地方是版本升级后的 API 兼容升级前把关键表单的脚本拷出来单独存一份升级后逐个回归。数据接口这块如果平台内置的接口能力不够用可以在外部写服务再通过数据连接挂进来不必强行在平台里实现复杂逻辑这条边界要早一点承认。验证方法上我一般分三步走。第一步用扩展应用里的示例功能做一次快速验证发布功能示例、门户示例、报表示例、大屏示例、图表示例、表格示例、表单示例都是现成的跑通说明环境本身没问题。第二步压数据用百万数据示例看看列表分页、高级查询、导出在真实数据量下什么表现很多配置问题只有数据量上来才暴露。第三步串一圈外围能力导入导出、电子签名、电子签章、条码、打印这几个在验收清单里几乎每次都会点到提前跑一遍比现场调试体面得多。从那以后我每次拿到一份新的平台手册第一件事都不是从第一页开始读而是先翻修订记录和目录把“这一版新加了什么、哪些是不可逆配置”标出来配置的时候强制走一遍确认流程主键策略、数据连接、多端显示这三项在点确定之前必须再确认一遍。这套习惯救过我很多次也希望对你有用。本文还有配套的精品资源点击获取
