The scheduler endpoint enables developers to configure services that execute at a given schedule or fixed interval.
|Name||(required)||The name of the endpoint.|
|Service||(required)||The service to execute when the endpoint is triggered.|
||The user to run the service in behalf of. This is logged to Tracker.|
|Document Type||<Name of endpoint type>||The document type to be used when adding documents to Tracker as this endpoint is triggered.|
||Whether or not to automatically start the endpoint upon package startup.|
|Log To Tracker||
||Flag determining whether executions should be logged to Tracker.|
||If this endpoint is configured on a Martini instance that's running in a cluster, replicated will determine whether to run the endpoint on all instances, or only the elected leader node in the cluster. When this is checked, all instances will run the endpoint. When it's unchecked, only the leader node will run the endpoint.|
||The frequency of execution. May be in the form of a cron expression, or a simple fixed interval.|
||When checked, the
There are two ways to configure schedules:
- Simple repeating, which accepts a non-negative number that denotes the interval, in seconds, at which the service will be executed.
- Cron, like the Unix
cronutility, this type allows a more fine-grained schedule configuration. The UI supports easy management of such expressions:
The above example becomes equivalent to the cron expression:
* * 3 ? * 1,2,3,4,5, which stands for
at every minute past hour 3 on every day-of-week from Monday through Friday.
You can import the cron expression or set an expression using the buttons located at the upper right of the seconds table.
When the endpoint is triggered, the following variables are exposed to the configured service:
||The Tracker document internal ID. If the endpoint was configured to not track, this value will be
||The Tracker object. If the endpoint was configured to not track, this value will be
||The Martini package that contains the endpoint.|
||A map containing all the endpoint specific parameters.|
||A map containing containing all the properties associated with the endpoint.|
Gloop as service
Consider this application using Gloop that sends an email to various recipients on schedule:
(1) Takes the credentials of the email sender from the package properties.
(5) Iterates the
to variable, containing a list of recipient emails.
(6) Constructs the email body using Velocity as templating language.
(7) Sends the email to each recipient.
Want more examples?
The distribution ships with a Martini package called
contains services (including the above example) demonstrating more use cases.
Groovy script as service
Consider this Groovy script that simply prints the available variables in the context:
1 2 3 4 5 6 7 8 9 10 11 12 13
When the endpoint is triggered - in this case, the schedule is met - - the console will show logs similar to the following:
1 2 3 4 5 6 7 8 9
Groovy function as service
We can also use a function of a Groovy class as a service for the endpoint. The following is an example that replicates
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30