Tuesday, September 29, 2026

SAP Commerce CronJobs Explained: Job, CronJob, Trigger, Performable, Scheduling, Cluster Execution & Production Best Practices

Introduction

Scheduled processing is a fundamental requirement in SAP Commerce.

Commerce applications frequently need background tasks such as:

  • Synchronizing products
  • Updating inventory
  • Sending notifications
  • Cleaning old data
  • Generating reports
  • Importing data
  • Exporting data
  • Updating prices
  • Processing integration data
  • Running maintenance activities
  • Triggering business processes

Instead of requiring an administrator to execute these operations manually, SAP Commerce provides CronJobs.

SAP describes CronJobs as a mechanism for executing complex business logic at particular times and intervals.

A simplified architecture is:

             CronJob
                |
                v
             Trigger
                |
                v
          ServicelayerJob
                |
                v
        JobPerformable
                |
                v
        Business Service
                |
        +-------+-------+
        |               |
        v               v
      DB/API          Commerce

Understanding the difference between Job, CronJob, Trigger and Performable is extremely important for SAP Commerce interviews.

1. What Is a CronJob?

A CronJob represents an execution of a scheduled task.

For example:

Every day at 11 PM
       |
       v
Product cleanup CronJob
       |
       v
Execute Java business logic

Another example:

Every Sunday at midnight
       |
       v
Inventory synchronization

CronJobs are useful when the operation needs to run:

  • Automatically
  • Repeatedly
  • At a particular time
  • Without user interaction

2. Job vs CronJob vs Trigger

This is one of the most frequently misunderstood areas.

Think of the three objects like this:

JOB
=
What should be executed?

CRONJOB
=
An execution/configuration instance of that job.

TRIGGER
=
When should the CronJob execute?

For example:

Job:
ProductCleanupJob

CronJob:
NightlyProductCleanupCronJob

Trigger:
Every day at 11:00 PM

The relationship can be visualized as:

             Job
              |
              v
         CronJob
              |
              v
           Trigger
              |
              v
         Scheduled Run

3. What Is a Job?

A Job represents the executable logic definition.

In modern SAP Commerce service-layer implementations, a common pattern is to implement JobPerformable through AbstractJobPerformable. SAP's documentation identifies AbstractJobPerformable as an abstract implementation that provides services such as ModelService, SessionService, and FlexibleSearchService.

Example:

public class ProductCleanupJob
        extends AbstractJobPerformable<CronJobModel>
{
    @Override
    public PerformResult perform(final CronJobModel cronJob)
    {
        // Business logic

        return new PerformResult(
                CronJobResult.SUCCESS,
                CronJobStatus.FINISHED
        );
    }
}

The important method is:

perform()

This is where the execution logic is normally implemented.

4. What Is a ServicelayerJob?

A ServicelayerJob connects the CronJob framework to a Java JobPerformable.

Conceptually:

CronJob
   |
   v
ServicelayerJob
   |
   v
Java Performable Class

For example:

ProductCleanupCronJob
        |
        v
ProductCleanupServicelayerJob
        |
        v
ProductCleanupJob

The Java class contains the actual business logic.

5. What Is a Trigger?

A Trigger determines when a CronJob should run.

For example:

Every day at 11 PM

or:

Every Monday at 2 AM

or:

Every 30 minutes

Conceptually:

Job
 |
 v
CronJob
 |
 v
Trigger
 |
 v
Execution

One job can have different CronJob instances and scheduling requirements.

6. Simple Real-World Example

Suppose the business requirement is:

Every night at 11 PM, identify abandoned carts older than 30 days and remove them.

Architecture:

AbandonedCartCleanupJob
           |
           v
AbandonedCartCleanupCronJob
           |
           v
Trigger
           |
           v
Every day at 11 PM

The Java class contains the logic.

The CronJob represents the execution.

The Trigger determines when it runs.

7. Creating a CronJob Performable

A common implementation is:

package com.mycompany.core.jobs;

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;

public class ProductCleanupJob
        extends AbstractJobPerformable<CronJobModel>
{
    @Override
    public PerformResult perform(final CronJobModel cronJob)
    {
        // Business logic

        return new PerformResult(
                CronJobResult.SUCCESS,
                CronJobStatus.FINISHED
        );
    }
}

PerformResult represents whether the execution completed and whether it was successful. SAP's service-layer CronJob API documents this execution-result model explicitly.

8. Injecting Services into a CronJob

Avoid putting all business logic directly inside the CronJob class.

Instead:

CronJob
   |
   v
Service
   |
   v
DAO
   |
   v
Database

Example:

public class ProductCleanupJob
        extends AbstractJobPerformable<CronJobModel>
{
    private ProductCleanupService productCleanupService;

    @Override
    public PerformResult perform(final CronJobModel cronJob)
    {
        productCleanupService.cleanup();

        return new PerformResult(
                CronJobResult.SUCCESS,
                CronJobStatus.FINISHED
        );
    }

    public void setProductCleanupService(
            final ProductCleanupService productCleanupService)
    {
        this.productCleanupService = productCleanupService;
    }
}

This keeps responsibilities separated.

9. Spring Configuration

The performable is normally registered as a Spring bean.

Example:

<bean id="productCleanupJob"
      class="com.mycompany.core.jobs.ProductCleanupJob"
      parent="abstractJobPerformable">

    <property name="productCleanupService"
              ref="productCleanupService"/>
</bean>

The important relationship is:

Spring Bean
     |
     v
ProductCleanupJob
     |
     v
ProductCleanupService

SAP's documentation also demonstrates registering a job bean and injecting services into the performable.

10. Registering the ServicelayerJob

The job can then be associated with a ServicelayerJob.

Conceptually:

ServicelayerJob
    |
    +-- code
    |
    +-- springId

For example:

code:
productCleanupJob

springId:
productCleanupJob

The springId identifies the Spring bean responsible for execution.

11. CronJob Type vs ServicelayerJob

For simple use cases, you may use:

CronJobModel

directly.

For more advanced use cases, you may define a custom CronJob type.

For example:

<itemtype code="ProductCleanupCronJob"
          extends="CronJob">
    <attributes>

        <attribute qualifier="batchSize"
                   type="java.lang.Integer">
            <modifiers read="true"
                       write="true"
                       optional="true"/>
            <persistence type="property"/>
        </attribute>

    </attributes>
</itemtype>

Now the CronJob can have custom configuration.

For example:

ProductCleanupCronJob
        |
        +-- batchSize = 500
        +-- dryRun = true
        +-- daysToKeep = 30

This is useful when the same job needs configurable behavior.

12. Using a Custom CronJob Parameter

Suppose the business wants:

Delete products older than N days

Instead of hardcoding:

30

you can store:

daysToKeep

on a custom CronJob.

Then:

ProductCleanupCronJobModel cleanupCronJob =
        (ProductCleanupCronJobModel) cronJob;

Integer daysToKeep =
        cleanupCronJob.getDaysToKeep();

This makes the job reusable.

13. Cron Expressions

Scheduling commonly requires a cron expression.

For example:

Every day at 11 PM

is conceptually represented by a schedule such as:

0 0 23 * * ?

However, SAP Commerce Trigger configuration should be validated against the version and scheduling syntax used by the specific project.

The key concept is:

Trigger
   |
   +-- start time
   +-- frequency
   +-- recurrence

14. Example: Daily 11 PM Job

Business requirement:

Run inventory synchronization every day at 11 PM.

Conceptually:

InventorySyncJob
       |
       v
InventorySyncCronJob
       |
       v
Daily Trigger
       |
       v
23:00

The execution then becomes:

23:00
 |
 v
Trigger fires
 |
 v
CronJob starts
 |
 v
perform()
 |
 v
Inventory synchronization
 |
 v
SUCCESS / FAILURE

15. CronJob Result and Status

A CronJob execution has two important concepts:

Result

For example:

SUCCESS
FAILURE
UNKNOWN

Status

For example:

RUNNING
FINISHED
ABORTED

These concepts answer different questions.

Result

Did the business operation succeed?

Status

What is the execution state?

For example:

Result  = FAILURE
Status  = FINISHED

means the execution finished but the business operation failed.

16. Handling Exceptions

A CronJob should not silently swallow exceptions.

Bad:

try
{
    service.process();
}
catch (Exception e)
{
    // Nothing
}

return success;

This is dangerous because the CronJob may report:

SUCCESS

even though processing failed.

Better:

try
{
    service.process();

    return new PerformResult(
            CronJobResult.SUCCESS,
            CronJobStatus.FINISHED
    );
}
catch (Exception e)
{
    LOG.error("Product cleanup failed", e);

    return new PerformResult(
            CronJobResult.FAILURE,
            CronJobStatus.FINISHED
    );
}

The exact exception strategy should depend on whether the exception should propagate to the framework or be converted into a failure result.

17. Logging Best Practices

Always provide useful logs.

Bad:

LOG.info("Job started");

Better:

LOG.info("Product cleanup job started. CronJob: "
        + cronJob.getCode());

At completion:

LOG.info("Product cleanup completed. "
        + "Processed: " + processed
        + ", Failed: " + failed);

Useful production logs should help answer:

When did it start?
What did it process?
How many records?
How long did it take?
Did anything fail?
Why did it fail?

18. FlexibleSearch Inside CronJobs

CronJobs frequently use FlexibleSearch.

Example:

final String query =
        "SELECT {pk} " +
        "FROM {Product} " +
        "WHERE {modifiedtime} < ?date";

final Map<String, Object> params =
        new HashMap<>();

params.put("date", cutoffDate);

SearchResult<ProductModel> result =
        flexibleSearchService.search(query, params);

Then:

for (ProductModel product : result.getResult())
{
    // Process
}

But be careful with large datasets.

19. Don't Load Millions of Records at Once

This is a common CronJob performance mistake.

Bad approach:

List<ProductModel> products =
        flexibleSearchService.search(query)
                             .getResult();

for (ProductModel product : products)
{
    process(product);
}

If there are millions of products, memory consumption can become significant.

Better approaches may include:

  • Pagination
  • Batch processing
  • FlexibleSearch pagination
  • Processing by PK ranges where appropriate
  • Search restrictions designed carefully
  • Chunked transactions

20. Batch Processing

Suppose there are:

1,000,000 records

Instead of:

Process 1,000,000

process:

Batch 1 -> 1,000
Batch 2 -> 1,000
Batch 3 -> 1,000
...

Conceptually:

int start = 0;
int pageSize = 500;

while (true)
{
    // Fetch one batch

    // Process batch

    // Move to next batch
}

Batch size should be chosen based on the operation and environment.

21. Transaction Considerations

A long-running CronJob should not necessarily perform millions of modifications inside one huge transaction.

Potential problems include:

  • Large transaction logs
  • Long locks
  • Rollback cost
  • Memory pressure
  • Database contention

A better strategy can be:

Batch
   |
   v
Process
   |
   v
Commit
   |
   v
Next batch

The correct transaction boundary depends on the business operation.

22. Long-Running CronJobs

Consider a job that takes:

6 hours

while its trigger runs every:

1 hour

You can potentially end up with overlapping executions.

Conceptually:

10:00 -> Job A starts
11:00 -> Job B starts
12:00 -> Job C starts

If the job isn't designed for this, multiple executions may process the same records.

This can cause:

  • Duplicate processing
  • Database contention
  • Incorrect results
  • Increased CPU usage
  • Integration duplication

23. Preventing Concurrent Execution

Before designing a CronJob, ask:

Can two instances safely run at the same time?

If not, the design needs a concurrency strategy.

Possible approaches include:

  • Scheduling frequency greater than maximum execution duration
  • Job-level execution controls
  • Locking
  • Status markers
  • Idempotent processing
  • Partitioning work

The best solution depends on the business requirement.

24. Idempotency

Idempotency is extremely important for integration CronJobs.

Suppose a job sends:

Order 1001

to an external system.

If the job runs twice, you don't want:

Order 1001
Order 1001

to be created twice externally.

A robust design can maintain:

Order
 |
 +-- integrationStatus
 +-- externalId
 +-- lastProcessedTime

Then the job can determine whether processing is required.

25. Abortable CronJobs

Some jobs are long-running and should support administrator cancellation.

SAP Commerce's JobPerformable contract includes abort-related functionality, and SAP's API documentation shows isAbortable() as the mechanism for identifying jobs that support abortion.

Conceptually:

@Override
public boolean isAbortable()
{
    return true;
}

A long-running job should also check whether an abort has been requested at sensible points in its processing loop.

For example:

Batch 1
  |
  v
Check abort
  |
  v
Batch 2
  |
  v
Check abort
  |
  v
Batch 3

Don't wait until millions of records have been processed before checking.

26. Thread Safety

SAP documentation notes that perform() may be called synchronously or asynchronously, so the implementation needs to be thread-safe.

Avoid mutable static state such as:

private static int counter;

for execution-specific information.

Prefer local variables:

int processed = 0;

and stateless service implementations where possible.

27. CronJobs in a Cluster

Modern SAP Commerce deployments commonly run multiple application nodes.

For example:

             Load Balancer
                  |
       +----------+----------+
       |                     |
    Node 1                 Node 2
       |                     |
       +----------+----------+
                  |
              Database

A major question is:

Which node executes the CronJob?

You don't want every node independently executing the same business operation.

SAP Commerce provides mechanisms for CronJob execution in clustered environments.

The exact behavior depends on the cluster configuration, scheduling setup, node configuration, and SAP Commerce version.

28. Cluster-Aware Design

When designing a CronJob, consider:

Is execution restricted to an appropriate node?

and:

Can another node accidentally execute the same work?

This becomes especially important for:

  • External API calls
  • Payment-related processing
  • Order processing
  • Inventory updates
  • Data exports
  • File generation

A cluster-safe design should make duplicate execution either impossible or harmless.

29. Node Groups

Node groups can be used to control where certain processing workloads execute.

Conceptually:

Cluster
 |
 +-- Processing nodes
 |
 +-- Web nodes
 |
 +-- Specialized nodes

You may want heavy background processing to execute on nodes intended for that workload rather than competing with customer-facing traffic.

The exact node-group configuration depends on the deployment architecture.

30. CronJob vs Task Engine

SAP Commerce also provides a Task Service.

SAP documentation describes the Task Service as suitable for time-based or event-based actions, including clustered environments, and notes that tasks can be simpler than CronJobs when the additional CronJob features aren't needed.

A useful conceptual distinction is:

CronJob
    |
    +-- Scheduled recurring processing
    +-- Execution history
    +-- CronJob configuration
    +-- Operational controls

Task
    |
    +-- Lightweight scheduled/event-driven work

Choose based on the requirements rather than automatically using CronJobs for every background task.

31. CronJob vs Business Process

Business Processes are different from simple scheduled jobs.

A Business Process is useful when you have a workflow such as:

Order Created
      |
      v
Payment
      |
      v
Warehouse
      |
      v
Shipment
      |
      v
Email

A CronJob is better suited to:

Every night
    |
    v
Run cleanup

SAP Commerce's process engine is designed for asynchronous business workflows with ordered actions and conditions.

32. When Should You Use a CronJob?

Good use cases include:

Daily cleanup
Nightly synchronization
Scheduled data export
Price recalculation
Catalog processing
Periodic reports
Scheduled integration
Maintenance operations

33. When Should You Avoid a CronJob?

Don't automatically use CronJobs for:

Real-time customer requests
Immediate synchronous processing
Complex stateful workflows
Simple one-off application logic

For example, if a customer clicks:

Place Order

you wouldn't normally create a CronJob to synchronously complete the order.

That belongs to the appropriate synchronous business flow/process architecture.

34. FlexibleSearch Performance in CronJobs

A common anti-pattern is:

for (ProductModel product : products)
{
    final String query =
        "SELECT {pk} FROM {SomeItem} "
      + "WHERE {product} = ?product";

    flexibleSearchService.search(
        query,
        Collections.singletonMap("product", product)
    );
}

This creates:

1 query
+
N additional queries

which is an N+1 query pattern.

Instead, investigate whether the required information can be fetched in one appropriately designed query or batch.

35. Example: Better Batch Query

Instead of:

Product 1 -> Query
Product 2 -> Query
Product 3 -> Query
...

consider:

One query
    |
    v
All required records
    |
    v
Process in memory/batches

For example:

SELECT {pk}
FROM {Product}
WHERE {modifiedtime} < ?cutoff

Then process the results in manageable batches.

The exact implementation should be tested against the expected data volume.

36. CronJob Monitoring

Every production CronJob should be operationally observable.

Useful information includes:

CronJob code
Start time
End time
Duration
Status
Result
Records processed
Records failed
Error details

For example:

ProductCleanupCronJob

Started:   23:00:01
Finished:  23:12:44
Duration:  12m 43s

Processed: 125,400
Failed:    14

Result: FAILURE

This is far more useful than:

Job failed.

37. CronJob History

CronJob execution history is useful when investigating:

When did the job last run?
Did it succeed?
How long did it take?
Has execution time increased?
Did failures start recently?

SAP Commerce provides services and DAOs for CronJob history and execution information.

This can help identify trends.

For example:

Monday      10 min
Tuesday     12 min
Wednesday   15 min
Thursday    30 min
Friday      75 min

That trend could indicate:

  • Data growth
  • Database slowdown
  • External API latency
  • Inefficient query
  • Increased processing volume

38. Common CronJob Production Problems

Problem 1: CronJob never runs

Check:

Trigger
CronJob
Job configuration
Node availability
Cluster configuration
Logs

Problem 2: CronJob runs twice

Investigate:

Multiple triggers
Cluster configuration
Overlapping executions
Manual execution
Duplicate configuration

Problem 3: CronJob takes too long

Investigate:

FlexibleSearch
N+1 queries
Batch size
External APIs
Database locks
Model loading
Large transactions

Problem 4: CronJob fails randomly

Look for:

Timeouts
Memory issues
External service failures
Database connectivity
Concurrent execution
Null data
Unexpected records

39. CronJob and External APIs

Suppose the job calls:

SAP Commerce
       |
       v
External ERP
       |
       v
External response

Never assume the external API will always be available.

You need to consider:

  • Timeout
  • Retry
  • Rate limits
  • Duplicate requests
  • Authentication expiration
  • Partial failures
  • Response validation

A robust design should make the job restartable.

40. Retry Strategy

Suppose:

1000 orders

are being exported.

Order 1-500 succeed.

Order 501 fails because the external API is temporarily unavailable.

You don't necessarily want the next execution to resend:

1-500

again.

Instead, track processing state:

Processed:
1-500

Failed:
501

Pending:
502-1000

Then the next execution can focus on failed/pending records.

41. Restartability

A good CronJob should be restartable whenever practical.

Imagine:

Job starts
    |
    v
Processes 100,000 records
    |
    X
Application crashes

If restarting requires:

Process all 100,000 again

the job may be expensive or cause duplicates.

Better:

Processed marker
        |
        v
Resume from remaining work

This is especially important for integration jobs.

42. Avoid Hardcoding Configuration

Bad:

private static final int BATCH_SIZE = 500;

For frequently changing operational values, configuration may be more appropriate.

Examples:

batchSize
retryCount
timeout
daysToKeep
endpoint

This makes the job more adaptable across environments.

43. Testing a CronJob

A CronJob should have tests at multiple levels.

Unit Test

Test business logic independently.

Integration Test

Test:

CronJob
+
Service
+
DAO
+
Commerce platform

End-to-End Validation

Verify:

Trigger
   |
   v
CronJob
   |
   v
Business operation
   |
   v
Expected data/result

SAP's own CronJob example includes integration-test coverage as part of the implementation workflow.

44. Example Test Scenarios

For a cleanup CronJob:

Test 1:
Old record -> deleted

Test 2:
Recent record -> retained

Test 3:
No records -> SUCCESS

Test 4:
Database exception -> FAILURE

Test 5:
Large dataset -> processed in batches

Test 6:
Abort requested -> execution stops safely

These scenarios are much more valuable than testing only the happy path.

45. SAP Commerce Cloud / CCv2 Considerations

In SAP Commerce Cloud environments, don't assume local development behavior exactly matches cloud execution.

Consider:

Multiple nodes
Containerized runtime
Cloud-managed infrastructure
Externalized configuration
Logging/monitoring
Deployment lifecycle

A CronJob should therefore be designed without relying on:

Local filesystem permanence
Specific machine hostname
Single-node assumptions
Manual server access

If a job generates files, think carefully about where the files need to go and how downstream systems consume them.

46. CronJob Generating a CSV

A common SAP Commerce requirement is:

Run a CronJob every night and generate a CSV containing orders.

Architecture:

Trigger
   |
   v
CronJob
   |
   v
Order Service / DAO
   |
   v
Batch Processing
   |
   v
CSV Generator
   |
   v
Output Destination

Don't load every order into memory.

Prefer:

Read batch
   |
Write batch
   |
Release memory
   |
Next batch

47. CronJob Design Pattern

A clean architecture is:

CronJob
   |
   v
Service
   |
   +---- DAO
   |
   +---- External Client
   |
   +---- Converter
   |
   +---- Repository/Storage

The CronJob should primarily orchestrate the operation.

Avoid:

CronJob
   |
   +-- 500 lines of business logic
   +-- SQL/FlexibleSearch everywhere
   +-- HTTP calls
   +-- CSV generation
   +-- Complex transformations

That becomes difficult to test and maintain.

48. Senior-Level Scenario

Requirement

Every hour, process 500,000 records and send them to an external API.

What would you consider?

Answer

I would evaluate:

1. Batch size
2. API rate limits
3. Retry strategy
4. Idempotency
5. Concurrent execution
6. Failure recovery
7. Transaction boundaries
8. Database query efficiency
9. Cluster execution
10. Monitoring
11. Abort support
12. Restartability

The important point is that the CronJob is only the scheduler/execution mechanism.

The real architecture must handle the operational characteristics of the workload.

49. Senior-Level Scenario: Job Running Twice

Problem

An order-export job unexpectedly sends duplicate orders.

Possible investigation:

Is there more than one Trigger?
        |
        v
Is the job already running?
        |
        v
Can multiple nodes execute it?
        |
        v
Is the job idempotent?
        |
        v
Is there a processing/status marker?

A robust integration should not depend solely on the assumption that the scheduler will never execute twice.

50. Senior-Level Scenario: CronJob Suddenly Becomes Slow

Suppose:

Previous execution = 15 minutes

Current execution = 2 hours

Investigate in layers:

Application
   |
   +-- Code changes?
   |
   +-- Batch size?
   |
   +-- Number of records?
   |
   +-- FlexibleSearch?
   |
Database
   |
   +-- Locks?
   +-- Slow queries?
   |
External Systems
   |
   +-- API latency?
   +-- Rate limiting?

Compare execution metrics rather than immediately rewriting the entire job.

51. Interview Questions

Q1. What is a CronJob?

A CronJob is SAP Commerce's scheduled execution mechanism for running business logic at specified times or intervals.

Q2. What is the difference between Job and CronJob?

Job
=
Execution logic definition

CronJob
=
Configured execution instance

Q3. What is a Trigger?

A Trigger determines when a CronJob should execute.

Q4. What is JobPerformable?

It is the service-layer contract for executable job logic. AbstractJobPerformable provides a convenient base implementation.

Q5. What method contains the execution logic?

Typically:

perform(CronJobModel cronJob)

Q6. What does PerformResult represent?

It represents whether the execution has finished and whether it succeeded.

Q7. How do you make a CronJob abortable?

Implement the appropriate abortable behavior, including isAbortable(), and design the processing loop to respond to abort requests safely.

Q8. How do you improve a slow CronJob?

Investigate:

FlexibleSearch
N+1 queries
Batch size
Database locks
External APIs
Model loading
Transactions
Concurrency

Q9. How do you prevent duplicate processing?

Use a combination of:

Idempotency
Processing status
Concurrency controls
Appropriate scheduling
Cluster-aware execution

Q10. CronJob vs Task Service?

CronJobs provide richer scheduled execution functionality, while SAP documents Task Service as a simpler option for time-based or event-based actions when the additional CronJob features aren't needed.

52. Production Checklist

Before deploying a CronJob, ask:

[ ] Is the business logic in a service?
[ ] Is the job Spring-configured?
[ ] Is the CronJob configuration correct?
[ ] Is the Trigger correct?
[ ] Is the schedule correct?
[ ] Is timezone behavior understood?
[ ] Is the job idempotent?
[ ] Can executions overlap?
[ ] Is it cluster-safe?
[ ] Is batch processing required?
[ ] Are FlexibleSearch queries optimized?
[ ] Are external API failures handled?
[ ] Is retry behavior defined?
[ ] Is the job abortable if necessary?
[ ] Is useful logging present?
[ ] Is execution history monitored?
[ ] Is restartability considered?
[ ] Has large-volume testing been performed?

53. CronJob Architecture Cheat Sheet

                     TRIGGER
                        |
                        | When?
                        v
                    CRONJOB
                        |
                        | Which execution?
                        v
                  SERVICE LAYER JOB
                        |
                        | What code?
                        v
                 JOB PERFORMABLE
                        |
                        v
                     SERVICE
                   /    |     \
                  /     |      \
               DAO    API     ModelService
                |       |
                v       v
             Database External System

Remember:

Trigger
    = WHEN

CronJob
    = EXECUTION INSTANCE

Job
    = EXECUTABLE DEFINITION

Performable
    = JAVA EXECUTION LOGIC

54. Final Takeaways

For SAP Commerce interviews and production development, remember these principles:

1. Don't put all business logic inside the CronJob.

Use:

CronJob → Service → DAO/API

2. Think about data volume.

A query that works with:

1,000 records

may fail badly with:

10 million records

3. Design for failure.

External systems, databases and application nodes can fail.

4. Make integration jobs idempotent.

Duplicate execution should not create duplicate business effects.

5. Think about clustering.

Never assume there is only one application node.

6. Monitor execution time.

A job becoming progressively slower can reveal a growing data or architectural problem.

7. Use the right background-processing mechanism.

CronJob, Task Service and Business Process solve different problems.

8. Design for restartability.

A failed job should ideally resume or safely reprocess work without creating duplicate effects.

Posted by at
Labels: , , , , , , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)