목차
이번시간에는 Booking 정보를 생성할때 Booking Number 도 자동으로 채번해 보겠습니다. Booking Number 는 번호범위 오브젝트를 사용하지 않고 현재 Booking Number의 Max값을 찾아서 Max + 10으로 생성하겠습니다.
그전에 현재 App은 Value Help기능도 없고 List에 Code만 있고 Description정보가 없어 보기가 불편합니다. 이전 Simple Report에서 했던것처럼 복습한다 생각하시고 App의 완성도를 올리고 시작해 보겠습니다.
Value Help
Agency ID, Customer ID, Travel Status 필드에 Value Help 기능을 추가해 보겠습니다. 지난 시간에 했던게 기억이 나시는 분들은 블로그를 보지 않고 직접 해보셔도 됩니다.

아래와 같이 추가해 줍니다. Value Help용 CDS View는 이미 만들어져 있는 View를 사용했습니다. 필요에 따라서는 직접 만들어서 사용해도 됩니다. 그 다음으로는 Code옆에 Description을 함께 보여주겠습니다.

Travel의 Interface View인 ZEVER_M_TRAVEL_I에 Description 관련 View를 Association으로 연결해 줍니다.

Projection View 에 AgencyID, CustomerID, Status 필드에 대한 Description 필드를 추가해 줍니다. 그리고 @ObjectModel.text.element 어노테이션을 사용하여 코드와 Description 을 한필드에 동시에 보여주도록 합니다. @ObjectModel.text.element 어노테이션을 Metadata Extension에 추가하지 않고 Projection View에 추가해 주는 이유는Metadata Extention 에서는 UI관련 어노테이션만 사용할 수 있기 때문입니다.

이번에는 Travel에 대한 해더정보를 추가해 주고 Search Field 도 추가해 주겠습니다. 하나씩 차근차근 추가해 줍니다.

날짜 필드에도 Value Help 기능을 활성화 해줍니다. 여기까지 하고 App을 실행해 보겠습니다.

잘 반영된것 같습니다. Create 버튼을 눌러보겠습니다.

아래와 같이 Object Page로 이동합니다. 여기에서 Booking 정보를 생성하기 위해 Create 버튼을 눌러보겠습니다.

Booking에 대한 Object Page 어노테이션을 적용 안했기 때문에 아래처럼 빈 화면만 보입니다. Booking정보에 대한 Object Page관련 어노테이션을 추가해 보겠습니다.

Booking Metadata Extension에 아래와 같이 headerInfo, facet, Search 관련 어노테이션을 추가해 줍니다. 그리고 App을 다시 실행해 보겠습니다. 아.. 그전에 Booking에도 Value Help와 Description 필드를 추가해 보겠습니다.

Booking Interface View에 association을 추가해 줍니다.

Booking Projection View에도 어노테이션을 추가해 줍니다.

마지막으로 Booking Metadata Extension에 Value Help 관련 어노테이션을 추가해 줍니다. 이제 다시 App을 실행해서 Booking Create 를 클릭해 봅니다.

이제 값을 입력할 수 있는 필드가 보입니다. 고생하셨습니다. 드디어 이번 강의에서 하려고 하는 부분까지 왔습니다. 아래 Booking Number를 보면 값이 비어있습니다. Booking 테이블의 Key 필드이기 때문에 비활성화 되어있고 내부적으로 채번을 해줘야 합니다. Booking Number는 번호범위 오브젝트를 사용하지 않고 10번, 20번... 이런식으로 채번하겠습니다. Travel ID때와 마찬가지로 Early Numbering 에 로직을 구현하겠습니다.

Early Numbering
Interface Behavior Definition 으로 가보겠습니다. Booking 정보 생성시 Booking Number를 채번해야 하기때문에 Booking Entity 쪽에 Early Numbering 을 추가해 줍니다. 그리고 Travel때와 마찬가지로 Booking쪽 create 부분에서 Quick Assist 기능으로 Method를 생성해야 하는데 Booking 쪽에는 이상하게 update와 delete만 있고 create는 없습니다. 이유는 이렇습니다. Travel과 Booking 부모, 자식관계로 연결해 놓았습니다. 이렇게 연결해 놓으면 부모 없는 자식은 존재할 수 없기 때문에 Booking의 create 기능이 부모쪽에 생기게 됩니다. 단, association이라는 옵션이 붙습니다. Behavior Definition의 Travel Entity쪽으로 올라가 보겠습니다.

아래와 같이 Booking에 대한 create 기능이 보이고 노란줄이 생긴걸 볼수 있습니다. 마우스를 올려놓고 Quick Assist 로 Method를 생성해 보겠습니다. 그전에 create; 뒷쪽에 with draft; 를 추가합니다.

생성하게 되면 아래와 같이 earlynumbering_cba_Booking 이라는 Method가 생성이 됩니다. cba는 create by association의 약자입니다. 이제 해당 Method에 로직을 추가해 보겠습니다.

Method에 마우스를 올려놓고 파라미터를 확인해 보겠습니다. Travel 때와 파라미터는 동일합니다.

아래와 같이 입력받은 entities 로 LOOP 을 도는 로직만 추가해 좋고 디버깅을 걸어 데이터가 어떻게 들어오는지 확인해 보겠습니다. App을 다시 실행시켜 Booking 정보를 Create 해보겠습니다. 디버깅이 걸리면 entities를 더블클릭해서 내용을 살펴보면 일단은 Travel 정보에 대한 Booking정보 생성이기 때문에 Travel 에 대한 정보가 존재합니다. 그리고 %TARGET 이라는 변수 하위에 현재의 Booking정보가 한줄 추가되어 있는걸 볼수 있습니다. 아직 저장전이기 때문에 임시 Key값이 보이고 드래프트 상태이기 때문에 %IS_DRAFT는 01 입니다. Travel ID는 Travel쪽 early numbering에서 채번된 번호가 넘어오고 BOOKINGID 가 0000입니다.
%CONTROL 변수의 값을 보면 필드는 Booking의 필드인데 값이 01 또는 00 입니다. %CONTROL 의 값이 01이면 해당 필드가 새로 입력되었거나 수정되었으니 DB에 반영하라는 의미입니다.
자 그럼 입력받은 Travel ID로 Booking 정보를 읽어 Booking ID Max + 10으로 Booking ID를 채번해 보겠습니다.

Booking ID를 채번하기 위해서는 Booking정보를 읽어와야 합니다. 여기에서 이제부터 우리가 알아야할 EML 문이 나옵니다. EML에 대한 보다 자세한 사항은 다음장에서 설명드리겠습니다. 여기에서는 Business Object로 구현되어 있는 Entity는 Select 문으로 읽으면 안되고 아래처럼 READ EML 구문으로 읽어야 한다는것만 기억하면 됩니다. 그 이유는 아래에서 설명드리겠습니다. 일단은 READ EML 구문을 하나씩 살펴보겠습니다. 첫번째 READ ENTITIES OF 다음에는 현재 Business Object 의 Root Entity를 입력합니다. 그 다음줄 ENTITY에는 실제 데이터를 가져올 View Entity를 입력해 주면 됩니다. 여기에서는 Booking 정보를 가지고 있는 Entity를 읽어야 하는데 zever_m_booking_i 를 사용하지 않고 zever_m_travel_i BY \_booking 처럼 Travel View의 Association _BOOKING을 읽습니다. 그러면 선택한 Travel ID에 해당하는 Booking정보가 lt_booking 에 담기게 되고 Booking ID Max + 10 값을 다시 mapped 로 리턴해 아래처럼 로직을 추가하고 App을 다시 실행해 보겠습니다.

Booking Create 버튼을 클릭합니다.

최초 10번이 채번됩니다. Apply 버튼을 클릭합니다.

아래와 같이 Booking정보가 한줄 생겼습니다. 여기에서 다시 Create 버튼을 눌러 보겠습니다.

Booking Number 20번이 채번되었습니다. 우리가 의도한대로 정상적으로 채번이 됩니다. 그럼 다시 Method로 돌아가서 데이터를 확인하면서 설명드리겠습니다.

테스트를 위해 아래와 같이 2번과 3번을 임시로 추가해 봤습니다. 2번은 Booking Entity를 직접 읽는 EML 구문이고 3번은 Booking Entity를 쿼리로 Select 하는 구문입니다. Loop 시작부분에 디버깅을 걸로 다시 Booking Create 버튼을 클릭해 보겠습니다. 그리고 lt_booking, lt_booking2, lt_booking3 에 데이터가 어떻게 들어가는지 확인해 보겠습니다.

lt_booking에만 데이터가 들어왔습니다. 앞에서 20번까지 채번한 정보가 담기게 되고 Loop 이후의 로직에 의해서 Max값 20 + 10 에 의해서 30번이 채번되게 될겁니다. earlynumbering_cba_Booking Method가 Travel Entity에서 Booking정보를 association 해서 생성된 Method이기 때문에 EML 구문도 1번처럼 사용해야 합니다. 3번 구문은 현재시점이 아직 저장하기 전이기 때문에 당연히 Select가 안됩니다. 왜 Business Object 에서는 테이블이나 View를 직접 Select 하면 안되는지 감이 오시나요? Business Object에서는 항상 이런 부분을 신경쓰면서 로직을 구현해야 합니다. 중요한 부분입니다.

자 그럼 Method에 임시로 추가했던 2번, 3번 부분을 삭제하고 Travel 및 Booking정보를 생성해 보겠습니다. 아래와 같이 입력하고 Create 버튼을 클릭합니다.

오류가 발생합니다. 왜그럴까요? 네 Booking 쪽도 View Entity 필드와 DB 필드가 틀리기 때문에 Mapping을 해줘야 합니다. Interface Behavior Definition으로 이동합니다.

아래와 같이 Mapping을 추가하고 다시 저장을 해보겠습니다.

정상적으로 저장되었습니다.

다음시간에는 EML에 대해 자세하게 살펴보겠습니다.
'RAP' 카테고리의 다른 글
| RAP 10 - MANAGED REPORT : Early numbering(1) (0) | 2026.07.09 |
|---|---|
| RAP 09 - MANAGED REPORT : Behavior Implementation (1) | 2026.07.06 |
| RAP 08 - MANAGED REPORT : Behavior Definition (0) | 2026.07.05 |
| RAP 07 - MANAGED REPORT : Metadata Extensions (0) | 2026.07.04 |
| RAP 06 - MANAGED REPORT (0) | 2026.06.16 |