How to make Error Handling in the Batches much Easier?

Have you ever faced such situation, when your batch handles loads of data, and suddenly one of chunks has failed, and to understand the cause of an error, you have to write customer error handlers to catch the error? And what if your org has dozens of various batches with different logic?

Well, Salesforce has a solution for this.

Any batch can implement the interface called Database.RaisesPlatformEvents which will wrap up your batch with a standard handler.

First, you need to ensure that your batch is implementing Database.RaisesPlatformEvents interface.

After that, if any unhandled error happens in your batch, the platform event called BatchApexErrorEvent will be created.

This event according to documentation has next fields:

• AsyncApexJobId – The AsyncApexJob record for the batch Apex job that fired this event.
• DoesExceedJobScopeMaxLength – True if the JobScope field is truncated due to the message exceeding the character limit.
• EventUuid – A universally unique identifier (UUID) that identifies a platform event message. This field is available in API version 52.0 and later.
• ExceptionType – The Apex exception type name. Internal platform errors are represented as the System.UnexpectedException type.
• JobScope – The Record IDs that are in scope if the event was fired from the execute() method of a batch job. If the batch job uses custom iterators instead of sObjects, JobScope is the toString() representation of the iterable objects. The maximum length is 40000 characters.
• Message – The exception message text. The maximum length is 5000 characters.
• Phase – The phase of the batch job when it encountered an error (start, execute, finish).
• ReplayId – Represents an ID value that is populated by the system and refers to the position of the event in the event stream. Replay ID values aren’t guaranteed to be contiguous for consecutive events. A subscriber can store a replay ID value and use it on resubscription to retrieve missed events that are within the retention window.
• RequestId – The unique ID of the batch job that fired the event. Event monitoring customers can use this information to correlate the error with logging information.
• StackTrace – The Apex stacktrace of the exception, if available. The maximum length is 5000 characters.

Once an event is created the next step is to catch and handle that event. There is a way to do it quite simple.

Don't forget to check out: Data Manipulation and Error Handling in Salesforce

Create the platform event triggered flow.

Than choose BatchApexErrorEvent platform event to handle.

Now $Record that is being passed to flow is BatchApexErrorEvent event that contains data about the batch error and the batch itself.

Now in this flow you can create a custom object (that should be created before), to store all error data, or send email about the batch error, or even fix records that have failed to proceed.

This event can be handled by a flow, apex trigger, processes and pub/sub API and streaming API.

As you can see RaisesPlatformEvents interface can make error handling in the batches much easier. You will receive complete information about your batch error.

Check out another amazing blog here by Vimera: Marketing Cloud Account Engagement (Pardot) Use Cases

This article was originally published on the Vimera's website.