Skip to Content

Dynamic assignment of component configuration using Floor plan Manager

In general, all the component configurations that we create for the Webdynpro components, we tend to assign it statically using component configuration in the application configurator of the Floor Plan Manager(FPM).


I was thinking how to make dynamic assignment of such configurations. This blog will explain you how to make dynamic  assignment of component configurations.


I have created a sample Webdynpro component using the flight information for the above scenario. The application will display different Webdynpro view based on the system user name.


I have created two Webdynpro component configurations for the Webdynpro component ZFLIGHT_LIST.





In the Component configuration ZFLIGHT_LIST_ONE, I have removed the search button. In ZFLIGHT_LIST_TWO, I removed the department city label and input box.



Every time  when I used the Object instance floor plan, I always made the static assignment as shown below.




I removed the static assignment of the component configurations in FPM and used the below logic to dynamically assign the component configurations based on the system user name.



DATA:  lo_api_controller       TYPE REF TO if_wd_component,
          lo_pers_manager      TYPE REF TO if_wd_personalization,
          ls_config_key           TYPE wdy_config_key.

           lo_api_controller = wd_comp_controller->wd_get_api( ).

           lo_pers_manager = lo_api_controller->get_personalization_manager( ).

        IF sy-uname EQ ‘USER1’.

                 ls_config_key-config_id = ‘ZFLIGHT_LIST_ONE’ .
                 lo_pers_manager->load_config_by_key( ls_config_key ).
                 ls_config_key-config_id = ‘ZFLIGHT_LIST_TWO’ .
                 lo_pers_manager->load_config_by_key( ls_config_key ).



 After dynamic assignment for USER1,







After dynamic assignment for USER2, 





 S.Rajkumar . 

You must be Logged on to comment or reply to a post.
  • The approach that is described above is really strange if it is used in order to modify the OIF application dynamically at runtime. I would not recommend it. It works only in the case of free-style UIBBs anyway.

    A better way of influencing the FPM application at runtime would be to use the OIF API IF_FPM_CNR_OIF or IF_FPM_OIF. With these APIs you can add, remove or change toolbar elements of the OIF, or add or remove main views, sub views, or UIBBs to/ from the OIF. In order to remove fields dynamically at runtime a good approach would be to use the FPM Form GUIBB and modify the field properties of the form fields at runtime via the form feeder class.

    • Jens,

      Thanks for your recommendation. I came across the requirement to include a new component configuration in the standard e-recruitiment applications as i don’t want to make any changes in the standard component configurations or enhance the standard class. Moreover in the standard e-recruitment webdynpro component it didn’t have the interface IF_FPM_CNR_OIF and moreover as you know, you cannot implement the new interface in in the standard component . Thus it made me to think the other way. Only few will understand if i show the e-recruitment changes using FPM that i developed using the enhancement framework and thus i expressed the same using a simple flights table.

      • Thank you for your explanations, Rajkumar. Let me add a few comments just for the sake of completeness…

        The OIF component configuration enables the specification of an Application Configuration Controller (AppCC). If such an AppCC is not specified in the standard OIF component configuration of your e-Recruitment application you can create a configuration enhancement (or customizing, if it is sufficient to be client-dependent) for the OIF component configuration and specify the AppCC there. You need not to enhance a standard class for this. The AppCC has to implement interface IF_FPM_OIF_CONF_EXIT. In its interface method OVERRIDE_EVENT_OIF an instance of IF_FPM_OIF will be passed. With this instance you can modify the OIF floorplan at runtime.

        In addition, an instance of interface IF_FPM_CNR_OIF is accessible everywhere, be it in an AppCC or in a GUIBB feeder class. In the paragraph above I explained how to can add an AppCC to the standard OIF component configuration in a modification-free way. In order to use your own coding modification-free in a standard feeder class delivered by SAP you can either enhance the standard feeder class or create a configuration enhancement (or customizing, if it is sufficient to be client-dependent) for it in which you can then specify your own feeder class.

        By the way, as of NW 7.31 the FPM offers another adaptation possibility, the so-called Context-Based Adaptations (CBAs). It allows to adapt an application at runtime depending on any application-specific context (for example, depending on the user role, country, industry, etc.).

  • hi Rajkumar Shanmuganathan, I am think whether we can get the configuration at run-time, then change it during run-time? So we do not need to load different configuration but set the configuration dynamically?

    • Hi Cain Sun,

      Yes we can get the configuration at the run time.

      The Code displayed above helps you to set the configuration at the run time.

      DATA:  lo_api_controller       TYPE REF TO if_wd_component,
                   lo_pers_manager      TYPE REF TO if_wd_personalization,
                   ls_config_key           TYPE wdy_config_key.

                 lo_api_controller = wd_comp_controller->wd_get_api( ).

                 lo_pers_manager = lo_api_controller->get_personalization_manager( ).

              IF sy-uname EQ ‘USER1’.

                       ls_config_key-config_id = ‘ZFLIGHT_LIST_ONE’ .
                       lo_pers_manager->load_config_by_key( ls_config_key ).
                       ls_config_key-config_id = ‘ZFLIGHT_LIST_TWO’ .
                       lo_pers_manager->load_config_by_key( ls_config_key ).



  • Hi Rajkumar,

    I tried to redo your steps but I’m facing some problems here.

    As you know one application config. needs at least 1…n component configurations.

    My component-configurations are in a separated folder(not in web-dynpro-components).

    So by executing your code nothing happens. Also I can’t remove the static component-configuration from the application-configuration, because it needs at least one.

    I was thinking if there is a way to get the component-configurations from another folder and with that I should be able to change the component-configuration right? Do you have a solution for this problem?

    I also created a question, if you want to refer to this: The specified item was not found.


    S. Atith