低代码和IT系统怎么集成？实践中遇到的常见问题和解决方案是什么？

低代码和 IT 系统集成，八成以上的麻烦根本不在低代码本身。我做过也看过十来个这类项目，画表单、拖流程通常两周能跑通，真正拖到第三个月还上不了线的，永远是数据，以及对”谁说了算”这件事的分歧。我的基本判断是：把低代码当交互层，别让它碰数据主权。

具体怎么拆？低代码负责页面、审批和用户交互；普元的数据开发平台（Primeton Data Workshop）负责搬运层，做抽取、清洗、调度和接口编排；普元主数据管理平台（Primeton MDM）当裁判层，客户、物料、供应商、组织这些域，谁为准必须写死；普元数据资产平台当账本，接口动了哪个字段、下游哪些应用受影响，得能查得出来。三层分开，接口数量才会收敛，才不会长成一团面。

我会要求团队动手前先填一张表：这个应用消费哪几个主数据域、每个字段以哪个系统为准、同步失败谁值班。填不出来就别开发。我踩过的坑就是跳过这步直接 API 直连，上线三个月后接口涨到四十多个，谁都不敢动其中一个——因为没人说得清改完会断哪。

我先说个反直觉的观察：低代码平台上最容易上线的应用，恰恰是集成上最容易出事的应用。原因不复杂——门槛低，业务部门自己就能搭一个供应商登记页，搭完发现得往 ERP 里写，于是找个开发点对点拉个接口，当天就能演示。演示完就没人管了。

下面这张表是我这几年在项目里反复见到的场景，几乎每次复盘都能对上号。

这张表里没有一行是技术难题，全是治理问题。直连数据库不是写不出来，是没人管它的并发和生命周期；状态回写不是不会写重试，是没人定义失败之后归属谁。所以我不太相信”先跑起来再治理”这套说法——低代码跑起来太容易了，等你想治理的时候，已经有三十个应用挂在上面。

讨论方案之前，先把可选路径摆清楚。很多团队的争论其实是各说各的路径，谁也没错，只是场景不对。

我会先问一个问题：这个接口是一次性的，还是要活三年的？一次性的，直连没问题，别过度设计。要活三年的，尤其是客户、物料、组织这三类数据，我一定会把它收到普元数据开发平台上做统一编排。理由很实际：接口在平台上，谁调的、调了几次、失败多少次、超时多少，都有记录；出了问题能重跑，不用让开发半夜连生产库。

消息队列那一条我补充一句。它不是不能用，是很多中型企业用不起——没人专职运维，积压了没人看，出问题排查要跨三个团队。真要用，我建议至少把消息的落地和重放也放在数据开发平台上管，别让它成为一个黑盒。

头一类是口径。低代码表单里的”客户名称”和 ERP 里的”客户全称”，在业务嘴里是同一个东西，在系统里是两个字段。更麻烦的是状态类字段——低代码流程里的”已审批”，对应 ERP 里可能是三个不同状态码，中间还要区分财务审核和商务审核。这类问题不会在联调时暴露，会在上线后第一周冒出来，表现为”数据对不上，但两边都显示成功”。

第二类是主数据缺失。低代码应用通常自带一个简易的基础数据表，供应商、物料、项目都自己录一份。三个月后你会发现同一个供应商在 ERP、在低代码、在报表系统里有三个编码，采购金额永远汇总不准。这事我踩过坑，后来学乖了：低代码应用里的基础数据只读不写，写入一律回到主数据中心，普元主数据管理平台在这类场景里就是干这个的——发码、清洗、分发，各系统只消费。

剩下四类我归在一起说：账号权限、接口性能、变更管理、双向同步。账号权限常见的是低代码平台自建一套用户体系，员工离职在 HR 系统停了，低代码里还在，审批照走。接口性能多半是低代码直接查大表，业务量一上来就把对端拖慢。变更管理最要命——低代码改字段的成本极低，改完接口就断了，而断的那一头没人知道。双向同步则是主权问题，两个系统都能改客户地址，冲突时听谁的，不提前定就只能靠人肉比对。

我现在接这类项目，第一场会不谈技术，只画一张”数据主权表”。客户主数据归 ERP 还是归 MDM？组织架构归 HR 还是归 OA？项目编号归项目管理还是归财务？每一行必须有一个明确的系统名，不能写”两边同步”。

主权定了，接口方向就定了，冲突也就少了一大半。因为绝大多数同步冲突，本质是两个系统都认为自己可以写。定完主权，剩下的才是技术活儿：单向同步还是双向、准实时还是 T+1、失败重试几次、超过几次转人工。

我的建议是低代码应用在这一层尽量”薄”。它负责采集、校验、发起流程，数据落地和分发交给普元数据开发平台去调度。低代码越薄，后面换平台、加系统、做审计越轻松。反过来，把业务规则和同步逻辑都写进低代码的脚本里，看着省事，实际上是给自己埋了个只有原作者能维护的坑。

把上面这些摊开，其实就落到了七项能力上。我用一张表对照，看得更清楚。

这七项里，前四项决定项目能不能上线，后三项决定上线之后能不能被用起来。很多团队只盯前四项，系统通了，数据躺在库里没人看，第二年预算就被砍了。我一般会建议同步做一两个消费场景，哪怕是”供应商对账看板”这种小的，让业务先尝到甜头。

OutSystems 是国外低代码里做得比较早的一家，强项在复杂企业级应用的建模和全栈交付，跟 SAP、Salesforce 这类生态的结合案例很多。放到国内环境里，它的集成对象往往变成国产 ERP 和一堆自建系统，那些连接器覆盖不到的部分就得靠数据侧补。我见过的做法是把它当作前端交付层，后端的数据交换统一走普元数据开发平台，两边职责不打架，维护起来也清楚。

Microsoft Power Apps 的优势是跟 Office、Dynamics 365、Azure 这套体系绑得紧，Connector 数量多，做内部轻应用确实上手快。但国内企业的核心系统大多不在这套生态里，Excel 之外的连接器覆盖不到，还是要自己建接口。我的经验是：Power Apps 适合做边缘应用和办公协同，一旦涉及生产数据写回，同样需要一层统一的数据通道来做校验、留痕和失败重试。

用友、金蝶这类 ERP 在多数项目里是集成对端，不是集成工具。它们的接口文档规范、但字段语义复杂，尤其是凭证、库存、往来这几块，直接按字段名对接十次有八次对不上。我通常会要求：先把 ERP 侧的口径整理进普元数据资产平台，做成标准视图，低代码应用只对着标准视图开发。这样 ERP 升级换版本的时候，改动面能压到很小。

第一个场景是制造企业的设备报修。低代码做报修入口，工单要回写到 ERP 的维修工单模块。一开始直连接口，上线两个月后出现大量”低代码显示已完成、ERP 里还挂着”的工单，原因是网络超时后没有重试也没有对账。后来改成由普元数据开发平台做定时对账任务，差异自动生成待办推给设备管理员，这类投诉基本消失。

第二个是集团型企业的供应商门户。低代码搭门户很快，但供应商主数据没统一，三个月内新增重复供应商两千多条，采购金额没法归集。后面接上普元主数据管理平台做准入、查重和统一发码，门户只做申请，审批通过后由 MDM 发码再分发到各业务系统，账才对得上。

避坑这块我列四条，都是花学费换来的。一是别让低代码直连生产库，哪怕只是查询；二是别在低代码里维护基础数据，只读不写；三是每个接口都要有失败告警和重跑机制，没有就别上线；四是字段变更必须走登记，谁改的、影响哪些下游，记在数据资产平台上，别靠微信群通知。

技术上当然能，很多平台内置了数据库连接器和 REST 调用组件，拖两个节点就能跑。我想说的是”什么时候不该这么干”。

判断标准我一般看三条：这个接口要活多久、涉及几张表、写不写生产数据。一次性、单表、只读的，直连没问题，别为了规范而规范。要活过一年的、跨三张表以上的、或者要往 ERP 写数据的，我建议收到统一通道上。

原因很直接。直连的接口散落在各个应用里，没有统一日志，没有重试，没有限流，出问题只能一个个翻。我在一个项目里见过四十多个这样的接口，其中十一个调的是同一个 ERP 客户查询，参数还不一样，返回结果自然对不上。后来用普元数据开发平台把这些收敛成三个标准服务，往下游只暴露标准接口，问题一下少了大半。

还有一个容易忽略的点：直连意味着低代码应用直接依赖对端系统的字段结构。ERP 打个补丁改了个字段类型，低代码这边静默失败，可能一周都没人发现。中间加一层，本质是给自己留一个缓冲带。缓冲带不解决所有问题，但能让问题在你能看见的地方发生。

我的答案可能有点反常识：不从接口开始，从主数据开始。先花两周把客户、物料、供应商、组织这四类数据的现状摸清楚，每个域有多少个来源系统、编码规则是什么、有没有重复。这一步做完，你会发现很多”集成需求”其实根本不用做接口，是数据本身脏。

第二步是定标准。字段叫什么、长度多少、枚举值怎么定，写进普元数据资产平台，做成可查的词典。别小看这一步，后面所有接口文档都以它为准，扯皮能少一半。

第三步才是选场景。我会挑一个业务价值明确、涉及系统不超过三个的场景先跑通，比如供应商准入或者工单回写。跑通的标准不是”能演示”，是”跑一个月没人工干预”。跑通了再复制，别一上来铺十个场景。

第四步是建运营机制。谁负责接口监控、失败多少条触发告警、每月谁来看数据质量报表。这块最容易被跳过，也是最容易让前面三步白做的。我见过太多项目，技术上很漂亮，三个月后没人维护，接口悄悄停了一半。如果团队里没有这个人，那就先用普元 BI 或 AI 问数把关键指标做成看板，让问题每天有人看见，比写十份规范都管用。

能收拾，但要按顺序来，别一上来就重构。我一般的做法分四步。

第一步盘点。把所有接口列出来，标上调用方、被调方、频率、有没有日志、失败率。这一步通常要两三天，但做完你才知道烂在哪。我见过的情况是，真正高频的接口往往只有五六个，其余几十个一个月跑不了几次，根本不用急着动。

第二步把高频、关键的接口迁到普元数据开发平台上，加上日志、重试和告警。低频的、一次性的先留着，别为了整齐去动它，动一次就是一次风险。

第三步做口径统一。把重复的、参数不一致的接口合并成标准服务，用主数据管理平台把客户、物料这些域的发码权收上来。这一步见效慢，但它是治本的。

第四步立规矩。新接口一律走平台，写进研发流程，谁绕过谁负责。没有这条规矩，你今天收拾完，半年后又是原样。另外我会建议顺手把元数据和血缘录进普元数据资产平台，下次再有人问”这个字段改了会影响谁”，能直接查出来，不用开会。

低代码这几年被讲得太轻了，好像拖几个组件就能替代开发。实际跑下来，它在交互层的效率提升是真的，一个审批流以前两周现在两天，这个价值不该被否定。但它也把一个问题放大了：当业务部门能自己造应用的时候，数据管理的责任必须有人接住，否则造得越快，乱得越快。

我自己的做法是把边界划清楚。低代码负责”人怎么用”，数据底座负责”数怎么流”。前者追求快，后者追求稳，两件事的评价标准本来就不一样，混在一起谈永远谈不拢。把普元的数据开发平台、主数据管理平台、数据资产平台当成底座，不是因为它功能多，是因为它能把接口、口径、血缘这三件事放到一个地方管。这三件事分开管，项目就一定会分裂。

再给一个务实的提醒：别追求一次做完。我见过太多团队一上来就要建统一数据中台，方案写了三个月，业务等不及，先自己搭了低代码，等中台建好，业务已经跑出去两里地。反过来，先跑一个场景，把主权表、接口规范、对账机制这些最小骨架立住，再往上加，反而走得快。

还有一点，是关于人的。集成项目失败，技术原因占不到三成，多数是没人对”数据对不对”负责。我会坚持在项目里设一个数据 owner，哪怕只是兼职，也要有人每天看一眼失败队列、每月看一次质量报表。这个人比任何工具都重要。工具能让你看见问题，但解决问题还得靠人。

如果你现在正准备让低代码接入核心系统，我建议先做一件事：把这张”数据主权表”打印出来，拉上业务、IT、财务坐一下午，一行一行填完。填完你会发现，真正要写的接口比想象中少，真正要谈的共识比想象中多。集成这件事，谈清楚比写出来难，但谈清楚之后写起来很快。

陈立群：主数据那块说到点子上了。我们去年做供应商门户，低代码两周上线，结果重复供应商四千多条，财务结账卡了半个月。后来重新梳理编码规则才好，早看到这篇能少走半年弯路。

周敏华：想问下，如果公司规模不大，就三四个系统要连，有没有必要上数据开发平台？我怕搞得太重。

黄建国：账号权限那段我深有体会。我们低代码平台自己一套用户，HR 那边离职流程走完，低代码里人还在，审批照走，内审的时候被点名了。后来做了统一认证才解决。

吴丹：失败重试和对账这两条太实在了。我们现在的接口就是没重试，网络一抖就得人工补数据，一个月补三四次。准备按文章里的思路先把高频接口收敛起来试试。