Skip to Content

Dynamic fields in WebUI using GET_A method (no new configuration needed)

Hi community,

Yesterday i’ve found a nice way to show/hide fields dynamically in WebUI!!

The first idea that occurred to me was to create 2 different configurations, one with the field and the other without… Then go to method DO_CONFIG_DETERMINATION and select the correct configuration according to the logic that i wanted…

For me, this is not the right approach! WHY? imagine a requirement where we have 10 dynamic fields:

For 1 dynamic field, we need 2 configurations;

For 2 dynamic fields, we need 4 configurations;

I’ve tryed to find a new solution using different foruns and blogs but unsucessfully… and then i’ve found the light (:P)

My solution is based on the creation of a custom Switch and Business Function, and used them in the BSP application (using method GET_A to change the visibility). Please check the following example:

Go to transaction BSP_WD_CMPWB, open Component SRQM_INCIDENT_H and view IncidentHeaderEF.

Let’s assume that we want to show/hide field “status” (LCSTATUS) from context node BTADMINH.

Note: All the objects should be enhanced!


The objective is to hide field LCSTATUS:


Now i will describe the steps to hide the field:

  • Create Switch using SFW1:


  • Create Business Function using SFW2:


  • Create Business Function Set using SFW3:


  • Activate Business Function in SFW5
  • Go to SM30 and open CRMV_GIL_COMP_AT:


  • In this view, we will set the attributes from BOL Objects with a switch ID and visible or not (check on GENIL_MODEL_BROWSER):


  • Now the BOL attribute has a switch ID. Next step is to maintain the visibility in the view of the component. This should be done in method GET_A of the attribute (in this case LCSTATUS):


  • If we open the WebUI, the field status should be hidden:


IMPORTANT NOTE: this will not work for extensions in AET!!! the standard will not go through GET_A of the attribute.

The reason why is because the name of the attribute starts with “EXT.”…

To solve that a new method should be created in the class of the context node:



Hope this can solve some problems that both have in SAP CRM 😀

You must be Logged on to comment or reply to a post.
  • Thanks for your effort on sharing this with the community, but, don't you think the switch framework is not mean to do stuff "bigger" than hide fields? 🙂



    • Hi Luis ,

      I completely agree with you on this one 🙂

      I can extend this blog with the info that it's not necessary to make changes to the switch. You can simply re-define the GET_A method of the field and pass the output field REACTION = ' H'


      • yuup I already saw implementing GET_A approch in some scn discussions and to be honest I don't like this approach either, I mean, I understand having 10000 configurations is hard to maintain and not very flexible, overwrite a GET which is meant for the switch framework is also a "dirty trick" and if we speak in the OO paradigm you have highly chances to violate it, its very easy,common, find you don't have enough criteria to hide the attribute X without considering the attribute Y and last but not least you lose the SAP support 🙁

        Let's face it, the WebUI framework doesn't have the flexibility in a task which the users and developers are used to, LOOP AT SCREEN. so what we can do?  I could agree on a method in the context node which is mean to hide/show fileds dinamically like the GET_I, but we don't have that so...let's go to our friend GET_A...hmmmm...not good.

        I've seen Andrei's and Nitish blogs:

        Dynamic modification of Configuration fields ( Part -1) : Form View

        Form Iterator and How It Should Be Cooked

        Form iterator. Reviewing mistakes.

        I never tried it but looks like a clearer approach to me, if we implement something is not in the standard at least let's do it offically 😉



        PD: This is a very nice topic and as we don't have a SAP best practice about this, it will be cool if we try to "standardize" with the help of the experience of ht community 🙂

  • Hey André, thank you, for the tutorial, it have help us passing from allot of ui configuration, just to hide a simple field, to a really simple development.

    Yes switch framework do allot more than hide fields, but in the meantime i can use it to simple my code/program, and just redefining the method get_A will not work..

  • Good document...However, I don't like this way of SAP making a field invisible through GET_A. The main problem is the space. For instance, if I need to make 10 fields unavailable on the screen, the space for those 10 fields will still be there as a blank area. This doesn't look good.

    I believe, there is no other better way other than creating different configurations if you want to hide fields.