Task Engine - Key concepts and use cases

• Lightweight scheduling framework
• Tasks may run in any node of a cluster
• A Task runs in only one node
•  Works on the service layer
• Tasks may be triggered by events
• Tasks may have a  context or custom attributes
• Each task is performed inside a transaction
• A task is removed from the database when it completes or expires. It may also be removed if an exception occurs Give an example of this situation
• A task will be mark as failed and never executes again if:
  • The server shutdowns when the task is running. The thread is killed and finally blocks aren't executed
  • The task throws an exception
  • The task ask to retry the execution in the future but it expires before running successfully
• Through the Groovy console new Tasks can be created without restarting the server

I can't see any strong benefit of using tasks instead of cronjobs:

• They run only once and most of the eShops where I have worked on have actions which run periodically
• The usefulness of tasks with scripts is limited because even if a cronjob doesn't have a trigger you can always start it. Secondly most of the actions are so complex that you need to split the code in many classes, write unit tests and test them carefully before running them in production. To have only a long script for a task will be error prone
• The events which trigger actions in a eShop usually come from a web service which received a status update in an order, product, stock or price. In this case, the action to be triggered must already be lightweight and short

A cronjob reads a file with product information. For each product, it creates a task which imports the data in the eShop and updates the Solr index. This method allows to import products in parallel and doesn't block the original cronjob.

• The task must be saved by the scheduler. If your code save it, the scheduler believes that it was already run.

–Based on SAP Hybris 6.4