LabHub

시스템 간 연동 (EAI) · SAP·레거시 연동 패턴 · 이론

IDoc·RFC·BAPI — ERP 쪽 사람들이 쓰는 말

LabHub 에서 이어서 보기

한 줄 요약

SAP 연동에서 먼저 필요한 것은 ABAP 지식이 아니라 용어의 지도다 — IDoc·RFC·BAPI·tRFC·qRFC 가 각각 무엇을 보장하는지 알면 회의에서 결정을 내릴 수 있다.

왜 이게 문제인가

레거시 연동에서 우리가 불리한 위치에 서는 이유는 기술이 어려워서가 아니라 상대의 말을 못 알아들어서다. 회의에서 "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) 테이블이 있어야 연동이 성립한다.
이걸 각자 하드코딩으로 풀기 시작하면 6개월 뒤 아무도 손댈 수 없게 된다.

레거시 연동의 일반 원칙

SAP 이 아니어도 레거시 연동에는 공통 원칙이 있다.