Syncplicity Support

Search our knowledgebase to get the help you need, today

Submit a request
Follow

Stop policy

Define Job Schedule

During job creation, the final step is to define when the job will run and what criteria will define when it stops. 

  • Save job will launch the job scheduler
  • Save job and run it right now will trigger the job to start immediately. It will run every 15 mins after the last execution completes

Schedule Stop Policies 

Stop policies determine when a job should stop running.  If none of the stop policies are enabled, a scheduled job will continue to run until it is manually stopped or removed. 

The options for the stop policy are: 

Stop after a number of total runs

The number of total executions before the job will move to "complete" status

Stop after a number of runs with no changes

The job has run and detected no further changes; all content has transferred successfully. 

If new content is added to the source and the job runs again, this will not increment your stop policy count. However, job executions that detect no changes do not need to be consecutive to increment your stop policy count.

Stop after a number of failures

This option stops the job after a set number of failures have been logged during a job run. Most failures are resolved through automatic retries. If the retries fail to resolve the failures, the failures are logged in the audit log. Manual intervention is required. This policy takes the job out of rotation so the issue can be investigated. Job executions that detect failures do not need to be consecutive to increment your stop policy count.

This stop policy does not include when jobs fail to start; only failures logged during the job run count toward the stop policy. When a job fails to start, it is generally the result of a configuration issue.

Stop after a specific date

This identifies the last date the job should run. The job will run as scheduled on the specified date and transition to "complete" when the job meets the other scheduled criteria for that day (if set). Setting a stop date does not stop the job from running on the date specified; it prevents subsequent runs after that date. 

For example, if you schedule a job to run at 12:00 AM and set the "stop after date" to be January 1, the job will run at 12:00 AM on January 1 and then transition to "complete." Similarly, if you have a job set to run every 15 minutes with a "stop after date" of January 1, the job will run every 15 minutes on January 1 and transition to "complete" when the last job in the schedule runs. 

Related:

Stop Policy - DataHub API

Stop Policy allows the user to decide when a scheduled job should stop running based on a defined set of criteria

  • "on_success" = No Changes in the DataHub Job Overview User Interface
  • "on_failure" = Failures in the DataHub Job Overview User Interface

Global Configuration - Environment Overrides and Precedence

All settings can be set through the command line (--settingname=value) or through (SKYSYNC_settingname=value)

When using environment variables, replace the colon (:) with double underscore (__). So server:port could be set using an environment variable named SKYSYNC_server__port=value. The order of precedence before the database is online is command-line, then environment variables, then appSettings.json. However, once the license and database are online, the order of precedence changes to the license, then the database (Configuration table), then command-line, then environment variables, then appSettings.json.

  1. License first
  2. Then database
  3. Then command-line
  4. Then environment variables
  5. Then appSettings.json

Global Stop Policy Configuration

{
  "data": {
    "connection": "SERVER=(local);DATABASE=SkySyncV4;Integrated Security=SSPI",
    "provider": "sqlserver",
    "directory": "C:\\ProgramData\\Syncplcity DataHub\\v4",
  },
  "server": {
    "proxy_url": "http://{{IP.ADDRESS}}:9090/"
  },
  "deployment": {
        "packageDirectory": "C:\\{{Choose Directory}}"
  },
  "jobs": {
    "default_stop_policy": {
      "on_success": 2,
      "on_failure": 2
        }
    }
  },
  "license": {
    "activation_key": "{{license Key}}"
    }
  }
}

Job Configuration

For stop policy purposes success means that during job's executions no actions were taken – i.e. no files/folders were copied and no errors occurred. This typically would happen after previous job executions have copied everything successfully and there are no new files to be copied.

Option

Description

Default Value
jobs:default_stop_policy:on_success

The number of successful executions before terminating a job by default

  • Example:
  • A copy job configured to stop running after 3 successful executions
"stop_policy": {
	"on_success": 3
}
  • When the job has executed and completed successfully 3 times, the job will stop and not run again. 
  • The successes do not need to be consecutive to increment the count
  • A successful execution is one that does not have any failures and does not have any additional content to move. This is useful to ensure that all content is moved.

(null)
jobs:default_stop_policy:on_failure

The number of failed executions before terminating a job by default

  • Example:
  • A copy job configured to stop running after 3 failed executions
"stop_policy": {
	"on_failure": 3
}
  • When the job has executed and failed 3 times, the job will stop and not run again.
  • The failures do not need to be consecutive to increment the count
  • This can be useful to prevent a job from continually failing and taking up resources.

(null)
jobs:default_stop_policy:on_execute

The number of total executions before terminating a job by default. This is different from "on_failure" and "on_success" in that it will terminate after the number of executions regardless of the status of the executions.

  • Example:
  • A copy job configured to stop running after 3 total executions
"stop_policy": {
	"on_execute": 3
}
  • When the job has executed 3 times, regardless of status, the job will stop and not run again.
  
jobs:convention_stop_policy:on_success

The number of successful convention executions before terminating a convention job by default

Example: 

  • A convention job, such as a User Drive Mapping or Folder Mapping job, is scheduled to run every 4 hours
"stop_policy": {
	"on_success": 3
}
  • When the parent job is run it will create the child jobs. Each subsequent job adds or deletes child jobs if users were added or deleted since last execution. If there are 3 job runs where no child jobs were created or deleted and there were no failures, the convention job will stop per the policy.
  • The successes do not need to be consecutive to increment the count

(null)
jobs:convention_stop_policy:on_failure

The number of failed convention executions before terminating a convention job by default

Example: 

  • A convention job, such as a User Drive Mapping or Folder Mapping job, is scheduled to run every 4 hours
"stop_policy": {
	"on_failure": 3
}
  • When the parent job is run it will create the child jobs.

    Each subsequent job adds or deletes child jobs if users were added or deleted since last execution. If there are 3 failures to create/delete the child jobs during one of these executions, the convention job will stop per the policy

  • The failures do not need to be consecutive to increment the count

(null)
jobs:convention_stop_policy:on_execute

The number of total executions before terminating a convention job by default.

  • Example:
  • A convention job, such as a User Drive Mapping or Folder Mapping job, is scheduled to run every 4 hours
"stop_policy": {
	"on_execute": 3
}
  • When the convention job has executed 3 times, regardless of status, the convention job will stop and not run again.
  

A job will be in a failure state if any of the items attempted to be transferred log one or more error level categories in the audit log. Note, the default failure policy is to log error and continue with the execution. 

See: 

Example Job JSON

The following copy job will stop future executions after 3 successful executions. Alternatively "on_failure" can be provided instead of "on_success" to stop executions after given amount of failed executions.

POST v1/jobs

{
    "name":"Simple Transfer Job with stop policy",
    "kind": "transfer",
    "transfer": {
        "transfer_type": "copy",
        "source": {
            "connection": { "id": "{{nfs_connection_id}}" },
            "target": {
                "path": "/w/source"
            }
        },
        "destination": {
            "connection": { "id": "{{cloud_connection_id}}" },
            "target": {
                "path": "/w/destination"
            }
        }
    },
    "schedule": {
        "mode": "auto"
    },
    "stop_policy": {
        "on_success": 3
    }
}

How to Reset Job Stop Policy

After a job has reached its stop policy, use one of the following to reset the stop policy. This will allow you to execute the job again.

For example, if you have defined a job stop policy to stop execution after 3 executions, DataHub will stop executing the job after 3 executions. If you want to run the job after the stop policy has been applied, use one of the following options to reset the number of executions and continue to run the job until your job has hit another 3 executions

  • Start - start will clear the stop policy and immediately trigger the job to start
  • Pause - pause will clear the stop policy and immediately set the job to a paused state
  • Resume - resume will clear the stop policy and put the job back into the scheduler queue based on the job's normal schedule

Reset Job Stop Policy | Start Job

PATCH {{url}}v1/jobs/{{job}}?start=1

Reset Job Stop Policy | Pause Job

PATCH {{url}}v1/jobs/{{job}}?pause=1

Reset Job Stop Policy | Resume Job

PATCH {{url}}v1/jobs/{{job}}?resume=1
Powered by Zendesk