2030을 위한 ERP 이야기

8. HANA DB기반 CDS 데이터 모델링 

(ABAP)CDS는 HANA DB의 강점을 활용하기 위하여 S/4HANA와 함께 도입된 Data Dictionary 인프라로서 ‘Semantically Rich Data Model’을 정의하고 활용(Consume)할 수 있게 해주는 Framework이다. CDS는 S/4HANA의 VDM(Virtual Data Model)의 기술적 기반이다.

S/4HANA는 SAP의 In-Memory DB인 HANA DB를 Data Infra로 사용한다. S/4HANA는 In-Memory Column DB인 SAP HANA의 장점을 적극 활용하기 위하여 여러 가지 노력을 거듭해 왔다. ABAP Coding을 HANA DB에 최적화 되게 일부 Syntax를 변경하고 Open SQL로 Advance 시키고 Code Push Down, AMDP 등의 새로운 개념과 기술을 적용해 왔다. 또한 기존의 복잡한 Table을 Simple하게 만드는 노력도 병행했다. 이를 통해 빠른 시스템 성능을 제공하고 Transaction과 Operational Reporting을 동시에 제공하는 등 다양한 Business 가치를 제공하는 것을 추구하고 있다. 이번 장에서는 이러한 S/4HANA의 Data Architecture의 근간이 되는 CDS(Core Data Service)에 대하여 알아보자. 

8.1 CDS 개요

 CDS(Core Data Service)는 S/4HAHA의 Semantically Rich Data Model을 제공하는 Data Infra이다.  CDS를 기반으로 OData clients, SAP Fiori, Analytics 등에 활용되어 Easy-to-integrate services를 제공하고 application coding을 단순하게 하며 workload를 HANA database로 Push-down 할 수 있게 한다. 

1) CDS 기본 개념 

[그림 8-1] CDS의 주요 개념

CDS는 SQL Enhancement(Advanced Open SQL) 기반 DDL이다. 특정 DB에 국한되지 않는 ABAP Open SQL의 Enhancement인 Advanced Open SQL을 기반으로 Entity, Associaton, Calculated Field, Annotation 등의 추가적인 기능을 갖추어 Data Model에 더 많은 Semnatic을 정의할 수 있게 한다.

CDS는 HANA DB의 강점을 활용할 수 있도록 Code Push Down을 실행해 주는 가장 기본적인 도구이다. Code Push Down은 복잡한 연산이 소요되는 작업을 Application 서버(즉 ABAP 프로그램) 대신에 DB서버가 할 수 있도록 하는 프로그램 기법이다. 이는 다음 절에서 좀 더 살펴보겠다.

[그림 8-2] Code Push Down

CDS는 OLTP와 OLAP를 통합한 Data Model로서 OData client,  SAP Fiori,  Analytics(예: SAP Business Object for MS Office, Embedded Analytics, SAC/BW Extraction)등에 활용된다. 아래 그림은 Fiori App 중심으로 CDS가 활용되는 Architecture를 설명한 것이다. 

[그림 8-3] CDS 활용 Architecture(Fiori 활용 중심)

CDS는 Application 단에서 정의되어 OData Runtime에 활용되고 Fiori App 등이 이러한 OData 서비스를 활용하여 Data를 사용자에게 제공하게 된다. 

CDS View는 Database Table에 기초하여 만들어지고 여러 가지 View Type으로 정의되며(Basic Interface View, Consumption, Metadata Extension 등) 서비스 정의와 Binding을 통하여 최종 활용된다. 

[그림 8-4] CDS View 주요 구성 예시

CDS View는 DB Table이나 View 및 다른 CDS view를 가지고 정의된다. CDS Projection View (Consumption View)는 다른 CDS View에 기초한 특별한 View로 다른 View(entity) element의 일정 subset만을 최종 소비자에게 expose 한다.

[그림 8-5] Classic ABAP Dictionary View

기존 SAP ERP에 익숙했던 분들은 위 그림과 같은 ABAP Dictionalry View에 익숙할 것이다. 이러한 Dictionary View의 기능에 [그림 8-4]에서와 같은 Association, Annotation 등 다양한 CDS 기능을 활용하여 좀 더 풍부한 Semantic 정의를 할 수 있다.

CDS View는 eclipase 기반의 ADT(ABAP Development Tool)에서 관리(생성, 변경, 조회 등) 할 수 있다. 개발 패키지나 Object 유형 등 다양한 그룹으로 CDS를 리스트 할 수 있고 오른쪽 상세 Editor 화면에서 DDL을 사용하여 CDS를 정의할 수 있다. 또한 CDS View 정의에 따른 Data를 다양한 기능으로 조회할 수도 있다. 기존 ABAP 개발 Tool의 SE11 T-Code와 SE16 T-Code 등과 유사한 기능을 ADT로 실행할 수 있다. 

ADT는 SAP S/4HAHA의 개발 도구이다. 기존 ABAP Work Bench도 일정 부분 계속 사용할 수도 있지만 SAP는 ADT 사용을 강력 권장하고 있다. 특히 CDS는 ADT에서만 생성하여 활성화 할 수 있다. 기존 ABAP Work Bench에서는 일부 조회 기능만 제공한다. 

[그림 8-6] ADT에서의 CDS View

2) S/4HANA 표준 CDS View

S/4HANA에서는 이러한 CDS 기술을 활용하여 표준 Data Model인 VDM(Virtual Data Model)을 제공한다. 

표준에서 제공하는 VDM 체계 하의 주요 CDS View 들을 HELP.SAP.COM에서  확인할 수 있다. (Cross Component > VDM & CDS Views> CDS Views)(https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/8308e6d301d54584a33cd04a9861bc52/955a323799624bd79221780675ada090.html?locale=en-US)

[그림 8-7] CDS View in help.sap.com 

컨설턴트나 개발자들은 ADT를 활용하여 표준 CDS를 찾아 CDS 정의나 Data를 확인하고 이를 활용할 수 있다. ADT를 활용한 표준 CDS 탐색 방법에 대하여는 이후 좀 더 설명하겠다.

[그림 8-8] ADT 활용한 CDS View 활용

아래 그림은 ADT에서 구매 영역 관련 기본 CDS View 중의 하나인 Basic Interface View I_PURCHASEORDER를 예시한 것이다. 검색이나 Project Explorer의 계층 탐색을 통하여 원하는 CDS View를 찾고 오른쪽 화면에서 Annotation, Association 등이 적용된 것을 확인해 볼 수 있다. 

[그림 8-9] ADT에서의 CDS 탐색 예시

S/4HANA VDM의 표준 CDS View의 이름 체계를 이해하면 SAP가 고객이 사용하도록 허용한 CDS Views를 찾아서 재활용하는데 용이하다. Virtual Data Model (VDM)은 SAP S/4HANA의 analytical models, transactional models, API models의 근간을 이룬다. 먼저 VDM의 체계를 알아보자. 

[그림 8-10] S4HANA VDM 체계

CDS View는 재사용을 위해 기본적인 data 정의를 해둔 Reuse View Layer의 Interface View와 최종 Application들이 활용할 수 있도록 하기 위해 Intface View에서 불필요한 것들을 빼고 추가적인 요소들을 정의한 Consumption View 혹은 Projection View라고 불리는 Consumption View Layer로 구성되어 있다. 

Reuse View Layer의 Interface View는 단일 Data Source로 정의된 Basic Interface View와 여러 개의 Interface View를 기반으로 하는 Composite Interface View로 구성되어 있다. Interface View는 이름에서 알 수 있듯이 DB Table을 참조하여 만들어지지만 다른 Interface view를 기반으로 만들어질 수도 있다. SAP 내부적으로 사용하기 위한 Restricted reuse View도 있다. 

이러한 Layer 체계에 맞춰 CDS View의 이름 규칙도 권고하고 있다. Interface View 들은 'I_'로 시작한다. Consumption View는 'C_'로 시작한다. Remote API는 'A_'로, Private View는 'P_'로, Extension Include View는 'E_'로 시작하는 이름 규칙을 권고한다.  

[그림 8-11] VDM 내 CDS View Naming 규칙 - Prefix

[그림 8-12] VDM내 CDV View Naming 규칙 - Suffix

Suffix 명명 규칙도 있다.

- Query, Qry, Q로 끝나는 것은 Analytical Query View이다.

- Cube, C로 끝나는 것은 Analytical Cube View이다.

- 주로 Dimension 등의 Text 값을 갖고 있는 CDS View는 Text, Txt, T로 끝난다.

- Transaction을 처리하기 위한 CDS View는 TP로 끝난다.

- Value Help를 위한 Data 제공을 위한 View는 VH 혹은 StdVH로 끝난다.

S/4HANA 표준 VDM의 CDS View는 OLTP와 OLAP가 동일 데이터 모델에서 같이 구현되어 있다. Basic/Composite Interface View,  TP(Root-Child) View, Cube/Query View, Value Help/Text/Hierarchy/Dimension 등 코드 마스터 성격의  View 등으로 VDM 구성되어 있다. 

[그림 8-13] OLTP와 OLAP를 위한 단일 VDM Model

3) Custom CDS View 생성

표준 CDS View를 다양한 영역에서 활용하거나 표준 CDS View를 근간으로 새로운 Custom CDS View를 생성할 수 있다. 물론 Custom Table를 기반으로 Custom CDS View를 만들 수 도 있다. Custom CDS View는 2가지 도구를 가지고 만들 수 있다. 

(1) In-App Key User Extensibility Tool

Key User가 표준 Enhancement 도구인 In-App Extensibility 도구 중 Custom CDS View(F1866A) App을 활용하여 VDM의 표준 CDS View나 Custom Business Objects에 기반하여 Custom CDS view를 생성할 수 있으며 API나 Analytics(Cube or Dimension)에 사용될 수 있다. 

[그림 8-14] In-App Extensibility 도구 활용한 Custom CDS View 생성

[Step 1] Scenario 선택 후 생성 : Analytical Cube/Dimension, External API, Standard CDS View 선택 가능

[Step 2] Data Source 지정 : Parameters 지정 > Elements 지정 > Element Properties 지정 > Filter 지정

[Step 3] Check, Publish 후 Preview로 결과 확인 

Custom CDS View App을 포함한 In-App Key User Extensibility 도구를 활용한 표준 Enhancement에 대하여는 앞 장에서 자세히 다루었다. 

(2) ADT(New Data Definition)에서 Custom CDS View 만들기

ADT Tool을 활용하여 Custom Table 기반으로 신규 Custom CDS View를 생성하거나, 기존 표준 CDS View를 Extension 하거나(Extend View),  표준 CDS View의 Meta Data Extension을 통하여 Annotation이나 Association을 추가할 수 있다. 

[그림 8-15] ADT Tool로 Custom CDS View 생성

A. 신규 Custom CDS View 생성

신규 테이블, 기존 테이블, 기존 CDS View 등 참조하여 생성 가능  

용도, 목적에 맞게 View 정의  

B. View Extension

기존 Table, 다른 View의 필드를 extend 할 View에 추가할 경우    

Append  Structure 통해 필드 추가 후 View Extension --> Table명 + EKKO_INCL_EEW_PS,  혹 CI Include 사용  

C. Meta data Extension

Annotation 추가  

[Step 1] Base가 되는 Object에서 Context 메뉴를 실행하거나, New 메뉴를 실행한 후 생성

[Step 2] ADT가 제공하는 Template를 사용하거나 Template 참조 없이 직접 생성하거나 할 수 있음

ADT 활용 표준 테이블 필드 추가 참조 : Extend SAP S/4HANA Manage Purchase Orders SAP Fiori App with Custom Fields Part-1 | SAP Blogs

4) 표준 CDS View Extension 및 활용

표준 수정 없이 표준 CDS View에 새로운 Element(필드)를 추가하거나 CDS element에 Annotation을 추가할 수 있다.

[그림 8-16] 표준 CDS View 확장의 2가지 방법

Metadata Extension : 

CDS annotation을 Overwrite 하거나 추가할 수 있음  

주요 Extension Scenario : DB Hints,  Data extraction, Default behavior key/text, Consumption value help, Consumption filter,  Hide fields, Analytical Detail Query Variable Sequence

CDS View Extension :

Data Source로부터 CDS View에 새로운 Element(필드) 추가  

CDS View의 신규 Association 정의  

주요 Extension Scenario :  

     - 표준 VDM에 Custom 테이블 추가 :  Association으로

     - 표준 VDM에 표준 필드 추가 : extension include View나 extension view에 추가

     - 표준 VDM에 Custom 필드 추가 : CFL, extension include view,  extension view 순으로 

다양한 표준 Enhancement 방법에 대하여는 앞장을 참고하기 바란다. 

8.2 S/4HANA VDM의 표준 CDS View

S/4HANA의 Embedded Analytics 기능을 활용하여 다양한 Operational Reporting을 만들던, 표준의 Data에 필드나 Table을 추가하여 표준을 Enhance 하던, 표준 Data를 활용하여 Custom App을 개발하던, 표준 Data Model를 참조하여 Custom Data Model을 만들던 S/4HANA VDM내의 표준 CDS를 이해하는 것은 S/4HANA 확장의 출발점이 될 것이다.

Virtual Data Model(VDM)은 기술적으로는 S/4HANA의 ABAP Table을 근간으로 정립되어 있다. 따라서 ABAP Table에 대한 이해는 필수적인 사항이다. SAP HANA DB를 ERP에 적용하기 시작하여 S/4HANA로 완성되어 오기 까지 SAP는 기존의 DB Table을 HANA DB를 최적으로 활용할 수 있도록 진화시켜 왔다. DB Table의 Simplification도 그 노력 중의 하나이다.  

이러한 HANA DB 최적화된 Simplification은 구체적인 방향을 살펴보면 다음과 같다. 

    Optimized for analytical read access (columnar table store)  

    Reduction in memory footprint and runtime  

    Only main tables remaining, no redundancies, no aggregates and indices  

    Clear separation of master data from transactional data  

    Data Aging framework for storing aged data outside of main memory  

이러한 방향성에 따라 이루어진 S/4HANA에서의 변화들을 SD 모듈, Material Document, Finance 등의 영역중심으로 살펴보면 아래 그림들과 같다.

[그림 8-17] S/4HANA Physical Data Model Simplification 예 - SD 모듈

주요 SD 모듈 Table들 중 Index Table, Status Table들은 없어졌고 KONV Condition Table은 PRCD_element라는 새로운 구조로 바뀌었고 VBFA Table은 단순화되었다. 물론 없어진 Table들은 Version 호환성을 위하여 CDS View 기술로 만들어진 Compatibility View라는 형태로 제공되어 기존 Program들도 문제없이 사용할 수 있도록 지원되기는 한다.

[그림 8-18] S4HANA Physical Data Model Simplification 예 - Material Document

SCM과 FCM 모든 영역에 걸쳐있는 Material Document도 많은 변화가 있었다. 

- 기본적으로 Inventory Movement는 MATDOC라는 하나의 Table로 통합되었다.

- Stock Type별로 존재했던 Inventory Table들도 모두 MATDOC로 통합되었다.

- 또한 Stock Type별로 존재했던 Inventory History Table들도 모두 MATDOC로 통합되었다.

- MARC와 MARD master data table은 stock aggregates 없이 단순화되어 MARC, MARD로 남게 되었고 Stock Aggregates는 MATDOC로 통합되었다. 

[그림 8-19] S/4HANA Physical Data Model Simplification 예 - Finance 영역

Simple Finance, Universal Journal, Central Fiance 등 수많은 변화와 새로운 기능이 추가된 Finance 영역도 많은 변화가 있었다. 

많은 Total Table과 Index Table들이 없어지고 각 서브 영역(모듈, 서브 모듈)에서 사용되던 Journal들이 통합되어 ACDOCA라는 하나의 Table로 통합되었다. Document Header BKFP와 Document Item BSEG는 일부 제한적인 용도로 사용되고 있다. 물론 Compatibility View가 제공되기는 한다.

S/4HANA에서는 Simplification을 통한 Physical Data Model의 변화뿐만 아니라 Virtual Data Model의 도입과 그 기술적 기반이 되는 CDS View들이 추가되었다. Virtual Data Models(VDM)은 S/4HANA의 근간으로서 CDS View로 만들어진 표준 Business Data View이다. CDS View는 아래 그림과 같이 다양한 용도로 사용된다. 

CDS Views는 Fiori 및 SAP BusinessObjects에 사용  

CDS Views는 BW에 데이터를 보내는 datasource, Fiori Enterprise Search, 및 ABAP program에서 사용될 수 있음  

Compatibility view(ABAP program 프로그램에서 호출)도 내부적으로 CDS Views 사용  

[그림 8-20] VDM CDS View 다양한 용도

VDM의 CDS View는 S/4HANA 표준 Transaction(Create, Update, Delete를 실행하는)을 생성하는 데에도 당연히 활용된다. 이 구조를 이해하는 것은 표준 App을 Enhance 하거나 참조하여 Custom App을 만들 때 반드시 필요하다. 

[그림 8-21] Transaction App 생성에 활용되는 VDM의 View(출처 : SAP S/4HANA Architecture by SAP Press)

CDS를 활용한 표준 Fiori App 및 Custom App 개발에 대하여는 이후의 RAP ABAP 개발을 다루는 장에서 좀 더 상세히 설명하겠다.

ADT를 활용하여 VDM내의 표준 CDS View들을 검색하고 확인하고 활용하기 위하여는 ADT의 기능 활용 Tip들이 도움이 된다. 내가 활용하는 방법들 몇 가지를 소개한다. 

[그림 8-22] ADT 활용 Tip - Tree 구조 복사 및 설정

(1) 먼저 ADT를 실행한 후 S/4HAHA의 시스템 Object를 보여주는 System Library를 복사하여 자신만의 Object Tree를 구성한다. 물론 System Library를 그대로 활용해도 되지만 표준 Object가 너무 많아 활용에 어려움이 많을 것이다.

(2) 오른쪽 마우스 클릭수 Context Menu에서 Duplicate Tree를 실행하여 Tree명, Filter 명, Tree Structure 계층 설정 등을 수행한 후 저장한다. 

- Filter 설정 시에는 대상 Object 단위 지정(예 package:) 후에 Filter에 포함시킬 Object명을 ,로 연결해서 나열한다. 다른 Object 단위를 지정할 때에는 Space 한 칸 띄우고 동일하게 진행한다.

- Tree Structure Level 설정은 필요한 Hiercrchy로 설정한다.

ADT에 아직 S/4HANA 연결이 되어 있지 않은 경우에는 File > New > ABAP Project 실행하여 설정하면 연결할 수 있다. 이때 SAP GUI program이 설치되어 Logon 정보가 등록되어 있으면 이 정보를 가져와서 설정할 수 있도록 해 주고 그렇지 않은 경우에는 Connection Setting에서 등록하면 된다.(System ID, Connection Type: Custom Application Server, Application Server IP주소, Instance Number 등)

내가 주로 설정하는 것은 아래 그림과 같이 

- 내가 주로 찾을 대상이 되는 모듈(appl: SD, MM, PP, FI, CO 등)

- Object Type Group(group: CORE_DATA_SERVICES)

- 개발 Package 명(package: VDM_SD, RAP_SD, ODATA_SD 등)

[그림 8-23] ADT를 활용한 VDM CDS View 탐색 활용 Tip

전에는 표준 기술 Object들의 해당 Package를 볼 일이 별로 없었는데 CDS View를 탐색하면서는 유형함을 느꼈다. 

CDS의 경우에는 주로

- VDM_모듈명: 해당 모듈의 기본이 되는 Interface CDS View들, Embedded Analytics용 Cube/Query CDS 

- ODATA_모듈명: 해당 모듈의 Fiori App을 위한 Consumption View 들(Fiori App 당 하나의 Package로 묶여 있는 경우 많음)

- RAP_모듈명: 해당 모듈의 표준 Transaction App(CUD 수행 App)을 위한 CDS와 같이 Package로 구성되어 있어 이를 활용하여 필요한 CDS를 찾기 용이하다.

지금부터는 주요 각 모듈의 표준 VDM CDS View를 예시적으로 살펴보자. CDS View는 앞에서 살펴보았듯이 OData Service를 통하여 Fiori App에 활용되는 UI Projection View, OData Service를 통하여 외부 시스템 연계에 활용되는 API View, BAPI 대용으로 쓰이기 위해 ABAP Program에 활용되어 Transaction에 사용되는 BO Interface View, Embedded Analytics에 활용되는 Cube/Query View 등과 함께 이 Consumption level의 근간이 되는 Interface View들을 담고 있는 VDM Package의 View들이 있다.

1) RAP Programming Model 중심으로 개발되어 있는 SD 모듈의 Sales Order 관련 CDS View 예시

[그림 8-24] VDM CDS View 예 - RAP 모델 중심 SD 모듈

RAP(ABAP Restfu Application Programming Model)은 Fiori App을 만들기 위한 가장 최신의 ABAP 개발 모델이다. 이에 대하여는 이후 하나의 장을 할애하여 설명할 계획이다. SAP는 이 최신 RAP 모델을 표준 S/4HANA에 적용해 나가고 있는데 S/4HANA에 새로 만들어진 기능들은 RAP 모델로 만들어지고 있고 기존 기능들도 하나씩 RAP 모델로 표준 Fiori App 프로그램을 바꿔 나가고 있다. 

SD 모듈의 Sales Order는 RAP 모델을 거의 완전하게 적용하고 있다. 그래서 Sales Order가 기존 S/4HANA 기능을 RAP 모델로 바꿔 나가는 선도 프로그램 대상이 아닌가 하는 생각도 든다.

설명의 복잡성을 줄이기 위하여(실제 그림 예시에도 Header 이외의 CDS View는 많이 생략했음) Header Table의 CDS View 중심으로 설명하겠다. 

(1) Sales Order Object를 실제로 저장하는 ABAP Table VBAK(당연히 VBAP, VBEP 등 포함)은 이후 CDS View들의 근간이 된다.

(2) I_SalesDocumentBasic이라는 Basic Interface CDS View는 VBAK를 근간으로 생성되어 있고 I_SalesDocument CDS View는 이를 참조로 생성되어 있다. 이들 CDS View는 다른 Consumption View들의 근간이 되기 때문에 package VDM_SD_SLS라는 것으로 묶여 있다. SD의 SLS라는 서브 모듈에는 공통으로 되니 SD-SLS(SD Sales)라는 Application Component에 포함되어 있다.

(2) I_SalesOrder라는 CDS View는 I_SalesDocument라는 CDS View를 참조해서 만들어진 CDS View이고 VDM_SD_SLS_SO Package, SD-SLS-SO Application Component에 포함되어 있다. Sales Order는 Sales Document의 한 유형으로 View 정의의 맨 마지막 구절을 보면 

where

 SalesDocument.SDDocumentCategory = 'C';

라는 Syntax를 확인할 수 있다. 여기서 C는 Sales Order를 의미한다. 즉 Sales Order, Return Order, Credit/Debit Memo Request 모두 Sales Document로 같은 CDS View I_SalesOrderDocument를 공유하지만 Sales Order는 이 중 문서 카테고리가 C인 것만을 추출해서 보여주는 I_SalesOrder라는 CDS View를 활용하게 하는 것이다. 

(3) Fiori App은 UI Projection View기반으로 정의된 Business Service를 OData Protocol로 Binding 하여 Data를 제공받아 사용자에게 보여준다. CDS View C_SalesOrderManage는 Manage Sales Order V2(F3893)를 위한 OData Service의 근간이 되는 Consumption View이다.

(4) A_SalesOrder는 OData Service API Protocol을 통하여 다른 시스템 연계에 사용되는 API View이다. 

(5) BO Interface는 ABAP Program이 CDS View를 활용하여 CUD 등의 Transaction을 처리할 수 있도록 한 것으로 좀 더 기술적으로 이야기하면 ABAP의 EML(Entity Manipuration Lanauage)이 Business Object를 처리(CUD 등)할 수 있도록 하는 기법에 사용된다. 이는 기존에 ABAP이 BAPI를 호출하여 표준 Object에 CUD 등의 Transaction을 처리했던 것을 CDS View 기반 Object를 대상으로 바꾼 것으로 이해하면 되고 향후에는 BAPI를 대체해 나갈 것으로 보인다.

이 그림에서는 I_SalesOrderTP가 역할을 하는 BO Interface CDS View이다. 이는 CDS Consumption View의 특별한 형태이다. 

 

(6) I_SalesOrderTP는 R_SalesOrderTP라는 BO(Business Object) CDS View를 참조로 만들어져 있다. BO 및 BO Interface에 대하여는 이후 RAP를 다루는 장에서 상세히 설명하겠다. 

(7) Analytical Cube 및 Query CDS View들은 VDM Pagkage, SD-ANA Application Component에 포함되어 있다. 

Sales Order가 RAP 모델로 충실히 만들어져 있는 모범에 가까운 것으로 보여지는 데 이는 R_SalesOrderTP BO CDS View를 근간으로 BO Interface CDS View 뿐만 아니라 Fiori App, API 등의 Consumption View들이 이 BO를 근간으로 만들어져 VDM의 체계가 단순하고 일관성 있게 정리되어 있어 그렇게 이야기하였다. 이후 다른 모듈들의 다른 개발 모델 방식 설명에서도 이야기하겠지만 이렇게 잘 정리된 모듈은 아직은 많지 않고 서로 다른 기술들이 복합적으로 쓰이고 RAP 모델은 일부에만 적용되어 있는 것을 확인할 수 있다.

마지막으로 위 그림에서 CDS View를 표시하는 네모에 색상이 표시되어 있는 것은 해당 CDS View가 다음장에서 설명할 표준 Enhancement Tool(CFL: Custom Field and Logic)로 필드를 추가하거나 Association, Annotation을 추가할 수 있는 CDS View들을 표시한 것이다.

2) Sourcing & Procurement의 Purchase Oder 관련 CDS View 예시

MM-PUR-PO 서브 모듈은 CDS기반 BOPF모델을 활용한 SEGW 기반 Fiori App, RAP BO 기반 BO I/F 및 API, VDM(Interface + Analytics) 기반 Cube & Query와 구성되어 있다. 즉 CDS Based BOPF 중심의 ABAP programming Model for Fiori로 개발된 것에 BO Interface View가 새로운 RAP 모델에 따라 추가되어 있는 모습니다. 이는 Fiori App은 그 이전 기술로 개발되어 있지만 ABAP에서 CDS 기반 Business Object를 처리할 수 있도록 BO와 BO Interface는 RAP Model로 만들어 추가한 것이다. 즉 RAP 이전 단계에서 RAP Model 단계로 전환되어 가고 있는 중의 기능이라고 할 수 있다.

[그림 8-25] VDM CDS View 예시 - MM모듈 Purchase Order

이러한 모습은 Data Model의 중복성에서도 확인할 수 있다. 

- VDM_MM_PUR_PD Package level의 R_PurchaseDocument CDS View와 I_PurchaseDocument CDS View는 거의 동일하다.

- VDM_MM_PUR_PO Pakcage level의 R_PurchaseOrder CDS View와 I_PurchaseOrder CDS View 또한 거의 유사하다.

- Business Object level에서 보면 BOPF 기반이 되는 I_PurchaseOrderTP CDS View와 RAP BO의 기반이 되는 R_PurchaseOrderTP CDS View는 정의나 역할이 거의 유사하여 앞으로는 통합되어야 할 것이다. 

- Consumption Level에서 보면 C_PurchaseOrderTP를 기반으로는 하는 Fiori App Manage Purchase Order(F0842A)는 RAP Model이 아닌 BOPF기반으로 ABAP Programming Model for Fiori로 만들어진 UI App이고 BO Interface와 API는 RAP BO 기반으로 RAP Model로 만들어진 것이다.

3) Manufacturing PP모듈의 Production Order 관련 CDS View 예시

Production Order 관련 VDM CDS View는 더 이전 단계의 개발 모델들에 활용되는 것으로 보인다. 즉 Fiori App은 BOPF 기반 ABAP programming model for Fiori로 만들어져 있고 API는 RAP BO 기반이 아니라 일반 VDM의 CDS View 기반으로 만들어져 있다.  RAP BO를 위한 CDS View R_ProductionOrderTP는 만들어져 있으나 아직은 Test 목적이라고 CDS View에 주석되어 있고 당연히 BO Interface 도 아직 없다. 

[그림 8-26] VDM CDS View 예시 - PP모듈 Production Order

PP 모듈의 Production Order 관련 CDS View는 주로 VDM_PP_SFC package, PP-VDM Application component에 포함되어 있다. Analytical CDS View의 일부는 특이하게 PPH_ANALYTICS라는 Package에 포함되어 있다. BOPF BO CDS View와 UI 및 API CDS View들은 ODATA_PP 및 ODATA_MPE package에 포함되어 있다.

4) Finance FI 모듈의 General Ledger 관련 CDS View 예시(ACDOC Table 중심)

Finance 영역의 오랜 기능들은 더욱 특이한 구성으로 CDS View와 App들이 개발되어 있다. Fiori App들은 최근에 기능이 추가된 것이 아니라면 대부분 SEGW 기반 OData Service을 토대로 만들어져 있다. SEGW로 OData를 개발하더라도 CDS를 기반으로 하는 것들이 MM의 Purchase Order나 PP의 Production Order였다면 Finance GL의 Manage Journal Entries(F0717) App 같은 경우에는 CDS 없이 ABAP Entity를 직접 활용하여 ABAP 로직으로 Data Model을 구현하여 개발한 것이다. 물론 ABAP 로직 안에서 찾아보면 근간이 되는 CDS View들을 활용하는 것을 보 수는 있다. 

[그림 8-27] VDM CDS View 에시 - FI모듈 General Ledger

Finance 영역의 package 명이나 CDS View의 명들을 보면 우리가 지금까지 보아온 CDS View의 용도로 분류한 package명도 아니고 VDM의 CDS 계층 체계에 따른 CDS View의 이름도 아니다. 이를 통해 유추해 볼 수 있는 것은 Finance 영역의 VDM 및 Fiori App 개발은 ABAP Programming Model for Fiori나 최신의 RAP Model 이전의 개발 방식으로 만들어진 것으로 이해된다. 물론 Finance 영역에서도 Central Finance, Group Finance, BRIM 등의 신규 모듈/서브 모듈/기능 등은 최신의 RAP Model로 만들어져 있는 것이 일반적이다.

나는 이것이 Finance 영역이 S/4HANA 출시부터 Simple Finance를 시작으로 SAP HANA DB를 적용하여 먼저 전환이 시작되었고 이때에는 ABAP Entity를 기반으로 하는 SEGW OData 개발과 Fiori 활용이 가장 최신이었을 것이기 때문으로 추측한다.

Finance 영역에서는 VDM은 주로 Analytical Cube 및 Query로 잘 정리되어 있다. Finance 영역에서는 CDS View와 이를 기반으로 하는 BO 및 Fiori App의 도입보다는 Cube 및 Query CDS View를 통한 Analytics 적용부터 먼저 시작된 것으로 이해된다. 

하나 눈여겨볼 것은 I_JournalEntry라는 VDM CDS View를 기반으로 R_JOURNALENTRYTP라는 RAP BO CDS View가 만들어져 있고 이를 토대로 I_JOURNALENTRYTP라는 BO Interface도 만들어져 있다는 것이다. 이를 보면 Fiance 영역에서도 최신의 모델로의 전환을 준비하고 있다고 느낄 수 있다. 그러나 한 가지 아쉬운 것은 I_JOURNALENTRYTP BO Interface는 CUD의 기능은 없이 일부 Action들 만을 가지고 있어 기존의 BAPI를 대체할 수 있는 수준은 아니라는 것이다. 

- Finance 영역의 Cube & Query View

[그림 8-28] Finance 영역 Analytica View 중심 Universal Journal VDM8

참조 : Analytics on Universal Journal, the heart of SAP S/4HANA | SAP Blogs

이들 Finance VDM의 주요 Cube CDS View 기반으로는 다음 표와 같은 표준 Query CDS View들이 만들어져 있고 Cube CDS View를 기반으로 Custom Query CDS View를 만들어서 활용할 수도 있다. 

[그림 8-29] Univeral Journal VDM - Cube View 기반 Consumption View(Query View)

지금까지 S/4HANA 표준 VDM의 CDS View들을 주요 모듈별로 예를 들어 살펴보았다. ADT를 활용하여 다양하게 필요한 영역을 탐색하면 필요한 Data 정의를 확인할 수 있을 것이다. 

개발자나 경험이 있는 컨설턴트가 아니라면 ADT를 활용하는데 어려움이 있을 것이다. 이럴 경우 앞장에서 살펴본 View Browser App(F2170)을 활용할 수 있다. 

이 Tool은 ADT 만큼 유연하게 활용할 수 있지는 않아서 필터 조건을 잘 활용해서 원하는 CDS View를 상세 페이지에서 Element(field) 선언, Annotation, Association 등을 확인할 수 있다. 

예를 들어 RAP BO CDS View를 탐색할 경우 Transactional영역 아이콘을 선택한 후 필터 조건으로 App. Component(SD* 로 시작(Start with)), Name(R_*로 시작(Start With))를 설정하면 R_*TP 형태의 이름 규칙을 가진 RAP BO CDS View를 확인할 수 있다. 

[그림 8-30] View Browser를 활용한 VDM CDS View 탐색

- Cube CDS View: Composite영역 선택, 필터 조건 :App. Component(SD*), Data Category(Cube), I_* Name으로 시작하며, Description/Name항목에 Cube 명칭이 사용됨

- Query CDS View: Consumption영역 선택, 필터 조건 : App. Component(SD*), Data Category(Query), C_* Name으로 시작하며, Description/Name항목에 Query/Qry 명칭이 사용됨

- Dimension CDS View: Basic영역 선택, 필터 조건 :App. Component(SD*), Data Category(Dimension), I_* Name으로 시작하며, Master/Text/Value Help 등이 있음

- BOPF BO CDS View: Transactional영역 선택, 필터 조건 : App. Component(SD*), Name(I_*),  I_*TP Name으로 되어 있으며, BOPF BO로 사용됨

- Extend View : Extension영역 선택, 필터 조건 : App. Component(SD*), E_* Name으로 시작하며, Description에 Extend 된 Table명칭 확인 가능

- API CDS View : Composite영역, 필터 조건 : App. Component(SD*), Name(A_*), A_* Name으로 시작하며, Description 항목에 Header, Item, Element 등으로 구별되어 있음

8.3 CDS Data Modelling

CDS의 기본 개념과 S/4HANA에서의 CDS의 활용에 대하여 살펴보았다. 이제는 CDS 기술을 활용하여 CDS를 설계하고 개발하기 위한 기술적 내용에 대하여 한 단계만 더 자세히 들여다 보기로 하자.

1) Why CDS View?

SAP가 S/4HANA의 Data Infra의 근간으로 CDS View 기반의 VDM을 도입한 이유에 대하여 살펴보는 것에서 출발해 보자. 이를 위해서 먼저 일반적인 SQL Basic과 ABAP의 기존(Classical) Approach에 대하여 복기해 보자.  

(1) SQL과 ABAP Open SQL

SQL(Structured Query Language)는 DBMS에 Access 하는 언어로서 SQL-92등으로 표준화의 정도가 높으며 통상 DDL(Data Definition Language), DML(Data Manipulation Lanauage), DCL(Data Control Language)로 구성되어 있다. DML은 Table의 Data를 Read/Change 하는데 활용된다. DDL은 DB Table과 View를 정의하고 관리한다. DCL은 Data 접근에 대한 권한을 관리한다. 

ABAP도 Applicaton Language로서 프로그래밍 언어와 통합된 Open SQL을 가지고 있다. Open SQL은 DB 독립적 문법을 가지고 있고 DB 독립적인 행위를 한다. 단 DB 독립적이기 때문에 어떤 DB에도 적용될 수 있도록 하기 위하여 공통적으로 적용될 기능만을 가지고 있기 때문에 SQL-92 표준 대비 기능은 적다.

ABAP에서의 DDL은 ABAP Dictionary로서 DB에 독립적인 도구이며 Table과 View를 정의하는 Form 기반 Editor를 사용한다. ABAP에서 DCL은 필요하지 않다. 이는 DB leveld에서 권한관리와 tranaction control이 이루어지고 항상 Application에서 권한 Check가 수행되기 때문이다. 요약하면 아래와 같다. 

[요약] SQL Basic & ABAP의 Classical SQL Approach

(2) ABAP에서의 Classical Open SQL의 한계 

ABAP Open SQL은 SAP가 지원하는 모든 DB에서 일반적인 Semantic을 정의하는 only DB abstraction layer이다. 따라서 몇 가지 제약을 가지고 있었다. 

[그림 8-31] ABAP Classical Open SQL의 한계

일반적인 제약사항  

   - No fixed values

   - No computed values

   - No CASE expressions  

   - No SQL functions

Join에 대한 제약사항

    - Inner join 및 left outer join만 가능

    - Only Equi-Joins (join condition with operator “=”)

    - left outer join에서 WHERE 문의 field 또는 right table 불가

이 외의 제약사항
- UNION 또는 UNION ALL 불가

이러한 한계가 발생하는 이유는 

Open SQL은 DB 벤더별로 다른 결과를 만드는 것을 피하기 위해 (Syntax가 아니라) 결과에 있어 DB 독립적이길 원하고 

ABAP Programming의 기본 Performance rule은 불필요한 load를 DB로부터 멀리 유지하는  것 즉 ABAP Runtime이 담당하는 것을 기본으로 하기 때문에 복잡한 SQL 기능(Feature)들이 필요 없기 때문이었다. 

ABAP Dictionary View를 정의하면 ABAP SQL과 Standard SQL 사이의 Gap은 더 커지게 된다.  

[그림 8-32] ABAP Dictionary View의 한계

DB에 독립적인 DB View  

  -  ABAP Dictionary 정의(form based tool)

  -  DB에서 생성됨 (CREATE VIEW statement)

SQL feature 지원 제약  

  - Only inner joins with Equi-join

  - Only simple projections
     (no 계산 field, no conversions, 

     functions,…)

  - Only simple selections (using literal 

     values)

                                                                             - Only DB tables as source (View-on-View

                                                                               는 지원되지 않음)

Some ABAP specialities  

  - Buffering

  - Labels (through data elements)

  - Search helps와 foreign key 관계(underlying table로부터 계승됨)

(3) SAP HANA와 Code-to-Data Programming 방식의 필요성

S/4HANA가 SAP HANA DB를 근간으로 하면서 SAP HANA의 장점(Parallelism, Optimized data Structure & transfer 등)을 활용하기 위해 ABAP application server로 대량의 데이터를 불러서 처리하기보다는 Expensive Calculation과 Aggregation을 DB에서 처리하도록 하는 ABAP Programming 패러다임의 근본적인 변화를 가져왔다.

[그림 8-33] Code Push Down Programming Approach

Classic ABAP programming의 기본 Approach는 DB에 부하를 주지 않고 Application server에 필요한 모든 데이터를 가져와서 ABAP에서 Processing 하는 것이었다. 이는 왼쪽 그림의 Data to Code Approach이다. 

그러나 HANA DB를 보유한 SAP는 이제 다른 DB를 고려할 필요 없이 DB의 장점을 충분히 누릴 수 있도록 하는 Programming 패러다임, 즉 Code-to-Data, 혹은 Code Push Down 방식으로 전환한 것이다. 

이에 따라 Application의 설계 시에도 각 로직 처리를 담당하는 서버의 역할이 아래 그림과 같이 바뀌게 되었다. 즉 Data Centric 로직은 DB서버가 담당하고 UI Application 로직은 UI나 Client 측 Application이 로직을 처리하여 Application 서버의 역할을 분산한 것이다. 

[그림 8-34] Code Pudh Down에 따른 Application Design의 변화

이것을 HANA CDS와 ABAP CDS에 대하여 살펴보면 아래 그림과 같다. 

[그림 8-35] HANA CDS와 ABAP CDS의 Application Design Paradigm 변화 비교

2) What is CDS? - CDS 개념 및 ABAP CDS 

Core Data Services(CDS)는 SAP HANA에서 의미적으로 풍부한(Semantically rich) Data model들을 정의하고 사용하기 위한 언어/서비스의 모음이다.

(1) ABAP CDS 기능

DDL, DCL과 함께 DML로서의 QL(Query Lanauage)로 구성되어 있으며 DB에 독립적이고 향상된 View 생성 기능을 가지고 있다. Data Model에 Semantics Information을 제공하는 Annotation과 CDS Object 권한 Rule 정의 기능, Join을 대체하는 Association, CDS Table Function 등의 기능을 제공한다.

[그림 8-36] ABAP CDS의 구성 및 기본 기능

ABAP Dictionary View에서 제공하지 않던 새로운 기능들을 제공하는데 아래와 같은 것들이 있다.

[그림 8-37] ABAP Dictionary View와 ABAP CDS View 차이

ABAP CDS View의 추가 기능 

UNION와 OUTER join 같은  combining query에 대한 지원이 강화됨   

selection을 위해서, 또는 column list에서 표현하는 calculations 지원  

data model에서 Aggregation, grouping 하는 기능  

Nested views (View on view)

(2) ABAP CDS View의 기술적 구성

CDS View는 DDL Source안에 정의되는 새로운 유형의 Repository Object이다. DDL Source는 Classic ABAP Workbench에서는 변경할 수 없으며 ADT에서만 분석/개발 진행할 수 있다.

DDL Source를 Active 시키면 SQL View, CDS View 두 가지 Object가 생성된다. 이 두 Object는 직접 수정은 불가능하고 DDL Source를 통하여 관리된다.

- SQL View : ABAP Dictionary에서 보이는 Object이며,  DDL Source의 일정
  정보만 보여 주는 DB Object의 representative 역할
- CDS View : SQL View보다 더 많은 semantics를 가지지만 DB에는 생성되지 
  않고 ABAP Dictionary에서는 보이지 않지만 (new) Open SQL로 활용 가능

[그림 8-38] CDS의 기술적 구조 - DDL Source, SQL View, CDS View

CDS View의 개발은  아래와 같은 순서로 이루어진다.

    DDL Sources  

    CDS View 정의 (DDL Source Code 편집)  

    CDS Entity에 Access control 추가  

    DDL Source Syntax 체크  

    DDL Source Activation  

    (Optional) Data Record 조회  

    (Optional) 복잡한 CDS View SQL Dependency Tree 분석   

    (Optional) View 간의 Association 분석(Data Preview에서)  

    (Optional) Graphic tool 활용 View 간의 관계 분석  

[그림 8-39] DDL Source에서의 SQL View와 CDS View

오른쪽 그림은 DDL Editor에서의 DDL Source를 통하여 SQL View와 CDS View를 정의하는 예시를 보여준 것이다.

    CDS Entity 이름은 DEFINE VIEW 구문 뒤에 명시됨  

    DDL Source 이름과 CDS View이름은 동일하게 부여하는 것을 권고함  

    SQL View 이름은 @ABAPCatalog.sqlViewName Annotation에 지정함   

    SQL View 이름은 CDS View 이름과 달라야 함 (최대 16자리, Dictionary View와 같이)  

DDL Source에 사용되는 언어는 SQL DDL

어느 DB에서나 적용 가능한 Open SQL Form

CDS는 Open SQL의 한 부분이므로 explicit client handling은 없음

가장 단순한 형태의 CDS는 Projection View(C_*)이며 이는 단일 테이블의  필드 일부를 가지며 기존  DB View와 유사

(3) CDS Annotation

CDS Annotation은 metadata를 가지고 ABAP CDS 내에서 definition을 강화해 준다.

[그림 8-40] ABAP CDS Annotation

metadata로 definition 향상  

“@”로 시작  

complete view(view annotations) 또는 individual parts (element annotations, parameter annotations, etc.)와 관련

대부분 Optional임
(예외: @AbapCatalog.sqlViewName)

View Annotation은 View 자체에 대한   Annotation이며 DEFINE View 구문 전에 위치

 Element Annotation은 필드 리스트 안의 element에 대한 것으로 element 전후에 위치할 수 있음

    - Element 앞에 위치할 때에는 @ 문자 다음

    - Element 뒤에 위치할 때에는 @< 문자 다음

[그림 8-41] ABAP CDS View Annotation 예시

(4) CDS View의 기술적 유형 

[그림 8-41A] CDS View  유형

(5) ABAP CDS View 생성

DB 테이블을 기초로 Basic Interface View를 만들 수 있다. View 생성 시나 편집 시에 Template을 활용할 수 있다.

[그림 8-42] ABAP CDS View 생성(ADT)

3) CDS View 활용

CDS View는 Business Entity를 위한 SAP의 전략적 Modeling Approach이다.  CDS View는 S/4HANA의 Code Push Down을 위한 가장 기본적이고 효과적인 도구이다.

[그림 8-43] CDS View as Code Push Down 도구

HANA의 강점을 최대한 활용하기 위해, application layer에서 DB layer로 Process를 옮기는 것이 필요  

push-down을 위해 CDS Views는 주요한 option이며 장점은 

   - push-down으로 High performance

   - No latency 

   - No data 중복 

   - Ready-to-use content 

   - 유연한 SQL expressions로 생성과

     enhancement이 용이함

   - application에서 쉽게 사용 가능

     (예. OData service 생성)

   - 여러 processes에서 재사용 가능

Recommended:

ABAP application server(즉 ABAP Program) 대신 CDS Views에서 Logic 구현 (예를 들어 ABAP에서 Internal에 필요한 Data를 DB에서 불러다 놓고 다른 처리를 하는 등의 방식을 CDS 사용으로 전환)  

Basic CDS Views 생성 후 여러 프로그램/Application에서 재사용  

이러한 장점을 가진 CDS View들은 다양한 용도로 활용된다.

(1) Analytics

Analytical Apps, Embedded Analytics 전용 Apps, SAP Analytics Cloud 및 BW에 활용될 수 있다. Fiori App(Analytical Fiori App 포함), Smart Business KPIs App, Analysis Path Framework App 등은 OData를 통하여 CDS View의 Data를 활용한다.  WDA(Web Dynpro ABAP) 기술을 기반으로 한 Multi Dimensional Report App, SAC는 InA이라는 Protocol 기반 Transient Query를 통해 CDS View의 Data를 활용한다.

[그림 8-44] 다양한 Analytical Application에 사용되는 CDS View

[그림 8-45] BW Data Source로 활용되는 CDS View

CDS View에 'dataExtractionenabled: true'라는 Annotation이 설정되어 있으면 BW 시스템으로 데이터를 보내는 BW Data Source 역할을 할 수 있다. BW로 replicate 되어 BW Datasource 역할을 수행하거나 Live Connection의 대상으로 설정될 수도 있다. CDS View에 있는 Attribute는 Datasource에서 delta extraction에 사용될 수 있다. 통상 표준 VDM에서는 CDS View 이름 Suffix에 DEX라고 이름 붙여진 것들이 이런 역할을 하는 CDS View들이다.

(2) OData Service 기반 Fiori App 및 API

CDS View를 기반으로 Business Service를 정의하고 이를 기반으로 OData 서비스를 만들어서 Fiori App이나 API를 개발할 수 있다.  

[그림 8-46] OData 서비스 기반 Fiori App, API에서의 CDS View 활용

(3) ABAP Program에서

ABAP 프로그램에서 (New/Advanced) Open SQL을 통하여 CDS View를 활용할 수 있다. Enhanced Open SQL은 SQL 표준 Coverage를 넓히고, Path expression을 통해 CDS association 사용하며, New SQL 기능/Enhanced syntax 지원한다. 

ABAP Program에서 Open SQL를 사용하여 CDS View를 활용할 수 있다. BOPF에서 CDS View를 기반으로 Business Object를 만들 수도 있으나 BOPF 기반 Fiori 개발 programming Model이 RAP Model로 진화되었으니 BOPF에 사용하는 것은 권고되지 않는다. 이 내용은 RAP를 다루는 장에서 다시 설명하겠다.

[그림 8-47] (New, Advanced) Open SQL를 통해 ABAP에서 CDS View 활용

4) CDS View Modelling Guide

CDS View 설계를 위한 참조를 위해 표준에서 정의하여 사용하고 있는 표준 CDS View들을 다음 유형들 중심으로 살펴 보고 가능한 경우 고려 사항도 추가로 언급해 보겠다.

[그림 8-48] VDM 주요 표준 CDS View 유형

(1) Interface View : I_Sales Order 예시

SD모듈 Sales Order 부문의 Basic Interface View 중 하나인 I_SalesOrder(VDM_SD_SLS_SO Package, S/W SD-SLS-SO)를 예시로 각 View 유형들이 어떻게 설계되면 좋을지 참조할 수 있을 것이다.

먼저 아래 그림은 I_SalesOrder CDS View의 View 선언 전에 설정되어 View에 공통적으로 적용되는 Annotation 부분이다. @AnapCatalog, @ObjectModel, @Metadata.allowExtension, @Analytics 등 주요 Annotation에 대하여 확인해 보기 바란다.

[그림 8-49] 표준 CDS View 참조 - Interface View의 View Annotation 부분

View 전체에 적용될 Annotation 선언부 다음에는 View Define 구문이 선언된다. 이때 CDS View명을 선언하고 Data Source(Table 혹은 다른 CDS View)를 지정한다. I_SalesOrder는 I_SalesDocument를 근간으로 하고 이 CDS View는 다시 I_SalesDocumentBasic에서 Data을 select 해 오며 이 CDS View는 최종적으로 VBAK Table의 Data를 근간으로 한다. 이러한 구조는 select 대상이 되는 CDS View명에 마우스를 놓고 Ctrl Key를 누른 상태에서 마우스를 클릭하면 해당 CDS View로 이동하여 확인할 수 있다.

다음으로는 해당 CDS View와 연계하여 사용하게 될 CDS View를 Association으로 선언한다. Association 다음으로는 CDS View의 메인 Element인 Field를 선언한다. Key Field가 먼저 선언되어야 하고 Field들은 해당 Field의 Semantics를 보강할 Annotation 선언을 추가할 수 있다. 

[그림 8-50] 표준 CDS View 참조 - Interface View의 View 선언 부분

Field 선언 다음에는 Association으로 선언된 CDS View들의 Field들도 해당 CDS View 선언으로 같이 활용할 수 있도록 Association Entity 선언을 해 주어야 한다. 

마지막으로는 Selection 조건을 추가하여 Data의 범위를 선언한다.

[그림 8-51] 표준 CDS View 참조 - Interface View의 Association Entity 및 Where 선언 부분

(2) Consumption View 

Consumption View는 CDS View가 최종적으로 사용되는 역할을 수행하는 것이다. 예를 들어 Fiori App에 사용되는 표준 CDS View 중 하나를 살펴보자. RAP OData V4 개발되어 있는 Manage Sales Order V2 app(F3893)의 Consumption View(C_SalesOrderManage)를 통해 표준 CDS View의 설계 원칙을 참조해 보자.

아래 그림 중간 부의 Define 구문이 View 선언의 주요 부분이고 그 이전에는 CDS View 전체에 적용되는 Annotation이 선언 된다. 이 예에서는 권한설정(@AccessControl), Metadata extension 설정(@Metadata), Object Model 설정(@ObjectModel), VDM 설정(@VDM) 등이 선언되어 있는 모습을 참조해 볼 있다. Consumption View는 특히 VDM View Type으로 '#CONSUMTION'이 선언되어 있고 많은 경우 Metadata extension이 허용되어 있다. 

Define View 구문을 살펴보면 

- Define View라는 구문 대신 그 구문의 최신 버전인 Define view entity를 사용해고

- RAP BO의 Main Object이기 때문에 Root로 선언되어 있으며

- Provider contract transaction_query로 선언되어 있고

- R_SalesOrderTP BO CDS View의 'Projection'으로 선언되어 있으며 SalesOrder라는 Alias를 선언했다. Define 구문 다음에는 연관된 CDS View들에 대한 Association이 선언되어 있다.

[그림 8-52] 표준 CDS View 참조 - Consumption View 선언 부분

Association 선언 다음에는 CDS View의 Data Element(Field)에 한 선언이 뒤 따른다. 여기에서는 Fiori App의 UI에서 사용할게 될 기본적인 Annotation이 필드 앞에 선언된다. @Search, @ObjectModel.text, @ObjectModel.sort 등이 그러한 것들이다. 또한 Virtual Field 선언도 눈여겨볼 만한다. 이 필드는 실제 DB Field를 참조하는 Data Element가 아니라 ABAP Class의 ABAP 로직을 통하여 Data를 제공하는 필드들이다. 이 예에서는 주로 상태들을 표시하기 위한 Virtual Field들이 선언된 것을 확인할 수 있다.

[그림 8-53] 표준 CDS View 참조 - Consumption View의 Element 선언 부분

Main CDS View 차체의 Field 선언들 뒤에는 BO Composition, Association 된 Field 들의 Project 선언이 뒤따른다.

예를 든 CDS View는 단순히 Data 조회만을 처리하는 일반적인 Consumption View가 아니라 CUD의 Transactional Consumption CDS View이기 때문에 이 View는 RAP BO의 Projection View이고 그렇기 때문에 Main CDS View 자신뿐 아니라 Composition Child 관계에 있는 CDS View와의 Composition 관계를 같이 projection 선언해 주어야 한다. 이러한 RAP BO 및 BO의 Composition 구성에 대하여는 RAP를 다루는 장에서 좀 더 상세히 설명하겠다. 

[그림 8-54] 표준 CDS View 참조 - Consumption View의 BO Composition projection 선언 부분

Composition Child들에 대한 선언 이후에는 Association 관계에 있는 CDS View들을 Projection 선언한다. 아래 그림의 예에서는 Main CDS View 주요 Data Element Field들의 값을 가지고 있는 Dimension CDS View들에 대한 Association을 Projection 선언한 것이다. 

[그림 8-55] 표준 CDS View 참조 - Consumption View의 Association, Where 선언

마지막으로 Where 구문을 통하여 Source CDS View로부터 선택해 올 Data의 조건을 부여 한다 이 예에서는 Sales Order의 Processing Type(VBAK-VBKLT필드) 이 'P', 즉 'Project-Based Service(PBS)'가 아닌 Data들만 Projection 하라는 조건절을 선언한 것이다. 

(3) CDS Meta Data Extension

Manage Sales Order V2 app(F3893) Consumption View(C_SalesOrderManage)의 MetaData Extension(C_SalesOrderManage)을 통해 표준 @UI Annotation을 어떻게 Metadata Extension으로 설계하는지 참조해 보자.

[그림 8-56] 표준 CDS View 참조 - MetaData Extension View 공통 Annotation 선언 부분

annotate view 구문으로 Metadata extension을 선언하기 전에 이 extension view에 공통으로 적용될 UI Annotation을 선언한다. 위 그림에서 몇 가지 예를 들어 보면

- @UI.headerInfo: 

Object Page의 Header Info(Sales Order No, Order Type, 이미지 등)와 List Report Page의 Header Info(Object 유형 이름 복수형과 가로 안에 Obejct 숫자 표시) 등 화면 표시 설정

- @UI.presentationVariant:

List Report page의 리스트의 Sort 순서 등 화면 표시 설정

이제 annotate view 구문으로 선언되는 UI Annotaion을 살표 보자. 

먼저 @UI.facet Annotation을 확인할 수 있다. 아래 그림의 예에서 (1) PartnerHeader, (2) StatusHeader은 type #FIELDGROUP_REFERENCE로 선언되어 있고 UI Facet은 우측 상단에 보여진 것과 같이 Object Page Header 영역에 Partner라는 Field Group과 Status라는 Field Group을 표시하기 위한 annotation이다. (3) SalesVolumeHeader와 NetValueDataHeader라는 id를 가진 UI facet도 선언되어 있으며 이는 type #DATAPOINT_REFERENCE로 설정되어 데이터 항목들을 Object Page Header 영역에 보여주는 Annotation이다. 

[그림 8-57] 표준 CDS View 참조 - Metadata Extension의 UI Annotation 선언 부분 1

아래 그림들은 Object Page Contnent 영역에 Generation tab에 Basic Data Section에 Order Data, Ship-to Party Data라는 필드 그룹에 필드들을 표시하기 위한 Annotation 예시들이다. 

[그림 8-58] 표준 CDS View 참조 - Metadata Extension의 UI Annotation 선언 부분 2

[그림 8-59] 표준 CDS View 참조 - Metadata Extension의 UI Annotation 선언 부분 3

아래 그림의 @UI.lineItem Annotation은 ListReport에서 항목들을 리스트 할 때 보여 줄 필드들을 위치와 함께 선언한 것이다.

[그림 8-60] 표준 CDS View 참조 - Metadata Extension의 UI Annotation 선언 부분 4

@UI.identification Annotation을 사용하여 화면에 아이콘을 표시하고 클릭했을 때 실행할 Action들을 정의할 수도 있다.

또한 아래 그림에서와 같이 @Consumption Annotation을 사용하여 Object Navigation을 위한 설정을 할 수도 있으며 @Annotation.valueHelpDefinition을 사용하여 Possible Entry를 위한 Annotation을 선언할 수도 있다.

@UI.selectionfield Annotation은 List Report 초기 화면에서 사용되는 Filter 설정을 위한 Annotation이며 @UI.textArrancement Annotation은 필드 이름 표시 규칙을 정의하는 데 사용되고 @UI.lineItem은 Table 들에 List 될 Item을 정의하는 데 사용된다. 

[그림 8-61] 표준 CDS View 참조 - Metadata Extension의 UI Annotation 선언 부분 5

앞의 Object Page Header 영역 화면 표시를 위한 Annotation에서 사용되었던 #FIELFGROUP_REFERENCE, #DATAPOINT_REFERENCE 등에서 정의했더 Fielf Group과 Data Point는 @UI.fieldGroup으로 별도로 포함되는 필드들을 선언해 주어야 하며 @UI.dataPoint로 필드명과 Title들을 지정해 주어야 한다.

이상의 C_SalesOrderManage CDS View의 Metadata Extension을 통하여 살펴보았듯이 UI Annotation을 통하여 meta data driven UI를 구현할 수 있다. F3893 Manage Sales Order V2 표준 App은 상당한 부분의 UI 기능이 Metadata extension에 선언되어 있다.

(4) RAP BO TP CDS View

RAP BO TP CDS View는 RAP 방식의 Fiori App 개발을 위한 RAP BO의 기반이 되는 CDS View이다. Fiori App 개발을 위한 Programming 방식은 크게 (1) Classic ABAP programming(SEGW), (2) CDS 기반 BOPF를 활용한 ABAP Programming Model for Fiori, (3) ABAP Restful Application Programming Model로 진화되어 왔다. RAP 모델은 새로운 S/4HANA 기능의 개발 중심으로 빠르게 적용되어 가고 있다. 이에 대하여는 이후 더 자세히 다루도록 하겠다. 

Manage Sales Order V2 app(F3893)의 Consumption View(C_SalesOrderManage)의 기본이 되는 RAP BO TP View인 R_SaleOrderTP를 참조하여 표준 RAP BO TP CDS View의 설계 원칙을 생각해 보자.

[그림 8-62] 표준 CDS View 참조 - RAP BO CDS View

RAP BO CDS View는 @VDM Annotation을 통해 lifeclycle.contract.type이 #SAP_INTERNAL_API로 선언되어 있고 viewType은 #TRANSACTION으로 선언되어 있다.

일반 CDS View와 달리 RAP BO 역할을 수행하기 위하여 Business Object를 구성하는 Entity들을 Parent-Child 관계로 구성하기 위하여 Composition 선언을 해야 하며 최상의 Node에 대하여는 Root view 선언을 해야 한다.

(5) API View, RAP BO Interface View

RAP BO TP View인 R_SaleOrderTP 기반으로 만들어진 API View(A_SalesOrder), BO Interface View(I_SalesOrderTP)를 참조를 위해 살펴보자. API View와 BO Interface View는 기술적 배경이나 목적이 다른 CDS View이기는 하나 외부 시스템과의 I/F(API View) 나 ABAP 내부에서의 호출에 사용(RAP BO Interface)된다는 측면에서 보면 유사하다. S/4HANA OP2022 기준 모든 Business Object가 RAP로 만들어져 있는 것도 아니고 RAP BO가 만들어져 있다고 해도 아직 RAP BO Interface가 만들어져 있지 않은 것도 있고 RAP BO Interface가 만들어져 있다고 해도 제한적인 기능만 수행하는 것(예, I_JournalEntryTP)도 있다. API View도 아직은 RAP BO 기반으로 만들어져 있는 것보다 그 이전의 법으로 만들어져 있는 것이 훨씬 많다. 그러나 앞으로의 새로운 S/4HANA 버전에서는 점점 이 방향으로 전환되어 갈 것으로 기대한다.

[그림 8-63] 표준 CDS View 참조 - API View, BO Interface View

(6) Anaytical CDS View - Cube 설계/개발 Guide

[그림 8-64] Analytical Cube CDS View Basic Model 및 Dimentsion CDS View association

Cube CDS View는 @VDM.viewType: #COMPOSITE , @Analytics.dataCategory: #CUBE annotations를 사용함  

모델 생성 시 Join 구조를 단순화되도록  FACT View 또는 개별 Entity를 생성하며, 복잡한 계산식은 Multi 레벨로 CDS View를 생성함

Dimensions 필드에 대해 @ObjectModel.foreignKey.association을 사용하여 필드의 Text를 결합 조건을 정의함  

수량/금액 등 단위를 포함하는 Measure 필드에 대해  @Semantics.amount.currencyCode , @Semantics.quantity.unitOfMeasure annotations를 사용  

분석 기준일에 대해 월/분기/반기/년도 등 추가정보 필요시 I_CalendarDate Dimension CDS view를 사용함. 

CDS parameters는 단일 값만 지원하고, 입력은 mandatory, 지원되는 parameters 최대 길이는 29 임

Cube CDS View에는 통화 변환을 제외한 parameters를 최소화함. parameter가 있는 Cube CDS View는 HANA 테이블 함수에 매핑되어 성능에 영향을 미칠 수 있음  

 Alpha Conversion, NUMC type 필드를  Join시 필드 길이 및 Alpha 유무를 확인

parameter가 있는 Dimension View 또는 Text View에 대한 Association을 지원하지 않음  

Cube, Dimension, Query CDS View에서 'group by' 절 사용금지하는데 이는 Analytic Engine에서  'group by' 절을 자동으로 생성하기 때문임   

 

(7) Anaytical CDS View - Query 설계/개발 Guide

Query CDS View는 @VDM.viewType: #CONSUMPTION, @Analytics.query: true annotations를 사용함.  

Measure 필드에 대해 @DefaultAggregation: #SUM / MAX / MIN 사용하여 집계 값을 표현  

Dimension 필드에 대해 @AnalyticsDetails.query.display: #KEY_TEXT 을 사용하여 Code 또는 Text의 Display를 선택함

고정된 hierarchy 연결을 사용 시 @ObjectModel.hierarchy.association annotations를 사용함

@AnalyticsDetails.query.hidden annotation을 사용하여 필드 숨김 기능을 사용할 수 있음

UNIT_CONVERSION, CURRENCY_CONVERSION 함수를 사용하여 단위/통화 환산을 적용 가능  

Multidimensional Report 사용 시 Layout에 대한 정의는 @AnalyticsDetails.query.axis: #ROWS/ #COLUMNS/#FREE (default) annotations을 사용함  

Query CDS View에서  @Analytics.query:true 를 사용하면 Union은 지원되지 않음. Cube CDS View에서 사용할 것  

(8) Enterprise Search Models에서 사용되는 Search Object CDS View

앞장의 Fiori Launchpad 기능 설명에서 S/4HANA의 강력한 기능 중의 하나로 Enterprise Search를 설명하였다. CDS View는 이 Enterprise Search의 대상이 되는 Search Object로 사용된다. Enterprise Search Models에서는 두 가지 클래스의 Search Model이 지원되고 있으며 Manage Search Models App(F3036)에서 확인할 수 있다.

이 App을 통하여 Enterprise Search Model 이름과 상태를 확인하고 상세 페이지에서 Data Source, Search View와 Genral Information 및 해당 Search Model의 상세 내용을 확인할 수 있다.

[그림 8-65] 표준 CDS View 참조 - Enterprise Search Model Search Object CDS View

[그림 8-66] 표준 CDS View 참조 - CDS 기반 Search Model Table 기반 Search Model

앞에서도 설명했지만 이렇게 Enterprise Search Model 설정을 활용하여 Fiori Launchpad 중앙 검색 창을 통해 HANA DB를 사용하는 연결된 애플리케이션 시스템의 비즈니스 entity를 검색 가능할 수 있다.

[그림 8-67] Enterprise Search Model 기반 Enterprise Serarch 활용

Enterprise Search Personalization 설정도 가능한데 특히 필요한 Search Object를 선택하여 검색의 범위를 좁힐 수 있다.

[그림 8-68] Enterprise Search 개인화 통한 Search Object Business Entity 범위 설정

5) CDS View 개발 및 Performance Guide

(1) CDS View General Guideline

CDS View 원칙: Model Once, Use everywhere

핵심 프로세스에 쓰이는 CDS인데 성능상의 명백한 이슈가 있으면 작은 CDS로 분할하여 성능 개선하는 것도 검토할 수 있음  

Analytics Scenario 등의 경우에 복잡한 계산을 포함하는 큰 CDS View를 만들면 성능상 이슈가 될 수 있음, 특히 많은 연산 Column을 포함할 경우  

HANA Studio의 Expensive Statement Trace 기능 사용하여 Execution이 오래 걸리거나 메모리 사용이 높은 CDS를 찾을 수 있음(DB 권한 필요)  

HANA Studio의 HANA_Threads_ThreadSamples_FilterAndAggregation SQL 구문 사용하여 high consumption CDS view 찾을 수 있음   

ADT의  dependency Analyzer tool을 사용하여 CDS View의 복잡도를 추적 관리할 수 있음

CDS 성능을 위한 Modeling Best Practices : 빠른 실행, 단순한 Preparation, 적은 run time 메모리 사용을 위해 CDS View는 가능한 단순하게 만들어야 함

가능한 적은 수의 테이블 사용 : 100개 이상의 테이블 기반으로 하는 CDS view는 만들지 말 것  

정말 필요로 하는 필드들만 Consumption View에 포함시켜 Expose 할 것  

Stack Depth(View on View의 계층)와 View 숫자를 줄일 것  

   - 필요한 extension이나 App을 가능한 적은 수의 View로 꼭 필요한 기능만 만들 것

   - 각 join이나 계산 field 마다 특별한 view를 만들 필요는 없음

   - 다른 aggregation drill을 사용하지 않는 한 같은 테이블 Access는 재사용할 것

모델링 순서  

- Result set을 먼저 구축하고 상위단의 View Hierarchy에서 보조 Data 데이터를 Join 할 것

   - Fact Table에서 skeleton 데이터를 먼저 읽고 결과의 레코드 수에 영향을 미치는 entity를 Join 할 것

    (INNER JOINS은 레코드 수를 줄이고, OUTERTOMANY 조인은 숫자를 증가시킬 것임)

   - 필요한 필드를 최상위 level에서 기존 레코드에 Join 하거나 Association 할 것 

   - 계산 Column 같은 Expensive Operation은 필터링, aggregation 통해 데이터를 줄일 후 실행 할 것 

   - 계산 column을 키필드나 (WHERE 절의) 필터 필드, (ON 절의) join 조건의 필드에 사용하는 것 피할 것 

(2) CDS VDM Guideline

Basic View : DB Table와 Public Basic View를 Access 하는 View, Reuse View

관련 Business Data를 Normalize 하여 expose 할 것  

Custom Basic View는 Custom Table에 기초하여 non-private view로  만들 것   

중복 Data를 담지 말 것   

Basic View는 Parameter를 정의하면 안 됨  

Composite View : Basic View 여러 개에 기초한 Reusable View 

Data를 projection, Calculation, Join, Filter 및 aggregate 하는 데 사용  

Extension include view 뿐만 아니라 Basic view 및 다른 Composite View와 association을 가질 수 있음  

Consumption View : Transaction, Analytics 등 다양한 영역에서 App 특화의 요구사항에 대응하기 위한 View

Consumption View : Transaction, Analytics 등 다양한 영역에서 App 특화의 요구사항에 대응하기 위한 View

(3) CDS View status Guideline

Released CDS View만 사용할 것, Deprecated CDS column 사용하지 말 것

[그림 8-69] CDS View Status

3가지 Stability Contract   

   - C0 : Contract for key user extension

   - C1 : Contract for system-internal use

            ( 표준 CDS를 고객이 재사용 가능)

   - C2 : Contract for remote API use

C1 Contract는 3가지 Release 상태 가짐  

   - Released 

   - Deprecated : Upgrade 전까지 만 사용 가능

   - Decommissioned : 무조건 사용 금지

Deprecated와 Decommissioned CDS View는 절대 사용하지 말고 Released  CDS View만 사용할 것   

ADT Tool의 Properities : API State CDS에서 확인 가능, 최신 Deprecated 및 New CDS는 관련 Note 확인   

표준  CDS View 내에 Deprecated 상태(@VDM.lifecycle.status: #DEPRECATED)를 가진 column은 사용하지 말고 @VDM.lifecycle.successor Annotation 가진 Column  대신 사용   

(4) CDS Extension Guideline

Extend View 사용 : 표준 CDS View에 표준 혹은 Custom 필드 추가, 혹은 association(특히 Custom table과) 정의 

[그림 8-70] CDS View Extension

CDS View Extension은 표준 CDS View에 신규 datasource 기반 새로운 element(필드) 추가 혹은 새로운 Association 정의   

Metadata Extension은 CDS entity의 element나 parameter들에 기존 Annotation을 overwrite 하거나 신규 Annotation을 추가함  

Upgrade 시 Field 이름 등으로 에러 발생할 수 있으니  In-App Key User tool인 CFL을 사용하거나 필드 이름 지정에 신중할 것  

[그림 8-71] CDS View Extension 표시

I_PLANT, I_PRODUCT 같은 Central CDS View를 Extend 할 때에는 관련된 Object가 다수이기 때문에 Activation 및 Transport 할 때 성능상 이슈가 발생할 수 있으니 주의할 것    

이러한 고려에도 불구하고 CDS를 새로 만드는 것보다는 기존 CDS View를 extend 하는 것이 나음  

Metadata Extension:  @Metadata.allowExtensions: true로 설정되어 있어야만 함 

CDS View Extension: @AbapCatalog.viewEnhancementCategory[#NONE]인 경우 불가

CDS Extend View  : 1) 표준 VDM에 Custom table 추가 2) 표준 VDM에 표준 필드 혹은 Custom필드 추가 @AbapCatalog.viewEnhancementCategory[#NONE] 설정되어 있는 CDS View를 Extend불가 

Release 되지 않은 표준 VDM Extend 하지 말 것 

Basic View를 다른 business contex로 Extend 하지 말 것. 예를 들어 I_SalesDocumentItem에 제품 속성을 추가하면 Basic view에 데이터 중복을 만들 게 됨

Custom field extension은 되도록 CFL(custom field & logic) App을 활용할 것  

CFL을 쓰지 않고 ADT를 쓸 경우 SAP가 제공한 extension include view(E_XXX 형태)를 사용할 것  

동일 CDS View의 Custom field extension에 CFL과 ADT를 같이 쓰지 말 것  

ADT를 쓸 경우 동일 CDS View에 여러 extension view를 만들지 말 것  

BW Datasource로 delta extraction이 가능하게 설정된 CDS View를 Extension 할 때, 특히 Association을 extension 할 때에는 추가 테이블을 delta capture 되도록 해야 함   

Naming 규칙을 따를 것 향후 Upgrade 안정성을 위해  

예시 1 : 표준 VDM에 Custom Table 추가  

   - 예를 들어 VBAK에 ZVBAK 추가하여 연계할 경우

   - Custom CDS view를 Custom Table을 access 하는 Basic View로 만들어야 함

   - 이 Basic View를 CDS View Extension을 통해 Association으로 연결

예시 2 : 표준 VDM에 Custom field 추가 시 아래 순서로

   - Option 1: CFL 사용: 프로젝트 정책에 따라

   - Option 2: E_로 시작하는 Extension Include View 사용하여 view extend

        step 1: extension include view에 필드 추가

        step 2: 추가할 표준 VDM의 View Extend 하여 extension include view 포함

   - Option 3 : View를 직접 Extend 하여 필드 추가

예시 3 : 표준 VDM에 표준 필드 추가 시 아래 순서로

   - Option 1: Extension Include View 사용, 예시 2와 동일 절차

   - Option 2 : View를 직접 Extend 하여 필드 추가

   - CFL은 표준 필드를 추가하거나 표준 view를 association 할 수 없고 Custom 필드만 할 수 있음 

Metadata Extension : 표준 CDS View의 behavior를 수정하는 것이므로 신중해야 함 

표준  CDS view의 behavior를 수정하는 것이므로 신중해야 함  

명시적으로 C1 Contract이거나 implicit UI Contract여야 함 : Fiori UI에 쓰이는 CDS view가 incompatibly 하게 변경되면 UI Extension 한 기능에 문제가 발생할 것임  

꼭 필요하고 Stable 한 CDS View만 Metadata extension을 사용할 것  

Released 되지 않은 표준 VDM은 Metadata extension 하지 말 것  

Metadata extension 파일이 정의되면 annotated CDS view의 모든 UI domain annotation을 포함해야 함  

동일 annotation domain의 annotation을 다양한 metadata extension 파일에 분산시키는 것은 피해야 함   

DB Hints: View level(전형적으로 Custom view나 Cube)의 metadata extension으로 설정되어야 함

Data Extraction enable 설정된 View의  Annotation을 추가/변경하고 싶은 경우 아래만 가능

 - analytics.dataExtraction.Delta.byElement.mazDelayInSeconds   
 - analytics.dataExtraction.delta.byElement.ignoreDeletionAfterDays

Default Behavior Key/Text: 특정 필드(특히 상항 key와 텍스트를 보여 주기 위해) 기본 display 옵션을 변경할 경우 새로운 필드 기반 annotation으로 dimension CDS View를 Extend 해야 함  (@AnalyticsDetails.query.display: #KEY_TEXT)  

Consumption Value Help : 필드의 Value Help를 변경하고자 할 경우 @consumption.valueHelpDefinion 추가  

Consumption Filter: 새로운 필드를 필터로 지정하고자 할 경우 @consumption.filter 추가할 수 있음,  표준 정의는 바꿀 수 없음    

Hide Fields: @consumption.hidden 혹 @Analytics.hidden 사용하여 필드를 숨기는 것 가능, 필수 필드는 숨길 수 없음  

Analytics Detail Query Variable Sequence: Prompt나 Filter bar에 Variable이나 parameter의 순서를 바꾸고 싶은 경우 @AnalyticsDetails.query.variableSequence으로 기존 정의 Overwrite 가능  

(5) CDS Annotation Guideline

[그림 8-72] CDS View Performance Annotation적용예시

CDS View Performance Annotation

CDS View에 @ObjectModel domain의 3가지 Performance Annotation은 반드시 설정해야 함 : serviceQuality, dataClass, sizeCategor

Performance Annotation별 종류
- @ObjectModel.usageType.serviceQuality :
     #A,#B,#C,#D,#X,#P
- @Object.Model.usageType.sizeCategory:
     #S,#M,#L,#XL,#XXL
- @ObjectModelusageType.dataClass:
#TRANSACTIONAL,#MASTER,#ORGANIZATIONAL,#CUSTOMIZING,#META,#MIXED

점검 방법
- ATC/ Code Inspector Check :
“CSD Views: Check @ObjectModel.usageType Annotations”를 사용 점검함
ATC Check ‘BC_CDS_PF1’은 없거나 잘못된 performance annotation 및 설정된 performance annotation에 부합하지 않은 CDS View 속성 알려 줌
- SE16 Table DDHEADANO 점검, 특히 STRUCOBJN: CDS Name; Name: OBJECTMODEL.USAGETYPE.SERVICEQUALITY

Annotation @ObjectModel.usageType.serviceQuality

serviceQuality는 CDS View의 예상성능에 대해 서비스 품질을 반영함. serviceQuality에 따라서 사용자는 view가 요구사항에 맞게 응답하는지를 정할 수 있음. 각 CDS View는 quality category 중 하나에 반드시 지정되어야 함. KPI들은 check 되고 몇몇의 Category는 특정 품질을 증명하기 위한 적절한 테스트 케이스가 있음

Service Quality의 등급은 4개가 있음. 

serviceQuality 종류: # A,# B,# C,# D,# X,#P
- KPI에 따라 ‘A’, ‘B’, ‘C’, ‘D’로 구분되며, 가장 높은 KPI 요구사항이 ‘A’ 임
- ‘X’는 KPI가 없으나 특정 test case가 요구됨
- ‘P’는 View hierarchy를 구성하는 데에 사용되며, hierarchy 밖에서는 사용되지 않음

점검 방법 :
CDS View Performance Annotation 공통 점검 방법
+ 각 Label에 대한 추가 점검 (A, B, C, D, X, P)

transactional processing을 하는 CDS view는 아래 필수사항을 만족해야 함
(Fiori application에서 Transactional 단계로 자주 사용되는 ABAP top 100 transactions)
- serviceQuality 중 높은 등급인 A나 B에 대해서는 service 계약을 필수 수행해야 함
- CDS view가 단순해야 함
- CDS view에 CDS key field를 통해서만 접근해야 함
- serviceQuality 중 낮은 등급인 C, D, X는 큰 볼륨의 transactional process에 사용 불가

Annotation @ObjectModel.usageType.serviceQuality : Label A

큰 볼륨의 transaction의 비즈니스 Logic이나 Background processing (예. Sales order 생성)에 사용되는 View. 데이터는 코드와 결정사항이 처리될 때 단계별로 요청되므로 result set에 몇 개의 row만 있는 많은 요청의 Access 패턴이 발생함. 이러한 프로세스는 고객 측에서 1초당 1000회 발생할 수 있으므로, 합리적인 응답 시간과 resource 사용을 위해 이러한 요청에 대한 KPI는 상당히 엄격함

View는 table 3개 이하로 구성되어야 함.  

Function을 포함하면 안 됨  

직접적인 Access로 많은 수의 Table row를 aggregate 하면 안 됨  

data class가 다른 table을 포함하면 안 됨  

모든 Underlying table이 buffer 되는 경우, View도 buffer 되어야 함  

최소의 field 전송인 SELECT SINGLE의 Runtime은 1 ms 미만이어야 함  

SELECT SINGLE *의 Runtime은 2 ms 미만이어야 함  

Annotation @ObjectModel.usageType.serviceQuality : Label B

Transaction을 위한 비즈니스 Logic이나 Background processing (예. Sales order 생성)에 사용되는 View.   

Label A의 요건이 Label B에도 모두 적용됨. Label A와의 차이점은 자주 실행되지 않는 트랜잭션의 경우 KPI 기준이 낮다는 것임  

View는 table 5개 이하로 구성되어야 함  

Result set(conversions)에서 적용될 수 있는 function들만 포함해야 함  

직접적인 Access로 많은 수의 Table row를 aggregate 하면 안 됨  

서로 다른 data class의 table들을 포함하면 안 됨  

모든 Underlying table이 buffer 되는 경우, View도 buffer 되어야 함  

최소의 field 전송인 SELECT SINGLE의 Runtime은 2 ms 미만이어야 함  

SELECT SINGLE *의 Runtime은 5 ms 미만이어야 함  

Annotation @ObjectModel.usageType.serviceQuality : Label C

단일 Object retrieval의 transaction 관련 UI에 활용됨. 주로 OData를 통한 UI로부터의 Read 요청에 대해서는 요청사항과 Access 패턴을 알 수 있음. 즉, CDS에 대한 요청이 매우 적기 때문에 KPI가 비교적 덜 엄격함.  

View는 table 15개 이하로 구성되어야 함.  

많은 수의 Table row를 aggregate 하면 안 됨  

Application Logic에 활용되면 안 됨  

최소의 field 전송인 SELECT SINGLE의 Runtime은 10 ms 미만이어야 함  

SELECT SINGLE *의 Runtime은 20 ms 미만이어야 함  

Annotation @ObjectModel.usageType.serviceQuality : Label D

이 View는 Analytical reporting에 활용됨. Transactional View에 비해 훨씬 적은 요청을 받기 때문에 KPI 기준이 낮음  

View는 table 100개 이하로 구성되어야 함.  

Customer-like data(또는 Customer 측의 data size)의 Test case가 필수임  

Annotation @ObjectModel.usageType.serviceQuality : Label X

이 View는 HANA에 application code를 push-down 하기 위해 생성되며, data migration과 같은 특수 목적을 위해서도 사용됨.  

Customer-like data(또는 Customer 측의 data size)의 Test case가 필수임.   

Push-down 외 대체 구현안이 존재하는 경우에는 Push-down으로 성능/처리량이 향상된다는 것을 입증해야 함  

Annotation @ObjectModel.usageType.serviceQuality : Label P

Application logic에서 활용 불가  

UI에 활용 불가  

View 재사용 목적으로 사용 불가  

명확한 Test case나 Runtime 측정이 필요하지 않음  

sizeCategory와 dataClass를 위한 annotation을 포함하지 않아도 됨  

Annotation @ObjectModel.usageType.sizeCategory

CDS View는 Size category를 필수 포함해야 함. CDS View에 포함된 테이블 사이즈가  HANA에서 리소스 사용에 영향을 미치기 때문임. (DB access가 몇 개의 row만 return 하는 경우에도)

sizeCategory는 예상되는 Row 개수에 따라 5가지로 분류됨
- S : 1,000 미만
- M : 1,000 ~ 100,000
- L : 100,000 ~ 10,000,000
- XL : 10,000,000 ~ 100,000,000
- XXL : 100,000,000 이상

사용 예시 : @ObjectModel.usageType.sizeCategory: #L

Annotation @ObjectModel.usageType.dataClass

dataClass는 CDS View에 필수 포함해야 함. 상위 layer의 캐시 전략에 대한 결정을 지원하고 이러한 캐시를 사용하여 Client 측 statement routing을 활성화하기 위해서임.  

dataClass 종류는 life time cycle에 따라 6가지로 구분됨
- TRANSACTIONAL :
대용량 transaction(또는 백그라운드 처리)에서 Write/Change 된 데이터가 View에 포함됨. (예. Sales Order processing 또는 Financial Postings의 헤더나 아이템)
- MASTER :
마스터 데이터는 대용량 transaction(또는 백그라운드 처리)에서 Read/Write 되지만 Change 되지 않음. 컨텍스트 정보로 사용자에게 표시됨 (예. material, business partner, account)
- ORGANIZATIONAL : 

     조직 변동 시 데이터가 Write/Change 됨(예. sales unit, distribution channel, cost center) 

   - CUSTOMIZING :

   고객이 SAP에서 제공되는 contents를 보강/확장한 데이터(예. countries, unit of measures, currency)

  -  META :
   Meta data는 시스템 구성 방법이나 entity의 기술구조를 설명하며 일반적으로 전송받은 데이터임. (예. DDIC structures, field control, authorization objects)
  - MIXED :
   서로 다른 dataClass 유형의 데이터가 혼합된 경우

사용 예시:  @ObjectModel.usageType.dataClass: #META

8.4 Code Push Down 이해 

CDS는 SAP HANA DB의 강점을 활용하기 위하여 도입된 S/4HANA의 Data Infrastructure라고 이야기했다. SAP HANA의 In-memory DB의 강점을 활용하기 위한 Program 방법이 Code Push Down이라고 이야기했고 CDS는 그중 가장 좋은 방법이라고 이야기했다. 이 번 절에서는 이 Code Push Down과 관련된 내용을 조금 더 설명해 보기로 한다.

Code Push Down은 SAP HANA DB의 강점을 활용하여 효율적인 개발을 하기 위한 개념으로 계산할 Data를 모두 ABAP Application layer로 불러와 처리하는 대신 HANA DB layer에서 계산을 수행하도록 하고 결과 값 만을 Application에서 받아서 처리하는 프로그램 방식으로 정의할 수 있으며 Code to Data이라고 불리기도 한다.

Code Pushdown에 사용되는 기술에는 다음과 같은 것들이 있다.

Open SQL enhancement = New Open SQL

   - Using SQL Query with imperative and declarative logic like use of literal, arithmetic and logical expressions

CDS Views

   - New Open SQL의 extension

   - Open SQL에서 사용한 데이터 모델이나 Union 및 Association과 같은 기능들을 재사용 가능 토록 함

ABAP Managed Database Procedures (AMDP)

   - DB Procedure를 ABAP에서 처리할 수 있게 한 기능(Class)

   - 하나의 비즈니스 로직을 구현하기 위해 수많은 CDS View가 필요한 경우 효과적임 

[그림 8-73] Code Push Down 노력 대비 HANA DB 강점 활용 정도

기타

    - Information models 

    - Transparent optimizations

    - Reuse components

    - HANA Native SQL

이러한 다양한 기술은 사용하는 노력 대비 SAP HANA DB 강점을 활용하는 성과측면에서 차이가 있다.

그림과 같이 S/4HANA ABAP Application Optimization 방안을 노력 대비 효과 측면에서 다음과 같이 3 Level로 설명할 수 있다.

[그림 8-74] S/4HANA Application Optimization 방안 (3 Level)

Level 1 : Transparent Optimizations : Quick Data Access

Level 2 : Table Buffer enhancements, Advanced SQL in ABAP(Open SQL  Enhancements, CDS Views)

Level 3: SAP HANA Native Features : AMDP, Native SQL

초기에는 Store Procedure Proxy 등의 Bottom-Up Approach만 가능했으나 Top-Down Approach도 가능하게 되어 보다 유용하게 사용될 수 있다.

[그림 8-75} Bottom Up & Top Dwon Code Pushdown Approach

1) CDS - A Most popular way of code pushdown in ABAP

CDS는 정의상 Semantically rich data model인데 이는 기술적으로 new open SQL의 extension으로 이해할 수 있으며 다음과 같은 추가 기능을 제공한다. CDS는 단순하고 재사용성 강한 가장 강력한 Code Push Down 기법이다.

CDS의 추가 기능(Open SQL 대비)

DDL(Data Definition Language) : Used to CREATE Table, MODIFY Table 등  

DQL(Data Query Language) : Used to READ data  

DCL(Data Control Language) : Used to configure ‘SECURITY’  

Expression based Language : Mathematical calculations, conditions Case, EndCase etc.  

Open SQL vs CDS

Open SQL은 개발자가 데이터 계산을 DB Layer로 Push Down 하는 가장 기본적인 기능임  

이 Open SQL에서 사용한 데이터 모델이나 Union 및 Association과 같은 기능들을 재사용할 수 있도록 하는 것이  Core Data Service   

ABAP Dictionary View vs CDS View

Dictionary View는 ABAP SE11에서 관리할  수 있는 View로 SQL문을 사용하여 Application이  결과를 도출하기 위하여 필요한 데이터를 DB로부터 가져오는 기능을 수행함. 이는 대표적인 Data to Code 방식임   

ADT에서 관리할 수 있는 CDS view는 로직을 DB Layer로 Push Down 함. Open SQL을 사용하면 INNER JOIN, OUTER JOIN, UNION 등의 기본적인 명령어들을 사용할 수 있고 매개변수를 프로그램 단에서 주고받을 수 있음  

2)  AMDP(ABAP Managed Database Procedure)

AMDP는 HANA Database에 접근해서 사용할 수 있었던 DB Procedure를 ABAP에서 처리할 수 있게 한 기능(Class)으로 하나의 비즈니스 로직을 구현하기 위해 수많은 CDS View가 필요한 경우 효과적이다.

[그림 8-76] AMDP 개념

AMDP은 구현 절차를 살펴보면 

AMDP Class 선언

AMDP method 선언

AMDP method 구현

ABAP에서 AMDP Class 사용  

등으로 진행되면 표준 인터페이스  IF_AMDP_MARKER_HDB를 사용한다.

[그림 8-77] AMDP Class 구현 예시

3) New Open SQL(Open SQL enhancement)

New OPEN SQL은 기존 일부 명령들이 사라지고 더 많은 내장 함수와 JOIN문들이 추가되어 Database에 좀 더 세부적인 Query를 전달할 수 있게 한 것이다. 주로 새로운 기능으로는 아래와 같은 것들이 있다.

Inline Declaration : 별도 변수 선언을 하지 않고도 선언과 동시에 값의 할당이 가능  

Column 분리 및 변수에 @ 사용 : Column 분리 시 Space 대신 comma(,) 사용하고 변수에 @를 붙여 SQL 가독성 향상  

Aggregate 함수의 기능 확장 :  AVG, MAX, MIN, SUM, COUNT function내에 계산식 적용 가능   

CAST 구문을 사용한 형 변환 : CAST 옵션을 사용하여 컬럼 타입을 변환  가능  

일부 컬럼과 한 테이블의 모든 컬럼을 SELECT 가능 : Open SQL에서 불가능했던 Join시 *으로 특정 테이블의 모든 컬럼을 SELECT 하는 것이 가능해짐  

&& 기호를 사용한 문자열 연결 :   

SQL CASE 사용 : CASE문을 이용하여 컬럼 값에 따라서 분기문으로 처리 가능  

OALESCE를 사용한 NULL 처리 : 컬럼 값이 NULL인 경우, 다른 값을 대체하여 출력할 수 있음, Coalesce 구문은 outer join에서 값이 없는 경우 활용 가능  

JOIN에 사용되는 ON 조건 기능 확장 : BETWEEN, <, >, LIKE 등 비교 연산자 사용 가능  

UNION/UNION ALL :  UNION  중복 제거, UNION ALL 전체 내역  

Complex Join : INNER JOIN안에 INNER JOIN 적용 가능, LEFT OUT JOIN에 다시 LEFT OUT JOIN 연결 가능  

8.5 표준 CDS View 확장 : Field, Table 추가 Enhancement

표준 S/4HANA의 기능, UI를 보완(Enhancement)하여 사용자가 원하는 바를 이루기 위하여 Data Model도 확장(Enhancement)이 이루어져야 한다. 기존 ABAP Workbench 도구에서는 표준 Table에 Append Structure로 필드를 추가하고 이 필드를 기반으로 BADI(혹은 이전의 User Exit 등)으로 로직을 보완하고 BADI(혹은 이전의 Screen Exit 등)으로 화면을 Enhance 하는 방법을 제공했었다. 

이번 절에서는 앞장에서 다룬 In-App Key User Extensibility 도구 및 개발자 ADT 도구를 활용하여 Data Model 차원에서 표준 S/4HANA에 필드와 테이블을 추가하는 방법에 대하여 설명하도록 하겠다. 필드와 테이블의 추가는 S/4HANA의 ABAP 테이블 및 CDS View 정의에서의 필드 data element, table assocaiotn등에 필요한 요소들을 추가하는 것이다. 여기서는 주로 ABAP table 단에서의 기술적 변화/영향에 대하여 설명하기로 한다. 

1) In-App Extensibility CFL(Custom Field and Logic) Tool에 대한 기술적 이해

CFL에 대하여는 앞장에서 소개를 했기 때문에 여기에서는 조금 더 상세한 기술적 이해를 돕기 위한 내용을 설명하기로 한다. CFL에서 필드를 추가하면 다음과 같은 기술 요소들에 자동적으로 필드들이 추가된다.

(1) Table Field 추가(시스템 자동 Generation)

앞 장에서 설명했던 것처럼 CFL을 활용하여 Business Context에 Custom 필드를 추가하면 Table  persistent include structure에 Append Structure로 추가된다. 예를 들어 Business Context Sales Order Header(VBAK)에 필드를 추가할 경우 Persistent include SDSALESDOC_INCL_EEW_PS에 Append Structure로 추가된다. Structure 이름은 시스템이 자동으로 부여한다. 필드 이름은 CFL에서 지정한 이름에 사전에 정의된 Suffix(이 경우 SDH)가 추가된다. SDH는 Sales Document Header의 영문 앞글자가 쓰인 것이다. 

[그림 7-78] Append Structure를 통해 Include Structure에 필드가 추가된 예시

[그림 7-79] Extension Include Persistent Structure 예시

[그림 7-80] 추가되는 필드가 포함된 Append Structure 예시

(2) CDS View Extension(시스템 자동 Generation)

CFL에서 원하는 Business Context(결국은 Table 단위)에 필드를 추가하고 어디에 추가한 필드를 사용할 것인지 설정하고 Generation 하게 되면 

- ABAP Table에 Append 되는 INCL_EEW_PS Structure 대응되는, 해당 VDM에 E_*의 이름을 가진 사전에 정의된 Extension View가 생성

- 이 Extension View는 필요한 CDS View에 표준에서 이미 association 되어 있는 것을 확인할 수 있음

- 이렇게 association 되어 있는 것은 해당 CDS View의 Define 구문 앞쪽에 @ 표시가 되어 있음

- @ 표시를 클릭하면 해당 CDS View의 Extend View를 조회할 수 있음 

- 아래 예에서는 Sales Oder Header(VBAK)의 VDM 구조를 볼 수 있는데 연두색으로 표시한 CDS View들이 Extend View를 가지고 있는 것을 확인할 수 있음 

[그림 7-81] CFL을 통한 CDS View Extension

(3) Data Source에 필드 추가

CFL UI & Reports에서 Enable 시킨 App의 Data Source 유형에 따라 직접  ADT에서 해당 view의 extension을 확인하거나 OData Model에서 CDS view 찾아 ADT에서 확인할 수 있다.

[그림 7-82] OData Service 등 Data Source에 필드 추가

(4) UI에 필드 추가

이렇게 CFL에서 Business Context에 필드를 추가하고 적용할 Application을 지정하게 되면 ABAP Table, 관련 CDS View, 관련 OData 등 필요한 기술 요소들에 해당 필드가 추가된다.

Fiori  App에서 이 추가될 필드를 사용하려면 App의 유형에 따라 필요한 후속 조치가 있다. 

Fiori Element Object Page : Adapt UI로 필드 추가  

Web Dynpro Grid Flexible Analysis app : 자동으로 추가됨  

Object Page 이외의 Fiori Element App 및 Free Style UI5 App(Data Source 가 CDS View인 경우) : Metadata extension으로 UI Annotation 추가  

Object Page 이외의 Fiori Element App 및 Free Style UI5 App(Data Source 가 SEGW OData인 경우) :  

KPI & Report Analytical App : 필드를 Initial Screen에 추가하려면 복사하여 신규 생성(Manage KPI & Reports App사용), Report에 추가하려는 경우에는 자동 추가됨  

 

(5) BAPI에 필드 추가

CFL에 의해 Enable 된 BAPI의 data source 명으로 SCFD_REGISTRY에서 Extensible Function module을 찾아 상세 조회를 하면 BAPI extension Structure를 확인할 수 있고 이 상세를 조회하면 Incl_eew_ps를 확인 가능하며 이 상세를 확인하면 추가한 필드를 확인할 수 있다.

[그림 7-83] CFL를 통한 BAPI에 필드 추가

(6) CFL을 활용한 구매오더, 구매 Info Record 필드 추가

[그림 7-84] CFL를 활용한 구매오더 필드 추가 예시

CFL를 활용하여 구매 오더 헤더 필드를 추가하는 경우 CDS 구조 속에서 어떻게 필드가 추가 되는지 살펴보자. 

Manage Purchase Order V2 App의 경우 OData MM_PUR_PO_MAINT_V2_SRV(SEGW) 사용하고 있고 이는  C_SALESORDERMANAGE_SRV를 사용하고 있는 Sales Order와 다른 형태이다. 이는 Sales Order가 RAP 모델로 개발되어 있다면 구매오더의 경우 BOPF 기반 이전 개발 모델로 구축되어 있기 때문이다.

구매오더 헤더의 경우 UI를 위해서는 I_PurchaseOrderTP View, BO Interface를 위해서는 R_PurchaseOrderTP View를 기반으로 하고 있고 이 두 개의 TP View에 E_PurchaseingDocument Extension View가 Association 되어 있다. 이 Extension View는 INCL_EEW_PS라는 EKKO의 Extension Include을 기반으로 하고 있다. 

CFL로 Org Plant level (EINA)에 필드를 추가하는 경우의 테이블 및 CDS View 필드 추가 구조는 아래와 같이 정리해 볼 수 있다. 

[그림 7-85] CFL를 활용한 구매 Info Record 필드 추가 예시

2) ADT Extend View로 필드 추가

Key User 도구인 CFL로 표준 테이블/CDS View에 필드를 추가할 수 없는 경우에는 개발자 도구인 ADT를 활용하여 필드를 추가할 수 있다. 

(1) 기존 DB table에 있는 필드 추가

DB Table에는 필드가 있으나 CDS View에 없을 경우 Extend View를 통해 필드 추가할 수 있다. 

[그림 7-86] Extend View로 필드 추가 - DB에 있는 필드

또한 DB에는 없는 Calculated Field도 추가할 수 있다.

(2) 기존 DB에 없는 새로운 필드 추가

표준 DB에 필드를 추가하는 가장 좋은 방법은 Key User 도구인 CFL이다. 그러나 이 도구로 할 수 없는 경우가 있다. 대표적으로 Business Contect가 없는 경우이다. 이 경우에는 전통적인 Append Structure 방법으로 Table에 필드 추가하고 관련 CDS View에도 추가하여 화면에 추가되도록 할 수 있다. 그러나 이런 경우 단순히 DB Table에 필드를 추가하는 것으로 완료되는 것이 아니라 필요한 관련 CDS View에 일일이 Extend View를 개발자 알아서 해 주어야 한다. Projection View와 최소한 Root BO CDS View에는 추가해야 한다. 또한 Draft table에도 동일하게 필드를 추가해 줘야 한다.

CDS View에 Extend view 추가하는 절차를 살펴보면 다음과 같다.

Fiori App의 Projection CDS View를 찾는다.  

Projection CDS View의 Extensible Root  View를 찾는다.  

E_ View에 추가하고자 하는 필드를 정의하는 Extend View 추가(Business Context가 있는 경우, 없는 경우에는 main CDS View에 직접 Extend View 추가)

E_View를 달고 있는 main view(I_PurgInfoRecordWWithDraft)에 동일 필드로 Extend View

Draft Table(infrec_hdr_d)에 Append Structure   

Projection View에 Extend View 추가  

3) ADT Extend View로 Table Association 추가 : 다른 Table/CDS View와 Association 

표준 DB Table과 1:1 관계를 가지는 필드들은 CFL이나 Extend View로 필드를 추가할 수 있지만 1:N의 관계를 가지는 필드 혹은 필드 조합은 Table 단위의 Association이 필요하다. Extend View를 활용하여 Table Association을 추가할 수 있다.

[그림 7-87] Extend View로 Table, CDS View Association

Extend View를 생성하고 Association을 활용하여 신규 Table/CDS View 혹은 기존 Table/CDS View를 해당 CSD View에 확장하여 연결할 수 있는 것이다.

하나의 사례를 가지고 CDS View에 Association을 추가하는 것을 좀 더 알아보자. Fiori App UI에서 추가 Table이 필요한 상황이 있다고 가정하고 살펴보자.

먼저 Fiori App의 필요한 기술적 속성을 확인해야 한다. Fiori App Reference Library를 활용하거나 Fiori Launchpad의 해당 App 실행 상황에서 사용자 Action Menu의 i(About)이나 App Support 메뉴를 통하여 확인할 수 있다.

[그림 7-88] Extend View 수행을 위한 Fiori App의 기술 속성 확인

위 그림에서 App의 Technical Name 및 OData Service 명을 확인한다. 이렇게 확인된 OData가 사용하는 표준 CDS View를 알아야 필드를 추가하거나 Table을 Assiciation 할 수 있다. OData의 생성 방법에 따라 확인 방법이 다를 수 있기는 하나 가장 기본적인 방법은 App의 BSP technical Name을 활용하여 확인하는 방법이다.

[그림 7-89] BSP Appplication의 기술적 속성 확인을 통한 CDS View 찾기

SE80 -> BSP Application -> App. Tech. Name(MM_INFOREC_MTS1) Annotation.xml 에 <Annotations Target="MM_PUR_INFO_RECORDS_MANAGE_SRV.C_PurInfoRecordWithOrgType">

을 통해 OData . Entity Type 으로 조합되어 있는 것 확인할 수 있고

Data Model> Page Fragments > i18n > ListReport > C_PurInfoRecordWithOrg (CDS View)을 통하여 CDS View를 확인할 수 있다.

이렇게 App에 쓰이고 있는 CDS View를 찾으면 이 표준 CDS View가 가지고 있는 표준 Association을 확인할 수 있다. 지금 설명하고 있는 예제의 경우에는 표준에 Association 되어 있는 테이블/CDS View가 적절하지 않아 대체가 필요하다고 가정하고 있다.

[그림 7-90]  표준 CDS View의 Association 확인

우리의 예제에서는 ADT에서 표준 CDS View(C_PurInfoRecordWithOrg)를 찾고 association 되어있는 I_* CDS View(Purchasing Info Record Category)를 찾아서 CDS View 복사한다. 

이제 이 CDS View가 대체되어야 한다고 가정하고 복사한 Z_I_* CDS View(Purchasing Info Record Category)의 Logic을 변경 후 활성화한다.

[그림 7-91] 표준 CDS View 복사하여 로직 보완

이제는 새롭게 로직을 정의한 이 Custom CDS View를 Association 할 Extend View를 생성한다. Extend 할 표준 CDS View 설정, Custom I View(Z_I_* CDS View)를 association 설정, Select Field 및 Annotation( Value Help, Label, foreignKey.association 등) 설정한다. 

[그림 7-92] Extend View에 Association 설정

이렇게 새롭게 정의된 필드와 Table이 새롭게 Assocication 되면 이렇게 추가된 필드들을 확인해 볼 수 있다. 

[그림 7-93] SEGW를 통한 새롭게 Association 된 필드들 확인

설명하고 있는 예제에서는 Association으로 추가한 필드를 활용하여 표준에 있는 Filter를 대체한 새로운 필터를 가진 화면을 구성하는 것을 목표로 하고 있다. 이를 위해 표준 CDS View에 Association 된 필드를 Adapt UI를 통하여 새로운 필터 필드로 추가할 수 있다. 

[그림 7-94] Association 된 필드 활용한 Custom Filter 적용

4) Meta Data Extension을 통한 필드 UI Annotation 추가

Metadata extension을 활용해서 metadata을 추가 정의할 수 있다. 표준 CDS View에 metadata extension을 수행하기 위하여는 관련 Annotation이 표준 CDS View 공통 선언부에 선언되어 있어야만 가능하다. 

2023.8.8 Seon