What is a node in abap-hr

Question

Hi all,
Can you plz explain the difference between
node and  tables .
ex:--
node :
infotypes: 0000
get <  >
ex:--
tables : pernr / objec
infotypes : 0000.
get < pernr/ objec>
Thanks and regards,
Ravi

Answer 1

NODES
Basic form
NODES node.
Additions:
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 using DATA in the 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 using DATA in the COMMON PART.
Dynamic Dictionary Type
Can have any name. The node is the name of an ABAP Dictionary type (as with type "Dictionary type"). A work area is created using DATA node TYPE "static type" in the 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 make the 'secret' reading of additional information before PUT dbtab can be made explicit if you assign a complex type to the node. Then the additional objects do 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.