RAP ABAP EML 입문: MODIFY, READ, COMMIT ENTITIES 쓰는 법

3줄 요약

• EML은 RAP 비즈니스 객체를 ABAP 코드에서 생성·조회·수정하는 문법이에요.

• BDEF에서 파생된 타입으로 입력과 응답을 준비하고, 요청의 임시 식별자인 %cid 등을 사용해요.

• 수정 요청은 먼저 트랜잭션 버퍼에 반영돼요. DB 저장은 COMMIT ENTITIES가 시작하는 저장 절차에서 이루어져요.

어떤 상황에서 쓰나요

RAP 비즈니스 객체를 배치 프로그램이나 다른 클래스에서 직접 읽고 수정할 때 EML을 사용해요. 이번 글에서는 요청과 응답의 타입을 준비하고, MODIFY ENTITIES·READ ENTITIES·COMMIT ENTITIES로 데이터를 생성·조회·저장하는 흐름을 알아봐요.

EML 수정 요청이 성공해도 곧바로 DB 저장이 끝난 것은 아닙니다. 아래 그림처럼 먼저 트랜잭션 버퍼가 바뀌고, 정해진 저장 절차를 거쳐 DB에 반영됩니다.

핵심 내용

읽기는 기본, 쓰기는 BDEF에 선언해야 해요. 읽기 작업은 BDEF에 나열된 모든 엔터티에서 암묵적으로 켜져 있지만, 생성, 수정, 삭제, 액션은 BDEF에 create;, update;, delete;, action ...;를 선언해야 쓸 수 있어요.

BDEF 파생 타입. EML 문장의 입력과 응답에는 RAP 전용 타입이 필요해요.

DATA: cr_tab        TYPE TABLE FOR CREATE root_ent,     " 입력
      mapped_resp   TYPE RESPONSE FOR MAPPED root_ent,  " 응답 매핑
      failed_resp   TYPE RESPONSE FOR FAILED root_ent,
      reported_resp TYPE RESPONSE FOR REPORTED root_ent.

ADT에서 변수에 마우스를 올리고 F2를 누르면 이 타입에 어떤 컴포넌트가 있는지 볼 수 있어요. 치트시트의 화면을 보면 create_tab 에는 CDS 엔터티의 필드(key_field, field1 …) 말고도 %로 시작하는 RAP 전용 컴포넌트가 있어요. 이름이 CDS 필드와 겹치지 않게 %를 붙인 것이고, %cid(요청 안의 임시 키), 필드마다 플래그를 담은 %control, 그리고 여러 필드를 한 이름으로 묶은 컴포넌트 그룹 %data(기본 키와 데이터 필드 전부)와 %key가 있어요.

% 컴포넌트가 무엇이 있는지는 BDEF 정의와 시나리오에 따라 달라요. 예를 들어 임시 ID 인 %pid는 늦은 채번(late numbering)에서만, draft 표시 %is_draft는 draft 에서만 쓰여요.

만들기 (MODIFY ... CREATE)

• 입력 테이블은 VALUE #( ( %cid = 'cid1' key_field = 1 field1 = 'A' ) ... )로 채워요. %cid는 쓰지 않더라도 지정하고 요청 안에서 유일해야 해요.

• FIELDS ( key_field field1 field2 ) WITH cr_tab: 어느 필드를 반영할지 지정해요. 목록에 있는 필드는 %control 플래그가 켜지고(if_abap_behv=>mk-on), 없으면 꺼져서 값이 무시돼요.

• 짧은 형태와 긴 형태(여러 엔터티를 한 요청에), 동적 형태가 있어요.

MODIFY ENTITY root_ent
  CREATE
  FIELDS ( key_field field1 field2 ) WITH cr_tab
  MAPPED mapped_resp
  FAILED failed_resp
  REPORTED reported_resp.

읽기 (READ ENTITIES)

• 읽기는 항상 결과를 돌려줘야 해서 RESULT가 필수예요. 읽은 값은 트랜잭션 버퍼의 현재 상태이고 아직 저장하지 않은 수정도 포함돼요. 버퍼에 없으면 managed 시나리오에서 저장된 값을 자동으로 버퍼에 읽어 와요.

• ALL FIELDS WITH로 전체 필드를 읽고, 입력 타입(TYPE TABLE FOR READ IMPORT)에는 키만 넣어요.

READ ENTITIES OF root_ent
  ENTITY root_ent
  ALL FIELDS WITH VALUE #( ( key_field = 1 ) ( key_field = 2 ) )
  RESULT DATA(result)
  FAILED DATA(f)
  REPORTED DATA(r).

• 연관으로 읽기(BY \_child)는 부모→자식과 자식→부모 모두 되고 LINK로 키 연결 정보를 받을 수 있어요.

RAP 트랜잭션의 단계. 치트시트는 한 RAP 트랜잭션을 상호작용 단계와 저장 순서로 나눠요. 아래 그림이 그 흐름이에요.

• 상호작용 단계: 핸들러 클래스(CL_ABAP_BEHAVIOR_HANDLER를 상속)의 핸들러 메서드가 불려요. 데이터는 트랜잭션 버퍼에서만 바뀌므로 버퍼가 일시적으로 일관되지 않아도 DB는 일관된 채로예요.

• 저장 순서: COMMIT ENTITIES가 일으켜요(OData 같은 RAP 직접 지원 시나리오에서는 RAP가 자동으로 호출). 저장 클래스(CL_ABAP_BEHAVIOR_SAVER를 상속)의 메서드가 정해진 순서로 불려요.

• 이른 저장 단계(선택): finalize(최종 계산, managed 에서는 ON SAVE 결정이 여기서 불려요), check_before_save(일관성 검사, ON SAVE 검증), 실패하면 cleanup_finalize를 거쳐 상호작용 단계로 돌아가요. 이때 COMMIT ENTITIES 뒤 sy-subrc는 4 예요.

• 되돌릴 수 없는 지점 이후 늦은 저장 단계: adjust_numbers(늦은 채번에서만 최종 번호 부여), save(managed의 추가/비관리 저장에서는 save_modified)가 버퍼를 DB에 쓰고, 문제가 없으면 암묵적 COMMIT WORK이 실행돼요. 마지막에 cleanup이 버퍼를 비워요. 원칙은 늦은 저장 단계에서는 실패가 없어야 한다는 것이고, 어쩔 수 없는 경우를 위한 CL_ABAP_BEHAVIOR_SAVER_FAILED가 있어요.

핸들러 메서드의 시그니처는 ADT의 F2로 확인할 수 있어요. create의 예를 보면 입력은 entities(TYPE TABLE FOR CREATE ...)이고, 응답 파라미터 mapped, failed, reported는 changing으로 암묵적으로 들어와요.

저장 (COMMIT ENTITIES)

• RAP 저장 절차를 시작해 버퍼의 수정이 DB에 반영돼요. 이 문장이 없으면 DB에 아무 영향이 없어요. OData 같이 RAP가 직접 지원하는 시나리오에서는 자동으로 실행돼요.

• COMMIT WORK를 암묵적으로 포함하지만 성공이 보장되지는 않아서 sy-subrc를 확인하도록 안내해요.

• 동작 구현(behavior implementation) 안에서는 COMMIT ENTITIES를 쓸 수 없어요.

• ROLLBACK ENTITIES, GET PERMISSIONS, SET LOCKS, 비즈니스 이벤트 발생시키기, 동작 풀 안의 IN LOCAL MODE 같은 추가 구문도 치트시트에 정리돼 있어요.

주의할 점

• IN LOCAL MODE, AUGMENTING 같은 추가 구문과 단계별로 허용되거나 금지되는 작업의 표는 이 글에서 다루지 않았어요. 동작 구현 안에서 EML을 쓰기 전에는 치트시트의 "RAP 트랜잭션 데이터 일관성" 절을 읽으세요.

• RAP 예제는 비교적 최근 릴리스(원문 기준 7.56 이상 필요)에서 동작한다고 치트시트 저장소의 README가 안내해요. 내 시스템 릴리스를 확인하세요.

• 치트시트는 계속 갱신되는 문서예요. 첫 공개는 2022년이고, 제가 읽은 판은 2026년 10월 기준이에요. 이 글은 읽고 정리한 것이고 예제를 직접 실행해 보지는 않았어요.

원문 주소: https://github.com/SAP-samples/abap-cheat-sheets/blob/main/08_EML_ABAP_for_RAP.md