38 KiB
Dynamic Programming
Notes on Dynamic Programming
-
Regarding "dynamic" in contrast to "static" aspects, ABAP programs can include both dynamic and static parts.
-
Consider a data object in your program:
-
It can be declared as a static data object, i. e. you provide all attributes by specifying the data type and more statically in the code.
"Internal table declaration DATA itab TYPE TABLE OF zdemo_abap_carr WITH EMPTY KEY. -
The name
itabof the data object is determined at compile time and remains stable throughout the execution of the program.
-
-
However, there can also be use cases where the attributes of such a data object are not statically determined. This is where dynamic aspects enter the picture: Attributes, names, types etc. are not determined at compile time but rather at runtime.
-
There are ABAP statements that include these dynamic aspects in the syntax. Assume you have a simple program and a UI that includes an input field storing the input in a data object named
dbtab. As input, you expect the name of a database table to be provided. In the end, you want to retrieve all entries of the database table and store them in an internal table. This table should be displayed. So, there is random input at runtime and your program must be able to deal with it.-
See the following
SELECTstatement. As also shown further down, theFROMclause does not include a statically defined table to be selected from. Instead, there is a pair of parentheses including a data object. Assume the data object holds the name of the database table. At runtime, the data retrieval happens from the database table that was inserted in the input field.DATA(dbtab) = `ZDEMO_ABAP_FLI`. SELECT * FROM (dbtab) INTO TABLE @DATA(some_itab).
-
-
Further aspects for dynamic programming in ABAP enter the picture if you want to determine information about data types and data objects at runtime (RTTI) or even create them (RTTC).
-
In general, dynamic programming also comes with some downsides. For example, the ABAP compiler cannot check the dynamic programming feature like the
SELECTstatement mentioned above. There is no syntax warning or suchlike. The checks are performed at runtime only which has an impact on the performance. Plus, the testing of procedures that include dynamic programming features is difficult.
Excursion: Field Symbols and Data References
Field symbols and data references are dealt with here since they are supporting elements for dynamic programming.
Field Symbols
Field symbols ...
- are symbolic names for almost any data object or parts of existing data objects.
- can be assigned actual memory areas at program runtime (using
ASSIGN). Note that you can only work with the field symbols if indeed they have been assigned before. - can be used as placeholders for a data object at an operand position.
- Consider there is a data object in your program. A field symbol is also available that is assigned the memory area of this data object. Accessing a field symbol is like accessing the named data object or part of the object itself.
- do not reserve physical space in the data area of a program like a data object. Instead, they work as dynamic identifiers of a memory area in which a specific data object or part of an object is located.
- can be typed either with generic data types or complete data types.
- are declared using the statement
FIELD-SYMBOLSor the declaration operatorFIELD-SYMBOL. Their names must be included between angle brackets.
Declaring field symbols
Syntax:
"Declaring field symbols using the FIELD-SYMBOLS statement
"and providing a complete/generic type
"Examples for complete types
FIELD-SYMBOLS: <fs_i> TYPE i,
<fs_fli> TYPE zdemo_abap_fli,
<fs_tab_type> TYPE LINE OF some_table_type,
<fs_like> LIKE some_data_object.
"Examples for generic types
FIELD-SYMBOLS <fs_data> TYPE data.
FIELD-SYMBOLS <fs_any_table> TYPE any table.
"Declaring field symbols inline
"The typing of the field symbol is determined using the statically
"known type of the assigned memory area.
"Prominent use case: Inline declaration of a field symbol for an internal table.
LOOP AT itab ASSIGNING FIELD-SYMBOL(<line>).
...
ENDLOOP.
💡 Note
- After its declaration, a field symbol is initial, i. e. a memory area is not (yet) assigned to it (apart from the inline declaration). If you use an unassigned field symbol, an exception is raised.
- There are plenty of options for generic ABAP types. A prominent one is
datathat stands for any data type (the older generic typeanyhas the same effect). See more information in the topic Generic ABAP Types.- Field symbols cannot be declared in the declaration part of classes and interfaces.
Assigning data objects
ASSIGN
statements assign the memory area of a data object to a field symbol.
Once the memory area is assigned, you can work with the content.
"Some data object declarations to be used
DATA: num TYPE i,
struc TYPE zdemo_abap_fli, "Demo database table
tab TYPE string_table.
"Declaring field symbols with complete types
FIELD-SYMBOLS: <fs_i> TYPE i,
<fs_struc> TYPE zdemo_abap_fli,
<fs_tab> TYPE string_table.
"Declaring field symbols with generic type
FIELD-SYMBOLS <fs_gen> TYPE data.
"Assigning data objects to field symbols
"Note: In this case, the field symbols have an appropriate type.
ASSIGN num TO <fs_i>.
ASSIGN struc TO <fs_struc>.
ASSIGN tab TO <fs_tab>.
ASSIGN num TO <fs_gen>. "Could be any of the data objects
"Inline declaration is possible, too. The type
"is automatically derived.
ASSIGN num TO FIELD-SYMBOL(<fs_inl>).
"CASTING addition for matching types of data object and field symbol
"when assigning memory areas
TYPES c_len_3 TYPE c LENGTH 3.
DATA(chars) = 'abcdefg'.
FIELD-SYMBOLS <fs1> TYPE c_len_3.
"Implicit casting
ASSIGN chars TO <fs1> CASTING.
FIELD-SYMBOLS <fs2> TYPE data.
"Explicit casting
ASSIGN chars TO <fs2> CASTING TYPE c_len_3.
💡 Note
- If you use an unassigned field symbol, an exception is raised. Before using it, you can check the assignment with the following logical expression. The statement is true if the field symbol is assigned.
IF <fs> IS ASSIGNED. ... ENDIF.- Using the statement
UNASSIGN, you can explicitly remove the assignment of the field symbol. ACLEARstatement only initializes the value.UNASSIGN <fs>.- See more information on the addition
CASTINGhere.
Field symbols in use
"For example, in assignments
DATA num TYPE i VALUE 1.
FIELD-SYMBOLS <fs_i> TYPE i.
ASSIGN num TO <fs_i>.
<fs_i> = 2.
"The data object 'num' has now the value 2.
"Loops
"Here, field symbols are handy since you can avoid an
"actual copying of the table line to boost performance.
SELECT *
FROM zdemo_abap_fli
INTO TABLE @DATA(itab).
FIELD-SYMBOLS <fs1> LIKE LINE OF itab.
LOOP AT itab ASSIGNING <fs1>.
<fs1>-carrid = ... "The field symbol represents a line of the table.
<fs1>-connid = ... "Components are accessed with the component selector.
"Here, a new value is assigned.
...
ENDLOOP.
"Inline declaration of field symbol
LOOP AT itab ASSIGNING FIELD-SYMBOL(<fs2>).
<fs2>-carrid = ...
<fs2>-connid = ...
...
ENDLOOP.
Data References
Data references ...
- are references that point to any data object or to their parts (for example, components, lines of internal tables).
- are contained in data reference variables in ABAP programs.
- are data objects that contain a reference.
- are "opaque", i. e. the contained references cannot be accessed directly. To access the content, these variables must be dereferenced first.
- are deep data objects like strings and internal tables.
- are typed with the addition
REF TOfollowed by a static type. Note the dynamic type in this context: The dynamic type of such a variable is the data type to which it actually points. This concept is particularly relevant in the context of assignments (see the assignment rules here). - can be typed with a complete or generic type. However, only
datacan be used as generic type.
💡 Note
Object references and object reference variables are not part of this cheat sheet. To get more details, refer to the ABAP Keyword Documentation or the cheat sheet ABAP Object Orientation.
Declaring data reference variables
"Example declarations of data reference variables
"Note that they do not yet point to a data object.
DATA: ref1 TYPE REF TO i, "Complete data type
ref2 TYPE REF TO some_dbtab, "Complete data type
ref3 LIKE REF TO some_data_object,
ref4 TYPE REF TO data. "Generic data type
Creating data references to existing data objects using the
reference operator
REF.
"Declaring a data object
DATA num TYPE i VALUE 5.
"Declaring data reference variables
DATA ref1 TYPE REF TO i.
DATA ref_gen TYPE REF TO data.
"Creating data references to data objects.
"The # sign means that the type is derived from the context.
ref1 = REF #( num ).
ref_gen = REF #( num ).
"You can also use inline declarations to omit the explicit declaration.
DATA(ref2) = REF #( num ).
"You can explicitly specify the data type after REF.
DATA(ref3) = REF string( `hallo` ).
"The older syntax GET REFERENCE having the same effect should not be used anymore.
"GET REFERENCE OF num INTO ref1.
"GET REFERENCE OF num INTO DATA(ref4).
Creating new data objects at runtime: You create an anonymous
data object
at runtime by assigning the reference to the data object of a data reference variable. You can use the instance
operator
NEW.
It replaces the older syntax CREATE DATA. However, as shown further, CREATE DATA is required for specifying a dynamically determined type.
"Declaring data reference variables
DATA ref1 TYPE REF TO i. "Complete type
DATA ref_gen TYPE REF TO data. "Generic type
"Creating anonymous data objects
"Using the # sign and the explicit type: see REF #( ) above.
ref1 = NEW #( ).
ref_gen = NEW string( ).
"For directly assigning values, insert the values within the parentheses.
ref1 = NEW #( 123 ).
"Using inline declarations to omit a prior declaration of a variable.
DATA(ref2) = NEW i( 456 ).
TYPES i_table TYPE STANDARD TABLE OF i WITH EMPTY KEY.
DATA(ref3) = NEW i_table( ( 1 ) ( 2 ) ( 3 ) ( 4 ) ( 5 ) ).
"CREATE DATA statements (older syntax)
"DATA ref4 TYPE REF TO string.
"DATA ref5 TYPE REF TO data.
"CREATE DATA ref4.
"Note: TYPE ... needed because of generic type data
"CREATE DATA ref5 TYPE p LENGTH 6 DECIMALS 2.
"CREATE DATA ref5 LIKE ref4.
Assigning existing data references to other data references. As mentioned above regarding the assignment, note that static types of both data reference variables must be compatible. As a result of an assignment, both the target reference variable and the source reference variable point to the same data object.
Excursion: Static vs. dynamic type, upcasts and downcasts
-
Data reference variables have ...
- a static type. This is the type you specify when declaring the variable, i. e.
iis the static type in this example:DATA ref TYPE REF TO i.. The static type can also be a generic data type:DATA ref TYPE REF TO data.. - a dynamic type, the type of a data object to which the reference variable actually points to at runtime.
- a static type. This is the type you specify when declaring the variable, i. e.
-
For an assignment to work, the differentiation is particularly relevant since the following basic rule applies: The static type of the target reference variable must be more general than or the same as the dynamic type of the source reference variable.
-
This is where the concepts of upcast and downcast enter the picture.
- Up and down? This concept originates from the idea of moving up or down in an inheritance tree. In an assignment between reference variables, the target variable inherits the dynamic type of the source variable.
- Upcast: If the static type of the target variables is less specific or the same as the static type of the source variable, an assignment is possible. This includes, for example, assignments with the assignment operator
=. - Downcast: If the static type of the target variable is more specific than the static type of the source variable, a check must be made at runtime before the assignment is done. If you indeed want to trigger such a downcast, you must do it explicitly in your code. You can do this, for example, using the
constructor operator
CAST. In older code, you may see the use of?=operator. - In contrast to a downcast, an upcast does not have to be done explicitly. However, you can - but need not - use the mentioned operators for upcasts, too.
"Examples demonstrating up- and downcasts
"Declaring data reference variables
DATA ref1 TYPE REF TO i.
DATA ref2 TYPE REF TO i.
ref1 = NEW #( 789 ).
"Assignments
ref2 = ref1.
"Casting
"Complete type
DATA(ref3) = NEW i( 321 ).
"Generic type
DATA ref4 TYPE REF TO data.
"Upcast
ref4 = ref3.
"Downcasts
DATA ref5 TYPE REF TO i.
"Generic type
DATA ref6 TYPE REF TO data.
ref6 = NEW i( 654 ).
ref5 = CAST #( ref6 ).
"Casting operator in older syntax
"ref5 ?= ref6.
Addressing data references
Before addressing the content of data objects a data reference points to, you must dereference data reference variables. Use the
dereferencing operator
->*. To check if dereferncing works, you can use a logical expression with IS BOUND.
"Creating data reference variables and assign values
DATA(ref_i) = NEW i( 1 ).
DATA(ref_carr) = NEW zdemo_abap_carr( carrid = 'LH' carrname = 'Lufthansa' ).
"Generic type
DATA ref_gen TYPE REF TO data.
ref_gen = ref_i. "Copying reference
"Accessing
"Variable number receives the content.
DATA(number) = ref_i->*.
"Content of referenced data object is changed.
ref_i->* = 10.
"Data reference used in a logical expression.
IF ref_i->* > 5.
...
ENDIF.
"Dereferenced generic type
DATA(calc) = 1 + ref_gen->*.
"Structure
"Complete structure
DATA(struc) = ref_carr->*.
"When dereferencing a data reference variable that has a structured
"data type, you can use the component selector -> to address individual components
DATA(carrid) = ref_carr->carrid.
ref_carr->carrid = 'UA'.
"This longer syntax with the dereferencing operator also works.
ref_carr->*-carrname = 'United Airlines'.
"Checking if a data reference variable can be dereferenced.
IF ref_carr IS BOUND.
...
ENDIF.
"Explicitly removing a reference
"However, the garbage collector takes care of removing the references
"automatically once the data is not used any more by a reference.
CLEAR ref_carr.
******************************************************
"Excursion: Generic data references in older ABAP releases
"Non-generic type
DATA ref_int TYPE REF TO i.
ref_int = NEW #( ).
ref_int->* = 123.
"Generic type
DATA ref_generic TYPE REF TO data.
ref_generic = NEW i( ).
"In older ABAP releases, CREATE DATA statements were needed.
CREATE DATA ref_generic TYPE i.
"The only option to access the variable in older releases was via field symbols.
ASSIGN ref_generic->* TO FIELD-SYMBOL(<fs_generic>).
<fs_generic> = 123.
"An access as the following, as it is possible in modern ABAP, was not possible.
ref_generic->* = 123.
"As shown in the example below, using dereferenced generic references is possible
"in various places in modern ABAP.
DATA ref_sel TYPE REF TO data.
CREATE DATA ref_sel TYPE TABLE OF zdemo_abap_carr.
SELECT *
FROM zdemo_abap_carr
INTO TABLE @ref_sel->*.
Data references in use
Some example contexts of using data references are as follows:
Overwriting data reference variables:
dref = NEW i( 1 ).
"ref is overwritten here because a new object is created
"with a data reference variable already pointing to a data object
dref = NEW i( 2 ).
Retaining data references:
"This snippet shows that three data references are created
"with the same reference variable. Storing them in an internal table
"using the TYPE TABLE OF REF TO prevents the overwriting.
DATA: dref TYPE REF TO data,
itab TYPE TABLE OF REF TO data,
num TYPE i VALUE 0.
DO 3 TIMES.
"Adding up 1 to demonstrate a changed data object.
num += 1.
"Creating data reference and assigning value.
"In the course of the loop, the variable gets overwritten.
dref = NEW i( num ).
"Adding the reference to itab
itab = VALUE #( BASE itab ( dref ) ).
ENDDO.
Processing internal tables:
"Similar use case to using field symbols: In a loop across an internal table,
"you can store the content of the line in a data reference variable
"instead of actually copying the content to boost performance.
"Filling an internal table.
SELECT *
FROM zdemo_abap_fli
INTO TABLE @DATA(fli_tab).
LOOP AT fli_tab REFERENCE INTO DATA(ref).
"A component of the table line might be addressed.
ref->carrid = ...
...
ENDLOOP.
Data reference variables as part of structures and internal tables:
"In contrast to field symbols, data reference variables can be used as
"components of structures or columns in internal tables.
"Structure
DATA: BEGIN OF struc,
num TYPE i,
ref TYPE REF TO i,
END OF struc.
"Some value assignment
struc = VALUE #( num = 1 ref = NEW #( 2 ) ).
"Internal table
DATA itab LIKE TABLE OF struc WITH EMPTY KEY.
APPEND struc TO itab.
itab[ 1 ]-ref->* = 123.
✔️ Hint
The question might now arise when to actually use either a field symbol or a data reference variable. It depends on your use case. However, data reference variables are more powerful as far as their usage options are concerned, and they better fit into the modern (object-oriented) ABAP world. Recommended read: Accessing Data Objects Dynamically (F1 docu for standard ABAP).
Dynamic ABAP Statements
As already mentioned above, there are ABAP statements that support the dynamic specification of syntax elements.
In this context, you can usually use elementary, character-like data objects - the content is usually provided in capital letters - specified within a pair of parentheses. In the SELECT list of an ABAP SQL SELECT statement, for example, you can use a standard table with a character-like row type. The dynamically specified syntax elements can be included as operands in various ABAP statements. The following code snippets are intended to give you an idea and rough overview.
Note that dynamically specifying syntax elements has downsides, too. Consider some erroneous character-like content of such data objects. There is no syntax warning. At runtime, it can lead to runtime errors.
-
Dynamic specifications in ...
-
statements for processing internal tables
"SORT: Dynamically specifying component name to be sorted for "Populating an internal table SELECT * FROM zdemo_abap_carr INTO TABLE @DATA(itab). "Named data object DATA(field_name) = 'CARRNAME'. SORT itab BY (field_name). "Unnamed data object SORT itab BY ('CURRCODE'). "READ TABLE: Dynamically specifying keys READ TABLE itab INTO DATA(wa) WITH KEY (field_name) = ... "MODIFY: Dynamically specifying WHERE conditions DATA(condition) = ( `CARRID = 'LH'` ). MODIFY itab FROM ... TRANSPORTING ... WHERE (condition). "DELETE: Dynamically specifying WHERE conditions DELETE itab USING KEY ... WHERE (condition). "LOOP: Dynamically specifying keys DATA(k) = `SOME_KEY`. LOOP AT itab INTO DATA(wa_lo) USING KEY (k). ... ENDLOOP. -
ASSIGN statements
"Accessing components of structures dynamically "Populating a structure SELECT SINGLE * FROM zdemo_abap_carr INTO @DATA(wa). "Declaring a field symbol FIELD-SYMBOLS <fs> type any. DATA(comp_name) = 'CARRNAME'. ASSIGN wa-(comp_name) TO <fs>. "named data object ASSIGN wa-('CARRID') TO <fs>. "unnamed data object "The statements set sy-subrc value. No exception occurs in case of an unsuccessful assignment. ASSIGN wa-('XYZ') TO <fs>. IF sy-subrc <> 0. ... ENDIF. "Numeric expressions are possible. Its value is interpreted as the position "of the component in the structure. ASSIGN wa-(4) TO <fs>. "If the value is 0, the memory area of the entire structure is assigned to the field symbol. ASSIGN wa-(0) TO <fs>. "The statements above replace the following, older statements. ASSIGN COMPONENT 'CARRID' OF STRUCTURE wa TO <fs>. ASSIGN COMPONENT 5 OF STRUCTURE wa TO <fs>. "Populating a structure that is referenced by a data reference variable SELECT SINGLE * FROM zdemo_abap_carr INTO NEW @DATA(ref_struc). "Note the object component selector. The field symbol is created inline here. ASSIGN ref_struc->('CARRNAME') TO FIELD-SYMBOL(<fs_inl>). ************************************************************* "Dynamically specifying attributes of classes/interfaces DATA(cl_name) = 'CL_SOME_CLASS'. DATA(dobj) = 'SOME_DOBJ'. ASSIGN cl_some_class=>(dobj) TO <fs>. ASSIGN (cl_name)=>some_dobj TO <fs>. ASSIGN (cl_name)=>(dobj) TO <fs>. "Class reference variable pointing to an object that contains attributes "and that are specified dynamically. DATA cl_ref TYPE REF TO cl_some_class. cl_ref = NEW #( ). ASSIGN cl_ref->('some_attribute') TO FIELD-SYMBOL(<another_fs>). "If ELSE UNASSIGN is specified, no memory area is assigned to the field symbol. "It has the state unassigned after the ASSIGN statement. ASSIGN cl_ref->('attr_xyz') TO FIELD-SYMBOL(<attr>) ELSE UNASSIGN.
-
-
Dynamically specifying data types
"Anonymous data objects are created using a type determined at runtime. "Note that the NEW operator cannot be used here. CREATE DATA dref TYPE (some_type). CREATE DATA dref TYPE TABLE OF (some_type). "Assigning a data object to a field symbol casting a dynamically specified type ASSIGN dobj TO <fs> CASTING TYPE (some_type). -
Dynamically specifying clauses in ABAP SQL statements
"This snippet demonstrates a selection of possible dynamic specifications in ABAP SQL SELECT statements. "Dynamic SELECT list DATA(select_list) = `CARRID, CONNID, COUNTRYFR, COUNTRYTO`. SELECT (select_list) FROM zdemo_abap_fli INTO TABLE ... "Dynamic FROM clause DATA(table) = `ZDEMO_ABAP_FLI`. SELECT * FROM (table) INTO TABLE ... "Excursion: Dynamic FROM clause and compatible target data object DATA(db_table) = `ZDEMO_ABAP_CARR`. DATA itab TYPE REF TO data. CREATE DATA itab TYPE TABLE OF (db_table). SELECT * FROM (db_table) INTO TABLE @itab->*. "Similar to the NEW operator, you can use the addition NEW here to create an anonymous data object "in place. The advantage is that the data type is constructed in a suitable way. SELECT * FROM (db_table) INTO TABLE NEW @DATA(a_dobj). "Dynamic WHERE clause "This is an example for using an internal table with a character-like row type DATA(where_clause) = VALUE string_table( ( `CARRID = 'LH'` ) ( `OR CARRID = 'AA'` ) ). SELECT * FROM zdemo_abap_fli WHERE (where_clause) INTO TABLE ... -
Dynamic invoke: Dynamically specifying procedure calls
"Notes: "- Dynamic method calls require a CALL METHOD statement. "- The first 3 examples assume that there are no mandatory parameters defined for the method. "- The example covers only static methods. Dynamic method calls for instance methods are also possible. "Method dynamically specified CALL METHOD class=>(meth). "Class dynamically specified CALL METHOD (class)=>meth. "Class and method dynamically specified CALL METHOD (class)=>(meth). "Assigning actual parameters to the formal parameters statically CALL METHOD class=>(meth) EXPORTING p1 = a1 p2 = a2 ... IMPORTING p1 = a1 p2 = a2 ... "Assigning actual parameters to the formal parameters dynamically DATA ptab TYPE abap_parmbind_tab. ptab = ... CALL METHOD class=>(meth) PARAMETER-TABLE ptab. "Notes on PARAMETER-TABLE ptab "- The table (of type abap_parmbind_tab; line type is abap_parmbind) must " be filled and have a line for all non-optional parameters. "- Components: name -> formal parameter name " kind -> kind of parameter, e. g. importing " value -> pointer to appropriate actual parameter, " is of type REF TO data "The addition EXCEPTION-TABLE for exceptions is not dealt with here.
Runtime Type Services (RTTS)
RTTS represent a hierarchy of type description classes containing methods for Runtime Type Creation (RTTC) and Runtime Type Identification (RTTI). Using these classes, you can ...
- get type information on data objects, data types or instances at runtime.
- define and create new data types at runtime.
The hierarchy of type description classes is as follows.
CL_ABAP_TYPEDESCR
|
|--CL_ABAP_DATADESCR
| |
| |--CL_ABAP_ELEMDESCR
| | |
| | |--CL_ABAP_ENUMDESCR
| |
| |--CL_ABAP_REFDESCR
| |--CL_ABAP_COMPLEXDESCR
| |
| |--CL_ABAP_STRUCTDESCR
| |--CL_ABAP_TABLEDESCR
|
|--CL_ABAP_OBJECTDESCR
|
|--CL_ABAP_CLASSDESCR
|--CL_ABAP_INTFDESCR
So, the
superclass
CL_ABAP_TYPEDESCR has multiple
subclasses,
for example, to deal with each kind of type.
Working with this inheritance tree means making use of
casts,
especially
downcasts when retrieving information at runtime.
Detailing out all the possibilities for the information retrieval and
type creation is beyond scope. Check the information, options and
various methods that can be used in the class documentation, e. g. using
F2 help information in
ADT,
for more details.
The following examples show the retrieval of information. Instead of the cumbersome extra declaration of data reference variables, you can use inline declarations. Method chaining comes in handy, too.
"The properties of a type are retrieved using RTTI
"In ADT, you may want to choose CTRL + SPACE after ...=> to explore the options.
DATA(some_type) = cl_abap_typedescr=>describe_by_data( var ).
"The components of a structure are retrieved.
"Like above, the describe_by_data method is used together with a variable.
DATA(components) = CAST cl_abap_structdescr(
cl_abap_typedescr=>describe_by_data( some_struc )
)->components.
"The attributes of a global class are retrieved. In contrast to the
"example above the describe_by_name method is used together with the actual name.
DATA(attributes) = CAST cl_abap_classdescr(
cl_abap_classdescr=>describe_by_name( 'CL_SOME_CLASS' )
)->attributes.
"Casting and method chaining as above in contrast to the following extra declarations
"If the variables were not declared inline as in the example, there would be even more lines of code.
DATA(a) = cl_abap_typedescr=>describe_by_data( some_struc ).
DATA(b) = CAST cl_abap_structdescr( a ).
DATA(c) = b->components.
The following example demonstrates the dynamic creation of data objects.
Note the TYPE HANDLE
addition as part of the CREATE DATA statement that is used when referring to dynamically created data types.
"RTTC examples
"Creation of an anonymous data object using a type description object for a
"dictionary structure that is obtained using RTTI
"Declaring a data reference variable with a generic type
DATA dref TYPE REF TO data.
"Getting type description using RTTI
DATA(type) = CAST cl_abap_datadescr(
cl_abap_typedescr=>describe_by_name( 'ZDEMO_ABAP_CARR' ) ).
"Creating an anonymous data object using the retrieved type description
CREATE DATA dref TYPE HANDLE type.
"Creating an internal table dynamically
"Getting type description using RTTI
DATA(line_type) = CAST cl_abap_structdescr(
cl_abap_tabledescr=>describe_by_name( `ZDEMO_ABAP_CARR` ) ).
"Defining primary table keys of internal table type to be created
DATA(itab_keys) = VALUE abap_keydescr_tab( ( name = 'CARRID' )
( name = 'CARRNAME' ) ).
"Creating internal table type using the create method of cl_abap_tabledescr
DATA(table_type) = cl_abap_tabledescr=>create(
p_line_type = line_type
p_table_kind = cl_abap_tabledescr=>tablekind_sorted
p_unique = cl_abap_typedescr=>true
p_key = itab_keys ).
"Creating internal table based on the created table type
DATA ref_tab TYPE REF TO data.
CREATE DATA ref_tab TYPE HANDLE table_type.
More Information
- It is recommended that you also consult section Dynamic Programming Techniques (F1 docu for standard ABAP) in the ABAP Keyword Documentation since it provides important aspects that should be considered when dealing with dynamic programming in general (e. g. security aspects or runtime error prevention).
- There are even further dynamic programming techniques in the unrestricted language scope like the
generation or execution of programs at runtime. They are not part of this cheat sheet. Find more details on the related syntax (e. g.
GENERATE SUBROUTINE POOL,READ REPORTandINSERT REPORTin the ABAP Keyword Documentation for Standard ABAP: Dynamic Program Development (F1 docu for standard ABAP)
Executable Example
Note the steps outlined here about how to import and run the code.