TT Lab
Get started
Learn Learning paths Courses

System Integration (EAI)

IDoc, RFC, BAPI — The Words the ERP People Use

Continue in TT Lab

Summary

What you need first in SAP integration is not ABAP knowledge but a map of the terms — if you know what IDoc, RFC, BAPI, tRFC, and qRFC each guarantee, you can make decisions in meetings.

Why this is a problem

The reason we stand in a disadvantageous position in legacy integration is not that the technology is hard but that we cannot understand what the other side says. If you cannot decide on the spot in a meeting "whether to go with tRFC or qRFC," the decision is postponed, and a postponed decision is usually settled in the way that is convenient for the other side and then notified to us.

That difference later becomes our work. If you agree on an approach with no ordering guarantee, we have to filter cases where the change messages of the same order arrive in swapped order on our side, and if the approach has no duplicate prevention, we have to build idempotent handling. Knowing the terms is not a nicety but bargaining power.

When you are assigned SAP integration

In large Korean enterprise projects, the ERP is usually SAP, and the system we build has to receive data from it or send data to it. In that situation, meetings bring up statements like this.

"You can receive that with IDoc, and for real time, call a BAPI over RFC. Let's discuss whether to go with tRFC or qRFC."

If you do not know what that means, you cannot decide anything on the spot. Let us sort out the terms first.

Term What it is When to use
IDoc Intermediate Document. SAP's standard document exchange format (asynchronous) Bulk, batch, EDI
RFC Remote Function Call. Remotely calls an SAP function Real-time lookup/processing
BAPI A standard business function exposed via RFC (Business API) Standard business processing
tRFC transactional RFC. Guarantees execution only once (duplicate prevention) Data changes
qRFC queued RFC. tRFC + ordering guarantee Changes where order matters
ALE Application Link Enabling. A framework for distributing IDocs between systems IDoc routing

There is one contrast to remember. IDoc = asynchronous document, RFC/BAPI = synchronous function call. And tRFC/qRFC are SAP's way of solving "duplicate prevention" and "ordering guarantee," the very problems covered in the previous module.

The structure of an IDoc

One IDoc consists of three parts.

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 성공 ...)

The key is SDATA. The actual values of the segment are held whole in a 1000-character fixed-length string. That is, parsing an IDoc is finding the layout by the segment name and cutting SDATA by position.

It is exactly the same work as the fixed-length parsing done in the previous module. So even if an IDoc feels hard, your hands have already learned the actual work.

Segments you often meet

The ones you actually see often in the order (ORDERS) family.

Segment Meaning Representative fields
E1EDK01 Header (the whole document) BELNR (document number), CURCY (currency)
E1EDKA1 Partner information PARVW (partner role), PARTN, NAME1
E1EDK02 Reference document QUALF, BELNR
E1EDP01 Item POSEX (item number), MENGE (quantity), MENEE (unit)
E1EDP19 Item reference (material code) QUALF, IDTNR (material number)

HLEVEL indicates the hierarchy, so the structure is one where, under E1EDP01, E1EDP19 is attached. When you convert to JSON, you must preserve this hierarchy.

IDoc status codes

It is enough to know the statuses you see often in operation.

Code Meaning
03 Sent to the external system (outbound)
12 Dispatch complete
51 Application document not created (error) ← the one you see most
53 Application document created successfully
64 Waiting for processing
68 Processing canceled (error ignored)

"The IDoc dropped to 51" means the data arrived, but the business processing inside SAP failed. It is not a transmission failure. If you cannot tell this apart, "we sent it" and "we did not receive it" run in parallel lines forever.

What to decide when designing in practice

The items you actually have to decide in an SAP integration design meeting.

  1. Direction and method — do we send or receive? IDoc or RFC?
  2. What is in between — direct, through an EAI hub, through PI/PO?
  3. Key mapping — a table linking SAP's customer number (KUNNR) and our system's customer ID. This mapping table is the heart of the integration. Without it you can do nothing
  4. Error handling — when a 51 occurs, who looks and who fixes? It cannot be decided without consultation with the SAP-side owner
  5. Resending — what happens if you send the same IDoc again? Is a duplicate document created, or is it ignored?

I want to emphasize item 3. Each system calls the same subject by a different ID. SAP's KUNNR=10001, the sales system's ACC-00001, our system's CUST-001. You need a cross-reference table linking these three for the integration to hold. If each side starts solving this with hardcoding, six months later nobody can touch it.

General principles of legacy integration

Even if it is not SAP, legacy integration has common principles.