Executions History shows the history of all jobs that the Server has executed – transformation graphs, jobflows, and Data Profiler jobs. You can use it to find out why a job failed, see the parameters that were used for a specific run, and much more.
The table shows basic information about the job: Run ID, Job file, current status, and time of execution, as well as some useful links. You will also find additional details after clicking on the job name in the list – details such as associated log files, parameter values, tracking, and more.
Please note that some jobs might not appear in the Executions History list. These are jobs that have disabled persistency for increased performance – e.g. some Launch Services disable storing the run information in order to increase service responsiveness.
Use the Filter panel to filter the view. By default, only parent tasks are shown (Show executions children) – e.g. master nodes in the Cluster and their workers are hidden by default.
Use the up and down arrows in the table header to sort the list. By default, the latest job is listed first.
Figure 23.1. Executions History - executions table
When some job execution is selected in the table, the detail info is shown on the right side.
Table 23.1. Persistent run record attributes
Attribute | Description |
---|---|
Run ID | A unique number identifying the run of the job. Server APIs usually return this number as a simple response to the execution request. It's useful as a parameter of subsequent calls for specification of the job execution. |
Execution type | Type of a job as recognized by the server. STANDALONE for ETL graph, JOBFLOW for Jobflow, PROFILER_JOB for profiler, MASTER for main record of partitioned execution in cluster, PARTITIONED_WORKER for worker record of partitioned execution in cluster |
Parent run ID | Run ID of the parent job. Typically Jobflow which executed this job, or master execution which encapsulates this worker execution. |
Root run ID | Run ID of the root parent job. Job execution which wasn't executed by another parent job. |
Execution group | Jobflow components may group sub-jobs using this attribute. See a description of Jobflow components for details. |
Nested jobs | Indication that this job execution has or has not any child execution. |
Node | In cluster mode shows ID of the cluster node which this execution was running on. |
Executed by | User which executed the job. Either directly using some API/GUI or indirectly using the scheduling or event listeners. |
Sandbox | Sandbox containing a job file. For jobs which are sent together with an execution request, so the job file doesn't exist on the server site, it's set to "default" sandbox. |
Job file | Path to a job file, relative to the sandbox root. For jobs which are sent together with an execution request, so the job file doesn't exist on the server site, it's set to generated string. |
Job version | Revision of the job file. It's a string generated by CloverETL Designer and stored in the job file. |
Status | Status of the job execution. READY - waiting for execution start, RUNNING - processing job, FINISHED OK - job finished without any error, ABORTED - job was aborted directly using some API/GUI or by parent Jobflow, ERROR - job failed, N/A (not available) - server process died suddenly, so it couldn't properly abort the jobs, so after restart the jobs with unknown status are set as N/A |
Started | Server date-time (and timezone) of the execution start. |
Finished | Server date-time (and timezone) of the execution finish. |
Duration | Execution duration |
Error in component ID | If the job failed due the error in a component, this field contains ID of the component. |
Error in component type | If the job failed due the error in a component, this field contains type of the component. |
Error message | If the job failed, this field contains error description. |
Exception | If the job failed, this field contains error stack trace. |
Input parameters | List of input parameters passed to the job. Job file can't be cached, since the parameters are applied during loading from the job file. Job file isn't cached by default. |
Input dictionary | List of dictionary elements passed to the job. Dictionary is used independently of job file caching. |
Output dictionary | List of dictionary elements at the moment the job ends. |
For jobs which have some children executions, e.g. partitioned or jobflows also an executions hierarchy tree is shown.
Figure 23.2. Executions History - overall perspective
Since the detail panel and expecially job logs may be wide, it may be useful to hide a table on the left, so the detail panel spreads. Click on the minimize icon on the top of the list panel to hide the panel. Then to show list panel again, click to the "Expand panel" icon on the left.
Figure 23.3. Executions Hierarchy with docked list of jobs
Executions hierarchy may be rather complex, so it's possible to filter the content of the tree by a fulltext filter. However when the filter is used, the selected executions aren't hierarchically structured.