Implementing CronJobs with Custom Logic

So far, you've discovered how to run and manage CronJobs, provided out-of-the-box. What if you want to run a CronJob with your business logic? 

The next interaction offers you the theory and the steps needed to code, register, and run a new CronJob.

Now that you know how to implement a CronJob from scratch, let’s take a look at additional properties and facts about CronJobs:

1. E-mail Notification

   After executing a CronJob, you can notify a user using a predefined e-mail template. This template is a velocity template, and you can customize it according to your needs.

   
2. User

   When you execute a CronJob, it operates within the context of an assigned user. Even if the user isn't actively logged in, this association restricts CronJob's access. Essentially, a CronJob's access is as extensive as the user's permissions assigned to it.

   For example, if you assign the Administrator role to a CronJob, which is the default, it can access virtually everything. However, assigning it to a specific user limits its access.

   
3. Node Group

   You can assign a CronJob to a specific group of server nodes, which allows it to run exclusively on those specific nodes. This way, you ensure the CronJob only runs on the server nodes you selected. You can make this adjustment in the Backoffice as shown in the screenshot:

   
   Note

   You can also set the nodeID (The "Process on server node" field as shown in above screenshot), but consider these points:

   It's not recommended to set the nodeID value, as it can be modified in a managed cloud environment, such as SAP Commerce Cloud.

   If both nodeGroup and nodeID values are specified for a CronJob, the nodeID value will take precedence over the nodeGroup setting.

   Alternatively, you can configure it based on the corresponding API. For example:

   Code Snippet

   Copy code

   Copy code

   Switch to dark mode

   Switch to dark mode

   1234567
   
   
   CronJobModel myCronJob = … // get the CronJob instance
   
   myCronJob.setNodeGroup("backoffice");
   modelService.save(MyCronJob);
   

   As a result, only the servers set with this configuration property will execute the mentioned CronJob:

   Code Snippet

   Copy code

   Copy code

   Switch to dark mode

   Switch to dark mode

   1
   cluster.node.groups = backoffice

4. Scripting

   You can implement CronJobs with scripting languages such as Groovy, Beanshell, or JavaScript, enabling dynamic execution at runtime without needing a server restart.

   While the specific details are beyond the scope of this learning journey, you can find a basic example in this blog post: A Step by Step Guide to Implementing CronJobs in SAP Commerce Cloud Using Scripting. For a deeper understanding of scripting support in SAP Commerce Cloud, we recommend our Expert Deep Dive live session: Identifying Scripting Support in SAP Commerce Cloud.

   Furthermore, a special property that involves Scripting in ImpEx may exist in certain CronJobs. But it's not associated with the previously mentioned Scripting Support. Instead, it relates to the corresponding ImpEx that comprises scripted code, such as the ImpEx Import CronJob illustrated below:

   

   You can modify the 'Enable code execution' property to allow or prevent the execution of scripted code in ImpEx. Additional details on implementing scripted code in ImpEx can be found in the previously recommended Expert Deep Dive live session: Identifying Scripting Support in SAP Commerce Cloud.