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

3줄 요약

• ABAP EML 은 RAP BO 의 데이터를 ABAP 코드에서 읽고 바꾸는 문법이에요. MODIFY ENTITIES, READ ENTITIES, COMMIT ENTITIES 가 기본이에요.

• 입력과 응답은 TYPE TABLE FOR CREATE ..., TYPE RESPONSE FOR MAPPED ... 같은 BDEF 파생 타입으로 받고, %cid(요청 안에서 유일한 임시 키)를 꼭 넣어요.

• MODIFY 는 트랜잭션 버퍼만 바꾸고, COMMIT ENTITIES 를 해야 DB 에 저장돼요.

어떤 상황에서 쓰나요

RAP 로 만든 BO 를 OData 서비스로만 쓰는 것이 아니라, 배치 프로그램이나 다른 클래스에서 직접 만들고 고쳐야 할 때 EML 을 써요. 연재 2회는 치트시트의 *ABAP EML* 편에서 가장 자주 쓰는 문장 세 가지를 중심으로 정리해요.

핵심 내용

읽기는 기본, 쓰기는 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