이글은 아래 링크의 원본 글에 대한 한글 번역 입니다
https://blogs.sap.com/2014/06/03/adaptation-in-web-dynpro-abap-in-depth-analysis/
* 번역자의 의견 *
주의!! 스크롤의 압박이 있습니다. FPM의 원리를 알고 싶은 분만 읽어 보세요.
이 글은 SAP의 공식 입장이 아니라 David Fernandez Castro 개인의 분석입니다.
adaptation(각색), enhancement(강화), configuration(구성), customization(맞춤)은 번역하지 않고 단어 그대로 사용하였습니다.
personalization은 주로 개인화로 번역하였습니다.
Adaptation in Web Dynpro ABAP – In-depth analysis
June 3, 2014
소개
웹딘프로아밥 adaptation은 웹딘프로아밥의 핵심 개념중 하나이고 FPM(Floorplan Manager)의 초석을 이루는 기술입니다. 최근 SAP의 UI 가이드라인에 따르면, FPM은 비지니스 어플리케이션의 UI 개발에 사용할 추천 기술입니다. 웹딘프로아밥 컴포넌트와 어플리케이션에 대한 adaptation은 웹딘프로아밥 컨피규레이션 프레임워크로써 제공됩니다.
이 글은 웹딘프로아밥 adaptation 개념에 대해 기술적 관점에서 매우 상세하게 분석해 보겠습니다. 설명에 사용되는 기술 용어들이 매우 유사한 의미를 가지지만 미묘한 차이가 있다는 것을 파악해야 합니다. 예를 들어 adaptation, configuration, customization, personalization은 동의어라고 할 수 있을 정도로 비슷한 단어 이지만 여기에서는 매우 다른 개념을 가지고 있다는 점을 염두해 두세요.
Adaptation의 계층구조와 각 계층
웹딘프로아밥 컨피규레이션 프레임워크라는 이름과는 다르게 단지 컨피규레이션만이 아니라 adaptation을 합니다. 웹딘프로아밥 adaptation 은 2가지 방식으로 분류합니다. 한가지 방식은, 계층 구조로 3개의 계층를 가집니다: configuration, customization, personalization(개인화); 그리고 다른 방식은, 2 종류로 분류하는데 built-in adaptation 과 component-defined adaptation 입니다.
그림 1. Adaptation의 계층구조와 built-in/component-defined 데이터 표현
위 그림은 잘알려진 웹딘프로아밥 adaptation 게층구조 표현입니다. 세로방향으로 3개의 계층 나뉘어져 있습니다. 각 계층에서 내부에 가로방향으로 2개의 종류가 있습니다. Customization은 개인화의 관리자모드(administrator personalization)라고 불리기도 합니다.
관리 주체
일반적으로 configuration 데이터는 개발자가, customization 데이터는 시스템 관리자가, 개인화 데이터는 각 사용자가 관리합니다. 여기서 개발자란 S_DEVELOP 권한이 있는 사람을 뜻하고, 관리자란 S_WDR_P13N 권한이 있는 사람을 뜻합니다.
데이터 적용 우선순위
개인화 데이터가 가장 높은 우선순위를 가집니다. 그 다음이 customization 데이터 그리고 다음이 configuration 데이터 입니다. 다른 말로 하자면 configuration 데이터가 기본으로 적용되지만 customization 데이터로 덮어써질 수 있고 개인화 데이터가 이 모든걸 덮어쓰고 최후에 적용될 수 있습니다. 하지만 예외적으로 configuration 이나 customization 에서 최종(final) 표시된 데이터는 더 높은 우선순위 데이터가 있더라도 변경 되지 않고 적용됩니다.
데이터 적용 범위
The scope of adaptation data is different for each adaptation data layer. The configuration data applies to the whole system, the customization data depends on the system client, and the personalization data depends on the user.
Built-in adaptation 데이터 와 component-defined adaptation 데이터
built-in adaptation 데이터는 웹딘프로아밥 컨피규레이션 프레임워크에 의해 직접 제공되는 데이터 입니다. 각 컴포넌트의 구현에 관계없이 모든 웹딘프로 컴포넌트에 동일하게 적용됩니다. 이것은 일반적인 adaptation으로 볼 수 있습니다. 기본적으로 UI 엘리먼트의 속성(보임/숨김, 텍스트 등)을 변경할 하는 것이라고 보면 됩니다.
그리고 또다른 종류의 adaptation 데이터가 있습니다. 바로 각 컴포넌트 별로 다르게 적용되는 component-defined adaptation 데이터 입니다. 이것을 정의하려면 WDA 컴포넌트에 컨피규레이션 컨트롤러를 만들어야 합니다. 컨피규레이션 컨트롤러에 어떤 데이터를 adaptation 해야 하는지 어트리뷰트를 정의합니다. 일반적이지 않고 각 컴포넌트 구현에 따라서 다른 데이터 구조를 가집니다.
adaptation 데이터 인스턴스 개념
콘크리트 adaptation, 이것은 공식 용어는 아니지만 쉽게 설명하기 위해 사용합니다. 콘크리트 adaptation 데이터는 하나의 웹딘프로아밥 컴포넌트 인스턴스를 위해 존재하는 adaptation 으로 3 계층을 포함합니다. 하나의 configuration 데이터 인스턴스, 클라이언트별로 여러개의 customization 데이터 인스턴스, 사용자별로 여러개의 개인화 데이터 인스턴스가 있습니다. 그림 1에서 설명한 내용을 대입하여 각 계층별로 맞춰보시기 바랍니다.
그림 2. adaptation 데이터 인스턴스 개념
그림 2에서는 하나의 configuration 데이터 인스턴스(system), 여러 customization 데이터 인스턴스(clients), 여러 개인화 데이터 인스턴스(users)를 보여줍니다. 하지만 실행시에는 웹딘프로아밥 컨피규레이션 프레임워크가 하나의 customization 데이터 인스턴스와 하나의 개인화 데이터 인스턴스만 선택할 것입니다. 선택과정은 나중에 다시 설명하겠습니다.
웹딘프로아밥 컴포넌트에 대한 adaptation - 컴포넌트 컨피규레이션
웹딘프로 아밥 컴포넌트는 웹딘프로아밥 컨피규레이션 프레임워크를 사용하여 adaptation 할 수 있습니다. 하나의 컴포넌트에 대해 여러개의 adaptation 인스턴스를 만들 수 있습니다. adaptation 데이터 인스턴스는 컴포넌트 컨피규레이션 이라는 곳에 저장됩니다. 이름 떄문에 의미가 햇갈릴 수 있으니 주의하세요. 컴포넌트 컨피규레이션은 단지 configuration만 저장하는게 아니라 adaptation 전체를 저장합니다. 각각의 컴포넌트 컨피규레이션은 각자 유일한 컨피규레이션 아이디를 가지고 있습니다.
웹딘프로아밥 컴포넌트는 여러개의 adaptation 인스턴스를 가질수 있기 때문에, 여러개의 컴포넌트 컨피규레이션에 의해 adaptation 될 수 있습니다. 반대 방향을 살펴보면 하나의 컴포넌트 컨피규레이션은 오직 하나의 adaptation 인스턴스 즉 하나의 웹딘프로아밥 컴포넌트만 가질 수 있습니다.
일반적으로 웹딘프로아밥 컴포넌트 adaptation 과정을 보면 개발자가 컴포넌트 컨피규레이션을 만드는 것으로 시작합니다. 그러나 이것만이 유일한 경우는 아닙니다. 컴포넌트 컨피규레이션이 암시적(implicitly)으로 시스템에 의해 자동 생성 되는 경우도 있습니다. 이렇게 두가지 경우로 구분할수 있습니다:
- 명시적 컴포넌트 컨피규레이션, 이것은 TADIR 오브젝트 입니다. 보통 개발 오브젝트 처럼 아밥 저장소에 저장되고 CTS할 수 있습니다. 개발자가 아밥 워크벤치(SE80)에서 개발합니다. Z로 시작하는 컨피규레이션 아아디를 입력해야 합니다. 인스턴스가 한번 만들어지면 모든 adaptation 데이터(configuration 데이터, customization 데이터, 개인화 데이터)를 관리합니다.
- 암시적 또는 이름없는 컴포넌트 컨피규레이션, 이것은 저장소에 저장되는 오브젝트가 아닙니다. 필요에 따라 웹딘프로아밥 컨피규레이션 프레임워크가 암시적으로 만들어냅니다. 컨피규레이션 아이디는 숫자와 알파벳을 혼용하여 자동으로 생성됩니다. 여기에는 configuration 데이터나 component-defined adaptation 데이터는 들어 있지 않습니다. 오직 built-in customization 데이터 와 built-in 개인화 데이터만 들어 있습니다. 웹딘프로 컨피규레이션 프레임워크는 웹딘프로아밥 어플리케이션과 컴포넌트 인스턴스/ 재사용에 대한 여러 조합에 각각 필요한 이름없는 컨피규레이션을 만들어 냅니다. 조합을 결정하는 자세한 과정은 아래에 다시 설명하겠습니다.
컴포넌트 컨피큐레이션 오브젝트에서 adaptation 데이터 관리
컴포넌트 컨피규레이션 오브젝트에서 adaptation 데이터 인스턴스는 추가되거나 변경될 수 있습니다. 각 계층에 따라 관리 방법이 다릅니다:
- Configuration 데이터, 컨피큐레이션 에디터를 사용해서 명시적 컴포넌트 컨피규레이션을 관리 할 수 있습니다. 시작하는 방법은 스탠다드 웹딘프로아밥 어플리케이션 CONFIGURE_COMPONENT(컴포넌트는 WDR_CFGE_EDITOR)을 실행하면 됩니다. 물론, 개발시에 이렇게 해야하고 실행시에는 관리가 불가능 합니다. 예외로 실행시 관리하는 유일한 것은 바로 컨피규레이션 에디터 자체를 실행할때 입니다.
- Customization 데이터, 커스터마이즈 에디터를 사용하여 관리합니다. 시작하는 방법은 스탠다드 웹딘프로아밥 어플리케이션 CUSTOMIZE_COMPONENT(컴포넌트는 WDR_CFGE_EDITOR)을 실행하면 됩니다. 물론, 개발시에 이렇게 해야합니다. 실행시에는 관리하는 방법도 있습니다. 바로 URL 파라미터 sap-config-mode=x 를 주어서 관리자 모드로 실행하는 것입니다. customization 데이터가 적용되는 범위는 오직 그 하나의 클라이언트라는 점을 주의하세요.
- 개인화 데이터, 오직 실행시에만 관리할 수 있습니다. 그리고 개인화 비활성화 옵션을 사용하지 않아야 합니다. 각 사용자는 자신의 개인화 데이터만 관리할 수 있습니다. 데이터 자체가 개인에게 속한것이라 할 수 있습니다. 실행시 웹딘프로아밥 컨피큐레이션 프레임워크는 built-in 개인화 데이터만 관리합니다. 그러므로 component-defined 개인화 데이터를 관리하고 싶다면 개발 단계에서 미리 사용자가 개인화 관리를 할 수 있도록 해주어야 합니다. 개인화 비활성화 옵션은 웹딘프로아밥 어플리케이션 파라미터 WDDISABLEUSERPERSONALIZATION로 조정합니다.
아래 표를 통해 정리해 보았습니다.
|
ADAPTATION
MATRIX
|
Configuration |
Customization |
개인화(Personalization)
|
| Built-in |
실행시: 불가.
개발시: CONFIGURE_COMPONENT 어플리케이션을 실행하여 관리. 명시적 컴포넌트 컨피규레이션만 가능.
|
실행시: 관리자 모드로 실행하면 마우스 오른쪽 버튼을 눌러 나온 메뉴로 들어갈 수 있음.
개발시: CUSTOMIZE_COMPONENT 어플리케이션을 실행하여 관리. 명시적 컴포넌트 컨피규레이션만 가능.
|
실행시: 실행중 마우스 오른쪽 버튼을 눌러 나온 메뉴로 들어갈 수 있음. 관리자모드가 아닐것. WDDISABLEUSERPERSONALIZATION 파라미터를 사용하지 않을것.
개발시: 불가.
|
| Component-defined |
실행시: 불가 (FPM은 가능).
개발시: CONFIGURE_COMPONENT 어플리케이션을 실행하여 관리. 명시적 컴포넌트 컨피규레이션만 가능.
|
실행시: 관리자 모드로 실행하면 마우스 오른쪽 버튼을 눌러 나온 메뉴로 들어갈 수 있음.
개발시: CUSTOMIZE_COMPONENT 어플리케이션을 실행하여 관리. 명시적 컴포넌트 컨피규레이션만 가능.
|
실행시: 불가. 개발 단계에서 미리 사용자가 개인화 관리를 할 수 있도록 해주어야 함.
개발시: 불가.
|
어플리케이션 컨피규레이션 오브젝트
어플리케이션 컨피규레이션 오브젝트는 adaptation 스키마에서 매우 중요합니다. 이것은 아밥 워크벤치에서 만듭니다. 항상 하나의 웹딘프로아밥 어플리케이션에 연결됩니다. 각 웹딘프로아밥 어플리케이션은 여러개의 어플리케이션 컨피규레이션이 연결될 수 있습니다. 어플리케이션 컨피규레이션 오브젝트는 TADIR 테이블에 타입 WDCA 오브젝트로 저장됩니다. 각각의 어플리케이션 컨피규레이션은 각자 유일한 컨피규레이션 아이디를 가지고 있습니다.
어플리케이션 컨피규레이션 오브젝트는 어떤 컴포넌트 컨피규레이션 오브젝트가 adaptation 되어야 하는지를 어플리케이션 관점에서 전체적으로 보는 지도 같은 존재 입니다. 어플리케이션에 속한 모든 컴포넌트에 대해서 컴포넌트 컨피규레이션을 지정할 필요는 없습니다. 명시적으로 지정하지 않은 경우는 웹딘프로아밥 컨피규레이션 프레임워크에 의해 이름없는 컴포넌트 컨피규레이션으로 인식하여 자동으로 관리합니다.
웹딘프로아밥 어플리케이션이 실행될때마다 특정 어플리케이션 컨피규레이션을 지정하여 실행하거나 명시적으로 지정하지 않은 경우 이름없는 어플리케이션 컨피규레이션이 자동으로 붙습니다. 두번째 경우라면, 어플리케이션에 속한 각 웹딘프로아밥 컴포넌트는 이름없는 컴포넌트 컨피규레이션 정책을 따릅니다. 반대로 어플리케이션 컨피규레이션을 지정하여 실행하면 각 컴포넌트에 어떤 컴포넌트 컨피규레이션을 사용하는지 알 수가 있습니다.
컴포넌트 컨피규레이션과 어플리케이션 컨피규레이션 둘은 FPM을 이루는 기반입니다. FPM을 사용하므로써 개발 기술이 웹딘프로아밥 컴포넌트를 전체 개발하는 방식에서 스탠다드 웹딘프로아밥 컴포넌트(FPM 컴포넌트)를 단지 adaptation 하는 형태로 개발 방식의 변경이 있습니다.
권장하는건 아니지만 컴포넌트 컨피규레이션 아이디와 어플리케이션 컨피규레이션 아이디를 동일하게 만들 수도 있습니다.
웹딘프로아밥 어플리케이션을 실행할때 2가지 방법으로 어플리케이션 컨피규레이션을 지정할 수 있습니다:
- URL 파라미터 SAP-WD-CONFIGID 로 어플리케이션 컨피규레이션 아이디를 전달합니다. 컨피규레이션 아이디가 올바르다면 해당 어플리케이션 컨피규레이션이 지정됩니다. 올바르지 않다면 어플리케이션 컨피규레이션을 지정하지 않고 어플리케이션이 시작됩니다.
- 만약 URL에 SAP-WD-CONFIG 파라미터가 없다면, 프레임워크는 웹딘프로아밥 어플리케이션 파라미터 WDCONFIGURATIONID를 확인합니다. WDCONFIGURATIONID에 값이 있고 그 컨피규레이션 아이디가 올바르다면 해당 어플리케이션 컨피규레이션이 지정됩니다. 올바르지 않다면 어플리케이션 컨피규레이션을 지정하지 않고 어플리케이션이 시작됩니다.
어플리케이션 컨피규레이션 오브젝트 정의는 테이블 WDY_CONFIG_APPL 에 저장됩니다.
실행시 동적으로 컴포넌트 컨피규레이션을 적용하는 방법
개발시에는 어플리케이션 컨피규레이션에서만 컴포넌트 컨피규레이션을 지정할 수 있습니다. 동적으로 컴포넌트 컨피규레이션을 변경해야 한다고 가정해 봅시다. 이런경우 어플리케이션 컨피규레이션은 적절한 컴포넌트 컨피규레이션을 동적으로 지정할 수 없습니다. 그러나 아밥 코드를 이용하여 실행중에 컴포넌트 컨피규레이션을 지정할 수 있는 방법이 있습니다. 사실 FPM 프레임워크가 UIBB(User Interface Building Block)를 지정할때 이 메소드를 사용합니다. (컨피규레이션 아이디는 개발시 미리 adaptation 데이터로 입력해 두긴 하지만 실행시 그 정보를 기반으로 변경합니다).
아래 코드를 WDDOINIT 메소드에 넣으면 컴포넌트 컨피규레이션을 실행중에 변경할 수 있습니다:
METHOD wddoinit .
DATA lif_api TYPE REF TO if_wd_component.
DATA lif_adaptation TYPE REF TO if_wd_personalization.
DATA ls_config TYPE wdy_config_key.
lif_api = wd_this->wd_get_api( ).
lif_adaptation = lif_api->get_personalization_manager( ).
CLEAR ls_config.
ls_config–config_id = 'ZWD_DFC_1_COMP_CONFIG_2'.
lif_adaptation->load_config_by_key( ls_config ).
ENDMETHOD.
위 예제 코드에서 컴포넌트 컨피규레이션으로 ZWD_DFC_1_COMP_CONFIG_2을 지정하였습니다.
adaptation 데이터를 CTS 전송하는 방법
CTS 가능한지와 주의사항은 각 계층별로 각각 다릅니다. 개인화 데이터는 전송할 수 없습니다. customization 데이터는 customizing request로 전송합니다. configuration 데이터는 workbench request로 전송합니다.
adaptation 데이터의 전송에는 테이블 WDY_CONF_USER, WDY_CONF_USERT, WDY_CONF_USERT2, WDY_CONF_UDEF를 포함합니다. 어플리케이션 컨피규레이션은 workbench request로 전송하고 내용은 WDY_CONFIG_APPL 테이블에 있습니다.
실행시 adaptation 데이터를 결정하는 과정
실행시 웹딘프로아밥 컨피규레이션 프레임워크는 adaptation 데이터를 결정하고 각 웹딘프로아밥 컴포넌트 인스턴스에 적용합니다. 그림 3 처럼 3단계 과정이 있습니다.
그림 3. 각 웹딘프로아밥 컴포넌트 인스턴스에 대해 실행시 adaptation 데이터를 결정하는 과정
첫번째 단계에서는 웹딘프로아밥 컨피규레이션 프레임워크는 adaptation 데이터를 가져와야할 컨피규레이션 아이디를 읽어 옵니다. 다음 두번째 단계에서는 클라이언트와 사용자를 고려하여 필요한 모든 adaptation 데이터를 가져옵니다. 마지막으로 세번째 단계에서는 각 계층의 adaptation 데이터를 병합하여 최종 adaptation 데이터를 만들어 냅니다. 각 단계의 상세 설명은 아래에 더 있습니다. 이 모든것은 웹딘프로아밥 컴포넌트 하나의 입장에서 설명하는 것입니다.
단계 1: 컴포넌트 컨피규레이션 오브젝트를 가져옴
실행시에 웹딘프로아밥 컨피규레이션 프레임워크는 실행중인 각 웹딘프로아밥 컴포넌트 인스턴스별로 어떤 컴포넌트 컨피규레이션이 필요한지 결정합니다. 각 웹딘프로아밥 컴포넌트 인스턴스별로 모든 adaptation 데이터는 지정된 컴포넌트 컨피규레이션에서 읽어오고 그 컴포넌트 컨피규레이션 이름으로 저장하고 관리합니다. 웹딘프로아밥 컨피규레이션 프레임워크는 사용할 컨피규레이션 아이디를 결정합니다. 컨피규레이션 아이디는 어플리케이션 컨피규레이션에 지정된 값을 사용하거나 실행중에 아밥 코드로 동적으로 지정될 수도 있습니다. 만약 컨피규레이션 아이디가 아무것도 지정되지 않았거나 유효하지 않은 아이디 값을 입력한 경우, 프레임워크는 이름없는 컴포넌트 컨피규레이션 결정을 합니다.
이름없는 컴포넌트 컨피규레이션 결정
실행시, 일부 웹딘프로아밥 컴포넌트 인스턴스는 유효하지 않은 컨피규레이션 아이디를 가지는 경우도 있습니다. 웹딘프로아밥 컨피큐레이션 프레임워크는 이런 경우 이름없는 컨포넌트 컨피규레이션 결정을 합니다. 컨피규레이션 아이디는 프레임워크에 의해 자동으로 생성됩니다. 웹딘프로아밥 어플리케이션 이름과 웹딘프로아밥 컴포넌트 인스턴스에 따라 해시 펑션을 적용하여 아이디 값을 결정합니다.
그림 4. 이름없는 컴포넌트 컨피규레이션에서 컨피규레이션 아이디 결정
그림 4는 웹딘프로 어플리케이션 ZWD_APPL 와 웹딘프로 컴포넌트 ZWD_MAIN 으로 실행하는 경우를 예를들어 보여주고 있습니다. ZWD_MAIN은 2개의 컴포넌트를 사용합니다. 컴포넌트 ZWD_COMP1를 USAGE_1으로 사용하고 컴포넌트 ZWD_COMP2는 USAGE_2로 사용합니다. 웹딘프로아밥 어플리케이션 ZWD_APPL은 어플리케이션 컨피규레이션 지정 없이 실행하였습니다. 그리고 동적인 컴포넌트 컨피규레이션 적용 코드도 없습니다. 그러므로 웹딘프로아밥 컨피규레이션 프레임워크는 각 웹딘프로아밥 컴포넌트 인스턴스에 (메인 컴포넌트(ZWD_MAIN), USAGE_1 재사용(ZWD_COMP1), USAGE_2 재사용(ZWD_COMP2)) 대해 이름없는 컴포넌트 컨피규레이션 결정을 합니다. 앞서 설명했듯이 컨피규레이션 아이디는 숫자와 알파벳을 혼용하여 자동으로 결정됩니다. 각 컨피규레이션 아이디 결정 과정은 어플리케이션이 변경되거나 컴포넌트가 변경되어도 항상 동일합니다. 웹딘프로아밥 컴포넌트 이름은 영향이 없고 컴포넌트 사용 이름(USAGE_1 과 USAGE_2)이 영향을 줍니다. 이것은 만약 USAGE_1의 실제 웹딘프로아밥 컴포넌트가 변경되더라도 (예를들어 ZWD_COMP1 에서 ZWD_COMP_OTHER로) 컨피규레이션 아이디는 동일할 것을 의미합니다.
단계 2: adaptation 데이터 읽음
다음은 앞 단계에서 결정한 컴포넌트 컨피규레이션 오브젝트에서 adaptation 데이터를 읽어오는 것입니다. 여기서는 각 adaptation 계층별로 각각 데이터를 읽어 옵니다. configuration 데이터는 컴포넌트 컨피규레이션으로 부터 직접 읽어 올 수 있습니다. customization 데이터는 해당 어플리케이션이 실행중인 클라이언트에 따라 데이터를 가져옵니다. 마지막으로 개인화 데이터는 해당 어플리케이션을 실행중인 사용자 아이디 별로 데이터를 가져옵니다.
그림 5. 계층별 adaptation 데이터 읽음
그림 5는 콘크리트 웹딘프로아밥 컴포넌트에서 계층별 adaptation 데이터 읽는 과정을 예를 들어 보여주고 있습니다. 이 예에서는 N개의 클라이언트와 M개의 사용자가 있음을 가정했습니다. 그림에 강조된 화살표를 따라가 보면 클라이언트는 "Client 1" 과 사용자는 "User M-1" 입니다.
단계 3: 각 계층의 adaptation 데이터를 병합
마지막으로, 앞 단계에서 읽어온 데이터를 병합하여 최종 adaptation 데이터를 만들어 냅니다. 병합의 의미는 configuration 데이터, customization 데이터, 개인화 데이터를 합친다는 뜻입니다. 이 과정은 중요한 점은 적용 우선순위로 개인화 데이터가 가장 높은 우선순위를 가지고 있고 그다음 customization 데이터이고 가장 낮은 우선순위는 configuration 데이터 입니다. 우선순위에 따른 데이터 적용 결정 과정이 CSS (Cascading Style Sheet)의 그것과 매우 유사합니다.
그림 6. 계층 adaptation 데이터 병합을 CSS와 비교
adaptation의 계층 구조 적용은 폭포같은 방법으로 높은 우선순위를 가진 계층이 상속받은 낮은 우선순위 계층의 데이터를 덮어쓰는 방식 입니다. 그리고 최종(final) 표시가 안된것만 이렇게 높은 우선순위가 낮은 우선순위 데이터를 덮어쓰는 방식이 적용됩니다.
이글은 아래 링크의 원본 글에 대한 한글 번역 입니다
https://blogs.sap.com/2014/06/03/adaptation-in-web-dynpro-abap-in-depth-analysis/
