Book Image

Mastering Apex Programming

By : Paul Battisson
5 (1)
Book Image

Mastering Apex Programming

5 (1)
By: Paul Battisson

Overview of this book

As applications built on the Salesforce platform are now a key part of many organizations, developers are shifting focus to Apex, Salesforce’s proprietary programming language. As a Salesforce developer, it is important to understand the range of tools at your disposal, how and when to use them, and best practices for working with Apex. Mastering Apex Programming will help you explore the advanced features of Apex programming and guide you in delivering robust solutions that scale. This book starts by taking you through common Apex mistakes, debugging, exception handling, and testing. You'll then discover different asynchronous Apex programming options and develop custom Apex REST web services. The book shows you how to define and utilize Batch Apex, Queueable Apex, and Scheduled Apex using common scenarios before teaching you how to define, publish, and consume platform events and RESTful endpoints with Apex. Finally, you'll learn how to profile and improve the performance of your Apex application, including architecture trade-offs. With code examples used to facilitate discussion throughout, by the end of the book, you'll have developed the skills needed to build robust and scalable applications in Apex.
Table of Contents (21 chapters)
1
Section 1 – Triggers, Testing, and Security
8
Section 2 – Asynchronous Apex and Apex REST
15
Section 3 – Apex Performance

Improving CPU time

CPU time is the amount of time spent running our Apex code during a transaction. It is difficult to pin down exactly, as many factors can come into play that determine how much time is spent running a piece of code; however, in general, there are two ways to improve the CPU usage:

  • Work on a smaller amount of data (that is, do less work).
  • Operate on the data in a more efficient manner.

It is always important to consider whether the first option is possible. Can we make our query more selective (refer to the Improving query selectivity section ahead) or simply reduce the amount of work we are doing to speed up the system? A standard synchronous transaction has 10,000 ms of CPU time available. If we are processing 10,000 records, that means 1 ms each. For 1,000 records, that means 10 ms each, again not a lot of time. Anything we can do, therefore, to reduce the scope of the data we are working on will be beneficial in improving our overall performance...