Internal tables are serialized and deserialized within a loop that sets the current node to the current table row:
<tt:loop [ref=“node“] [name=“alias“]>
...
</tt:loop>
The optional attribute ref can be used to define the current node for the command. If refis not specified, the current node of the surrounding element is used. The ABAP data object that is bound to the current node must be an internal table.
The name attribute can be used to define an alias for the current node within the loop. The current node can then be address with “$alias“ in the <tt:loop> loop. When nested loops are used, the alias permits access to the current nodes of outer loops. If only one loop is used and in the outermost loop, when entering the loop $alias is equivalent to $ref.
During serialization, a loop is run for the entire internal table. If the internal table is blank, processing continues after the element. During each loop pass, the current node of a data node is set and the current ABAP table row is bound to the data node. The content of element <tt:loop>, which can contain any template elements, is processed for each data node.
During the deserialization process, the ABAP table is initialized and the contents of element <tt:loop> are also executed in a loop. The XML document continues to be processed until a position is reached that cannot be processed with the contents of the element. A new line is generated in the bound ABAP table for each loop pass and is in turn bound to the current node. The XML values that are deserialized in the current loop pass are passed on to the current table row.
If you want to be able to deserialize a transformation, you have to make sure that loop execution can be ended properly, especially in the case of nested <tt:loop> loops. This is the case when the contents of a <tt:loop> element can be synchronized with the sections to be deserialized. If the XML elements in a loop are not sufficient, the entire loop body can be enclosed with a literal XML element, for example, which defines a hierarchy level that can be analyzed during the deserialization process.
In a simple transformation, a data node has to be treated either exclusively or not at all as an internal table. In particular, this applies to dividing a template into different transformation directions.
In the following symmetrical simple transformation, the internal table that is bound to the ROOT data roots and its table-like component values are serialized and deserialized in two nested <tt:loop> loops. For demonstration purposes, an alias called line is defined in the outermost loop and is addressed in the loop using $line. Because $line is not addressed in the inner loop, the definition of the alias name would not be necessary here.
<tt:transform xmlns:tt="http://www.sap.com/transformation-templates">
<tt:root name="ROOT"/>
<tt:template>
<tab1>
<tt:loop ref=".ROOT"
name="line">
<key>
<tt:value
ref="$line.key" />
</key>
<tab2>
<tt:loop
ref="$line.values">
<value>
<tt:value
/>
</value>
</tt:loop>
</tab2>
</tt:loop>
</tab1>
</tt:template>
</tt:transform>
The following ABAP program can call the transformation:
DATA xml_string TYPE
string.
DATA: BEGIN OF line,
key TYPE i,
values TYPE TABLE OF i,
END OF line.
DATA num TYPE i.
DATA itab LIKE TABLE OF line.
DATA result LIKE itab.
DO 3 TIMES.
CLEAR line.
line-key = sy-index + 1.
num = line-key ** 2.
APPEND num TO line-values.
num = line-key ** 3.
APPEND num TO line-values.
num = line-key ** 4.
APPEND num TO line-values.
APPEND line TO itab.
ENDDO.
CALL TRANSFORMATION
...
SOURCE root =
itab
RESULT XML xml_string.
CALL TRANSFORMATION
...
SOURCE XML xml_string
RESULT root = result.
The result of the serialization is the following:
<tab1>
<key>2</key>
<tab2>
<value>4</value>
<value>8</value>
<value>16</value>
</tab2>
<key>3</key>
<tab2>
<value>9</value>
<value>27</value>
<value>81</value>
</tab2>
<key>4</key>
<tab2>
<value>16</value>
<value>64</value>
<value>256</value>
</tab2>
</tab1>
After deserialization, result has the same contents as itab.