Literale XML-Elemente und Attribute (SAP-Bibliothek - Applikationsentwicklung auf AS ABAP)

Literale XML-Elemente und Attribute

Literale XML-Elemente sind XML-Elemente, die keine ST-Befehle sind, bzw., die nicht im Namensraum “http://www.sap.com/transformation-templates“ (Namensraumpräfix tt) liegen. Attribute von literalen XML-Elementen, die nicht in diesem Namensraum liegen, werden als literale Attribute bezeichnet.

Literale XML-Elemente und deren literale Attribute werden bei der Serialisierung ungeändert in das XML-Zieldokument übertragen und bei der Deserialisierung standardmäßig wortwörtlich mit dem XML-Ausgangsdokument abgeglichen. Neben den literalen Attributen können literale XML-Elemente auch bestimmte Attribute mit dem Namensraumpräfix tt, also ST-spezifische Attribute enthalten, um den aktuellen Knoten zu setzen und das Verhalten bei der Deserialisierung zu steuern.

Allgemeine literale XML-Elemente

Die Syntax für allgemeine literale XML-Elemente ist wie folgt:

<element [attr] [tt:ref=″node″>]
[tt:lax=lax_flag]
[tt:extensible=extensible_flag]>
...
</element>

Dabei ist element der Name des Elements und attr eine beliebig große Menge optionaler literaler Attribute beliebigen Namens. Das optionale ST-spezifische Attribut tt:ref setzt den aktuellen Knoten node für den Kontext des literalen Elements. Die optionalen ST-spezifischen Attribute tt:lax tt:extensible wirken nur bei der Deserialisierung. tt:lax legt fest, ob der Elementname element bei der Deserialisierung abweichen darf. tt:extensible gibt an, ob der Inhalt des Elements um unspezifizierte Elemente erweiterbar ist.

Serialisierung literaler XML-Elemente

Bei der Serialisierung wird der Elementanfang <element [attr]> mit seinen literalen Attributen attr an das Ziel-XML-Dokument übertragen, der Inhalt des Elements serialisiert und dann das Elementende </element> übertragen. Wenn es mehrere literale Attribute des gleichen Namens gibt, wird nur das letzte übertragen.

Hinweis

Zur Behandlung von Namensräumen siehe Namensräume.

Deserialisierung literaler XML-Elemente

Bei der Deserialisierung wird der Elementanfang mit der aktuellen Position des Ausgangs-XML-Dokuments abgeglichen. Standardmäßig muss im Ausgangs-XML-Dokument ein Element des gleichen Namens mit allen literalen Attributen attr des gleichen Inhalts stehen. Die Reihenfolge der literalen Attribute ist beliebig. Überzählige literale Attribute des Elements im Ausgangsdokument werden grundsätzlich ignoriert. Wenn es mehrere literale Attribute des gleichen Namens gibt, wird nur das letzte berücksichtigt.

Nach erfolgreichem Abgleich des Elementanfangs wird der Elementinhalt deserialisiert und abschließend das Elementende konsumiert.

Spezialform literaler XML-Elemente

Eine Spezialform literaler XML-Elemente kombiniert den tt:value-Befehl mit obiger Syntax:

<element [attr] tt:value-ref=″node″
[tt:lax=lax_flag]
[map=″mapping_list″]

[length|minLength|maxLength=″length″] />

Diese Spezialform ist eine Kurzform von:

<element [attr] [tt:lax=lax_flag]>
<tt:value ref=″node″ [map=″mapping_list″]

[length|minLength|maxLength=″length″] />
</element>

Dadurch kann der häufige Anwendungsfall, einen elementaren Wert als Inhalt eines XML-Elements auszudrücken, einfach formuliert werden.

Das Attribut tt:extension kann nicht zusammen mit tt:value-ref angegeben werden.

Beispiel

Das folgende ST-Programm ist geeignet, ein elementares Datenobjekt zu serialisieren.

<tt:transform xmlns:tt="http://www.sap.com/transformation-templates">

<tt:root name="ROOT"/>

<tt:template>
     <X my_attr="attr">
       <tt:value ref="ROOT" />
    </X>
</tt:template>

</tt:transform>

Das Ergebnis einer Serialisierung ist wie folgt, wenn “abc“ der Wert des an ROOT angebundenen ABAP-Datenobjekts ist.

Man beachte, dass literaler Text, der nichts als Leerräume (Leerzeichen und Zeilenumbrüche) enthält, in ST-Programmen standardmäßig irrelevant ist. Aus diesem Grund liefert die Serialisierung auch nicht etwa:

Wenn in Beispielen Ergebnisse von Serialisierungen mit Einrückungen und Zeilenumbrüchen gezeigt werden, dienen diese meistens der Verdeutlichung und sind nicht tatsächlich Teil des Ergebnisses.

Folgendes ST-Programm kann das Ergebnis wieder deserialisieren, wobei das literale Attribut my_attr ignoriert wird:

<tt:transform xmlns:tt="http://www.sap.com/transformation-templates">

<tt:root name="ROOT"/>

<tt:template>
    <X>
      <tt:value ref="ROOT"/>
    </X>
</tt:template>

</tt:transform>

Folgendes ST-Programm zeigt die äquivalente Kurzform des vorhergehenden Programms:

<tt:transform xmlns:tt="http://www.sap.com/transformation-templates">

<tt:root name="ROOT"/>

<tt:template>
<X tt:value-ref="ROOT" />
</tt:template>

</tt:transform>

Folgendes ST-Programm führt zur Ausnahme CX_ST_MATCH_ELEMENT, da statt dem Element Y ein Element X geliefert wird.

<tt:transform xmlns:tt="http://www.sap.com/transformation-templates">

<tt:root name="ROOT"/>

<tt:template>
    <Y>
      <tt:value ref="ROOT"/>
    </Y>
</tt:template>

</tt:transform>

Folgendes ST-Programm führt trotz gleicher Elementnamen zur Ausnahme CX_ST_MATCH_ATTRIBUTE, da das erwartete literale Attribut my_value nicht im Ausgangsdokument vorhanden ist.

<tt:transform xmlns:tt="http://www.sap.com/transformation-templates">

<tt:root name="ROOT"/>

<tt:template>
    <X my_value="value">
      <tt:value ref="ROOT"/>
    </X>
</tt:template>

</tt:transform>

Ein richtiger Attributname mit falschem Attributinhalt führt zur Ausnahme CX_ST_MATCH_TEXT.