Bedingte Transformationen
Bedingte Transformationen sind Teile von ST-Programmen, die bei dessen Verarbeitung nur bei Erfüllung bestimmter Voraussetzungen berücksichtigt werden. In der Regel werden bedingte Transformationen als Fälle in tt:switch und tt:group verwendet.
Eine bedingte Transformation wird als Inhalt eines Elements tt:[s-|d-]cond realisiert:
<tt:[s-|d-]cond
[using="precond"] [data="assertion"]
[[s-|d-]check="cond"]>
...
</tt:[s-|d-]cond>
Der Inhalt von tt:[s-|d-]cond wird in Abhängigkeit einer
● Vorbedingung precond
● Zusicherung assertion
● Bedingung cond
prozessiert. Dabei gilt
● Das Element tt:cond wird bei Serialisierung und Deserialisierung ausgewertet.
● Das Element tt:s-cond wird nur bei der Serialisierung ausgewertet und bei der Deserialisierung übersprungen. Der Inhalt von tt:s-cond wird nie deserialisiert.
● Das Element tt:d-cond wird nur bei der Deserialisierung ausgewertet und bei der Serialisierung übersprungen. Der Inhalt von tt:d-cond wird nie serialisiert.
Die Bedingung cond ist ebenfalls gerichtet anwendbar:
● Die Bedingung check wird bei Serialisierung und Deserialisierung ausgewertet.
● Die Bedingung s-check wird nur bei der Serialisierung ausgewertet.
● Die Bedingung d-check wird nur bei der Deserialisierung ausgewertet.
Eine Angabe von s-check in tt:d-cond oder d-check in tt:s-cond ist nicht sinnvoll.
Wenn der Inhalt von tt:[s-|d-]cond kein Muster ist, muss mindestens ein Attribut using, data oder check angegeben werden.
Serialisierung
Bei der Serialisierung werden
...
1. die Vorbedingung
2. die Zusicherung
3. die Bedingung
ausgewertet. Der Inhalt des Elements tt:[s-]cond wird nur serialisiert, wenn alle drei Voraussetzungen erfüllt sind, andernfalls wird der Vergleich bei der ersten falschen Voraussetzung abgebrochen und der Inhalt von tt:[s-]cond übersprungen.
Wenn in tt:[s-]cond keines der drei möglichen Attribute angegeben ist, wird die Voraussetzung als erfüllt betrachtet. Wenn der Inhalt von tt:[s-]cond bei der Serialisierung leer ist, wird das Element nicht berücksichtigt.
Deserialisierung
Bei der Deserialisierung wird vor und während der Überprüfung der Vorbedingung unterschieden, ob der Inhalt von tt:[d-]cond ein Muster ist oder nicht. Die Deserialisierung verläuft wie folgt:
...
1. Überprüfung, ob der Inhalt von tt:[d-]cond ein Muster ist.
a. Wenn der Inhalt von tt:[d-]cond ein Muster ist, wird er gegen das aktuelle Element des XML-Eingangsstroms abgeglichen. Falls das Muster nicht auf das aktuelle Element passt, wird das Element tt:[d-]cond übersprungen und das aktuelle Element des XML-Eingangsstroms nicht konsumiert, sonst weiter mit Schritt 2.
b. Wenn der Inhalt von tt:[d-]cond kein Muster ist, weiter mit Schritt 2.
2. Überprüfung der Vorbedingung
a. Wenn der Inhalt von tt:[d-]cond ein Muster ist und die Vorbedingung using nicht erfüllt ist, wird das Element tt:[d-]cond übersprungen und das aktuelle Element des XML-Eingangsstroms konsumiert, ohne dass es deserialisiert wird. Wenn die Vorbedingung erfüllt ist, weiter mit Schritt 3.
b. Wenn der Inhalt von tt:[d-]cond kein Muster ist und die Vorbedingung using nicht erfüllt ist, wird die Deserialisierung mit der Ausnahme CX_ST_REF_ACCESS abgebrochen. Wenn die Vorbedingung erfüllt ist, weiter mit Schritt 3.
3. Auswertung des Instruktionsrumpfs
Der Rumpf der Instruktion wird ausgewertet. Dabei werden in der Regel Datenknoten deserialisiert. Deren Existenz oder Typ kann in Schritt 2 sichergestellt worden sein; das Ergebnis der Deserialisierung kann in Schritt 5 einer Plausibilitätsprüfung unterzogen werden.
4. Etablierung der Zusicherung
Allen Datenknoten, die in der Zusicherung data angegeben sind, wird der dort zugesicherte Wert zugewiesen. Wenn einem dieser Datenknoten während der Deserialisierung des aktuellen Elements des XML-Eingangsstroms ein anderer Wert zugewiesen wurde, wird die Deserialisierung mit der Ausnahme CX_ST_COND_CHECK_FAIL abgebrochen.
5. Überprüfung der Bedingung
Die Bedingung [d-]check wird überprüft. Wenn die Bedingung nicht erfüllt ist, wird die Deserialisierung mit der Ausnahme CX_ST_COND_CHECK_FAIL abgebrochen.
...
Wenn in tt:[d-]cond keines der drei möglichen Attribute using, data oder check angegeben ist, darf der Inhalt von tt:[d-]cond nicht leer sein und wird in Abhängigkeit davon, ob es sich um ein Muster handelt oder nicht, in Schritt 1 ausgewertet. Die übrigen Voraussetzungen (Schritt 3 bis 4) werden als erfüllt betrachtet.
Hinweise
● Über eine Zusicherung kann einem Datenknoten ein Wert zugewiesen werden, ohne dass dieser vom Eingangsstrom versorgt wird. Statt eines leeren Elements tt:[d-]cond sollte hierfür aber die Anweisung tt:assign verwendet werden.
● Mit einem leeren Element tt:[d-]cond kann während einer Deserialisierung der aktuelle Inhalt von Datenknoten überprüft werden.
● Mit einem Element tt:[d-]cond ohne explizite Bedingungen kann bei der Deserialisierung optionaler Inhalt gekennzeichnet werden. D.h., wenn ein Muster im XML-Eingangsstrom nicht vorhanden ist, wird dessen Auswertung übersprungen, ohne dass es zu einer Ausnahme kommt.
Beispiel
Die folgende Transformation demonstriert Bedingungen:
<tt:transform xmlns:tt="http://www.sap.com/transformation-templates">
<tt:root name="ROOT1"/>
<tt:root name="ROOT2"/>
<tt:root
name="ROOT3"/>
<tt:template>
<X>
<tt:d-cond>
<X0>
...
</X0>
</tt:d-cond>
<tt:d-cond
data="ROOT3=333"/>
<tt:cond using="type-I(ROOT1), type-I(ROOT2)"
data="ROOT1=111"
d-check="ROOT2<ROOT3">
<X1>
<tt:value
ref="ROOT1"/>
</X1>
<X2>
<tt:value
ref="ROOT2"/>
</X2>
</tt:cond>
<tt:cond
d-check="ROOT2>111"/>
</X>
</tt:template>
</tt:transform>
Wenn die an ROOT1 und ROOT2 angebundenen ABAP-Datenobjekte vom Typ i sind und ROOT1 den Wert 111 hat, erzeugt die Transformation unabhängig vom ABAP-Datenobjekt, das an Datenknoten ROOT3 angebunden ist, z.B. folgendes XML-Fragment:
<X>
<X1>111</X1>
<X2>222</X2>
</X>
Die gleiche Transformation kann dieses XML-Fragment deserialisieren, wobei ROOT3 auf den Wert 333 gesetzt wird. Die Deserialisierung scheitert, wenn X1 nicht den Wert 111 hat und X2 nicht zwischen 111 und 333 liegt. Das Element X0 der Transformation ist optional. Folgendes XML-Fragment wäre ebenfalls deserialisierbar:
<X>
<X0>...</X0>
<X1>111</X1>
<X2>222</X2>
</X>
Wenn das erste Unterelement des XML-Fragments aber einen anderen Namen als X0 hätte, käme es zur Ausnahme CX_ST_MATCH_ELEMENT.