To pass a value from one Spring Batch step to a later step, write it to the producing step’s StepExecution ExecutionContext, then promote the selected key to the job’s ExecutionContext with ExecutionContextPromotionListener. The next step can read the promoted value from the JobExecution context.
Understand the two execution contexts
Spring Batch provides an execution context for each step and another for the entire job. They have different lifetimes and persistence points.
| Context | Scope | When it is persisted | Typical use |
|---|---|---|---|
StepExecution context |
One step execution | During a chunk step, at chunk commits; for tasklets and other steps, according to repository updates | Checkpoint state and values owned by the active step |
JobExecution context |
The job execution across steps | At the end of each step | Values that a later step needs after the producing step completes |
Do not use the job context as a live checkpoint while a step is processing. If the step fails before completion, data written only to the job context may not have been persisted. Keep in-progress state in the step context and promote only the completed step’s handoff values.
The promotion pattern
- Write during the producing step. Put the value in the active step’s execution context, for example
stepExecution.getExecutionContext().put("reportId", reportId). - Configure promotion. Attach an
ExecutionContextPromotionListenerto that step and configure the keyreportId. - Complete the step. By default, the listener promotes configured keys only when the step exit status is
COMPLETED. - Read in the following step. Obtain
reportIdfrom the job execution context.
producing step, during execution:
stepExecution.executionContext["reportId"] = generatedReportId
at step completion:
promote "reportId" to jobExecution.executionContext
following step:
reportId = jobExecution.executionContext["reportId"]Writing to the step execution context
Capture the active StepExecution
A writer, tasklet, or listener can receive the active StepExecution. A common listener-based approach captures it in beforeStep, then uses the captured object while processing.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems#1 Best Overall
public class ReportWriter implements ItemWriter<Record>, StepExecutionListener {
private StepExecution stepExecution;
@Override
public void beforeStep(StepExecution stepExecution) {
this.stepExecution = stepExecution;
}
@Override
public void write(Chunk<? extends Record> items) {
String reportId = createOrUpdateReport(items);
stepExecution.getExecutionContext().put("reportId", reportId);
}
}The exact writer method signature depends on the Spring Batch version. The important operation is writing to stepExecution.getExecutionContext() while that step is running. For chunk processing, write checkpoint-relevant values at a point consistent with your transaction and restart design.
Use stable, intentional keys
- Choose a unique key such as
reportIdrather than a generic name likevalue. - Store values that can be serialized by the configured job repository.
- Keep the context small; it is batch metadata, not a general-purpose data store.
Configure ExecutionContextPromotionListener
Configure the listener on the producing step and list every key that should cross the step boundary. The listener is a StepExecutionListener that copies those keys from the step context to the job context when the step ends.
ExecutionContextPromotionListener promotion =
new ExecutionContextPromotionListener();
promotion.setKeys(new String[] { "reportId" });
// Register promotion on the producing step.
stepBuilder.listener(promotion);Builder and bean APIs differ between Spring Batch releases, so adapt the registration syntax to the dependency version used by your application. The listener’s central configuration is the list of keys.
Control the status that permits promotion
The default promotion condition is an exit code of COMPLETED. If your workflow deliberately needs promotion for another exit status, configure exit-status patterns explicitly rather than changing the rule accidentally.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →promotion.setStatuses(new String[] { "COMPLETED", "CUSTOM_*" });Use custom patterns only when the downstream step is valid for those outcomes. Promoting data after a partial or failed operation can make a restart consume an invalid handoff.
Enable strict handling for missing keys
Strict mode makes a missing configured key an error instead of silently skipping it. This is useful when the following step cannot operate without the value.
promotion.setStrict(true);With strict handling enabled, verify that every configured key is written on every path that can reach the promotion point, including branches and empty-input cases.
Read the value in the next step
Read through JobExecution
A tasklet, reader, writer, or listener in the following step can access the job execution and retrieve the promoted value:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
String reportId = stepExecution
.getJobExecution()
.getExecutionContext()
.getString("reportId");Use the type-specific accessor that matches the stored value, and handle a missing key as a configuration or workflow error when the value is required.
Use late binding when appropriate
Spring Batch late binding can inject a job-context value into a job-scoped or step-scoped component. Configure the required scope and expression in your application, then resolve the promoted key from the job execution context. The expression and bean wiring must match the Spring Batch version and configuration style in use.
Persistence, restartability, and repository choice
The job repository stores batch metadata and execution contexts. A persistent repository is required when you need restartability or reliable context sharing between steps.
ResourcelessJobRepository is intended for executions that do not need restartability or execution-context sharing between steps. It is therefore not an appropriate choice for the promotion pattern when a later step must receive persisted context data.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteBest Value
In a chunk step, repository updates occur at checkpoint boundaries. The transaction boundaries used by repository storage and by your business-data transaction can differ, so a failure may cause an item or chunk to be processed again. Design writes to be idempotent or make duplicate handling explicit.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose the right mechanism
| Requirement | Recommended approach | Reason |
|---|---|---|
| Checkpoint state while one step runs | Step execution context | It is updated during step processing and supports restart state. |
| Pass a completed step’s result to a later step | Step context plus promotion listener | The handoff is explicit and occurs at the step boundary. |
| Promote only on successful completion | Default listener status | Promotion occurs for COMPLETED. |
| Promote on a deliberate alternate status | Configured exit-status patterns | The workflow defines exactly which outcomes are safe. |
| No restartability or cross-step context sharing | Resourceless repository | It is designed for executions without those requirements. |
Common failure modes
The next step cannot find the key
- The producing component wrote to a local field instead of the active step execution context.
- The promotion listener was not registered on the producing step.
- The key name differs between
put, listener configuration, and retrieval. - The producing step did not finish with an exit status allowed by the listener.
- A resourceless repository was selected even though context sharing is required.
Promotion fails in strict mode
Check every execution path, including skipped input, validation failure, and conditional branches. Either write the key on those paths or remove the key from promotion when it is not required.
A restart repeats work or uses stale data
Review when the value is written relative to chunk commits, how the repository transaction is configured, and whether the operation that creates the value is idempotent. A value needed for restart must be stored in the step context at a checkpoint that can be recovered safely.
Version compatibility
Spring Batch APIs and builder configuration change across releases. The current documentation set includes Spring Batch 6.0.5 reference material, a 6.0.4 API page, and a 5.0 common-pattern guide. Confirm the exact Spring Batch dependency version before copying builder, listener, or scope configuration into an application. The step-context-to-job-context promotion pattern remains the same across those documented versions.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
