Lead your team forward
OCT 24 / 9AM ET Register nowHow to Log Schedule Execution
Running a schedule generates logs with the information about the execution of the schedule and the triggering of the target job. This article covers the information about the log contents and configuration options. For the general logging reference, see Logging Configuration.
This article applies to the Notifications Handler as well, which is a component for scheduling jobs based on changes in Metadata Management Module (MMM). |
Execution state persister
Execution state persister stores basic information about the execution of a scheduled job.
The execution state can be written either to an .sjr
file or a database.
This is configured in the Scheduler Server Component.
The information written to these persisters contains the following:
Attribute | Description |
---|---|
id |
(Internal) job execution ID. |
schedule_id |
Schedule ID consisting of |
creation_date |
Date of the job start in the "yyyy-mm-dd HH:MM:ss" format. |
exec_state |
Execution start state marks whether the job was successfully started or not. The attribute only reports about the job start. To see the result of the job execution, see the logs of the job which was executed. |
target_id |
Unique ID of the object that was created or executed as a response to the job invocation. For example, if you have started a Run Workflow job, then this ID represents the ID of the started workflow instance (for more information, see How to Log Workflow Execution). Some jobs return n`ull` since their executions do not create any execution objects. For example, the Run Shell job simply invokes a command so there’s no explicit result object whose ID should be returned. |
exec_desc |
Description data. |
The following is a sample execution state log (using the database persistence option):
ID | SCHEDULE_ID | CREATION_DATE | EXEC_STATE | TARGET_ID | EXEC_DESC |
---|---|---|---|---|---|
100 |
S1:06_01_schedule_win_command.sch |
2017-03-24 12:00:44 |
OK |
2758 |
<null> |
101 |
S1:06_02_schedule_wfl_task.sch |
2017-03-23 17:04:00 |
ERROR |
<null> |
Missing workflow-variables definition for: SALUTATION |
102 |
S1:06_02_schedule_wfl_task.sch |
2017-03-22 17:04:00 |
ERROR |
<null> |
workflow id '../WF00:00_01_Hello_World.ewf' was not found |
103 |
S1:06_02_schedule_wfl_task.sch |
2017-03-21 17:04:00 |
OK |
2759 |
<null> |
104 |
S1:06_02_schedule_wfl_task.sch |
2017-03-20 17:04:00 |
OK |
2760 |
<null> |
SJR file
Execution information is stored to an SJR (Schedule Job Result) file if the Result Persister is set to File State Result Persister in the Scheduler Server Component. The file is created in the location specified in the Resources Folder property. SJR files are stored in the CSV format.
For each schedule there is one .sjr
file, with the following naming convention: <source_id>_<schedule_name>.sch.sjr
, for example, S1_06_01_schedule_win_command.sch.sjr
.
Each row in this file represents one execution.
Data is stored in the following order (from the latest to oldest executions):
schedule_id;id;creation_date;exec_state;target_id;exec_desc
The maximum number of historical executions stored in an SJR file is 15. The oldest log is removed when the limit is exceeded. |
Database persistence
Execution information is stored into a database if the Result Persister is set to Db State Result Persister in the Scheduler Server Component.
In this case, a .sjr
file is not created.
The scheduler execution persister registers several tables with the schdef
prefix.
The most useful one is schdef_job_exec_state
, which contains information about all schedule executions.
Every schedule execution inserts a row with a unique ID (see the sample schdef_job_exec_state
table in Execution state persister).
For more information about schdef
tables, see Workflow and Scheduler Database Persistence Tables.
The maximum number of historical records stored for each schedule is 15. The oldest log is removed when the limit is exceeded. |
EXEC folder
An exec
folder contains temporary scripts and log files that depend on the schedule job type:
-
Run Workflow job generates a
job.log
, which logs whether the target workflow was successfully started. -
Run Win Cmd and Run Shell Script jobs log whether the target command was executed.
These tasks log into two files: stdout.log`and `stderr.log
.
Every schedule execution generates a new exec
folder.
The exec
folder is created in the Resources Folder specified in the Scheduler Server Component and has the following naming convention: exec_<execution_id>_<source_id>_<schedule_name>.sch
.
The maximum number of historical exec folders stored for each schedule is 15.
The oldest log is removed when the limit is exceeded.
|
The following examples show the contents of log files:
D:\ONE\project\workspace\workflows\src1>echo Hello Sherlock from Workflow task!
Hello Sherlock from Workflow task!
D:\ONE\project\workspace\workflows\src1>EXIT 0
2017-03-24 16:08:12 INFO: Starting instance of workflow 'WF02:02_02_Parallel_DQC_Processing.ewf'
2017-03-24 16:08:12 INFO: Workflow successfuly started
Scheduler logging as part of unified server logging
ONE lets you log the starting and finishing of all scheduler jobs into a single log, together with the other server components. Configuring scheduler execution logging does not affect the schedule execution state and EXEC outputs described previously.
To capture logs from the Scheduler Server Component in the unified server logs, review your Logging Configuration and add new logging rules and appenders if necessary.
The following excerpt shows a configuration example, where logs of the severity level INFO
and higher coming from the Scheduler Server Component are written to the standard output (console).
<?xml version='1.0' encoding='UTF-8'?>
<loggingConfig>
<appenders>
...
<iLogAppenderFactory logMillis="false" name="stdout" class="com.ataccama.dqc.commons.logging.factories.StdOutLogAppenderFactory" useStdErr="false"/>
...
</appenders>
<loggingRules>
...
<loggingRule level="INFO" appender="stdout">
<trace>
<string>SchedulerServerComponent</string>
</trace>
</loggingRule>
...
</loggingRules>
</loggingConfig>
Was this page useful?