1. Introduction
1.1 What is the ABAP Restful Application Programming Model?
which existing ABAP tech are reflected in the abap RAP model and how they influence the programming model.
what is RAP?
the essential features of the RAP
the RAP architectural style that serves as the basis for the programming model
1.1.1 the purpose of the programming model
the programming model includes 1) data model 2) operations ( ex. creating, reading, changing, or deleteing business objects) 3) busienss logic (ex. calcultions or checks) 4) transactional behavior (ex. locking behavior, numbering , etc) 5) technical interface ( typically odata)
basic concept of programming model based on ABAP platform
which development objects are used to implement a specific application or functionality
what are the tasks of thes development objects?
how are these development object related to and how do they build on each other
( dependencies between the development objects)
which application programming intefaces (apis) are available to help implemtn the typical requirements and functionalities of an application?
- there are two types of APIs : which APIs are made available to the application for direct calls in order to implement specific function? - called as library based APIS ( they are provided via libraries) / which APIs are implemented by the application so that they are called at defined processing times from the outside - called as framework-based interface.
the RAP programming model is based on a stateless web server as part of the abap platform that provides rest based api.
RAP takes into account various technical aspect that are typical of enterprise applications. - the implementation of standard operations such as the creation, reading, update, or deletion of business objects within a logical transaction and the persistence of transactional data. numbering persistence, locking behavior, draft handling of the installation of authorization checks are supported by the programming model.
RAP is ready made implementations.
- Defined program flow for processing business operations
Runtime Environment : RAP 프레임워크가 앱을 실행하면서 동작을 처리하는 전체 흐름과 컨트롤 구조
Defined Program flow : 앱이 처리되는 표준적인 절차 ( 예: validate -> check -> save)
표준적인 절차가 정해져 있고 개발자가 configure하는 영역은 미리 정해진 흐름에 맞춰 필요한 지점에 로직 삽입(hook)
-> RAP의 런타임 환경은 비즈니스 작업이 실행될 때의 표준적인 처리 흐름을 미리 정의하고, 개발자는 그 흐름 안에서 필요한 로직만 추가함 ( Hooking)
-Declarative, model-based approach ( 선언적 모델 접근,무엇을 할지 선언적으로 정의하고, 그 정의에 기반해서 프레임워크가 어떻게 할지는 자동으로 처리, 개발자에게 더 구체적이고 제한된 방향 제시)
RAP follows a model-based approach. this means that the programming model provides specific languages tailored to an applicaion purpose(domain- specific languaged)
-> rap가 구조와 데이터 흐름을 정해 놓았고 그래서 정해놓은 구조와 흐름을 설계자와 개발자는 따르면 됨 (DSL : Domain Specific Languages)
Properties of the programming model
=예시
RAP - DSL
CDS VIEW : 데이터 모델 정의
Behavior Definition : 행위 정의 (트랜잭션 처리를 선언적으로 정의)
Service Definition / Binding : 어떤 엔티티를 Odata로 노출할지는 정의
( 어떻게 구현할지를 고민하기 보다는 무엇을 구현해야하는 지에 집중하면 되기 때문에 개발자의 부담이 줄고 아키텍처도 자동으로 표준화됨)
contains a list of all the DSLs that relevant to RAP model.
CDS provides data definition languages
: CDS provides a data definition language that you can use to define the semantic data models of an application.
-> 이때 semantic data model의 의미는 데이터가 어떤 비즈니스 의미를 가지는 지 까지 표현 ( 단순히 테이블의 구조만 표현할 뿐만 아니라, 이 데이터가 어떤 역할을 하는지, 무엇을 의미하는지 다른 엔티티와 어떻게 연결되는 지 까지 정의하는 것이 semantic model임)
-Support of SAP Product Feartures ( support existing SAP tech and product features)
SAP Fiori user experience
develop application with an OData-based interface that seamlessly integrates with an sap fiori ui.
such interfaces can be implemented with SAP fiori elements.
SAP HANA database capabilities
RAP uses CDS as the base tech for the data model of a business application.
computation can be performed directly on the SAP HANA database layer.-> CDS 뷰가 HANA DB에서 직접 실행(필터링 등 포함)
Cloud Readiness
RAP의 의미는 stateless APIs.
서버 사이드의 앱 상태는 정비 안함
(남아 있는 가용량은 rap가 클라우드 환경에서 사용될 수 있도록 함)
클라우드 환경 하의 모델은
-> RAP로 개발된 APP은 restful한 구조이고
RAP에서 CDS + Behavior + Service Definition으로 자동으로 Odata API를 만들기 때문에-> stateless API를 제공 ( 예측 가능하고 확장 가능한 일관되고 표준화된 방식의 api 제공)
-> 클라이언트의 각 요청이 서버 입장에서는 매번 처음보는 요청처럼 독립적으로 처리됨 -> 서버는 상태 저장 부담 없이 가볍고 확장 가능하게 운영됨
상황 | stateful | stateless |
로그인 후 페이지 이동 | 서버가 로그인 상태를 기억함 | 매 요청 마다 토큰을 보내서 인증 |
장바구니 유지 | 서버가 장바구니 정보를 세션에 저장 | 클라이언트가 장바구니 정보를 보내거나 별도 저장소 사용 |
확장성 | 서버가 사용자 상태를 기억하므로 확장 어려움 |
사용자 인증 정보 저장 하지 않고 토큰을 통해 정보를 주고 받음
(사용자 특정이 아니라 주문서만 주면 주문서에 따라 음식을 주는 거고 해당 주문서를 토큰으로 보면 됨)
1.1.2 the REST Architectural Style
the architectural style is independent of the implementation by concrete tech.
we'll immediately place the basic REST principles and architecture elements in the context of the software building blocks and standards underlying the www.
-> "REST라는 아키텍처 스타일은 특정 기술에 묶이지 않고, 다양한 환경에서 적용될 수 있다. 우리는 이런 REST의 기본 원칙과 구성 요소들이 어떻게 웹의 표준과 구조 안에서 사용되는지 바로 설명할 것이다."
1.1.3 Odata
odata protocol defines the communication between the consumer and the odata service.
odata - data model ( how that model is constructed)
metadata of a OData service : data model, how that model is constructed.
entities are described with their attributes(property) and associations ( association, navigation property)
the data model of an OData service is provided via the service metadata documnet.
open data protocol is a specification of RAP.
Odata protocol defines the communication between the consumer and the odata service.
OData
1. data model
2. how data model is constructed
entities ( entity type)
property ( the entities are described with their attributes)
associations ( association, navigation property)
-> OData 서비스는 데이터 모델을 기반으로 하며,
이 데이터 모델은
엔티티(엔티티 타입) : 하나의 데이터 객체 유형 ( 예) product, sales order 등)
해당 엔티티의 속성(프로퍼티) : 해당 엔티티가 갖는 속성 ( 예) productID, name, price 등)
association : 두 엔티티간의 관계 정의
navigation property : association을 통해 다른 엔티티로 이동할 수 있게 해주는 연결 경호
그리고 엔티티 간 관계를 나타내는 어소시에이션(두 엔티티 간의 관계 정의) 및 내비게이션 프로퍼티(어소시에이션을 통해 다른 로 구성
Technical Software Layers for S4HANA
SAP HANA Database : in-memory database tech ( to increase the access speed of read accesses and reduce the memory requirements in the main memory of the database server, data sets are stored in a column-oriented manner in the column store and automatically indexed.)
in memory : 데이터를 디스크가 아닌 메모리에 저장 -> 빠름
column-oriented : 열단위로 저장 -> 피요한 열만 읽음 -> 메모리 효율 + 속도 향상
automatically indexed : 인덱스를 자동으로 만들어서 쿼리 성능 개선
CDS and virtual data model :
you have the option of a code pushdown into the sap hana database.(Code pushdown)
code pull- up -> code push down
select * from orders where -> CDS View에서 조건, 조인, 집계 등을 미리 정의함 ( HANA DB가 이 모든 처리를 자체적으로 하고 결과만 전달)
DB에서 데이터를 다 끌고 온 다음에 조건, 조인, 집계 들을 했다면
데이터를 다 끌고와서 하는 게 아니고 DB에서 이미 정제해서 가져오는 것
(데이터 처리 작업을 ABAP이 아니라 HANA DB가 직접수행하도록 할 수 있어서 성능이 뛰어나고 대용량 데이터 처리에 유리함)
CDS also allows you to define a semantic data model of your application based on database tables. you can integrate the CDS entities at various points in the application.
-> data의 구조적 정의 ( 엔티티, 프로퍼티, 어소시에이션과 같은 데이터 구조 + 주석(비즈니스 로직)
SAP Gateway and OData
during development you can implement read or write access to application data using the functions of SAP Gateway without having to know the details of the OData protocol. SAP gateway also provides features to integrate CDS funcionalities and expose OData services on this basis.
SAP Gateway = SAP 시스템에서 외부와의 통신을 위한 Odata api를 생성, 관리하는 프레임 워크 (sap의 odata 서비스 엔진으로 odata의 복잡한 기술을 몰라도 gateway 기능으로 cds -> odata -> 외부 노출 까지 쉽게 구현 가능)
(내부 데이터/ 기능을 외부에 노출할 수 있게 해주는 odata 서비스 게이트 웨이임)
1) OData 서비스 생성 : CDS View 기반으로 OData 서비스 자동 생성 가능
2) OData 요청 처리 : 외부 앱이 get, post, patch 등으로 요청 보내면 sap 시스템과 연결
3) 보안, 버전 관리 : 인증, 권한 체크, 버전 구분 같은 api 관리 기능도 지원
4) RAP 연계 : rap 기반 app에서는 cds + behavior definition등을 통해 sap gateway에서 자동 odata 서비스 생성 가능
SAP Fiori user experience with the SAP Fiori launchpad and the SAP UI5 framework
role based application -> transaction based application
fiori app and ui5 app 을 odata 기반
프론트 엔드 : sap ui5
백엔드 : cds view, abap class 등에서 데이터 제공
통신방식 : 전부 odata protocol 사용
OData 통신은 sap gateway가 처리
odata 프로토콜을 통해 sap 백엔드와 주고받을 떄는 반드시 sap gateway를 거침
sap gateway가 odata 요청을 해석하고
해당 요청은 abap/db 계층까지 전달
결과를 다시 odata로 포맷팅 해서 ui로 전달
▶ SAP Fiori는 트랜잭션 중심에서 역함 중심 UX로 전환됐고
▶ 사용자 과업(task)에 집중할 수 있도록 화면과 흐름을 단순화 했으며
▶ 모든 fiori 앱은 launchpad에 타일로 제공되고
▶ SAP UI5/Fiori 앱은 Odata를 통해 데이터를 주고받으며
▶ 그 OData 통신은 SAP Gateway가 담당함
they focus on the user's particular task by tailoring the selection of visible fields and dialogue steps to that task.
all sap fiori apps available to a user are displayed as tiles in the sap fiori launchpad.
sap fiori apps or sap ui5 apps are designed to read data from the backend via the odata protocol and to write data back to the backed via this protocol. for this reason, they usually communicate with sap gateway to access application functionality.
BOPF(Business Object Processing Framework)
BOPF was the first framework to support the direct implementation of the business core of an application.
BOPF is based on ABAP Objects
in its capacity as a framework, it defines the control flow of business logic processing.
an ABAP application implemnts certain BOPF interfaces and thus hooks into this controal flow.
business objects
business logic
business object API
consumer API.
▶ BOPF는 RAP의 전신이자 핵심 컴포넌트 중 하나로
sap app에서 비즈니스 로직을 구조적으로 재사용 가능하게 일관되게 구현하고 실행하게 해주는
중후 역할을 맡은 프레임 워크임
▶ 비즈니스 오브젝트 단위로 로직 흐름을 제어하는 프레임 워크
▶ 개발자는 BOPF가 제공하는 인터페이스를 구현함으로써
▶ 미리 정의된 컨트롤 플로우에 후킹해서 자신의 로직 삽입 가능
abap programming model for sap fiori
data modeling with CDS : cds entities can then be exposed as odata services to provide read access to the respective application data.
transactional behavior with BOPF : using a lightwight CDS based variants of BOPF, you can add transactional behavior to CDS entities.
-> BOPF의 경량화된 CDS 기반 버전을 사용하면
-> CDS 엔티티에 트랜잭션성(Create/Update/Delete 같은 행동)을 추가할 수 있음
RAP의 CDS 기반 BOPF의 경량 버전
모델 정의 : CDS Entity + Behavior Definition
로직 삽입 : Behavior Implementation 클래스 작성
메타 데이터 노출 : cds + annotation으로 자동 노출
트랜잭션 처리 : RAP Framework가 처리 ( 내부적으로 BOPF 구조 기반)
결론적으로 RAP에서는 개발자가 BOPF를 직접적으로 쓰진 않지만,
그 구조적 원리 ( Business Object, action, determination, validation 등) 는 그대로 살아 있고
이걸 CDS + Behavior 로 '경량화된 방식'으로 구현 가능
CDS-based lightweight variant of BOPF
= RAP의 Behavior Definition 기반 트랜잭션 모델링 구조를 말하는 것이고
= 전통적인 BOPF보다 훨씬 단순하고 CDS중심으로 구성된 경량 프레임 워크
SAP Gateway
SAP UI5 and SAP Fiori
1.2 Architecture and Concepts -> 여기서 부터 다시
basic architectural concepts of the programming model
take a first look at the development environment you'll be using to develop application with the RAP.
more datail about the main architecture-relevant concepts of the RAP.
this includes the technical components in which a RAP application is embedded at runtime.( RAP 앱이 실행될 때, 이 모든 구성요소들이 연결되고 함께 작동하여 하나의 일관된 시스템 처럼 동작함)
-> 예를 들어 fiori 앱에서 어떤 데이터를 수정하면, OData > Gateway > service binding > RAP runtime > Behavior -> CDS view > DB 이런식으로 전 구성요소가 런타임에 함께 연결 되어 작동!
-> RAP앱이 임베디드되는 기술 컴포넌트 (런타임 기준)
-> 앱을 만들기 전에 이미 존재하는 기술 스택위에 구축 되는 구조로 -> ui에 어떤 데이터를 저장하면 fiori, odata call, gateway, cds view 등의 컨포넌트들이 runtime에 순서대로 작동
-> 1) RAP Runtime 2) SAP Gateway/Odata Runtime 3) CDS기반 Data Model 4) Behavior Pool (ABAP Class) 5)Service Definition / Service Binding 등이 포함된 런타임 기반 구조
-> 하나의 트랜잭션이 발생하면, 구성하는 모든 컴포넌트가 순차적으로 작동하면 서로 연계됨
Transaction Model : 비즈니스 트랜잭션이 rap에서 어떻게 관리되는 지
데이터의 처리 단위와 일관성 관리구조를 어떻게 설계하는가를 설명(unit of work)
between two phases in the processing of operations on business objects.
1) during the interaction phase
operations are performed on a business object instance.
as a result of these operations, instances of the respective CDS entities are stored in the transaction buffer.
bo 인스턴스 내에서 operation이 일어나고
이 operation의 결과로 각 cds entities들의 인스턴스가 transaction buffer에 저장됨
2) save
commit에 의해서 save
transaction buffer의 상태는 데이터베이스에 영구적으로 기록
the state of the transaction buffer isn't kept across multiple requests , as this would violate a key REST principle.
-> 여러 요청에 걸쳐 유지되지 않는다.
->이는 핵심 REST 원칙인 stateless 해야한다는 중요한 원칙을 위배하기 때문
(즉, 서버는 각 요청을 독립적으로 처리해야하며, 서버 쪽에서 클라이언트의 상태를 기억하고 있으면 안됨)
the CDS entity instances that are stored in the transaction buffer, which have been created, modified, or deleted, can be considered a logical unit of work within the SAP system.
as part of the save sequence, the LUW is persistently written to the database within a database LUW.
** transaction buffer란?
사용자가 화면에서 여러 변경 작업을 하고
마지막에 저장 버튼을 누를 때
그 변경사항들을 임시로 버퍼에 쌓아두었다가
한번에 커밋하는 구조
다만, 클라이언트 내 혹은 하나의 http 요청 내에서만 유효하면 다른 요청으로 넘어가면 그 버퍼는 유지되짖 않음
3) Draft handling
temporarily store the state of the transaction buffer with inconsistent application data persistently on the database.
this enables you to distribute the interaction phase across multiple standalone request or user sesstions without violating RAP.
트랜잭션 중간상태(예: 사용자가 작성하다 만 견적서 같은 것)를
DB에 임시로 저장함으로써
하나의 요청나 세션에 국한되지 않고
여러 요청/세션에 걸쳐 상호작용을 분산할 수 있게 해준다
-> 그런데도 RAP의 Stateless 원칙은 위배하지 않는다
왜?? 서버 세션/메모리에 저장하지 않고 db(임시 저장소)에 저장 하여 클라이언트가 상태를 db에서 읽고 다시 넘김
"클라이언트가 상태를 관리" 하는 구조로 본다
-사용자가 작업중간에 저장한 임시 데이터는 db에 남아 있고
-다음 요청에서 그 데이터를 클라이언트가 다시 로딩해서 이어서 작업함
-서버는 상태를 기억하지 않은 -> 그냥 db에 있는 걸 조회할뿐
state is stored on the client or in a resource never in the server session
Implementation Types : managed와 unmanaged 타입 두가지 구현 방식 제공/ 기능 구현을 어떤 컴포넌트가 맡을 것인가를 결정
managed : sap가 대부분 처리하고 개발자는 BDEF 등만 작성
unmanaged : CRUD 로직 등을 전부 개발자가 구현
아키텍처 관점에서는 기능구현을 어디서 어떤 컴포넌트가 맡을 것인가를 결정
Entity Manipulation Language
rap에서 abap코드로 엔티티를 다룰 때 사용하는 언어
서비스 계층과 데이터 계층 사이의 인터페이스 역할을 함
CDS + Behavior + DB 사이의 연결고리이자 데이터 흐룸제어의 일부임
Technical Context of Applications and Runtime Environment
::RAP가 실행되는 전체 환경을 설명하는 항목
_RAP APP이 동작할 수 있는 플랫폼적/기술적 조건을 말하며, 아키텍처의 운영환경과 배치구조와 밀접한 관련이 있음
1.2.1 Transaction Model
between two phases in the processing of operations on business objects.
Processing phases :
the RAP transaction model distinguishes between two phases in the processing of opertions on business objects:
during the interaction phase, operations are performed on a business object instance.
as a result of these operations, instances of the respective CDS entities are stored in the transaction buffer.
-> 연계 단계 동안, 오퍼레이션은 비즈니스 오브젝트 인스턴스 단위에서 실행됨
이 오퍼레이션의 결과, 각각의 CDS 엔티티들의 인스턴스는 트랜잭션 버퍼에 저장됨
the subsequent save sequence is triggered by a commit.
다음의 저장 시퀸스는 커밑에 의하여 트리거 됨
the state of the transaction buffer is persistently written to the database.
트랜잭션 버퍼상 상태는 데이터 베이스에 영구적으로 기록됨
the state of the transaction buffer isn't kept across multiple requests, as this would violate a key REST principle.
트랜잭션 버퍼의 상태는 여러 요청에 의해 유지되지 않으며 이거 RAP 원칙에 위배됨
the CDS entity instances that are stored in the transaction buffer, which have been created, modified, or deleted, can be considered a logical unit of work within the SAP system.
생성, 수정, 삭제를 포함한 트랜잭션 버퍼에 저장되는 CDS 엔티티 인스턴스는 SAP 시스템 내에서 작업의 논리적 구성으로 여겨짐
as part of the save sequence, the LUW is persistently written to the database within a database LUW.
저장 시퀸스의 한 부분으로서 luw는 영구적으로 데이터베이스에 기록됨
the draft handling in the RAP allows to temporarily store the state of the transaction buffer with incon-sistent application data persistently on the database.
rap의 드라프트 핸들링은 트랜잭션 버퍼의 상태는 임시적으로 저장함
this enables you to distribute the interaction phase across multiple standalone requests or user sessions without violating the RAP of stateless communication.
이것은 너가 다수의 스탠드얼론 요청이나 유저 세선을 통해 인터랙션을 구별하도록 하되 rap의 커뮤니케이션을 거스름
user can continue their work at a later point in tiem, regardless of the terminal device.
사용자는 터미널 디바이스에도 불구하고 그들의 작업을 지속함
the draft handling functionality is fully implmented by the RAP runtime
드라프트 핸들링 기능은 rap 런타임에 의해 완벽히 실행됨
draft handling
state is stored on the client of in a resource, never in the server session.
(사용자가 작업중간에 저장한 임시 데이터는 db에 남아 있고..
다음 요청에서 그 데이터를 클라이언트가 다시 로딩해서 이어서 작업
서버는 상태를 기억하지 않고 그냥 db에 있는 걸 조회)
이걸 rap에서는 drafe 처리 라고 하는데
서버는 작업중인 상태를 저장하지 않고
DB 리소스로 상태를 유지함
예를 들어 fiori 앱에서 사용자가 견적서를 작성하다 중간에 나가면
그 데이터는 draft 상태로 db에 저장됨
다시 접속하면 사용자 세션과 무관하게 이어서 작성 가능
이건 서버가 상태를 기억하는게 아니라 db 리소스로 상태를 유지하는 것
결론
1) db에 트랜잭션 버퍼 상태를 임시로 저장하는 것은 rest 원칙을 위배하지 않는다.
왜냐하면 서버가 상태를 기억하지 않고, 상태는 클라이언트가 참조 가능한 리소스로 존재하기 때문이다
2) 서버 세션이 아닌 db 리소스에 저장하고, 클라이언트가 상태를 다시 넘겨주기 떄문에 rest 원칙을 위배하지 않는다
1.2.2 Implementation Types
RAP는 누가 query와 behavior ( transactional or writing functionality)를 제공하는 지를 특정하기 위해서 사용할 수 있는
implementation type의 컨셉을 포함하고 있음
implementation type을 관리하는 거는 business object provider
[implementing custom busienss logic]
managed(ready-made implementation of the business object) and unmanaged()
-> 이미 주어진 business object를 사용하는 지 아니면 직접 만드는 지에 따라 다름
there are always very specific business requirements, in these cases, the business object provider can't provide an implementation.
in both the managed and unmanaged senarios, you can implement the respective business logic yourself.
implementation of a business object
:
implementing custom business logic
queries
rap
1) 읽기 중심(조회) -queries
2) 쓰기 중심(CRUD) - behavior(managed/unmanaged)
rap의 query 구조 = CDS + Projection +Service Definition
(DB Table -> CDS View/ data model -> projection view -> service definition/binding)
cds view = data model
projection view = 서비스 노출 모델
service definition/binding = odata 서비스화
=> 결론
RAP에서는 조회(Query)는 behavior 없이 cds view만으로도 가능하기 떄문에, 구조상 독립적으로 설명됨.
반면, 쓰기(crete/update/delete)는 반드시 behavior 로직이 필요해서 managed/unmanaged 구분과 함께 설명됨
1.2.3 Entity Manipulation Language
is a standardized, type-safe API used to access the data and functionality of a business object.
it's an integral part of the abap scope.
표준화 되고 타입 세이프한 API로 비즈니스 오브젝트의 데이터와 기능(예:Behavior)를 접근할 수 있게 함
-> SQL 처럼 직접 테이블을 다루는 것이 아니라, BO의 추상화된 인터페이스를 통해 작업
using EML, you can access instances of a business object in write mode.
-> EML을 사용하면, BO의 인스턴스를 쓰기 버전으로도 접근할 수 있음 (BO의 인스턴스를 쓸 수도 있음)
but you can also read individual instances from the transaction buffer.
eml은 단순히 쓰기 뿐 아니라 transaction buffer에 있는 bo의 단일 인스턴스를 읽는 용도로 사용됨
-> 이건 db에서 직접 읽는 게 아니라, 현재 트랜잭션 중에 생성되었거나 변경된 데이터를 포함해서 조회가능
EML = RAP에서 BO 조작을 위한 표준 api
타입 안전하면서 abap 문법의 일부
쓰기(CUD) 뿐만 아니라 읽기(trasactional buffer 포함)도 가능
테이블이 아니라 bo 중심으로 조작
EML playes a major role within the RAP in the following use cases;
Implementing the behavior of a business object
your application assumes the role of a business object provider.
Performing operations on a business object
you need EML statement if you program an abap application that accesses the funtionality of a business object as a consumer.
it's also possible to use EML in the context of unit tests to check the functionality of a bo in your application.
consuming a custom business object
you also use the EML in the business object consumer role.
you use it to read data about the business object from the transaction buffer to validate it, bypassing authorication checks,
1.2.4 Technical Context of application and runtime environment -> 요기부터
1.3 Development Objects
1.4 ABAP Development Tools
1.5 Quality Attributes of the ABAP RESTful Application
1.6 Availability of the ABAP RESTfull Application Programming
2. Core Data Services : Data Modeling
2.1 what are Core Data Services?
2.2. Structure and Syntax of Core Data Services
2.3 Association
2.4 Annotations
2.5 Access Controls
2.6 Extensibility of CDS Entities
2.7 Additional CDS Functionality
2.8 Virtual Data Model
2.9 CDS Lanauage Elements for Modeling Business Objects
2.6 Extensibility of CDS Entities
3. Behavior Definition
4. Entity Manupulation Language : Accesing Business Logic
5. Behavior Implementation
6. Business Services
7. User Interfaces and SAP Fiori Elements
RAP 개발 흐름
1. ABAP Dictionary (DDIC) : 기본적인 데이터 타입, 구조, 테이블 정의
2. Core Data Services : ABAP Dictionary 기반으로 데이터 모델(view entity) 정의
3. Behavior Definition : CDS View Entity 에 트랜잭션 성격과 동작방식 정의 ( create, update 등)
4. Behavior Implementation : 위에 정의한 동작을 abap 코드에 구현 ( 예, save 시 처리 로직 , 사용자 검증 등)
5. Service Definition/ Service Binding : rap 애플리케이션을 외부에 odata api로 노출하기 위한 설정 (ui 또는 외부 시스템 연계)
ABAP Dictionary -> CDS View Entity (데이터 모델 정의) -> Behavior Definition (행위/ 트랜잭션 정의 ) -> Behavior Implementation ( ABAP 코드 구현) -> Service Definition & Bindings (외부 노출/ odata)
abap dictionary 기반의 cds view entity 정의 -> 해당 entity에 behavior definition 부여 -> behavior implementation 작성 -> 서비스로 노
rap의 핵심은
CDS
경량화된 BOPF(Business Object Processing Framework) - Business Object
CDS-based lightweight variant of BOPF
OData
runtime
'NEW_SAP > RAP' 카테고리의 다른 글
[WIP]Data Definition (0) | 2025.03.18 |
---|---|
RAP란? (0) | 2025.03.17 |
BTP Cockpit - Destination (0) | 2025.03.17 |
[WIP]What is the ABAP RESTful Application Programming Model? (1) | 2024.11.12 |
[WIP]Chapter 1 Modeling Your First CDS View (0) | 2024.11.12 |