RAP 18 - MANAGED REPORT : CUSTOM ENTITY

 

 

 

목차

Custom Entity

Custom Entity는 데이터베이스 테이블을 직접 조인하여 데이터를 조회하는 일반 CDS View와 달리 개발자가 직접 작성한 ABAP Class를 통해 데이터를 동적으로 수집하고 처리하는 특수 CDS Entity 입니다.

 

설명만 들어선 감이 잘 안옵니다.

이번 실습에서는 메인 리스트에서 Travel ID를 선택하면 Object Page에 Booking Supplement 정보를 보여주려고 합니다. 하지만 Booking Supplement정보를 가져오려면 "/DMO/FLIGNT_TRAVEL_READ" 함수를 이용해야 한다고 가정을 해보겠습니다. 어떻게 해야 할까요? 일반 CDS View를 추가하는 방법으로는 안되고 함수를 호출해서 값을 가져오는 로직이 들어가야 합니다. 이럴때 Custom Entity를 사용하면 됩니다. 그럼 시작해 보겠습니다.

 

 

Data Definition 폴더에 마우스 우클릭 후 New Data Definition을 선택합니다.

 

 

Name과 Description을 입력하고 Next 버튼을 클릭합니다.

 

 

defintCustomEntityWithParameters를 선택하고 Finish 버튼을 클릭합니다.

 

 

Custom Entity는 CDS View의 빈 껍데기만 생성한다고 생각하면 됩니다. 특정 테이블이나 View를 Join해서 필드를 구성하는게 아니기 때문에 테이블을 만들때와 동일하게 필드를 정의하면 됩니다. 이번 실습에서는 "/DMO/FLIGNT_TRAVEL_READ" 함수의 Booking Supplement정보를 리턴받아 화면에 보여줄것이기 때문에 함수에서 리턴해주는 Booking Supplement의 필드구조와 동일하게 정의했습니다. 그리고 @ObjectModel.query.implementedBy 어노테이션을 추가해서 로직을 구현할 Class명을 입력해 줍니다. 아직 Class를 생성하기 전이라 오류가 발생합니다. Class를 생성해 보겠습니다.

 

 

어노테이션에 지정한 이름과 동일하게 클래스를 생성합니다. 선언부분에 if_rap_query_provider라는 Interface를 추가해주고 구현부분에 select 메소드를 추가해 줍니다. 추가한 Interface의 select 메소드에 로직을 구현해야 합니다. select 메소드에 마우스를 클릭하고 파라미터를 살펴보겠습니다.

 

 

io_request와 io_response가 있고 각각 또다른 Interface를 참조하고 있습니다. 각각의 Interface를 클릭하여 내용을 살펴보겠습니다.

 

 

먼저 io_request 파라미터의 참조 Interface를 살펴보겠습니다. get과 관련된 메소드들이 있는걸 보니 io_request를 이용하여 화면의 정보를 받을수 있는것 같습니다.

 

 

이번엔 io_response 파라미터의 참조 Interface를 살펴보겠습니다. set과 관련된 메소드들이 있습니다. 아마 결과값을 반환받는 메소드 들인것 같습니다.

 

 

이제 로직을 구현해 보겠습니다. 화면의 Filter정보와 Paging정보를 가져오는 로직과 결과값으로 빈값을 반환하도록 하는 로직입니다. 저 로직이 없으면 App 실행시 오류가 발생하기 때문에 가장 기본적인 로직만 추가해 놓고 화면 UI작업을 먼저 한 후에 나머지 로직을 구현하면서 설명드리겠습니다.

 

 

Travel Interface View에 위에서 생성한 Custom View를 Association으로 연결해 줍니다.

 

 

Travel Projection View에도 Booking Supplement에 대한 Association을 추가해 줍니다.

 

 

Travel Metadata Extension에 Booking Supplement를 보여주기 위한 facet을 등록해 줍니다.

 

 

이제 Custom View를 화면에 노출시킬 작업을 해야 합니다. Custom View 상단에 Metadata Extension을 만들기 위해서 어노테이션을 추가합니다.

 

 

Custom View를 참조하여 Metadata Extension을 아래와 같이 생성해 줍니다.

 

 

마지막으로 Service Definition에 Custom View를 추가하고 App을 다시 실행시켜 보겠습니다.

 

 

App을 실행시키고 Travel ID를 하나 선택해서 Object Page로 들어오면 아래와 같이 Booking Supplement 영역이 추가되었습니다. 이제 준비는 다됐습니다. Custom Entity Class에서 Booking Supplement 데이터만 반환해 주면 화면에 나타날것 같습니다. 

 

 

그럼 메소드에 디버깅을 걸고 데이터가 어떻게 들어오는지 확인해 보겠습니다. lt_filter 에는 NAME과 RANGE필드가 존재하고 메인 List에서 데이타를 선택하고 Object Page로 들어왔기 때문에 NAME에는 "TRAVELID" 가 들어옵니다. 그리고 RANGE에 실제 Value값이 Range 형태로 들어옵니다.

 

 

아랫쪽에 offset 및 size, sort 정보도 확인해 보겠습니다. offset은 OData 옵션중 $skip에 해당합니다. 클라이언트가 몇번째 레코드부터 원하는지를 나타냅니다. 0이기 때문에 첫번째 데이터부터 화면에 보여주게 됩니다. size는 OData 옵션중 $top에 해당합니다. 한번에 가져올 최대건수를 의미합니다. 10이기 때문에 한번에 10건씩 보여주게 됩니다. sort는 OData 옵션중 $orderby에 해당합니다. 우리 실습에서는 Booking Supplement정보를 컨트롤하는 기능이 없기 때문에 빈값으로 들어옵니다.

 

 

size 10에 대해 화면을 보면서 설명을 드리겠습니다. 현재 제 서버에서는 Travel ID "6"번에 대한 Booking정보가 10개가 넘어갑니다. 선택해서 Object Page로 들어가 보면 한 화면에 10건씩 보이는걸 확인할 수 있습니다. More를 누르면 나머지 2건의 정보가 추가로 보이게 됩니다.

 

 

이제 정말로 로직을 구현해 보겠습니다.

1. lt_filter로 입력받은 range조건으로 Travel 정보를 Select 합니다.

2. Select한 Travel정보로 "/DMO/FLIGHT_TRAVEL_READ" 함수를 호출하여 Booking Supplement 정보를 리턴받아

    lt_result 테이블에 값을 보관합니다.

3. Booking Supplement의 전체 건수를 반환합니다.

3. Booking Supplement의 정보를 반환합니다.

 

 

Custom Entity Class에 로직을 추가하고 다시 App을 실행해서 Main List의 Travel ID를 선택해 보겠습니다. 

 

 

Booking Supplement 정보가 잘 조회됩니다.

 

 

이번에는 아까 Booking정보가 좀 많았었던 Travel ID "6"번을 선택해 보겠습니다.

 

 

오류가 발생합니다. 디버깅을 한번 해보겠습니다.

 

 

LT_RESULT가 총 16건 입니다. size가 10 즉 한화면에 보여줄 정보가 10건인데 초과하여 데이터를 반환해서 그런것 같습니다. offset과 size의 정보를 적용하여 반환하도록 수정해 보겠습니다.

 

 

1. offset은 데이터를 건너뛸 건수를 의미 하기 때문에 offset에 값이 있는경우 1 ~ offset 까지 데이터를 삭제해 줘야 합니다. 

    만약 offset값이 lt_result의 총건수보다 크거나 같으면 전체 데이터를 삭제해 주면 됩니다.

2. 이번엔 size입니다. size는 한 화면에 보여줄 데이터 총 건수이기 때문에 1번에서 살아남은 lt_result에서 size 만큼만

    남기고 삭제해 주면 됩니다. 만약 살아남은 lt_result 총건수가 size보다 작거나 같으면 삭제할 필요없이 그냥 그대로 둡니다.

 

 

로직을 추가하고 App을 다시 실행시켜서 확인해 보겠습니다. 아래과 같이 오류없이 출력이 됩니다.

 

 

 

이번 시간에는 Custom Entity를 간단하게 활용해 보았습니다. 사실 복잡한 Custom Entity의 경우 Class에서 구현해줘야 할 일들이 더 많습니다. 그부분은 Unmanaged 실습을 할 때 좀더 알아보도록 하겠습니다.