Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
michał_badura
Participant
6,043
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.
2 Comments
Labels in this area