用户复盘:如何在严苛信创与网络隔离环境下,打通大型基建现场数字化的“最后1公里”?
在一个集团的数字化转型的项目中,有太多细碎的“踩坑点”,过去一年我们都在和“现场表单线上化”这件事情死磕。
集团的核心干线系统(如企业级 ERP、大型资产管理系统、项目管控系统)早就跑得很顺。但真正到了基建现场调试、质量安全巡检等“数字化末端”,信息化推行的阻力极大。现场存在大量结构极度复杂的“现场记录单、隐蔽工程验收表”,动辄包含几百个合并单元格和严谨的国标级计算公式,甚至对线框粗细、跨页排版打印格式有着像素级的强迫症要求。
如果用传统的低代码“拖拉拽”去重构这些重度表格,光是前端排版和公式绑定就会让研发团队陷入数周的泥潭。在经历了多次现场退单、网络合规审查卡壳后,我们换了思路。今天不谈宏大概念,只是复盘我
一、 最大的拦路虎:严苛的网络隔离与数据传输要求
大型集团的生产网、管理网、现场办公网之间存在着多道物理隔离或反向网闸。在项目方案设计初期,安全合规部门给出了近乎苛刻的要求:新嵌入的表单交互模块,其样式、脚本和临时数据,绝对不能侵入或污染主系统的核心网络和既有技术栈。
为了解决这一冲突,我们放弃了传统的代码嵌入方案,采用 iframe 实现了前端样式的彻底沙箱化隔离。我们希望将主系统与表单运行时的交互成本降到最低,就像调用本地函数一样简单。
以下是我们在集团基建系统前端安全网关下,实现跨域隔离通信的核心对接代码复盘:我们是如何在严苛的环境下,通过“少量的定制开发 + 极轻量的解耦组件”跑通全链路的。
<!DOCTYPE html><html lang="zh-CN"><head><meta charset="UTF-8"><title>集团基建管控系统 - 现场重度表单安全集成</title><script src="/assets/js/flash-table-rpc.min.js"></script><style>.form-frame-container { width: 100%; height: 95vh; }
iframe { width: 100%; height: 100%; border: none; }
</style></head><body><div class="form-frame-container"><iframe id="tableEngineFrame" src="http://table-engine-service.internal:9150/viewer"></iframe></div><script>const iframe = document.getElementById('tableEngineFrame');
const engineOrigin = 'http://table-engine-service.internal:9150';
// 1. 初始化 RPC 实例,注入本地回调函数const rpc = createFlashTableRPC(iframe, engineOrigin, {
// 当复杂的重度表单模板在安全沙箱内部加载完成后触发TEMPLATE_LOADED: function (meta) {
console.log('表单内核准备就绪,模板ID:', meta.templateId);
// 2. 模拟从集团主系统后端安全网关调取的现场设备安装质检数据const siteInspectionData = {
project: { name: "大型跨区域输变电工程(一期)" },
checkList: {
inspector: "李工",
components: [
{ name: "1号变压器基础线圈", resistance: 505, result: "合格" },
{ name: "2号变压器基础线圈", resistance: 498, result: "合格" }
]
}
};
// 3. 跨域安全灌入数据,触发只读/编辑或电子签署模式
rpc.SET_DATA({
templateId: "tpl_infrastructure_rec_001",
data: siteInspectionData,
mode: "edit"
});
},
// 现场多方人员填报/签署完毕,触发提交时的回调ON_FORM_SAVE: function (formData) {
console.log('捕获到现场填报数据,准备通过集团安全通道回传主系统后台:', formData);
}
});
</script></body></html>
这里利用FlashTable表单开发组件,主系统只需维护基础的业务逻辑,具体的重度渲染交给隔离带另一侧的组件去处理,平滑地绕过了合规审查。
二、 避不开的硬考题:全栈国产信创环境适配
对于国央企项目,全信创兼容是一条红线,也是我们在方案阶段必须死守的底座。
我们的底层服务器用的是符合信创要求的操作系统,数据库则全面切到了国产达梦数据库。在这个大前提下,传统的国外开源表单组件或者依赖特定环境的低代码平台在离线私有云里根本跑不起来。
在项目实施阶段,我们采用了容器化离线交付的策略,基于底层支持的 Linux x86_64 信创底座,通过定制的一键脚本自动链接信创关系型数据库。这种高度的架构灵活性,给我们的运维和私有云合规部署省去了大量去改写底层驱动的麻烦。
三、 数据层的硬核死磕:面对现场多变物料的“动态行”反推
回到业务本身,基建现场填报有一个极度折磨前端开发的常态:表格行数是不确定的。
例如:今天进场 3 批物料,表单需要展示 3 行明细;明天进场 30 批,表单就要自动向下延伸出 30 行,同时还要精准保留表格底部的多方签字盖章区以及 Excel 级联计算公式。
为了不让研发团队针对每一种现场表单写大量的 DOM 拼接逻辑,我们采用了“路径反推”的数据流设计。前端研发人员通过标准的接口,将复杂的嵌套 JSON 数据结构一次性推送给表单设计内核:
[
{
"uniqueId": "f_proj_name",
"fieldName": "project.name",
"fieldComment": "工程项目名称",
"type": "text"
},
{
"uniqueId": "f_comp_name",
"fieldName": "checkList.components#name",
"fieldComment": "检测部位名称(动态多行)",
"isArray": 1,
"type": "text"
},
{
"uniqueId": "f_comp_res",
"fieldName": "checkList.components#resistance",
"fieldComment": "绝缘电阻(MΩ)",
"isArray": 1,
"type": "number"
}
]
这里的核心逻辑在于引入了 对象属性访问 与 动态循环体标记 路径规则。当业务人员通过 Ctrl+C / Ctrl+V 把现有的 Excel 表单像素级复制到线上后,只需要将带有 # 标识的动态字段绑定到对应的单元格中。
在实际运行填报时,渲染内核解析到数据包中的数组,就会自动触发 DOM 层的像素级克隆。通过这种方式,我们不仅解决了多变物料的自适应展示,更完整保留了原本线下的格式习惯。
四、 经验总结:低成本激活既有系统血脉
复盘整个项目,我最大的感悟是:在大型集团做数字化,大刀阔斧地推翻核心系统是不现实的,风险也极高。
我们在这个项目里之所以能啃下基建现场这块硬骨头,核心在于定位清晰:主系统负责跑审批流、管台账、控风险;而末端复杂的表单生成、像素级还原和打印,我们交给了组件去干。在这个过程中,FlashTable 表单开发工具只作为我们架构中的一个轻量化转换中枢,辅助我们完成了“最后1公里”的重度表单承载。
集团内部的 IT 团队或长期合作的软件服务商,只需要以类似的轻量组件为内核,结合自身具体的业务场景进行少量的定制开发工作(如对接企业自建的工作流引擎、电子签名签章系统、工业级静默批量打印机),就能以极低的综合成本,将原本流落在线下的零散数据彻底激活,纳入集团统一的数据资产管理中心。
这才是大型国央企数字化末端落地的可行路径。
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
所有评论(0)