Fetching texts for domain fixed values

[michał_badura]

In ABAP it's quite a common requirement to fetch text to a fixed value from domain, e.g. Customer Production Program for value K of domain RSTAT. How to do it?

 

The classic way of fetching the values, beside selecting them directly from database table DD07T, would be by using function modules DD_DOMVALUES_GET or DDUT_DOMVALUES_GET.

DATA return_code TYPE i.

DATA fixed_values TYPE STANDARD TABLE OF dd07v.

CALL FUNCTION 'DD_DOMVALUES_GET'

  EXPORTING

    domname        = 'YIT_FIXED_VALUES'

    text           = abap_true

  IMPORTING

    rc             = return_code

  TABLES

    dd07v_tab      = fixed_values

  EXCEPTIONS

    wrong_textflag = 1

    OTHERS         = 2.

DATA fixed_values TYPE STANDARD TABLE OF dd07v.

CALL FUNCTION 'DDUT_DOMVALUES_GET'

  EXPORTING

    name          = 'YIT_FIXED_VALUES'

    langu         = ''

  TABLES

    dd07v_tab     = fixed_values

  EXCEPTIONS

    illegal_input = 1

    OTHERS        = 2.

Unfortunately, they're not released for the customers, even though the short text of the first one says External interface… And they're not released for ABAP in Cloud either.

 

So what to do instead? Use RTTS (Runtime Type Services)! With this framework, you can easily fetch fixed values and it can be used for ABAP in Cloud.

DATA fixed_value TYPE yit_de_fixed_values.

CAST cl_abap_elemdescr( cl_abap_typedescr=>describe_by_data( fixed_value ) )->get_ddic_fixed_values(

  EXPORTING

    p_langu        = ''

  RECEIVING

    p_fixed_values = DATA(fixed_values)

  EXCEPTIONS

    not_found      = 1

    no_ddic_type   = 2

    OTHERS         = 3 ).

 

But do this two ways really do exactly the same? Let's see!

 

First difference – for which language texts are read? I have summarized the differences in the table below.

 

	DD_DOMVALUES_GET	DDUT_DOMVALUES_GET	RTTS
Key language not specified	Texts in current language (sy-langu).	Only fix values, no texts, language column is empty.	Texts in language from system profile parameter zcsa/second_language; if the texts are missing for some fixed values, the result will be populated with fixed value (or with the low value, to be more precise) and the language column for these values is empty.
Key language = *	Texts in all languages.	Only fix values, no texts, language column is empty.	Texts in language from system profile parameter zcsa/second_language; if the texts are missing for some fixed values, the result will be populated with fixed value (or with the low value, to be more precise) and the language column for these values is empty.
Valid language key	Texts in specified language; if the texts are missing for some fixed values, the result and the language column for these values are empty.	Texts in specified language; if the texts are missing for some fixed values, the result and the language column for these values are empty.	Texts in specified language; if the texts are missing for some fixed values, the result will be populated with fixed value (or with the low value, to be more precise) and the language column for these values is empty.
Invalid language key	Only fix values, no texts, language column is empty.	Only fix values, no texts, language column is empty.	Texts in language from system profile parameter zcsa/second_language; if the texts are missing for some fixed values, the result will be populated with fixed value (or with the low value, to be more precise) and the language column for these values is empty.

 

As for my understanding, function module DD_DOMVALUES_GET gives the most flexibility. But it has no fallback for the case, when some texts were not found. Function module DDUT_DOMVALUES_GET is used also by RTTS, so I wouldn't use it, unless I would like to implement my own fallback scenario for language key. And this would perhaps make sense, since the fallback scenario implemented by RTTS is not very clear for me. I mean: why is parameter zcsa/second_language used? What about the first language? It could be the parameter zcsa/system_language. But its documentation says in short text: Default logon Language. On the other hand, the documentation for the parameter zcsa/second_language says: The value must be different from the value of 'zcsa/system_language'.

My case:

• zcsa/system_language = 'E'


• zcsa/second_language = 'D'


• Logon language = 'E'

When I now use RTTS with an invalid or initial language key, I will get texts in German, but no texts or texts in English would be more intuitive for me.

 

Besides, function modules provide also counterparts for fetching texts for a single value – DD_DOMVALUE_TEXT_GET and DDUT_DOMVALUE_TEXT_GET. A feature, which is not available by RTTS.

Another feature, which is not available by RTTS, is append indicator – domains based on fixed values can be extended by defining fixed values appends. Whereas RTTS considers all fixed values the same, the function modules set the component APPVAL of the resulting table  to true, if the fixed value was added via an append.
Resulting table of the two function modules defines also two components, which are not clear for me: DOMVAL_LD (Language-specific values for domains, lower limit) and DOMVAL_HD (Language-specific values for domains, upper limit). Maybe it was intended to allow for translation of fixed values too? I'll be glad to hear more about it, so please leave a comment, when you know what are these fields for.

The last difference would be where-used list. Function modules work with the name of a domain. It's not possible, to reference it in the code. But it would be crucial, so that by changes it can be easier spotted whether the change is save. But normally there is some variable with a key, for which text is needed. So one could use RTTS to get the description of this variable and access the domain name dynamically. RTTS on the other hand work with data elements – either directly as variables or with their dictionary names.

DATA fixed_value TYPE yit_de_fixed_values.

CAST cl_abap_elemdescr( cl_abap_typedescr=>describe_by_data( fixed_value ) )->get_ddic_field(

  RECEIVING

    p_flddescr   = DATA(ddic_field)

  EXCEPTIONS

    not_found    = 1

    no_ddic_type = 2

    OTHERS       = 3 ).

IF sy-subrc > 0.

ENDIF.



DATA fixed_values TYPE STANDARD TABLE OF dd07v.

CALL FUNCTION 'DD_DOMVALUES_GET'

  EXPORTING

    domname        = ddic_field-domname

    text           = abap_true

  IMPORTING

    rc             = return_code

  TABLES

    dd07v_tab      = fixed_values

  EXCEPTIONS

    wrong_textflag = 1

    OTHERS         = 2.

DATA fixed_value TYPE yit_de_fixed_values.

DATA fixed_values TYPE STANDARD TABLE OF dd07v.

CALL FUNCTION 'DD_DOMVALUES_GET'

  EXPORTING

    domname        = CAST cl_abap_elemdescr( cl_abap_typedescr=>describe_by_data( fixed_value ) )->get_ddic_field( )-domname

    text           = abap_true

  IMPORTING

    rc             = return_code

  TABLES

    dd07v_tab      = fixed_values

  EXCEPTIONS

    wrong_textflag = 1

    OTHERS         = 2.

 

Summary

In this blog post I showed a way how to access from ABAP the list of fixed values for a given domain. I showed a way for doing it according to the rules and limitations of ABAP in Cloud and described the differences between classic approach with function modules and the new one with RTTS.