简介SAP两大批处理工具BDC与LSMW的使用详解资料面向SAP顾问、数据迁移及运维人员帮助解决系统内批量数据录入与旧系统数据迁移等效率问题。包内含1个docx文档共2.49MB主要以图文结合的Word文档呈现便于按章节阅读与检索。文档从SHDB录屏开始完整演示物料账期逐月打开等真实场景涵盖脚本录制、字段修改、导出模板、邮件合并生成批量脚本及前台/后台执行等内容同时对LSMW从项目对象创建、源与目标结构定义、转换规则到数据传输的14个标准步骤逐一说明适合不同规模的数据处理任务。资源已有1749人学习对于希望系统掌握SAP批处理操作、提升数据维护效率的读者具有较强参考价值。1. 打开 SAP 批处理的正确姿势BDC 和 LSMW 到底怎么分工做过 SAP 数据导入的人十有八九都被问过同一个问题“这块用 BDC 还是 LSMW”如果你翻开论坛或者问身边的顾问答案往往分成两派老 ABAP 偏向 BDC说不就是录个屏再回放做成程序还能定时跑数据迁移和后勤模块的人偏爱 LSMW说简单、弱代码、业务顾问自己就能上手。这两个工具的界限其实很清晰——BDC 本质是「录屏 代码回放」LSMW 本质是「映射表 引擎驱动」。选哪个不取决于个人习惯取决于数据量、来源格式和后续是否自维护。本文不打算把两个工具的界面按钮照着文档念一遍而是按一线实施的使用场景来拆什么情况该用 BDC 写程序、什么情况该上 LSMW 建 Mapping、两种方案各自的参数设置和典型翻车点分别在哪里。适合正在做数据迁移、接口开发或者日常批量维护的 SAP 从业者——不管是业务顾问还是 ABAP 开发花十分钟看完回去就能照着搭一套自己的批处理方案避开让人头疼的锁表、格式转换和重复执行的大坑。2. 用 BDC 做批量录屏回放入库SHDB 录制与 CALL TRANSACTION 双玩法2.1 BDC 的两种底层回放机制先搞清楚再动手BDC 全称 Batch Data CommunicationSAP 从老早的 R/3 时代就提供的一套批处理机制。它的核心思路非常简单粗暴把人操作 SAP 画面的过程录下来然后在后台按同样的顺序再次走一遍。录制时系统记录的是每个屏幕上的字段名、程序名、屏幕号和输入值所以本质上是「事务码的自动化回访」。常见的回放方式有两种这个必须分清楚因为后续参数设置完全不同。第一种叫 Session Method会话法典型代码是BDC_INSERT加BDC_TRANSACTION开一个批输入会话。它的特点是数据先进批输入队列由 SM35 事务码在后台异步执行。也就是说调用程序只负责把动作序列放进队列真正跑数据的是 SM35 里面的处理进程。这种方式的优势是出错不阻塞主流程处理不了的记录留在队列里人工修订。第二种叫 Call Transaction Method调用事务法ABAP 代码里直接写CALL TRANSACTIONFB60 USING bdcdata...完全同步执行。每一笔数据的动作序列会立刻在该逻辑单元中跑完实时返回消息。这种方式的好处是你对每一笔数据都有完全控制权——随时随地抓到 SY-SUBRC 错误码可以针对某几行做异常处理。缺点是慢而且如果中途某行出问题处理不当会留下半截数据。实际操作中大批量数据迁移我几乎不用会话法原因下面会细说会话执行的出错排查太折磨人黑匣子一样看不到实时状态。2.2 录制完整流程从 SHDB 到生成源码落地一个 BDC 程序前第一步永远是录制。我建议的顺序是先手工完完整整走一遍业务操作把流程跑通再去录。很多人一上来就录录到一半发现某个必填字段漏了或者弹出了意料之外的弹窗返工成本很高。录制路径事务码SHDB- 新建录制 - 给一个录制名比如 ZBDC_MM01_CREATE→ 输入要回放的事务码 MM01 回车 → 系统开始记录你的每一步操作。完成所有操作后保存SHDB 里就有了一段记录。录完不能直接用。你要做的是进入 SHDB 列表找到这条录制点「程序」按钮SAP 会自动把这段录制生成一段 ABAP 代码。生成的代码大致长这样DATA: BEGIN OF bdcdata OCCURS 0. INCLUDE STRUCTURE bdcdata. DATA: END OF bdcdata. DATA: gt_messtab LIKE bdcdata OCCURS 0 WITH HEADER LINE. * 屏幕进入 CLEAR bdcdata. bdcdata-program SAPLMGMM. bdcdata-dynpro 0060. bdcdata-dynbegin X. APPEND bdcdata. * 字段输入 CLEAR bdcdata. bdcdata-fnam RMMG1-MBART. bdcdata-fval 001. APPEND bdcdata. * 回车进入下个屏幕 CLEAR bdcdata. bdcdata-fnam BDC_OKCODE. bdcdata-fval ENTE. APPEND bdcdata.生成的代码里有几个关键结构bdcdata-program是当前屏幕所属的程序名bdcdata-dynpro是屏幕号dynbegin X表示这是一个新屏幕的起点紧接着 APPEND 的若干条fnam/fval是该屏幕上需要填的字段名和值。BDC_OKCODE是功能码相当于你点的按钮ENTE就是回车。这段代码的逻辑很清楚先声明一个内表承载所有屏幕动作然后按顺序填充「进屏幕 → 填字段 → 触发功能码」三个动作的循环。但生成出来的代码是死数据直接拿去用每次跑的屏幕值都一样。要变成可用的批处理工具核心改造点是把 FNAM/FVAL 对应的值从常量替换成内表变量。2.3 把录制代码改造成可传参的批处理程序实际落地时我不会把录制的代码拉出来直接改。更标准的路径是自定义一个带输入内表的处理程序把 SHDB 录出来的屏幕结构当作模板用变量的值去填充。常见做法是这样先创建一个输入结构比如从 Excel 或者后台表拉出来的主数据数组然后循环每一行动态构造 BDC 数据内表。这里有一段核心骨架DATA: lt_bdcdata TYPE TABLE OF bdcdata, ls_bdcdata LIKE LINE OF lt_bdcdata. * 针对单条物料主数据创建 BDC 屏幕序列 FORM build_bdc USING ls_mara TYPE zsmara. 输入数据容器 CLEAR ls_bdcdata. ls_bdcdata-program SAPLMGMM. ls_bdcdata-dynpro 0060. ls_bdcdata-dynbegin X. APPEND ls_bdcdata TO lt_bdcdata. CLEAR ls_bdcdata. ls_bdcdata-fnam RMMG1-MBART. ls_bdcdata-fval ls_mara-mbart. APPEND ls_bdcdata TO lt_bdcdata. CLEAR ls_bdcdata. ls_bdcdata-fnam RMMG1-MATNR. ls_bdcdata-fval ls_mara-matnr. APPEND ls_bdcdata TO lt_bdcdata. CLEAR ls_bdcdata. ls_bdcdata-fnam BDC_OKCODE. ls_bdcdata-fval ENTE. APPEND ls_bdcdata TO lt_bdcdata. ENDFORM.参数说明ls_mara是上游传过来的单条数据容器ls_bdcdata-fval接受的是一个字符型值所以数字、日期等类型必须统一转换成字符串再塞进去BDC_OKCODE是画面跳转的开关值不同动作就不同比如ENTE是回车、BACK是返回。这里有个非常容易翻车的细节program和dynpro的取值必须和录制的画面完全一致一旦有投射或者增强导致屏幕号变了BDC 会把数据填到错误的字段上不报错但数据错位极难发现。2.4 用 CALL TRANSACTION 带回数据处理逻辑与消息捕获屏幕序列构造好了接下来是执行和结果捕获。我喜欢用 CALL TRANSACTION 的同步模式并且使用带消息表的形式DATA: lt_messtab TYPE TABLE OF bdcmsgcoll, ls_msg LIKE LINE OF lt_messtab. CALL TRANSACTION MM01 USING lt_bdcdata MODE N UPDATE S MESSAGES INTO lt_messtab. IF sy-subrc 0. LOOP AT lt_messtab INTO ls_msg. 收集每条消息记录物料号便于事后报表 ENDLOOP. ENDIF.参数说明MODE控制屏幕显示方式N表示完全不显示画面——后台静默跑调试时用A会显示出错瞬间的屏幕建议小数据量联调用A跑大批量再用N。UPDATE的S是同步更新数据库L是本地更新远端数据迁移时用S容错更可靠。消息表lt_messtab是这里的关键每条执行完的记录SAP 会把屏幕上的所有消息含报错、警告、成功信息收集进来你再根据MSGID、MSGTY做判断。常见做法是把报错的行收进一个日志内表跑完批量再一起输出。LOOP AT lt_messtab INTO ls_msg WHERE msgty E. 条数据报错记录错误信息到日志 ENDLOOP.注意MSGTY的值E表示错误W警告S成功A中断。实际做批导时不能只看sy-subrc因为有的业务校验不返回程序级异常而是在屏幕消息里用警告形式体现——比如物料号已存在时可能返回 W 而不是 E导致你以为数据进去了实际被拦截了一半。3. LSMW 做数据迁移的工程化配置五种导入方法怎么选、映射怎么搭3.1 LSMW 到底比 BDC 多做了哪几件事LSMWLegacy System Migration Workbench是 SAP 官方提供的数据迁移工作台虽然长得像个事务码界面但它做的远不止「录屏回放」。如果你把 BDC 定位成「自动化操作员」LSMW 更像一台「数据交换机」——它有完整的导入结构定义、字段映射、转换规则和文件管理器业务数据到 SAP 字段的翻译工作才是它的重头戏。同样导物料主数据BDC 要求你写代码去处理格式转换和字段对应LSMW 里这一切全部变成配置源字段选哪个、目标字段填哪个、日期格式怎么处理、出错的文件扔到哪个文件夹全在界面上操作ABAP 代码量接近于零——这是它最大的价值也是很多业务顾问能自行维护的原因。值得注意的是 LSMW 不止支持录屏法Recording这一条路径。进入 LSMW 后新建一个项目里面第一步就是选导入方法常见有五种方法简称全称适用场景数据来源Standard Batch标准批输入大批量、字段固定文本文件Recording录屏法任何有事务码的操作通用的录屏回放BAPIBAPI 接口有现成 BAPI 的场景文本或代码IDoc中间文档异步集成、复用接口IDoc 文件Object业务对象特定对象模型可复用 BDC 集实操上能用 IDoc 和 BAPI 的场景我优先用它们因为报文有结构性校验、查错方便。但真实项目里大量定制事务并没有现成 BAPI所以录屏法依然是 LSMW 用得最广的导入方式。录屏法的 LSMW 本质就是 BDC 的「配置化封装」你把录屏录好再把文件字段拖到录屏字段上LSMW 引擎自动执行回放。3.2 LSMW 录屏法全流程最小闭环照着走就能通我以一个固定资产主数据迁移为例把录屏法的最小可用流程捋出来。在 LSMW 里新建项目按下面顺序操作第一步定义源结构。在子步骤里维护源结构Source Structures有多少个文件字段就建多少字段建议直接复用文件类型的字段名减少后面映射的混淆。嵌套结构在复杂对象里有用但普通物料、资产导数据用平面结构就够了。第二步定义源字段。在字段属性里把源字段一个个列出这里要注意数据类型选择——文本、数字、日期、时间、浮点这些不同类型在后续转换规则里处理方式不一样尤其日期后面会专门讲坑。第三步维护映射关系。这是整个 LSMW 配置里最核心、也最容易看花眼的环节。进入映射界面后左侧是目标字段来自录屏右侧是源字段来自文件中间划一条线就把对应关系建好了。目标字段的名字可能长得像BSEZ-ZWELS你一眼看不出含义的字段可以直接用 F1 帮助查元素文档。第四步读取数据。在「读取源数据」步骤里上传或指定你的文件路径系统会把文件内容读进 LSMW 的内部缓冲区。这里常见一个误操作——不先维护「文件到源结构」的固定格式约定就上传系统会用默认的 TAB 分隔去解读字段对不上。LSMW 的文件格式设置里分固定长度和分隔符两种分隔符用分号还是 TAB读入效果完全不同。第五步转换和导入。转换是执行你之前配好的映射规则系统会生成一个「转换后的数据」底表导入才是真正执行 BDC 回放把数据写入 SAP 系统。很多人分不清这两步错误地把转换当成了导入导致数据停留在系统缓存里没进库。3.3 字段映射里的转换规则与日期格式坑LSMW 的映射不只是「字段对字段」的划线它还在每个映射关系上支持转换规则。双击一条映射线就能看到转换规则列表常用的有几种转换规则作用使用场景CONSTANT固定值填充比如每个资产的资产类别固定为 1000MOVE直接搬值同类型字段直接映射RANGE范围映射对数值区间做个判断再填值X translators组合多个源字段比如把名称 描述拼成一个文本DATE日期格式转换比如把 YYYYMMDD 转成 SAP 内部格式日期格式这块是 LSMW 最典型的坑。源文件里写的是20230615SAP 屏幕期望的可能是2023.06.15或者06/15/2023这跟系统用户的个人日期格式设置直接相关。如果在文件定义阶段你没把日期字段标记为 Date 类型LSMW 会拿字符串直接去填日期字段系统往往不报错内部存储的却是错误日期。表现就是导完后查表发现日期比源文件少了一天或乱码——这种脏数据进了财务账非常难收拾。3.4 LSMW 的批输入会话建议为什么我推荐先建会话再跑LSMW 的最后一步导入界面里有几个选项其中「处理模式」和「更新模式」很关键但真实项目里更值得花心思的是「创建批输入会话」这个选项。很多人图省事直接选「在前台导入」让 LSMW 逐条画面弹出来。数据量几十条行能接受上千条就灾难现场了——你要在屏幕前点一整天的回车。更优的做法是勾选创建批输入会话LSMW 会把所有记录打包成一个批输入会话然后去 SM35 里执行。这样既能批量跑又能在出错时保留未处理记录反复修正而不是整批重来。更新模式的选择有一点经验之谈完工数据用S同步测试阶段用L本地更灵活。如果测试阶段直接用同步更新一旦数据进库你要么用错误日志反查、要么手动删测试数据非常不划算。本地更新模式下跑挂了只要回滚数据库后台表是干净的。4. 两种工具的典型翻车场景与排查路径避坑要从现象抓到根源4.1 现象一BDC 跑完大量成功消息数据却没变表现CALL TRANSACTION 返回的消息表全是S类型程序也没报错去查 SAP 表发现数据根本没写入。原因这个坑最常见于BDC_OKCODE设置不对。录制时你走的最后一步如果多点了一次保存按钮生成的代码里会多一个SAVE和一个BACK而回放时屏幕在某个中间节点弹出了不同的确认画面导致后续动作全部在错误的屏幕上下文里执行。表面看每个动作都被执行了实际逻辑单元没有完成提交。解决重新录制。录制过程中每一步都核对屏幕标题和操作按钮尤其是最后保存的环节精简掉冗余的动作。另外检查 CALL TRANSACTION 的 UPDATE 参数L模式下数据只更新到本地缓冲进程结束未提交时就会丢。4.2 现象二LSMW 文件读进来全是乱码或字段错位表现中文乱码数字列跑到文本列里日期变得毫无规律。原因文件编码和字段分隔符不匹配。LSMW 读文件时如果源数据文件是从 Excel 导出的 CSV默认可能是 GBK 或 UTF-8而 LSMW 端设定的文件格式是按 SAP 系统的代码页解析的。另一个常见原因是 Excel 导出 CSV 时逗号放在文本内容里整个字段被切开。解决统一文件编码为 UTF-8带 BOM 更稳分隔符改为分号并且在 LSMW 的文件格式定义里明确指定分隔符。导入前先用记事本看一眼原始文件的原始内容确认字段分隔正确再进 LSMW。4.3 现象三批处理执行中提示「系统锁定」表现跑大批量 BDC跑到两三百笔时突然报出TD 行锁竞争或短期锁等待超时程序挂起。原因SAP 数据库行锁或对象锁竞争。多个批处理会话同时操作同一张表或者后台有其他任务占了某条主数据的写锁。BDC 和 LSMW 批执行基本都是短事务一个事务没提交前锁不释放批量并发就积累成死锁。解决错峰执行避免高峰期跑大批量大批量拆分成若干小批次比如每次 500 条中间加等待时间让锁资源释放。在后续版本可以适当调整运行参数但最直接的始终是控制单批数据的体量。4.4 现象四部分数据进库了重新批量会重复建记录表现第一次跑挂了回头查看 SM35 会话发现未处理条目改了几笔数据后再次全量执行已经处理完的记录被重复创建主数据混入多条一模一样的内容。原因批处理没有幂等控制。BDC 回放时系统正统地按事务逻辑执行屏幕上有「该物料已存在」的判断时普通录屏不会处理这种场景数据只会往后追加。LSMW 如果录屏法是直接调用事务码同样不检查是否已存在。解决从源头做控制。BDC 场景在程序里提前按业务主键查表已存在的记录跳过LSMW 场景增加一个「存在性检查」字段映射——比如物料号建立在 MATN1 上把 MATN1 作为固定判断条件通过公式规则让已存在的记录直接给出警告而不执行导入。数据迁移前对源文件做一次剔除重复处理永远是值得的。4.5 现象五功能码相同但屏幕行为不一致表现同一段 BDC 代码在测试环境顺利通过在生产环境某一步屏幕弹出了不同的弹窗字段填错位直接报错。原因系统增强或配置差异。屏幕上的字段状态可能因模块配置不同而不同——比如物料屏幕测试环境没启用批次管理生产环境启用了屏幕就会多出批次字段后面的字段顺序全被顶乱。解决用批量模式联调时加MODE A观察一遍执行全程确认生产环境屏幕与测试环境一致。手段比较土但能在分批前规避大量脏数据。如果是自定义程序可以在代码里用SY-BATCH判断当前模式在调试模式下打印每条 BDC 屏幕动作的序号便于快速锁定提前弹出的屏幕。5. 混合方案的进阶用法用 LSMW 搭模板用 BDC 补盲区时间久了你会发现LSMW 和 BDC 不是互相替代的关系而是可以组合的。LSMW 配置好一套录屏映射后数据还是得走批处理会话执行而 BDC 程序里遇到复杂的文件解析和格式转换又没有 LSMW 界面那么直观。所以我的习惯是把两者当一个流水线用LSMW 负责把外部文件的脏数据清洗、转换、映射成标准屏幕值BDC 负责处理 LSMW 搞不定的定制界面和复杂校验。一个具体的用法是针对 LSMW 录屏法无法直接覆盖的屏幕字段组合比如某些自定义增强屏幕你可以把 LSMW 的录屏录制停在一个中间屏幕剩下那几步单独用 BDC 程序去补。这样配置工作量和 ABAP 开发量都不大还避免了全写程序时维护困难的尴尬。另外一个技巧是验证导入结果。无论 BDC 还是 LSMW跑完一定要用另一个事务码去反查数据库底表而不是只看界面提示。比如导物料主数据跑完用 MM03 抽查几笔数据确认扩展字段、文本字段和视图都创建完整导会计凭证用 FB03 抽查科目和金额是否正确——界面提示的成功不全等于业务正确这是做了多年数据迁移最大的教训。常说批处理能提高效率但我更愿意强调它的代价出错时错误是批量生产的所以验证环节省不得。希望这套方法能帮你在自己的批处理任务里少走弯路。工具不难精准的配置习惯和到位的验证才是硬功夫。本文还有配套的精品资源点击获取