Sling Jobs | AEM Community Blog Seeding

[kautuk_sahni]

Sling Jobs by AEM Learning

Abstract

Sling Jobs
One of the most underused and powerful feature of sling is Sling Jobs. We use OSGI events for handling of events but in general event mechanism has no knowledge about the content of events. Therefore, it can't decide if an event is important and should be processed by someone. As the event mechanism is a "fire event and forget about it" algorithm, there is no way for an event admin to tell if someone has really processed the event. Processing of an event could fail, the server or bundle could be stopped etc.

On the other hand, there are use cases where the guarantee of processing is a must and usually this comes with the requirement of processing exactly once. Typical examples are sending notification emails (or sms), post processing of content (like thumbnail generation of images or documents), workflow steps etc.

Sling Event takes care of the above use cases. Sling Event has a concept of Job. A Job is also an event that is guaranteed to be executed at least once with the exception being the instance processing the job crashed after the job processing is finished but before the state is persisted. This results in job consumer processing the job twice.



Job Fundamentals:
1) A job has two parts - topic which describes the nature of the job and payload, the data in the form of key-value pairs.

2) A job consumer is a service consuming and processing a job. It registers itself as an OSGi service together with a property defining which topics this consumer can process.

3) A job executor is a service processing a job. It registers itself as an OSGi service together with a property defining which topics this consumer can process.

Now lets start by creating a event handler for publishing a content

Read Full Blog

Sling Jobs

Q&A

Please use this thread to ask the related questions.