How to use a recurring Integration Endpoint for importing data
You are here
BatchRetryable RunBaseBatch Class
BatchRetryable RunBaseBatch Class
Updated "Standard" Batch Job for BatchRetryable
I wrote an article on how to create a batch class several years ago. I thought I'd update it for modern times with the implementation of BatchRetryable. All source code for this article can be found here.
As compared to what we've done in the past to use this framework, not a whole lot has changed but there are a few notable call outs.
internal final class AAXStandardBatchJob extends RunBaseBatch implements BatchRetryable
First, let's review the class delcartion. a few different modifiers on the class that are now defaults. Internal and Final are optional but will be added by default. The implements BatchRetryable makes this class retry-able using the BatchRetryable system. Using this new system is optional but reccommended.
Next is how we build the workloads because of how BatchRetryable works:
public void run()
{
AAXStandardBatchJobTable AAXStandardBatchJobTable;this.batchInfo().parmRetriesOnFailure(this.numberOfRetries());
int64 maxId;
try
{
info(strFmt("Running batch job with parameter: %1", workCount));
Info(strfmt("ThrowError set to %1", throwError));
if (workCount)
{
while select forupdate Id, Updated, RecId from AAXStandardBatchJobTable
where AAXStandardBatchJobTable.Updated == NoYes::No
{if(AAXStandardBatchJobTable)
{
ttsbegin;
AAXStandardBatchJobTable.Updated = NoYes::Yes;
AAXStandardBatchJobTable.update();
ttscommit;}
if(throwError == NoYes::Yes)
{
if(new RandomGenerate().randomInt(0,1000) >= 999) // 1 in 1000 chance of error
{
warning(strFmt("simulating throwing an unrecoverable error to trigger a retry"));
throw Exception::UpdateConflictNotRecovered;
}
}
}}
}
catch (Exception::Error)
{
error("An error occurred during the batch job execution.");
}
}
If you look at our while select, we are only getting records that present for the given batch job to process then process them in a set based manner knowing any 1 record / loop iteration may have a simulated error that needs to be recovered from. BatchRetryable will recover from this, if instructed to, so we have to plan ahead and consider that 1 batch job execution maybe get tried more than once with its first attempt being partially successful. Consider a workload of 1000 records. If we process 100 record, then occur an error, BatchRetryable will start the batch job again - wiping any logging placed during the first run of the job. So iteration 1 of our job will start with 1000 records to process, process 100 of them, have an error, then restart the job with only 900 left to process. If any logging was recorded during the first 100's records being updated, BatchRetryable will remove it and it will not be stored anywhere for review - unless it is written somewhere outside of the BatchInfo instance for the job.
Next, we have a new method to indicate if our batch task is retry-able.
public boolean isRetryable()
{
return true;
}
This being true or false says if true, the batch job is retry-able; can be retried if an error occurs.
Optionally, you can change the code that may schedule the batch job to use a non-default retry count. The default value is 5. You can change this on the Batch header record if you'd like using code or using the UI in System Administration > Setup > Batch Class.
public int numberOfRetries()
{
return 10;
}
This will set the number of retries allows on the batch header record using the Run() method to specifically set this to a non-default and also non-configured value.
All source code for the entire project can be found here. Further reading is available here.