UI5 모드
RAP

OData V2 vs V4 — Fiori에서 맞는 선택 #shorts #SAP #RAP

수정: 2026년 6월 21일 👁 0 · ♥ 0

OData V2와 V4, 무엇이 어떻게 달라졌나

OData는 SAP가 REST 기반 데이터 액세스 표준으로 채택한 프로토콜이며, 현재 SAP 생태계에는 V2와 V4 두 가지 메이저 버전이 공존합니다. V2는 2010년대 초반부터 SAP Gateway, SAP UI5, Fiori Classic에서 광범위하게 사용되며 사실상의 사내 표준 역할을 해왔습니다. 반면 V4는 OASIS에서 2014년 정식 표준화된 차세대 사양으로, SAP S/4HANA Cloud의 Fiori Elements, RAP(RESTful ABAP Programming Model), CAP(Cloud Application Programming Model)에서 기본으로 권장됩니다.

두 버전의 가장 큰 차이는 메타데이터 모델과 어노테이션 처리 방식에 있습니다. V2는 메타데이터가 정적(static)이며 어노테이션이 별도 파일이나 Local Annotation으로 따로 관리되는 경우가 많았습니다. V4는 메타데이터 자체에 어노테이션이 내장되고, $expand·$select 같은 쿼리 옵션의 성능이 개선되었으며, Singleton·Containment·Action·Function 같은 새로운 개념이 추가되었습니다. JSON 페이로드도 V4가 훨씬 가볍고 직관적입니다.

이 글에서 확인할 핵심은 다음과 같습니다.

  • RAP에서 Service Binding이 무엇을 의미하며 왜 두 가지로 나뉘는지
  • OData V2와 V4가 페이로드·메타데이터·드래프트 처리에서 어떻게 다른지
  • Fiori Elements 앱과 함께 사용할 때 V4를 선택해야 하는 구체적 이유
  • SalesOrder 엔티티를 기반으로 V4 Service Binding을 만드는 실전 흐름
  • V2를 유지해야 하는 레거시 상황과 V4 마이그레이션 시 점검 사항

이 글을 따라가기 전 알아두면 좋은 것

이 글은 ABAP RAP의 기본 구성요소(CDS View Entity, Behavior Definition, Behavior Implementation, Service Definition)에 대한 기본적인 이해를 전제로 합니다. ABAP Development Tools(ADT)에서 CDS 뷰를 생성하고 활성화한 경험, 그리고 SAP Fiori Launchpad나 Fiori Elements 프리뷰를 한 번이라도 실행해 본 경험이 있다면 한결 수월합니다. OData 자체에 대한 깊은 지식은 필요 없지만, REST와 JSON에 익숙하면 좋습니다.

환경 및 준비물

이 글의 예제는 다음 환경을 기준으로 검증되었습니다.

  • SAP S/4HANA 2022 (On-Premise) 또는 SAP BTP ABAP Environment(Steampunk) 2305 이상
  • ABAP Development Tools (ADT) for Eclipse 2023-06 이상
  • ABAP RAP 지원 릴리스 (ABAP Platform 7.56 이상 권장)
  • Fiori Elements V4 프리뷰 (Service Binding 우클릭 → Preview)
  • SAP Gateway Foundation (V2 Binding 테스트 시)

Steampunk(BTP ABAP Environment)에서는 V2 Service Binding 옵션이 일반적으로 제공되지 않으며, V4 또는 InA(Information Access) 바인딩만 활성화되어 있는 경우가 많습니다. On-Premise S/4HANA 환경에서는 두 가지 모두 선택 가능하지만, 신규 개발은 V4로 진행하는 것이 일반적으로 권장됩니다.

RAP에서 Service Binding이 담당하는 역할

RAP에서 비즈니스 객체(Business Object)는 CDS View Entity와 Behavior Definition으로 정의되며, 이를 외부에 노출하기 위해 Service Definition과 Service Binding 두 단계를 거칩니다. Service Definition은 "어떤 엔티티를 어떤 별칭으로 노출할지"를 정의하는 추상 계층이고, Service Binding은 "그 정의를 어떤 프로토콜과 버전으로 실제 게시할지"를 결정하는 구체적 게시(Publication) 계층입니다.

비유하자면 Service Definition은 음반의 마스터 테이프이고, Service Binding은 그 마스터를 CD로 찍을지, 스트리밍으로 배포할지, 바이닐로 프레스할지를 정하는 단계입니다. 동일한 Service Definition 하나에 V2 Binding과 V4 Binding을 모두 연결할 수도 있고, UI 서비스용과 Web API용을 분리해서 만들 수도 있습니다.

Service Binding 생성 시 선택하는 Binding Type은 크게 다음과 같이 나뉩니다.

  • OData V2 - UI: Fiori Classic 또는 Freestyle UI5 앱용. Draft 처리가 V2 방식으로 동작.
  • OData V2 - Web API: 외부 시스템 연동용 V2 서비스(드래프트 없음).
  • OData V4 - UI: Fiori Elements V4 앱용. 최신 어노테이션·드래프트·Side Effect 지원.
  • OData V4 - Web API: 외부 시스템 연동용 V4 서비스.
  • InA: SAP Analytics Cloud Live Connection용 분석 바인딩.

V2 Service Binding이 여전히 필요한 경우

V4가 권장되더라도 V2를 선택해야 하는 상황은 분명히 존재합니다. 기존에 V2 기반으로 작성된 SAP UI5 Freestyle 앱이 다수 운영 중이라 어노테이션·라우팅 패턴을 그대로 재사용해야 할 때, SAP Gateway 기반 외부 인터페이스가 이미 V2 페이로드 포맷에 종속되어 있을 때, 또는 일부 표준 SAP Fiori 앱이 여전히 V2 백엔드를 요구할 때입니다.

V2 페이로드는 일반적으로 다음과 같은 형태를 가집니다.

{
  "d": {
    "results": [
      {
        "__metadata": {
          "uri": "/sap/opu/odata/sap/ZSALES_ORDER_V2_SRV/SalesOrder('1000')",
          "type": "ZSALES_ORDER_V2_SRV.SalesOrderType"
        },
        "SalesOrderId": "1000",
        "CustomerName": "ACME Corp",
        "TotalAmount": "12500.00",
        "Currency": "EUR"
      }
    ]
  }
}

반면 V4는 동일한 데이터를 훨씬 가볍게 표현합니다.

{
  "@odata.context": "$metadata#SalesOrder",
  "value": [
    {
      "SalesOrderId": "1000",
      "CustomerName": "ACME Corp",
      "TotalAmount": 12500.00,
      "Currency": "EUR"
    }
  ]
}

V4 Service Binding과 Fiori Elements의 궁합

Fiori Elements V4는 메타데이터에 내장된 UI 어노테이션(@UI, @Search, @ObjectModel 등)을 읽어 List Report, Object Page, Analytical List Page 등을 자동 렌더링합니다. RAP의 CDS View Entity에 작성한 어노테이션이 별도 변환 없이 V4 메타데이터로 그대로 노출되기 때문에, V4 Binding을 선택하면 "한 번 정의, 어디서나 사용" 원칙이 실제로 성립합니다.

V2와 비교했을 때 V4 Binding이 Fiori Elements와 잘 맞는 이유는 다음과 같습니다.

  • Draft 처리 최적화: V4는 RAP의 Managed Draft를 네이티브로 인식하며, Side Effect 어노테이션을 통한 부분 갱신이 매끄럽습니다.
  • $expand 성능: V4는 다단계 Association 확장에서 SQL 조인 최적화가 잘 이루어집니다.
  • Action 바인딩: RAP의 Action·Function이 V4의 bound action으로 자연스럽게 매핑됩니다.
  • 최신 컨트롤 지원: 멀티 입력 필드, 트리 테이블, 차트 등 최신 Fiori 컨트롤은 V4 위주로 신규 기능이 추가되는 경향이 있습니다.

실전 예제 - SalesOrder 엔티티로 V4 Service Binding 만들기

다음 예제는 판매 주문(SalesOrder)을 RAP로 노출하고 V4 Service Binding으로 게시한 후 Fiori Elements 프리뷰로 확인하는 흐름입니다.

1단계 - CDS View Entity 정의

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Sales Order Root View'
@Metadata.allowExtensions: true
define root view entity ZR_SalesOrderTP
  as select from zsales_order_hdr
{
  key sales_order_id           as SalesOrderId,
      customer_name            as CustomerName,
      @Semantics.amount.currencyCode: 'Currency'
      total_amount             as TotalAmount,
      @Semantics.currencyCode: true
      currency                 as Currency,
      order_status             as OrderStatus,
      @Semantics.user.createdBy: true
      created_by               as CreatedBy,
      @Semantics.systemDateTime.createdAt: true
      created_at               as CreatedAt
}

2단계 - Behavior Definition (Managed, Draft 포함)

managed implementation in class zbp_r_salesordertp unique;
strict ( 2 );
with draft;

define behavior for ZR_SalesOrderTP alias SalesOrder
persistent table zsales_order_hdr
draft table zsales_order_d
lock master
total etag CreatedAt
authorization master ( instance )
etag master CreatedAt
{
  field ( readonly ) SalesOrderId, CreatedBy, CreatedAt;
  field ( mandatory ) CustomerName, TotalAmount, Currency;

  create;
  update;
  delete;

  draft action Edit;
  draft action Activate optimized;
  draft action Discard;
  draft action Resume;
  draft determine action Prepare;

  action ( features : instance ) ConfirmOrder result [1] $self;
}

3단계 - Service Definition

@EndUserText.label: 'Sales Order Service Definition'
define service ZUI_SALES_ORDER {
  expose ZR_SalesOrderTP as SalesOrder;
}

4단계 - V4 UI Service Binding 생성

ADT에서 Service Definition을 우클릭하고 New Service Binding을 선택합니다. Binding Type 드롭다운에서 OData V4 - UI를 고르고 이름을 ZUI_SALES_ORDER_O4로 지정합니다. 활성화 후 Local Service Endpoint에서 Preview 버튼을 누르면 Fiori Elements V4 List Report가 즉시 렌더링됩니다.

"* Service Binding 메타데이터 일부 (자동 생성)
"* Binding Type: ODATA_V4_UI
"* Service: ZUI_SALES_ORDER
"* Version: 0001
"* URL: /sap/opu/odata4/sap/zui_sales_order_o4/srvd/sap/zui_sales_order/0001/

5단계 - UI 어노테이션 추가 (Metadata Extension)

@Metadata.layer: #CORE
annotate entity ZR_SalesOrderTP with
{
  @UI.facet: [
    { id: 'General', purpose: #STANDARD, type: #IDENTIFICATION_REFERENCE,
      label: 'General Information', position: 10 }
  ]
  @UI.lineItem: [{ position: 10, label: 'Order ID' }]
  @UI.identification: [{ position: 10 }]
  SalesOrderId;

  @UI.lineItem: [{ position: 20, label: 'Customer' }]
  @UI.identification: [{ position: 20 }]
  @UI.selectionField: [{ position: 10 }]
  CustomerName;

  @UI.lineItem: [{ position: 30, label: 'Amount' }]
  @UI.identification: [{ position: 30 }]
  TotalAmount;

  @UI.lineItem: [{ position: 40, label: 'Status' }]
  @UI.identification: [{ position: 40 }]
  OrderStatus;
}

이 어노테이션은 V4 메타데이터에 그대로 포함되어 Fiori Elements가 List Report와 Object Page를 자동 구성합니다. V2 Binding에서도 일부 어노테이션이 노출되긴 하지만, V4가 훨씬 풍부하게 지원합니다.

V2 vs V4 핵심 비교와 선택 기준

항목OData V2OData V4
표준화 기관Microsoft 주도(사실상 표준)OASIS 정식 표준
페이로드 크기상대적으로 큼 (__metadata 포함)가벼움 (@odata.context만)
JSON 형식d.results 래핑value 배열 직접 노출
Draft 처리Sibling 엔티티 패턴네이티브 IsActiveEntity 지원
Fiori Elements 권장 버전V2 앱(레거시)V4 앱(신규 기본)
$expand 성능다단계 시 부담최적화됨
Action/Function제한적bound/unbound 모두 풍부
BTP ABAP Environment제한적 제공기본 권장

선택 기준은 단순합니다. 신규 RAP 개발이고 Fiori Elements V4 앱을 만들 계획이라면 V4 UI Binding이 일반적으로 권장됩니다. 기존 V2 기반 Freestyle UI5 앱을 확장하거나 V2 페이로드를 소비하는 외부 시스템과 연동해야 한다면 V2 Binding을 유지하거나 V2 Web API Binding을 별도로 추가하는 것이 안전합니다.

자주 마주치는 함정과 해결법

Q1. V4 Binding을 활성화했는데 Fiori Elements 프리뷰에서 컬럼이 비어 있습니다.

대부분 @UI.lineItem 어노테이션이 Metadata Extension에 누락된 경우입니다. CDS 본문 또는 Metadata Extension에 lineItem position 값을 명시했는지 확인하세요. 또한 활성화 후 ADT 캐시를 새로고침(F5)하지 않으면 이전 메타데이터가 표시될 수 있습니다.

Q2. V2 Binding에서는 동작하던 Draft가 V4로 바꾸니 에러가 납니다.

V4는 Draft Table 구조와 etag 필드를 명확히 요구합니다. Behavior Definition의 draft table 절, etag master 필드, total etag 설정을 다시 확인하세요. 특히 draft determine action Prepare가 정의되지 않으면 Activate 단계에서 검증 로직이 호출되지 않아 일관성 문제가 발생할 수 있습니다.

Q3. 같은 Service Definition에 V2와 V4 Binding을 동시에 만들면 충돌하나요?

충돌하지 않습니다. Service Definition 하나에 여러 Service Binding을 연결할 수 있으며, 각 Binding은 독립적인 URL과 메타데이터를 갖습니다. 다만 동일 비즈니스 로직을 두 채널로 노출하므로 Behavior Implementation의 변경이 양쪽에 동시에 영향을 미친다는 점은 유의해야 합니다.

Q4. V4 Binding URL에 /odata4/가 붙어 있는데 V2 URL과 호환되지 않습니다.

정상적인 동작입니다. V4는 /sap/opu/odata4/..., V2는 /sap/opu/odata/... 경로 패턴을 사용합니다. 클라이언트 측 매니페스트(manifest.json)의 dataSources 설정에서 odataVersion을 "4.0"으로 명시해야 SAPUI5가 올바른 모델(sap.ui.model.odata.v4.ODataModel)을 로드합니다.

V4를 일단 선택한 뒤 무엇을 더 봐야 하는가

V4 Service Binding으로 기본 CRUD가 동작하면 다음 단계로는 RAP의 고급 기능을 점진적으로 적용해 볼 수 있습니다. Action을 추가해 "주문 확정" 같은 비즈니스 로직을 노출하고, Determination과 Validation을 작성해 데이터 일관성을 강화하며, Side Effect 어노테이션으로 UI 부분 갱신을 자연스럽게 만드는 작업이 우선순위입니다. 이후에는 Composition을 활용한 헤더-아이템 구조, Unmanaged Save로의 부분 전환, 그리고 Behavior Pool에서 EML(Entity Manipulation Language)을 활용한 트랜잭션 제어 등을 살펴보면 좋습니다.

외부 시스템 연동이 필요해지면 동일 Service Definition에 V4 Web API Binding을 별도로 추가해 UI 채널과 API 채널을 분리하는 패턴도 일반적으로 권장됩니다. BTP ABAP Environment에서는 Communication Scenario와 Communication Arrangement를 통한 인증 구성이 추가로 필요합니다.

댓글 0

아직 댓글이 없습니다.