목차
1.RAP Architecture Overview
첫시간에 봤던 RAP Architecture 를 다시한번 보겠습니다. 오랜지색 박스부분이 SIMPLE REPORT를 만들면서 실습했던 부분입니다. /DMO/FLIGHT 테이블과 /DMO/BOOKING 테이블을 참조하여 CDS View를 생성했습니다. 그리고 생성한 View에 대해서 SERVICE DEFINITION을 생성하고 UI용 SERVICE BINDING을 생성했습니다. 실제 APP은 아니지만 PREVIEW 기능으로 결과를 확인할 수 있었습니다. (이번 MANAGED 시나리오에서는 APP을 완성한 후에는 BAS를 연동하여 실제 Fiori APP을 생성해 볼 예정입니다.)
SIMPLE REPORT에서는 READ-ONLY APP을 개발했다면 이번시간부터는 DATA를 생성하고, 수정하고, 삭제할 수 있는 APP을 개발해 보겠습니다. CUD기능을 구현하기 위해서는 RAP의 BUSINESS OBJECT(BO)기능을 사용해야 합니다.
바로 RAP Architecture의 붉은색 박스부분입니다.
ALV로 CUD 프로그램을 개발하셨던 분들은 아시겠지만 손이 많이 갑니다. 사용자 편의성도 제공해야 하고 DATA 무결성을 위한 적절한 제어도 해줘야 합니다. 메세지 처리도 신경써서 해줘야 사용자의 혼란을 줄일수 있습니다. 이를 위한 ALV의 고유한 기능이 존재하듯이 RAP BO에도 많은 기능이 존재합니다. MANAGED 시나리오에서 그 기능들을 하나하나 실습해 보도록 하겠습니다.
2.INTERFACE VIEW, PROJECTION VIEW 정의
RAP에서는 목적에 맞게 두가지 유형의 VIEW를 사용합니다. 먼저 INTERFACE VIEW는 데이터베이스 테이블에서 데이터를 읽어 비즈니스 로직에 필요한 형태로 정의하는 뷰로 APP에 필요한 DATA 만들기 위한 복잡한 쿼리등을 포함하는 VIEW입니다.
PROJECTION VIEW는 INTERFACE VIEW에서 열심히 만든 데이터를 목적에 맞게 필터링 하거나 가공하여 사용자에게 노출시키는 VIEW입니다.
DB TABLE → INTERFACE VIEW → PROJECTION VIEW → OData SERVICE 의 순서로 흘러갑니다.
물론 SIMPLE REPORT에서처럼 INTERFACE VIEW만 사용해도 APP개발이 가능합니다. INTERFACE VIEW만 사용했을때와 PROJECTION VIEW를 사용했을때의 차이점을 알아보겠습니다.
INTERFACE VIEW 단독으로만 사용했을때...
예를들어 보겠습니다. 지난시간에 만들었던 FLIGHT정보를 Fiori UI용, 외부 API용, 모바일용으로 서비스를 해야 한다고 생각해 보겠습니다. 그리고 세가지 서비스마다 필요한 FLIGHT정보가 조금씩 틀리다고 하면 어떻게 될까요? 각 서비스에 맞게 모델링을 따로 해줘야 합니다.
PROJECTION VIEW 함께 사용했을때...
INTERFACE VIEW에는 Fiori UI용, 외부 API용, 모바일용 서비스에서 필요한 모든 필드를 관리하고 있습니다. 그렇기 때문에 INTERFACE VIEW를 참조하여 각각의 서비스별로 PROJECTION VIEW를 생성하고 서비스에 맞게 노출할 필드만 조정해 주면 됩니다.
Note.
두 레이어를 분리함으로써 얻는 장점
재사용성 : 하나의 데이터 모델로 여러 서비스 제공
유지보수성 : 비즈니스 로직과 UI의 로직을 분리
확장성 : 새로운 용도의 서비스 추가 용이
3.INTERFACE VIEW 생성
MANAGED 시나리오에서는 신규 PACKAGE를 만들어 아래와 같이 진행하겠습니다.
PACKAGE : ZEVER_02
TABLE : /DMO/TRAVEL
INTERFACE VIEW : ZEVER_M_TRAVEL_I
먼저 /DMO/TRAVEL 테이블을 참조하여 INTERFACE VIEW를 아래와 같이 생성하겠습니다. SIMPLE REPORT에서 만든것처럼 동일하게 생성하면 됩니다.
4.PROJECTION VIEW 생성
PROJECTION VIEW를 생성해 보겠습니다. INTERFACE VIEW에 마우스 오른쪽 클릭 후 New Data Definition을 선택합니다.
VIEW 이름과 Description을 입력하고 Next 버튼을 클릭합니다.
defineProjectionView를 선택하고 Finish 버튼을 클릭합니다.
통화키 참조는 VIEW마다 해줘야 합니다. provider contract는 transactional query를 선택합니다.
그래도 오류가 남아 있습니다. 오류내용을 확인해 보겠습니다.
"Transactional Projection View must be part of a business object."
PROJECTION VIEW는 BUSINESS OBJECT의 구성원이어야 하는데 그렇지 않아서 나는 오류입니다.
Note.
provider contract
transactional_query : CUD, Action등 Transactional 기능 지원, 일반적인 Fiori APP 개발시 사용
transactional_interface : 외부 시스템 연동용 API 개발시 사용
analytical_query : 집계/분석 쿼리 최적화, SAP Analytics Cloud 연동시 사용
sql_query : 단순 SQL 조회 목적
아래와 같이 INTERFACE VIEW와 PROJECTION VIEW에 root 를 입력하면 에러가 사라집니다. BO의 시작은 root view 부터 시작한다고 생각하시면 편합니다. BUSINESS 로직을 구현하기 위해서는 Behavior를 생성해야 하는데 Behavior는 view 를 참조하여 생성하게 됩니다. 그런데 일반 view로는 생성이 불가능 하고 오직 root view 로만 참조하여 생성할수 있습니다. 그렇기 때문에 INTERFACE VIEW와 PROJECTION VIEW를 root view로 선언만 하더라도 시스템은 BO의 구성원으로 인정하게 됩니다.
참고로 INTERFACE VIEW가 root view이면 PROJECTION VIEW도 root view 이어야 하고 반대로 INTERFACE VIEW가 일반 view이면 PROJECTION VIEW도 일반 view로 생성해야 합니다. 안그러면 에러가 발생합니다.
이제 화면에 노출시킬 필드를 지정해 보겠습니다. 아래와 같이 @UI.lineItem 어노테이션을 추가해 줍니다. UI와 관련된 VIEW가 PROJECTVIEW이기 때문에 어노테이션을 PROJECTION VIEW에 추가해 줍니다. 사실 INTERFACE VIEW에 추가해도 결과는 동일하지만 목적에 맞게 PROJECTION VIEW에 추가해 주겠습니다.
CUD기능을 위한 BO는 서비스까지 만든다음에 생성할 예정입니다. 일단은 빠르게 서비스까지 생성해서 APP을 화면에 띄워보겠습니다. PROJECTION VIEW에 마우스 오른쪽 클릭 후 New Service Definition을 선택합니다.
Service Name과 Description을 입력하고 Next 버튼을 클릭합니다.
Finish 버튼을 클릭합니다.
이번에는 조금전 생성한 Service Definition 에 마우스 오른쪽 클릭 후 New Sercive Binding 을 선택합니다.
Service Binding Name과 Description을 입력하고 Binding Type은 OData V4 - UI를 선택합니다.
그리고 Next 버튼을 클릭합니다.
Service Binding을 활성화 시킨 후 Publish 버튼을 클릭합니다.
Publish가 완료되면 Entity를 선택하고 Preview 버튼을 클릭해서 APP을 실행해 봅니다.
특별한 문제가 없다면 정상적으로 조회가 됩니다. Managed CUD APP의 Main Entity를 생성하고 빠르게 서비스까지 생성해 보았습니다. 앞으로 SIMPLE REPORT에서 했었던 기능들도 계속 나올 예정입니다. 한번 해봤다고 지나가지 마시고 익숙해 질때까지 계속 해보는게 좋습니다.
다음시간에는 Metadata Extension 에 대해 알아보고 Business 로직을 위한 Behavior를 만들어 보겠습니다.