Defining a Job
A Job represents both the object to be serialized to a Connection to eventually work as well as the code to execute when working a Job.
Extending from AbstractJob
The first step to define a Job is to extend from AbstractJob
. This provides the necessary helper methods to run a Job through the cbq pipeline.
Properties
Defining properties on your job allow you to see at a glance what data your Job expects when constructing it. These properties and their values will be serialized to a Connection when dispatching a Job.
Defining the properties is not strictly necessary, but your future self will thank you when you try to remember what properties your job is using.
The handle method
The handle
method is called when a Job is worked. Before being called, a Job will be reconstructed with the serialized data from the Connection. This method is the only required method when defining a Job.
Prefer using provider:
injections or inline getInstance
calls for logic in your handle
method. The Job
component is created both when dispatching and when working your job, so utilizing these tools will reduce unnecessary processing time when dispatching your job.
Job Execution Properties
A job can define several execution properties on the job itself. If defined, these values override the module, connection, or worker defaults. It can still be overridden using the job methods when creating a job.
Last updated