Job Execution Task Properties
Property Pages
Property pages common to all Tasks
General
Name for this step (optional)Optionally, specify a descriptive name for the step.Enable this stepUncheck this box to disable the step. If the step is not enabled, it will be skipped at execution.Description/NotesEnter any extended descriptive information or notes for this step.Conditions
The Conditions page defines conditions that must be satisfied before the step is run.
Condition Criteria
The Condition Criteria determine how the conditions should be evaluated:
- Execute only if all conditions are met. The step is only executed if all of the listed conditions are met.
- Execute if any condition is met. The step is executed if any of the listed conditions is met.
If Conditions are not satisfied
The satisfaction options determine what adTempus should do if the conditions are not satisfied:
- Fail the step. The step is not executed; the status is set to Failed.
- Execute anyway. The step is executed anyway.
- Skip the step (do not report as a failure). The step is not run, but it is not treated as a failure. The status of the step is reported as "Skipped (conditions not met)."
Conditions List
The Conditions list lists the conditions that have been defined for the step. You can add, edit, or delete conditions. See the Conditions topic for information on the available condition types.
Variables
See the Job Variable Propagation section below for information on which variables are sent to the target job(s).
The Variables page allows you to define Job Variables for this step. You can add new Variables, or override the values of Variables inherited from the Job. Any Variables you define or override here affect only this step of the Job.
To set Variables that apply to the entire job, use the Variables page in the Job properties.
Job Variable list features and toolsThe Job Variable list shows variables defined for the current object as well as variables inherited from a higher level. Icons next to each variable in the list convey information about their inheritance:
 | The variable is inherited from a higher level |
 | The variable is inherited from a higher level and is locked (cannot be overridden) |
 | The variable is inherited from a higher level and has been modified at this level |
 | The variable is new at this level |
 | The variable is inherited from a higher level and must be overridden (a value provided) at this level |
 | The variable has been overridden (redefined) at a lower level. This icon only appears if you have analyzed variable usage (see below). |
When you hove the mouse pointer over the icon for an inherited variable, adTempus will show where the variable was inherited from.
Filtering the variable list
The variable list can be filtered to:
- Hide inherited variables (so you only see variables defined at this level)
- Hide variables that cannot be modified (inherited variables that are locked to prevent modification)
- Show only variables that must be overridden
Analyzing and viewing variable usage
5.0
When you click Analyze variable usage, adTempus searches for all the places where the variables are used or overridden. After this analysis is complete, new columns are added to the list to show, for each variable:
- Whether it has been overridden (redefined) at a lower level
- A count of how many times it is referenced (used)
Clicking Show variable usage opens a new window showing all the references and overrides for the variables. This is the same window shown by the Find Variable and Function References tool.
Analyze variable usage only finds references and overrides that are "below" the current level. For example, if you are viewing the variables for a job, this will find all references and overrides within the job, or within jobs that may receive variables from this jobs (jobs run by Responses or Job Triggers). If you are viewing a group, this will find all references and overrides within groups and jobs below the selected group. That is, the tool only lists places that might be affected by changes to the variables in the list.
This tool does not show other places where the variables might be used. For example if you are viewing job A and some of the variables are also used in job B, those uses will not be listed unless there is a link between job A and job B.
To find all references to a variable:
- If the variable is defined at the server level, use the Analyze variable usage tool from the variables list at the server level. This will show all uses everywhere in adTempus.
- Use the Find Variable and Function References tool to find a specific variable or all variables.
Responses
The Responses page defines the actions that adTempus should take in response to events that are fired during execution of the step. You can add, edit, delete, or reorder responses.
All job steps support the events listed below. Some tasks may define additional events .
| Event | Description |
| Step Started | Occurs at the beginning of the step. |
| Step Ended | Occurs at the end of the step, regardless of the step result. |
| Step Failed | Occurs if the step fails for any reason. |
| Step Restarted | Occurs if the step is restarted due to a Response. |
| Restart Limit Exceeded | Occurs if the restart limit is exceeded. |
| Step skipped | Occurs when the step is skipped, either because conditions were not met (if the Skip... option is selected on the Conditions page) or due to a skip option specific to the task. |
| One or more conditions failed | Occurs if one or more Conditions for the step is not satisfied. |
| Conditions not met within the specified time | Occurs if the job or a step within the job has been waiting for conditions for longer than the specified time. |
Job Execution
The Job Execution page defines which jobs the task will run and contains options controlling the execution.
Target Jobs
The Target Jobs list is the list of jobs that the task will run. The Job Execution Task Target Properties is used to edit the settings for each target job.
If there is more than one target job, they will be submitted for execution in the order they are listed; use the up and down arrows to change the order of the jobs. Note:
- If the Wait For option is one of the "Each job..." settings, the target jobs will execute in the order specified: adTempus waits for each job to complete before executing the next.
- If the Wait For option is one f the other settings, the target jobs are all submitted at the same time. Though they are submitted in the order specified there is no guarantee they will begin executing in that order, and they will all execute at the same time.
Wait For and Success Criteria
The Wait For and Success Criteria options determine how the task executes jobs and how adTempus determines if the step should be treated as successful or failed.
If multiple instances are started for a target job (see Multiple Instances), the target waits for all instances, and all instances must succeed for the target to be considered successful.
The following table shows the available settings and how they interact.
| Success Criteria | |||
|---|---|---|---|
| Wait For | All targets must succeed | At least one target must succeed | Ignore target result |
| Do not wait |
All target jobs are submitted for execution at the same time. The task ends without waiting for any of them to complete. The success criteria are ignored and the step is always successful. |
||
| Any job to complete |
All target jobs are submitted for execution at the same time. The task waits until any one of the jobs completes. The success or failure of the step is based on the result of the completed job. |
All target jobs are submitted for execution at the same time. The task waits until any one of the jobs completes. Any failures are ignored and the step is always successful. |
|
| Any job to succeed |
All target jobs are submitted for execution at the same time. The task waits until any one of the jobs completes with a successful result. The step is successful if at least one target job succeeds, otherwise it fails. |
||
| All jobs to complete |
All target jobs are submitted for execution at the same time. The task waits until all of the jobs complete. The step is successful if all of the target jobs are successful, otherwise it fails. |
All target jobs are submitted for execution at the same time. The task waits until all of the jobs complete. The step is successful if at least one of the target jobs is successful, otherwise it fails. |
All target jobs are submitted for execution at the same time. The task waits until all of the jobs complete. Any failures are ignored and the step is always successful. |
| Each job (stop on failure) |
The target jobs are executed one at a time in the order listed. The task waits until each job completes before submitting the next job. If a target job fails, the step does not execute the remaining jobs. The step is successful if all of the target jobs it has executed are successful, otherwise it fails. |
The target jobs are executed one at a time in the order listed. The task waits until each job completes before submitting the next job. If a target job fails, the step does not execute the remaining jobs. The step is successful if any of the target jobs it has executed are successful, otherwise it fails. |
The target jobs are executed one at a time in the order listed. The task waits until each job completes before submitting the next job. If a target job fails, the step does not execute the remaining jobs. Any failures are ignored and the step is always successful. |
| Each job (run all targets) |
The target jobs are executed one at a time in the order listed. The task waits until each job completes before submitting the next job. If a target job fails, the step continues executing the remaining jobs. The step is successful if all of the target jobs it has executed are successful, otherwise it fails. |
The target jobs are executed one at a time in the order listed. The task waits until each job completes before submitting the next job. If a target job fails, the step continues executing the remaining jobs. The step is successful if any of the target jobs it has executed are successful, otherwise it fails. |
The target jobs are executed one at a time in the order listed. The task waits until each job completes before submitting the next job. If a target job fails, the step continues executing the remaining jobs. Any failures are ignored and the step is always successful. |
Maximum time to wait for job execution
This limit specifies the maximum time the task should wait for target jobs to execute. Once this time limit is exceeded, adTempus will log a warning message and then determine the success or failure of the step by applying the Success Criteria:
- All targets must succeed: The step fails (regardless of the outcome of any jobs that have completed) because not all jobs succeeded (i.e., the job(s) that have not completed are treated as failures).
- Any target must succeed: The step succeeds if any target job has completed with a successful result. Otherwise it fails.
- Ignore target result: The step succeeds.
Maximum time to wait for job dispatch
This limit specifies the maximum time the task should wait for target jobs to be dispatched to a Controller or remote server for execution (see Remote Job Execution). If a target job cannot be sent to the other server within the time limit (i.e., because the remote server cannot be contacted), adTempus will log a warning message and that target will be treated as failed. The Wait For and Success Criteria will be applied as normal, treating the timed-out target as failed.
Note: This wait limit is not enforced while there are any other target jobs that are executing: as long as at least one target job has been successfully submitted and is still executing, adTempus will continue to wait for remote jobs to be dispatched. However, the wait time is calculated from the time the target job was sent for dispatch.
Responses
Choose which Responses you want to execute (this option applies to Responses for the job and for steps within the job):
- Execute Responses: All Responses are executed as normal.
- Do not execute any Responses: No Responses will be executed.
- Do not execute any Job Control Responses:All Responses will be executed except Job Control Responses (Responses that run, terminate, hold, or release a job or job step). Use this option if you do not want adTempus to execute any other jobs that are chained to the current job.
Ignore conditions for the job
If this option is checked, adTempus will ignore any conditions that are defined for the target job (this forces the job to execute even if the conditions are not met). Conditions at the step level are not ignored (see next option).
Ignore conditions for individual steps
If this option is checked, adTempus will ignore any conditions that are defined for the target step, or for the steps of the target job (this forces the step(s) to execute even if the conditions are not met).
Force a new instance of the job if necessary
This option overrides the Multiple Instances option for the target job, forcing adTempus to start a new instance of the job even if another instance is already running.
Run only on same Agent
This option is only available if the current server is a Distributed Scheduling Controller computer. If this option is checked, the target job will be run only on the same computer as the calling job. If this option is not checked, the job will execute according to the Distributed Scheduling settings for its Queue, and may not execute on the same computer as the calling job.
Run only on Controller
This option is only available if the current server is a Distributed Scheduling Controller computer. If this option is checked, the target job will be run only on the Controller computer; any Agents associated with the job's Queue will be ignored. If the Queue is not configured to run jobs on the Controller, the job will not run unless the Force job to run on Controller option is also checked.
Force job to run on Controller
This option is only available if the current server is a Distributed Scheduling Controller computer. If this option is checked, the target job will run on the Controller computer even if the Queue is not configured to run jobs on the Controller.
Job Variable Propagation
The Job Variables listed on the Variables page for the task are the variables inherited by or defined in the job/step that you are editing (the calling job). They do not reflect the variables defined for the target job(s). To see the variables defined for a target or to define different variable for different targets, edit the target and review the Variables page of the target properties.
The following rules determine whether the variables listed for the step are sent to the target job:
- If the variable was defined () or overridden () on this page, it will be sent to the target job. The Override Target box will be checked and cannot be changed.
- If the variable was inherited from a higher level () it will not be sent to the target job by default. Check the box in the Override Target column to send the variable to the target. The value sent to the target will be the value inherited or calculated at runtime, which may be different than the value currently shown. To send a specific value, edit the variable here and set the value you want to use.
When the Job Execution Task sends variables to the target job, those variables override the values defined in the target job. For example, suppose the target job has a "Customer ID" variable set to "14". The calling job also has a "Customer ID" variable with the value "97". If you check the Override Target box for this variable, the target job will use the value "97".