Repository Scheduler


The Bloomreach Experience Manager repository exposes a scheduling service that can be used to schedule jobs within the repository. To schedule a job you can either programatically leverage the RepositoryScheduler API interface, or configure the job manually in the repository.

Leverage the RepositoryScheduler API

The API of the repository scheduler service is located in the repository api module. You also need the Hippo services dependency:


To obtain an instance of the repository scheduler service, get it from the hippo service registry:

final RepositoryScheduler scheduler =

To schedule a job using the scheduler you need to provide a job description in the form of a RepositoryJobInfo object and a specification of when to run the job in the form of a RepositoryJobTrigger:

final RepositoryJobInfo myJobInfo = new RepositoryJobInfo("my",
testJobInfo.addAttribute("foo", "bar");
final RepositoryJobTrigger myJobTrigger =
                            new RepositoryJobSimpleTrigger("my", new Date());

scheduler.scheduleJob(myJobInfo, myJobTrigger);

The job to be scheduled ( TestRepositoryJob in the example above) must have a public no-argument constructor and must be an instance of interface org.onehippo.repository.scheduling.RepositoryJob which has one method:

 * Job execution callback.
 * @param context operational context object.
 * @throws RepositoryException when an error occurs.
public void execute(RepositoryJobExecutionContext context)
                                               throws RepositoryException;

From the passed-in context you can obtain a session by calling:

context.createSession(new SimpleCredentials("myuser", "mypass".toCharArray());

Or a system session by calling:


These sessions must be logged out after you are done using them.

Attributes that were passed in to the RepositoryJobInfo with which this RepositoryJob was scheduled are also available from the context:

assert context.getAttribute("foo").equals("bar");

Available Triggers

There are two different implementations of RepositoryJobTrigger at your disposal: RepositoryJobSimpleTrigger and RepositoryJobCronTrigger.

If you want to schedule a job to execute once at a give date and time, you should use the former of these two:

final RepositoryJobTrigger myJobTrigger =
                     new RepositoryJobSimpleTrigger("my", new Date());

This trigger can also be constructed with the optional repeatCount and repeatInterval arguments. The job will then be scheduled to execute a total of repeatCount times starting at the given startDate. The repeatInterval argument specifies the number of milliseconds between job executions.

The second trigger at you disposal triggers the execution of jobs based on a cron expression:

final RepositoryJobTrigger myJobTrigger =
                   new RepositoryJobCronTrigger("my","0 15 10 ? * 6L");

If you use the scheduler from a DaemonModule make sure your module is loaded after the module that registers the scheduler by leveraging the @RequiresService annotation described there.

Configure Jobs Manually

Instead of registering a job programatically with the RepositoryScheduler service, you can add it directly to the repository. Repository jobs are persisted at /hippo:configuration/hippo:modules/scheduler/hippo:moduleconfig/. Below a job group of your own choosing add a job node with an appropriate trigger: 

    jcr:primaryType: hipposched:repositoryjob
    hipposched:attributeNames: [key]
    hipposched:attributeValues: [value]
    hipposched:repositoryJobClass: org.example.ExampleRepositoryJob
      jcr:primaryType: hipposched:triggers
        jcr:primaryType: hipposched:crontrigger
        hipposched:cronExpression: 0 0/5 * * * ?

Notice how you can parameterize the RepositoryJob using the two properties hipposched:attributeNames and hipposched:attributeValues. The key/value pairs are available as described above from the RepositoryJobExecutionContext. This configuration schedules a job using a trigger that fires every 5 minutes. You can add as many triggers as you need.

Disable Jobs and Triggers

Job and trigger nodes have a property called hipposched:enabled that can be used to disable the job or trigger in question. If the property is not specified, it is interpreted as that the job or trigger is enabled.

Disable the Scheduler on Specific Nodes in a Clustered Environment

In a clustered environment, by default all repository nodes perform scheduled tasks. In some use cases, such as delivery-only nodes, this is not recommended, because nodes could interfere with scheduled (de)publications from CMS nodes. 

The scheduler can be disabled by adding the following directive to the startup script of the application container:

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?