Skip to Content

ABOUT FIELD DESCRIPTION IN THE CRM WEB UI.

 

The Controller class of the View (the one following the …IMPL pattern) handles various tasks, amongst which the specification of the description text for each field rendered on the View, including table header texts. In the CRM Web UI, starting from CRM 6.0 onwards, the description of a field can have multiple origins.

 

  • When the Attribute of the context node is attached to a BOL object, it is a so called Model Attribute; the defaulted description is inherited from the Data Dictionary of the corresponding structure attached to the BOL Object.
  • When the Attribute of the context node is created locally, meaning in the application, it is so called a Value Attribute; the defaulted description is defined in the Wizard at the time you create this new Attribute.

 

These descriptions are defaulted and can be overwritten in different ways, sequenced hereafter by priority (increasing order).

 

  1. The description can be overwritten in the configuration of the view. A simple yet efficient way to customize your view with the field labels of your organization.
  2. The description can be overwritten by a Design Layer object, a convenient method to maintain a description centrally, across various views or even applications.
  3. The description can be overwritten via the code logic of the view’s Controller class. Though this method requires (a bit of) Abap knowledge, it allows you to play with your description dynamically.

 

This blog approaches the latter way of overriding the description of Attributes.

 

CASE STUDY.

 

In SAP implementations, my thoughts obviously firstly go for less coding as possible, though sometimes like these it can bring even more flexibility in the handling of your application. To illustrate the case, I come up with a customer requirement where a dedicated View contained a list of business transaction documents meant to be maintained altogether; a mass maintainance tool allowing the user to easily adapt the status and the partners of up to 6 partner functions. The tricky part was that the chosen 6 partner functions could be adapted via a customizing table. The column header text could not be stored statically, rather determined according to the setup of the customizing.

 

 

HOW TO.

 

 

  • In the Component Workbench,locate your view, start the configuration and identify the fields for which you need to override the description. Here’s the list of fields (table columns).

//DOCUMENTGRID/STRUCT.PARTNERPF1

//DOCUMENTGRID/STRUCT.PARTNERPF2

//DOCUMENTGRID/STRUCT.PARTNERPF3

//DOCUMENTGRID/STRUCT.PARTNERPF4

//DOCUMENTGRID/STRUCT.PARTNERPF5

//DOCUMENTGRID/STRUCT.PARTNERPF6

 

  • Here’s thecustomizing table we have defined toassign the 6 columnswith therequired Partner Functions.

 

Mapping Table

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Mapping Table Content

 

 

 

 

 

 

 

 

 

 

 

  • In the Component Workbench,locate the controller class of your view. Switch to change mode and create a Public Instance Method called SET_ELEMENT_TEXT.

 

 

New method

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • Code the Methodwith the code hereadter, the logic fetches the description of the Partner function and overrides the columns’ header description with it.

 

 

 

 

  • Redefine the Controller Method DO_VIEW_INIT_ON_ACTIVATION and Insert the call to the method SET_ELEMENT_TEXT.

 

 

RESULT.

 

 

The column headers are overwritten with the description of the respective partner functions as expected.

Result

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Varone Daniele
    hi Christophe,

    In this how-to I do not understand if you create a new view or you change a existant view.

    I have some questions for you:
    1. Do you have created Zdemo or this is a existant table for the view where you want to change the description?

    2. The class builder is a copy of standar class builder?

    Last question:
    is possible to create how-to where you demonstrate how to create a new non-standar view?

    thank’s
    Daniele

    (0) 
    1. Anonymous
      Hello Daniele,

      in this how-to I took a sample custom (new) view to show how you could adapt the description. But this case can be applied to any standard view as well – you must redefine it beforehand.

      In the near future I’ll try to free some time to demo the creation of a new non-standard view.

      Cheers

      (0) 
      1. Varone Daniele
        Thank you for the reply,
        I am new in CRM, i have posted in your blog why I’m trying to create a new nonstandar view.

        Waiting your demo, I make a new asks:

        which of the two is better, for exampre to create a ALV?

        1. create a ABAP report, assign a transaction, use this transaction in a view of CRM.

        2. create a nonstandard view to replicate the same ALV.

        Regards

        Daniele

        (0) 
  2. Carsten Kasper
    Hi Christophe,

    I stumbled across this approach a while ago and decided to not use it.
    In the configuration descriptor class CL_BSP_DLC_CONFIGURATION2 you call method SET_CUSTOM_TEXT(). This method does write an entry into an existing transport request.

    Do you have any experiences how it works on productive systems where there is no transport request?
    Have you any knowledge about the impact on the performance?

    regards
    Carsten Kasper

    (0) 
    1. Anonymous
      Hello Carsten,

      the solution described is bullet-proof including on this perspective, the tool is used in several productive environments without any problem or similar circumstances. Regards.

      (0) 

Leave a Reply