Admin Jobs (3.x.x and earlier) - Revision history

Carfey: /* Custom Calendar Assignment */

2016-07-01T17:05:50Z

Custom Calendar Assignment

← Older revision		Revision as of 17:05, 1 July 2016
Line 203:		Line 203:
	=== Custom Calendar Assignment ===		=== Custom Calendar Assignment ===

	As of Obsidian 2.0, an Enabled Schedule may also be assigned a [[Admin_Custom_Calendars_(3.x.x_and_earlier)\|~~Custom Calendar~~]]. Use this to prevent scheduling/execution on the dates specified by the Custom Calendar.		As of Obsidian 2.0, an Enabled Schedule may also be assigned a [[Admin_Custom_Calendars_(3.x.x_and_earlier)\|custom calendar]]. Use this to prevent scheduling/execution on the dates specified by the Custom Calendar.

	[[Image:2.5.0.CustomCalendarAssignment.png]]		[[Image:2.5.0.CustomCalendarAssignment.png]]

Carfey: /* Execution & Pickup */

2016-07-01T17:04:51Z

Execution & Pickup

← Older revision		Revision as of 17:04, 1 July 2016
Line 149:		Line 149:
	''Pickup Buffer'' indicates for how many minutes the job is considered within normal execution time from the exact scheduled time. This allows for leniency when dealing with conflicting jobs or with short-term downtime. If a minor delay isn't significant to your job, using a higher buffer can help prevent jobs from being marked missed or conflict missed unnecessarily.		''Pickup Buffer'' indicates for how many minutes the job is considered within normal execution time from the exact scheduled time. This allows for leniency when dealing with conflicting jobs or with short-term downtime. If a minor delay isn't significant to your job, using a higher buffer can help prevent jobs from being marked missed or conflict missed unnecessarily.

	''Fixed Hosts'' allows you to indicate that only certain hosts should run this job. You can select one or more hosts which Obsidian knows about, and add additional options in case a host is not yet deployed or active. As of Obsidian 2.2.1, a configuration item allows you to specify whether you wish host restrictions to apply on AdHoc jobs or not. On new installations of 2.2.1, it defaults to TRUE while it defaults FALSE (to maintain behaviour from versions before 2.2.1) on upgrades from prior releases. This can be found under '''[[Admin_System_(3.x.x_and_earlier)\|~~Admin~~ System]]/Job/adHocJobsRespectFixedHostsRestrictions'''.		''Fixed Hosts'' allows you to indicate that only certain hosts should run this job. You can select one or more hosts which Obsidian knows about, and add additional options in case a host is not yet deployed or active. As of Obsidian 2.2.1, a configuration item allows you to specify whether you wish host restrictions to apply on AdHoc jobs or not. On new installations of 2.2.1, it defaults to TRUE while it defaults FALSE (to maintain behaviour from versions before 2.2.1) on upgrades from prior releases. This can be found under '''[[Admin_System_(3.x.x_and_earlier)\|System]]/Job/adHocJobsRespectFixedHostsRestrictions'''.

	''Host Preference'' indicates that Fixed Hosts are only preferred hosts, and that other available hosts can run the job when none of the preferred hosts are running. When selected, you can also order the hosts using drag & drop. Obsidian will always choose the highest priority host to run the job if one is available.		''Host Preference'' indicates that Fixed Hosts are only preferred hosts, and that other available hosts can run the job when none of the preferred hosts are running. When selected, you can also order the hosts using drag & drop. Obsidian will always choose the highest priority host to run the job if one is available.

Carfey: /* Execution & Pickup */

2016-07-01T17:04:34Z

Execution & Pickup

← Older revision		Revision as of 17:04, 1 July 2016
Line 149:		Line 149:
	''Pickup Buffer'' indicates for how many minutes the job is considered within normal execution time from the exact scheduled time. This allows for leniency when dealing with conflicting jobs or with short-term downtime. If a minor delay isn't significant to your job, using a higher buffer can help prevent jobs from being marked missed or conflict missed unnecessarily.		''Pickup Buffer'' indicates for how many minutes the job is considered within normal execution time from the exact scheduled time. This allows for leniency when dealing with conflicting jobs or with short-term downtime. If a minor delay isn't significant to your job, using a higher buffer can help prevent jobs from being marked missed or conflict missed unnecessarily.

	''Fixed Hosts'' allows you to indicate that only certain hosts should run this job. You can select one or more hosts which Obsidian knows about, and add additional options in case a host is not yet deployed or active. As of Obsidian 2.2.1, a configuration item allows you to specify whether you wish host restrictions to apply on AdHoc jobs or not. On new installations of 2.2.1, it defaults to TRUE while it defaults FALSE (to maintain behaviour from versions before 2.2.1) on upgrades from prior releases. This can be found under '''[[~~Admin_System~~\|Admin System]]/Job/adHocJobsRespectFixedHostsRestrictions'''.		''Fixed Hosts'' allows you to indicate that only certain hosts should run this job. You can select one or more hosts which Obsidian knows about, and add additional options in case a host is not yet deployed or active. As of Obsidian 2.2.1, a configuration item allows you to specify whether you wish host restrictions to apply on AdHoc jobs or not. On new installations of 2.2.1, it defaults to TRUE while it defaults FALSE (to maintain behaviour from versions before 2.2.1) on upgrades from prior releases. This can be found under '''[[Admin_System_(3.x.x_and_earlier)\|Admin System]]/Job/adHocJobsRespectFixedHostsRestrictions'''.

	''Host Preference'' indicates that Fixed Hosts are only preferred hosts, and that other available hosts can run the job when none of the preferred hosts are running. When selected, you can also order the hosts using drag & drop. Obsidian will always choose the highest priority host to run the job if one is available.		''Host Preference'' indicates that Fixed Hosts are only preferred hosts, and that other available hosts can run the job when none of the preferred hosts are running. When selected, you can also order the hosts using drag & drop. Obsidian will always choose the highest priority host to run the job if one is available.
Line 159:		Line 159:
	''Auto Retries - Exponential'' allows you to indicate if you desire the auto retries interval to exponentially increase as retries are attempted. For example, if you set the interval minutes to 5 and check ''Exponential'', the first retry will be 5 minutes after failure, the second retry after a subsequent failure will be 10 minutes later, then 20 minutes, and so on. As of Obsidian 2.5.0.		''Auto Retries - Exponential'' allows you to indicate if you desire the auto retries interval to exponentially increase as retries are attempted. For example, if you set the interval minutes to 5 and check ''Exponential'', the first retry will be 5 minutes after failure, the second retry after a subsequent failure will be 10 minutes later, then 20 minutes, and so on. As of Obsidian 2.5.0.

	''Expected Length'' allows you to trigger event notifications in the event that the job execution is shorter or longer than the durations specified. Both fields are optional, and you are permitted to specify only one of the two. Specify a duration followed by a unit indicator (s-seconds, m-minutes, h-hours), e.g. 45s, 10m or 1h. To receive notifications based on the job running outside these parameters, configure [[Admin ~~Notifications~~\|Notifications]] at the Warning level or above. As of Obsidian 1.5.		''Expected Length'' allows you to trigger event notifications in the event that the job execution is shorter or longer than the durations specified. Both fields are optional, and you are permitted to specify only one of the two. Specify a duration followed by a unit indicator (s-seconds, m-minutes, h-hours), e.g. 45s, 10m or 1h. To receive notifications based on the job running outside these parameters, configure [[Admin Notifications_(3.x.x_and_earlier)\|Notifications]] at the Warning level or above. As of Obsidian 1.5.

	''Auto Interrupt'' allows you to specify if you wish an [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Job]] to be interrupted when its maximum expected run length is exceeded. Only available as an option for those jobs that adhere to the [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Job]] requirements and have a maximum expected length specified. As of Obsidian 3.4.0.		''Auto Interrupt'' allows you to specify if you wish an [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Job]] to be interrupted when its maximum expected run length is exceeded. Only available as an option for those jobs that adhere to the [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Job]] requirements and have a maximum expected length specified. As of Obsidian 3.4.0.

Carfey: /* Custom Calendar Assignment */

2016-07-01T16:59:36Z

Custom Calendar Assignment

← Older revision		Revision as of 16:59, 1 July 2016
Line 203:		Line 203:
	=== Custom Calendar Assignment ===		=== Custom Calendar Assignment ===

	As of Obsidian 2.0, an Enabled Schedule may also be assigned a [[~~Admin_Custom_Calendars~~\|Custom Calendar]]. Use this to prevent scheduling/execution on the dates specified by the Custom Calendar.		As of Obsidian 2.0, an Enabled Schedule may also be assigned a [[Admin_Custom_Calendars_(3.x.x_and_earlier)\|Custom Calendar]]. Use this to prevent scheduling/execution on the dates specified by the Custom Calendar.

	[[Image:2.5.0.CustomCalendarAssignment.png]]		[[Image:2.5.0.CustomCalendarAssignment.png]]

Carfey: /* Global Parameters */

2016-07-01T16:59:14Z

Global Parameters

← Older revision		Revision as of 16:59, 1 July 2016
Line 111:		Line 111:
	=== Global Parameters ===		=== Global Parameters ===

	Both defined and custom parameters support the usage of [[~~Admin_Global_Parameters~~\|global parameters]]. These let you configure job parameters globally, and then simply import them into jobs as needed.		Both defined and custom parameters support the usage of [[Admin_Global_Parameters_(3.x.x_and_earlier)\|global parameters]]. These let you configure job parameters globally, and then simply import them into jobs as needed.

	To use a global parameter in a job, simply enter its name surrounded by double curly braces (e.g. <code>{{param}}</code>) in the value field, and Obsidian will locate the matching global parameter (e.g. <code>param</code>). When the job is executed, Obsidian discards the global parameter reference and replaces it with the current global parameter values. You may use multiple global parameters for a given parameter by specifying each in its own value field, and they can be combined with regular parameter values, also in their own fields. All imported global parameter values will be validated against applicable job parameter definitions and data types. Note that Obsidian does not support global parameter references embedded inside parameter values, since it does not perform text substitution - only parameter values containing only the global parameter reference will be replaced with the global parameter value.		To use a global parameter in a job, simply enter its name surrounded by double curly braces (e.g. <code>{{param}}</code>) in the value field, and Obsidian will locate the matching global parameter (e.g. <code>param</code>). When the job is executed, Obsidian discards the global parameter reference and replaces it with the current global parameter values. You may use multiple global parameters for a given parameter by specifying each in its own value field, and they can be combined with regular parameter values, also in their own fields. All imported global parameter values will be validated against applicable job parameter definitions and data types. Note that Obsidian does not support global parameter references embedded inside parameter values, since it does not perform text substitution - only parameter values containing only the global parameter reference will be replaced with the global parameter value.

Carfey: /* Run Parameters */

2016-07-01T16:58:53Z

Run Parameters

← Older revision		Revision as of 16:58, 1 July 2016
Line 47:		Line 47:
	Note that the first field has a Remove Parameter link instead of Remove, and it will remove all values for that named parameter.		Note that the first field has a Remove Parameter link instead of Remove, and it will remove all values for that named parameter.

	If you reference a [[~~Admin_Global_Parameters~~\|global parameter]] by entering a value surrounded by double curly braces (e.g. <code>{{param}}</code>), Obsidian will resolve this to the values that are configured for the corresponding global parameter (e.g. <code>param</code>). When the job is executed, Obsidian will use the global parameter's values in place of the global parameter reference. You may use multiple global parameters for a given run parameter by specifying each in its own value field, and they can be combined with regular parameter values, also in their own fields. All imported global parameter values will be validated against applicable job parameter definitions and data types.		If you reference a [[Admin_Global_Parameters__(3.x.x_and_earlier)\|global parameter]] by entering a value surrounded by double curly braces (e.g. <code>{{param}}</code>), Obsidian will resolve this to the values that are configured for the corresponding global parameter (e.g. <code>param</code>). When the job is executed, Obsidian will use the global parameter's values in place of the global parameter reference. You may use multiple global parameters for a given run parameter by specifying each in its own value field, and they can be combined with regular parameter values, also in their own fields. All imported global parameter values will be validated against applicable job parameter definitions and data types.

	= Adding & Editing Jobs =		= Adding & Editing Jobs =

Carfey at 16:58, 1 July 2016

2016-07-01T16:58:35Z

← Older revision		Revision as of 16:58, 1 July 2016
Line 1:		Line 1:
	The job listing and edit pages give you access to the core of Obsidian's functionality - scheduling and configuring jobs. All job-related screens are accessible under the Jobs tab, with secondary navigation underneath for various [[Job_Features\|features]]. This page discusses listing and modifying jobs. Other job-related features in the administration app are discussed on other pages in the [[Admin Web Application ~~Guide~~]].		The job listing and edit pages give you access to the core of Obsidian's functionality - scheduling and configuring jobs. All job-related screens are accessible under the Jobs tab, with secondary navigation underneath for various [[Job_Features\|features]]. This page discusses listing and modifying jobs. Other job-related features in the administration app are discussed on other pages in the [[Admin Web Application Guide_(3.x.x_and_earlier)\|guide]].

	= Job Listing =		= Job Listing =

Carfey: Carfey moved page Admin Jobs to Admin Jobs (3.x.x and earlier) without leaving a redirect

2016-07-01T16:51:19Z

Carfey moved page Admin Jobs to Admin Jobs (3.x.x and earlier) without leaving a redirect

← Older revision	Revision as of 16:51, 1 July 2016
(No difference)

Craig: /* Execution & Pickup */

2016-06-06T13:07:53Z

Execution & Pickup

← Older revision		Revision as of 13:07, 6 June 2016
Line 163:		Line 163:
	''Auto Interrupt'' allows you to specify if you wish an [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Job]] to be interrupted when its maximum expected run length is exceeded. Only available as an option for those jobs that adhere to the [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Job]] requirements and have a maximum expected length specified. As of Obsidian 3.4.0.		''Auto Interrupt'' allows you to specify if you wish an [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Job]] to be interrupted when its maximum expected run length is exceeded. Only available as an option for those jobs that adhere to the [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Job]] requirements and have a maximum expected length specified. As of Obsidian 3.4.0.

	''Chain All'' allows you allows you specify the behaviour when this job is to be chained but is executing another instance at that moment. By default, only one newly chained instance will be queued. Choose this option to chain all such occurrences - As of Obsidian 2.0. As of Obsidian 3.8.0, each chained target instance is queued for the same minute. Ensure your Pickup Buffer is set large enough for these to be picked up and run in sequence. Prior to Obsidian 3.8.0, when Chain All was set and the target job would be chained multiple times, each target instance was chained one minute further into the future.		''Chain All'' allows you allows you specify the behaviour when this job is to be chained but is executing another instance at that moment. By default, only one newly chained instance will be queued. Choose this option to chain all such occurrences - as of Obsidian 2.0. As of Obsidian 3.8.0, each chained target instance is queued for the same minute. Ensure your Pickup Buffer is set large enough for these to be picked up and run in sequence. Prior to Obsidian 3.8.0, when Chain All was set and the target job would be chained multiple times, each target instance was chained one minute further into the future.

	== Saving ==		== Saving ==

Craig: /* Execution & Pickup */

2016-06-06T13:07:40Z

Execution & Pickup

← Older revision		Revision as of 13:07, 6 June 2016
Line 163:		Line 163:
	''Auto Interrupt'' allows you to specify if you wish an [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Job]] to be interrupted when its maximum expected run length is exceeded. Only available as an option for those jobs that adhere to the [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Job]] requirements and have a maximum expected length specified. As of Obsidian 3.4.0.		''Auto Interrupt'' allows you to specify if you wish an [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Job]] to be interrupted when its maximum expected run length is exceeded. Only available as an option for those jobs that adhere to the [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Job]] requirements and have a maximum expected length specified. As of Obsidian 3.4.0.

	''Chain All'' allows you allows you specify the behaviour when this job is to be chained but is executing another instance at that moment. By default, only one newly chained instance will be queued. Choose this option to chain all such occurrences. As of Obsidian 2.0. As of Obsidian 3.8.0, each chained target instance is queued for the same minute. Ensure your Pickup Buffer is set large enough for these to be picked up and run in sequence. Prior to Obsidian 3.8.0, when Chain All was set and the target job would be chained multiple times, each target instance was chained one minute further into the future.		''Chain All'' allows you allows you specify the behaviour when this job is to be chained but is executing another instance at that moment. By default, only one newly chained instance will be queued. Choose this option to chain all such occurrences - As of Obsidian 2.0. As of Obsidian 3.8.0, each chained target instance is queued for the same minute. Ensure your Pickup Buffer is set large enough for these to be picked up and run in sequence. Prior to Obsidian 3.8.0, when Chain All was set and the target job would be chained multiple times, each target instance was chained one minute further into the future.

	== Saving ==		== Saving ==