Service-Oriented API Task Scheduling
Want to customize your jobs? Here's how to do it with Zato.
Join the DZone community and get the full member experience.Join For Free
An integral part of Zato, its scalable, service-oriented scheduler makes it is possible to execute high-level API integration processes as background tasks. The scheduler runs periodic jobs, which, in turn, trigger services, and services are what are used to integrate systems.
In this article, we will check how to use the scheduler with three kinds of jobs, one-time, interval-based, and Cron-style ones.
What we want to achieve is a sample yet fairly common use-case:
- Periodically consult a remote REST endpoint for new data
- Store data found in Redis
- Push data found as an e-mail attachment
Instead of, or in addition to, Redis or e-mail, we could use SQL and SMS, or MongoDB and AMQP or anything else — Redis and e-mail are just example technologies frequently used in data synchronization processes that we use to highlight the workings of the scheduler.
No matter the input and output channels, the scheduler works always the same — a definition of a job is created and the job's underlying service is invoked according to the schedule. It is then up to the service to perform all the actions required in a given integration process.
Our integration service will read as below:
Now, we just need to make it run periodically in the background.
Mind the Time Zone
In the next steps, we will use web-admin to configure new jobs for the scheduler.
Keep in mind that any date and time that you enter in web-admin is always interpreted to be in your web-admin user's time zone and this applies to the scheduler too - by default the time zone is UTC. You can change it by clicking Settings and picking the right time zone to make sure that the scheduled jobs run as expected.
It does not matter what time zone your Zato servers are in — they may be in different ones than the user that is configuring the jobs.
First, let's use web-admin to define the endpoints that the service uses. Note that Redis does not need an explicit declaration because it is always available under "self.kvdb" in each service.
- Configuring outgoing REST APIs
- Configuring SMTP e-mail
Now, we can move on to the actual scheduler jobs.
Three Types of Jobs
To cover different integration needs, three types of jobs are available:
- One-time: fires once only at a specific date and time and then never runs again
- Interval-based: for periodic processes, can use any combination of weeks, days, hours, minutes, and seconds for the interval
- Cron-style: similar to interval-based but uses the syntax of Cron for its configuration
Select one-time if the job should not be repeated after it runs once.
Select interval-based if the job should be repeated periodically. Note that such a job will by default run indefinitely but you can also specify after how many times it should stop, letting you express concepts such as "Execute once per hour but for the next seven days".
Select cron-style if you are already familiar with the syntax of Cron or if you have some Cron tasks that you would like to migrate to Zato.
Running jobs manually
At times, it is convenient to run a job on demand, no matter what its schedule is and regardless of what type a particular job is. Web-admin lets you always execute a job directly. Simply find the job in the listing, click "Execute" and it will run immediately.
It is very often useful to provide additional context data to a service that the scheduler runs - to achieve it, simply enter any arbitrary value in the "Extra" field when creating or editing a job in web-admin.
Afterward, that information will be available as self.request.raw_request in the service's handle method.
There is nothing else required - all is done and the service will run in accordance with a job's schedule.
Yet, before concluding, observe that our integration service is completely reusable - there is nothing scheduler-specific in it despite the fact that we currently run it from the scheduler.
We could now invoke the service from the command line. Or we could mount it on a REST, AMQP, WebSocket, or trigger it from any other channel — exactly the same Python code will run in exactly the same fashion, without any new programming effort needed.O
Opinions expressed by DZone contributors are their own.