목차
1.Behavior Definition
RAP Architecture 를 다시한번 보겠습니다. 지난시간에 Business Object중 Data Modeling에 대해 알아봤다면 이번시간에는 그 아래에 있는 Behavior definition과 Behavior implementation에 대하여 알아보겠습니다.
과거의 CDS View는 단순히 데이터베이스의 테이블을 조인해서 화면에 뿌려주는 역할에 그쳤습니다. 하지만 RAP 모델에서는 CDS View에 Behavior Definition을 결합함으로써 해당 데이터 엔티티가 CUD 작업을 할 수 있는 강력한 비즈니스 객체로 진화하게 됩니다.
Behaviro Definition에서는 다음과 같은 행동들을 정의하게 됩니다.
- CUD작업의 선언 : 데이터의 등록(Create), 수정(Change), 삭제(Delete)를 명시적으로 선언.
- Action, Validation, Determination등 비즈니스 로직을 수행하기 위한 다양한 기능에 대한 선언
- 잠금(Locking) 및 권한(Authorization) 제어 : 여러 사용자가 동시에 같은 데이터를 수정하지 못하도록 막는 Lock기능과 특정 유저만 수정할 수 있게 제한하는 권한체크로직 매핑
Behavior Definition은 Main View인 Root View를 참조하여 생성합니다. Interface View와 Projection View에 대한 Behavior Definition을 각각 생성하여 사용합니다. 여기서는 각각 Interface Behavior Definition, Projection Behavior Definition으로 부르겠습니다. 자 그럼 Interface Behavior Definition을 먼저 생성해 보겠습니다.
Root Interface View인 ZEVER_M_TRAVEL_I에 마우스 오른쪽 클릭 후 New Behavior Definition을 클릭합니다.
Behavior Name은 View이름과 동일하게 생성이 됩니다. Description을 입력하고 Implementation Type을 Managed를 선택합니다. BO가 Managed인지 Unmanaged인지가 여기서 결정이 됩니다. 다 입력했으면 Next 버튼을 클릭합니다.
Behavior Definition이 생성되었습니다. Root View인 ZEVER_M_TRAVEL_I를 참조하여 만들었지만 자식 View인 Booking에 대해서도 함께 생성된 걸 볼 수 있습니다. 이처럼 Root View와 부모 자식관계 즉 Composition으로 연결된 View들도 함께 생성되게 됩니다. 생성된 Behavior를 보면 일반 ABAP로직도 아니고 복잡해 보입니다. 실습하면서 하나씩 알아보도록 하겠습니다.
strict
strict( 2 )를 선언하면 개발표준규칙을 엄격하게 적용하겠다라는 선언이라고 생각하시면 됩니다.
과거 RAP초창기 버전에는 Behavior Definition을 작성할 때 컴파일러가 문법검사를 다소 느슨하게 처리했습니다. 그러다 보니 실수로 아키텍쳐 위반을 하거나 향후 업그레이드시 오류를 유발할 수 있는 불안정한 코드가 빌드되는 문제가 있었습니다. 이를 해결하기 위해 strict mode를 도입하였습니다. 그중에서 strict(2)는 가장 최신 진화 버전으로 가장 엄격한 기준을 적용하는 모드입니다.
프로젝트 수행시 아마 strict(2) 모드로 개발을 진행하게 될꺼라 생각합니다. 여기서도 strict(2) 모드로 실습하겠습니다.
이번에는 Root Projection View인 ZEVER_M_TRAVEL_P를 참조하여 Behavior Definition을 생성하겠습니다.
Projection View에 마우스 오른쪽 클릭 후 New Behavior Definition을 선택합니다.
Projection Behavior Definition도 동일한 이름으로 생성됩니다. Description을 입력하고 Next 버튼을 클릭합니다.
Projection Behavior Definition도 아래와 같이 생성되었습니다. Interface Behavior Definition 보다 내용이 좀 간단합니다.
Interface Behavior Definition은 App에서 사용할 기능들을 지정하는 역할을 한다면 Projection Behavior Definition에서는 그 기능들을 사용할지 말지를 결정하는 역할을 합니다.
여기까지 하고 App을 다시 실행해보면 이전에 안보였던 Delete라는 버튼이 생겼습니다. 그런데 Create버튼이 안보입니다. 그 이유는 Service Binding을 V4로 생성하면 Behavior Definition에 Draft 기능을 구현해야만 Create 버튼이 기본으로 활성화 됩니다.
(V2는 Draft기능이 없어도 Create 버튼이 기본으로 활성화 되어있습니다.)
프로젝트시 특별한 경우 아니면 V4를 사용하기 때문에 여기서도 Draft 기능을 기본으로 사용하도록 구현해 보겠습니다.
DRAFT
그러면 Draft기능이 무엇인지 잠깐 알아보고 가겠습니다.
웹 UI를 다루다 보면 사용자가 데이터를 입력하다가 실수로 창을 닫거나 인터넷이 끊기면 입력하던 데이터가 통째로 날아가게 됩니다. RAP 모델에서는 이를 깔끔하게 해결해주는 Draft 기능을 제공하고 있습니다.
쉽게말하면 사용자가 데이터를 한글자 한글자 입력할 때 마다 백엔드로 비동기 요청이 날라가 자동으로 임시 저장이 됩니다. 이때를 Draft 상태라고 하는데 실제 저장전까지는 Draft 상태가 되고 사용자가 저장하기 전까지 자동으로 Lock을 유지해 줍니다.
임시 저장을 위해 Draft 테이블을 생성해야 하고 실제 저장하기 전까지의 정보가 이 Draft 테이블에 저장되어 관리가 되고 저장하는 순간 Draft 테이블의 정보를 본 테이블에 저장하고 Draft 테이블에서는 삭제가 됩니다. 이러한 과정은 실습을 하면서 보여드리겠습니다. 먼저 Interface Behavior Definition에 Draft 기능을 추가해 보겠습니다.
Draft 기능을 사용하기 위해 상단에 with draft; 를 추가해 줍니다. with draft를 추가하면 아래와 같이 많은 에러가 발생합니다. Draft기능을 사용하기 위해서는 필수로 지정해줘야 하는 기능들을 하나씩 추가해 보겠습니다.
먼저 위에서 설명했듯이 임시저장을 위해서는 Draft 테이블이 필요하다고 했습니다. Travel과 Booking 두곳에 Draft 테이블을 추가합니다. 테이블 이름은 적당히 지어줍니다.
그리고 lock master옆에 total etag + 필드를 하나 지정해 줘야 합니다. 일단 아래처럼 입력해 줍니다. 그리고 draft 관련 action들을 아래와 같이 입력해 줍니다. 설명은 뒷부분에서 하도록 하겠습니다. 여기까지 입력했으면 실제로 Draft 테이블을 생성해 보겠습니다.
생성할 Draft 테이블 마우스 클릭후 Ctrl + 1 을 누르면 Quick Assist 창이 뜹니다. Create draft table.. 을 더블클릭 합니다.
테이블 Name과 Description을 확인하고 Next 버튼을 클릭합니다.
아래와 같이 원본 테이블을 참조하여 Draft 테이블을 자동으로 만들어 줍니다. 동일하게 Booking Draft 테이블도 생성합니다.
여기서는 생략하겠습니다. 여기서는 Booking Draft 테이블 생성 설명은 생략하겠습니다.
Note.
Draft 테이블은 원본 테이블을 참조하여 생성이 됩니다. 만약 원본 테이블의 필드가 추가되거나 수정되면 Behavior Definition에 오류가 발생합니다. Draft 테이블도 동일하게 수정해 줘야 합니다.
여기까지 잘 따라오셨다면 Interface Behavior Definition이 오류없이 활성화가 될겁니다.
Interface Behavior Definition에 Draft 기능을 추가했으니 Projection Behavior Definition에 사용하겠다고 등록을 해줘야 합니다.
상단에 use draft; 를 추가하고 Draft관련 action들을 등록해 줍니다.
그리고 다시 App을 실행해 보겠습니다. 드디어 Create 버튼이 생겼습니다. 하지만 지금 시점에서 Go 버튼이나 Create 버튼을 클릭하면 에러가 발생합니다. 다음 시간에는 이 에러를 잡아보겠습니다.
