This quick post is about how to troubleshoot cronjob issues, specifically when a cronjob does not start.
Many of you still use HMC. Yes, it was removed from SAP Commerce Cloud, but there are still hundreds of installations where HMC is in use.
I found an interesting issue today. The issue is related to cronjobs and HMC.
What I observed today was a cronjob not starting when its schedule said it should. It was enabled, but the system didn’t execute it on time.
HMC showed that the settings were correct. What was wrong? The first thing I checked was whether the cronjob had a node group or node ID configured. If these settings are not correct, the cronjob won’t be executed at all. They were set properly.
The next step was making a snapshot of all relevant data. For cronjobs, it is CronJob and all its subtypes, and Trigger.
For exporting all data objects, I used the script from my article about exporting data. The script generates the type tree; you can pick the relevant types from the tree, and then generate ImpEx export scripts for the types with all attributes.
I compared data extracted from the broken instance with the same set from the working instance and found that a Trigger object was not populated correctly.
How is it possible? I know for sure that nobody would change these settings on purpose. Zeros mean “a first day,” while “-1” means “every day.”
The reason is a bug in HMC.
The screenshot below is from the out-of-the-box SAP Commerce Cloud configuration:
Interval Range select boxes are populated incorrectly because there is no such value as “-1” in the list of available items. If someone tries to save this object, the zeros will be saved, and the trigger will be reconfigured silently. And, of course, it will stop working as expected.
In other words, the UI says there is a zero value for days, seconds, hours, days, months, and years, but in the database each of the listed items has “-1.”
Checking data before pushing the “Save” button:
select {CronJob.code}, {day}, {hour}, {month}, {second}, {weekInterval}
from {Trigger}, {CronJob}
where {Trigger.cronjob} = {CronJob.pk}
and {CronJob.code} = 'update-index-cronJob'
Then we push the “Save” button:
Checking data after saving the trigger:
select {CronJob.code}, {day}, {hour}, {month}, {second}, {weekInterval}
from {Trigger}, {CronJob}
where {Trigger.cronjob} = {CronJob.pk}
and {CronJob.code} = 'update-index-cronJob'
There is no such issue in Backoffice because select boxes were replaced with input fields:
To fix the issue, you need to apply the following ImpEx code (the example is for the “every 5 minutes” case):
INSERT_UPDATE Trigger;cronjob(code)[unique=true];day;hour;month;second;year;weekInterval
;update-index-cronJob;-1;-1;-1;-1;-1;;But This Issue Wasn’t the Only One
The reason was that the update task was marked as failed because of a series of unsuccessful attempts, and the TriggerTask was marked as failed.
In Commerce Cloud, there are two similarly named objects: Trigger and TriggerTask. For each Trigger item, there must be a corresponding TriggerTask item. The TriggerTask items are created together with Trigger items (see CronJobManager.afterItemCreation). Sometimes, these objects become out of sync, and there are triggers without TriggerTasks. In previous versions, the OOTB code removes the TriggerTask in some situations, and the cronjob stops working. But that wasn’t my case.
In my case, the TriggerTask item was marked as failed, which was the reason why the corresponding Trigger was blocked and was not fired by the system on time.
The TriggerTask item is not reachable from HMC/Backoffice from the Trigger panel.
Conclusion
If you experience a similar issue, remember that there is a TriggerTask object corresponding to Trigger, and check its configuration as well.