NODES

Basic form

NODES node.

Extras:

1.... TYPE type.

This statement is not allowed in an ABAP Objects context. See NODES Statement Not Allowed.

Effect

Creates a variable node with reference to a data type from the ABAP Dictionary with the same name. The variable node is used to transport data from logical databases to the ABAP program.

A node of a logical database can have a name of up to 14 characters. The node may have one of four types. For nodes that do not have the type "Dynamic Dictionary Type", you cannot use the TYPE addition. IF the node type is "Dynamic Dictionary Type", the NODES statement within the logical database may not have a TYPE addition. However, this is compulsory in the executable program.

There are four different types of nodes in a logical database:

Tables

The name is that of an ABAP Dictionary structure. The NODES statement has the same effec as the TABLES statement, and declares a table work area as a common dta area for the database program and the ABAP program. In this case, you can only use table names shorter than 15 characters.

ABAP Dictionary Type

This type can have any name. The node is an ABAP Dictionary structure or a Dictionary type. The work area is created as with DATA COMMON PART. In this case, you can use ABAP Dictionary structures or types with names longer than 14 characters.

Type from a Type Group

The type can have any name, and the node is the name of a type defined in a type pool. The work area is created as with DATA COMMON PART

Dynamic Dictionary Type

Can have any name. The node is the name of an ABAP Dictionary type (as with type "Dictionary type"). Similarly to the Dictionary type, a work area is created as with DATA ... TYPE type COMMON PART.
"TYPE type" defines the type of the node. The type type must be assigned to the node node in Transaction 36. The data object returned to GET node or GET node LATE at runtime (which also has the node name node) has the type type. In this case, the data is only available within the GET/GET LATE events. Nodes of this type allow their data type to be determined by the report (choosing from a list of types determined by the logical database).

Examples:

Node SPFLI, type table
In PUT SPFLI -> GET SPFLI, the work area created using TABLES SPFLI is filled with data.

Node HUGO, type Dictionary type, structure SPFLI
In PUT HUGO -> GET HUGO, the field HUGO TYPE SPFLI is filled with data.

Node OTTO, Type from Type pool, type RSDS_WHERE
In PUT OTTO -> GET OTTO, the field OTTO TYPE RSDS_WHERE is filled with data.

Node DYNNODE, "static" type SPFLI, "dynamic" type SFLIGHT.
In PUT DYNNODE -> GET DYNNODE, the (local) field DYNNODE TYPE SFLIGHT is filled with data. Outside GET DYNNODE (LATE) the (global) data object DYNNODE with type SPFLI is recognized.

Activating a Node

Nodes used to be activated in the database program and the report using TABLES tab, which created the work area, declared all database-specific objects ( PARAMETERS, SELECT-OPTIONS, SELECTION-SCREEN objects), belonging to tab or a higher-level table in the hierarchy of the logical database to the program, and, where necessary, included the corresponding input fields on the selection screen.

This is now done by the new NODES node statement. You can use eitherNODES tab or TABLES tab for nodes with type T.

Example:

NODES SPFLI. (or TABLES SPFLI.)
creates a TABLES work area for SPFLI, and activates all database-specific objects for SPFLI and its higher-level nodes.
NODES HUGO.
creates the data object DATA HUGO TYPE SPFLI (in the COMMON PART), and activates all database-specific objects for HUGO and its higher-level nodes.
NODES OTTO.
creates the data object DATA OTTO TYPE RSDS_WHERE (in the COMMON PART) and activates all database-specific objects for OTTO and its higher-level nodes.
NODES DYNNODE TYPE SFLIGHT.
creates the data object DATA DYNNODE TYPE SPFLI (in the COMMON PART), and activates all database-specific objects for DYNNODE and its higher-level nodes.

Database-specific objects for nodes with type Dictionary or TYPE POOL type.

PARAMETERS and SELECTION-SCREEN objects are assigned to a node using the FOR NODE node addition (instead of FOR TABLE tab that was used previously).

For type table, you can use either FOR NODE or FOR TABLE.

Valid 'LIKE' fields in the PARAMETERS statement

For 'LIKE' fields f in the ABAP statement PARAMETERS p LIKE f, the following values of f are possible:

A node field for nodes with complex type only at the highest level. If a node has the type "Dynamic Dictionary Type", the static type is used.

An ABAP Dictionary field or structure

Examples:
Permitted values of f:
SPFLI-CARRID (Field of node SPFLI)
HUGO-CARRID (Field of node HUGO)
OTTO-TABLENAME (Field of node OTTO at highest level)
HUGO (Knoten)
SFLIGHT-CONNID (Dictionaryfeld)
DYNNODE-CARRID (Feld des Knotens DYNNODE, versehen mit seiner statischen Struktur)
Reference fields with a deep type or type F (floating point) are only allowed with the addition NO-DISPLAY.

Fields in the SELECT-OPTIONS statement
In the ABAP statement SELECT-OPTIONS sel FOR f, f may be a node field, but only at the highest level for nodes with a complex type.

Examples:
Permitted values of f:
SPFLI-CARRID (Field of node SPFLI)
HUGO-CARRID (Field of node HUGO)
OTTO-TABLENAME (Field of node OTTO at highest level)
DYNNODE-CARRID (Field of node DYNNODE, with its static
structure)
Not permitted:
SFLIGHT-CONNID (Not a node field)
Deep types are not allowed in Select-Options.
Floating point - as in parameters - is only allowed with the NO-DISPLAY addition.

Advantages of logical nodes:

Using the same Dictionary structure for more than one node.

You can explicitly read additional information before PUT tab by assigning a complex type to the node, for example. Then this additional information does not bypass tools such as SAP Query, dynamic selections, and variants.

Existing naming conventions for the database programs are retained: FORM PUT_node and FORM AUTHORITYCHECK_node.

This would have lead to syntax errors if you used 30-character table names. Consequently, eitehr an incompatible change would have been necessary, or long table names had to be forbidden in logical databases.

Additional help

Interface Work Areas

Logical Databases