LabHub
学习 学习路径 课程

系统间对接 (EAI)

IDoc、RFC、BAPI — ERP 那边的人说的话

在 LabHub 中继续学习

一句话总结

SAP 集成首先需要的不是 ABAP 知识，而是一张术语地图——理解 IDoc、RFC、BAPI、tRFC、qRFC 各自提供什么保证，才能在会议中做出决定。

概念图: 听不懂对方在说什么 · 同一订单的变更报文乱序到达 · IDoc · 文档交换格式

为什么这是个问题

遗留系统集成中，我们之所以处于不利位置，不是技术太难，而是听不懂对方在说什么。如果无法当场判断“使用 tRFC 还是 qRFC”，决策就会被推迟，而被推迟的决策通常会按对方最方便的方式确定后再通知我们。

差异最终都会变成我们的工作。若商定的方式不保证顺序，我们就必须在我方拦截同一订单的变更报文乱序到达；若不防重复，就必须自行实现幂等处理。理解术语不是常识修养，而是谈判能力。

接手 SAP 集成时

在韩国大型企业项目中，ERP 通常是 SAP，我们开发的系统需要与它交换数据。会议中常会听到这样的话。

“那个用 IDoc 接收就可以，实时部分通过 RFC 调 BAPI。 至于是 tRFC 还是 qRFC，再协商决定。”

如果听不懂，就无法当场决定任何事情。先整理术语。

术语 是什么 何时使用
IDoc Intermediate Document，SAP 标准文档交换格式（异步） 大批量、批处理、EDI
RFC Remote Function Call，远程调用 SAP 函数 实时查询／处理
BAPI 通过 RFC 暴露的标准业务函数（Business API） 标准业务处理
tRFC transactional RFC，保证只执行一次（防重复） 数据变更
qRFC queued RFC，tRFC + 顺序保证 顺序重要的变更
ALE Application Link Enabling，在系统间分发 IDoc 的体系 IDoc 路由

只需记住一组对比：IDoc = 异步文档，RFC/BAPI = 同步函数调用。 tRFC/qRFC 则是 SAP 侧解决“防重复”和“保证顺序”的方式，正对应前一模块讨论的问题。

IDoc 的结构

一个 IDoc 由三部分构成。

Control Record (제어 레코드)  ← 딱 1개. "이 문서가 무엇이고 어디서 어디로"
  IDOCTYP  기본 타입 (예: ORDERS05)
  MESTYP   메시지 타입 (예: ORDERS)
  SNDPRN   송신 파트너
  RCVPRN   수신 파트너
  DOCNUM   IDoc 번호
  CREDAT   생성일자

Data Records (데이터 레코드)  ← 여러 개. 세그먼트 단위
  SEGNAM   세그먼트 이름 (E1EDK01, E1EDKA1, E1EDP01 ...)
  HLEVEL   계층 레벨 (부모-자식 관계)
  SDATA    실제 데이터 — 고정길이 문자열 1000자

Status Records (상태 레코드)  ← 처리 이력
  STATUS   상태 코드 (03 전송, 51 오류, 53 성공 ...)

核心是 SDATA。 一个段的所有实际值都放在一个1000 字符的定长字符串中。因此，解析 IDoc 就是根据段名找到布局，再按位置切分 SDATA。

这与上一模块的定长格式解析完全相同。IDoc 看似陌生，其实实际操作已经练习过。

常见段

订单（ORDERS）系列中经常见到以下段。

段 含义 代表字段
E1EDK01 头部（整份文档） BELNR（文档编号）、CURCY（货币）
E1EDKA1 合作方信息 PARVW（合作方角色）、PARTN、NAME1
E1EDK02 参考文档 QUALF、BELNR
E1EDP01 项目 POSEX（项目编号）、MENGE（数量）、MENEE（单位）
E1EDP19 项目引用（物料代码） QUALF、IDTNR（物料编号）

HLEVEL 表示层级，因此在 E1EDP01 下方会挂接 E1EDP19。转换为 JSON 时必须保留这种层级。

IDoc 状态码

运维时掌握常见状态即可。

代码 含义
03 已发送至外部系统（出站）
12 发送完成
51 未生成应用文档（错误），最常见
53 成功生成应用文档
64 等待处理
68 取消处理（忽略错误）

“IDoc 掉到 51”表示数据已经到达，但 SAP 内部业务处理失败，并非传输失败。不能区分这一点，双方就会一直争论“我们已经发了”和“我们没有收到”。

实际设计时要确定什么

SAP 集成设计会议中，需要真正决定以下事项。

  1. 方向与方式——我们发送还是接收，使用 IDoc 还是 RFC
  2. 中间经过什么——直连、经过 EAI 中心，还是经过 PI/PO
  3. 键映射——连接 SAP 客户编号（KUNNR）与我方客户 ID 的表。这张映射表是集成的心脏。 没有它，任何工作都无法进行
  4. 错误处理——出现 51 时由谁查看、谁修复，必须与 SAP 负责人协商
  5. 重发——再次发送相同 IDoc 时，是生成重复文档，还是忽略

第 3 项尤其重要。不同系统用不同 ID 指代同一个对象：SAP 的 KUNNR=10001、销售系统的 ACC-00001、我方系统的 CUST-001。只有建立连接三者的交叉引用（cross-reference）表，集成才能成立。如果各方都通过硬编码解决，六个月后就会无人敢改。

遗留系统集成的一般原则

即使不是 SAP，遗留系统集成也有共同原则。