Difference between revisions of "ExecutionPlan Variables"

From Gcube Wiki
Jump to: navigation, search
(External)
(Object Reflectable)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
=Variables=
 
=Variables=
While in the process of executing an [[ExecutionEngine#ExecutionPlan | ExecutionPlan]], the two main actors, are the elements that represent an execution step, either by controlling the flow of execution or by invoking some processing actor, and the second is the data that are provided to the actors as well as the results produced by these actors. This data is usually also the target of the execution. The data is stored as typed structures using the engine available [[ExecutionEngine_DataTypes | Data Types]].
+
While in the process of executing an [[ExecutionEngine#Execution_Plan | Execution Plan]], the two main actors, are the elements that represent an execution step, either by controlling the flow of execution or by invoking some processing actor, and the second is the data that are provided to the actors as well as the results produced by these actors. This data is usually also the target of the execution. The data is stored as typed structures using the engine available [[ExecutionEngine_DataTypes | Data Types]].
  
 
Wherever a plan element needs to define some association with some data stored in such a [[ExecutionEngine_DataTypes | Data Type]] it references it using a unique name. [[ExecutionEngine_DataTypes | Data Types]] are generally encapsulated as ''Named Data Types''. This encapsulation provides some additional metadata on the [[ExecutionEngine_DataTypes | Data Type]]. This metadata include a unique name by which the data are referenced. Additionally a grouping tag can be applied to a data type which can be used by some [[ExecutionPlan_Variables#Filters | Filters]] that operate on this data. Finally, a flag indicating that the data is available for usage is also included so that while in execution, no element will try to use some data that is not yet available.
 
Wherever a plan element needs to define some association with some data stored in such a [[ExecutionEngine_DataTypes | Data Type]] it references it using a unique name. [[ExecutionEngine_DataTypes | Data Types]] are generally encapsulated as ''Named Data Types''. This encapsulation provides some additional metadata on the [[ExecutionEngine_DataTypes | Data Type]]. This metadata include a unique name by which the data are referenced. Additionally a grouping tag can be applied to a data type which can be used by some [[ExecutionPlan_Variables#Filters | Filters]] that operate on this data. Finally, a flag indicating that the data is available for usage is also included so that while in execution, no element will try to use some data that is not yet available.
Line 6: Line 6:
 
''Named Data Types'' are considered as the '''Variables''' of a running execution plan. One of the [[ExecutionEngine#ExecutionPlan | ExecutionPlan]]'s root elements is a collection of '''Variables'''. These provide a global placeholder for all [[ExecutionPlan_Elements | Plan Elements]] to retrieve data from as well as to store data so that they are later on used by either a different [[ExecutionPlan_Elements | Plan Element]] or to be returned to the client. Access to this global collection is moderately supervised. This means that while the underlying data structures are protected from concurrent modifications, the actual synchronization is performed mainly by the access and timeplan dictated by the [[ExecutionEngine#ExecutionPlan | ExecutionPlan]]'s execution tree.
 
''Named Data Types'' are considered as the '''Variables''' of a running execution plan. One of the [[ExecutionEngine#ExecutionPlan | ExecutionPlan]]'s root elements is a collection of '''Variables'''. These provide a global placeholder for all [[ExecutionPlan_Elements | Plan Elements]] to retrieve data from as well as to store data so that they are later on used by either a different [[ExecutionPlan_Elements | Plan Element]] or to be returned to the client. Access to this global collection is moderately supervised. This means that while the underlying data structures are protected from concurrent modifications, the actual synchronization is performed mainly by the access and timeplan dictated by the [[ExecutionEngine#ExecutionPlan | ExecutionPlan]]'s execution tree.
  
This for example means that if two [[ExecutionPlan_Elements | Plan Elements]] share a variable, having one of the elements produce a value that is placed in the variable and the second element accessing it, the correct access to the variable is mainly enforced by the execution path that connects the two elements. If the the producing element is defined in the plan as a child of a [[ExecutionPlan_Elements#Sequence | Sequence]] node, and the consuming element is also a child of this element or some other element that preserves this ordering, the access will be safe. In the case though that for example the two elements are direct children of a [[ExecutionPlan_Elements#Flow | Flow]] element, there is nothing ensuring that the consuming element will access the variable after the producing element. As a last line of defense, the engine provides the above mentioned flag indicating that some variable is initialized and populated. This way some cases of mis-usage can be avoided and the execution stopped before corrupt data are used.
+
This for example means that if two [[ExecutionPlan_Elements | Plan Elements]] share a variable, having one of the elements produce a value that is placed in the variable and the second element accessing it, the correct access to the variable is mainly enforced by the execution path that connects the two elements. If the producing element is defined in the plan as a child of a [[ExecutionPlan_Elements#Sequence | Sequence]] node, and the consuming element is also a child of this element or some other element that preserves this ordering, the access will be safe. In the case though that for example the two elements are direct children of a [[ExecutionPlan_Elements#Flow | Flow]] element, there is nothing ensuring that the consuming element will access the variable after the producing element. As a last line of defense, the engine provides the above mentioned flag indicating that some variable is initialized and populated. This way some cases of mis-usage can be avoided and the execution stopped before corrupt data are used.
  
 
'''''XML definition'''''
 
'''''XML definition'''''
Line 118: Line 118:
 
The ''Object Reflectable'' filter is applicable only to [[ExecutionPlan_Variables#Variables | Variables]] of [[ExecutionEngine_DataTypes | Data Type]] ''Reflectable'' or ''Array'' with a component type of ''Reflectable''. In the former case, the serialization provided as the values source is processed to be used along with the target Object type that is to be populated with these values. The target Object type is provided also as an input [[ExecutionPlan_Variables#Variables | Variable]] of type ''String'' containing the qualified type name. The respective Object is inflated, populated and retrieved. In the later case, an array with a component type of the respective inflated Object is created with as many dimensions as dictated by the ''Array'' [[ExecutionEngine_DataTypes | Data Type]]. Every position of the generated array is filled with the Object inflated by the ''Reflectable'' in the corresponding ''Array'' position.
 
The ''Object Reflectable'' filter is applicable only to [[ExecutionPlan_Variables#Variables | Variables]] of [[ExecutionEngine_DataTypes | Data Type]] ''Reflectable'' or ''Array'' with a component type of ''Reflectable''. In the former case, the serialization provided as the values source is processed to be used along with the target Object type that is to be populated with these values. The target Object type is provided also as an input [[ExecutionPlan_Variables#Variables | Variable]] of type ''String'' containing the qualified type name. The respective Object is inflated, populated and retrieved. In the later case, an array with a component type of the respective inflated Object is created with as many dimensions as dictated by the ''Array'' [[ExecutionEngine_DataTypes | Data Type]]. Every position of the generated array is filled with the Object inflated by the ''Reflectable'' in the corresponding ''Array'' position.
  
The way the processing is performed to inflate the target Object is sketched at the [[ExecutionEngine_DataTypes | Data Types]] section. The token mapping facility is utilized byt this filter ad affects the process described there. The inflation process described finds a member of the inflated object named using the common part of matching getter and setters. If at the populating [[ExecutionPlan_Variables#Variables | Variable]] an item with the respective name is found, that it6em is used to set the respective value. In case a token mapping set is defined, this mapping will be used to replace the name of the Object's member with tha target name defined in the mapping if one exists for that name.
+
The way the processing is performed to inflate the target Object is sketched at the [[ExecutionEngine_DataTypes | Data Types]] section. The token mapping facility is utilized byt this filter ad affects the process described there. The inflation process described finds a member of the inflated object named using the common part of matching getter and setters. If at the populating [[ExecutionPlan_Variables#Variables | Variable]] an item with the respective name is found, that item is used to set the respective value. In case a token mapping set is defined, this mapping will be used to replace the name of the Object's member with the target name defined in the mapping if one exists for that name.
  
 
'''''XML definition'''''
 
'''''XML definition'''''

Latest revision as of 17:23, 25 November 2013

Variables

While in the process of executing an Execution Plan, the two main actors, are the elements that represent an execution step, either by controlling the flow of execution or by invoking some processing actor, and the second is the data that are provided to the actors as well as the results produced by these actors. This data is usually also the target of the execution. The data is stored as typed structures using the engine available Data Types.

Wherever a plan element needs to define some association with some data stored in such a Data Type it references it using a unique name. Data Types are generally encapsulated as Named Data Types. This encapsulation provides some additional metadata on the Data Type. This metadata include a unique name by which the data are referenced. Additionally a grouping tag can be applied to a data type which can be used by some Filters that operate on this data. Finally, a flag indicating that the data is available for usage is also included so that while in execution, no element will try to use some data that is not yet available.

Named Data Types are considered as the Variables of a running execution plan. One of the ExecutionPlan's root elements is a collection of Variables. These provide a global placeholder for all Plan Elements to retrieve data from as well as to store data so that they are later on used by either a different Plan Element or to be returned to the client. Access to this global collection is moderately supervised. This means that while the underlying data structures are protected from concurrent modifications, the actual synchronization is performed mainly by the access and timeplan dictated by the ExecutionPlan's execution tree.

This for example means that if two Plan Elements share a variable, having one of the elements produce a value that is placed in the variable and the second element accessing it, the correct access to the variable is mainly enforced by the execution path that connects the two elements. If the producing element is defined in the plan as a child of a Sequence node, and the consuming element is also a child of this element or some other element that preserves this ordering, the access will be safe. In the case though that for example the two elements are direct children of a Flow element, there is nothing ensuring that the consuming element will access the variable after the producing element. As a last line of defense, the engine provides the above mentioned flag indicating that some variable is initialized and populated. This way some cases of mis-usage can be avoided and the execution stopped before corrupt data are used.

XML definition

<variables>
  <ndt available="..." name="..." token="...">
    <dt .../>
  </ndt>
  ...
</variables>

Parameters

Access to Variables and their underlying Data Types is never performed directly from the Plan Elements. Access is always performed through Parameters. Parameters are distinguished based on their direction and the processing they are performing on the Variable and underlying Data Type before storing or accessing the actual data.

Based on the direction, Parameters can be separated to:

  • In parameter
    Data can be retrieved using this parameter
  • Out parameter
    Data can be stored using this parameter
  • InOut parameter
    Data can be retrieved and stored using this parameter

Based on the processing, Parameters can be separated to:

  • Simple
    Direct access to the underlying data is enabled
  • Filter
    Before retrieving, or storing, the parameter will apply a number of Filters

Filter parameters contain an ordered list of Filters. Every time such a parameter is requested to retrieve or store some data, it goes through the list of filters. After all the filtering steps are completed, the value is retrieved or stored depending on the parameter direction. At every intermediate filtering step intermediate data are produced which depending on the definition of the filter may also be stored.

XML definition

<param direction="In" process="Simple">
  <variable name="variable name"/>
</param>"
...
<param direction="Out" process="Simple">
  <variable name="variable name"/>
</param>"
...
<param direction="InOut" process="Simple">
  <variable name="variable name"/>
</param>"
...
<param direction="In" process="Filter">
  <filter .../>
  ...
</param>"
...
<param direction="Out" process="Filter">
  <updateVar name="variable name"/>
  <filter .../>
  ...
</param>"
...
<param direction="InOut" process="Filter">
  <updateVar name="variable name"/>
  <filter .../>
  ...
</param>"

Filters

One of the constructs that make the Execution Plan versatile and allows for generic Data Type transformations are the Filters described in this section. These filters can be used to compose filtered input and or output Parameters. This provides for on the fly transformations of Variables to be used by any Plan Element or for bulk "off line" processing using Processing Elements. The available filters come in a long range of complexity and applicability. These filters are presented in this section.

All the filters described bellow offer two common properties other than the additional ones each one of them provide. Firstly, they have the notion of order, in the sence that they can be composed in an ordered list to be sequentially executed. This way two or more filters can be composed to create more complex filters which can be found in filtered Parameters. Secondly, as will become evident from the following listing, in some of the filters, the attributes of Name and Token as presented in Variables and Data Types are utilized during the filtering process. There is an option to override the meaning of some of these Names and Tokens to alter the outcome of these filters. More will be presented in the filters that this feature can be utilized.

XSLT

The XSLT filter is the simpler and most powerful filter offering the possibility to apply a provided XSLT trasnformation on some Variables's payload. The outcome of the transformation is available at runtime and can also be requested to be stored in some Variable.

XML definition

<filter type="XSLT" order="..." storeOutput="true/false" storeOutputName="...">
  <filteredVariable>...</filteredVariable>
  <expressionVariable>...</expressionVariable>
  <tokenMap/>
</filter>

XPath

The XPath filter is another simple filter offering the possibility to apply an XPath expression on some Variables's payload. The outcome of the evaluation is available at runtime and can also be requested to be stored in some Variable. The outcome of the evaluation can be declared of being either a primitive value to be interpreted directly as a string literal or an XML fragment which in order to be stored needs to be serialized.

XML definition

<filter type="XPath" order="..." storeOutput="true/false" storeOutputName="...">
  <queryResultType>String/Node</queryResultType>
  <filteredVariable>...</filteredVariable>
  <expressionVariable>...</expressionVariable>
  <tokenMap/>
</filter>

Object Convertable

The Object Convertable filter is applicable only to Variables of Data Type Convertable or Array with a component type of Convertable. In the former case, the respective converter is loaded and the Object that corresponds to the serialization stored in the provided Variable is inflated and retrieved. In the later case, an array with a component type of the respective inflated Object is created with as many dimensions as dictated by the Array Data Type. Every position of the generated array is filled with the Object inflated by the Convertable in the corresponding Array position.

XML definition

<filter type="ObjectConvertable" order="..." storeOutput="true/false" storeOutputName="...">
  <filteredVariable>...</filteredVariable>
  <tokenMap/>
</filter>

Object Reflectable

The Object Reflectable filter is applicable only to Variables of Data Type Reflectable or Array with a component type of Reflectable. In the former case, the serialization provided as the values source is processed to be used along with the target Object type that is to be populated with these values. The target Object type is provided also as an input Variable of type String containing the qualified type name. The respective Object is inflated, populated and retrieved. In the later case, an array with a component type of the respective inflated Object is created with as many dimensions as dictated by the Array Data Type. Every position of the generated array is filled with the Object inflated by the Reflectable in the corresponding Array position.

The way the processing is performed to inflate the target Object is sketched at the Data Types section. The token mapping facility is utilized byt this filter ad affects the process described there. The inflation process described finds a member of the inflated object named using the common part of matching getter and setters. If at the populating Variable an item with the respective name is found, that item is used to set the respective value. In case a token mapping set is defined, this mapping will be used to replace the name of the Object's member with the target name defined in the mapping if one exists for that name.

XML definition

<filter type="ObjectReflectable" order="..." storeOutput="true/false" storeOutputName="...">
  <filteredVariable>...</filteredVariable>
  <targetReflectableVariable>...</targetReflectableVariable>
  <tokenMap>
    <map key="source name" value="target name"/>
    ...
  </tokenMap>
</filter>

XSLT From 1D Array

The XSLT From 1D Array filter bases its operation in XSLT transformations. A default transformation is available, but it can be overridden to offer different functionality. The default functionality aims at transforming an input Variable of Data Type Array to an xml serialization that can be presented as an array of values with an element name of the set of values as the one provided.

This filter is applicable in the following cases:

  • If the default transformation is used and
    • Source is array and target is set and not array
    • Source is array and target is set and is array
    • Source is array and target is not set
  • If the default transformation is overridden and
    • Source is array and target is set and not array
    • Source is array and target is set and is array
    • Source is array and target is not set
    • Source is not array target is set and is array

In the following cases the filter cannot be applied:

  • Source is not array and target is set and is not array
  • Source is not array and target is not set

The default XSLT is the following:

<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:for-each select="dt/value/array/item/dt/value">
      <$$tagValue$$><xsl:value-of select="."/><$$tagValue$$>
    </xsl:for-each>
  </xsl:template>
</xsl:stylesheet>

XML definition

<filter type="XsltFrom1DArray" order="..." storeOutput="true/false" storeOutputName="...">
  <filteredVariable>...</filteredVariable>
  <expressionVariable>...</expressionVariable> <!-- optional overriding XSLT -->
  <valueTagVariableName>...</valueTagVariableName>
  <tokenMap/>
</filter>

XSLT To 1D Array

The XSLT To 1D Array filter bases its operation in XSLT transformations. A default transformation is available, but it can be overridden to offer different functionality. The default functionality aims at transforming an input Variable containing an xml serialization that can be presented as an array of values to a Data Type of type Array. The component type of the target Array cannot be Reflectable while only one dimensional arrays are supported.

This filter is applicable in the following cases:

  • If the default transformation is used and
    • Source is array and target is set and not array
    • Source is array and target is not set
  • If the default transformation is overridden and
    • Source is array and target is set and not array
    • Source is array and target is not set
    • Source is array and target is set and is array
    • Source is not array and target is set and is array

In the following cases the filter cannot be applied:

  • Source is not array and target is set and is not array
  • Source is not array and target is not set

The default XSLT is the following:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <dt type="Array+">
      <value>
        <array code="$$target array code$$">
          <xsl:for-each select="$$valueIteration$$">
            <item>
              <dt type="$$target array component type$$">
                <value>
                  <xsl:value-of select="$$valueSelection$$"/>
                </value>
              </dt>
            </item>
          </xsl:for-each>
        </array>
      </value>
    </dt>
  </xsl:template>
</xsl:stylesheet>

XML definition

<filter type="XsltT1DoArray" order="..." storeOutput="true/false" storeOutputName="...">
  <filteredVariable>...</filteredVariable>
  <expressionVariable>...</expressionVariable> <!-- optional overriding XSLT -->
  <selectionVariableName>...</selectionVariableName>
  <iterationVariableName>...</iterationVariableName>
  <tokenMap/>
</filter>

Serialization

The Serialization filter is another simple filter offering the possibility to enrich an already available serialization with additional values based on token replacement. An input Variable acts as the template to enrich and a set of value providers are iterated and their values are used to populate the template based on their tokens. The set of token mappings can be used to override the token values of the value providers so that when they are iterated to match tokens, the target value is used if a mapping exists for their original token value.

XML definition

<filter type="Serialization" order="..." storeOutput="true/false" storeOutputName="...">
  <filteredVariable>...</filteredVariable>
  <tokenProviders>
    <var name="..."/>
  </tokenProviders>
  <tokenMap>
    <map key="initial name" value="target name"/>
    ...
  </tokenMap>
</filter>

Reflectable To Template

The Reflectable To Template filter can be applied to an input Variable of Data Type Reflectable or a Data Type Array of component type Reflectable. In the former case the Reflectable is processed using the provided template to serialize it in the way the template defines. In the later case, each item stored in the input Array will be processed as before and the results are concatenated.

The template follows a schema that is depicted in the following examples that progresivly become more complicated. Lets assume we have a Web Service with three methods that receive an argument of type TestContainer1, TestContainer2 and TestContainer3 with the following definitions:

public class TestWebService{
  ...
  public void TestMethod1(TestContainer1 value){
     ...
  }
  ...
  public void TestMethod2(TestContainer2 value){
     ...
  }
  ...
  public void TestMethod3(TestContainer3 value){
     ...
  }
}

Lets assume that the definitions of these three types, TestContainer1, TestContainer2 and TestContainer3 are the following:

public class TestContainer1{
  private boolean booleanField;
  private double doubleField;
  private float floatField;
  private String stringField;
 
  private boolean getBooleanField(){return this.booleanField;}
  private void setBooleanField(boolean value){this.booleanField=value;}
  private double getDoubleField(){return this.doubleField;}
  private void setDoubleField(double value){this.doubleField=value;}
  private float getFloatField(){return this.floatField;}
  private void setFloatField(float value){this.floatField=value;}
  private String getStringField(){return this.stringField;}
  private void setStringField(String value){this.StringField=value;}
}
public class TestContainer2{
  private TestContainer1 cont1;
  private TestContainer1 cont2;
  private int intPayload;
  private String stringPayload;
 
  private TestContainer1 getCont1(){return this.cont1;}
  private void setCont1(TestContainer1 value){this.cont1=value;}
  private TestContainer1 getCont2(){return this.cont2;}
  private void setCont2(TestContainer1 value){this.cont2=value;}
  private String getStringPayload(){return this.stringPayload;}
  private void setStringPayload(String value){this.StringPayload=value;}
  private int getIntPayload(){return this.intPayload;}
  private void setIntPayload(int value){this.intPayload=value;}
}
public class TestContainer3{
  private TestContainer1 cont1;
  private TestContainer2 cont2;
  private TestContainer1 []cont3;
  private String plainStringPayload;
  private String []stringPayload;
  private int []intPayload;
 
  private TestContainer1 getCont1(){return this.cont1;}
  private void setCont1(TestContainer1 value){this.cont1=value;}
  private TestContainer2 getCont2(){return this.cont2;}
  private void setCont2(TestContainer2 value){this.cont2=value;}
  private TestContainer1 []getCont3(){return this.cont3;}
  private void setCont3(TestContainer1 []value){this.cont3=value;}
  private String getPlainStringPayload(){return this.plainStringPayload;}
  private void setPlainStringPayload(String value){this.plainStringPayload=value;}
  private String []getStringPayload(){return this.stringPayload;}
  private void setStringPayload(String []value){this.stringPayload=value;}
  private int []getIntPayload(){return this.intPayload;}
  private void setIntPayload(int []value){this.intPayload=value;}
}

The respective templates to be used in this filter in order to generate the serialization from the respective Reflectables stored in the input Variables would be the following for the previous three types.

<refl>" +
  <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4">
    <ax21:cont xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1">
      <ax21:booleanField>tok1</ax21:booleanField>
      <ax21:doubleField>tok2</ax21:doubleField>
      <ax21:floatField>tok3</ax21:floatField>
      <ax21:stringField>tok4</ax21:stringField>
    </ax21:cont>
  </item>
</refl>
<refl>
  <item type="literal" isxml="false">
    &lt;ax21:cont xmlns:ax21=&quot;http://some.namespace.url/xsd&quot; type=&quot;some.package.name.TestContainer1&quot;&gt;
  </item>
  <item type="refl" token=\"ContTok1\">
    <refl>
      <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4">
        <ax21:cont1 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1">
          <ax21:booleanField>tok1</ax21:booleanField>
          <ax21:doubleField>tok2</ax21:doubleField>
          <ax21:floatField>tok3</ax21:floatField>
          <ax21:stringField>tok4</ax21:stringField>
        </ax21:cont1>
      </item>
    </refl>
  </item>
  <item type="refl" token="ContTok2">
    <refl>
      <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4">
        <ax21:cont2 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1">
          <ax21:booleanField>tok1</ax21:booleanField>
          <ax21:doubleField>tok2</ax21:doubleField>
          <ax21:floatField>tok3</ax21:floatField>
          <ax21:stringField>tok4</ax21:stringField>
        </ax21:cont2>
      </item>
    </refl>
  </item>
  <item type="literal" isxml="false" tokenSeparator="--" tokens="tok5--tok6">
    &lt;ax21:intPayload&gt;tok5&lt;/ax21:intPayload&gt;
    &lt;ax21:stringPayload&gt;tok6&lt;/ax21:stringPayload&gt;
    &lt;/ax21:cont&gt;
  </item>
</refl>
<refl>
  <item type="literal" isxml="false">
    &lt;ax21:cont xmlns:ax21=&quot;http://some.namespace.url/xsd&quot; type=&quot;some.package.name.TestContainer3&quot;&gt;
  </item>
  <item type="array" token="tok7">
    <item type="literal" isxml="true" tokenSeparator="--" tokens="tok7">
      <ax21:stringPayload xmlns:ax21="http://some.namespace.url/xsd">tok7</ax21:stringPayload>
    </item>
  </item>
  <item type="array" token="tok8">
    <item type="literal" isxml="true" tokenSeparator="--" tokens="tok8">
      <ax21:intPayload xmlns:ax21="http://some.namespace.url/xsd">tok8</ax21:intPayload>
    </item>
  </item>
  <item type="array" token="ContTok3">
    <item type="refl" token="ContTok3">
      <refl>
        <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4">
          <ax21:cont3 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1">
            <ax21:booleanField>tok1</ax21:booleanField>
            <ax21:doubleField>tok2</ax21:doubleField>
            <ax21:floatField>tok3</ax21:floatField>
            <ax21:stringField>tok4</ax21:stringField>
          </ax21:cont3>
        </item>
      </refl>
    </item>
  </item>
  <item type="refl" token="ContTok1">
    <refl>
      <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4">
        <ax21:cont1 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1">
          <ax21:booleanField>tok1</ax21:booleanField>
          <ax21:doubleField>tok2</ax21:doubleField>
          <ax21:floatField>tok3</ax21:floatField>
          <ax21:stringField>tok4</ax21:stringField>
        </ax21:cont1>
      </item>
    </refl>
  </item>
  <item type="literal" isxml="true" tokenSeparator="--" tokens="tok9">
    <ax21:plainStringPayload xmlns:ax21="http://some.namespace.url/xsd">tok9</ax21:plainStringPayload>
  </item>
  <item type="refl" token="ContTok2">
    <refl>
      <item type="literal" isxml="false">
        &lt;ax21:cont2 xmlns:ax21=&quot;http://some.namespace.url/xsd&quot; type=&quot;some.package.name.TestContainer2&quot;&gt;
      </item>
      <item type="refl" token="ContTok1">
        <refl>
          <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4">
            <ax21:cont1 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1">
              <ax21:booleanField>tok1</ax21:booleanField>
              <ax21:doubleField>tok2</ax21:doubleField>
              <ax21:floatField>tok3</ax21:floatField>
              <ax21:stringField>tok4</ax21:stringField>
            </ax21:cont1>
          </item>
        </refl>
      </item>
      <item type="refl" token="ContTok2">
        <refl>
          <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4">
            <ax21:cont2 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1">
              <ax21:booleanField>tok1</ax21:booleanField>
              <ax21:doubleField>tok2</ax21:doubleField>
              <ax21:floatField>tok3</ax21:floatField>
              <ax21:stringField>tok4</ax21:stringField>
            </ax21:cont2>
          </item>
        </refl>
      </item>
      <item type="literal" isxml="false" tokenSeparator="--" tokens="tok5--tok6">
        &lt;ax21:intPayload&gt;tok5&lt;/ax21:intPayload&gt;
        &lt;ax21:stringPayload&gt;top6&lt;/ax21:stringPayload&gt;
        &lt;/ax21:cont2&gt;
      </item>
    </refl>
  </item>
  <item type="literal" isxml="false">
    &lt;/ax21:cont&gt;
  </item>
</refl>

The set of token mappings can be used to override the token values of the input Reflectables so that when they are iterated to match the template, the target value is used if a mapping exists for their original token value.

XML definition

<filter type="ReflectableToTemplate" order="..." storeOutput="true/false" storeOutputName="...">
  <filteredVariable>...</filteredVariable>
  <templateVariable>...</templateVariable>
  <tokenMap>
    <map key="initial name" value="target name"/>
    ...
  </tokenMap>
</filter>

Reflectable From Template

The Reflectable From Template filter can be applied to an input Variable of which its string representation is used to populate another inpout value acting as a template. This template infated using these values generate an output which is of Data Type Reflectable or Array of Reflectables.

The template follows a schema that is depicted in the following examples that progressively become more complicated. Lets assume we have a Web Service with three methods that return values of type TestContainer1, TestContainer2 and TestContainer3 with the following definitions:

public class TestWebService{
  ...
  public TestContainer1 TestMethod1(){
     ...
  }
  ...
  public TestContainer2 TestMethod2(){
     ...
  }
  ...
  public TestContainer3 TestMethod3(){
     ...
  }
}

For the sake of brevity, we will assume that the definitions of these types are as the ones described in Reflectable To Template filter example.

The respective templates to be used in this filter in order to inflate the respective Reflectable or Array of Reflectables to be stored in the output Variable would be the following for the previous three types.

The set of token mappings can be used to override the token values of the input serialization so that when they are iterated to match the template, the target value is used if a mapping exists for their original token value.

<refl name=return" ns="http://some.namespace.url">
  <item name="tok1" token="booleanField" ns="http://some.namespace.url/xsd" type="BooleanPrimitive"/>
  <item name="tok2" token="doubleField" ns="http://some.namespace.url/xsd" type="DoublePrimitive"/>
  <item name="tok3" token="floatPField" ns="http://some.namespace.url/xsd" type="FloatPrimitive"/>
  <item name="tok4" token="stringField" ns="http://some.namespace.url/xsd" type="String"/>
</refl>
<refl name="return" ns="http://some.namespace.url">
  <item name="Cont1" token="cont1" ns="http://some.namespace.url/xsd" type="Reflectable">
    <refl name="cont1" ns="http://some.namespace.url/xsd">
      <item name="tok1" token="booleanField" ns="http://some.namespace.url/xsd" type="BooleanPrimitive"/>
      <item name="tok2" token="doubleField" ns="http://some.namespace.url/xsd" type="DoublePrimitive"/>
      <item name="tok3" token="floatPField" ns="http://some.namespace.url/xsd" type="FloatPrimitive"/>
      <item name="tok4" token="stringField" ns="http://some.namespace.url/xsd" type="String"/>
    </refl>
  </item>
  <item name="Cont2" token="cont2" ns="http://some.namespace.url/xsd" type="Reflectable">
    <refl name="cont2" ns="http://some.namespace.url/xsd">
      <item name="tok1" token="booleanField" ns="http://some.namespace.url/xsd" type="BooleanPrimitive"/>
      <item name="tok2" token="doubleField" ns="http://some.namespace.url/xsd" type="DoublePrimitive"/>
      <item name="tok3" token="floatPField" ns="http://some.namespace.url/xsd" type="FloatPrimitive"/>
      <item name="tok4" token="stringField" ns="http://some.namespace.url/xsd" type="String"/>
    </refl>
  </item>
  <item name="tok5" token="intPayload" ns="http://some.namespace.url/xsd" type="IntegerPrimitive"/>
  <item name="tok6" token="stringPayload" ns="http://some.namespace.url/xsd" type="String"/>
</refl>
<refl name="return" ns="http://some.namespace.url/xsd">
  <item name="tok9" token="plainStringPayload" ns="http://some.namespace.url/xsd" type="String"/>
  <array name="tok8" ns="http://some.namespace.url/xsd">
    <item name="tok8" token="intPayload" ns="http://some.namespace.url/xsd" type="IntegerPrimitive"/>
  </array>
  <array name="tok7" ns="http://some.namespace.url/xsd">
    <item name="tok7" token="stringPayload" ns="http://some.namespace.url/xsd" type="String"/>
  </array>
  <item name="Cont1" token="cont1" ns="http://some.namespace.url/xsd" type="Reflectable">
    <refl name="cont1" ns="http://some.namespace.url/xsd">
      <item name="tok1" token="booleanField" ns="http://some.namespace.url/xsd" type="BooleanPrimitive"/>
      <item name="tok2" token="doubleField" ns="http://some.namespace.url/xsd" type="DoublePrimitive"/>
      <item name="tok3" token="floatPField" ns="http://some.namespace.url/xsd" type="FloatPrimitive"/>
      <item name="tok4" token="stringField" ns="http://some.namespace.url/xsd" type="String"/>
    </refl>
  </item>
  <array name="Cont3" ns="http://some.namespace.url/xsd">
    <refl name="cont3" ns="http://some.namespace.url/xsd">
      <item name="tok1" token="booleanField" ns="http://some.namespace.url/xsd" type="BooleanPrimitive"/>
      <item name="tok2" token="doubleField" ns="http://some.namespace.url/xsd" type="DoublePrimitive"/>
      <item name="tok3" token="floatPField" ns="http://some.namespace.url/xsd" type="FloatPrimitive"/>
      <item name="tok4" token="stringField" ns="http://some.namespace.url/xsd" type="String"/>
    </refl>
  </array>
  <item name="Cont2" token="cont2" ns="http://some.namespace.url/xsd" type="Reflectable">
    <refl name="cont2" ns="http://some.namespace.url/xsd">
      <item name="Cont1" token="cont1" ns="http://some.namespace.url/xsd" type="Reflectable">
        <refl name="cont1" ns="http://some.namespace.url/xsd">
          <item name="tok1" token="booleanField" ns="http://some.namespace.url/xsd" type="BooleanPrimitive"/>
          <item name="tok2" token="doubleField" ns="http://some.namespace.url/xsd" type="DoublePrimitive"/>
          <item name="tok3" token="floatPField" ns="http://some.namespace.url/xsd" type="FloatPrimitive"/>
          <item name="tok4" token="stringField" ns="http://some.namespace.url/xsd" type="String"/>
        </refl>
      </item>
      <item name="Cont2" token="cont2" ns="http://some.namespace.url/xsd" type="Reflectable">
        <refl name="cont2" ns="http://some.namespace.url/xsd">
          <item name="tok1" token="booleanField" ns="http://some.namespace.url/xsd" type="BooleanPrimitive"/>
          <item name="tok2" token="doubleField" ns="http://some.namespace.url/xsd" type="DoublePrimitive"/>
          <item name="tok3" token="floatPField" ns="http://some.namespace.url/xsd" type="FloatPrimitive"/>
          <item name="tok4" token="stringField" ns="http://some.namespace.url/xsd" type="String"/>
        </refl>
      </item>
      <item name="tok5" token="intPayload" ns="http://some.namespace.url/xsd" type="IntegerPrimitive"/>
      <item name="tok6" token="stringPayload" ns="http://some.namespace.url/xsd" type="String"/>
    </refl>
  </item>
</refl>

XML definition

<filter type="ReflectableFromTemplate" order="..." storeOutput="true/false" storeOutputName="...">
  <filteredVariable>...</filteredVariable>
  <templateVariable>...</templateVariable>
  <tokenMap>
    <map key="initial name" value="target name"/>
    ...
  </tokenMap>
</filter>

Compose

The Compose filter is another filter offering the possibility to combine a set of input Variables into a single one. The provided input Variables may by of any Data Type including Arrays of different length although they should be one dimensional. The filter processes the types of inputs and decides if the combination of the types should be a single object or an array of objects. To control this decision one can also request to promote array creation. If it is requested not to promote arrays, even if the input types are arrays, the combined object will not be an array. Otherwise, if at least one of the provided types is an array, the result will be an array. The length of the created array will be equal to the minimum length of the provided arrays. The rest of the values of the input arrays will be discarded. If an array is constructed but some of the inputs are not arrays, then the same value is used to fill all array positions. The Data Type of the composed object that is created solely is of type Reflectable. If the created object is of type Array it has a component type of Reflectable. This Reflectable is the composition of the respective values from each input.

The set of token mappings can be used to override the token values of the value providers so that when they are composed into a single object, the token value they will have will be the one defined by the token mappin instead of the original token they had as input.

XML definition

<filter type="Compose" order="..." storeOutput="true/false" storeOutputName="..." promoteArray="true/false">
  <filteredList>
    <filteredVariable name="..."/>
    ...
  </filteredList>
  <tokenMap>
    <map key="initial name" value="target name"/>
    ...
  </tokenMap>
</filter>

Decompose

The Decompose filter is another filter offering the possibility to decompose a single input to a set of output Variables. The provided input Variables may by of Data Type Reflectable or an Array of component type Reflectable'. In case the input is of type Reflectable, the filter will iterate over its first level items scanning the tokens of these items. Should these tokens match the respective tokens of one of the provided outputs and their Data Type match, this item's value is set to the output. In case the input is an Array of Reflectables, the array is iterated and for each element of the array, the first level items are scanned to match with tokens of desired output, as before. In case of match, instead of directly setting the values as before, a temporary array is created for each of the desired output variable and each matching item found in the previous step is placed there. After this process is completed, the output variables are iterated again and in case the output is of type Array, the constructed list is set as its value. If the output is not of type Array, only the first value of the list is used to set the items value.

The set of token mappings can be used to override the token values of the value providers so that when they are iterated to locate the first level input items that match the desired output variables, the token value that will be used will be the one defined by the token mapping instead of the original token it had as input.

This filter does not have the store output option as there are multiple outputs. The default behavior of this filter is to store all outputs it produces.

XML definition

<filter type="Decompose" order="...">
  <filteredVariable>...</filteredVariable>
  <outputList>
    <outputVariable name="..."/>
    ...
  </outputList>
  <tokenMap>
    <map key="initial name" value="target name"/>
    ...
  </tokenMap>
</filter>

External

The External filter is provided to give the possibility for applications outside the Execution Engine to define their own custom filters. Applications can define their own filters implementing a required interface and be available at the execution container that the specific filter will be needed. Examples of this utility are the filters defined by the filters provided by the WorkflowGridAdaptor.

The set of token mappings is available to be used by the external filter if requested.

XML definition

<filter type="External" order="...">
  <external type="class name of external filter"...>
  ...
  </external>
  <tokenMap>
    <map key="initial name" value="target name"/>
    ...
  </tokenMap>
</filter>