RAP 16 - MANAGED REPORT : DETERMINATION

 

 

 

목차

Determination

 

핵심개념

Determination은 비즈니스 객체(BO) 데이터가 수정되거나 특정 이벤트가 발생했을 때, 시스템이 비즈니스 로직에 따라 필드값을 자동으로 계산하거나 채워 넣는(Calculate & Auto-fill) 기능입니다. 사용자의 직접적인 입력을 받지 않고, 시스템이 연산 결과나 기본값(Default Value)을 결정해 전달할 때 사용합니다.

 

주요특징

트리거 시점 명시: 데이터의 생성(Create) 또는 수정(Update)시 특정 필드 값이 변할 때 로직이 실행되도록 설정합니다.

실행모드 : 

 - on modify: 화면에서 데이터가 입력/변경되는 즉시 실행되어 UI에 반영됩니다.

 - on save: 최종 저장(Save) 버튼을 누르는 순간 실행됩니다.

 

 

 

그러면 Determination에 대해 실습을 해보겠습니다. 지난 시간에 Total Price 필드를 비활성화 시켰습니다. Total Price는 Travel의 Booking Fee와 Booking의 Flight Price를 모두 더한 값으로 하기로 해서 직접 입력이 필요 없기 때문입니다. 이제 Determination을 이용하여 Booking Fee 또는 Flight Price에 값을 입력 또는 변경하면 실시간으로 Total Price를 계산하는 기능을 구현해 보겠습니다.

 

 

Interface Behavior Definition에 Determination을 추가합니다. 실시간으로 Total Price에 반영하기위해 on modify 옵션을 사용했고 field에는 BookingFee 필드를 지정했습니다. 필드를 지정하지 않고 create 또는 update 시점에 Determination이 실행되도록 할수도 있습니다.

 

 

Note

[실행 조건 - on save, on modify]
determination xxx on save : 저장버튼 누르는 시점에 determination이 실행됩니다.
determination xxx on modify : 필드가 수정될때마다 determination이 실행되고 저장시점에도 다시한번 실행됩니다.

[트리거 조건 - create, update]
determination xxx on modify { create; } : create 버튼 누르는 시점에 determination이 실행됩니다.
determination xxx on save { create; } : create 버튼 누르고 저장버튼 누르는 시점에 determination이 실행됩니다.

determination xxx on modify { update; } : 생성/수정 시점에 필드가 수정되고 엔터를 치는 순간 실행됩니다.
determination xxx on save { create; update; } : create버튼 및 저장버튼 클릭시 determination이 실행됩니다.
determination xxx on save { update; } : 실행조건 on save와 트리거 조건 update 단독으로는 사용 못합니다.

 

 

Determination이름에 마우스를 클릭하고 Quick Assist 기능으로 Method를 생성합니다.

생성된 Method의 파라미터를 확인해 보겠습니다. keys로 데이터를 받고 reported로 메세지 처리를 해주는것 같습니다. failed가 없는걸로 봐서 Validation처럼 에러처리를 하는 기능은 없어 보입니다. 그럼 keys에 값이 어느시점에 어떻게 넘어오는지 확인해 보겠습니다. Method에 디버깅을 걸로 App을 실행시켜 보겠습니다.

 

 

생성되어 있는 Travel ID 중 하나를 선택해서 Booking Fee를 수정하고 엔터를 치면 Determination Method가 호출됩니다.

 

 

Booking Fee 필드가 수정되는 시점에 keys 파라미터로 해당 Travel ID 정보가 넘어오는걸 알 수 있습니다. 그럼 전달받은 Travel ID정보로 Travel Enitity와 Booking Entity를 읽어서 Total Price를 계산하고 Travel Entity를 Modify 해주면 될 것 같습니다. 로직을 구현해 보겠습니다.

 

 

1. 입력받은 keys 값으로 Travel, Booking 정보를 읽습니다.

2. Total Price 값을 계산합니다.

3. 계산된 Total Pirce값을 Modify 합니다.

 

 

App을 실행해서 Booking Fee를 900으로 수정을 하고 저장해 보겠습니다. 900 + 858이니까 Total Price는 1,758이 되야 합니다.

 

 

정상적으로 반영되었습니다.

 

 

이제 Booking 쪽에도 Flight Price가 변경되었을때 Total Price를 계산하는 Determination을 추가해 보겠습니다. Behaivor Definition으로 이동해서 Determination을 추가하고 Quick Assist 기능으로 Method를 추가합니다. Determination 이름은 Travel에서 선언했던 이름과 동일하게 하겠습니다. Travel과 Booking은 Class로 구분되기 때문에 Method 이름은 동일해도 상관없습니다.

 

 

Method이름에 마우스를 클릭하고 파라미터를 확인해 보겠습니다. Travel때와 동일합니다. keys의 필드를 확인하기 위해 [derived type..]을 클릭합니다.

 

 

Travel때와 다르게 bookingid 필드가 하나 더 있습니다. Booking의 Flight Price가 변경되면 어차피 Travel의 Booking Fee정보와 Booing의 Flight Price 정보를 모두 읽어야 하기 때문에 Travel에서 구현한 로직과 동일하게 하면 될 것 같습니다. 로직을 구현해 보겠습니다.

 

 

Travel에서 구현했던 로직이랑 동일합니다. 로직을 추가하고 App을 다시 실행시켜서 Flight Price를 변경했을때 Total Price 계산이 정상적으로 되는지 확인해 보겠습니다.

 

 

아래와 같이 Flight Price를 1000으로 수정하고 저장버튼을 눌러 보겠습니다. 정상적이라면 Total Price가 1900으로 계산되어야 합니다.

 

 

정상적으로 계산되었습니다.

 

 

이번 실습에서는 Total Price를 계산하기 위하여 Travel쪽과 Booking쪽에 Determination을 활용하여 로직을 구현했습니다. 그런데 양쪽모두 로직이 동일합니다. 이 부분을 Classic ABAP의 함수같은걸 만들어서 사용하면 유지보수 측면에서 좋을것 같습니다. 이때 지난시간에 잠깐 소개해 드렸던 Internal Action을 사용하면 됩니다.

 

Internal Action

Internal Action은 외부에 노출되지 않고 RAP 비즈니스 객체 내부에서만 호출하여 사용할 수 있는 Action입니다. OData로 노출되지 않아 UI나 외부 EML에서 부를수 없고 같은 BO의 Determination이나 다른 Action에서 호출하여 사용할 수 있습니다.

 

 

자 그럼 Behavior Definition에 Internal Action을 추가해 보겠습니다. recalcTotPrice 이름으로 추가하고 Method를 생성합니다.

 

 

파라미터를 살펴보면 일반 Action과 동일합니다. 각각의 Determination에서 Internal Action을 호출할 때 keys에 값을 넘겨주고 Method 내부에서는 넘겨받은 keys값으로 기존 Determination에서 구현했던 로직을 그대로 구현하면 될 것 같습니다. 먼저 Action 로직먼저 구현해 보겠습니다.

 

 

로직은 Determination 로직과 동일합니다. 그럼 Travel과 Booking쪽 Determination에서는 Internal Action을 호출하는 로직으로 수정해 보겠습니다.

 

 

Action을 호출하는 EML구문은 아래와 같습니다. Travel과 Booking쪽 Determination 모두 아래처럼 동일하게 호출하면 됩니다.

로직을 모두 수정했으면 App을 실행시켜 정상적으로 작동하는지 확인해 보겠습니다.

 

 

Booking Fee를 500으로 수정하고 Flight Price를 2000으로 수정한 후 저장버튼을 눌러보겠습니다. 

 

 

정상적으로 반영되는걸 확인할 수 있습니다.

 

 

 

마지막으로 Determination의 실행조건과 트리거 조건에 대하여 주의해야 할 점을 살펴보고 가겠습니다.

 

determination calculateTotalPrice on modify { update; }

만약 위와같이 Determination의 실행조건과 트리거 조건을 선언했다면 어떻게 될까요? 로직이 지금과 같다면 무한루프에 빠지게 됩니다. 트리거 조건 update는 모든 필드를 대상으로 하기 때문에 메소드에서 마지막에 Total Price 필드를 Modify하기 때문에 시스템은 Total Price 필드가 수정되었다고 판단하고 determination을 또 실행합니다. determination 로직 구현시 이런 부분은 주의해야 합니다.

 

 

Side Effect

Booking Fee를 수정하고 엔터를 치면 Determination이 수행되어 Entity에는 새로 계산된 Total Price가 반영이 되지만 화면 갱신이 안됩니다. Booking Fee를 수정하는 즉시 실시간으로 Total Price에 값도 갱신되도록 할수는 없을까요? 있습니다. Side Effect 기능을 사용하면 됩니다.

 

그럼 Ingerface Behavior Definition에 Side Effect 구문을 추가해 보겠습니다. 먼저 Travel쪽 입니다. 앞쪽 field에는 데이터를 입력하는 필드이고 뒷쪽 affects field는 앞쪽 필드의 값에 의해서 갱신되는 필드를 입력하면 됩니다.

 

 

마찬가지로 Booking쪽에도 Side Effect를 추가해 줍니다.

 

 

마지막으로 Projection Behavior Definition에 Side Effect를 노출시킨 후 App에서 확인해 보시면 실시간으로 Total Price가 갱신되는걸 확인할 수 있습니다.