Conditional Transformations (SAP Library

Conditional Transformations

Conditional transformations are parts of ST programs that are considered during program execution only if certain prerequisites are met. Usually conditional transformations are used as cases in tt:switch and tt:group.

A conditional transformation is realized as the content of an element tt:[s-|d-]cond:

<tt:[s-|d-]cond [using="precond"] [data="assertion"] [[s-|d-]check="cond"]>
...
</tt:[s-|d-]cond>

The content of tt:[s-|d-]cond is processed depending on a

· Precondition precond

· Assertion assertion

· Condition cond

The following applies:

· The element tt:cond is evaluated during serialization and deserialization.

· The element tt:s-cond is evaluated only during serialization and skipped during deserialization. The content of tt:s-cond is never deserialized.

· The element tt:d-cond is evaluated only during deserialization and skipped during serialization. The content of tt:d-cond is never serialized.

The condition cond can also be used directionally:

· The condition check is evaluated during serialization and deserialization.

· The condition s-check is evaluated only during serialization.

· The condition d-check is evaluated only during deserialization.

It makes no sense to specify s-check in tt:d-cond or d-checkin tt:s-cond.

If the content of tt:[s-|d-]cond is no pattern, you must specify at least one attribute using, data or check.

Serialization

During serialization, the

...

1. precondition

2. assertion

3. condition

are evaluated. The content of element tt:[s-]condis serialized onyl if all three prerequisites are met; otherwise the comparison is terminated at the first false prerequisite and the content of tt:[s-]condis skipped.

If in tt:[s-]cond none of the three possible attributes is specified, the prerequisite is considered to be met. If the content of tt:[s-]cond is empty during serialization, the element is not considered.

Deserialization

During deserialization, before and during the check of the precondition the system distinguishes whether or not the content of tt:[d-]cond is a pattern. The deserialization proceeds as follows:

...

1. Check whether the content of tt:[d-]cond is a pattern.

a. If the content of tt:[d-]cond is a pattern, it is compared to the current element of the XML inbound stream. If the pattern does not fit onto the current element, the element tt:[d-]cond is skipped and the current element of the XML inbound stream is not consumed; otherwise Step 2 follows.

b. If the content of tt:[d-]cond is no pattern, Step 2 follows.

2. Check the precondition

a. If the content of tt:[d-]condis a pattern and the precondition using is not fulfilled, the element tt:[d-]cond is skipped and the current element of the XML inbound stream is consumed without being deserialized. If the precondition is fulfilled, Step 3 follows.

b. If the content of tt:[d-]cond is no pattern and the precondition using is not fulfilled, the deserialization is terminated with the exception CX_ST_REF_ACCESS. If the precondition is fulfilled, Step 3 follows.

3. Evaluation of the instruction body.

The body of the instruction is evaluated. In this process, data nodes are deserialized. Their existence or type can have been checked in Step; the result of the deserialization can be checked for plausibility in Step 5.

4. Establish the assertion

To all data nodes specified in the dataassertion, the value asserted there is assigned. If to one of these data nodes during deserialization of the current element of the inbound stream a different value is assigned, the deserialization is terminated with exception CX_ST_COND_CHECK_FAIL.

5. Check the condition

The condition [d-]check is checked. If the condition is not fulfilled, the deserialization is terminated with exception CX_ST_COND_CHECK_FAIL.

...

If in tt:[d-]cond none of the three possible attributes using, data or check is specified, the content of tt:[d-]cond must not be empty; it is evaluated in Step 1, depending on whether or not it is a pattern. The other prerequisites (Steps 3 to 4) are considered to be fulfilled.

Notes

· You can use an assertion to assign a value to a data node without the node being filled by the inbound stream. Instead of an empty element tt:[d-]cond you should use the statement tt:assign in this case.

· You can use the empty element tt:[d-]condto check the current content of data nodes during deserialization.

· Use an element tt:[d-]condwithout explicit conditions to flag optional content during deserialization. This means, if a pattern does not exist in the XML inbound stream, its evaluation is skipped without triggering an exception.

Example

The transformation below shows conditions:

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

<tt:root name="ROOT1"/>
<tt:root name="ROOT2"/>
<tt:root name="ROOT3"/>

<tt:template>
    <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"/>
</tt:template>
</tt:transform>

If the ABAP data objects bound to ROOT1 and ROOT2 are of type i and ROOT1 has the value 111, then the transformation generates the following XML fragment, independent of the ABAP data object bound to the data root ROOT3:

The same transformation can deserialize this XML fragment, thereby setting ROOT3 to value 333. The deserialization fails if X1 does not have value 111 and if X2 does not lie between 111 and 333. The element X0 of the transformation is optional. It would also be possible to deserialize the following XML fragment:

However, if the first element of the XML fragment has a name other than X0, the exception CX_ST_MATCH_ELEMENT would be triggered.