华为MetaERP 元数据驱动是什么、微服务是什么、元数据 vs Oracle EBS/Fusion 的表字段、微服务 vs Oracle 存储过程/API。最后给一张可直接拿去汇报的对比表。一、华

元数据驱动是什么、微服务是什么、元数据 vs Oracle EBS/Fusion 的表字段、微服务 vs Oracle 存储过程/API。最后给一张可直接拿去汇报的对比表。一、华为 MetaERP 里的「元数据驱动」到底是什么核心一句话传统 ERP 是“代码里写死业务”元数据驱动是“用数据描述业务引擎读数据生成功能”。1. 三层结构传统 vs 元数据驱动传统 EBS 风格代码 数据库表加一个“项目参考号”字段 → 改表结构、改 Form、改 PL/SQL、改报表、发版MetaERP 元数据驱动引擎 元数据 物理表加同一个字段 → 在元数据层建一条“对象采购订单 / 字段项目参考号 / 类型文本 / 必填否”的记录元数据引擎自动建列或映射到扩展存储、生成 UI、校验、权限、API、列表、导出2. MetaERP 元数据管什么不是只管“字段名”而是管一整条业务骨架业务对象订单、物料、凭证、核算维度字段属性类型、默认值、校验、可见性、跨租户覆盖关系一对一、一对多、父子级联流程状态机、审批路由、条件分支规则会计引擎映射、计税规则、信用检查界面列表、表单、仪表盘布局权限角色对对象/字段/操作的访问控制3. 一个具体例子会计科目COAOracle EBS公司段部门段科目段项目段拼成CCID弹性域大宽表维度固化在字符串里加维度要重构科目结构MetaERP把 COA 拆成核算单元 / 自然科目 / 核算维度​ 三块元数据维度是独立元数据可动态增删事件进来 → 会计规则也是元数据→ 自动出多维凭证注意元数据驱动不等于 EAV 万能宽表。现代做法含 MetaERP 思路是“元数据描述结构物理层仍用正常关系表或动态 ORM 映射”避免 EAV 性能灾难。二、微服务在 MetaERP 里是什么角色核心一句话把一个巨型 ERP 单体按业务域拆成几百个独立部署、独立库、通过 API/事件说话的服务。1. 拆分粒度以财务链为例应付微服务有自己的表t_ap_invoice*采购微服务t_po_*会计引擎微服务t_journal_*主数据微服务维度/元数据微服务每个服务独立代码仓库、独立容器、独立 DB Schema对外只暴露声明式 API 事件内部爱用啥索引、啥表结构自己定2. 跨模块怎么协作EBS同一个 Oracle 库里PL/SQL 直接INSERT应付表再UPDATE采购分布表一个事务搞定MetaERP应付服务落本地事务发“发票已录入”事件 / 调会计服务 API会计服务自己落凭证失败用Saga 补偿事务不是数据库级 rollback3. 微服务的代价必须知道分布式事务变最终一致不能像 EBS 那样“全成功或全回滚”跨服务查询要做 CQRS / 只读副本 / 聚合层运维复杂度高K8s、服务网格、链路追踪三、元数据 vs Oracle EBS / Fusion 的「数据库表字段」这是你问题里最容易被混淆的一点元数据不是替代表而是“表的上面再盖一层描述层”。维度Oracle EBS / Fusion 物理表字段MetaERP 元数据本质业务数据的真实存储位置GL_JE_LINES.ENTERED_DR就是钱关于“有什么对象/字段/规则”的描述数据存在元数据表或元数据服务里谁定义甲骨文产品组写死客户改要 AD 补丁/个性化平台预置 租户管理员在界面配加字段路径新建列 → 改 PKG → 改 OAF/Form → 迁移元数据加记录 → 引擎决定落物理列还是扩展表表样例PO_HEADERS_ALL,GL_CODE_COMBINATIONS,AP_INVOICES_ALLMETA_OBJECT对象定义、META_FIELD字段定义、META_WORKFLOW业务含义绑定表名和列名即含义但规则在 PL/SQL 里含义、校验、标签、权限全在元数据里物理列可能只是col_128多租户差异靠_ALL表 ORG_ID 过滤结构全局统一标准元数据全局租户元数据叠加互不影响升级影响升 EBS R12 经常要跑 adop、处理客户化失效核心引擎升租户元数据兼容迁移即可关键区别一句话EBS 的“字段”是物理存储 代码含义MetaERP 的“元数据字段”是逻辑定义物理落库由引擎翻译可能真建列可能进扩展表可能进 JSON 半结构化列Fusion 比 EBS 好一点有更多配置化、OTBI、弹性字段但底层仍是“预定义表结构 部分扩展”不是 MetaERP 那种“对象/流程/规则全元数据化”。四、微服务 vs Oracle 存储过程 / API1. Oracle 存储过程PL/SQL Package位置在数据库内部和表在同一个 Oracle 实例能力直接读全表、游标、触发器、自治事务、CCID 校验事务原生 ACID一个COMMIT跨应付/总账/库存扩展改 PKG 要数据库权限版本靠文件加载痛点业务逻辑沉到 DB应用层变薄无法跨非 Oracle 库难以容器化2. Oracle EBS 的 API形式xxx_pub.create_invoice这种 PL/SQL 包包装的“API”或 OAF 的 AM/VO本质仍是库内调用外面 Java/Form 过来走 JDBC 调包限制绑定 Oracle 技术栈水平扩展靠 RAC 堆机器3. MetaERP 微服务位置独立进程/容器可能连 GaussDB、可能连 Redis、可能只存事件能力自己决定怎么存跨服务靠 HTTP/gRPC/消息队列事务本地 ACID 跨服务最终一致Saga/事件补偿扩展服务独立发版A 服务升级不影响 B对外标准 RESTful / gRPC 声明式 API前端和低代码平台直接消费对照表维度Oracle PL/SQL 存储过程Oracle EBS Pub APIMetaERP 微服务运行位置Oracle DB 内Oracle DB 内被外部调独立容器/K8s跨模块写数据直接跨表写一个事务调包间接跨表写仍同库事务只写自己库跨模块发事件/API一致性强一致强一致最终一致补偿技术绑定死绑 Oracle死绑 Oracle自主栈GaussDB/欧拉扩容RAC 纵向/横向受限同左按服务独立 HPA 扩容改逻辑改 PKG 重编译改 PKG改某个服务镜像低代码/AI 接入难要懂 PL/SQL难易API元数据即描述五、把四件事串起来MetaERP 的全局画面元数据驱动解决“业务怎么描述”对象、字段、流程、规则、UI 都是数据微服务解决“代码怎么部署”按域拆开各管各的表和事务元数据引擎读元数据 → 动态生成物理表 DDL / CRUD SQL / 表单 / API 路由微服务把这些能力按“应付”“总账”“采购”切成独立运行时→ 所以 MetaERP 里你配元数据引擎建表你调微服务 API服务按元数据校验后写自己的物理表。反观 Oracle EBS表是甲骨文建的你动不了核心规则在 PL/SQL 里你改要会写 Package模块靠同库事务粘在一起你拆不出去