SAP RAP 아키텍처 전체 흐름
1. 데이터 모델
[ CDS View Entity ]
↓
[ Entity Relationship ]
↓
[ Composition / Association ]
실제 DB 테이블 기반으로 RAP 엔티티 구조를 만드는 단계이다.
그리고 비즈니스 오브젝트의 물리적 형태이다. 이때 비즈니스 오브젝트라는 것은 하나의 비즈니스 업무 단위를 구성하는 데이터 + 로직 전체를 묶어놓은 객체를 말한다.
예를들어 현실 세계의 업무 단위라고 하면 구매요청, 판매오더, 입고문서 등을말하고 SAP안에서 하나의 완전한 구조고 모델링 한 것이 바로 BO라고 한다.
비즈니스 오브젝트 예시 들기
-
현실세계 : 판매오더라는 업무가 있음.
-
SAP RAP : 판매오더 = 하나의 BO임.
그리고 BO 안에는 아래가 전부 포함된다. -
Header 데이터
-
Item 데이터
-
Header와 item의 관계
-
생성 / 삭제 / 수정/ 액션 로직
-
Validation/Determination 등 비즈니스 규칙 등.
구조가 아래와 같다고 해보자
SalesOrder (Root)
└── SalesOrderItem (Child)그러면 이 BO에는
- 판매오더 생성 로직
- 판매오더 아이템 자동 생성 로직
- 수정/삭제 규칙
- validation
- Determiniation
- 승인/취소 같은 action
이 존재하며 BO 하나가 모든 것을 가지고 있다.
BO를 구성하는 4가지 요소
1) Root Entity
BO의 최상위. 반드시 하나가 필요하다.
예시)
- 판매오더
- 구매오더
- 요청헤더
- 자재문서헤더 등등...
BO의 생명주기(생성/삭제)는 Root 기준으로 결정된다.
2) Composition Child
Root 아래에 속하는 자식들. (아이템)
부모 엔티티에 붙어서 함께 살아가는 필수 자식 엔티티이다. 부모가 생성되면 같이 생성되거나 따라붙는 구조이며 부모가 삭제되면 같이 삭제된다.
BO를 생성할때 이 데이터가 부모 없이 단독으로 존재할 수 있는지 없는지를 먼저 판단한 후 이 결합 구조를 사용하면 된다.
예시)
- 판매오더 아이템
- 구매오더 아이템
- Attachment
- Comment
특징은 부모가 삭제되면 -> 자식도 삭제된다.
왜? 부모와 자식으로 연결을 한 강한 생명주기 결합 관계이기 때문이다.
3) Association (약한관계)
BO의 일부가 아닌 단순 참조 관계를 볼때 사용한다.
Join 처럼 다은 엔티티를 연결해 참조한다는 점에서는 비슷하지만 Join은 아니다.
Join은 데이터를 즉시 병합하는 역할을 하고 이것은 연결만 해두고 필요할 때 탐색하는 참조 관계를 나타낸다.
즉, 이것은 데이터를 묶는 역할이 아니라 필요할때 찾아가는 링크 역할을 한다.
- 생명주기를 공유하지 않음.
- 부모-자식 구조가 아님
4. Behavior (동작)
BO가 어떻게 행동하는지 정의한다.
CDS는 데이터의 모양을 만들고 Behavior는 그 데이터가 실제 살아 움직이는 동작을 결정한다.
여기서 CDS라는 것은 Core Data Service라는 것이다. SAP의 데이터 모델링 언어이다. SAP 테이블을 기반으로 엔티티를 만드는 기술을 말한다.
S/4HANA 시대를 맞아 새로운 방식의 데이터 정의 방법을 뜻한다.
Behavior가 다루는 것들
| 종류 | 의미 |
|---|---|
| CRUD | 생성/수정/삭제 가능 여부 |
| Action | 승인·취소·전송 같은 동작 |
| Validation | 데이터 유효성 검사 |
| Determination | 자동 계산/자동 입력 |
| Authorization | 권한 제어 |
| Locking | 동시 수정 방지 |
| Draft Handling | 초안 기능 지원 |
왜 이것을 따로 들까?
CDS는 데이터 모양만 만들고 이것은 동작만 담당하도록 분리시키기 위해서 그렇다.
RAP의 핵심 원칙을 다시 봐보자.
데이터와 로직을 분리 시킨다.
그래서 아래와 같이 계층이 나뉜다.
- CDS : 데이터 구조
- Behavior : 행동 규칙
- Service : 외부 노출
- UI/Fiori : 소비
그리고 이것을 정의할때 사용하는 언어가 따로 있는데 그것이 BDL이라고 한다.
구조를 시각적으로 봐보면
┌────────────────────────┐
│ Behavior Definition │ ← BDL로 작성 (선언부)
│ (BDEF, behavior pool) │
└─────────▲──────────────┘
│ 연결됨
┌─────────┴──────────────┐
│ Behavior Implementation │ ← ABAP 클래스로 구현 (실행부)
│ (클래스 ZCL_…) │
└────────────────────────┘
RAP에서 모든 서비스는 BO 기반이다.
왜냐하면
1. Fiori에서 보여줄 화면
2. API로 만들 OData
3. CRUD 가능여부
4. 액션 기능
5. validation
6. 내부 로직
이 모든 것들의 최초 기준이 BO이기 때문이다.
2. Behavior Layer (BO logic)
[ Behavior Definition (BDEF) ]
↓
[ Behavior Implementation (ABAP Class) ]
- create, update, delete
- actions
- validations
- determinations
- 데이터가 어떻게 동작하는지 정의한다
- BO의 두뇌역할을 한다.
- CRUD와 액션을 여기서 선언하고 구현한다.
3. Business Service Layer
[ Service Definition ]
↓
[ Service Binding ]
↓
(OData V4 / OData V2 서비스 자동 생성)
- BO의 어느 부분을 API로 내보낼지 결정한다. Fiori, 외부 API와 연결되는 단계
4. Service consumption layer
[ Fiori Elements App ][ UI5 Custom App ]
[ 외부 시스템 API 호출 ][ Postman, React, Python 등 ]
- 이 단계에서는 OData 서비스가 실제 UI/Fiori에서 사용된다.
요약
┌──────────────────────────────┐
│ UI / 소비 계층
│ Fiori / UI5 / 외부 API
└───────────────▲──────────────┘
│ OData 호출
┌───────────────┴──────────────┐
│ Service Layer (노출 계층)
│ Service Definition / Binding
└───────────────▲──────────────┘
│ BO 기반 서비스 생성
┌───────────────┴──────────────┐
│ Behavior Layer (동작 정의)
│ BDEF / BIMP (CRUD/Action)
└───────────────▲──────────────┘
│ BO 생명주기 관리
┌───────────────┴──────────────┐
│ Data Model Layer (데이터 모델)
│ CDS View Entity / BO 구조
└───────────────┘