Overview

Stop Policies can be set by selecting the Stop policy tab. The stop policy works in conjunction with the job schedule. It determines when a job should stop running. If a stop policy is not set for a scheduled job, the job will continue to run based on the set schedule until it is manually stopped or removed. Once a job meets the stop policy, its status changes to "Complete."

Define a Stop Policy

You can set the schedule for a job when you save the job on the Summary page of the job creation process. Select Save job from the Save list.

Once you assign the job a name, select the Schedule job to run toggle. This displays the schedule options.

Select the Stop policy tab to set the stop policies for the job.

Stop after a number of total runs

Use this option option to set the total number of job runs that should occur. The job will only run the specified number of times.

Stop after a number of runs with no changes

Use this option option to stop the job once the specified number of runs occur without any changes to the content; all content has transferred successfully. Job executions that detect no changes do not need to be consecutive to increment your stop policy count. If new content is added to the source and the job runs again, this will not increment your stop policy count.

Stop after a number of failures

Use this option option to stop the job after the set number of failures are reached. Job executions that detect failures do not need to be consecutive to increment your stop policy count. Most failures are resolved through automatic retries. If the retries fail to resolve the failures, then manual intervention is required. This policy takes the job out of rotation so the issue can be investigated.

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

Use this option to set a specific stop date for the job. The job will run according to the schedule and stop at 12:00 AM on the specified date.

Stop Policy Using the REST API

The 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 DryvIQ Job Overview User Interface
"on_failure" = Failures in the DryvIQ Job Overview User Interface

Global Configuration

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.

License first
Then database
Then command-line
Then environment variables
Then appSettings.json

 {
  "data": {
    "connection": "SERVER=(local);DATABASE=SkySyncV4;Integrated Security=SSPI",
    "provider": "sqlserver",
    "directory": "C:\\ProgramData\\SkySync\\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

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. 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. `"stop_policy": { "on_success": 3 }`	(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. 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. `"stop_policy": { "on_failure": 3 }`	(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. When the job has executed 3 times, regardless of status, the job will stop and not run again. `"stop_policy": { "on_execute": 3 }`
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. 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. `"stop_policy": { "on_success": 3 }`	(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. 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. `"stop_policy": { "on_failure": 3 }`	(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. When the convention job has executed 3 times, regardless of status, the convention job will stop and not run again. `"stop_policy": { "on_execute": 3 }`

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 Job Reports: Transfer Audit Categories and Job Failure Policy for more information.

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
	}
}

Reset a 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, DryvIQ 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 and Start Job

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

Reset Job Stop Policy and Pause Job

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

Reset Job Stop Policy and Resume Job

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

Job Stop Policy