Describe a scheduled job once -- get the AbstractJobPerformable class, its Spring bean, an optional custom CronJob type, and the ImpEx to schedule it.
🔒 Your code never leaves your browser — everything is generated locally from templates, no AI, no server round-trip.
trainingcore/src/com/prospect2p/core/cronjob/MyJobJob.javapackage com.prospect2p.core.cronjob;
import de.hybris.platform.cronjob.enums.CronJobResult;
import de.hybris.platform.cronjob.enums.CronJobStatus;
import de.hybris.platform.cronjob.model.CronJobModel;
import de.hybris.platform.servicelayer.cronjob.AbstractJobPerformable;
import de.hybris.platform.servicelayer.cronjob.PerformResult;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
public class MyJobJob extends AbstractJobPerformable<CronJobModel> {
private static final Logger LOG = LogManager.getLogger(MyJobJob.class);
@Override
public PerformResult perform(final CronJobModel cronJob) {
LOG.info("Starting MyJobJob");
// TODO: replace with the job's real work. Check isAbortRequested(cronJob)
// periodically inside any loop so a manual abort from Backoffice/HAC
// actually stops the job instead of running to completion.
if (isAbortRequested(cronJob)) {
return new PerformResult(CronJobResult.UNKNOWN, CronJobStatus.ABORTED);
}
LOG.info("Finished MyJobJob");
return new PerformResult(CronJobResult.SUCCESS, CronJobStatus.FINISHED);
}
@Override
public boolean isAbortable() {
return true;
}
}
A CronJob in SAP Commerce (Hybris) is a scheduled background task: a Java class that runs on a recurring schedule, defined by a CronJob item plus a Trigger that holds the actual cron expression. Platform examples include catalog synchronization, order cleanup, and search indexing.
The Java side is a class extending AbstractJobPerformable<T>, registered as a Spring bean, and wired to the CronJob item via a ServicelayerJob whose springId points at that bean.
Use a CronJob for anything that needs to run on its own schedule without a user triggering it directly -- nightly cleanup, periodic data sync, scheduled report generation, expiring stale records, and similar recurring background work.
If the custom CronJob type is enabled below, the job gets its own configurable attributes (e.g. a batch size) stored on the CronJob item itself and editable per-run in Backoffice/HAC, instead of being hardcoded in the Java class.
The CronJob item defines what to run (via its job reference) and holds run state/results; the Trigger holds the schedule (cronExpression) and is what actually causes it to fire. One CronJob can have multiple Triggers.
No -- most jobs work fine on the plain CronJob type. Add a custom type only when the job needs its own configurable parameters (like a batch size) that should be editable per CronJob instance without touching code.
In Backoffice, open the CronJob and use Actions > Execute, or in HAC's Console > Flexible Search find the CronJob and trigger it. Both run it immediately regardless of the Trigger's schedule.
It controls whether an "Abort" action is offered in Backoffice/HAC for a running instance of this job. Returning true doesn't stop the job by itself -- the perform() method still has to check isAbortRequested(cronJob) and return early.
Yes -- create multiple CronJob + Trigger pairs that both reference the same ServicelayerJob springId, each with its own schedule.