在SAP MDG项目里摸爬滚打过的朋友一定遇到过这个需求上游系统或者历史数据清洗工具不打算给操作人员开一堆GUI和Web UI权限却想让物料、供应商、客户的新增和变更规规矩矩地走一遍MDG的治理流程。这时候最省事的方案就是让API直接在主数据治理模块里生成一张变更请求草稿。很多刚接触MDG的同事会把它想成往数据库表里插一条数据真不是。MDG的草稿背后是一整套状态机、临时数据区、业务规则和工作流逻辑API接口生成草稿的方法不是“insert一条记录”这么简单。理解它的运行机制之后你才能选对接口方式、改对配置避免交付一个能跑但没法上线的半成品。这篇文章我会从业务场景讲起把API创建草稿的原理、三种主流路径、前置配置、代码骨架和踩坑经验一次性说清楚适合正在实施MDG、或者准备做MDG与外围系统集成的顾问和开发参考。如果你只是临时想改一条物料描述建议直接关掉这个页面去用界面操作如果你的目标是把整个数据变更流程自动化那这篇文章值得看完。1. 为什么放着现成界面不用非要API创建草稿1.1 一个从项目里带回来的真实场景我上次做的项目里客户有一条自主研发的PLM系统研发人员在PLM里完成物料设计后同一套数据还要落到SAP MDG里走主数据治理流程。如果让研发人员再去MDG的Web UI里手工建变更请求、复制粘贴几十个属性就会出现三个问题第一PLM和MDG两边数据靠人肉搬运错误率很高。第二物料属性多的时候手工填写至少耽误半天。第三领导想追踪这个新增请求是从哪个PLM记录发出的根本查不到。后来我们做了一个集成接口PLM生成唯一请求标识通过API发送到MDGMDG侧自动创建变更请求并将状态置于草稿等主数据专员在界面里补充审核意见、做进一步加工后再提交审批。这就是API创建草稿最典型的价值——数据生成过程可以自动化但治理流程的控制点一个都没少。1.2 API创建草稿到底解决了什么从技术上说API创建草稿做了三件事在MDG的变更请求管理里注册一个新的治理对象也就是CR号。将源系统的数据以草稿形式写入MDG的临时数据区不污染正在使用的激活区数据。为接下来的业务校验、审批、激活保留一个可演进的版本。对比人工流程差别很清楚维度人工Web UI创建API创建草稿数据录入人工录入错误率受操作者状态影响程序化写入稳定可靠触发方式无法在业务发起系统内自动触发可被上游系统、调度任务自动触发批量处理一条条处理效率低可批量、可并发需要做好锁控制审计链路依赖操作日志从头到尾可追溯直接关联源系统业务主键规则校验界面实时提示由MDG规则统一校验消息结构化返回1.3 适合谁不适合谁如果项目的诉求是把上游系统数据无缝进入MDG流程API草稿是最理想路径如果只是偶尔想改一条物料的文字描述用MDG界面操作反而更快。另外特别不建议拿API创建草稿去逃避规则校验——我见过有的团队为了方便绕开MDG的staging区直接改激活区的MARA表后果是MDG后续的变更追踪和审批链路全部失效这种暴力方案等于把治理工具变成了一张普通数据表。2. 变更请求草稿在MDG里的真实身份2.1 草稿不是一张表是一套状态机老有人问草稿存在哪张表 这个问题不好回答因为草稿在MDG里不是一个物理表概念而是一个状态机概念。MDG把主数据变更都装进名为变更请求Change RequestCR的容器里。这个容器有状态刚创建的时候是草稿状态可以修改、可以补充数据数据准备完成后提交审批审批通过后做激活把数据写入生产区激活完成后状态封存。你完全可以把CR理解成一套带红绿灯的数据快递链路。业务人员通过界面创建变更请求时MDG界面自动建了草稿状态API创建草稿则是把同一件事通过程序化方式完成不打开界面但背后的数据流没有任何不同。2.2 数据模型与实体MDG是按数据模型管理主数据的。物料有一个模型供应商/客户有一个模型财务主数据又是另一个模型。每个数据模型由若干实体组成例如物料模型里通常包含基本视图、分类视图、扩展字段等一个变更请求可以同时承载同一个实体的多条记录甚至承载同一模型下不同类型的变更。关键点是API不是往一个扁平表里塞数据而是要告诉MDG你要在哪个数据模型的哪个实体下发起哪条记录的变更意向。所以调用API之前先弄清楚目标系统的数据模型结构比写代码更花时间。2.3 草稿数据落在哪里MDG系统里有两类数据区。一类是激活区存的是当前有效的主数据比如物料的MARA、客户KNA1、供应商LFA1另一类是临时区staging存的是尚未生效的候选数据。API创建草稿后新数据进入的是临时区以变更请求号作为区分标识等审批通过后MDG的激活机制会把这些数据写进激活区的正式表里。用术语讲草稿写的是暂存版本激活写的是有效版本。提示永远不要在API集成里直接UPDATE激活区的主数据表。这在技术上是可行的但在MDG治理语义上是作弊会造成审计断链。前东家有同事这么干过一次后来补了半个多月的数据。3. 三种API路径的选型与调用姿势3.1 路径ASAP内部ABAP环境用Function Module/BAPI如果数据源本身就在同一个SAP系统里或者你有RFC连接直接在ABAP里调用MDG提供的标准Function Module/BAPI是最轻量的一种路径。这类函数在版本间命名有些差异通常带MDG_或者USMD_前缀例如创建变更请求、向变更请求添加数据、保存并提交校验等。这个方式的好处是性能好、方便在SE37里调试、不用折腾网络协议坏处是只能由SAP系统发起外部系统想用需要包一层代理接口。我一般建议在MDG系统里封装一个自定义RFC函数把创建CR写数据保存捆绑成一个业务操作上游系统只需要传一个业务参数结构。3.2 路径BOData/REST API这几年SAP对外接口全面往OData/REST方向迁MDG也提供了标准OData服务外部系统可以直接用HTTP方法调用在API Hub上能找到相关服务的定义。用OData创建草稿的姿势通常分两步先调一个创建变更请求的POST拿到返回的CR号再往该CR下面写属性集合。也有服务支持一步到位把CR头皮和明细数据放在同一个请求体里一次调用就生成完整的草稿。大概长这样{ dataModelId: MDG_M_MATERIAL, changeRequestType: MAT01, externalId: PLM-2025-00123, entity: MATERIAL, keyFields: { MATERIAL_ID: NEW-MAT-001 }, attributes: { MATERIAL_TYPE: HERS, BASE_UOM: ST, DESCRIPTION: TECHNICAL SAMPLE MATERIAL } }真实调用的字段名会根据数据模型、OData版本有所差别但这个整体结构是通用的告诉MDG模型是什么、变更类型是什么、外部唯一标识是什么、实体主键是什么、要写入的属性有哪些。3.3 路径CSOAP WebService / IDoc再传统一点如果企业已经有了ESB企业服务总线或者希望走标准的SOAP接口MDG同样支持通过Web Service发布变更请求的操作。这种方式的特征是强类型、有WSDL、接口契约清晰适合对接总线型集成平台。IDoc路径更多用于大批量数据同步不一定是先创建草稿再审批有时候直接就是创建激活。所以如果你的业务要求先草稿不让生效要确认IDoc配置的动作类型别一个不小心把半成品冲到激活区。3.4 三种路径怎么选我用一张表总结自己的判断逻辑路径适用场景通信方式实时性实施复杂度Function Module/BAPI源系统是SAP或内部ABAP程序RFC/内部调用高低OData/REST API外部Java/.NET/Python系统HTTPS/JSON中高中SOAP/IDoc已有ESB、需要强契约、大批量同步SOAP/HTTP或ALE中中高我的经验是能走OData就走OData因为它标准、容易在PI/CPI里配也容易被外围系统接受要是纯粹想快速打通内部联调就用Function Module封装有ESB传统架构的项目再考虑SOAP/IDoc。选型没有绝对的对错关键是你现有基础设施能支撑哪种调用方式。4. 让API能顺利创建草稿的前提清单4.1 权限与角色配置API调用的是人是人就要权限。很多接口调不通第一锅查出来都是授权错误。在MDG系统里不管是RFC用户、Web Service用户还是OData服务用户都要分配相应的MDG角色至少包含创建/修改变更请求的权限访问对应数据模型的权限如果涉及提交审批还要有提交动作的授权这些权限通常通过PFCG角色挂到服务用户上。我的建议是把接口服务用户建成专用账号不要用SAP_ALL也不要直接复用业务操作员账号否则后面审计的时候说不清哪个程序建了这条CR。4.2 数据模型与业务规则是否就绪API创建草稿不是上线那一刻就天然可用。你得先在MDG里把数据模型激活把BRFplus规则集部署好把必填字段、默认值、字段推导配好。为什么这个顺序很重要因为API调用实际上是最严格的业务规则体检——如果BRFplus里配了某个字段的默认值那API可以不传如果配了必填不传就会报错如果字段有从属关系比如物料类型决定某些字段是否可见规则没配好接口就会收到一堆莫名其妙的校验消息。先上线规则、再开放接口这是我不变的顺序。4.3 服务激活与端点配置OData服务要先在SICF里激活SOAP服务要在SOAMANAGER里完成端点配置RFC目标要在SM59里配好。常见的服务不可用问题很多不是代码问题而是服务压根没激活或者路径大小写不对或者SSL配置出错。上线前建议把端点的烟雾测试全部跑一遍健康检查、空CR创建、带完整数据的草稿创建、重复调用幂等测试。4.4 批导工具与分发配置如果你的场景是一次性海量历史数据清洗不一定非要写自定义API——MDG自带的文件传输工具FTT、加载与校验工具LYT也能实现文件导入后生成草稿。它们的思路是把Excel/CSV上传后按配置逐行创建CR适合数据迁移阶段。如果是激活后还要分发到下游系统预留DRFData Replication Framework是必须的。DRF负责在CR激活后将主数据分发到ECC、CRM等系统。很多项目一开始忘配DRF结果API已经能把数据治理好了下游系统没拿到排查一圈才发现是分发配置缺失。5. 实操示例从一个空的变更请求到带数据的草稿5.1 第一步获取或创建CR号不管走哪种API先要拿到一个CR号。以ABAP内嵌调用为例通常流程是确定数据模型和变更请求类型。调用创建CR的函数传入模型、类型、外部标识。检查返回值成功则拿到CR号。伪代码大概是这样的风格DATA: lv_cr_number TYPE usmd_change_request. 以实际类型定义为准 CALL FUNCTION MDG_CR_CREATE 示意名称以系统SE37为准 EXPORTING iv_data_model MDG_M_MATERIAL iv_change_request_type MAT01 iv_external_id PLM-2025-00123 IMPORTING ev_change_request lv_cr_number EXCEPTIONS OTHERS 1. IF sy-subrc 0. MESSAGE CR创建成功: lv_cr_number TYPE S. ELSE. 这里要做错误日志并回滚任何前置操作 ENDIF.创建CR时如果有外部标识字段一定要把上游系统的业务主键塞进去。这是后面做追溯、查重、幂等控制的关键。5.2 第二步向临时数据区写主数据拿到CR号之后往该CR下添加一条或多条实体数据。这里通常不是直接INSERT临时表而是调用MDG提供的数据写入函数或OData的实体集操作让MDG自己完成临时区落盘。伪代码思路DATA: ls_material TYPE some_mdg_material_structure. 结构以数据模型为准 ls_material-material NEW-MAT-001. ls_material-material_type HERS. ls_material-base_uom ST. CALL FUNCTION MDG_CR_ADD_ENTITY_DATA 示意名称以系统SE37为准 EXPORTING iv_change_request lv_cr_number iv_entity MATERIAL is_data ls_material.外部系统用OData时就是调对应资源下的POST结构跟前面JSON示例一致。这里必须提醒一点一次调用不要塞太多条记录。如果你要生成1000条草稿分100个调用包做而不是一个请求体10万行。SAP后端对单次API操作的资源消耗有上限把大批量拆分是更稳的姿势。5.3 第三步保存并触发校验数据写入不是自动保存草稿也得确认一下。业务系统里的保存动作在MDG API里对应一个提交校验动作。调用后MDG会执行BRFplus校验把不符合规则的消息返回给调用方。不要忽略校验返回的消息列表。很多集成团队把这个当噪声忽略但消息里往往带着字段名、规则ID、错误类型是定位问题最好的线索。5.4 第四步验证草稿确实生成保存成功后可以从几个层面验证用MDG工作台或对应事务码打开CR号能看到草稿状态下的待处理数据。直接查询临时区的数据表确认记录关联了正确的CR号。如果系统配置了消息日志确认没有W或E级别的未处理消息。验证这个环节很容易被省略但我不建议省。有一次我们就因为源系统传了全角空格数据进入草稿后所有文本字段都带隐藏字符如果当时多看一眼草稿内容一个批次就能发现问题而不是事后返工。6. 接口上线后的监控确认草稿状态与定位问题的三条路径6.1 从变更请求状态反查草稿API创建完草稿业务顾问第一个动作往往是打开MDG的界面输入CR号看数据在不在。这个动作很有用因为在界面上能看到状态、消息、待处理事项是判断草稿是否真正创建成功的最直观方式。如果你在命令行里执行事务码注意看CR的状态字段。它跟草稿、处理中、提交、激活等状态是一一对应的。如果显示的是草稿状态说明整个链路走通了如果直接显示已激活那你就要警惕是不是IDoc或者OData服务配置的动作类型选错了把本该停下的草稿直接冲到了激活区。6.2 直接翻阅staging区数据表有些问题在界面层看不出来比如字段值传对了没有、隐藏字符、大小写转换、默认值有没有被正确填充。这时候要去临时区数据表看。MDG的临时区表名通常以USMD_开头并且带上数据模型相关字段或者通过CR号关联的组织结构表来查。你可以用SE16N直接根据CR号过滤看这条草稿记录在临时区的真实值。这里有个小技巧比较“源系统传入值”和“staging区实际落库值”。如果两者不一致八成是BRFplus的派生规则或者转换规则动了手脚如果一致但校验报错那问题就出在规则条件的判断逻辑上。6.3 从API调用日志和消息队列看链路如果是外部系统调OData或RFC中间还有CPI/PO这类中间件建议在每一个跳点保留日志。我们用的方案是外部系统侧记录完整请求报文和响应报文。中间件侧留存调用日志包括HTTP状态码、耗时、目标服务路径。MDG侧在自定义封装函数里写应用日志记录CR号、操作类型、传入数据摘要。三层日志对比下来九成问题能在十分钟内定位。最怕的是各环节都没日志出了问题只能靠猜。7. 我在项目里踩过的坑和优化建议7.1 坑一外部请求没有幂等设计最常见的问题是重复调用。上游系统网络超时后自动重试结果MDG这边生成了两条CR看起来像两个不同的请求实际上源头是同一个PLM记录。后来我们在集成层做了一张映射表用外部业务主键判断这个请求是否已经创建过CR创建过就直接返回旧CR号绝不再建第二次。这个表本身不复杂但能避免后续大量重复数据清理工作。7.2 坑二BRFplus校验函数的性能MDG的草稿校验往往会触发多条BRFplus规则如果你在上游传入了大量字段规则执行时间会明显拉长。我们曾遇到一个接口初始化到一半因为某条对字段历史值的校验规则要扫大量数据单次调用耗时飙升到分钟级。解法是从三方面下手优化校验规则本身的查询逻辑、把不必要的字段逐出接口、以及给API调用设置合理的超时时间与异步化处理方案。7.3 坑三并发与锁的冲突同一批数据并发创建CR时如果数据模型里配置了唯一性检查两条并发调用可能在同一时间都认为该物料不存在结果双双创建成功。解决思路是串行化关键路径或者用SAP锁机制锁住对应的主数据键值再就是依赖MDG自带的重复检查配置。我们团队最后的方案是在自定义RFC封装层加一个串行队列把同一物料编号的请求排成FIFO。损失了一点吞吐量但再没出现过并发重号。7.4 坑四状态理解不到位误把草稿当激活这是业务层面的坑。API创建草稿后数据并没有生效如果下游业务系统的读取视图直接查了激活区会觉得接口没传过来啊。集成文档里必须把状态机写清楚草稿、审批中、已激活是三个不同阶段对业务系统而言只有已激活数据才具备对外使用的效力。否则接口验收的时候业务会说你的接口有问题其实是状态理解不一致。7.5 优化建议封装、日志与清理有几件日常操作值得坚持将创建CR、写数据、保存封装成一个内部接口而不是让每个集成场景各自拼代码。封装层可以统一处理权限、日志、异常、幂等后续维护成本低很多。每次调用记录请求报文、响应报文、CR号关联日志排查时救命。定期清理长期停留在草稿状态的废弃CR避免临时区膨胀影响性能。增加告警当某个API批次校验失败率超过阈值时通知集成与MDG负责人。结尾的几句实话如果你正在做类似的MDG集成方案我的建议是先别急着动手写API调用代码把状态机、数据模型、BRFplus规则和权限这四件事想清楚再去选接口路径。这条顺序我踩了快一个项目周期才体会到分享出来希望能帮你把API创建草稿这条路走得更顺。