Difference between revisions of "ExecutionPlan Elements"

From Gcube Wiki
Jump to: navigation, search
(Wait)
(Try Catch Finally)
Line 156: Line 156:
  
 
==Try Catch Finally==
 
==Try Catch Finally==
 +
The ''Try Catch Finally'' construct acts as the common programmatic '''try/catch/finally''' block of execution. During execution the sub element that is declared in the ''try'' block is executed. In case an exception is caught, the ''catch'' blocks are iterated to match the exception caught with one of the handled ones. If some ''catch'' block can handle the exception, the sub element defined in that block is executed. If the selected ''catch'' block does not define that the exception is re-thrown after the execution of the compensation code, the execution is moved to the  ''finally'' block sub element. If however the exception is to be re-thrown or a new exception is thrown from the compensation code, the exception is bubbled up after the ''finally'' block is executed.
 +
 
==Checkpoint==
 
==Checkpoint==
 
==Processing==
 
==Processing==

Revision as of 16:11, 9 February 2010

Overview

All plan elements are automatically assigned with an unique identifier through which they are retrievable and identified. Additionally, all elements can be assigned with a name that they use when emitting progress events. This way the execution monitoring can be made more user friendly.

The elements listed below can be roughly separated in two large categories based on the position they may have in the execution tree.

All the Nodes elements have placeholders where other elements, either Nodes themselves or Leafs can be plugged in. The Leafs on the other hand can be plugged in other Nodes but the execution plan path ends to them.

Plan Elements

Sequence

The Sequence construct offers a simple ordering utility for a set of execution steps. This element is a simple container maintaining the order of execution of its sub elements. When executed, the ordered list of sub elements is executed one after the other and the Sequence element is completed when its last sub-element is completed.

XML definition

<planElement id="element id" name="element name" type="Sequence">
  <list>
    <planElement .../>
    <planElement .../>
    <planElement .../>
    ...
  </list>
</planElement>

Flow

The Flow construct offers a simple parallelization utility for a set of execution steps. This element is a simple container maintaining a set of sub elements that can be executed in parallel. When executed, the set of sub elements are executed all at once in parallel and the Flow only completed when all the sub elements that have started are terminated. If one of the elements is terminated with an error, after all the elements have terminated, the exception indicating the error is re-thrown. If more than one elements finished with an error, only the first error found iterating through the set of sub elements is thrown.

XML definition

<planElement id="element id" name="element name" type="Flow">
  <list>
    <planElement .../>
    <planElement .../>
    <planElement .../>
    ...
  </list>
</planElement>

Bag

The Bag construct acts as a container of other sub elements. It orchestrates their execution based on their execution preconditions. These elements as well as their conditions are evaluated every time one of the previously running elements have completed their execution. While this element is executing every time an element previously running has terminated the set of not yet run elements is scanned. If no element can be run while no more elements are still running, the process is terminated if such a behavior is requested. Even if more elements are still running, if termination condition is set and is evaluated to true, the execution of the element is terminated. This condition follows the syntax defined by Execution Conditions. The execution preconditions of each element also follow the syntax defined by Execution Conditions.

XML definition

<planElement id="element id" name="element name" type="Bag">
  <list>
    <bagElement>
      <planElement ... />
      <conditionTree .../>
    </bagElement>
    <bagElement>
      <planElement ... />
      <conditionTree .../>
    </bagElement>
    ...
  </list>
  <termination onNoProgress="true">
    <conditionTree .../>
  </termination>
</planElement>

Know issues

It is possible that if it has not been requested for the Bag to terminate when no progress can be made, and the termination condition, if set, does not cover this case, that the Bag element will never terminate its execution.

Furthermore, currently the execution conditions of the bag's elements are only evaluated once at the beginning of the execution and then every time a previously running element terminates. This means that even if some execution condition is not dependent of some other element being terminated, it will not be discovered before that.

File Transfer

The File Tranfer construct can be used to mediate at the execution level the staging of files to and from the StorageSystem. The transfer can have a direction of either Store or Retrieve. In case the direction is Store, the File Tranfer utility expects as input the file path that is to be stored in the StorageSystem and is located in the same hosting machine as the one executing the element. After the operation is completed, the output of the File Transfer will be the identifier assigned to the stored file by the StorageSystem. In case the direction is Retrieve, the input is expected to be the identifier of the document that is stored in the StorageSystem and after the execution, the output of Filte Transfer will have the local filename where the document is stored.

When the File Transfer direction is Retrieve it is also possible to define a MoveTo parameter that can dictate a new filename to rename the retrieved file to. Additionally, the permission attributes of the retrieved file can also be set. A simplified IsExecutable flag can be used to make the file executable, but the more flexible Permissions field can be used to set the full permissions of the file. For these permissions the common four digit UNIX format is used.

XML definition

<planElement id="element id" name="element name" type="FileTransfer">
  <input ... />
  <output ... />
  <direction value="Store"/>
</planElement>
 
<planElement id="element id" name="element name" isexec="true" type="FileTransfer">
  <input ... />
  <output ... />
  <direction value="Retrieve"/>
  <mvto ... />
  <perms value="0700"/>
</planElement>

Conditional

The Conditional construct represents a set of flows that are only executed in case their respective conditions are met. The element follows the known pattern of if/else if/else construct. The if and else if flows are only executed in case their respective conditions are met. The else flow is only executed , if defined, if none of the if and else if flows have been executed. When the execution is started, the conditions of the flows are initialized and evaluated in turn until the first condition that is evaluated to true is found. The respective flow is executed. If none of the conditions are met, the else flow is executed if available. The conditions defined follow the syntax defined by Execution Conditions.

XML definition

<planElement id="element id" name="element name" type="Conditional">
  <if>
    <conditionalFlow>
      <conditionTree ... />
      <planElement ... />
    </conditionalFlow>
  </if>
  <elif>
    <conditionalFlow>
      <conditionTree ... />
      <planElement ... />
    </conditionalFlow>
    ...
  </elif>
  <else>
    <planElement ... />
  </else>
</planElement>

Loop

The Loop construct acts as a container of a sub plan which is executed iteratively until the loop condition defined is evaluated to false. If during the execution of the sub plan a break is caught, the loop is terminated without bubbling up the exception. The loop condition defined follows the syntax defined by Execution Conditions.

XML definition

<planElement id="element id" name="element name" type="Loop">
  <conditionTree ... />
  <planElement ... />
</planElement>

Break

The Break construct is simply used to be able to declare the termination of the execution before all its steps are completed or to break from a loop present somewhere higher in the hierarchy.

XML definition

<planElement id="element id" name="element name" type="Break">
  <message>...</message>
</planElement>

Wait

The Wait construct is simply used to pause the thread of execution that contains this element for a specific period of time. Although used by it self, the element can have some usability, it is expected to be used in conjunction with one of the condition enabled elements such as the ExecutionPlan_Elements#Loop element in such a way as to be able to define execution pausing until some condition is met.

XML definition

<planElement id="element id" name="element name" type="Wait">
  <wait value="..."/>
</planElement>

Try Catch Finally

The Try Catch Finally construct acts as the common programmatic try/catch/finally block of execution. During execution the sub element that is declared in the try block is executed. In case an exception is caught, the catch blocks are iterated to match the exception caught with one of the handled ones. If some catch block can handle the exception, the sub element defined in that block is executed. If the selected catch block does not define that the exception is re-thrown after the execution of the compensation code, the execution is moved to the finally block sub element. If however the exception is to be re-thrown or a new exception is thrown from the compensation code, the exception is bubbled up after the finally block is executed.

Checkpoint

Processing

Boundary

Web Service

Java Object (POJO)

Shell Script