Jobs API:

Many applications require tasks that can be executed without user involvement. These tasks all follow the same pattern of repeated executions over time or based on some state that is already recorded with the task. Any worker can pick up the task and execute it to completion or failure and finalize the task. This is the nature of these tasks.

Therefore a service that can schedule these jobs or enable their execution would be helpful because jobs can now be submitted over the http. This service has an endpoint as:

jobs.paas.corp.xyz.com

The service is primarily a scheduler but not a message broker. The latter is also similar in purpose for the execution of jobs by putting them in a message queue however each queue has its own producer and consumer. Here we are talking about a service that has a single queue and manages hybrid tasks in it. It also put these jobs in the queue again and again as the task needs to be executed repeatedly. The count of times a task is repeatedly executed or the interval after which they are executed depends on the scheduler.

Jobs are handled in one of two ways. They are either successfully executed or they are marked as failed When the jobs are marked as failed, any helpful error message or exception may also be captured with the task. The states of the task move forward progressively from initialized, started, processing, completed or failed and closed. The granularity of the states and the progression depend exclusively on the schedule for the kind of tasks processed. The data structures for storing the state of the job, the results and the associated action description depend on the tasks. The scheduler follows the command design pattern to invoke the jobs. Each job is granular and flat with no hierarchy even though the associated tasks may be heterogeneous.

Jobs metadata can keep track of logic to execute in the form of location of scripts or assemblies. These are stored in a database along with the job description. The parameters are passed to the logic at the time of scheduler invocation. To make it easier for the scheduler to identify the entry point of the function and the call parameters, some decorators may be allowed to be used with the logic defined. All associated files or auxiliary data may be packaged as a tar ball if necessary.

As with most services that have REST based API endpoints, a command line plug-in or a language library with constructs that make it easier to call the REST API may also come in handy. It should be noted however that the service is helpful only within a narrow domain and not as a general purpose library such as the likes of Celery package. The idea is that this service will fill the gap of a global scheduler for the APIs so that they can be lightened from the tasks that can be executed in the background and make the APIs more responsive. Most applications and portals manage their own cron jobs but APIs have generally relied on a message broker. This service brings both the functionality exclusively for the API developers as an internal automation. It does not need to interact with users directly.

Micro service models are thin and streamlined to avoid any dependencies on other applications and this remains true for the users of those micro services. Inside a micro service, a database, a message broker or other APIs may generally be called to complete the overall goal of the micro service. Since the scheduler is another API to be called by a micro service, there is no conflict with the notion of a micro service.

It can be argued that this scheduler service may be replaced by a data structure in a shared database for use by all services.  A Jobs table for example could allow logic to be local to the micro-service while allowing consistency and accounting of the jobs in a shared repository. Whether the jobs remain in a table or in a message broker queue, it will require servicing that can all be consolidated at one point. This is where a service API comes helpful because other services may frequently ignore or miss the uniform bookkeeping that is required for the servicing of these jobs. In conclusion, the purpose of such a scheduling service is determined by the existing use cases already in practice.

#codingexercise

find the count of digits that are odd in sequential numbers upto n
int GetCount(int n)
{
int count = 0;
for (int i = 0; i <=n; i++)
{
var digits = i.ToDigits();
count += digits.Count(t => t%2 == 1);
}
return count;
}