You can use web admin
and the public API
to specify a service be invoked once or at certain intervals. Jobs type supported
are one-time, interval-based and cron-style.

Among other things, the cluster’s singleton server
runs a background thread whose sole purpose is to publish messages on
Redis when a service should be invoked. The message
is picked up by one of servers and Zato invokes the service specified.

It’s worth emphasizing that publishing a message that a service should be run
and actually running it can be performed by two different servers, the process
is asynchronous.

Because Zato won’t wait for a previous execution of a service to
complete before the next one can be started, multiple instances of a service
triggered by a scheduler’s job are able to run in parallel.

From the perspective of a service, being triggered by a job is like any other
access method. Programmatically, if you need to check if a service was
invoked through a job, you can consult its
channel
and
job_type
attributes.
Note that are service hooks specific to scheduler jobs available.

When creating a new job definition, you can specify extra data. In run-time,
this will accessible to a service in its request.payload
attribute.