Introduction
The adaptation of Web Dynpro ABAP applications is a core concept in Web Dynpro ABAP technology and the cornerstone of the Floorplan Manager for Web Dynpro ABAP framework which, according to the most recent SAP guidelines, is the recommended technology to develop business applications and design user interfaces. The adaptation of Web Dynpro ABAP components and applications is provided by means of the Web Dynpro ABAP Configuration Framework.
This document aims to explain the Web Dynpro ABAP adaptation concept from a very detailed and technical point of view. In the topic handled, the terminology used contains similar terms and it is very important to understand subtleties of the language used; for example, although they may seem synonymous, the terms adaptation, configuration, customization and personalization represent very different concepts which are essential to grasp.
Adaptation hierarchy and adaptation layers
Despite its name, WDA Configuration Framework has to do with adaptations and not just configurations. Web Dynpro ABAP adaptation can be classified in two ways. On the one hand, there is a hierarchical classification that divides adaptation in three layers: configuration, customization and personalization; on the other hand, adaptation comes in two flavors: built-in adaptation and component-defined adaptation.
Figure 1. Adaptation hierarchy showing built-in and component-defined adaptation data
The picture depicted in the figure represents the well-known Web Dynpro ABAP adaptation hierarchy, a vertical division of the adaptation concept in three hierarchical adaptation layers. This stack includes also an horizontal division that divides each layer two-fold into built-in adaptation data and component-defined adaptation data. Customization is sometimes called administrator personalization.
Responsible for maintenance
Normally, configuration data is mantained by a developer/programmer, customization data is mantained by system administrators and personalization data is directly handed by users. Here, developer means any user with authorization S_DEVELOP and administrator means any user with, at least, authorization S_WDR_P13N.
Data layer priorities
Personalization data has the highest priority of them all, followed by customization data and configuration data. This means that, by default, configuration data can be overrided by customization data and that both of them can be overrided by personalization data. However, each attribute adapted in the configuration data layer or in the customization data layer can be set as final, which means that this concrete attribute cannot be further adapted in a higher adaptation data layer.
Data layer scope
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 data and component-defined adaptation data
The built-in adaptation data are the adaptation data directly provided by Web Dynpro ABAP Configuration Framework. This kind of data is applicable in the same way to every Web Dynpro component, without considering the semantics of each component. This kind of adaptation can be seen as generic adaptation, allowing basically to change the metadata of the UI elements (visibility, texts, and so on).
Every WDA component can define another kind of adaptation data, the component-defined adaptation data. To define this, a WDA component has to use a configuration controller which defines the exact attributes that can be adaptable for the component. This kind of adaptation data is component specific, considering the semantics of the component itself.
Adaptation data instance concept
In order to lay foundation on the concepts discussed here, although these are not globally accepted terms, we can say that a concrete adaptation data that applies to a concrete Web Dynpro ABAP component instance is an adaptation data instance, which contains a single configuration data instance, many customization data instances as system clients and many personalization data instances as users in the system. Keeping this in mind, the previous figure 1 can be elaborated to depict in detail a concrete adaptation data instance with all its layer instances.
Figure 2. Adaptation data instance concept
As stated before, the figure 2 shows a single configuration data instance (system), multiple customization data instances (clients) and multiple personalization data instances (users). At runtime, however, the Web Dynpro Configuration Framework must be able to grasp only one customization data instance and only one personalization data instance; this will be examined later in Determining adaptation data process at runtime.
Adapting a Web Dynpro ABAP component - The Component Configuration object
Every Web Dynpro ABAP component can be adapted by means of WDA Configuration Framework. Multiple adaptation instances may exist for a certain Web Dynpro ABAP component in a SAP system. Each adaptation data instance is stored in a specific object known as component configuration; again, the name is a bit unfortunate because the object includes full-adaptation data and not only configuration data. A component configuration object is identified by a unique configuration ID.
Since each Web Dynpro ABAP component can have multiple adaptation instances, it can be adapted by multiple component configurations; on the other hand, a component configuration can only include an adaptation instance, which is related to one Web Dynpro ABAP component.
Normally, the adaptation process for a concrete Web Dynpro ABAP component starts with the creation of a component configuration by a developer, but this is not the only case; a component configuration can be implicitly provided by the system. This lead us to distinguish two types of component configuration objects:
- Explicit component configuration, is a "TADIR" object, mantained in the ABAP repository and transportable via a workbench request. These are created by a developer from the ABAP workbench as any other development object. They must be assigned a configuration ID in the customer namespace. Once they are created, the explicit component configurations contain a whole adaptation data instance: configuration data, customization data and personalization data.
- Implicit or generic component configuration, these are not repository objects and they are implicitly created by Web Dynpro ABAP Configuration Framework when needed. Their configuration IDs, generated automatically, consist of alphanumeric characters and are not in the customer namespace. Implicit component configurations cannot include any configuration data or component-defined adaptation data, they can only include built-in customization data and built-in personalization data. Web Dynpro Configuration Framework is able to mantain a generic component configuration for each different combination of WDA application name and WDA component instance / usage. Check Determining adaptation data process at runtime below for more details on this.
Mantaining adaptation data in a Component Configuration object
Adaptation data instance data can be inserted and mantained in the component configuration object. Each layer is mantained by different ways:
- Configuration data, can be mantained only for explicit component configurations using the Configuration Editor Tool. This tool is accessed by means of the standard Web Dynpro ABAP application CONFIGURE_COMPONENT (which launches WDA component WDR_CFGE_EDITOR). Of course, this can be done at design time by executing this application; at runtime, configuration cannot be done unless the executed application includes any option that allows to launch the Configuration Editor Tool (for example, Floorplan Manager framework allows to configure FPM applications runtime).
- Customization data, can be mantained using the Customization Editor Tool. The Customization Editor Tool is accessed by means of the standard Web Dynpro ABAP application CUSTOMIZE_COMPONENT (which launches component WDR_CFGE_EDITOR). Of course, this can be done at design time by executing this application; at runtime, the Web Dynpro ABAP Configuration Framework provides access to this tool if the executing WDA application is executing in administrator mode. To execute a WDA application in administrator mode use the URL parameter sap-config-mode=x. Remember that the adaptation of customization data applies only to a concrete system client.
- Personalization data, can only be mantained at runtime, and only if the personalization is not disabled. Each user can only mantains its own personalization data, that is, the personalization data instance associated to him. At runtime, Web Dynpro ABAP Configuration Framework only provides options to maintain built-in personalization data, so if you need to personalize component-defined data specific component controls must be developed to allow the users at runtime to personalize component-defined data. Personalization can be disabled at runtime using WDA application parameter WDDISABLEUSERPERSONALIZATION.
Below, a table summary is shown of how to adapt a Web Dynpro ABAP component.
ADAPTATION MATRIX | Configuration | Customization | Personalization |
|---|---|---|---|
| Built-in | Runtime: no standard support. Design time: can be made using WDA application CONFIGURE_COMPONENT. Only for explicit component configurations. | Runtime: can be made directly using contextual menu when execution is in administrator mode. Design time: can be made using WDA application CUSTOMIZE_COMPONENT. Only for explicit component configurations. | Runtime: can be made directly using contextual menu when execution is not in administrator mode and WDA application does not include parameter WDDISABLEUSERPERSONALIZATION. Design time: no standard support. |
| Component-defined | Runtime: no standard support (although available in Floorplan Manager). Design time: can be made using WDA application CONFIGURE_COMPONENT. Only for explicit component configurations. | Runtime: can be made directly using contextual menu when execution is in administrator mode. Design time: can be made using WDA application CUSTOMIZE_COMPONENT. Only for explicit component configurations. | Runtime: no standard support. This has to be developed in the component to allow personalization of component-defined data at runtime. Design time: no standard support. |
The Application Configuration object
The application configuration objects are very important in the adaptation schema. They are created in the ABAP workbench and are always associated to a unique WDA application. Each Web Dynpro ABAP application can have any number of application configurations associated, from none to many. The application configuration objects are repository objects stored in TADIR table as type WDCA objects. Each application configuration is uniquely determined by a configuration ID.
An application configuration object acts as a roadmap that defines which component configuration objects must be used to adapt each one of the Web Dynpro ABAP component instances used and triggered by the WDA application it is related to. It is not mandatory that an application configuration defines a component configuration for every WDA component used by the application, leaving Web Dynpro Configuration Framework to determine a generic component configuration for every component with no component configuration explicitely defined in the application configuration.
Each time a WDA application is executed, it can be executed in the context of one of its defined application configurations or it can be executed in a generic way without any application configuration at all. In the latter case, each WDA component used during application execution will use a generic component controller for adaptation purposes, unless a component configuration is set dynamically (see below in Setting Component Configuration dynamically at runtime). Conversely, WDA applications running in the context of an application configuration can determine the component configuration for each WDA component that is executed.
Together with component configurations, application configurations are the heart of Floorplan Manager technology framework.This technology is directed towards adaptation of standard WDA components (floorplan components), and not to the entire development.
Although not advisable, in any WDA component it is allowed to have component configuration IDs that coincide with application configuration IDs.
When a WDA application is launched, there are two ways to set an application configuration:
- Using URL parameter SAP-WD-CONFIGID and setting its value to the application configuration ID. If the configuration ID is correct and there is an application configuration with that ID, then the WDA application is run in the context of the application configuration; otherwise, the WDA application is executed with no application configuration associated.
- If the URL does not contain parameter SAP-WD-CONFIG, the framework checks for WDA application parameter WDCONFIGURATIONID. If parameters exists, then its value is used to search an application configuration with that configuration ID. Again, if there is an application configuration with that ID, then the WDA application is run in the context of the application configuration; otherwise, the WDA application is executed with no application configuration associated.
Application configuration object definitions are stored in table WDY_CONFIG_APPL.
Setting Component Configuration dynamically at runtime
At design time, in an application configuration only component configurations can be set for statically defined component usages. Suppose a WDA application that creates WDA component usages dynamically by demand; in this case, the application configuration is not capable to determine the component configurations for these dynamically created WDA components. However, using ABAP code it is possible to set component configurations to WDA component instances at runtime. In fact, this is how Floorplan Manager framework does to set UIBBs (User Interface Building Blocks) component configurations at runtime (although it takes this information from the adaptation data set at design time in the floorplan component).
For example, a WDA component can set its own component configuration object in WDDOINIT lifecycle method as the following sample code shows:
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.
In the above example, the WDA component establishes at runtime that its assigned component configuration is ZWD_DFC_1_COMP_CONFIG_2.
Transporting adaptation data
The possibilities and considerations on transport of adaptation data depend on the concrete adaptation layer. Personalization data cannot be transported at all, as these are intended to work for concrete users in a concrete environment. Customization data can be transported if needed, and the transportation can be done by means of a workbench request or a customizing request (recommended). Finally, the configuration data must be transported using a workbench request.
The transport of adaptation data normally includes the transport of data from tables WDY_CONF_USER, WDY_CONF_USERT, WDY_CONF_USERT2 and WDY_CONF_UDEF. Application configurations are transported in a workbench request, and changes are included in table WDY_CONFIG_APPL.
Determining adaptation data process at runtime
At runtime, the Web Dynpro ABAP Configuration Framework determines the adaptation data that must be applied to each running WDA component instance. This can be seen as the three-step process shown in figure 3.
Figure 3. Runtime determination of the adaptation data for each running WDA component instance
In the first step, the Web Dynpro ABAP Configuration Framework determines the configuration ID of the component configuration object which adaptation data must be retrieved. Next, in the second step, adaptation data from each adaptation layer must be fetched, taking into account runtime client and user. Finally, in the third and last step, all the adaptation instance layer data is merged and combined into the final adaptation data that must be applied to the Web Dynpro ABAP component instance. Each step of the process is explained in detail below, always considering a single WDA component.
Step 1: Get component configuration object
At runtime, the Web Dynpro ABAP Configuration Framework determines which component configuration must be used for each WDA component instance that is executed. For each WDA component instance, all the adaptation data is read from its associated component configuration at runtime and all the adaptations made to the instance at runtime are stored in that component configuration. For each running WDA component, Web Dynpro Configuration Framework checks if a configuration ID has been set for it. The configuration ID can be set at design time by the application configuration in use or dynamically at runtime by ABAP code. If no configuration ID is defined for a WDA component instance or the configuration ID is wrong, then the framework determines a generic component configuration object.
Determining a generic component configuration
At runtime, if a particular WDA component instance does not have a valid configuration ID, the Web Dynpro ABAP Configuration Framework has to determine a generic component configuration for it. In this case, a generic configuration ID must be determined by the framework. The ID is determined by applying a hash function to the combination of the WDA application name and the specific WDA component instance usage.
Figure 4. Determining configuration IDs for generic component configurations
Figure 4 depicts a runtime scenario with a WDA application ZWD_APPL that launches WDA component ZWD_MAIN. This component defines two WDA component usages: usage USAGE_1 for component ZWD_COMP1 and usage USAGE_2 for component ZWD_COMP2. The Web Dynpro ABAP application ZWD_APPL does not get executed in the context of any application configuration and there are not any dynamic setting of component configurations, so Web Dynpro ABAP Configuration Framework has to determine a generic component configuration for each WDA component instance usage, that is, for main component (ZWD_MAIN), usage USAGE_1 (ZWD_COMP1) and usage USAGE_2 (ZWD_COMP2). As stated previously, the configuration IDs determined are not in customer namespace and are a complex combination of alphanumeric characters. It is important to emphasize that the determined configuration IDs will be the same in each execution, unless the application name or the usage names are changed. The names of the WDA components does not affect in the determination of the configuration IDs, but the usage names (USAGE_1 and USAGE_2); this means that if the WDA component is changed for USAGE_1, for example from ZWD_COMP1 to ZWD_COMP_OTHER, the configuration ID will be determined the same.
Step 2: Fetch adaptation data
The next step is about retrieving the adaptation data from the component configuration object determined in the previous step. In this step, the data is obtained for each adaptation layer separately. The configuration data is directly obtained from the unique configuration data instance in the component configuration. The customization data is obtained from the customization data instance that is related to the client in which the application is getting executed. Finally, personalization data is obtained from the personalization data instance associated to the user running the application.
Figure 5. Fetching adaptation data layer
Figure 5 show an example of a runtime scenario that depicts the adaptation data layer retrieval for a concrete WDA component. The example is based on a N-clients system and M users. Following the highlighted path, we can suppose that the execution client is "Client 1" and the user is "User M-1".
Step 3: Combine adaptation data
Finally, the data fetched in the previous step have to be combined and merged to obtain the final adaptation data result set that will apply to the Web Dynpro component. This merging is about mixing configuration data, customization data and personalization data. In this process is very important to remember that personalization data are those with the highest priority of all, followed by customization data and, with the lowest priority, the configuration data. If we compare this cascading scheme with the style sheet language CSS (Cascading Style Sheet) used for describing the look and formatting of a HTML document we can discover many similarities.
Figure 6. Comparing adaptation data-layer merging with cascading style sheets
The adaptation data layers are applied in cascading-like methodology with higher priority layers overriding inherited data from lower priority layers. Remember that a higher priority adaptation data layer instance can only override the inherited adaptation data that is not declared as final.
- SAP Managed Tags:
1 Comment
