零代码搭应用：宜搭108页手册表单流程与系统集成实践

简介这份《0代码搭应用——宜搭开发手册》PDF面向企业信息化负责人、业务人员及希望快速搭建内部应用的开发者围绕业务无系统支持、流程脱节、信息孤岛与开发运维成本高等痛点系统介绍阿里巴巴宜搭零代码平台的定位与能力。资源共1个PDF文件压缩包约22.76MB内容完整便于翻阅与检索。手册从宜搭简介、产品优势与客户案例讲起覆盖杭州市一医院内控升级、老板电器品质管理、居然之家OA改造、海纳威生产数字化等落地场景并给出核心要素、快速入门与进阶教程实践部分以“T恤尺码收集”“设备报修”“企业进销存”“报表分析”“定时消息通知”“企业报销流程”等案例演示拖拽配置、表单流程搭建与数据收集分析读者可据此理解零代码应用的搭建思路与适用边界。目前已有6793人学习适合作为企业低代码选型与业务人员自助搭建的入门参考。1. 从一张改到第六版还在对账的 Excel 说起去年帮一个做行政的朋友看流程他们收差旅报销单靠一份 Excel 模板发到群里让大家填填完回传再手工汇总。同一批数据来回征询了六轮还是对不上。我跟他说这种收集、审批、汇总的活儿用《0 代码搭应用——宜搭开发手册》里最基础的表单加流程就能先跑起来。他原本以为零代码平台是给大公司用的翻完这 108 页的 PDF 才发现开篇就摆着一个对比同样一个差旅报销流程传统开发要 2 到 3 周用宜搭拖拽配置 1 小时就能上线。这份资料适合的人其实很明确被 Excel 和邮件夹在中间的业务同学以及手里已经有 ERP、OA想把碎片流程和主数据打通的技术同学。它不是宣传册从简介、教程到六个能照着做的实践案例跟着目录走一遍第一天就能出东西。2. 目录拆解108 页里的四个板块与四类场景这本手册的 PDF 一共 108 页目录结构相对扁平没有嵌套到三四层而是按“先认识、再入门、后动手”的顺序铺开。我按页码顺序整理了一遍开篇 1 页宜搭简介 3 到 18 页使用教程 19 到 44 页搭建实践 45 到 107 页注册与咨询 108 页。其中简介部分占了 15 页教程部分占 25 页实践部分占 63 页内容重心明显落在“动手搭”上而不是讲概念。这种分配对读者其实挺友好前面给你建立心智后面全是照着就能做的操作步骤。2.1 四个板块各管一段简介、教程、实践、接入下面是我照着目录拆出来的对照表方便你按目的直接跳读板块页码回答的问题读完能干什么开篇10 代码到底能解决什么判断自己的场景值不值得搭宜搭简介3–18能做什么、产品优势、客户案例理解能力边界和典型落地方式使用教程19–44核心要素、快速入门、进阶教程独立完成第一个表单和流程搭建实践45–107六个可复制的案例照着搭出收集、报修、进销存、报表、通知、报销注册与咨询108怎么开始用找到入口并启动第一个项目简介部分的四个小节值得细看分别是“什么是宜搭”“宜搭能够做什么”“宜搭产品优势”“宜搭客户案例”。前三节篇幅很短加起来不到 10 页主要把页面设计、业务规则定义、数据收集与分析这三项核心能力说清楚。真正有信息量的是客户案例占了 12 页每个案例都附了方案架构的描述把“哪个部门、用了哪些模块、解决了什么问题”讲得比较具体。2.2 四类典型场景平台能力边界在哪里手册里一共放了四个案例都是做深度的场景拆解不是那种“某某企业上线后效率提升 XX%”一句话带过的宣传。我按场景类型重新归了归分别是内控与审批、质量管理、OA 改造、生产执行四类。第一类是集团型的内控审批。这个场景的核心不是表单本身而是“预算、采购、合同、付款”之间的上下游联动。预算填了之后采购单据要能引用预算编号合同又要能引用采购结果最后付款还要能核对合同履约情况。手册里的方案架构拆成了预算管理、采购管理、合同管理、履约保证金四个模块每个模块都列出了需要录入的字段比如预算类型、预算编号、预算项目、预算金额、归口部门以及状态流转未执行、执行中、已执行。这段内容对做行政或采购系统的同学参考价值比较大因为它把“一笔钱从立项到付出去”需要的数据结构完整摆了出来。第二类是制造业的过程质量控制。场景特点是人多、点位多、数据要能立刻反馈成图表。手册里拆了三块关键物料上线检查、成品终检记录、供应商现场质量数据收集。每个场景都用“检验员录数据 → 图表看波动 → 异常快速响应”这条链路串起来。这里有个细节值得注意成品终检记录里要求能追溯“当时的检验记录和图片”说明表单里除了结构化字段还得挂附件。做质检类应用的同学可以重点看这段因为质量数据的追溯要求比普通表单高一个量级。第三类是 OA 系统的改造和集成。这个案例的含金量在于它明确写了集成方案不是只讲“打通了”。手册里列了五种同步方式HTTPS 数据服务实时查询并回填单据、HTTPS 回调服务审批节点提交时触发自定义处理、主数据同步人员、岗位、组织架构同步到宜搭的主数据单据、定时任务同步配好频率自动比对、手动同步通过运维应用触发。同步逻辑也写清楚了以 HR 系统为主数据单向同步用编码作唯一标识存在则更新不存在则新增。这段内容对做系统集成的人来说是最值得反复看的部分因为它把“数据从哪里来、以谁为准、怎么匹配”三个问题都回答了。第四类是生产执行。场景特点是现场设备多、数据采集自动化程度要求高。方案里提到了用摄像头和边缘服务器做工序计件数据落到系统里再自动汇总成工人一天的工作量。这块对纯软件背景的同学可能离得远一点但它说明宜搭的能力上限不只是“填表”还可以承接页面级的应用和外部硬件采集的数据。把这四类放在一起看能得出一个相对清晰的边界宜搭比较擅长“有明确字段结构、有审批流转、有统计需求”的业务场景对“强实时计算、复杂算法、海量非结构化数据”这类需求还是得靠外部系统来做宜搭负责把入口和结果收集起来。2.3 三条阅读路线业务同学、实施顾问、后端开发我自己给不同角色捋了三条读法。业务同学也就是不写代码但天天跟流程打交道的人建议直接从第 19 页的核心要素开始看完快速入门就跳到第 45 页的 T 恤尺码收集案例照着做一遍。这个案例的字段最简单只有姓名、部门、尺码、数量几个字段但把“建表单 → 配页面 → 发布 → 看数据”的完整闭环走了一遍。做完之后再回头补简介部分理解会快很多。实施顾问或者负责内部信息化的同学建议顺着目录读但重点放在第 24 页开始的进阶教程和第 75 页之后的几个流程类案例。进阶教程里会涉及流程节点、审批人设置、消息通知这些内容这些是区分“做一张表”和“做一个应用”的关键。后端开发同学可以直接跳到第 97 页的企业报销流程案例配合前面 OA 改造案例里的集成方案一起看搞清楚宜搭在这套体系里扮演的是“业务入口”还是“数据主库”的角色。这个判断很重要它决定了你后面要不要写回调、要不要做数据同步。3. 核心要素拆解页面、表单、流程三件套怎么配手册第 19 页把平台能力归纳成三个核心要素页面设计、业务规则定义、数据收集与分析。乍一看像产品介绍词但真动手搭过几个应用之后会发现这三项其实对应着三种不同的工作页面设计解决“长什么样、谁能看到”业务规则解决“填的时候有什么限制、提交之后往哪走”数据收集与分析解决“数据存哪里、怎么统计出来”。这三件事在传统开发里分别对应前端、后端逻辑和数据库在零代码平台上被压缩成了三个配置区。3.1 三项能力的职责划分与典型配置项先说说页面设计。宜搭的页面配置是拖拽式的左边是组件区中间是画布右边是属性面板。组件大致分几类基础输入类单行文本、多行文本、数字、日期、下拉选择、选择类单选、多选、级联、附件类图片、文件、布局类分组、分栏、标签页、展示类文本、图片、分割线。页面设计阶段最容易被忽略的是布局组件新手往往把所有字段平铺在一列里字段一多就变成一条长长的滚动条。常见做法是按业务含义用分组组件切成几块比如“基本信息”“费用明细”“附件材料”每一块单独设置标题填表的人一眼就能看出哪块该填什么。业务规则定义这块手册里叫“业务规则”实际包括三类字段校验、字段联动、流程流转。字段校验是“这个格子必须填什么格式”比如金额必须大于 0、手机号必须是 11 位字段联动是“填了 A 之后 B 自动变”比如选了部门之后下面的审批人自动带出部门负责人流程流转是“提交之后经过哪几个节点、每个节点谁审批”。这三类规则在宜搭里分别对应表单的校验配置、联动配置和流程设计器配置入口不一样但都属于“业务逻辑”范畴。数据收集与分析对应的是数据管理层。每一张表单提交之后都会形成一条数据记录平台会自动生成一张数据表所有记录按提交时间排列。在这个基础上可以做视图筛选、条件过滤、数据汇总也可以配置报表组件做图表展示。手册里的报表分析案例就是在这个层面做文章把收集到的数据按维度分组用柱状图、饼图、明细表展示出来。3.2 从零搭一张收集表字段、校验、联动、发布拿 T 恤尺码收集这个案例来拆这是全手册最简单的实战案例但麻雀虽小五脏俱全。需求很明确行政要统计每个员工的尺码和数量方便统一定制。需要的字段是姓名、工号、部门、尺码S/M/L/XL/XXL、数量、备注。第一步是建表单。在应用里新建一个普通表单然后把需要的字段组件拖到画布上。字段类型的选择有个小原则能用选项的不用文本能用数字的不用文本。尺码用单选组件而不是单行文本好处是提交的数据格式统一后面统计的时候不会出现“XL”“xl”“X-L”三种写法混在一起的情况。数量用数字组件并设置最小值 1、最大值 5避免有人填 0 或者填个 999。第二步是配校验。姓名和工号设为必填工号可以再加一条正则校验限制为 6 位数字。这块在宜搭的表单设置里有现成的校验规则配置不需要写代码。如果平台自带的校验规则不满足还可以挂自定义校验函数思路大概是下面这样// 表单自定义校验示例工号必须为 6 位数字且不能重复提交 // 说明不同版本的平台 API 名称可能略有差异思路一致 export function validateJobNo(value, ctx) { // 1. 格式校验 if (!/^\d{6}$/.test(value)) { return { valid: false, message: 工号必须是 6 位数字 }; } // 2. 查重调用数据服务查询该工号是否已有记录 return ctx.service .query({ formId: tshirt_collect, // 当前表单标识 condition: { jobNo: value } // 按工号过滤 }) .then(res { if (res.total 0) { return { valid: false, message: 该工号已提交过请勿重复填写 }; } return { valid: true }; }); }这段逻辑分两层第一层是纯格式校验用正则判断位数第二层是查重去当前表单的数据里查一下这个工号是不是已经提交过。第二层要比第一层慢因为它涉及一次异步请求所以放在后面做。实际配置的时候如果不想写这段代码也可以在表单设置里开启“同一字段不允许重复”效果差不多。我一般会给这类收集表都加上防重复不然统计的时候会多出一堆重复数据得手工去重很麻烦。第三步是配联动。选了部门之后如果想让审批人自动带出来需要在部门字段上挂一个数据联动数据源指向组织架构表。这个配置在表单的“联动”设置里完成选择“当部门变化时从组织架构表查询对应负责人写入审批人字段”。配置好之后填表的人就不用自己去翻审批人是谁了。第四步是发布。宜搭支持一次搭建双端适配PC 端和移动端共用一套配置发布的时候可以选择发布到哪些端。发布之后会生成一个访问链接或者二维码把链接发到群里员工点开就能填。表单提交的数据可以在后台的“数据管理”里查看也可以导出成 Excel。3.3 流程设计节点、审批人、权限和消息通知表单只能解决“收集”一旦涉及到“审批”就得用流程表单。设备报修这个案例就是典型的流程场景员工提交报修单 → 班组长审批 → 维修人员接单 → 维修完成填写结果 → 提交人确认。五个节点涉及三种角色。流程设计器里每个节点需要配三样东西节点名称、审批人或处理人、节点权限。节点名称就是流程图上显示的文字建议按业务动作来命名比如“班组长审批”比“节点 2”清楚得多。审批人可以按角色配、按部门配、按具体人员配也可以从表单字段里取比如“取提交人所在部门的负责人”。按角色配的好处是人员变动的时候不用改流程只要调整角色成员就行按具体人员配的好处是责任明确但人员离职的时候要记得回来改这是后面避坑部分会提到的点。节点权限决定了这个节点上的人能看到什么、能改什么。常见配置是审批节点只能看不能改或者只能改某几个字段比如审批意见、审批结果。这块配不好容易出问题比如维修人员节点如果给了全字段编辑权限他可能把报修人填的内容也改了后面追溯的时候说不清楚。我一般的做法是给每个节点单独配权限填报节点全字段可编辑审批节点只开审批意见和结果字段执行节点开执行结果相关字段。消息通知这块手册里单独有“定时消息通知”的案例说明这是平台的标配能力。流程表单的消息通知一般分两类节点到达通知轮到谁处理了发消息给他和流程结束通知流程走完了发消息给提交人。通知渠道通常是站内信、邮件、移动端推送配置的时候按节点勾选就行。定时消息通知则是在流程之外单独配置的比如每天早上 9 点把昨天未处理的报修单汇总发到某个群里这个用定时任务配置。3.4 报表和分析数据进来之后怎么用数据收集上来之后如果只是躺在数据表里价值其实没释放出来。手册第 86 页的报表分析案例专门讲这块。宜搭的报表能力大致分三层明细表、汇总表、图表。明细表就是把原始数据按条件筛出来展示适合“我要看具体每一条记录”的场景比如查某个员工提交的所有报销单。汇总表是按某个维度做聚合比如按部门统计报销总额、按尺码统计定制数量。图表是在汇总的基础上做可视化柱状图看趋势、饼图看占比、折线图看变化。配置报表的时候有个容易踩的点统计维度要和数据字段的类型对上。比如按“提交时间”做月度统计时间字段得是日期类型不能是文本类型按“部门”做分组部门字段得是选项或关联字段不能是自由填写的文本。这个在数据收集阶段就要规划好等数据都收上来了再改字段类型历史数据可能要清洗。4. 实践案例拆解六个案例的搭建套路与复用点手册从第 45 页到第 107 页一共放了六个实践案例每个案例都按“需求背景 → 表单设计 → 流程/规则配置 → 效果展示”的结构写。六个案例的复杂度是递进的从最简单的信息收集到流程审批再到多表联动的进销存最后到需要集成外部系统的报销流程。按难度排个序大概是T 恤尺码收集 定时消息通知 设备报修 报表分析 企业报销流程 企业进销存。4.1 T 恤尺码收集最轻量的表单加统计这个案例前面已经拆过表单部分这里补充一下它的统计侧。收集表提交之后行政需要知道两件事每个尺码各要多少件、每个部门各要多少件。这两件事对应两个汇总视图一个按尺码分组统计数量之和一个按部门分组统计数量之和。配置方式是在数据管理里新建两个汇总视图分别设置分组字段和统计字段。这个案例的复用价值在于它的模式一张表单 两个汇总视图 一个导出。凡是“报名登记、问卷收集、物资申领”这类需求都可以套这个模板。区别只是字段不同结构完全一样。我后来帮人搭过一个会议报名表就是把尺码换成餐食偏好数量换成参会人数十分钟就配完了。4.2 设备报修流程、附件、消息推送的最小闭环设备报修案例的核心是流程前面拆过节点设计这里说说附件和消息。报修单里通常要传现场照片方便维修人员提前判断问题。附件字段在表单里配置可以限制文件类型只允许图片和大小比如单张不超过 5MB。附件上传之后会存在平台的存储里表单详情页可以直接预览。消息推送这块配置的时候要注意触发时机。节点到达通知是在流程流转到该节点时触发如果审批人设置了多人比如会签每个人都会收到。流程结束通知是在最后一个节点提交后触发发给提交人。如果希望抄送给其他人可以在流程结束时配置抄送节点抄送人只读不审。这个案例的复用价值在于它是“提交 → 处理 → 反馈”这个最小闭环的标准模板。IT 报障、行政维修、客服工单结构都一样换一下字段和节点名称就能用。4.3 企业进销存主数据表加单据联动的组合拳进销存这个案例是六个里面最复杂的因为它涉及多张表的关联。手册里虽然篇幅不长但从描述能看出结构商品表主数据、供应商表主数据、采购单业务单据、销售单业务单据、库存表汇总结果。采购单里要选商品和供应商这两个字段是关联字段数据源分别指向商品表和供应商表库存表则是根据采购入库和销售出库的增减自动算出来的。这里的关键设计是主数据和业务单据分离。商品、供应商这类变化不频繁的数据放在主数据表里业务单据只存关联 ID 和当时的快照数据比如采购单价。为什么要存快照因为商品价格会变如果业务单据只存关联 ID回头查历史单据的时候显示的是当前价格而不是成交价格对账就乱了。这个细节手册里没展开写但做进销存的人应该都懂。库存的计算有两种做法一种是实时计算每次打开库存表的时候把采购入库减销售出库汇总出来另一种是定时计算每天跑一次任务更新库存表。前者实时性好但数据量大时慢后者快但有延迟。常见做法是两者结合日常查询走定时更新的库存表对账的时候走实时计算。4.4 报表分析、定时通知、报销流程三个案例的共性与差异剩下的三个案例放在一起说因为它们分别代表了三种不同的能力方向。报表分析案例的重点在数据展示层讲的是怎么把收集到的数据按维度组织成图表。这个案例的配置步骤和前面说的汇总视图差不多区别是要在前端页面上把图表组件拖出来绑定数据源。注意图表的数据源要选汇总视图而不是明细表否则数据量大时会卡。定时消息通知案例的重点在任务调度讲的是怎么配置一个定时触发的消息推送。配置项包括触发时间每天几点、触发频率每天/每周/每月、消息内容可以用模板变量取数据、接收人按角色或按群。这个能力适合做“日报推送、待办提醒、异常告警”这类需求。企业报销流程案例的重点在流程复杂度它涉及多级审批、条件分支金额超过多少走额外审批、财务复核、打款确认等多个环节。条件分支是这里的关键配置的时候要写清楚判断条件比如“报销金额大于 5000 时增加财务总监审批节点”。这个案例适合拿来练手复杂流程。把这六个案例放在一起看会发现它们覆盖了零代码平台的四种典型用法信息收集T 恤尺码、工单处理设备报修、数据管理进销存、流程审批报销。大部分企业内部的需求都能归到这四类里。先把这四类的模板搭熟后面遇到新需求改改就能用。5. 避坑与排查0 代码项目最容易翻车的五个位置零代码平台降低了搭建门槛但没有降低业务复杂度。我照着这本手册搭过几个应用也帮人排查过一些线上问题下面这五个坑是出现频率比较高的。每条按“现象 → 原因 → 解决”写方便对照排查。5.1 表单发布后打不开提示无权限现象表单在编辑态一切正常点发布之后把链接发给同事同事打开提示“无权限访问”或者直接白屏。原因宜搭的权限是独立设置的表单发布不等于对所有人开放。发布的时候需要配置访问范围可以按组织架构、按角色、按指定人员配。如果只配了“本部门可见”其他部门的人打开就是无权限。另外还有一种情况是表单绑定了流程但流程的发起权限没配也会导致打不开。解决进入表单的权限设置确认访问范围覆盖了目标人群。如果是外部人员访问需要单独开通外部分享权限。排查的时候可以用一个不在目标范围内的小号测一下能复现问题就好定位。5.2 流程走到一半卡住没人能处理现象流程提交后停在某个节点不动审批人说自己没收到待办。原因常见的有三种。一是审批人配置用了“具体人员”而那个人已经离职或者调岗账号被停用了二是审批人配置用了“表单字段取值”但那个字段提交时是空的导致找不到审批人三是节点设置了会签要求所有人都同意其中一个人长期不处理流程就一直等。解决先看流程实例的当前节点和审批人配置。如果是人员离职把配置改成按角色或按部门负责人取值这样人员变动时不用改流程。如果是字段取值为空给该字段加必填校验或者在流程里配置“审批人为空时转交给指定人员”。会签节点可以配置超时自动通过或者超时提醒。5.3 报表数字和明细对不上现象汇总报表里显示的总额和把明细导出来自己加一遍的结果不一致。原因大概率是统计口径问题。比如汇总的时候按“审批通过”过滤了但明细导出没有加这个条件或者金额字段有小数位汇总的时候四舍五入了明细里是原始值再或者有重复提交的数据没去重汇总的时候重复计算了。解决先把汇总视图的过滤条件和明细导出的过滤条件对齐确认是同一批数据。然后检查金额字段的类型和精度设置确保汇总和明细用的是同一个精度。最后检查有没有重复数据必要的话在表单上加防重复提交。5.4 接口回调收不到集成方说没数据现象流程审批通过后配置的回调接口没有收到请求下游系统里查不到数据。原因可能是回调地址配错了比如少了协议头、多了斜杠也可能是网络策略没放通还可能是回调的服务挂了或者超时了。手册里居然之家那个案例提到的 HTTPS 回调服务是审批节点提交时触发的如果节点配置里没勾选“触发回调”配了地址也不会调。解决先在平台的集成日志里看有没有调用记录。有记录但失败看返回码和错误信息没记录检查节点配置里有没有开启回调。确认配置没问题的话用 curl 手动调一下回调地址看服务本身通不通。网络策略这块找运维确认一下出口 IP 有没有加白。5.5 权限配完了用户还是看不到数据现象给用户配了表单的查看权限但他打开数据管理页面一条数据都看不到。原因宜搭的数据权限分两层一层是功能权限能不能进这个页面一层是数据权限能看到哪些数据。功能权限开了但数据权限没配用户进去就是空的。数据权限的默认值通常是“仅本人提交的数据”如果用户不是提交人自然看不到。解决在数据管理里单独配置数据权限可以按部门、按角色、按字段条件配。比如“部门负责人可以看到本部门所有人的数据”。配完之后让用户刷新一下页面权限变更有时候有缓存。6. 二次开发与验证把宜搭接进现有系统的三种姿势手册最后一个客户案例里集成方案占了不小篇幅这不是偶然。真正在企业里落地的时候零代码平台很少是孤立存在的它要么作为现有系统的补充入口要么作为主数据的采集端。我梳理了一下把宜搭接进现有系统大致有三种姿势难度和适用场景都不一样。第一种是数据单向同步适合主数据场景。人员、组织架构、岗位这类数据以现有系统为准定时同步到宜搭的主数据表里。配置方式是按编码做唯一标识存在则更新不存在则新增。这种最省事不涉及实时性要求定时任务跑失败了下一次也能补上。验证方法很简单在源系统改一条人员信息等同步周期到了之后去宜搭里查这条数据有没有更新。第二种是接口实时查询适合填单时带出数据的场景。比如员工填报销单时选了工号系统实时去 HR 查这个人的部门、岗位、上级回填到表单里。这种要求接口响应快一般控制在 1 秒以内超时了就降级成手动填写。实现方式是在字段的联动事件里挂异步请求查到了就回填查不到就提示。验证的时候要重点测异常情况接口超时、接口返回空、接口报错这三种情况下表单还能不能正常提交。第三种是回调通知适合审批完成后触发下游动作的场景。比如报销审批通过后通知财务系统生成付款单。这种要求回调接口幂等因为平台可能会重试。回调里一般带上流程实例 ID 和关键业务字段下游系统根据实例 ID 做去重。验证方法是重复触发同一个流程的审批通过动作看下游有没有生成重复单据。集成方式触发时机实时性典型场景验证要点数据同步定时任务分钟级人员、组织架构新增、修改、删除三条路径实时查询字段联动秒级填单带出主数据超时、空值、报错降级回调通知节点提交秒级审批后触发下游幂等、重试、去重最后说个我自己的习惯。每次配完集成我都会手工走一遍完整的链路在宜搭里提交一条测试数据去下游系统确认数据到了再回宜搭看状态有没有回写。这三个点都通了才算集成跑通。有一次图省事只看了回调日志显示成功结果下游字段映射配错了数据落到了错误的表里等业务反馈的时候已经积了几十条脏数据。从那以后我每次配完回调都强制走一遍端到端验证宁可多花十分钟也不留这种黑匣子。希望帮到你。本文还有配套的精品资源点击获取