RAP Determination vs Validation 차이 #shorts #SAP #RAP

📖 개요 — 이 글에서 다루는 것

RAP(ABAP RESTful Application Programming Model)의 Behavior Definition을 처음 다루다 보면 가장 자주 마주치는 갈림길이 있습니다. "이 로직은 Determination으로 구현해야 하나, Validation으로 구현해야 하나?" 둘 다 저장 흐름 어딘가에서 자동으로 호출되는 로직이라는 점 때문에 헷갈리기 쉽지만, 목적과 동작 원리가 근본적으로 다릅니다. 이 글은 구현 방법을 나열하는 대신, 두 개념의 차이를 판단 기준 중심으로 정리합니다.

Determination과 Validation의 목적 차이를 한 문장으로 설명할 수 있다
발동 시점(on modify / on save)과 저장 시퀀스 내 실행 순서를 이해한다
데이터 변경 가능 여부와 저장 거부 가능 여부의 비대칭을 이해한다
실무에서 자주 나오는 혼용 실수 패턴을 피할 수 있다

📚 시작 전에 알고 있으면 좋은 것

이 글은 intermediate 난이도로, 다음 내용을 이미 접해 본 독자를 기준으로 합니다. CDS View Entity 기본 문법, Managed RAP 비즈니스 오브젝트의 구조(Behavior Definition + Behavior Implementation 클래스), 그리고 EML(Entity Manipulation Language)의 READ/MODIFY 구문 기초입니다. Determination이나 Validation을 직접 구현해 본 경험은 없어도 괜찮습니다. 오히려 구현 전에 이 글로 개념 지도를 먼저 그려 두는 편이 시행착오를 줄여 줍니다.

🔧 환경과 준비물

이 글의 예제 코드는 다음 환경을 기준으로 작성했습니다.

SAP BTP ABAP Environment 또는 SAP S/4HANA 2022 이상(온프레미스/Private Cloud, ABAP Platform 2022 이상) — 두 환경 모두 strict(2) 모드의 Managed RAP을 지원합니다
ABAP Development Tools(ADT) — Eclipse 기반. Behavior Definition은 SE80/GUI에서 편집할 수 없으므로 ADT가 필수입니다
Managed 구현 타입의 RAP 비즈니스 오브젝트 1개 — 이 글에서는 사내 설비 수리 요청 관리 시나리오를 새로 만들어 사용합니다. 루트 엔티티 ZR_FCM_RepReq(별칭 RepairRequest), 저장 테이블 zfcm_repreq, 주요 필드는 손상 등급(DamageGrade), 예상 수리비(EstimatedCost), 우선순위(PriorityCode), 상태(Status)입니다

클라우드 환경에서는 released API만 사용 가능하다는 제약이 있지만, Determination/Validation 문법 자체는 온프레미스와 동일하게 동작합니다.

💡 핵심 개념 — "채워 넣는 로직"과 "막아서는 로직"

비유로 시작하겠습니다. 수리 요청서를 접수하는 창구를 상상해 보세요. 창구에는 두 명의 직원이 있습니다.

Determination은 서류를 대신 채워 주는 직원입니다. 신청자가 손상 등급을 적으면 그에 맞는 우선순위 칸을 자동으로 채워 넣습니다. 서류를 반려하는 권한은 없습니다.
Validation은 접수 도장을 찍기 직전에 서류를 검사하는 직원입니다. 예상 수리비가 예산 한도를 넘으면 접수를 거부합니다. 대신 서류 내용을 고칠 권한은 없습니다.

이 비유가 두 개념의 핵심 비대칭을 그대로 담고 있습니다. Determination은 데이터를 파생·보정하는 로직이고, Validation은 데이터를 검증하고 저장을 거부하는 로직입니다. 이제 비교 축을 표로 정리합니다.

비교 축	Determination	Validation
목적	필드 값 자동 계산·파생·초기화	일관성 검증, 잘못된 데이터의 저장 차단
발동 시점	`on modify` 또는 `on save` 선택 가능	`on save`만 가능
데이터 변경	가능 (EML `MODIFY ... IN LOCAL MODE`)	불가 — 읽기 전용, 변경 시도 시 런타임 오류
저장 거부	불가 — 시그니처에 `failed` 파라미터 자체가 없음	가능 — `failed`에 키를 넣으면 저장 롤백
메시지 전달	`reported`로 안내성 메시지만 가능	`reported` + `failed`로 오류 메시지와 거부를 함께
DB 읽기	가능 (EML READ, SELECT 모두)	가능 — 읽기는 자유, 쓰기만 금지
실행 순서	on modify는 변경 직후, on save는 저장 시퀀스의 finalize 단계	저장 시퀀스의 check_before_save 단계 — Determination on save 이후
트리거	`create`, `update`, `delete`, `field`	`create`, `update`, `delete`, `field`

가장 중요한 두 줄만 다시 강조합니다. 첫째, 실행 순서입니다. 저장 버튼이 눌리면 RAP 저장 시퀀스는 일반적으로 finalize(Determination on save 실행) → check_before_save(Validation 실행) → 번호 조정 → 실제 DB 저장 순으로 진행됩니다. 즉 Validation은 항상 Determination on save가 데이터를 마지막으로 손본 뒤에 검사합니다. 그래서 "Determination이 채운 값을 Validation이 검증한다"는 설계가 자연스럽게 성립합니다. 둘째, 권한의 비대칭입니다. Determination은 고칠 수 있지만 막을 수 없고, Validation은 막을 수 있지만 고칠 수 없습니다. 이 비대칭을 기억하면 "언제 무엇을 쓰는가"에 대한 답의 8할이 나옵니다.

판단 기준을 한 문장으로 요약하면 이렇습니다. "결과적으로 필드에 값이 들어가야 하면 Determination, 결과적으로 사용자에게 오류가 보여야 하면 Validation."

💻 실전 예제 3단계 — 차이가 드러나는 최소 코드

1단계: Behavior Definition에서 두 개념 선언하기

설비 수리 요청 시나리오의 Behavior Definition입니다. 손상 등급이 바뀌면 우선순위를 자동 산출하고(Determination), 저장 시점에 예상 수리비의 예산 한도를 검사합니다(Validation).

managed implementation in class zbp_fcm_repreq unique;
strict ( 2 );

define behavior for ZR_FCM_RepReq alias RepairRequest
persistent table zfcm_repreq
lock master
authorization master ( instance )
etag master LastChangedAt
{
  create;
  update;
  delete;

  // 손상 등급이 바뀔 때마다 우선순위를 다시 계산
  determination setPriority on modify { field DamageGrade; }

  // 저장 직전, 생성 시와 수리비 변경 시 예산 한도 검사
  validation checkCostLimit on save { create; field EstimatedCost; }
}

선언만 봐도 차이가 보입니다. Determination은 on modify를 선택해 사용자가 값을 바꾸는 즉시 반응하게 했고, Validation은 문법상 on save만 허용되므로 저장 직전에만 개입합니다. 중괄호 안의 트리거(create, field ...)는 "언제 이 로직을 깨울 것인가"를 정의하는 부분으로, 두 개념이 동일한 문법을 공유합니다.

2단계: 구현에서 드러나는 시그니처의 비대칭 — 메시지와 로깅

Behavior Implementation 클래스의 로컬 핸들러입니다. 시그니처를 나란히 놓고 보면 프레임워크가 두 개념에 부여한 권한 차이가 명확해집니다.

CLASS lhc_repairrequest DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.
    " Determination: failed 파라미터가 아예 없다 → 저장 거부 불가
    METHODS setpriority FOR DETERMINE ON MODIFY
      IMPORTING keys FOR repairrequest~setpriority.

    " Validation: failed/reported가 자동 포함된다 → 거부 + 메시지 가능
    METHODS checkcostlimit FOR VALIDATE ON SAVE
      IMPORTING keys FOR repairrequest~checkcostlimit.
ENDCLASS.

CLASS lhc_repairrequest IMPLEMENTATION.

  METHOD setpriority.
    " 트리거된 인스턴스를 읽고
    READ ENTITIES OF zr_fcm_repreq IN LOCAL MODE
      ENTITY repairrequest
        FIELDS ( damagegrade ) WITH CORRESPONDING #( keys )
      RESULT DATA(lt_req).

    " 파생 값을 계산해 다시 써 넣는다 (Determination만 가능한 동작)
    MODIFY ENTITIES OF zr_fcm_repreq IN LOCAL MODE
      ENTITY repairrequest
        UPDATE FIELDS ( prioritycode )
        WITH VALUE #( FOR ls_req IN lt_req
                      ( %tky         = ls_req-%tky
                        prioritycode = COND #( WHEN ls_req-damagegrade >= 4
                                               THEN 'URGENT'
                                               ELSE 'NORMAL' ) ) ).
  ENDMETHOD.

  METHOD checkcostlimit.
    CONSTANTS lc_limit TYPE p LENGTH 10 DECIMALS 2 VALUE '5000000.00'.

    READ ENTITIES OF zr_fcm_repreq IN LOCAL MODE
      ENTITY repairrequest
        FIELDS ( estimatedcost ) WITH CORRESPONDING #( keys )
      RESULT DATA(lt_req).

    LOOP AT lt_req INTO DATA(ls_req) WHERE estimatedcost > lc_limit.
      " 저장 거부: failed에 키 추가 (Validation만 가능한 동작)
      APPEND VALUE #( %tky = ls_req-%tky ) TO failed-repairrequest.

      " 사용자에게 보여줄 오류 메시지: 필드 단위로 지정하면 UI에서 하이라이트됨
      APPEND VALUE #( %tky = ls_req-%tky
                      %msg = new_message_with_text(
                               severity = if_abap_behv_message=>severity-error
                               text     = '예상 수리비가 결재 한도를 초과했습니다' )
                      %element-estimatedcost = if_abap_behv=>mk-on
                    ) TO reported-repairrequest.
    ENDLOOP.
  ENDMETHOD.

ENDCLASS.

주목할 포인트가 세 가지입니다. 첫째, setpriority의 시그니처에는 failed가 없습니다. Determination 안에서 아무리 심각한 문제를 발견해도 저장을 막을 방법이 문법 차원에서 봉인되어 있습니다. 둘째, checkcostlimit는 데이터를 READ만 하고 MODIFY하지 않습니다. 저장 시퀀스 중에는 인스턴스 데이터 변경이 허용되지 않아, Validation에서 MODIFY를 시도하면 런타임 오류로 이어집니다. 셋째, 두 메서드 모두 IN LOCAL MODE로 자기 BO에 접근합니다. 내부 로직이 권한·기능 제어를 다시 통과할 필요가 없기 때문이며, 실무에서는 이 지점을 로깅 포인트로 활용해 Application Log(BALI 계열 API)에 계산 근거나 거부 사유를 남기는 패턴이 일반적입니다.

3단계: 프로덕션 관점 — 대량 처리, 순서 의존, 테스트

두 개념의 차이는 프로덕션 설계에서 더 크게 벌어집니다.

대량 처리(mass-enabled) 작성. Determination과 Validation 모두 keys가 테이블로 들어옵니다. API나 마이그레이션으로 수백 건이 한 번에 들어와도 메서드는 한 번만 호출되므로, 위 예제처럼 READ 한 번 → 내부 LOOP 구조를 지켜야 합니다. LOOP 안에서 건별 SELECT를 하는 순간 성능이 무너집니다. 특히 Determination on modify는 사용자의 필드 변경마다 라운드트립이 발생하므로 무거운 조회는 on save로 미루는 판단이 필요합니다.

순서를 이용한 설계. Determination on save가 Validation보다 먼저 실행된다는 순서를 활용하면, "Determination이 ApproverGroup을 산출 → Validation이 산출된 결재 그룹의 존재 여부를 검증"처럼 파생과 검증을 안전하게 연결할 수 있습니다. 반대로 Validation이 먼저 실행된다고 착각하고 설계하면 검증이 항상 옛 값을 보는 버그가 생깁니다.

테스트. 두 로직 모두 cl_abap_behavior_test_environment 기반의 ABAP Unit으로 검증할 수 있습니다. Determination은 "MODIFY 후 READ했을 때 파생 필드 값이 기대와 같은가", Validation은 "COMMIT ENTITIES가 실패하고 reported에 메시지가 쌓였는가"로 단언 포인트 자체가 다릅니다. 보안 관점에서 한 가지 덧붙이면, 인스턴스 권한 통제는 Validation이 아니라 authorization master (instance)와 권한 핸들러의 몫입니다. Validation으로 권한 검사를 흉내 내는 것은 권장되지 않는 패턴입니다.

⚠️ 흔한 실수와 트러블슈팅 FAQ

Q1. Validation 안에서 잘못된 값을 발견했으니 그 자리에서 고쳐 주고 싶은데요?
안 됩니다. 저장 시퀀스의 검증 단계에서는 데이터 변경이 금지되어 있어 EML MODIFY가 런타임 오류를 일으킵니다. "고쳐 주는 게 맞는 로직"이라면 그 자체가 Validation이 아니라 Determination이어야 한다는 신호입니다. 값 보정은 Determination으로 옮기고, Validation은 보정 후에도 남는 위반만 거부하도록 역할을 나누세요.

Q2. Determination에서 조건이 안 맞으면 저장을 막고 싶습니다.
불가능합니다. Determination 시그니처에는 failed가 없어서 무엇을 해도 저장은 진행됩니다. reported에 오류 메시지를 넣어도 저장 자체는 성공하기 때문에 사용자에게 혼란만 줍니다. 저장 차단이 목적이면 같은 조건을 Validation으로 구현해야 합니다.

Q3. Determination on modify가 예상보다 여러 번 실행되는 것 같습니다.
트리거 필드가 바뀔 때마다 실행되는 것이 정상 동작입니다. 일반적으로 자기 자신이 만든 변경으로 무한 재트리거되지는 않지만, Determination A가 바꾼 필드가 Determination B의 트리거이고 B가 다시 A의 트리거 필드를 바꾸는 상호 참조 구조는 예측하기 어려운 실행 흐름을 만듭니다. 각 Determination을 몇 번 실행돼도 결과가 같은 멱등(idempotent) 로직으로 작성하고, 트리거 필드를 최소한으로 선언하는 것이 안전합니다.

Q4. Determination을 on save로 선언했더니 화면에 계산 값이 바로 안 보입니다.
의도된 동작입니다. on save는 저장 시퀀스에서 실행되므로 저장 전 화면에는 반영되지 않습니다. 사용자가 입력 중에 파생 값을 봐야 한다면 on modify로 바꾸고, Fiori Elements UI라면 side effect 애노테이션으로 화면 갱신을 함께 정의해야 합니다. 반대로 화면 반영이 필요 없는 번호 채번·집계성 로직이라면 on save가 라운드트립 부담이 적습니다.

🚀 여기서 더 나아가기

두 개념의 경계가 잡혔다면 자연스러운 다음 주제는 세 가지입니다. 첫째, Validation의 이벤트 시점 분리 — 같은 on save라도 트리거 구성에 따라 동작이 달라지는 세부를 파고들 수 있습니다(이 블로그의 Validation 심화 글 참고). 둘째, Action과 Feature Control — 사용자가 명시적으로 실행하는 로직과 버튼 활성화 제어는 Determination/Validation과 또 다른 축입니다. 셋째, Draft 활성화 시의 동작 변화 — Draft BO에서는 Determination/Validation이 draft 인스턴스에도 적용되므로 prepare 단계와의 관계를 이해할 필요가 있습니다. 마지막으로 unmanaged/managed with additional save 시나리오에서 저장 시퀀스가 어떻게 확장되는지도 좋은 후속 주제입니다.

📚 더 읽어볼 자료

댓글 0