Table of Contents

Background Job Execution Framework

Many services implemented with an application usually have a very short runtime and returning an almost instantaneous response.
But there are also cases where the processing will take significantly more time and thus needs to be dispatched to a rather long running background job. Further more there are use cases where the specific processing is not intended to be initiated by any direct user interaction or API invocation at all, but is controlled by general housekeeping rules or operational schedules. Data exchange, import/export or synchronization tasks for example are executed in a more automated fashion taking place in the background.

The Tlabs.JobCntrl library offers a framework to execute, schedule and monitor potentially long running background jobs that is based on the following basic concepts:

Job

A Job represents the work task to be performed asynchronously in background. A Job needs a custom definition in terms of the program code to be executed to perform the job. A job is required to implement the IJob interface and could be optionally derived from the abstract class BaseJob for convenience.
In general a Job could be parameterized with an arbitrary set of properties combined from a per Job configuration and from per activation specified values.
When finished a Job returns a JobResult object to give details regarding the outcome of the processing.

Since a Job is forming a transient service being created for each activation, it has full access to all services defined for an application by simply referencing services it dependents on in its constructor.

Starter

Starter(s) are responsible to control the activation (or start) of Job(s). For this a Starter is typically monitoring some external state in order to determine whether it needs to effectively activate a Job’s execution. Like Jobs Starters can be programmatically defined. Examples of library included Starters are:

  • Time Scheduler
    A Starter that activates Job(s) according to a (optional periodic) time schedule.

  • File Watcher
    A Starter to watch for the creation or modification of files in defined folders in order to activate Jobs to process these files.

  • Continuation
    A Starter that serves as a chain link for Jobs to be processed in a sequence. (It detects the completion of a preceding Job and activates the next Job to continue with.)

  • Manual
    Starts the Job activation in response to a “manual” start-method invocation.

  • Message
    Starter that is subscribing to a certain message type and activates job(s) on message reception.

Each Starter has 0 to n associated Job(s) which are all getting concurrently activated once the condition monitored by the Starter is met. Once all activated Jobs have completed (regardless if successful or not) the Starter provides a joint completion result.

Control

A central job-control service is managing the (re-)loading and overall control activation of the jobs' runtime configuration. This allows for pausing the Starters' Job activation, reconfiguration and resumption of operation during runtime.
The job-control also provides options to track the history and outcome of the entire job execution.

By application of the flexible framework infrastructure of the Tlabs.JobCntrl library one can dispatch jobs to background work loads while keeping full control of the planed, currently executed or completed task of the application. The Job execution plan could be specified with any combination of

  • a file based configuration

  • details kept in persistent storage like a database

  • changes created during runtime on user demand

Further Reading