How to make Error Handling in the Batches much Easier? : Vimera

How to make Error Handling in the Batches much Easier?
by: Vimera
blow post content copied from  Forcetalks
click here to view original post

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.

The post How to make Error Handling in the Batches much Easier? appeared first on Forcetalks.

November 10, 2023 at 11:44PM
Click here for more details...

=============================
The original post is available in Forcetalks by Vimera
this post has been published as it is through automation. Automation script brings all the top bloggers post under a single umbrella.
The purpose of this blog, Follow the top Salesforce bloggers and collect all blogs in a single place through automation.
============================