User Community Service Desk Downloads
If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

How 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 <source_id> and <schedule_name>.

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:

Sample Run Windows Commandd stdout.log file
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
Sample Run Workflow job.log file
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).

Scheduler logging configuration excerpt
<?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?