With the Spring ‘21 release, BatchApexErrorEvent is a newly available error handling tool for managed packages that makes it easier for ISVs to diagnose and debug batch processing errors. In our latest tech webinar, CodeScience Technical Architect, Rob Davis, presents a deep dive into how to use this new tool in tandem with other error handling methods to make your managed packages more resilient.

2. ● Who is CodeScience?
● Introduction
● Error handling in ISV Applications
● New In Spring ‘21
● Using these events in packages
● Demo
● Recap
Agenda

3. This is an image placeholder for an image.
Please size accordingly.
● Founding partner of the Salesforce Product
Development Organization (PDO) Program since
2008 - named Master PDO in 2017
● PDO Program provides app development services
to ISVs for the Salesforce AppExchange
● Partner with clients in various industries to assist
in building over 300 apps on the AppExchange
● From design to build to implementation, we
support through the full lifecycle
Who is CodeScience

4. Client success: 10% of the AppExchange

5. CodeScience client focus:

6. Today’s Speakers:
Rob Davis
Technical Architect
CodeScience

7. Error Handling In ISV Applications

8. Why do errors occur?
● We aren’t perfect, sometimes there are coding mistakes
● Subscribers often misconfigure applications. Missing permissions,
credentials, etc.
● Subscribers may build logic, automation, validations, etc that
interfere with the normal function of applications
● Subscriber environments may present unanticipated challenges,
such as 50M+ accounts, hundreds of Process Builders, inefficient
custom code, elaborate sharing models
● Sometimes, errors just happen

9. Reactive Error Handling
● A subscriber notices some functionality is not working, such as “An
Unexpected Error Has Occurred”, Apex jobs are in error state, data is
not correct, etc.
● They reach out to your customer support with this information, and
you have to help diagnose and fix the issue
● This is time-consuming, costly, and can lead to a loss of trust if it
happens often

10. Proactive Error Handling
● You attempt to catch errors that you anticipate, and handle them
appropriately
● You attempt to catch anything unexpected, with a few options:
○ Store in a “Log” object with visibility to subscriber, and possible trigger logic
○ Emit an event that can be subscribed to
○ “Phone home” with the information (with explicit subscriber consent)
○ Use FMA FeatureParameterInteger to log error counts
○ Flag “problem” records to exclude from processing
○ Implement a retry mechanism

11. New in Spring ‘21

12. New in Spring ‘21
Use BatchApexErrorEvent Triggers to Monitor ISV Applications
● Include BatchApexErrorEvent triggers in your managed package to
monitor the health of batch jobs and take necessary corrective action
without any post-installation steps
● This change applies to Lightning Experience and Salesforce Classic
● The BatchApexErrorEvent object represents a platform event
associated with a failing batch Apex execution

13. BatchApexErrorEvent
● This is a standard Salesforce event, which can be emitted from Batch
Apex Classes that encounter errors
● This event can be subscribed to just like normal Platform Events, as
well as being able to handle the events with triggers
● It was released in Winter ‘19, but a trigger handler could not be
packaged until Spring ‘21
● It includes information such as job id, error type, record ids being
processed, etc.
● It is triggered on any batch error, including “uncatchable” errors,
such as limit exceptions

14. Using These Events In Packages

15. Basic Setup

16. What Information do you get?
● What job id was running, from which you can get Apex class &
namespace
● The type of exception
● What IDs of the records that were being processed
● The exception message
● The Phase
● The stack trace*** (caveat on next slide)

17. What are the limitations/concerns?
● No stack trace is available when running from a managed package
● This is a standard event, so you get all subscriber and other package
events as well
● You should limit your error processing to just Apex classes in your
namespace for both data quality & security reasons
● You still don’t get direct access to the error information, and need
consent from your customers to send it to you.
● The JobScope (record ids) is limited to 40k characters (~2100 record
ids and commas), after which point it will be truncated and
DoesExceedJobScopeMaxLength set to true

18. Demo

19. In Summary...
● This new Spring ‘21 feature fills in a gap of batch error handling
● This should be used in conjunction with other available
error-handling, such as catching DML errors in the batch and
flagging problem records for follow-up
● You could log this information, subscribe to it, phone home, retry the
batch, flag problematic records, increase error counts in FMA…
● All of these options should increase the resiliency of your solution,
and make debugging issues easier

20. Contact Us:
Thank You
info@codescience.com

21. References
● Salesforce Blog Post -
https://developer.salesforce.com/blogs/2019/01/building-a-batch-retry
-framework-with-batchapexerrorevent.html
● Developer documentation -
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/ape
xcode/apex_batch_platformevents.htm
● Technical Documentation -
https://developer.salesforce.com/docs/atlas.en-us.platform_events.me
ta/platform_events/sforce_api_objects_batchapexerrorevent.htm