The Ant task allows Ant build files, as described by the Apache Foundation, to be launched from within a job. Ant is extremely flexible, allowing file operations, ftp, mail etc. to be coordinated. In order to use the Ant task, you need only define the location of the Ant file (typically called build.xml) that you wish to launch. Optionally, you can specify the name of the target within the build file that should be executed. If no target is named, then the default target will be chosen. Please see the Ant manual at http://ant.apache.org/manual/ for more details on the Ant file format and options.

The CallJob task allows one job (master) to invoke another (child). The child job is identified by name, and may have parameters passed to it to control its execution. When the CallJob task is executed within the master job, it locates the child job by name and executes it within the scope of the master job. This means all parameters, scripts etc. of the master job are available to the child. In addition, the child job will write it's log to the master job log. This task will only complete when the child job has completed.

The DataLoop task is a composite task that executes each of the child tasks sequentially. The DataLoop has a datasource that supplies records. For each record, the DataLoop will set the execution scope to include the record fields, so they can be accessed by name from the children. The children will then be executed sequentially. The process will repeat until all records in the datasource have been used. In order for users to know that the datasource is valid, the fields of the datasource will be displayed under Schema, as shown in Figure 2.4, “DataLoop”. If not, the text in the Name field will be red in colour.

Figure 2.4. DataLoop

The Echo task allows information to be written to the log. As with all tasks, text values may include variable substitution strings of the form ${Name} which will be replaced by the appropriate parameter value during execution. This is useful for logging progress of a job and also for debugging. For example, you can echo a message such as

Job run by ${User} to render ${Report}

The FileLoop task is a composite task that executes each of the child tasks sequentially. The FileLoop requires the name of a folder in the repository. You can also define file criteria that allow the files within the folder to be filtered, for example by extension or modification date. The FileLoop will iterate through all files and execute the child tasks sequentially, once for each file that matches the criteria. While executing the children, the loop makes available the current filename so that it can be used in variable substitutions. The name of the variable is taken from the Parameter Name value defined in the task panel, the default name is FileName. If no criteria are entered, all files in the folder will be used. Selecting the Recursive option repeats the process for all subdirectories under the chosen folder.

The GenerateData task invokes an Elixir Data Designer's Composite DataSource to output to one of its DataStores. The name of the datasource is required, along with the name of the datastore within it that is to receive the records. It is also possible to pass parameters with the invocation which are then accessible within the datasource. Note that only parameters explicitly identified in the GenerateData task will be passed to the datasource - those defined within the scope of the job are not implicitly available to the Ensemble engine.

The Loop task is a composite task that executes each of the child tasks sequentially. The loop requires a simple repeat count that indicates the number of times the children should be executed. If there are three children, A,B and C, and the repeat count is two, then the sequence of execution will be A,B,C,A,B,C. Loop has two common uses, first, to skip a set of tasks, and second to perform the same tasks repeatedly, for example for performance testing or benchmarking.

The Parallel task is a composite task that executes all of the child tasks at the same time. Each child task runs as a separate thread and the parallel task will not complete until all of the child tasks have completed. This task allows a thread count to be specified. If no count is given then each child task runs in a separate thread. Otherwise a pool of threads is created and each child task uses a thread from the pool when it is available. For example, by using a thread count of two, only two of the child tasks would be running simultaneously.

The RenderReport task invokes the Elixir Report engine to render a report on the server. The required information includes the report name, the chosen target on the server and the mime-type that is required. Additional parameters may be passed to the report and to the target. Report parameters would include information needed to control the datasource or rendering process. Target parameters would include information needed by the chosen target. For example, if the target is a directory, a target parameter would usually be used for the filename. Alternatively, if the target is an email, a target parameter might be needed to identify the recipient (this depends on how the target is configured on the server - i.e. whether the recipient name has been pre-defined). Note that only parameters explicitly identified in the RenderReport task will be passed to the rendering engine - those defined within the scope of the job are not implicitly available.

When user tries to change to another report, there is a possibility that there will new parameters listed under Target. As a result, there will be presence of unnecessary parameters. To resolve this, user can right-click within the list of parameters and an option, Clear unused parameters, will help to delete parameters that are not required.

The Script task allows Elixir Schedule Designer to invoke JavaScript and Java codes within the job. Variable substitutions of ${Name} variables is performed before executing the code.

After the SendMail task is created, the email panel is empty. You will need to fill up From and To field in order to send out an email. The rest of the fields are optional.

The user can right-click in the Message field to find the list of parameters that can be embedded in the email. The parameters are evaluated and substituted with real values on the server side before the email is being sent out. If there are no parameters available, the popup menu will show No available parameters. If the the user define some parameters in the task that encloses the SendMail task (such as the job), he will also be able to find the parameters in the popup menu. However, disabled parameters defined in the job will not be shown in the popup menu. Only enabled parameters are shown.

The user can click on the Add button in the email panel to add attachments. Add more than one attachment by clicking on Add again. To remove the attachment, simple click on the Remove button.

Note

SendMail task allows encodings to be included in attachments so as to allow the receiver to see the original text correctly. An example is shown in Figure 2.5, “Encoding in Attachment of SendMail task”.

Figure 2.5. Encoding in Attachment of SendMail task

<ers:mbean name="ERS2:name=SMTPServer" 
  	class="com.elixirtech.ers2.mail.SMTPServer">
	<ers:property name="Host">elixir.aspirin</ers:property>
	<ers:property name="User"></ers:property>
	<ers:property name="Password"></ers:property>
	<!-- Set a DNS host here if default DNS lookup doesn't  
  	work when using elixir.aspirin SMTP -->
	<ers:property name="DnsResolver"></ers:property>
	<ers:property name="Debug">false</ers:property>			
</ers:mbean>

The OnError task can only be the child of a job and cannot be added under other composite tasks such as Loop. It should always be the last top-level task listed under the job. There can only be one OnError task for each job. When the user try to add another one, he will be prompted to overwrite the existing one. Similarly, when the user copy a OnError task from one job to another that has an existing OnError task, he will be prompted to overwrite the existing one.

OnError task is triggered to run when error occurs during the job execution. The user can configure the number of times to re-try the job when it hits an error. The default value is zero, which means there is no re-trying.

A user can also add tasks under the OnError task, which are executed when the OnError task runs. Typically, it will be those tasks that clean up the leftover from previous job failure such that Repertoire can re-try the job again in a consistent way.

If there are no errors during job execution, the OnError task is skipped.