You are on page 1of 10

1

Dynamic Programming
ABAP offers five forms of dynamic token specification, each of which is intended for a specific part of a
program statement:
1.

Dynamic field specification contains the name of a field. The field for an ASSIGN
statement, which should be assigned to a field symbol, can be specified dynamically. (We have seen
examples of this in earlier blogs of this series)

2.

Dynamic type specification contains the name of a type. The type for CREATE DATA can
be specified dynamically. (We have seen examples of this in earlier blogs of this series)

3.

Dynamic component specification contains the name of a component of a structure, such as


the sort order for an internal table. (this was our example at the start of this blog)

4.

Dynamic clause specification contains a whole part of a statement. For example, all clauses
of the Open SQL statement SELECT can be specified dynamically. In this case, the variable must be an
internal table of character fields. (you will se examples of this shortly)

5.

Dynamic
subroutine
specification contains the
name
of
functions, forms, programs, and transactions can be called dynamically.
Dynamic Programming

subroutine.

Methods,

Both Field Symbols and Data References help us in dynamic programming which means, we can access
the contents of the data objects whose name and the properties are not known to until runtime. Another
advantage is performance improvement.
Understanding of Field symbols field symbol means value at address
Field symbols are placeholders for other fields. They do not physically reserve space for a field, but point
to its contents. A field symbol cam point to any data object. You can create field symbols either without or
with type specifications. If you do not specify a type, the field symbol inherits all of the technical attributes
of the field assigned to it. If you do specify a type, the system checks during the field assignment whether
the assigned field matches the type of field symbol.
Check whether the field symbol is assigned or not before processing field symbol, it is very important to
check field symbol, if it is not assigned it will get a run-time error, use the blow syntax to check
field symbol assignment. We can check this using IS ASSIGNED statement.
Understanding of Data References Data references are pointers to data objects or Data references
are addresses of data objects. You can use data references to create data objects dynamically. You can
only dereference a data reference using a special assignment to a field symbol.
To access the contents of the data object to which a data reference is pointing, you must assign it to field
symbols using following statement, because we cannot work with the contents of the created data object
by using only the dereferencing operator ->*.
ASSIGN <dref>->* TO <FS>.

We can also use data references as follow:DATA: i_bseg TYPE STANDARD TABLE OF bseg,
o_bseg TYPE REF TO bseg.
LOOP AT i_bseg REFERENCE INTO o_bseg.
Write: / o_bseg->belnr.
ENDLOOP.
To check if the data reference variable is pointing to an object, we can use following statement:IS [NOT] BOUND.

1. Data : dref type ref to DATA.


A variable dref with type TYPE REF TO DATA is declared, which can Hold a REFERENCE to any data
object. It will work as generic data object.
2. CREATE DATA dref TYPE (tabname)
FIELD-SYMBOLS : <row> TYPE ANY,
ASSIGN dref->* To <row>.
CREATE DATA dref TYPE (tabname) statement will create work area with line type tabname
dynamically. The reference dref is referring to this work area and this work area is not accessible
directly. Instead we need a field symbol refer to the work area referenced by dref using ASSIGN
dref->* To <row>. This will allow us to safely fetch the data from the table tabname into <row>
because it is guaranteed that the database table is type compatible with work area.
3. For Work Area
CREATE DATA dref TYPE (tabname).
ASSIGN dref->* To <row>.
4. For Internal Table
FIELD-SYMBOLS : <row> TYPE ANY TABLE
table addition is there for internal table
CREATE DATA dref TYPE TABLE of (tabname).
ASSIGN dref->* To <row>.

Example 1:DATA: dref

TYPE REF TO data,

tabname TYPE tabname.


FIELD-SYMBOLS: <row>

TYPE any,

<component> TYPE any.


START-OF-SELECTION.
WRITE: / 'EBAN', / 'MARA', / 'VBAK'.

AT LINE-SELECTION.
READ CURRENT LINE LINE VALUE INTO tabname.
* dynamically create appropriate Data Structure
CREATE DATA dref TYPE (tabname).
ASSIGN dref->* TO <row>.

* fetch the data


SELECT *
FROM (tabname) UP TO 2 ROWS
INTO <row>.

* display the result


NEW-LINE.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE <row> TO <component>.
* the above statement is used because <row> is of generic typed. it is not typed using create data
statement with type information.
IF sy-subrc <> 0.
EXIT. " no more components
ENDIF.
WRITE: <component>.
ENDDO.
ENDSELECT.

Example 2:DATA: tabname TYPE tabname,


dref
alv

TYPE REF TO data, " Generic data reference


TYPE REF TO cl_gui_alv_grid.

FIELD-SYMBOLS: <itab> TYPE ANY TABLE.

START-OF-SELECTION.
WRITE: / 'EBAN', / 'MARA', / 'VBAK'.

AT LINE-SELECTION.
READ CURRENT LINE LINE VALUE INTO tabname.

* dynamically create appropriate internal table


CREATE DATA dref TYPE TABLE OF (tabname).
ASSIGN dref->* TO <itab>.

* fetch the data


SELECT *
FROM (tabname) up to 100 rows
INTO TABLE <itab>.

* display the result


CREATE OBJECT alv
EXPORTING
i_parent = cl_gui_container=>screen0.

CALL METHOD alv->set_table_for_first_display


EXPORTING
i_structure_name = tabname
CHANGING
it_outtab

= <itab>.

6
In ABAP Objects, there is a class-based concept called Run Time Type Information (RTTI) that you can use
to determine type attributes at run time. The methods used in this class replaces statements like describe
table, describe field etc.
Another concept Run time Type Creation (RTTC) was added to the above to create data of any type
dynamically.
Both these together comprise the RTTS (Run time Type Services).
Runtime Type Identification (RTTI)
Runtime Type Identification (RTTI) is a powerful technique for obtaining all information about a data type
at
runtime.
When
you
use dynamic
programming techniques,
sometimes
you
need
to
dynamically determine the data type or properties in order to decide how to handle the data. This situation
typically occurs when you use generic types, where you need to obtain at runtime the missing data
characteristics not described by the generic type. For example, if you use the generic type ANY in a
subroutine, you will need to get information at runtime about the type of the data being passed.
RTTI is implemented in ABAP Objects using description objects. Description objects for types are created
from description classes, and every type in the ABAP hierarchy has a corresponding description object.
Next, every description class has special attributes and appropriate navigation methods. For instance,
the class
CL_ABAP_TABLEDESCR
has
an
attribute TABLE_KIND
and
a
navigation
method GET_TABLE_LINE_TYPE.
In the RTTI class hierarchy. As you can see below, the class CL_ABAP_TYPEDESCR is the root class, which
contains all methods to derive a description object from a data type or the name of the type.

The class CL_ABAP_TYPEDESCR provides four methods to derive a description object for a type:
DESCRIBE_BY_NAME: This method takes a name of a type as an input parameter and returns an object
reference to the corresponding description object.
DESCRIBE_BY_DATA: This method
the description object of the data type.

takes

data as

input

and

returns

an

object

reference

to

DESCRIBE_BY_DATA_REF: This method takes a data reference as input and returns an object reference
to the description object of the data type for the data pointed to by the reference.

7
DESCRIBE_BY_OBJECT_REF: This method takes an object reference as input and returns an object
reference to the description object of the object type for the object pointed to by the reference.
You can obtain a reference to a description object for a type in different ways (e.g., by name, by
data, with navigation, etc.). Now this is important RTTI guarantees that exactly one description
object exists for every type. All references point to the same description object, no matter which path
was chosen to retrieve it.
So lets look at an example. Lets use RTTI to guarantee a STRICT Parameter check. ABAP performs only
a technical parameter check. In other words, types with the same features are considered to be
compatible, even if they have different names. What if a method relies on a passed parameter being
typed with a specific type because of something other than its technical compatibility? This cannot be
expressed in ABAP.

RTTS and Class Hierarchy


The RTTS is implemented as system classes that are available in all ABAP programs. There are only
a few general principles to consider:

For each type kind there exists an RTTI description class

A concrete type is defined by its type object, and for every type, one type object exists at runtime

As a bi-implication, each type object defines exactly one type

Properties about a type are defined by attributes of the type object

So what this means is that each kind of type has a corresponding RTTS class (e.g. all elementary
data types have one corresponding type class) and for each concrete type of that kind there will be a
single object of that class at runtime (e.g. the elementary integer data type has one single type object
that defines it). Lets get an overview of all of this.
All RTTS related classes are named CL_ABAP_*DESCR, depending on which type kind the class
represents. CL_ABAP_ELEMDESCR is the description class for elementary datatypes,
CL_ABAP_TABLEDESCR is for table types and so on. Illustrated below, is the complete hierarchy of
type classes (that closely resembles the ABAP type hierarchy).
RTTI Example
Lets get our hands a bit dirty and do some runtime examination of data types. The superclass CL_ABAP_TYPEDESCR,
which is also the root of the RTTS type hierarchy, defines a set of (primarily RTTI related) static methods that are available
for all the different type kinds. The two most used methods are DESCRIBE_BY
_DATA and DESCRIBE_BY_NAME that each returns the corresponding type object for some data object at runtime.
These are used by either by providing a reference to the data object in question or the relative name of the type, as input
argument respectively. Note that for a reference to some data object (e.g. a reference to an integer or table) the

8
DESCRIBE_BY_DATA_REF method must be used, and likewise for references to reference types the
DESCRIBE_BY_OBJECT_REF method is available.
In the following example the RTTI methods are used to get the type object for the elementary integer data type. We
declare a simple integer and retrieve its type object using both methods first by passing the data object in question and
secondly by using the relative name of the integer type in ABAP.
So far so good lets see what this type object can tell us about the integer type by inspecting the object referenced by
lr_typeobj_for_i (which is the same object reference assigned in both assignments):

The elementary integer type object tells us that the kind of the type object is an integer, it has no decimals and occupies 4
bytes. Nothing extremely exciting or surprising for this type, but nonetheless, it shows us the principle of a type object.
Lets go ahead and use the DDIC to get the type object for the data structure that is underlying of the database table for
the pa0002 infotype. We use the CL_ABAP_STRUCTDESCR for accessing type information specific to a data structure:

The PA0002 data structure occupies 988 bytes, and the CL_ABAP_STRUCTDESCR specific attributes defines the
structure as a flat structure. Finally the COMPONENTS attribute provides an internal table that lists all the individual fields
on the structure by their name, including the data type of each of these (by their relative name). By combining the DDIC
and RTTS we are able to examine a database table, and see all of its columns and the data type of each column, at
runtime. Furthermore we could use this information to get the type object for each of these columns.
These examples shows just a small piece of the RTTI features. One can do many more interesting type inspections, e.g.
determining which attributes or methods are available on a class or concrete object at runtime.
Finally we can also create new data objects using the type objects. The following shows the creation of a new data
structure of the pa0002 type previously obtained, and assigning a value to the pernr field on this structure:
In this case we know the type and thus the field symbol used to access the individual fields of the structure created as any
other structure. This, however, is not always be the case e.g. if we create a complete new data type at runtime using
RTTC. In such case we would have to work with the generic programming parts of ABAP to assign a value to a field. We
will get to see more advanced cases like this in the next part.

10

RTTS
Type Hierarchy
The type class hierarchy is slighty different than the ABAP type hierarchy, however, with less classes
than types. This is a result of only type kinds having a corresponding type class. Specific details
about a type are represented by the attributes on the object of that class. E.g. in ABAP we have many
different kinds of internal tables standard tables, hashed tables, sorted tables and so on. All of these
are described by the same CL_ABAP_TABLEDESCR class, but at runtime they will be different by
each having an object of the type CL_ABAP_TABLEDESCR, with attributes that describe whether it is
e.g. a hashed table.
As a final note on RTTS in general, I want to clear up some possible naming confusion that appears
to arise in general. In the old days, only type introspection was available, and not dynamic type
creation. This was named RTTI in ABAP. Later RTTC became available and both were synthesised
into RTTS. There are, however, no specific RTTI or RTTC classes. RTTS is available through the
previously mentioned type classes. We simply divide the interface of each class into RTTI and RTTC
methods and attributes. So any method on any of the CL_ABAP_*DESCR classes that relate to type
introspection can be categorised as an RTTI method and any method that relates to the creation of a
new type object of some type kind will be categorised as an RTTC method.

You might also like