General
In List ATS UIBB and Tree UIBB there is the possibility for the user to create variants and to switch between variants (aka views). It is necessary to enable this functionality by configuration (section general settings). A variant contains the UI properties such as the columns that shall be displayed, how the columns shall be sorted, grouped, filtered and aggregated and also information about conditional formatting and export options.
Special variants
There exist two special variants: The standard variant and the default variant. The standard variant is always there and mirrors the UI properties as they have been in the List UIBBs original configured state. Then there is the default variant. This is an attribute that can be assigned to one arbitrary variant. The default variant will be applied every time the application is started.
WD ABAP configuration layers
The variants are stored by utilizing the WD ABAP configuration framework. Thus there are three different layers where the variants can be stored.
- Personalization layer: This is the default. All variants created in this mode are user specific.
- Customizing layer: To activate this layer add the URL parameter sap-config-mode=X. This is meant for the administrator. Variants created in this mode will be available for all users. It is only available with corresponding authorization.
- Configuration layer: To activate this layer add the URL parameter sap-config-mode=config. This is meant for the developer to ship variants. Variants created in this mode will be available for all users. It is only available with corresponding authorization.
FIORI UI guideline
The FIORI UI guideline has been implemented for the List ATS UIBB personalization and with that come some changes in the handling of variants. When a variant is changed there appears an asterisk behind the name of the variant (signalizing unsaved changes). The save button has moved from the personalization dialog to the new popover that appears when clicking the variant name. That popover is used to choose variants and to access a new dialog for managing variants.
Changes to the standard variant (and customized and configured variants as well) cannot be saved therefore the “reset to default” button is not necessary anymore. Instead one can make changes to the standard variant and then use the “save as” button to create a new variant.
Dynamic variants
There exists the feature of dynamic configurations, i. e. the configuration is done by feeder class method IF_FPM_GUIBB_LIST~GET_DEFAULT_CONFIG( ). In such a case it is possible to raise the FPM standard event CL_FPM_EVENT=> GC_EVENT_INVALIDATE_UIBB. When this happens the UIBB is rebooted and method IF_FPM_GUIBB_LIST~GET_DEFINITION is called again. This also gives the feeder class the chance to use a different field catalog all together. The problem that might arise here is that the same personalization variants are used for different field catalogs. In order to avoid this the feeder class developer can provide an application specific key. This key then is used to distinguish the scenarios and separate the variants. This key is provided also via the configuration API, method SET_APP_KEY( ). There exists a demo application, the application configuration ID is FPM_TEST_LIST_ATS_DYN_PERSO_AC.
Shared variants in the List ATS
With NW release 7.53 or cloud release 1808 the personalization is extended with the new feature of Shared Variants. The idea is to allow power users with certain authorizations (authorization object S_WDR_ADM with activity ‘06’ or S_WDR_P13N) to share their personalization variants with other users, without having to create them in the customizing layer of a customizing system and transporting them.
In the manage variants dialog shared variants appear as type global for normal users and as type shared variants for users with sharing authorizations.
