Obsidian Scheduler - Recent changes [en]

Release Notes

Craig — Wed, 12 Aug 2026 21:58:16 GMT

Bug Fixes

← Older revision		Revision as of 21:58, 12 August 2026
(One intermediate revision by the same user not shown)
Line 6:		Line 6:

	<div class="toclimit-2">__TOC__</div>		<div class="toclimit-2">__TOC__</div>

			== Obsidian 7.0.2 ==

			Released August 2026

			=== Bug Fixes ===

			* '''Scheduler startup on JDK 17''' — Fixed an issue where JDK 17 required Unsafe for GSON deserialization. Unsafe is globally disabled now.
			* '''Startup / shutdown job modes on Postgres and SQL Server''' — Job column for modes was too short for some mode values.

	== Obsidian 7.0.1 ==		== Obsidian 7.0.1 ==

Main Page

Craig — Wed, 12 Aug 2026 21:57:34 GMT

Wiki update

← Older revision		Revision as of 21:57, 12 August 2026
Line 1:		Line 1:
	'''[[Obsidian]]''' is a fully-featured Java-based scheduling application which supports load balancing, failover and job workflow. It is designed for [[Deployment Diagram\|high availability]], and it is specially built for demanding scheduling environments.		'''[[Obsidian]]''' is a fully-featured Java-based scheduling application which supports load balancing, failover and job workflow. It is designed for [[Deployment Diagram\|high availability]], and it is specially built for demanding scheduling environments.

	'''[[Release_Notes#Obsidian_7.0.1\|Version 7.0.1]]''' is the latest release, and was released in August 2026.		'''[[Release_Notes#Obsidian_7.0.2\|Version 7.0.2]]''' is the latest release, and was released in August 2026.

	Check out '''[[Getting Started]]''' if you are looking to set up Obsidian.		Check out '''[[Getting Started]]''' if you are looking to set up Obsidian.

Installation Guide

Craig — Sun, 02 Aug 2026 02:26:32 GMT

Offline or restricted-network install

Main Page

Craig — Sun, 02 Aug 2026 02:24:52 GMT

← Older revision		Revision as of 02:24, 2 August 2026
Line 1:		Line 1:
	'''[[Obsidian]]''' is a fully-featured Java-based scheduling application which supports load balancing, failover and job workflow. It is designed for [[Deployment Diagram\|high availability]], and it is specially built for demanding scheduling environments.		'''[[Obsidian]]''' is a fully-featured Java-based scheduling application which supports load balancing, failover and job workflow. It is designed for [[Deployment Diagram\|high availability]], and it is specially built for demanding scheduling environments.

	'''[[Release_Notes#Obsidian_7.0.0\|Version 7.0.0]]''' is the latest release, and was released in ~~July~~ 2026.		'''[[Release_Notes#Obsidian_7.0.1\|Version 7.0.1]]''' is the latest release, and was released in August 2026.

	Check out '''[[Getting Started]]''' if you are looking to set up Obsidian.		Check out '''[[Getting Started]]''' if you are looking to set up Obsidian.

Release Notes

Craig — Sun, 02 Aug 2026 02:24:21 GMT

← Older revision		Revision as of 02:24, 2 August 2026
Line 6:		Line 6:

	<div class="toclimit-2">__TOC__</div>		<div class="toclimit-2">__TOC__</div>

			== Obsidian 7.0.1 ==

			Released August 2026

			=== Bug Fixes ===

			* Fixed site and hardware-linked licence verification on Obsidian 7.0.0. Workaround for 7.0.0 available on request.

	== Obsidian 7.0.0 ==		== Obsidian 7.0.0 ==

Advanced Configuration

Craig — Fri, 31 Jul 2026 17:15:44 GMT

Dependent Libraries

Show changes

Installation Guide

Craig — Fri, 31 Jul 2026 15:37:28 GMT

@@ Line 65: / Line 65: @@
 == Obsidian Configuration ==
 [[Image:Obsidian-7.0.0-Configuring-Obsidian.png]]
+First, you must choose what [[Authenticator]] mechanism will be used within Obsidian. Obsidian supports five authentication methods: native (database), LDAP, OAuth (OIDC), SAML 2.0, and custom. Select ''Native (Database)'', ''LDAP'', ''OAuth (OIDC)'', ''SAML 2.0'', or ''Other'' (custom). ''Native (Database)'' requires no additional configuration and is what most users will select at least to start.
 Next, you'll want to select the email usage type. We highly recommend you configure Obsidian for email use as it will allow you to benefit from the event [[Event_Notifications|notification]] and [[Admin_Notifications|subscription]] support in Obsidian.
@@ Line 82: / Line 78: @@
 If you selected '''OAuth (OIDC)''' as the authentication type, the installer displays additional panels for OAuth configuration.
@@ Line 147: / Line 144: @@
 Before starting Obsidian, register the redirect URI shown in the installer at your IdP: Keycloak — Client → Settings → Valid Redirect URIs; Entra ID — App Registration → Authentication → Redirect URIs; Okta — Application → General Settings → Sign-in Redirect URIs; Auth0 — Application → Settings → Allowed Callback URLs. The URI must match ''com.carfey.suite.security.OAuthAuthenticator.redirectUri'' exactly, including scheme and port.
 ==== LDAP Configuration ====

Release Notes - Older Releases

Craig — Fri, 31 Jul 2026 15:14:43 GMT

← Older revision		Revision as of 15:14, 31 July 2026
Line 358:		Line 358:
	* Improved [[Admin_Job_Run_Time_Preview\|runtime preview]] listing performance.		* Improved [[Admin_Job_Run_Time_Preview\|runtime preview]] listing performance.
	* Automatic logging of Obsidian version number no longer requires special configuration.		* Automatic logging of Obsidian version number no longer requires special configuration.
	* [[Authenticator]] implementations including LDAP now support checking user validity when the "remember me" option is used to authenticate.		* [[Authenticator]] implementations including LDAP now support checking user validity when the "remember me" option is used to authenticate. (Remember Me feature removed in 7.0.0 - see [[Release_Notes#Obsidian_7.0.0\|Release Notes]].)
	* Runtime listing [[REST_Endpoints#GET_a_list_of_scheduled_runtimes_.28supports_multiple_jobs.29\|REST endpoint]] and [[Embedded_API#List_Scheduled_Runtimes\|Embedded API]] now support specifying a sort order, maximum quantity and parameter filtering, and now guarantee ordering by scheduled time.		* Runtime listing [[REST_Endpoints#GET_a_list_of_scheduled_runtimes_.28supports_multiple_jobs.29\|REST endpoint]] and [[Embedded_API#List_Scheduled_Runtimes\|Embedded API]] now support specifying a sort order, maximum quantity and parameter filtering, and now guarantee ordering by scheduled time.

Getting Started

Craig — Fri, 31 Jul 2026 15:11:41 GMT

← Older revision		Revision as of 15:11, 31 July 2026
Line 152:		Line 152:
	Alternatively, to use LDAP authentication, select the LDAP option in the installer and enter your LDAP details.		Alternatively, to use LDAP authentication, select the LDAP option in the installer and enter your LDAP details.

	As of 7.0.0, you can also select OAuth / OIDC authentication to enable Single Sign-On via an external identity provider. See [[Authenticator#OAuthAuthenticator_(OIDC_SSO)\|OAuthAuthenticator]] for details.		As of 7.0.0, you can also select OAuth / OIDC or SAML 2.0 authentication to enable Single Sign-On via an external identity provider. See [[Authenticator#OAuthAuthenticator_(OIDC_SSO)\|OAuthAuthenticator]] and [[Authenticator#SAMLAuthenticator_(SAML_2.0_SSO)\|SAMLAuthenticator]] for details.

	Finally, you may implement your own [[authenticator\|custom authenticator]] Java class, which you also enter when running the installer.		Finally, you may implement your own [[authenticator\|custom authenticator]] Java class, which you also enter when running the installer.

Legacy API

Craig — Fri, 31 Jul 2026 15:02:39 GMT

Craig deleted page Legacy API Documents the API deprecated in 2.3; superseded by Embedded API

Upgrading Obsidian

Craig — Fri, 31 Jul 2026 15:02:38 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 15:02, 31 July 2026
Line 63:		Line 63:

	== Database Upgrade Scripts ==		== Database Upgrade Scripts ==
	~~''Available as of version 3.0''~~

	When you start Obsidian, it will automatically upgrade the schema in your target database. However, if you wish to run Obsidian with a database user without create and drop privileges, or simply wish to prepare your database structure ahead of time, you can use the database upgrade scripts provided with your download zip file under the "db_scripts" directory.		When you start Obsidian, it will automatically upgrade the schema in your target database. However, if you wish to run Obsidian with a database user without create and drop privileges, or simply wish to prepare your database structure ahead of time, you can use the database upgrade scripts provided with your download zip file under the "db_scripts" directory.

Troubleshooting

Craig — Fri, 31 Jul 2026 15:02:30 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 15:02, 31 July 2026
Line 58:		Line 58:

	The quick start method runs Obsidian in a separate process to ensure you can gracefully stop it. Unfortunately, the separate process is failing before you can see what the problem is. To temporarily see the error and have it try to run in the same process, open the script in a text editor and find the line that launches Java: in <code>webObsidian.bat</code> it begins with <code>start "Obsidian" java</code>, and in <code>standaloneObsidian.bat</code> it begins with <code>start java</code>. Remove the <code>start</code> command and its window title if present (so the line begins with <code>java</code>), save the file and try again. You should get an informative message. Correct the underlying cause, restore the original line and run it again.		The quick start method runs Obsidian in a separate process to ensure you can gracefully stop it. Unfortunately, the separate process is failing before you can see what the problem is. To temporarily see the error and have it try to run in the same process, open the script in a text editor and find the line that launches Java: in <code>webObsidian.bat</code> it begins with <code>start "Obsidian" java</code>, and in <code>standaloneObsidian.bat</code> it begins with <code>start java</code>. Remove the <code>start</code> command and its window title if present (so the line begins with <code>java</code>), save the file and try again. You should get an informative message. Correct the underlying cause, restore the original line and run it again.






Line 139:		Line 135:
	If you have set a smaller value (e.g. 10), and have a very large amount of API or job activity, you can try increasing this value.		If you have set a smaller value (e.g. 10), and have a very large amount of API or job activity, you can try increasing this value.

	Most frequently though, this issue arises because Obsidian is configured to use a JNDI data source with its own connection pool, and there are incompatibilities between the pools' settings. As a rule, your JNDI database pool maximum size must be equal to or greater than the the maximum size of the Obsidian pool via property <code>com.carfey.obsidian.db.maxConnections</code> as outlined in [[Advanced_Configuration#Database_Properties\|Advanced Configuration]]. In addition, if there is an eviction process for idle connections, ensure than the value for the maximum idle age is 65 seconds or above to avoid warnings about unreleased connections. Alternatively~~, as of Obsidian 3.4.0~~, you can disable the Obsidian connection pool entirely by specifying <code>com.carfey.obsidian.db.disablePooling=true</code> in your <code>com.carfey.properties</code> file. This will cause Obsidian to never cache an opened idle connection.		Most frequently though, this issue arises because Obsidian is configured to use a JNDI data source with its own connection pool, and there are incompatibilities between the pools' settings. As a rule, your JNDI database pool maximum size must be equal to or greater than the the maximum size of the Obsidian pool via property <code>com.carfey.obsidian.db.maxConnections</code> as outlined in [[Advanced_Configuration#Database_Properties\|Advanced Configuration]]. In addition, if there is an eviction process for idle connections, ensure than the value for the maximum idle age is 65 seconds or above to avoid warnings about unreleased connections. Alternatively, you can disable the Obsidian connection pool entirely by specifying <code>com.carfey.obsidian.db.disablePooling=true</code> in your <code>com.carfey.properties</code> file. This will cause Obsidian to never cache an opened idle connection.

	Here is a good base JNDI pool configuration for Tomcat 7.		Here is a good base JNDI pool configuration for Tomcat 7.

Spring Integration

Craig — Fri, 31 Jul 2026 15:02:21 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 15:02, 31 July 2026
Line 3:		Line 3:
	= Dependency Injection via Spring =		= Dependency Injection via Spring =

	~~As of~~ Obsidian ~~2.2.0, Obsidian has greatly improved the integration~~ with your Spring dependency injection container, and ~~now~~ supports loading job implementations from the Spring context. Obsidian does not include any Spring libraries and will defer to the version and libraries you include with your application. It supports versions of Spring from 2.5 onward.		Obsidian integrates with your Spring dependency injection container, and supports loading job implementations from the Spring context. Obsidian does not include any Spring libraries and will defer to the version and libraries you include with your application. It supports versions of Spring from 2.5 onward.

	Obsidian uses the <code>@Component</code> and any Spring or custom extensions of those annotations (such as <code>@Service</code> and <code>@Repository</code>) as a basis for knowing which job implementations should be retrieved from the Spring context. It is important to note that if a job class does not have one of these annotations, '''Obsidian will not use the container version''', and will instantiate the job directly.		Obsidian uses the <code>@Component</code> and any Spring or custom extensions of those annotations (such as <code>@Service</code> and <code>@Repository</code>) as a basis for knowing which job implementations should be retrieved from the Spring context. It is important to note that if a job class does not have one of these annotations, '''Obsidian will not use the container version''', and will instantiate the job directly.
Line 13:		Line 13:
	Spring will need to be configured and started in all Obsidian scheduler runtimes, but not standalone Admin UI web apps. Each environment will require the job classes to be wired in Spring, scheduler nodes to permit retrieval from the context for execution, admin deployments to allow retrieval from the context for configuration validation.		Spring will need to be configured and started in all Obsidian scheduler runtimes, but not standalone Admin UI web apps. Each environment will require the job classes to be wired in Spring, scheduler nodes to permit retrieval from the context for execution, admin deployments to allow retrieval from the context for configuration validation.

	To allow Obsidian to locate your application's Spring context, you will need to ensure Obsidian's [~~http~~://docs.spring.io/spring/docs/2.5.6/api/org/springframework/context/ApplicationContextAware.html ApplicationContextAware] implementation is configured by Spring. If you are using Spring's classpath scanning, you can use the following approach to add an additional package to your configuration:		To allow Obsidian to locate your application's Spring context, you will need to ensure Obsidian's [https://docs.spring.io/spring/docs/3.2.18.RELEASE/api/org/springframework/context/ApplicationContextAware.html ApplicationContextAware] implementation is configured by Spring. If you are using Spring's classpath scanning, you can use the following approach to add an additional package to your configuration:

	<context:component-scan base-package="com.my.package.scan.base''', com.carfey.ops.job.di'''"/>		<context:component-scan base-package="com.my.package.scan.base''', com.carfey.ops.job.di'''"/>
Line 23:		Line 23:
	If you have multiple instances of a given bean type in your Spring context, please ensure you use the <code>value=""</code> when you annotate your job with <code>@Component</code> or its specializations as this is how Obsidian will uniquely identify the job within the Spring context.		If you have multiple instances of a given bean type in your Spring context, please ensure you use the <code>value=""</code> when you annotate your job with <code>@Component</code> or its specializations as this is how Obsidian will uniquely identify the job within the Spring context.

	~~As of '''Obsidian 2.2.1''', implementations~~ of <code>SchedulableJob</code> found in your [~~http~~://docs.spring.io/spring/docs/2.5.6/api/org/springframework/context/ApplicationContext.html ApplicationContext] will automatically be available in the [[Admin_Jobs#Adding_.26_Editing_Jobs\|Job Admin]] screen thus avoiding needing to configure distinct [[Implementing_Jobs#Classpath_Scanning\|Classpath Scanning]]. If you're using at least Spring 3.0, your [[Implementing_Jobs#Annotation-Based_Jobs\|annotated]] jobs will also be found in the Spring <code>ApplicationContext</code>.		Implementations of <code>SchedulableJob</code> found in your [https://docs.spring.io/spring/docs/3.2.18.RELEASE/api/org/springframework/context/ApplicationContext.html ApplicationContext] will automatically be available in the [[Admin_Jobs#Adding_.26_Editing_Jobs\|Job Admin]] screen thus avoiding needing to configure distinct [[Implementing_Jobs#Classpath_Scanning\|Classpath Scanning]]. If you're using at least Spring 3.0, your [[Implementing_Jobs#Annotation-Based_Jobs\|annotated]] jobs will also be found in the Spring <code>ApplicationContext</code>.

	== Grails ==		== Grails ==
Line 101:		Line 101:
	Obsidian can run scheduler nodes that do not include the full web application deployment. This is often used in conjunction with a separate standalone admin web application.		Obsidian can run scheduler nodes that do not include the full web application deployment. This is often used in conjunction with a separate standalone admin web application.

	~~As of 2.2.1,~~ Obsidian comes bundled with a simple Spring component to automatically start and stop an embedded scheduler. <code>com.carfey.ops.job.di.SpringSchedulerStarter</code> can be wired into your Spring application via XML:		Obsidian comes bundled with a simple Spring component to automatically start and stop an embedded scheduler. <code>com.carfey.ops.job.di.SpringSchedulerStarter</code> can be wired into your Spring application via XML:

	<pre>		<pre>

Scripting Jobs

Craig — Fri, 31 Jul 2026 15:02:12 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 15:02, 31 July 2026
Line 9:		Line 9:
	* com.carfey.ops.job.script.RubyJob executing a [https://www.jruby.org/ JRuby] script. ''Supported as of Obsidian 4.10.0''		* com.carfey.ops.job.script.RubyJob executing a [https://www.jruby.org/ JRuby] script. ''Supported as of Obsidian 4.10.0''
	* com.carfey.ops.job.script.ReflectiveJob is a convenience GroovyJob that does not require a script, using defined parameters to construct an object and invoke method(s), both supporting argument(s)		* com.carfey.ops.job.script.ReflectiveJob is a convenience GroovyJob that does not require a script, using defined parameters to construct an object and invoke method(s), both supporting argument(s)
	* <strike>com.carfey.ops.job.script.[[#SpringBeanJob\|SpringBeanJob]]</strike> is a convenience GroovyJob that does not require a script, using defined parameters to obtain the bean and invoke the method(s). Deprecated ~~as of Obsidian 2.2.0~~. Use [[Implementing_Jobs#Dependency_Injection_via_Spring\|Dependency Injection]] instead.		* <strike>com.carfey.ops.job.script.[[#SpringBeanJob\|SpringBeanJob]]</strike> is a convenience GroovyJob that does not require a script, using defined parameters to obtain the bean and invoke the method(s). Deprecated. Use [[Implementing_Jobs#Dependency_Injection_via_Spring\|Dependency Injection]] instead.

	= Parameters =		= Parameters =
Line 16:		Line 16:
	== Loading Scripts from the File System ==		== Loading Scripts from the File System ==

	~~As of Obsidian 2.4, all~~ script file jobs can ~~now~~ use a script file path instead of configuring the script directly in Obsidian. When the job runs, Obsidian will load the contents of the file and execute the script in the same way that jobs configured using the <code>script</code> parameter are run.		All script file jobs can use a script file path instead of configuring the script directly in Obsidian. When the job runs, Obsidian will load the contents of the file and execute the script in the same way that jobs configured using the <code>script</code> parameter are run.

	To use this feature, when configuring the job, omit the <code>script</code> parameter and instead supply a file path under <code>Script File Path</code>. It is recommended that an absolute path is used, and the Obsidian process will need read access to the file for it to run successfully.		To use this feature, when configuring the job, omit the <code>script</code> parameter and instead supply a file path under <code>Script File Path</code>. It is recommended that an absolute path is used, and the Obsidian process will need read access to the file for it to run successfully.
Line 40:		Line 40:

	= <div id="SpringBeanJob">SpringBeanJob</div> =		= <div id="SpringBeanJob">SpringBeanJob</div> =
	'''Deprecated ~~as of Obsidian 2.2.0~~.''' Use [[Implementing_Jobs#Dependency_Injection_via_Spring\|Dependency Injection]] instead.		'''Deprecated.''' Use [[Implementing_Jobs#Dependency_Injection_via_Spring\|Dependency Injection]] instead.
	A SpringBeanJob is simply a convenience GroovyJob with a predefined script that uses some specified parameters to find a Spring Bean and invoke specified method(s). Specify any optional class imports (class names only), the single line of code to retrieve the Spring Bean reference and the method name(s) to invoke.		A SpringBeanJob is simply a convenience GroovyJob with a predefined script that uses some specified parameters to find a Spring Bean and invoke specified method(s). Specify any optional class imports (class names only), the single line of code to retrieve the Spring Bean reference and the method name(s) to invoke.

Release Notes - Older Releases

Craig — Fri, 31 Jul 2026 14:49:59 GMT

De-link the deleted Legacy API page

← Older revision		Revision as of 14:49, 31 July 2026
Line 708:		Line 708:
	Released November 2013.		Released November 2013.
	==== Features / Enhancements ====		==== Features / Enhancements ====
	* Fully unified [[Embedded API]] which contains same operations and has same semantics as the [[REST API]]. The previous [[Legacy API~~\|API]]~~ is now deprecated.		* Fully unified [[Embedded API]] which contains same operations and has same semantics as the [[REST API]]. The previous Legacy API is now deprecated.
	* [[REST API]] bean classes bundled in <code>obsidian.jar</code> for simplified Java integration.		* [[REST API]] bean classes bundled in <code>obsidian.jar</code> for simplified Java integration.
	* Submission of [[Admin_Jobs#Ad_Hoc_.26_One-Time_Run_Submission\|one-time job runs]] via the UI now allows specifying exact minutes instead of 5 minute intervals.		* Submission of [[Admin_Jobs#Ad_Hoc_.26_One-Time_Run_Submission\|one-time job runs]] via the UI now allows specifying exact minutes instead of 5 minute intervals.
Line 728:		Line 728:
	* Correct custom calendar reversed PUT/POST for [[REST API]], and implement standardized date formatting.		* Correct custom calendar reversed PUT/POST for [[REST API]], and implement standardized date formatting.
	* UI table listings no longer flash error message when quickly navigating away during a request.		* UI table listings no longer flash error message when quickly navigating away during a request.
	* [[Legacy API]] calls no longer incorrectly start non-daemon threads for notifications and event logging.		* Legacy API calls no longer incorrectly start non-daemon threads for notifications and event logging.
	* Lock issues when evaluating many [[Chaining\|chained jobs]].		* Lock issues when evaluating many [[Chaining\|chained jobs]].

REST Endpoints

Craig — Fri, 31 Jul 2026 14:49:58 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

Show changes

REST API

Craig — Fri, 31 Jul 2026 14:49:57 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 95:		Line 95:
	Enumerations are consistent with the [[Unified_API#Enumerations\|Embedded API's enumerations]].		Enumerations are consistent with the [[Unified_API#Enumerations\|Embedded API's enumerations]].

	'''Note:''' Prior to 2.5, Enumerations in the REST API would in some cases return values with spaces instead of underscores, and would accept enumerations in requests in the same format. This is no longer supported.

	= JSON Bean Classes =		= JSON Bean Classes =

	~~As of version 2.3,~~ Obsidian comes bundled with simple bean classes in the package <code>com.carfey.ops.api.bean</code> that can be used to serialize JSON requests and deserialize responses into plain old Java objects (POJOs). These bean classes are located in <code>obsidian.jar</code> which is included in your Obsidian zip download within the <code>standalone</code> directory.		Obsidian comes bundled with simple bean classes in the package <code>com.carfey.ops.api.bean</code> that can be used to serialize JSON requests and deserialize responses into plain old Java objects (POJOs). These bean classes are located in <code>obsidian.jar</code> which is included in your Obsidian zip download within the <code>standalone</code> directory.

	These classes are tested with [https://github.com/google/gson Gson] since that is what Obsidian uses internally, but you can integrate it with the JSON library of your choosing. Obsidian uses custom types for dates and datetimes, so see the following section on how to configure JSON serialization correctly.		These classes are tested with [https://github.com/google/gson Gson] since that is what Obsidian uses internally, but you can integrate it with the JSON library of your choosing. Obsidian uses custom types for dates and datetimes, so see the following section on how to configure JSON serialization correctly.

	'''Compatibility Note:''' If upgrading to Obsidian 2.5, you will notice that bean classes for requests now use typed enumeration values instead of String values. You may have to make small modifications to your code which uses these classes.

	Each [[REST Endpoints\|endpoint]] documents the appropriate bean class to use.		Each [[REST Endpoints\|endpoint]] documents the appropriate bean class to use.

Obsidian Tables

Craig — Fri, 31 Jul 2026 14:49:57 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 42:		Line 42:
	== Oracle Privileges ==		== Oracle Privileges ==

	~~As of version 2.1, if~~ you are not using the schema owner as your Obsidian database user, the following privileges will need to be granted to your database user:		If you are not using the schema owner as your Obsidian database user, the following privileges will need to be granted to your database user:

	<pre>		<pre>

Licenses & Nodes

Craig — Fri, 31 Jul 2026 14:49:56 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 5:		Line 5:
	* Running scheduler instances must have access to the Internet to lease and verify the license.		* Running scheduler instances must have access to the Internet to lease and verify the license.
	* Every license key has one or more valid licenses associated with it.		* Every license key has one or more valid licenses associated with it.



Line 17:		Line 16:
	Obsidian also supports hardware licenses. These are tied to deployment hardware and are not floating. Contact [[Contact Carfey Software\|Carfey Software]] for further details.		Obsidian also supports hardware licenses. These are tied to deployment hardware and are not floating. Contact [[Contact Carfey Software\|Carfey Software]] for further details.

	~~As of Obsidian 2.1,~~ Obsidian can also be run under a site license. When Obsidian is run under a site license, no Internet connectivity and verification is required and a specific maximum number of nodes are permitted within the licensed organization based on prior agreement. Contact [[Contact Carfey Software\|Carfey Software]] for further details.		Obsidian can also be run under a site license. When Obsidian is run under a site license, no Internet connectivity and verification is required and a specific maximum number of nodes are permitted within the licensed organization based on prior agreement. Contact [[Contact Carfey Software\|Carfey Software]] for further details.

	=Nodes=		=Nodes=

Key Server Proxy

Craig — Fri, 31 Jul 2026 14:49:56 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 3:		Line 3:
	In your software package, you would have received the key server proxy as <code>obsidianKeyProxy.war</code>. Within this war, under <code>WEB-INF/classes</code> is <code>com.carfey.properties</code>. Note you should not need to edit the master key server url, which is fixed at "https://licence.carfey.com/proxy".		In your software package, you would have received the key server proxy as <code>obsidianKeyProxy.war</code>. Within this war, under <code>WEB-INF/classes</code> is <code>com.carfey.properties</code>. Note you should not need to edit the master key server url, which is fixed at "https://licence.carfey.com/proxy".

	'''~~Prior to Obsidian 2.5.0~~'''		Once the proxy is deployed, to configure use of the key server proxy by the Obsidian scheduler, simply login to Obsidian Web Admin app as an admin user, open [[Admin_Scheduler_Settings\|Scheduler Settings]], select the ''Licence'' category and set the address of your deployed key server proxy as the ''clientKeyServerUrl''. Make sure it ends with "/licence", e.g. "https://internal.server/licence".
	~~Within the file <code>com~~.~~carfey~~.~~properties<~~/~~code>, you should set your license key, based on the template provided~~.

	Once the proxy is deployed, to configure use of the key server proxy by the Obsidian scheduler, simply login to Obsidian Web Admin app as an admin user, access the System tab, select the ''Licence'' category and set the address of your deployed key server proxy as the ''clientKeyServerUrl''. Make sure it ends with "/licence", e.g. "https://internal.server/licence".		Then make sure the value for the [[Admin_Scheduler_Settings\|scheduler setting]] ''clientKeyServerUrlBackup'' is set to Carfey Software's key license server at https://licence.carfey.com/licence. This will give you failover in case your proxy goes down.

	Then make sure the value for the [[~~Admin System_(3.x.x and earlier)~~\|~~system~~ setting]] ''clientKeyServerUrlBackup'' is set to Carfey Software's key license server at https://licence.carfey.com/licence. This will give you failover in case your proxy goes down.

	'''Security Note:''' By default, the proxy key server allows non-secure connections. If you wish to force secure connections through HTTPS, you can edit the web.xml in your war and uncomment the <security-constraint> element in the file. This will force all requests to redirect to an encrypted connection. For details on setting up SSL on your servlet container, refer to its documentation.		'''Security Note:''' By default, the proxy key server allows non-secure connections. If you wish to force secure connections through HTTPS, you can edit the web.xml in your war and uncomment the <security-constraint> element in the file. This will force all requests to redirect to an encrypted connection. For details on setting up SSL on your servlet container, refer to its documentation.

Job Forking

Craig — Fri, 31 Jul 2026 14:49:55 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 1:		Line 1:
	~~As of Obsidian 3.0.0,~~ Obsidian can run each job in its own JVM. This allows for a number of possibilities, including support for dynamic changes to your deployed jobs (i.e. hot-swapping of JARs). In theory, you could even specialize classpaths on a per job basis by customizing the provided execution scripts.		Obsidian can run each job in its own JVM. This allows for a number of possibilities, including support for dynamic changes to your deployed jobs (i.e. hot-swapping of JARs). In theory, you could even specialize classpaths on a per job basis by customizing the provided execution scripts.

	JVM job forking is disabled by default. Standalone deployments support forking out-of-the-box, but it is not active until you enable it as defined in [[#Configuring_Job_Forking\|Configuring Job Forking]].		JVM job forking is disabled by default. Standalone deployments support forking out-of-the-box, but it is not active until you enable it as defined in [[#Configuring_Job_Forking\|Configuring Job Forking]].
Line 14:		Line 14:
	== Interrupt Support ==		== Interrupt Support ==

	~~As of Obsidian 3.6.0, forked~~ jobs can be interrupted. See [[Job_Forking#Configuring_Job_Forking \| Configuring Job Forking]] below.		Forked jobs can be interrupted. See [[Job_Forking#Configuring_Job_Forking \| Configuring Job Forking]] below.

	= Configuring Job Forking =		= Configuring Job Forking =
Line 22:		Line 22:
	To use forking, first you must enable a setting (''jvmJobForkingEnabled'') that will apply across the cluster. This is a [[Admin Scheduler Settings\|scheduler setting]] found in the ''Job Spawner'' category. You may enable it through the admin web application, the [[Embedded API]], [[REST API]], or Obsidian's [[Initializing and Restoring\|initialization & restore]] support.		To use forking, first you must enable a setting (''jvmJobForkingEnabled'') that will apply across the cluster. This is a [[Admin Scheduler Settings\|scheduler setting]] found in the ''Job Spawner'' category. You may enable it through the admin web application, the [[Embedded API]], [[REST API]], or Obsidian's [[Initializing and Restoring\|initialization & restore]] support.

	If you wish to enable interruption of forked jobs that implement the necessary [[Implementing_Jobs#Interruptable_Jobs\|Interruptable]] interface, you must also enable the setting ''jvmForkedJobsCanBeInterrupted'' also found in the ''Job Spawner'' category~~, introduced as of Obsidian 3.6.0~~.		If you wish to enable interruption of forked jobs that implement the necessary [[Implementing_Jobs#Interruptable_Jobs\|Interruptable]] interface, you must also enable the setting ''jvmForkedJobsCanBeInterrupted'' also found in the ''Job Spawner'' category.

Job Features

Craig — Fri, 31 Jul 2026 14:49:54 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

Installation Guide

Craig — Fri, 31 Jul 2026 14:49:54 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 1:		Line 1:
	'''This installation guide generally applies to Obsidian versions 4.0 and newer but is specific to 7.0. You may see a few minor differences in 4.x, 5.x and 6.x releases~~. See the [[Installation_Guide_(3.x.x_and_earlier)\|Installation Guide]] for all prior versions~~.		'''This installation guide generally applies to Obsidian versions 4.0 and newer but is specific to 7.0. You may see a few minor differences in 4.x, 5.x and 6.x releases.

	This installation guide is a companion to the Obsidian Installer UI. Its purpose is to provide additional detail as to the meaning of various inputs and to provide guidance on advanced usage of the installer.		This installation guide is a companion to the Obsidian Installer UI. Its purpose is to provide additional detail as to the meaning of various inputs and to provide guidance on advanced usage of the installer.

Initializing and Restoring

Craig — Fri, 31 Jul 2026 14:49:53 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 83:		Line 83:
	"recoveryType": "NONE",		"recoveryType": "NONE",
	"hosts": [ "Demo-PC" ],		"hosts": [ "Demo-PC" ],
	"ordinalParameters": [ ~~// as of 3.8.0, prior to 3.8.0, this was simply the child element "parameters"~~		"ordinalParameters": [
	"ordinal": 0, ~~// as of 3.8.0~~		"ordinal": 0,
	"parameters": [		"parameters": [
	{		{

Implementing Jobs

Craig — Fri, 31 Jul 2026 14:49:53 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 3:		Line 3:
	We recommend you review this page fully before implementing your own jobs. Obsidian provides you features that are not available in other schedulers which greatly improve re-usability and help ensure reliable execution. Reviewing this page and considering all available features will help you make the best choices for your needs.		We recommend you review this page fully before implementing your own jobs. Obsidian provides you features that are not available in other schedulers which greatly improve re-usability and help ensure reliable execution. Reviewing this page and considering all available features will help you make the best choices for your needs.

	You can also look at examples in our convenience [[Built-in_Jobs\|Built-in Jobs]] that have been open-sourced under the [[https://opensource.org/license/mit/ MIT License]] ~~as of Obsidian 2.7.0~~. In the root of the installation folder, you can find the source in <code>obsidian-builtin-job-src.jar</code>.		You can also look at examples in our convenience [[Built-in_Jobs\|Built-in Jobs]] that have been open-sourced under the [[https://opensource.org/license/mit/ MIT License]]. In the root of the installation folder, you can find the source in <code>obsidian-builtin-job-src.jar</code>.

	In addition, you can check out our [https://web.obsidianscheduler.com/obsidianapi/ Javadoc] which documents the features you'll need to write your own Obsidian jobs. We recommend you consult with the Javadoc in combination with this page to understand the best way to use Obsidian's job functionality.		In addition, you can check out our [https://web.obsidianscheduler.com/obsidianapi/ Javadoc] which documents the features you'll need to write your own Obsidian jobs. We recommend you consult with the Javadoc in combination with this page to understand the best way to use Obsidian's job functionality.
Line 126:		Line 126:
	public String name();		public String name();
	public boolean required();		public boolean required();
	public boolean requiredAtRuntime(); ~~// as of 3.7.0~~		public boolean requiredAtRuntime();
	public Type type() default Type.STRING;		public Type type() default Type.STRING;
	public boolean allowMultiple() default false;		public boolean allowMultiple() default false;
	public String defaultValue() default "";		public String defaultValue() default "";
	public Class<? extends ListProvider> listProvider() default StaticListProvider.class; ~~// as of 3.3.0~~		public Class<? extends ListProvider> listProvider() default StaticListProvider.class;
	public String[] listArgs() default {}; ~~// as of 3.3.0~~		public String[] listArgs() default {};
	public String description() default ""; // as of 4.0.2		public String description() default ""; // as of 4.0.2
	public String[] urls() default {}; //as of 4.9.0		public String[] urls() default {}; //as of 4.9.0
Line 140:		Line 140:
	''As of Obsidian 4.0.2'', a parameter can be associated with a <code>description</code> that is integrated with help information displayed in the user interface. This description is also returned in the API calls that return job parameter information.		''As of Obsidian 4.0.2'', a parameter can be associated with a <code>description</code> that is integrated with help information displayed in the user interface. This description is also returned in the API calls that return job parameter information.

	~~''As of Obsidian 3.7.0'', a~~ parameter can be defined as <code>requiredAtRuntime</code>. This allows the job to be configured without a parameter, but ensures a parameter value is set with one-time submissions. Of course, if it is configured with a parameter value, one-time submissions will not require a value.		A parameter can be defined as <code>requiredAtRuntime</code>. This allows the job to be configured without a parameter, but ensures a parameter value is set with one-time submissions. Of course, if it is configured with a parameter value, one-time submissions will not require a value.

	''As of Obsidian 4.9.0'', Parameters support providing an optional array of <code>urls</code>. Any provided URLs are displayed in the UI's inline help for the parameter. This is useful for linking to additional documentation regarding your parameter.		''As of Obsidian 4.9.0'', Parameters support providing an optional array of <code>urls</code>. Any provided URLs are displayed in the UI's inline help for the parameter. This is useful for linking to additional documentation regarding your parameter.
Line 148:		Line 148:
	== List Parameterization ==		== List Parameterization ==

	~~''As of Obsidian 3.3.0'', you~~ can directly specify a list of valid values within a <code>@Parameter</code> annotation by using the <code>listArgs</code> option. The [[Admin_Jobs\|job screen]] will then present the values for these parameters as a selection list. Note that if <code>required</code> is set to false, an empty value will automatically be included in the list.		You can directly specify a list of valid values within a <code>@Parameter</code> annotation by using the <code>listArgs</code> option. The [[Admin_Jobs\|job screen]] will then present the values for these parameters as a selection list. Note that if <code>required</code> is set to false, an empty value will automatically be included in the list.

	<pre>		<pre>
Line 175:		Line 175:
	=== Dynamic File Lists ===		=== Dynamic File Lists ===

	~~As of Obsidian 3.3.0, if~~ you wish to define a parameter which enumerates a file listing based on a server-side directory, you can use the built-in [https://web.obsidianscheduler.com/obsidianapi/com/carfey/ops/job/param/FileListProvider.html FileListProvider]. It also marked with the [https://web.obsidianscheduler.com/obsidianapi/com/carfey/ops/job/param/ListProvider.DynamicListProvider.html DynamicListProvider] annotation explained below.		If you wish to define a parameter which enumerates a file listing based on a server-side directory, you can use the built-in [https://web.obsidianscheduler.com/obsidianapi/com/carfey/ops/job/param/FileListProvider.html FileListProvider]. It also marked with the [https://web.obsidianscheduler.com/obsidianapi/com/carfey/ops/job/param/ListProvider.DynamicListProvider.html DynamicListProvider] annotation explained below.


Line 193:		Line 193:
	By default, all <code>@Configuration</code> annotations on the job class hierarchy are inherited by children and their parameters are combined. However, if a subclass defines a parameter with the same name as a parent class, the subclass version will override the parent version.		By default, all <code>@Configuration</code> annotations on the job class hierarchy are inherited by children and their parameters are combined. However, if a subclass defines a parameter with the same name as a parent class, the subclass version will override the parent version.

	~~As of Obsidian 3.0,~~ <code>@Configuration</code> ~~added~~ a <code>replaceInherited</code> attribute. If set to true, parent classes' <code>@Configuration</code> annotations are completely ignored, effectively replacing their parameter definitions completely.		The <code>@Configuration</code> annotation supports a <code>replaceInherited</code> attribute. If set to true, parent classes' <code>@Configuration</code> annotations are completely ignored, effectively replacing their parameter definitions completely.

	== Global Parameters ==		== Global Parameters ==

	Obsidian ~~2.5 introduced~~ [[Admin_Global_Parameters\|Global Parameters]]. These let you configure job parameters globally, and then simply import them into jobs as needed. Global parameters help avoid repeating the same configuration steps over and over, and can even be used to hide sensitive values from users, since they have separate access control in the admin web application.		Obsidian supports [[Admin_Global_Parameters\|Global Parameters]]. These let you configure job parameters globally, and then simply import them into jobs as needed. Global parameters help avoid repeating the same configuration steps over and over, and can even be used to hide sensitive values from users, since they have separate access control in the admin web application.

	By default, if a job parameter is configured with a value that is surrounded by double curly braces (e.g. <code>{{param}}</code>), then it is treated as a global parameter reference. When Obsidian sees a global parameter reference in this format during job execution, it imports all configured global parameters under the name (e.g. <code>param</code>) in place of the reference. 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.		By default, if a job parameter is configured with a value that is surrounded by double curly braces (e.g. <code>{{param}}</code>), then it is treated as a global parameter reference. When Obsidian sees a global parameter reference in this format during job execution, it imports all configured global parameters under the name (e.g. <code>param</code>) in place of the reference. 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.
Line 211:		Line 211:
	=== Global Substitution Mode ===		=== Global Substitution Mode ===

	~~''Available as of Obsidian 3.4.0''~~

	In some cases, you may wish to embed global parameters inside other parameters, rather than substitute them entirely. For example, when using a [[Built-in_Jobs#Script_Job\|ScriptFileJob]], you may wish to inject a global parameter value into an argument passed into a script as follows:		In some cases, you may wish to embed global parameters inside other parameters, rather than substitute them entirely. For example, when using a [[Built-in_Jobs#Script_Job\|ScriptFileJob]], you may wish to inject a global parameter value into an argument passed into a script as follows:
Line 289:		Line 288:
	context.saveJobResult(resultsParamName, oldResults + " Updated");		context.saveJobResult(resultsParamName, oldResults + " Updated");

	// ~~As of 2.2, you~~ can save multiple results at a time as a convenience.		// You can save multiple results at a time as a convenience.
	context.saveMultipleJobResults("file", Arrays.asList("first", "second"));		context.saveMultipleJobResults("file", Arrays.asList("first", "second"));

	// ~~As of 3.6, you~~ can replace job results.		// You can replace job results.
	context.replaceJobResult(resultsParamName, "replace old value");		context.replaceJobResult(resultsParamName, "replace old value");
	context.replaceMultipleJobResults("file", Arrays.asList("third", "fourth"));		context.replaceMultipleJobResults("file", Arrays.asList("third", "fourth"));
Line 353:		Line 352:
	[https://web.obsidianscheduler.com/obsidianapi/com/carfey/ops/job/InterruptableJob.html InterruptableJob Javadoc]		[https://web.obsidianscheduler.com/obsidianapi/com/carfey/ops/job/InterruptableJob.html InterruptableJob Javadoc]

	[https://web.obsidianscheduler.com/obsidianapi/com/carfey/ops/job/InterruptableContextJob.html InterruptableContextJob Javadoc] ~~(since 3.2)~~		[https://web.obsidianscheduler.com/obsidianapi/com/carfey/ops/job/InterruptableContextJob.html InterruptableContextJob Javadoc]

	~~As of Obsidian 1.5.1, it~~ is possible to '''terminate''' a running job on a best effort basis. ~~As of Obsidian 3.6.0,~~ [[Job_Forking\|Forked Jobs]] can also be interrupted.		It is possible to '''terminate''' a running job on a best effort basis. [[Job_Forking\|Forked Jobs]] can also be interrupted.

	In some exceptional cases, it may be necessary or desirable to force termination of a job. Since exposing this functionality for all jobs could result in unexpected and even dangerous results, Obsidian provides two Java interfaces that are used specifically for this function.		In some exceptional cases, it may be necessary or desirable to force termination of a job. Since exposing this functionality for all jobs could result in unexpected and even dangerous results, Obsidian provides two Java interfaces that are used specifically for this function.
Line 382:		Line 381:

	== JVM Forking ==		== JVM Forking ==
	~~Obsidian 3.0 introduced~~ [[Job_Forking\|Job Forking]] ~~which~~ runs each job in its own JVM instance which is started for each execution. This enables hot-swapping of JARs so that jobs can be updated without restarts. By default, this feature works on standalone instances, but other modes can be supported with minor customization.		[[Job_Forking\|Job Forking]] runs each job in its own JVM instance which is started for each execution. This enables hot-swapping of JARs so that jobs can be updated without restarts. By default, this feature works on standalone instances, but other modes can be supported with minor customization.

	= Classpath Scanning =		= Classpath Scanning =
Line 398:		Line 397:


			You can also configure how often Obsidian will check "packageScannerPrefix" for changes, which results in a re-scan of available jobs. This is done via the "classpathScanFrequency" parameter in the "Job" category in [[Admin_Scheduler Settings\|scheduler settings]].
	~~As of 3.0.1, you~~ can also configure how often Obsidian will check "packageScannerPrefix" for changes, which results in a re-scan of available jobs. This is done via the "classpathScanFrequency" parameter in the "Job" category in [[Admin_Scheduler Settings\|scheduler settings]].

	If you are using Spring and wish to integrate Obsidian and [[Spring_Integration\|Spring]], you will likely not need to use this distinct classpath scanning functionality, since jobs found in the Spring context will be available in the [[Admin_Jobs#Adding_.26_Editing_Jobs\|job edit screen]] automatically.		If you are using Spring and wish to integrate Obsidian and [[Spring_Integration\|Spring]], you will likely not need to use this distinct classpath scanning functionality, since jobs found in the Spring context will be available in the [[Admin_Jobs#Adding_.26_Editing_Jobs\|job edit screen]] automatically.

	= Initializing Jobs on Startup =		= Initializing Jobs on Startup =
	If you're interested in initializing your jobs into Obsidian on startup without having to write and execute code or manually configure them using the UI, you can use the [[Initializing and Restoring]] functionality ~~available as of Obsidian 3.0.0~~.		If you're interested in initializing your jobs into Obsidian on startup without having to write and execute code or manually configure them using the UI, you can use the [[Initializing and Restoring]] functionality.

	= Best Practices =		= Best Practices =

Getting Started

Craig — Fri, 31 Jul 2026 14:49:52 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 1:		Line 1:
	This Getting Started is for Obsidian 4.0 and newer ~~versions. See the [[Getting_Started_(3.x.x_and_earlier)\|Previous Getting Started]] for prior~~ versions.''		This Getting Started is for Obsidian 4.0 and newer versions.''

FAQ

Craig — Fri, 31 Jul 2026 14:49:51 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 63:		Line 63:
	Out of the box, Obsidian will display any previously scheduled jobs and Obsidian's bundled jobs. You can type in your class name as described in [[Admin_Jobs#Nickname.2C_Class_and_Folder\|Admin Jobs]].		Out of the box, Obsidian will display any previously scheduled jobs and Obsidian's bundled jobs. You can type in your class name as described in [[Admin_Jobs#Nickname.2C_Class_and_Folder\|Admin Jobs]].

	~~As of '''Obsidian 2.2.1''', you~~ can take advantage of our [[Spring_Integration\|Spring Integration]]. Jobs that have been wired into your <code>ApplicationContext</code> will be available in the list.		You can take advantage of our [[Spring_Integration\|Spring Integration]]. Jobs that have been wired into your <code>ApplicationContext</code> will be available in the list.

	You can also use Obsidian's [[Implementing_Jobs#Classpath_Scanning\|classpath scanning]] as of '''Obsidian 2.0'''. Note that for this feature to work, the user account running Obsidian must have read privileges to the <code>WEB-INF</code> directory of Obsidian's deployment directory.		You can also use Obsidian's [[Implementing_Jobs#Classpath_Scanning\|classpath scanning]] as of '''Obsidian 2.0'''. Note that for this feature to work, the user account running Obsidian must have read privileges to the <code>WEB-INF</code> directory of Obsidian's deployment directory.

Embedded API

Craig — Fri, 31 Jul 2026 14:49:51 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

Show changes

Email Templates

Craig — Fri, 31 Jul 2026 14:49:50 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 1:		Line 1:
	~~As of version 2.0,~~ Obsidian supports customizable templates for all email notifications.		Obsidian supports customizable templates for all email notifications.

	If you have questions or require help building your own templates, please [[Contact Carfey Software\|contact us]] for free support.		If you have questions or require help building your own templates, please [[Contact Carfey Software\|contact us]] for free support.
Line 36:		Line 36:
	\| level \|\| Text \|\| Always \|\| Indicates the level of the event. One of: <code>INFO</code>, <code>WARNING</code>, <code>ERROR</code>, <code>FATAL</code>.		\| level \|\| Text \|\| Always \|\| Indicates the level of the event. One of: <code>INFO</code>, <code>WARNING</code>, <code>ERROR</code>, <code>FATAL</code>.
	\|-		\|-
	\| category \|\| Text \|\| Always \|\| Indicates the category of the event~~. Available as of 2.3~~. One of: <code>SYSTEM_PARAMETER</code>, <code>QUEUE</code>, <code>JOB</code>, <code>JOB_CHAIN</code>, <code>JOB_CONFIG</code>, <code>JOB_RUN</code>, <code>JOB_RECOVERY</code>, <code>LICENCE</code>.		\| category \|\| Text \|\| Always \|\| Indicates the category of the event. One of: <code>SYSTEM_PARAMETER</code>, <code>QUEUE</code>, <code>JOB</code>, <code>JOB_CHAIN</code>, <code>JOB_CONFIG</code>, <code>JOB_RUN</code>, <code>JOB_RECOVERY</code>, <code>LICENCE</code>.
	\|-		\|-
	\| levelDisplayName \|\| Text \|\| Always \|\| Indicates the level of the event, in a pretty format~~. Available as of 2.3~~. One of: <code>Info</code>, <code>Warning</code>, <code>Error</code>, <code>Fatal</code>.		\| levelDisplayName \|\| Text \|\| Always \|\| Indicates the level of the event, in a pretty format. One of: <code>Info</code>, <code>Warning</code>, <code>Error</code>, <code>Fatal</code>.
	\|-		\|-
	\| categoryDisplayName \|\| Text \|\| Always \|\| Indicates the category of the event, in a pretty format~~. Available as of 2.3~~. One of: <code>System Parameter</code>, <code>Queue</code>, <code>Job</code>, <code>Job Chain</code>, <code>Job Config</code>, <code>Job Run</code>, <code>Job Recovery</code>, <code>Licence</code>.		\| categoryDisplayName \|\| Text \|\| Always \|\| Indicates the category of the event, in a pretty format. One of: <code>System Parameter</code>, <code>Queue</code>, <code>Job</code>, <code>Job Chain</code>, <code>Job Config</code>, <code>Job Run</code>, <code>Job Recovery</code>, <code>Licence</code>.
	\|-		\|-
	\| recipients \|\| Text (multiple) \|\| Always \|\| The email addresses of all recipients of this message.		\| recipients \|\| Text (multiple) \|\| Always \|\| The email addresses of all recipients of this message.

Cron

Craig — Fri, 31 Jul 2026 14:49:49 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 21:		Line 21:
	The most basic cron expressions use simple ordinals or an asterisk for each field. As an example, the pattern <code>30 19 * * 5</code> means 7:30 PM on all Fridays.		The most basic cron expressions use simple ordinals or an asterisk for each field. As an example, the pattern <code>30 19 * * 5</code> means 7:30 PM on all Fridays.

	~~As of Obsidian 3.3.0, multiple~~ Cron patterns may be specified for a single schedule by delimiting them with a semi-colon (e.g. <code>35 8 * * * ;20 12 * ;40 16 * *</code>). This means that the job will fire if it matches any of the supplied patterns.		Multiple Cron patterns may be specified for a single schedule by delimiting them with a semi-colon (e.g. <code>35 8 * * * ;20 12 * ;40 16 * *</code>). This means that the job will fire if it matches any of the supplied patterns.

	As of '''Obsidian 4.2.0''', '''TimeZone ID''' support was added. This allows for a cron pattern to be associated with a specific TimeZone. The job will fire according to the timing of the TimeZone specified regardless of the default TimeZone of the Obsidian cluster. Supported TimeZone IDs can be found by running [https://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html#getAvailableIDs() TimeZone.getAvailableIDs()] in your runtime JVM.		As of '''Obsidian 4.2.0''', '''TimeZone ID''' support was added. This allows for a cron pattern to be associated with a specific TimeZone. The job will fire according to the timing of the TimeZone specified regardless of the default TimeZone of the Obsidian cluster. Supported TimeZone IDs can be found by running [https://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html#getAvailableIDs() TimeZone.getAvailableIDs()] in your runtime JVM.
Line 121:		Line 121:

	= Recurrence =		= Recurrence =
	~~''Available as of 3.2.0''~~

	In addition to Cron syntax, Obsidian supports special recurrence syntax to allow expression of recurring intervals that can't be defined in a single Cron pattern. For example, if you wanted to run a job every 7 minutes, every 2 weeks or every 5 months, none of these can be expressed in a single Cron pattern.		In addition to Cron syntax, Obsidian supports special recurrence syntax to allow expression of recurring intervals that can't be defined in a single Cron pattern. For example, if you wanted to run a job every 7 minutes, every 2 weeks or every 5 months, none of these can be expressed in a single Cron pattern.
Line 145:		Line 144:

	==Recurrence Start DateTime==		==Recurrence Start DateTime==
	~~As of 3.4.0, the~~ recurrence pattern may include an optional start datetime. This datetime would be used as a basis for calculating recurrence (if before the effective date of the schedule window), or as the initial recurrence datetime (if after the effective datetime of the schedule window). Without this value, any recurrence pattern without history for the given schedule window will have its first runtime at the effective datetime of the schedule window. When the schedule effective date is greater than the start datetime specified, the first calculated recurrence value that is greater than or equal to the schedule effective datetime will be the first scheduled runtime. See examples below.		The recurrence pattern may include an optional start datetime. This datetime would be used as a basis for calculating recurrence (if before the effective date of the schedule window), or as the initial recurrence datetime (if after the effective datetime of the schedule window). Without this value, any recurrence pattern without history for the given schedule window will have its first runtime at the effective datetime of the schedule window. When the schedule effective date is greater than the start datetime specified, the first calculated recurrence value that is greater than or equal to the schedule effective datetime will be the first scheduled runtime. See examples below.

	This functionality can be used to ensure a job fires on consistent recurrence intervals when migrating between environments, perhaps using the [[Initializing and Restoring]] functionality.		This functionality can be used to ensure a job fires on consistent recurrence intervals when migrating between environments, perhaps using the [[Initializing and Restoring]] functionality.

Conflicts

Craig — Fri, 31 Jul 2026 14:49:49 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 12:		Line 12:

	== Jobs in Multiple Conflict Groups ==		== Jobs in Multiple Conflict Groups ==
	~~As of Obsidian 2.9.0, a~~ job can be put into multiple conflict groups, each having their own separate priority ordering.		A job can be put into multiple conflict groups, each having their own separate priority ordering.

	When selecting available non-conflicted jobs to run, Obsidian inspects the conflict groups in the order provided when they are saved (from left to right in the user interface), and selects the highest priority available job before moving onto the next conflict group. When priority is significant and varies across different groups, ensure your conflict groups are in the desired order.		When selecting available non-conflicted jobs to run, Obsidian inspects the conflict groups in the order provided when they are saved (from left to right in the user interface), and selects the highest priority available job before moving onto the next conflict group. When priority is significant and varies across different groups, ensure your conflict groups are in the desired order.

Clustering

Craig — Fri, 31 Jul 2026 14:49:48 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 7:		Line 7:
	'''All scheduler nodes, any [[Deployment_Diagram\|deployed]] Web Admin WARs and the database should be time synchronized from the same source and to the same timezone.'''		'''All scheduler nodes, any [[Deployment_Diagram\|deployed]] Web Admin WARs and the database should be time synchronized from the same source and to the same timezone.'''

	~~'''As of Obsidian 3.5.1''', scheduler~~ nodes may have different timezones that adhere to the same time rules (are functionally equivalent). This is implemented via the [[https://docs.oracle.com/javase/6/docs/api/java/util/TimeZone.html#hasSameRules(java.util.TimeZone) TimeZone.hasSameRules(TimeZone)]] method.		Scheduler nodes may have different timezones that adhere to the same time rules (are functionally equivalent). This is implemented via the [[https://docs.oracle.com/javase/6/docs/api/java/util/TimeZone.html#hasSameRules(java.util.TimeZone) TimeZone.hasSameRules(TimeZone)]] method.

	== Load Sharing Algorithm ==		== Load Sharing Algorithm ==
Line 18:		Line 18:

	==Host Preference ==		==Host Preference ==
	In addition to host restrictions, Obsidian ~~3.0 introduces~~ the concept of host preference. For each job, you can select this option to enable prioritizing specific hosts for job execution. When a job configured with this setting is ready for execution, Obsidian will select the most preferred host to execute the job on, and if no preferred host is available, execution will fall back to any available host. This is configurable on the [[Admin_Jobs#Adding_.26_Editing_Jobs\|job configuration screen]].		In addition to host restrictions, Obsidian supports the concept of host preference. For each job, you can select this option to enable prioritizing specific hosts for job execution. When a job configured with this setting is ready for execution, Obsidian will select the most preferred host to execute the job on, and if no preferred host is available, execution will fall back to any available host. This is configurable on the [[Admin_Jobs#Adding_.26_Editing_Jobs\|job configuration screen]].

Chaining

Craig — Fri, 31 Jul 2026 14:49:48 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 1:		Line 1:
	Obsidian supports dynamic job chaining between two jobs. All chaining configuration is managed in the [[Admin Job Chains\|job chains]] portion of the admin web application.		Obsidian supports dynamic job chaining between two jobs. All chaining configuration is managed in the [[Admin Job Chains\|job chains]] portion of the admin web application.

	Chaining can be triggered simply by the state of the queued job, or ~~as of version 1.4,~~ conditionally, based on the saved results of a successfully completed job.		Chaining can be triggered simply by the state of the queued job, or conditionally, based on the saved results of a successfully completed job.

	A job can be chained to any other job. By default, chaining between two jobs will trigger when the source job either completes or fails, but any source termination state can be selected to trigger the chain. Chain configurations can be disabled and re-enabled at any time. Chaining can also be constrained to a schedule, using a standard cron schedule.		A job can be chained to any other job. By default, chaining between two jobs will trigger when the source job either completes or fails, but any source termination state can be selected to trigger the chain. Chain configurations can be disabled and re-enabled at any time. Chaining can also be constrained to a schedule, using a standard cron schedule.

Built-in Jobs

Craig — Fri, 31 Jul 2026 14:49:47 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 1:		Line 1:
	Obsidian comes bundled with free [[Admin_Jobs\|jobs]] for common tasks. These are provided in addition to [[Scripting Jobs]] to reduce implementation and testing time for common job functions.		Obsidian comes bundled with free [[Admin_Jobs\|jobs]] for common tasks. These are provided in addition to [[Scripting Jobs]] to reduce implementation and testing time for common job functions.

	~~As of '''Obsidian 2.7.0''', we~~ have open-sourced our built-in convenience jobs under the [[https://opensource.org/license/mit/ MIT License]]. In the root of the installation folder, you can find the source in <code>obsidian-builtin-job-src.jar</code>.		We have open-sourced our built-in convenience jobs under the [[https://opensource.org/license/mit/ MIT License]]. In the root of the installation folder, you can find the source in <code>obsidian-builtin-job-src.jar</code>.

	= File Processing Jobs =		= File Processing Jobs =
Line 11:		Line 11:
	'''Job Class:''' <code>com.carfey.ops.job.maint.FileCleanupJob</code>		'''Job Class:''' <code>com.carfey.ops.job.maint.FileCleanupJob</code>

	~~''Introduced in version 2.0''~~

	This job deletes files in specified paths based on one or more file masks (using regular expressions).		This job deletes files in specified paths based on one or more file masks (using regular expressions).
Line 46:		Line 45:
	'''Job Class:''' <code>com.carfey.ops.job.maint.FileArchiveJob</code>		'''Job Class:''' <code>com.carfey.ops.job.maint.FileArchiveJob</code>

	~~''Introduced in version 2.0''~~

	This job archives files passed in via a chained job's saved results. Therefore, it is intended to be used as a chained job only. One or more accessible absolute file paths can be passed in via job results called 'file'. Each one will be processed for archiving. For example, if you have a job that generates two files called 'customers.txt' and 'orders.txt', you will use <code>Context.saveJobResult(String, Object)</code> to save a value for each absolute file path (e.g. 'C:/customers.txt' and 'C:/orders.txt').		This job archives files passed in via a chained job's saved results. Therefore, it is intended to be used as a chained job only. One or more accessible absolute file paths can be passed in via job results called 'file'. Each one will be processed for archiving. For example, if you have a job that generates two files called 'customers.txt' and 'orders.txt', you will use <code>Context.saveJobResult(String, Object)</code> to save a value for each absolute file path (e.g. 'C:/customers.txt' and 'C:/orders.txt').
Line 85:		Line 83:
	'''Job Class:''' <code>com.carfey.ops.job.maint.FileScannerJob</code>		'''Job Class:''' <code>com.carfey.ops.job.maint.FileScannerJob</code>

	~~''Introduced in version 2.2''~~

	This job locates files in a directory matching one or more file masks (using Java regular expressions) and stores the result via source job results stored under the name <code>file</code> as absolute paths (Strings).		This job locates files in a directory matching one or more file masks (using Java regular expressions) and stores the result via source job results stored under the name <code>file</code> as absolute paths (Strings).
Line 127:		Line 124:
	This job will delete job history and related records beyond a configurable age in days. This is useful for keeping the database compact and clearing out old, unneeded data.		This job will delete job history and related records beyond a configurable age in days. This is useful for keeping the database compact and clearing out old, unneeded data.

	The value for <code>maxAgeDays</code> corresponds to the maximum age for records to retain. By default it is set to ~~365~~, but you may configure it to any desired value.		The value for <code>maxAgeDays</code> corresponds to the maximum age for records to retain, including expired job schedules. By default it is set to 366, but you may configure it to any desired value.

	~~As of 3.0.1, the value for <code>maxAgeScheduleDays</code> corresponds to the maximum age for expired job schedules to retain. If this isn't specified, expired job schedules won't be deleted.~~

	~~As of 3.4.0, the value for <code>maxAgeDays</code> is used to prune expired job schedules and <code>maxAgeScheduleDays</code> is no longer used~~.

	'''Note:''' We recommend high volume users schedule the job weekly or less frequently and to schedule it for a non-peak time.		'''Note:''' We recommend high volume users schedule the job weekly or less frequently and to schedule it for a non-peak time.
Line 175:		Line 168:
	== Disabled Job Cleanup Job ==		== Disabled Job Cleanup Job ==

	~~''Introduced in Obsidian 3.7.0''~~

	'''Job Class:''' <code>com.carfey.ops.job.maint.DisabledJobCleanupJob</code>		'''Job Class:''' <code>com.carfey.ops.job.maint.DisabledJobCleanupJob</code>
Line 192:		Line 184:
	'''Job Class:''' <code>com.carfey.ops.job.script.ScriptFileJob</code>		'''Job Class:''' <code>com.carfey.ops.job.script.ScriptFileJob</code>

	~~''Introduced in Obsidian 2.3.1''~~

	This job enables you to specify an existing script, command or other executable to invoke/execute. Validation of the file's existence and executable state is done only at runtime. You must ensure that the file exists or is accessible via environment variables and in an executable state on all Obsidian Hosts in the cluster or restrict the job to the necessary [[Admin_Jobs#Advanced_Options\|Fixed Hosts]]. This job uses [http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html ProcessBuilder], so refer to it for expected behaviour.		This job enables you to specify an existing script, command or other executable to invoke/execute. Validation of the file's existence and executable state is done only at runtime. You must ensure that the file exists or is accessible via environment variables and in an executable state on all Obsidian Hosts in the cluster or restrict the job to the necessary [[Admin_Jobs#Advanced_Options\|Fixed Hosts]]. This job uses [http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html ProcessBuilder], so refer to it for expected behaviour.

	~~As of ''Obsidian 3.8.0'', this~~ job supports best-effort interruption as an [[Implementing_Jobs#Interruptable_Jobs\|Interruptable job]]. It is best effort in that it only destroys the underlying process that invoked the script, but cannot ensure that anything the script has invoked has terminated.		This job supports best-effort interruption as an [[Implementing_Jobs#Interruptable_Jobs\|Interruptable job]]. It is best effort in that it only destroys the underlying process that invoked the script, but cannot ensure that anything the script has invoked has terminated.

	* ''Script with Arguments (1 or more Strings)'' - The first value is a path to the execution script (or other executable), which is typically fully qualified, or relative to the working directory. The additional values are any required arguments for the command. On *nix, if you are invoking a script, you may need to prefix the command with "./", e.g. <code>./script.sh</code>. Corresponds to the [http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html#ProcessBuilder(java.lang.String...) ProcessBuilder(java.lang.String...) constructor].		* ''Script with Arguments (1 or more Strings)'' - The first value is a path to the execution script (or other executable), which is typically fully qualified, or relative to the working directory. The additional values are any required arguments for the command. On *nix, if you are invoking a script, you may need to prefix the command with "./", e.g. <code>./script.sh</code>. Corresponds to the [http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html#ProcessBuilder(java.lang.String...) ProcessBuilder(java.lang.String...) constructor].
Line 227:		Line 218:
	= MySqlBackupJob =		= MySqlBackupJob =

	~~''Introduced in version 2.4''~~

	This is a convenience job to utilize the mysqldump utility to extract a backup and store on the filesystem. A timestamp is appended to the filename prefix specified to protect against overwrites. The optional mysqldump options are not validated and will result in runtime failures if they are invalid. Likewise, all paths specified are not verified and are only required to be available on the scheduler host at runtime. If the mysqldump executable is not found at runtime, change the ''mysqldump Executable'' to have the fully qualified path.		This is a convenience job to utilize the mysqldump utility to extract a backup and store on the filesystem. A timestamp is appended to the filename prefix specified to protect against overwrites. The optional mysqldump options are not validated and will result in runtime failures if they are invalid. Likewise, all paths specified are not verified and are only required to be available on the scheduler host at runtime. If the mysqldump executable is not found at runtime, change the ''mysqldump Executable'' to have the fully qualified path.
Line 245:		Line 235:

	= Shell Script Jobs =		= Shell Script Jobs =
	'''Deprecated ~~as of Obsidian 2.3.1~~.''' Use [[#Script_Job\|Script Job]] instead.		'''Deprecated.''' Use [[#Script_Job\|Script Job]] instead.

	These jobs are provided to give convenient access to shell scripting. ''Not supported on Windows-based platforms.''		These jobs are provided to give convenient access to shell scripting. ''Not supported on Windows-based platforms.''
Line 251:		Line 241:
	== Shell Script Job ==		== Shell Script Job ==

	'''Deprecated ~~as of Obsidian 2.3.1~~.''' Use [[#Script_Job\|Script Job]] instead.		'''Deprecated.''' Use [[#Script_Job\|Script Job]] instead.

	'''Job Class:''' <code>com.carfey.ops.job.script.ShellScriptJob</code>		'''Job Class:''' <code>com.carfey.ops.job.script.ShellScriptJob</code>

	~~''Introduced in version 2.0''~~

	This job enables you to specify the actual contents of a shell script and have it execute on the runtime host. At runtime, the script will be written to disk, marked as executable and then executed. The script is then cleaned up. The shell script provided should be completely self-sufficient with any desired interpreter directives included and no assumptions or expectations of environment variables.		This job enables you to specify the actual contents of a shell script and have it execute on the runtime host. At runtime, the script will be written to disk, marked as executable and then executed. The script is then cleaned up. The shell script provided should be completely self-sufficient with any desired interpreter directives included and no assumptions or expectations of environment variables.

	== Shell Script Execution Job ==		== Shell Script Execution Job ==
	'''Deprecated ~~as of Obsidian 2.3.1~~.''' Use [[#Script_Job\|Script Job]] instead.		'''Deprecated.''' Use [[#Script_Job\|Script Job]] instead.

	'''Job Class:''' <code>com.carfey.ops.job.script.ShellScriptExecutionJob</code>		'''Job Class:''' <code>com.carfey.ops.job.script.ShellScriptExecutionJob</code>

	~~''Introduced in version 2.0''~~

	This job enables you to specify an existing shell script to execute. Validation of the script's existence and executable state is done only at runtime. You must ensure that the script exists in an executable state on all Obsidian Hosts in the cluster or restrict the job to the necessary [[Admin_Jobs#Execution_.26_Pickup\|Fixed Hosts]].		This job enables you to specify an existing shell script to execute. Validation of the script's existence and executable state is done only at runtime. You must ensure that the script exists in an executable state on all Obsidian Hosts in the cluster or restrict the job to the necessary [[Admin_Jobs#Execution_.26_Pickup\|Fixed Hosts]].

Authenticator

Craig — Fri, 31 Jul 2026 14:49:47 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 127:		Line 127:
	'''<code>public boolean supportsRememberMe()</code>'''		'''<code>public boolean supportsRememberMe()</code>'''

	~~from~~ <code>com.carfey.suite.security.remember.Authenticator</code> available ~~as of~~ Obsidian 3.5.0.		From <code>com.carfey.suite.security.remember.Authenticator</code>, available from Obsidian 3.5.0 and '''removed in Obsidian 7.0.0'''.

	This method~~, from~~ <code>com.carfey.suite.security.remember.Authenticator</code>~~, indicates whether the Authenticator supports~~ Obsidian~~'s remember me feature available in the Web Admin login~~. ~~This~~ is ~~primarily used to ensure~~ the remember me feature is not exposed in environments where the user could be disabled, made inactive or otherwise invalidated while allowing a lookup to succeed - as may be the case in directory authentication implementations such as LDAP.		This method indicated whether the Authenticator supported Obsidian's remember me feature in the Web Admin login. The Remember Me feature and the <code>com.carfey.suite.security.remember.Authenticator</code> interface were removed in Obsidian 7.0.0, so this method is no longer part of the authenticator contract.

	=== Users ===		=== Users ===

Advanced Configuration

Craig — Fri, 31 Jul 2026 14:49:46 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

Show changes

Admin Web Application Guide

Craig — Fri, 31 Jul 2026 14:49:45 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 1:		Line 1:
	'''Important: This guide is for Obsidian 4.0 and newer ~~versions. See the [[Admin_Web_Application_Guide_(3.x.x_and_earlier)\|old guide]] for prior~~ versions.		'''Important: This guide is for Obsidian 4.0 and newer versions.

	Obsidian's administration web application lets you manage scheduler settings, monitor job execution, create and update jobs, and manage various notification settings.		Obsidian's administration web application lets you manage scheduler settings, monitor job execution, create and update jobs, and manage various notification settings.

Admin User Management

Craig — Fri, 31 Jul 2026 14:49:45 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 49:		Line 49:
	== User Rights ==		== User Rights ==

	Rights are broken out into these categories: ''Default'' (read), ''Write'', ''Admin'', ''API Access'', ''Author'' and ''Operator''. In addition~~, as starting with Obsidian 2.0~~, ''Default'' read access can be limited using the ''Limited Read Access'' setting.		Rights are broken out into these categories: ''Default'' (read), ''Write'', ''Admin'', ''API Access'', ''Author'' and ''Operator''. In addition, ''Default'' read access can be limited using the ''Limited Read Access'' setting.

	* ''Default'' rights allow you read access to most parts of the application, with the exception of user lists and the [[Admin Scheduler Settings\|Scheduler Settings]] screen.		* ''Default'' rights allow you read access to most parts of the application, with the exception of user lists and the [[Admin Scheduler Settings\|Scheduler Settings]] screen.

Admin Jobs

Craig — Fri, 31 Jul 2026 14:49:44 GMT

Remove pre-4.x version references (4.0.0 is the oldest documented release)

← Older revision		Revision as of 14:49, 31 July 2026
Line 85:		Line 85:
	''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.

	''Auto Retries - #'' allows you to indicate the number of times you wish Obsidian to automatically resubmit (retry) the job for execution when triggered by a non-interrupted execution failure~~. As of Obsidian 2.0~~.		''Auto Retries - #'' allows you to indicate the number of times you wish Obsidian to automatically resubmit (retry) the job for execution when triggered by a non-interrupted execution failure.

	''Auto Retries - Interval'' allows you to indicate the minimum interval in minutes from the point in time the job failed and the job will be retried~~. As of Obsidian 2.5.0~~.		''Auto Retries - Interval'' allows you to indicate the minimum interval in minutes from the point in time the job failed and the job will be retried.

	''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.

	''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 Subscribers\|subscribers]] 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 Subscribers\|subscribers]] at the Warning level or above.

	''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.

	''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. If a host is not listed and will be started later, simply type in the name and click the (+) button to add it to the list. ~~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_Scheduler_Settings\|Scheduler Settings]]/Job/adHocJobsRespectFixedHostsRestrictions'''. As of version 4.4, you may use a Java regular expression to use pattern matching on the host name. For example, a wildcard match for hosts that start with "abc" can be done with a pattern like "abc.". To implement a blacklist of hosts that the job should not run on, a single pattern with negation can be used: "(?!(blacklist-one\|blacklist-two)).".		''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. If a host is not listed and will be started later, simply type in the name and click the (+) button to add it to the list. A configuration item allows you to specify whether you wish host restrictions to apply on AdHoc jobs or not. It defaults to TRUE on new installations. This can be found under '''[[Admin_Scheduler_Settings\|Scheduler Settings]]/Job/adHocJobsRespectFixedHostsRestrictions'''. As of version 4.4, you may use a Java regular expression to use pattern matching on the host name. For example, a wildcard match for hosts that start with "abc" can be done with a pattern like "abc.". To implement a blacklist of hosts that the job should not run on, a single pattern with negation can be used: "(?!(blacklist-one\|blacklist-two)).".

	''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 158:		Line 158:

	'''Note:''' In order to save your schedule changes, you'll need to save the job itself. If you click the ''Revert'' button after making schedule changes, they will be discarded and will not be included if you then click Save.		'''Note:''' In order to save your schedule changes, you'll need to save the job itself. If you click the ''Revert'' button after making schedule changes, they will be discarded and will not be included if you then click Save.

Advanced Configuration

Craig — Fri, 31 Jul 2026 02:18:21 GMT

Dependent Libraries

← Older revision		Revision as of 02:18, 31 July 2026
(4 intermediate revisions by the same user not shown)
Line 636:		Line 636:

	'''Web Admin - As of Obsidian 7.0.0:'''		'''Web Admin - As of Obsidian 7.0.0:'''
	~~Wiki~~ rendering ships as 12 modular JARs:		Markdown rendering for job and parameter descriptions ships as 12 modular JARs:
	flexmark-0.62.2.jar, flexmark-util-ast-0.62.2.jar, flexmark-util-builder-0.62.2.jar, flexmark-util-collection-0.62.2.jar, flexmark-util-data-0.62.2.jar, flexmark-util-dependency-0.62.2.jar, flexmark-util-format-0.62.2.jar, flexmark-util-html-0.62.2.jar, flexmark-util-misc-0.62.2.jar, flexmark-util-options-0.62.2.jar, flexmark-util-sequence-0.62.2.jar, flexmark-util-visitor-0.62.2.jar		flexmark-0.62.2.jar, flexmark-util-ast-0.62.2.jar, flexmark-util-builder-0.62.2.jar, flexmark-util-collection-0.62.2.jar, flexmark-util-data-0.62.2.jar, flexmark-util-dependency-0.62.2.jar, flexmark-util-format-0.62.2.jar, flexmark-util-html-0.62.2.jar, flexmark-util-misc-0.62.2.jar, flexmark-util-options-0.62.2.jar, flexmark-util-sequence-0.62.2.jar, flexmark-util-visitor-0.62.2.jar

Line 642:		Line 642:
	* '''log4j upgraded''': log4j-api and log4j-core updated from 2.17.1 to 2.26.0.		* '''log4j upgraded''': log4j-api and log4j-core updated from 2.17.1 to 2.26.0.
	* '''Modular Groovy libraries''': Obsidian no longer ships '''apache-groovy-all-4.0.24.jar'''. Groovy scripting now uses 13 modular JARs (see ''Scripts'' above). When Groovy is disabled at install time, all 13 modules are excluded.		* '''Modular Groovy libraries''': Obsidian no longer ships '''apache-groovy-all-4.0.24.jar'''. Groovy scripting now uses 13 modular JARs (see ''Scripts'' above). When Groovy is disabled at install time, all 13 modules are excluded.
	* '''Modular Flexmark libraries''': Obsidian no longer ships '''flexmark-util-0.62.2.jar'''. ~~Wiki~~ rendering now uses 12 modular Flexmark JARs (see ''~~Scripts~~'' above).		* '''Modular Flexmark libraries''': Obsidian no longer ships '''flexmark-util-0.62.2.jar'''. Markdown rendering for job and parameter descriptions now uses 12 modular Flexmark JARs (see ''Web Admin'' above).
	* '''OAuth / OIDC authentication libraries''' added (Nimbus OAuth 2.0 SDK and transitive dependencies). Required only when OAuthAuthenticator is configured. See [[Advanced_Configuration#OAuth_/_OIDC_Authentication_Properties\|Authentication (OAuth/OIDC)]] above.		* '''OAuth / OIDC authentication libraries''' added (Nimbus OAuth 2.0 SDK and transitive dependencies). Required only when OAuthAuthenticator is configured. See [[Advanced_Configuration#OAuth_/_OIDC_Authentication_Properties\|Authentication (OAuth/OIDC)]] above.
	* '''SAML 2.0 authentication libraries''' added (OpenSAML 4 and its transitive dependencies, plus the SLF4J-to-log4j2 binding). Required only when SAMLAuthenticator is configured. See [[Advanced_Configuration#SAML_Authentication_Properties\|Authentication (SAML 2.0)]] above.		* '''SAML 2.0 authentication libraries''' added (OpenSAML 4 and its transitive dependencies, plus the SLF4J-to-log4j2 binding). Required only when SAMLAuthenticator is configured. See [[Advanced_Configuration#SAML_Authentication_Properties\|Authentication (SAML 2.0)]] above.

← Older revision		Revision as of 14:49, 31 July 2026
Line 63:		Line 63:
	Out of the box, Obsidian will display any previously scheduled jobs and Obsidian's bundled jobs. You can type in your class name as described in [[Admin_Jobs#Nickname.2C_Class_and_Folder\|Admin Jobs]].		Out of the box, Obsidian will display any previously scheduled jobs and Obsidian's bundled jobs. You can type in your class name as described in [[Admin_Jobs#Nickname.2C_Class_and_Folder\|Admin Jobs]].

	~~As of '''Obsidian 2.2.1''', you~~ can take advantage of our [[Spring_Integration\|Spring Integration]]. Jobs that have been wired into your <code>ApplicationContext</code> will be available in the list.		You can take advantage of our [[Spring_Integration\|Spring Integration]]. Jobs that have been wired into your <code>ApplicationContext</code> will be available in the list.

	You can also use Obsidian's [[Implementing_Jobs#Classpath_Scanning\|classpath scanning]] as of '''Obsidian 2.0'''. Note that for this feature to work, the user account running Obsidian must have read privileges to the <code>WEB-INF</code> directory of Obsidian's deployment directory.		You can also use Obsidian's [[Implementing_Jobs#Classpath_Scanning\|classpath scanning]] as of '''Obsidian 2.0'''. Note that for this feature to work, the user account running Obsidian must have read privileges to the <code>WEB-INF</code> directory of Obsidian's deployment directory.

← Older revision		Revision as of 02:26, 2 August 2026
(3 intermediate revisions by the same user not shown)
Line 32:		Line 32:
	==== Deployment options ====		==== Deployment options ====

	Obsidian 7~~.0.0~~ offers four deployment profiles in the installer:		Obsidian 7 offers four deployment profiles in the installer:

	* '''Obsidian WAR''' — deploy '''obsidian.war''' to your own servlet container (Tomcat, WebLogic, etc.).		* '''Obsidian WAR''' — deploy '''obsidian.war''' to your own servlet container (Tomcat, WebLogic, etc.).
Line 110:		Line 110:
	* '''Scopes''' — ''openid profile email''.		* '''Scopes''' — ''openid profile email''.
	Note: the ''groups'' claim contains GUIDs by default; configure Optional Claims in the Azure portal to receive group display names.		Note: the ''groups'' claim contains GUIDs by default; configure Optional Claims in the Azure portal to receive group display names.
	'''Multi-tenant applications are not supported in Obsidian 7.0.0.'''		'''Multi-tenant applications are not supported in Obsidian 7.0.x.'''

	[[Image:Obsidian-7.0.0-Configuring-Okta.png]]		[[Image:Obsidian-7.0.0-Configuring-Okta.png]]
Line 133:		Line 133:
	* '''Client ID''' and '''Client Secret''' from the provider.		* '''Client ID''' and '''Client Secret''' from the provider.
	* '''Scopes''' — at minimum ''openid''; add ''profile'' and your groups scope as needed.		* '''Scopes''' — at minimum ''openid''; add ''profile'' and your groups scope as needed.


	===== Group → Role Mapping =====		===== Group → Role Mapping =====
Line 253:		Line 252:
	==== Offline or restricted-network install ====		==== Offline or restricted-network install ====

	Obsidian 7.0.0 resolves third-party libraries when you run the installer. For environments without direct access to Maven Central:		Obsidian 7.x.x resolves third-party libraries when you run the installer. For environments without direct access to Maven Central:

	# Pre-stage a local dependency cache containing every coordinate listed in the Obsidian dependency inventory for your release (contact Carfey support or your account team for the checklist file matching '''Obsidian-Install-7.0.0.jar''').		# Pre-stage a local dependency cache containing every coordinate listed in the Obsidian dependency inventory for your release (contact Carfey support or your account team for the checklist file matching '''Obsidian-Install-7.x.x.jar''').
	# Copy the cache to the install host. Two layouts are supported:		# Copy the cache to the install host. Two layouts are supported:
	#* '''Flat:''' one file per installed JAR name directly under the cache root.		#* '''Flat:''' one file per installed JAR name directly under the cache root.
Line 261:		Line 260:
	# Run the installer with offline mode and the cache directory:		# Run the installer with offline mode and the cache directory:

	java -Dobsidian.install.deps.offline=true -Dobsidian.install.deps.cache.dir=/path/to/cache -jar Obsidian-Install-7.0.0.jar		java -Dobsidian.install.deps.offline=true -Dobsidian.install.deps.cache.dir=/path/to/cache -jar Obsidian-Install-7.x.x.jar

	If a required library is missing from the cache, the install stops with an error naming the coordinate — add that artifact to the cache and re-run.		If a required library is missing from the cache, the install stops with an error naming the coordinate — add that artifact to the cache and re-run.
Line 269:		Line 268:
	When your site mirrors Maven Central, point the installer at your repository base URL:		When your site mirrors Maven Central, point the installer at your repository base URL:

	java -Dobsidian.install.deps.repo.url=https://nexus.example.com/repository/maven-public/ -jar Obsidian-Install-7.0.0.jar		java -Dobsidian.install.deps.repo.url=https://nexus.example.com/repository/maven-public/ -jar Obsidian-Install-7.x.x.jar

	The installer reuses resolved artifacts for the duration of one install session.		The installer reuses resolved artifacts for the duration of one install session.


	== Completing the Installation ==		== Completing the Installation ==

← Older revision		Revision as of 14:49, 31 July 2026
Line 44:		Line 44:
	Jobs can be restricted to run only on specified hosts. This allows you to use Obsidian in a multi-host environment, even when certain jobs can only run on one of the hosts in the cluster.		Jobs can be restricted to run only on specified hosts. This allows you to use Obsidian in a multi-host environment, even when certain jobs can only run on one of the hosts in the cluster.

	~~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~~. It can by found under '''[[Admin Scheduler Settings\|Scheduler Settings]] / Job / adHocJobsRespectFixedHostsRestrictions'''.		A configuration item allows you to specify whether you wish host restrictions to apply on AdHoc jobs or not. It defaults to TRUE on new installations. It can by found under '''[[Admin Scheduler Settings\|Scheduler Settings]] / Job / adHocJobsRespectFixedHostsRestrictions'''.

	=Host Preference =		=Host Preference =

	In addition to strict host selections, Obsidian ~~3.0 introduces~~ the concept of host preference. For each job, you can select this option to enable prioritizing specific hosts for job execution. When a job configured with this setting is ready for execution, Obsidian will select the most preferred host to execute the job on, and if no preferred host is available, execution will fall back to any available host. This is configurable on the [[Admin_Jobs#Adding_.26_Editing_Jobs\|job configuration screen]].		In addition to strict host selections, Obsidian supports the concept of host preference. For each job, you can select this option to enable prioritizing specific hosts for job execution. When a job configured with this setting is ready for execution, Obsidian will select the most preferred host to execute the job on, and if no preferred host is available, execution will fall back to any available host. This is configurable on the [[Admin_Jobs#Adding_.26_Editing_Jobs\|job configuration screen]].

	=Recovery=		=Recovery=
Line 62:		Line 62:
	* ''None'' indicates that no job runs will be recovered.		* ''None'' indicates that no job runs will be recovered.

	~~As of Obsidian 2.0,~~ Obsidian also supports individual job failure recovery through automated retries.		Obsidian also supports individual job failure recovery through automated retries.
	Each job can be configured to use ''Auto Retries''. Specify a ''Count'' that will tell Obsidian how many times to keep trying (essentially an auto-resubmit) a failed job.		Each job can be configured to use ''Auto Retries''. Specify a ''Count'' that will tell Obsidian how many times to keep trying (essentially an auto-resubmit) a failed job.

	~~As of Obsidian 2.5.0, you~~ can use ''Interval'' and ''Exponential'' as well. Use ''Interval'' to indicate the minimum number of minutes from the last failure to the next retry.		You can use ''Interval'' and ''Exponential'' as well. Use ''Interval'' to indicate the minimum number of minutes from the last failure to the next retry.
	Use ''Exponential'' if you want 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.		Use ''Exponential'' if you want 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.

Line 73:		Line 73:
	In addition, when you submit an ad hoc job run, you can supply job parameters which apply only to that execution. This can be useful for executing jobs for a particular one-time need. For example, if you run out of disk space on a host, you may have a log archival job which can be run against a specific directory for a single execution.		In addition, when you submit an ad hoc job run, you can supply job parameters which apply only to that execution. This can be useful for executing jobs for a particular one-time need. For example, if you run out of disk space on a host, you may have a log archival job which can be run against a specific directory for a single execution.

	~~As of ''Obsidian 3.8.0'', multiple~~ Ad Hoc Runs may be submitted per minute for both immediate (next minute) execution and future execution.		Multiple Ad Hoc Runs may be submitted per minute for both immediate (next minute) execution and future execution.

	= Forced Termination (interruptable jobs) =		= Forced Termination (interruptable jobs) =
Line 79:		Line 79:

	=Expected Length Handling (job execution duration) =		=Expected Length Handling (job execution duration) =
	~~As of Obsidian 1.5.~~

	Jobs can have an expected runtime length set, which causes a Warning level event to be triggered if a job falls outside of the expected range. This is used primarily for notifications. Users can be alerted in the event of a long-running (or unexpectedly short) job by configuring the appropriate [[Admin Notifications\|Notifications]].		Jobs can have an expected runtime length set, which causes a Warning level event to be triggered if a job falls outside of the expected range. This is used primarily for notifications. Users can be alerted in the event of a long-running (or unexpectedly short) job by configuring the appropriate [[Admin Notifications\|Notifications]].

	~~As of Obsidian 3.4.0,~~ [[Implementing_Jobs#Interruptable_Jobs\|Interruptable Jobs]] also support auto interruption when execution length exceeds maximum expected run length.		[[Implementing_Jobs#Interruptable_Jobs\|Interruptable Jobs]] also support auto interruption when execution length exceeds maximum expected run length.

	= Custom Calendars =		= Custom Calendars =