(soft upbeat music)
- [Narrator] Because future looking statements
are inherently subject to risk and uncertainty, our reminder
is that you should make any purchasing decisions
or investment decisions based on products
that are currently commercially available.
- Hi everyone.
Thank you so much for joining this session
in which we are going to talk about asynchronous Apex.
My name is Alba Rivas
and I am a developer evangelist here at Salesforce.
- Hi, my name is Kevin
and I'm a developer evangelist here at Salesforce.
Today, our goal is to walk you through
the range of asynchronous offerings Apex provides.
And when you want to use Batch Apex,
versus Queueables, versus Salesforce functions
we're gonna start with a review
and in 15 minutes or so when we're done
you'll know which use cases
are perfect for asynchronous Apex
and which are good for Salesforce functions.
- Apex is the native server-side language on the platform.
We released Apex in 2006,
and today there are more than 123 billion
Apex transactions happening monthly.
A big portion of these transactions
are related to integrations,
integrations with external systems
many integrations start on Apex call-out
or finish with Apex work service.
And it is a acceptable
that those integrations are non-blocking.
This means that the user can continue working
on the page until the call-out finishes.
We achieve that by making integrations asynchronous,
asynchronous programming has historically
been a front-end development topic
but today we have seen it incorporated
more and more into server side code development.
So pay attention because during the next few minutes
Kevin and I are going to talk about the newest
and coolest Apex features
that will help you build amazing integrations easily.
- Let's do a quick review
of the async features that you can use in Apex today.
First up is Batch Apex.
Batch processes are the King of multi record processing,
they allow you to process data in batches
and each batch has its own transaction.
This is the secret sauce.
This means that each batch
has its own set of governor limits
and allows you to process large quantities of data
up to 50 million records.
And you can this without hitting the limits
because each batch is isolated in its own transaction.
If a batch succeeds and a subsequent batch fails
the successful batches will not be rolled back.
Batches are a great tool
for sequential processing of unrelated data.
- Batch's processes are definitely great.
Then we have Queueables.
Queueables are really, really fast
they are great for operations
in which you don't have to process many records.
Yes, async transaction can handle it.
And they replaced at Future methods.
Queueables are defined by classes,
the class needs to implement the Queueable interface
and as they are class-based
that means that you can define constructors,
set parameters in them and much more.
Most importantly Queueables can be changed together.
This means that you can build multi-step
asynchronous processes with them very easily.
Did you ever want to make a series of API call-outs
while saving the data between them?
That's very easy to do thanks to Queueables.
- This is great info
but example code is worth a thousand words
and that's why we've created Apex Recipes.
Apex Recipes is our newest sample app.
You can find it here,
the sticker URL below
and the recipes are broken down by category.
And if we navigate to the async Apex folder
you'll find a few examples.
I wanna call your attention
to the Queueable chaining recipes class.
That's a mouthful.
This class is all about demonstrating
how to construct Queueable classes and chain them together.
There's three things that I wanna call out here.
First, notice how this class
has that implements Queueable bits
there at the end of the definition,
that's the interface you need to implement
in order for your class to work as a Queueable.
Secondly, let's look at that execute method.
This method is required by the Queueable interface.
And it's important because this is the method
where you'll put your asynchronous logic.
Anything in here is what will be run
when the Queueable fires.
Finally, I wanna draw your attention
to the last couple of lines in that execute method.
These two lines demonstrate how you can enqueue
another Queueable.
This is the magic behind chaining Queueables together.
Each Queueable job can, enqueue a single subsequent job.
- This is fantastic Kevin
and know what we are not stopping here
we are investing in making async Apex even better.
With example of that are Transactional Finalizers.
Transaction Finalizers Pilot
is moving to (indistinct) in spring '21.
And Transaction Finalizers allow you to attach actions
to Queueable jobs that will execute when that job finishes.
no matter if it succeeded or if it failed.
A good use case for them is to design recovery actions
but either (murmurs)
Redwoods insurance is our fiction car insurance company
during normal times our mechanics
use their smartphones to arrive to incident locations.
However, that's not always possible
as sometimes policy holders may be in remote locations
with very poor GPS coverage.
Because of that Redwoods asked its developers
to generate a step-by-step driving instructions
so that mechanics can arrive anywhere.
So let's see how they did it.
First, they created a trigger case.
The trigger invokes a Queueable
The Queueable makes an asynchronous call-out
to Google Maps API where maps calculates the directions
and when those directions
are returned back to the Queueable.
The Queueable stores them
into our custom field that we have created
on the contact object.
We also added a Finalizer
the Finalizer will retry the Queueable up to three times
in case of failure.
Now let's go to VS code.
This is the class for the Queueable.
We attached the Finalizer in the execute method.
This is the class for the Finalizer.
It needs to implement the Finalizer interface
and then if you want to know,
if the Queueable succeeded or failed
you can use the get result method
on the Finalizer context parameter
that it's received in the execute method.
In this case, what we do
is to retry the Queueable up to three times
in case of failure.
Great, so now let's go to our Redwoods app.
Here we're in the Redwoods app
and what happened is that Francisco Santos
was going up a mountain with his car, got a problem
he got stuck and he called us.
He gave us his GPS coordinates
and now I'm going to create a case and see what happens.
So what I will do is to select Francisco as the main contact
and I will indicate the subject and the description,
he got a problem with his car,
he's really stuck and the engine does not start
and I will click on Save.
When I click on Save
remember that the case trigger
is going to invoke the Queueable
and the Queueable is going to retrieve that information
from Google Maps,
the directions and it's going to store that
in the custom field that we have created on contact.
Here we have them,
the directions have been retrieved correct.
In this case, the Queueables succeeded
thus the Finalizer didn't have to retry it.
But sometime later, Anna calls with a similar problem
but this time Anna gave us wrong coordinates
and let's see what happens.
I'm going to create a case with Anna, for Anna, sorry.
I'm going to indicate the contact,
the subject, the description.
And I'm going to pick on Save.
When I click on Save this time
as the coordinates were incorrect,
the Finalizer, well, the Queueable is going to fail
and the Finalizer is going to retry it up to three times
with no luck.
This time the Finalizer
couldn't recover the error
because the error was
guess that the coordinates were incorrect,
but if the error happened for another reason
for example a network connection error
we could have recovered from it thanks to the Finalizer.
Indeed Finalizers can be used for much more.
We could have extended our retry Finalizer
to create a task so that's an agent can call Anna
and ask for the correct coordinates.
We could have created a logging system.
We could even have created a promise chain.
Same as you do in JavaScript.
Indeed, I will tell you a secret
I promise pattern is coming to Apex Recipes
once the Finalizers Pilot is moving to (indistinct)
- That's an amazing example.
Queueables and Finalizers can help you implement
many async use cases.
But what if you want to implement
a more complex use case,
functions to the rescue.
Functions can be invoked from Apex
both synchronously and asynchronously.
So let's take a look at how they work.
Salesforce functions is our service
for elastic scale serverless compute
because they're written in Java and JavaScript.
You can utilize third-party libraries
for quick productivity.
Now y'all might be thinking
I can't wait to get my hands on functions
but functions aren't a good match for all workloads.
And we really wanna help you shape your understanding
of when to use native asynchronous Apex tools
such as Queueables and when to use functions.
So it looks examine an extended use case.
Alba demonstrated the way that Queueables
can call out to third-party systems
and integrate data and how those Finalizers
can then provide a mechanism for retrying failed call-outs.
While fast and robust
this solution still suffers from one critical problem
and that is that those directions are stored in Salesforce.
If our customers ended up needing help
where there's no connectivity,
Redwoods employees won't be able to access those directions,
thankfully functions give us an elegant solution to this.
Instead of getting the directions and storing them
we can write a function that generates a PDF
including maps and directions and then stores that PDF
back on the record in Salesforce.
Employees can then print this PDF at the office
before heading out to an area
where there's questionable connectivity.
So let me show you how we invoke
that Apex function asynchronously.
To invoke the function asynchronously
you have to pass a callback
to the function dot invoke method.
This callback needs to implement the functions
that function callback interface
and to have a handle response method
which is where the result will be processed.
Now let's try it out.
We'll insert a case, our function will run
and if we navigate to the case
we'll see that the PDF was created and attached correctly.
The differences between these use cases are subtle,
so let's tease them out.
Both integrate with third-party systems
for generating directions.
However, one of them also generates a PDF
with a map generated from Google Maps.
Creating a PDF through Visualforce is possible
but it requires calling a method that acts like a call-out
and this provides some difficulty as you have to handle DML
and call-outs in the same transaction.
You could probably write a clever
mostly bulk saved trigger to generate PDFs with maps
and imagery from a Visualforce page
but you're still gonna have to deal
with navigating DML after a call-out.
Of course you could also write multiple Queueables
and chain them together to do it
alternating between DML and call-outs,
but each or does have a finite number
in queue jobs each day.
What's more important with functions
is that there are already libraries for generating PDFs
and accessing Google Map directions.
You can use those libraries straight away
via NPM and implement this use case really quickly.
And if you're a Java expert
you can do the same thing with Java libraries.
Additionally functions are elastic
and this means that even though this particular example
isn't very resource heavy
functions do not constrain you by resource limits.
Functions, shift the focus away from governor limits
making this sort of work much easier.
They're not a replacement for asynchronous Apex,
but an addition to it, why?
Because functions trade governor limits for startup time.
Once a function is hot, meaning that it's up and running
they're speedy little functions.
But once a functions container goes to sleep
you'll have to wait the startup time.
In some cases like this one
it's not likely
they we'll need the directions PDF in seconds
so a few minutes warm up and processing time is just fine.
On the other hand, getting access
to the directions in a custom field
now that would be really nice to have immediately.
- When you are developing asynchronous Apex
the guidelines on which method to use are clear
but sometimes subtle.
If you need to process large amounts of data
use a batch job.
If you want to implement asynchronous behavior first
use a Queueable.
Remember that part of the power of Queueables
is that you can chain them together
to build a process chain
and now you can even attach Finalizers to them.
Finally, functions are perfect
when you want to leverage the power of programming languages
as Java and JavaScript.
Third party libraries and of course, elastic compute.
One last more thing
remember that we have a new sample app
to help you master Apex this is Apex Recipes.
If you want to learn more about async Apex
we have recipes for you there.
If you want to learn more about REST Web Services
we have recipes for you as well
and we are always adding more.
To get started with Apex Recipes
check out this Quickstart
that we have created on Trailhead especially for you.
And with that we have arrived to the end of the session.
Thank you so much for watching and happy coding.
(soft music)