Advanced 35 min read

Add Async Processing

By the end of this lesson, you'll be able to:

Add a nightly Batch Apex job recalculating health for every active Project
Explain why this async safety net matters even with the real-time trigger already in place
Reuse Module 42's exact scheduled-batch pattern on a new domain

Prerequisites: "Build the Trigger Handlers"

The batch job

global class RecalculateProjectHealthBatch implements Database.Batchable<SObject> {
    global Database.QueryLocator start(Database.BatchableContext bc) {
        return Database.getQueryLocator([SELECT Id FROM Project__c WHERE Status__c = 'Active']);
    }

    global void execute(Database.BatchableContext bc, List<SObject> scope) {
        Set<Id> projectIds = new Map<Id, SObject>(scope).keySet();
        Map<Id, String> health = new ProjectHealthService().calculateHealth(projectIds);
        // ...build and update Project__c records from the health map
    }

    global void finish(Database.BatchableContext bc) {}
}

System.schedule('Nightly Project Health Recalculation', '0 0 3 * * ?', new RecalculateProjectHealthBatchScheduler());

The exact start/execute/finish shape and 3:00 AM scheduling from Module 42\'s RecalculateBalancesBatch — this project reuses the pattern directly rather than reinventing it, because the underlying need is identical: a periodic safety net for a value kept correct in real time by triggers.

Why a safety net is needed even with real-time triggers

The same reasons from Module 42, Lesson 3, still apply here: a bulk data load of Milestonec records with triggers disabled, a bug fixed after some records were already affected, or a manual data correction could all leave `Projectc.Health__c` out of sync with its true Milestone data. The nightly job self-heals any such drift.

Reusing `ProjectHealthService` directly, unmodified

Notice that RecalculateProjectHealthBatch.execute calls the exact same ProjectHealthService.calculateHealth method the real-time trigger path (Lesson 6) already uses — this is the actual payoff of Lesson 5\'s dependency-injection design: the business logic lives in one place, callable identically from a trigger-triggered real-time path and a scheduled batch path, with zero duplication.

Exercise

As a comment, explain why RecalculateProjectHealthBatch.execute calls ProjectHealthService.calculateHealth rather than reimplementing the health-calculation logic directly inside the batch class.

Show hint

Think about what would happen if the health-calculation rules changed later.

APEX

Add Async Processing Quiz

1. What is the actual payoff of Lesson 5's dependency-injection design, as demonstrated by this lesson's batch job?

The same business logic (ProjectHealthService) is reused identically by both the real-time trigger path and the scheduled batch path, with zero duplication Dependency injection has no connection to how the batch job was built It means the batch job runs faster than a trigger would It allows the batch job to skip governor limits entirely

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

A nightly batch job recalculates every active Project's health from scratch — Module 42's exact Batch Apex safety-net pattern, reused here to catch any drift the real-time trigger-driven recalculation might miss.

← Build the Trigger Handlers Add Integrations →