Over a million developers have joined DZone.

Triggering API Services With Zato Scheduler: Part I

This article introduces the Zato scheduler, a feature of Zato that lets one configure API services and background jobs to be run at selected intervals.

Build APIs from SQL and NoSQL or Salesforce data sources in seconds. Read the Creating REST APIs white paper, brought to you in partnership with CA Technologies.

Overview

This article introduces the Zato scheduler, a feature of Zato that lets one configure API services and background jobs to be run at selected intervals and according to specified execution plans without any programming needed.

Future articles will introduce all the details whereas this one gently describes major features such as overall architecture, one-time jobs, interval-based jobs, cron-style jobs, and public API to manage jobs from custom tools.

Architecture

In Zato, scheduler jobs are one of the channels that a service can be invoked from. That is, the same service can be mounted on a REST, SOAP, AMQP, ZeroMQ, or any other channel in addition to being triggered from the scheduler. No changes in code are required to achieve it.

Zato channels

For instance, let's consider the code below of a hypothetical service that downloads billings from an FTP resource and sends them off to a REST endpoint:

from zato.server.service import Service

class BillingHandler(Service):
    def handle(self):

        # Download data ..
        ftp = self.outgoing.ftp.get('Billings')
        contents = ftp.getcontents('/data/current.csv')

        # .. and send it to its recipient.
        self.outgoing.plain_http['ERP'].post(self.cid, contents)

Nowhere in the service is any reference embedded as to how it will be invoked and this is the crucial part of Zato design. Services only focus on doing their jobs not on how to make themselves available from one channel or another. Thus, even if a service to bulk transfer billings initially will likely be invoked from the scheduler only, there is nothing preventing it from being triggered by a REST call or from command line as needed.

Or, perhaps a message sent to an AMQP should trigger it. That is fine as well, and the service will not need to be changed to accommodate it.

Working With Scheduler Jobs

There are three types of scheduler jobs:

  1. One-time jobs: Great if a service should be invoked at a specific time, but it does not need to be repeated further.
  2. Interval-based jobs: Let one specify how often to invoke a given service (i.e., once in four weeks, twice an hour, five times a minute), as well as when to stop it so as to form complex plans such as "after two weeks from now, invoke this service twice an hour but do it twelve times only."
  3. Cron-style jobs: Work similar to interval-based ones but use syntax of Cron so 00 3-6 * * 1-5 will mean "run the service every hour on the hour from 3 a.m. to 6 a.m., but only Monday to Friday (i.e., excluding weekends)."

Note that job definitions always survive cluster restarts. This means that if you fully shut down a whole cluster of Zato servers then all jobs will continue to execute once the server is back. However, any jobs missed during the downtime will not be re-scheduled.

When a job is being triggered, its target service can receive extra data that may be possibly needed for that service to perform its tasks. This data is completely opaque to Zato and can be in any format, JSON, XML, YAML, plain text, anything.

If a job should not be scheduled anymore (be it because it was a one-time job or because it reached its execution limit) it becomes inactive rather than being deleted.

Such an inactive job still is available in web-admin and can be made active again, possibly with a different schedule plan. On the other hand, actually deleting a job deletes it permanently.

One-time jobInterval-based jobCron-style jobPart of main scheduler GUI

Full public API is available to manage jobs either through REST or SOAP calls, as well as from other services directly in Python, such as below:

from zato.common import SCHEDULER

class JobManager(Service):

    def handle(self):

        # Create a sample job that will trigger one of built-in test services

        self.invoke('zato.scheduler.job.create', {
            'cluster_id': self.server.cluster_id,
            'is_active': True,
            'name': 'My Sample',
            'service': 'zato.helpers.input-logger',
            'job_type': SCHEDULER.JOB_TYPE.INTERVAL_BASED,
            'seconds': 2,
        })

Stay Tuned for More

This was just the first installment that introduced core concepts behind the Zato scheduler. Coming up are details of how to work with each kind of the jobs, their APIs, and how to efficiently manage their definitions in source code repositories.

The Integration Zone is brought to you in partnership with CA Technologies.  Use CA Live API Creator to quickly create complete application backends, with secure APIs and robust application logic, in an easy to use interface.

Topics:
integration ,api services ,zato scheduler

Published at DZone with permission of Dariusz Suchojad. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}