Configure schedules
You can schedule tasks and events using:
By convention, IDM uses file names of the form schedule-schedule-name.json
, where schedule-name is a logical name for the scheduled operation; for example, schedule-reconcile_systemCsvAccounts_managedUser.json
. There are several example schedule configuration files in the openidm/samples/example-configurations/schedules
directory.
Each schedule configuration has the following format:
{
"enabled" : boolean,
"persisted" : boolean,
"recoverable" : boolean,
"concurrentExecution" : boolean,
"type" : "simple | cron",
"repeatInterval" : (optional) integer,
"repeatCount" : (optional) integer,
"startTime" : "(optional) time",
"endTime" : "(optional) time",
"schedule" : "cron expression",
"misfirePolicy" : "optional, string",
"invokeService" : "service identifier",
"invokeContext" : "service specific context info",
"invokeLogLevel" : "(optional) level"
}
Schedule configuration properties
The schedule configuration properties are defined as follows:
enabled
-
Set to
true
to enable the schedule. When this property isfalse
, IDM considers the schedule configuration dormant, and does not allow it to be triggered or launched.If you want to retain a schedule configuration, but do not want it used, set
enabled
tofalse
for task and event schedulers, instead of changing the configuration orcron
expressions. persisted
(optional)-
Specifies whether the schedule state should be persisted or stored only in RAM. Boolean (
true
orfalse
),false
by default.In a clustered environment, this property must be set to
true
to have the schedule fire only once across the cluster. For more information, see Configure Persistent Schedules.If the schedule is stored only in RAM, the schedule will be lost when IDM is restarted. recoverable
(optional)-
Specifies whether jobs that have failed mid-execution (as a result of a JVM crash or otherwise unexpected termination) should be recovered. Boolean (
true
orfalse
),false
by default. concurrentExecution
-
Specifies whether multiple instances of the same schedule can run concurrently. Boolean (
true
orfalse
),false
by default. Multiple instances of the same schedule cannot run concurrently by default. This setting prevents a new scheduled task from being launched before the same previously launched task has completed. For example, under normal circumstances you would want a liveSync operation to complete before the same operation was launched again. To enable multiple schedules to run concurrently, set this parameter totrue
. The behavior of missed scheduled tasks is governed by the misfire policy. type
-
The trigger type, either
simple
orcron
.To decide which trigger type to use, see the Quartz documentation on SimpleTriggers and CronTriggers.
repeatCount
-
Used only for simple triggers (
"type" : "simple"
).The number of times the schedule must be repeated. The repeat count can be zero, a positive integer, or -1. A value of -1 indicates that the schedule should repeat indefinitely.
If you do not specify a repeat count, the value defaults to -1.
repeatInterval
-
Used only for simple triggers (
"type" : "simple"
).Specifies the interval, in milliseconds, between trigger firings. The repeat interval must be zero or a positive long value. If you set the repeat interval to zero, the scheduler will trigger
repeatCount
firings concurrently (or as close to concurrently as possible).If you do not specify a repeat interval, the value defaults to 0.
startTime
(optional)-
This parameter starts the schedule at some time in the future. If the parameter is omitted, empty, or set to a time in the past, the task or event is scheduled to start immediately.
Use ISO 8601 format to specify times and dates (
yyyy-MM-dd’T’HH:mm:ss
).To specify a time zone, include the time zone at the end of the
startTime
, in the format+|-hh:mm
; for example2017-10-31T15:53:00+05:00
. If you specify both astartTime
and anendTime
, they must have the same time zone. endTime
(optional)-
Specifies when the schedule must end, in ISO 8601 format (
yyyy-MM-dd’T’HH:mm:ss+|-hh:mm
. schedule
-
Used only for cron triggers (
"type" : "cron"
).Takes
cron
expression syntax. For more information, see the CronTrigger Tutorial and Lesson 6: CronTrigger.
misfirePolicy
-
For persistent schedules, this optional parameter specifies the behavior if the scheduled task is missed, for some reason. Possible values are as follows:
-
fireAndProceed
. The first run of a missed schedule is immediately launched when the server is back online. Subsequent runs are discarded. After this, the normal schedule is resumed. -
doNothing
. All missed schedules are discarded and the normal schedule is resumed when the server is back online.
-
invokeService
-
Defines the type of scheduled event or action. The value of this parameter can be one of the following:
-
sync
for reconciliation. -
provisioner
for liveSync. -
script
to call some other scheduled operation defined in a script. -
taskScanner
to define a scheduled task that queries a set of objects. For more information, see Scan data to trigger tasks.
-
invokeContext
-
Specifies contextual information, depending on the type of scheduled event (the value of the
invokeService
parameter).The following example invokes reconciliation:
{ "invokeService": "sync", "invokeContext": { "action": "reconcile", "mapping": "systemLdapAccount_managedUser" } }
The following example invokes a liveSync operation:
{ "invokeService": "provisioner", "invokeContext": { "action": "liveSync", "source": "system/ldap/__ACCOUNT__" } }
For scheduled liveSync tasks, the
source
property follows IDM’s convention for a pointer to an external resource object and takes the formsystem/resource-name/object-type
.The following example invokes a script, which prints the node ID performing the scheduled job and the time to the console.
A similar sample schedule is provided in
schedule-script.json
in the/path/to/openidm/samples/example-configurations/schedules
directory.{ "enabled" : true, "type": "simple", "repeatInterval": 3600000, "persisted" : true, "concurrentExecution" : false, "invokeService": "script", "invokeContext": { "script" : { "type" : "text/javascript", "source" : "java.lang.System.out.println('Job executing on ' + identityServer.getProperty('openidm.node.id') + ' at: ' + java.lang.System.currentTimeMillis());" } } }
These are sample configurations only. Your schedule configuration will differ according to your specific requirements.
invokeLogLevel
(optional)-
Specifies the level at which the invocation will be logged. Particularly for schedules that run very frequently, such as liveSync, the scheduled task can generate significant output to the log file, and you should adjust the log level accordingly. The default schedule log level is
info
. The value can be set to any one of the SLF4J log levels:-
trace
-
debug
-
info
-
warn
-
error
-
fatal
-
Manage schedules using REST
The scheduler service is exposed under the /openidm/scheduler
context path. Within this context path, the defined scheduled jobs are accessible at /openidm/scheduler/job
. A job is the actual task that is run. Each job contains a trigger that starts the job. The trigger defines the schedule according to which the job is executed. You can read and query the existing triggers on the /openidm/scheduler/trigger
context path.
The following examples show how schedules are validated, created, read, queried, updated, and deleted, over REST, by using the scheduler service.
When you configure schedules over REST, changes made to the schedules are not pushed back into the configuration service. Managing schedules by using the If you need to perform an operation on a schedule that was created by using the configuration service (by placing a schedule file in the PATCH operations are not supported on the |
Validate cron trigger expressions
Schedules are defined using Quartz cron or simple triggers. If you use a cron trigger, you can validate your cron expression by sending the expression as a JSON object to the scheduler
context path:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Content-Type: application/json" \ --header "Accept-API-Version: resource=2.0" \ --request POST \ --data '{ "cronExpression": "0 0/1 * * * ?" }' \ "http://localhost:8080/openidm/scheduler/job?_action=validateQuartzCronExpression" { "valid": true }
Define a schedule
To define a new schedule, send a PUT or POST request to the scheduler/job
context path with the details of the schedule in the JSON payload. A PUT request lets you specify the ID of the schedule. A POST request assigns an ID automatically.
The following example uses a PUT request to create a schedule that fires a script (script/testlog.js
) every second. The example assumes that the script exists in the specified location. The schedule configuration is as described in Configure Schedules:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Content-Type: application/json" \ --header "Accept-API-Version: resource=2.0" \ --request PUT \ --data '{ "enabled": true, "type": "cron", "schedule": "0/1 * * * * ?", "persisted": true, "misfirePolicy": "fireAndProceed", "invokeService": "script", "invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } } }' \ "http://localhost:8080/openidm/scheduler/job/testlog-schedule" { "_id": "testlog-schedule", "enabled": true, "persisted": true, "recoverable": false, "misfirePolicy": "fireAndProceed", "schedule": "0/1 * * * * ?", "repeatInterval": 0, "repeatCount": 0, "type": "cron", "invokeService": "org.forgerock.openidm.script", "invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } }, "invokeLogLevel": "info", "startTime": null, "endTime": null, "concurrentExecution": false, "triggers": [ { "calendar": null, "group": "scheduler-service-group", "jobKey": "scheduler-service-group.testlog-schedule", "name": "trigger-testlog-schedule", "nodeId": "node1", "previousState": null, "serialized": { "type": "CronTriggerImpl", "calendarName": null, "cronEx": { "cronExpression": "0/1 * * * * ?", "timeZone": "Africa/Johannesburg" }, "description": null, "endTime": null, "fireInstanceId": "node1_1570611359345", "group": "scheduler-service-group", "jobDataMap": { "scheduler.invokeService": "org.forgerock.openidm.script", "scheduler.config-name": "scheduler-testlog-schedule", "scheduler.invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } }, "schedule.config": { "enabled": true, "persisted": true, "recoverable": false, "misfirePolicy": "fireAndProceed", "schedule": "0/1 * * * * ?", "repeatInterval": 0, "repeatCount": 0, "type": "cron", "invokeService": "org.forgerock.openidm.script", "invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } }, "invokeLogLevel": "info", "startTime": null, "endTime": null, "concurrentExecution": false }, "scheduler.invokeLogLevel": "info" }, "jobGroup": "scheduler-service-group", "jobName": "testlog-schedule", "misfireInstruction": 1, "name": "trigger-testlog-schedule", "nextFireTime": 1570611569000, "previousFireTime": 1570611568000, "priority": 5, "startTime": 1570611391000, "volatility": false }, "state": "NORMAL", "_rev": "000000001d4724d6", "_id": "scheduler-service-group.trigger-testlog-schedule" } ], "previousRunDate": "2019-10-09T08:59:28.000Z", "nextRunDate": "2019-10-09T08:59:29.000Z" }
The previous output includes the |
The following example uses a POST request to create an identical schedule to the one created in the previous example, but with a server-assigned ID:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Content-Type: application/json" \ --header "Accept-API-Version: resource=2.0" \ --request POST \ --data '{ "enabled": true, "type": "cron", "schedule": "0/1 * * * * ?", "persisted": true, "misfirePolicy": "fireAndProceed", "invokeService": "script", "invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } } }' \ "http://localhost:8080/openidm/scheduler/job?_action=create" { "_id": "b12e4a77-a626-4a38-a1dc-8edc7498ca1c", "enabled": true, "persisted": true, "recoverable": false, "misfirePolicy": "fireAndProceed", "schedule": "0/1 * * * * ?", "repeatInterval": 0, "repeatCount": 0, "type": "cron", "invokeService": "org.forgerock.openidm.script", "invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } }, "invokeLogLevel": "info", "startTime": null, "endTime": null, "concurrentExecution": false, "triggers": [ { "calendar": null, "group": "scheduler-service-group", "jobKey": "scheduler-service-group.b12e4a77-a626-4a38-a1dc-8edc7498ca1c", "name": "trigger-b12e4a77-a626-4a38-a1dc-8edc7498ca1c", "nodeId": null, "previousState": null, "serialized": { "type": "CronTriggerImpl", "calendarName": null, "cronEx": { "cronExpression": "0/1 * * * * ?", "timeZone": "Africa/Johannesburg" }, "description": null, "endTime": null, "fireInstanceId": null, "group": "scheduler-service-group", "jobDataMap": { "scheduler.invokeService": "org.forgerock.openidm.script", "scheduler.config-name": "scheduler-b12e4a77-a626-4a38-a1dc-8edc7498ca1c", "scheduler.invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } }, "schedule.config": { "enabled": true, "persisted": true, "recoverable": false, "misfirePolicy": "fireAndProceed", "schedule": "0/1 * * * * ?", "repeatInterval": 0, "repeatCount": 0, "type": "cron", "invokeService": "org.forgerock.openidm.script", "invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } }, "invokeLogLevel": "info", "startTime": null, "endTime": null, "concurrentExecution": false }, "scheduler.invokeLogLevel": "info" }, "jobGroup": "scheduler-service-group", "jobName": "b12e4a77-a626-4a38-a1dc-8edc7498ca1c", "misfireInstruction": 1, "name": "trigger-b12e4a77-a626-4a38-a1dc-8edc7498ca1c", "nextFireTime": 1570611659000, "previousFireTime": null, "priority": 5, "startTime": 1570611659000, "volatility": false }, "state": "NORMAL", "_rev": "000000009e2e2212", "_id": "scheduler-service-group.trigger-b12e4a77-a626-4a38-a1dc-8edc7498ca1c" } ], "previousRunDate": null, "nextRunDate": "2019-10-09T09:00:59.000Z" }
The output includes the generated _id
of the schedule, in this case:
"_id": "b12e4a77-a626-4a38-a1dc-8edc7498ca1c"
View scheduled job details
The following example displays the details of the schedule created in the previous example. Specify the job ID in the URL:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request GET \ "http://localhost:8080/openidm/scheduler/job/testlog-schedule" { "_id": "testlog-schedule", "enabled": true, "persisted": true, "recoverable": false, "misfirePolicy": "fireAndProceed", "schedule": "0/1 * * * * ?", "repeatInterval": 0, "repeatCount": 0, "type": "cron", "invokeService": "org.forgerock.openidm.script", "invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } }, "invokeLogLevel": "info", "startTime": null, "endTime": null, "concurrentExecution": false, "triggers": [ { "calendar": null, "group": "scheduler-service-group", "jobKey": "scheduler-service-group.testlog-schedule", "name": "trigger-testlog-schedule", "nodeId": null, "previousState": null, "serialized": { "type": "CronTriggerImpl", "calendarName": null, "cronEx": { "cronExpression": "0/1 * * * * ?", "timeZone": "Africa/Johannesburg" }, "description": null, "endTime": null, "fireInstanceId": "node1_1570611359712", "group": "scheduler-service-group", "jobDataMap": { "scheduler.invokeService": "org.forgerock.openidm.script", "scheduler.config-name": "scheduler-testlog-schedule", "scheduler.invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } }, "schedule.config": { "enabled": true, "persisted": true, "recoverable": false, "misfirePolicy": "fireAndProceed", "schedule": "0/1 * * * * ?", "repeatInterval": 0, "repeatCount": 0, "type": "cron", "invokeService": "org.forgerock.openidm.script", "invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } }, "invokeLogLevel": "info", "startTime": null, "endTime": null, "concurrentExecution": false }, "scheduler.invokeLogLevel": "info" }, "jobGroup": "scheduler-service-group", "jobName": "testlog-schedule", "misfireInstruction": 1, "name": "trigger-testlog-schedule", "nextFireTime": 1570611719000, "previousFireTime": 1570611718000, "priority": 5, "startTime": 1570611391000, "volatility": false }, "state": "NORMAL", "_rev": "000000002d1c2465", "_id": "scheduler-service-group.trigger-testlog-schedule" } ], "previousRunDate": "2019-10-09T09:01:58.000Z", "nextRunDate": "2019-10-09T09:01:59.000Z" }
Query scheduled jobs
You can query defined and running scheduled jobs using a regular query filter.
The following query returns the IDs of all defined schedules:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request GET \ "http://localhost:8080/openidm/scheduler/job?_queryFilter=true&_fields=_id" { "result": [ { "_id": "reconcile_systemLdapAccounts_managedUser" }, { "_id": "testlog-schedule" } ] ... }
The following query returns the IDs, enabled status, and next run date of all defined schedules:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request GET \ "http://localhost:8080/openidm/scheduler/job?_queryFilter=true&_fields=_id,enabled,nextRunDate" { "result": [ { "_id": "reconcile_systemLdapAccounts_managedUser", "enabled": false, "nextRunDate": null }, { "_id": "testlog-schedule", "enabled": true, "nextRunDate": "2019-10-09T09:43:17.000Z" } ] ... }
Update a schedule
To update a schedule definition, use a PUT request and update all the static properties of the object.
This example disables the testlog
schedule created in the previous example by setting "enabled":false
:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Content-Type: application/json" \ --header "Accept-API-Version: resource=2.0" \ --request PUT \ --data '{ "enabled": false, "type": "cron", "schedule": "0/1 * * * * ?", "persisted": true, "misfirePolicy": "fireAndProceed", "invokeService": "script", "invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } } }' \ "http://localhost:8080/openidm/scheduler/job/testlog-schedule" { "_id": "testlog-schedule", "enabled": false, "persisted": true, "recoverable": false, "misfirePolicy": "fireAndProceed", "schedule": "0/1 * * * * ?", "repeatInterval": 0, "repeatCount": 0, "type": "cron", "invokeService": "org.forgerock.openidm.script", "invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } }, "invokeLogLevel": "info", "startTime": null, "endTime": null, "concurrentExecution": false, "triggers": [], "previousRunDate": null, "nextRunDate": null }
When you disable a schedule, all triggers are removed, and the nextRunDate
is set to null
. If you re-enable the schedule, a new trigger is generated, and the nextRunDate
is recalculated.
List running scheduled jobs
This example returns a list of the jobs that are currently executing. The list lets you decide whether to wait for a specific job to complete before shutting down a server.
|
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request POST \ "http://localhost:8080/openidm/scheduler/job?_action=listCurrentlyExecutingJobs" [ { "enabled": true, "persisted": true, "misfirePolicy": "fireAndProceed", "type": "simple", "repeatInterval": 3600000, "repeatCount": -1, "invokeService": "org.forgerock.openidm.sync", "invokeContext": { "action": "reconcile", "mapping": "systemLdapAccounts_managedUser" }, "invokeLogLevel": "info", "timeZone": null, "startTime": null, "endTime": null, "concurrentExecution": false } ]
Trigger a schedule manually
For testing purposes, and for certain administrative tasks, you can trigger a scheduled task manually, outside of its specified schedule. A scheduled task must be enabled
before it can be triggered.
This command triggers the testlog-schedule
job created previously:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request POST \ "http://localhost:8080/openidm/scheduler/job/testlog-schedule?_action=trigger" { "success": true }
This action is available only from version 2.0 of the scheduler API onwards. |
Pause and resume a scheduled job
Instead of deleting and recreating scheduled jobs, you can pause and resume them if necessary. This command pauses the testlog-schedule
job:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request POST \ "http://localhost:8080/openidm/scheduler/job/testlog-schedule?_action=pause" { "success": true }
This command resumes the testlog-schedule
job:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request POST \ "http://localhost:8080/openidm/scheduler/job/testlog-schedule?_action=resume" { "success": true }
These actions are available only from version 2.0 of the scheduler API onwards. |
Pause all scheduled jobs
You can temporarily suspend all scheduled jobs. This action does not cancel or interrupt jobs that are already in progress; it simply prevents any scheduled jobs from being invoked during the suspension period.
This command suspends all scheduled tasks and returns true
if the tasks could be suspended successfully:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request POST \ "http://localhost:8080/openidm/scheduler/job?_action=pauseJobs" { "success": true }
Resume all scheduled jobs
You can resume scheduled jobs to start them up again. Any jobs that were missed during the downtime follow their configured misfirePolicy
.
This command resumes all scheduled jobs and returns true
if the jobs could be resumed successfully:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request POST \ "http://localhost:8080/openidm/scheduler/job?_action=resumeJobs" { "success": true }
Query schedule triggers
When a scheduled job is created, a trigger for that job is created automatically and is included in the schedule definition. The trigger is essentially what causes the job to be started. You can read all the triggers that have been generated on a system with the following query on the openidm/scheduler/trigger
context path:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request GET \ "http://localhost:8080/openidm/scheduler/trigger?_queryFilter=true" { "result": [ { "_id": "scheduler-service-group.trigger-testlog-schedule", "_rev": "00000000db3523f1", "calendar": null, "group": "scheduler-service-group", "jobKey": "scheduler-service-group.testlog-schedule", "name": "trigger-testlog-schedule", "nodeId": "node1", "previousState": null, "serialized": { ... }, "state": "NORMAL" } ] }
The trigger object contents are:
_id
-
The ID of the trigger, which is based on the schedule ID. The trigger ID is made up of the group name, followed by
trigger-
prepended to the schedule ID:group.trigger-schedule-id
. For example, if the schedule ID wastestlog-schedule
, then the trigger ID would bescheduler-service-group.trigger-testlog-schedule
. _rev
-
The revision of the trigger object. This property is reserved for internal use and specifies the revision of the object in the repository. This is the same value that is exposed as the object’s ETag through the REST API. The content of this property is not defined. No consumer should make any assumptions of its content beyond equivalence comparison.
previousState
-
The previous state of the trigger, before its current state. For a description of Quartz trigger states, see the Quartz API documentation.
name
-
The trigger name, which matches the ID of the schedule that created the trigger, with
trigger-
added:trigger-schedule-id
. state
-
The current state of the trigger. For a description of Quartz trigger states, see the Quartz API documentation.
nodeId
-
The ID of the node that has acquired the trigger, useful in a clustered deployment. If the trigger has not been acquired by a node yet, this will return
null
. calendar
-
This is a part of the Quartz implementation, but is not currently supported by IDM. This will always return
null
. serialized
-
The JSON serialization of the trigger class.
group
-
The name of the group that the trigger is in, always
scheduler-service-group
. jobKey
-
The name of the job associated with the trigger:
group.schedule-id
.
To read the contents of a specific trigger, send a GET request to the trigger ID; for example:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request GET \ "http://localhost:8080/openidm/scheduler/trigger/scheduler-service-group.trigger-testlog-schedule" { "_id": "scheduler-service-group.trigger-testlog-schedule", "_rev": "00000000cd1723dd", "calendar": null, "group": "scheduler-service-group", "jobKey": "scheduler-service-group.testlog-schedule", "name": "trigger-testlog-schedule", "nodeId": "node1", "previousState": null, "serialized": { ... }, "state": "NORMAL" }
To view the triggers that have been acquired, send a GET request to the scheduler, with a _queryFilter
of nodeId
. For example:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request GET \ "http://localhost:8080/openidm/scheduler/trigger?_queryFilter=(nodeId+pr)"
To view the triggers that have not yet been acquired by any node, send a GET request to the scheduler, with a _queryFilter
to list the triggers with a null nodeId
. For example:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request GET \ "http://localhost:8080/openidm/scheduler/trigger?_queryFilter=%21(nodeId+pr)"
Delete a schedule
To delete a schedule, send a DELETE request to the schedule ID. For example:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=2.0" \ --request DELETE \ "http://localhost:8080/openidm/scheduler/job/testlog-schedule" { "_id": "testlog-schedule", "enabled": false, "persisted": true, "recoverable": false, "misfirePolicy": "fireAndProceed", "schedule": "0/1 * * * * ?", "repeatInterval": 0, "repeatCount": 0, "type": "cron", "invokeService": "org.forgerock.openidm.script", "invokeContext": { "script": { "type": "text/javascript", "file": "script/testlog.js" } }, "invokeLogLevel": "info", "startTime": null, "endTime": null, "concurrentExecution": false, "triggers": [], "previousRunDate": null, "nextRunDate": null }
The DELETE request returns the entire JSON object.