Introduction

Texts describe objects in SAP. When texts are language dependent they are are stored in a separate table from the object itself. An example of this would be the Dimension Texts table T006T which gives a text per language for the dimension objects in table T006D.

When the texts are language independent they are usually stored in the same table as the object they describe. For example t001W defines plants along with their name.

In Fiori apps we often use these texts when reporting or when filtering. In many cases the key of the text is of such a technical nature to be of little or no interest to a user. It is therefore important that the user can work with the texts themselves and not (just) the keys.

Examples

Example 1 – Language-Independent Texts

DB Tables

ZJTPHONE contains phones along with their colour. In reality, a particular phone would come in various colours but we’ll assume they only come in one colour. Normally such a table would describe many other attributes of a phone but for our purpose we only have one attribute of a phone – its colour code.

The colour codes themselves are described in table ZJTCOLOR as follows:

CDS Views

We will create a BASIC interface view on top of each of the tables. They are essentially dimension views.  One describes the dimension “Phone” and the other the dimension “colour”.

The phone dimension is described in view Z_I_Phone:

@AbapCatalog.sqlViewName: 'ZIJTPHONE'
@EndUserText.label: 'Phones'
@ObjectModel.representativeKey: 'zphone'
@ObjectModel.semanticKey: ['zphone']
@Analytics.dataCategory: #DIMENSION
@VDM.viewType: #BASIC

define view Z_I_Phone
  as select from zjtphone
    association [0..1] to Z_I_COLOR as _Color
                       on $projection.zcolor = _Color.zcolor
{
    @EndUserText.label: 'Phone'
key zphone,
    @EndUserText.label: 'Colour'
//    @ObjectModel.foreignKey.association: '_Color'

    zcolor,

     _Color
}

Note the @ObjectModel.foreignkey… line is commented out

The colour dimension is described in view Z_I_COLOR:

@AbapCatalog.sqlViewName: 'ZIJTCOLOR'
@EndUserText.label: 'Colours'
@ObjectModel.representativeKey: 'zcolor'
@ObjectModel.semanticKey: ['zcolor']
@Analytics.dataCategory: #DIMENSION
@VDM.viewType: #BASIC
@ObjectModel.resultSet.sizeCategory: #XS

define view Z_I_COLOR
  as select from zjtcolor
{
//     @ObjectModel.text.element: ['zcolortxt']
      @EndUserText.label: 'Colour'
  key zcolor,

      @Semantics.text: true
      zcolortxt
}

Note the @ObjectModel.text.element  line is commented out

We create a consumption view on top of the “Phone” view called Z_C_Phone:

@AbapCatalog.sqlViewName: 'ZCJTPHONE'
@Metadata.allowExtensions:true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Phones'
@VDM.viewType: #CONSUMPTION

define view Z_C_Phone
  as select from Z_I_Phone
{   
  key zphone,

  @Consumption.valueHelpDefinition: [{association: '_Color'}]
  zcolor,

  /* Associations */
  _Color
}

Here we have used the association from the Phone to the Colour table as our value Help for Colour.

VDM

We now have this simple VDM:

Output

After adding relevant UI annotations on the consumption view, creating a service and binding to a List Report we get the following output:

  When using the value help on the colour filter it yields:

Clearly in this situation the colour codes (1,2, and 3) are of no interest to the user who will be thinking purely in terms of the names of the colours.

To Replace the codes in the value help with the colour names we uncomment the following line in the Colour dimension view:

@ObjectModel.text.element: [‘zcolortxt’]

This annotation sets the element “zcolortxt” as the text for the element “zcolor”.

To add the colour description texts to the list report output we uncomment the following line in the phone dimension view:

@ObjectModel.foreignKey.association: ‘_Color’

This annotation sets the association “_Color” as a foreign key for the element “zcolor”.

Rerunning the list report we now get:

Note that the Colour code is retained in brackets in the output of colour. This is extra information that while technical in nature does not distract from the colour description.

Example 2 – Language-dependent texts

When the texts are language-dependent they need to go into a separate table from the dimension with language as a key field.

In this example the phone table is unchanged from above but the colour table must be split into the table that will be used as the colour dimension and the colour text table:

Note that in practice the colour dimension table ZJTCOLOR would have other properties of the colour like perhaps its RGB values and alpha channel value. But for our example it now only holds the colour key plus one new property – a flag that indicates whether the colour is a dark colour.

The new ZJTCOLORTXT table has the colour’s texts in both English and German.

VDM

Our new VDM hierarchy looks as follows:

CDS Views

The dimension view Z_I_COLOR has been reduced to simply the Colour key (zcolor), one attiubute (Is_Dark) plus an exposure of the association to the text table. Note also the annotation @ClientHandling… which instructs the use of the global logon language when linking to the text view. The extra small result category annotation has been commented out as we want to use the new flag IS_DARK to reduce the number of entries returned by the value help and hence no longer want a simple drop-down list.

@AbapCatalog.sqlViewName: 'ZIJTCOLOR'
@EndUserText.label: 'Colours'
@ObjectModel.representativeKey: 'zcolor'
@ObjectModel.semanticKey: ['zcolor']
@Analytics.dataCategory: #DIMENSION
@ClientHandling.algorithm: #SESSION_VARIABLE
//@ObjectModel.resultSet.sizeCategory: #XS

define view Z_I_COLOR
  as select from zjtcolor
     association [0..*] to Z_I_COLORTXT as _Text
              on $projection.zcolor = _Text.zcolor
{
      @ObjectModel.text.association: '_Text'
      @EndUserText.label: 'Colour'
  key zcolor,

      @EndUserText.label: 'Is a dark Colour'
      is_dark,

      _Text
}

The new text view also has annotation @ClientHandling… along with the data category #TEXT.

@AbapCatalog.sqlViewName: 'ZIJTCOLORTXT'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Colour Texts'
@ClientHandling.algorithm: #SESSION_VARIABLE
@ObjectModel.representativeKey: 'zcolor'
@ObjectModel.dataCategory: #TEXT

define view Z_I_COLORTXT
    as select from zjtcolortxt
{
    @Semantics.language: true
key language,
    @ObjectModel.text.element: ['zcolortxt']
key zcolor,

    @Semantics.text: true
    zcolortxt
}

Output

When running the list report the output is identical to before despite the newly added German texts which are ignored due to the logon language being used to restrict results from the text table.

When hitting the drop-down on the value help for colour we now get a popup where we can restrict the colours to those that are dark (would be more useful if we had more than 3 colours!):

As expected, selecting these 2 colours restricts the list report output to phones with dark colours:

Conclusion

By presenting users with object texts instead of just object codes Fiori app developers can produce apps that are more meaningful to users. Both language-independent and language-dependent texts can be catered for at CDS level. Once a CDS dimension view and related text view have been created for a given object these views can be reused whenever the object is used in future app developments.