[MUSIC]
Speaker 1: Because future looking statements are inherently subject to risk
and uncertainty.
A reminder is that you should make any purchasing decisions or
investment decisions based on products that are currently commercially available.
Asavari: Hi, everyone, welcome to our episode of TDX.
Today we're excited to talk to you about the latest addition to the Salesforce
platform, that is Salesforce functions.
In this episode, we'll cover the key capabilities of functions and
share some exciting new demos.
Let's get started.
My name is Asavari.
I'm a product manager on the Salesforce platform working on functions.
Joe: And I'm Joe Kutner.
I'm an architect working on Salesforce functions and the Heroku platform.
Asavari: All right, and before we get into the details of what functions is,
Joe, why don't you tell us more about why functions?
Why are we building this product?
Joe: Sure, if we look at the current landscape of how our customers are running
their custom business logic, there's really two paradigms they follow.
The first is running on-platform.
But there's some disadvantages here.
There's limited language choice and
you have a limited ability to pull in open source libraries and other dependencies.
You also have a fixed scale.
So it becomes difficult to scale to the demand that you may need to.
The alternative and what some of our other customers are doing is moving that
custom logic off the platform onto their own infrastructure.
But this incurs its own burden, because now you have to operate and
manage that infrastructure.
So you're taking on operational burden for those services.
It also comes with its cost, as you have to pay for that infrastructure, and
a whole set of security concerns.
You have to apply security patches, make sure these things are up to date.
And then you also have the risk of taking your customer data outside of that
Salesforce trust boundary.
At the end of the day, you may not even be able to do what you want to do
because of API limits that the platform imposes on you.
So it's a kind of pick your poison situation.
But now, imagine if there was a best of both worlds scenario where you could have
the flexibility of the off-platform solution,
but with all the trust from the on-platform solution.
Asavari, can you tell us about that?
Asavari: Sure, and that's exactly the kind of solution
that we're trying to build with Salesforce functions.
So, let's talk more about what Salesforce function is.
As the name suggests, it functions as a service offering or offers offering.
It gives you the ability to write custom code in a language of your choice and
run it on demand and at scale in the cloud.
You can build these functions using open source programming languages like Node
and Java.
So you can pick the stack that's best suited for
your skills and put the requirements of your workload and
still take advantage of a whole myriad of NPM and Maven libraries available to you.
For those of you who are more familiar with Apex,
you can still take advantage of the event-driven paradigms and
elastic scale that functions has to offer by writing your functions in Apex.
Now, what's cool is that functions provide a context aware programming model, so
you can easily read and write data in your Salesforce org from within your function.
These functions can be developed using the sfdx CLI locally and
or the VS code extension for Salesforce.
What's also cool is that these functions are a native part of the platform,
which means they can seamlessly integrate with other programmatic or declarative
tools on the platform, such as lightning web component flow, or even Apex.
If you're an ISV, guess what?
You can even package and
distribute these functions as part of the AppExchange solutions.
Asavari: So with that, Joe, would you like to tell us more about what are some use
cases that we can truly accomplish using Salesforce functions?
Joe: Sure, there are really three categories of use case that different
customers will fit into.
Now, the first is what we call database operations,
this is where you need to run custom logic against your sales data or
even against external data like financial or some other import.
The second category is the event-driven or elastic compute solution.
These are CPU-bound processes, for example, where you might be
generating a QR code or reading a QR code, or doing other image processing.
The last category is the reusable backend logic where these functions are powering
some other kind of frontend application like a web app or a mobile application.
And these are just reusable bits of logic that are behind that.
This might also include data validation and cleansing like an ETL process.
So now what I'd like to do is show you a demo of how to get
started with Salesforce functions.
Okay, so I have, VS Code open here with a very simple sfdx project,
you can see my sfdx-project.json.
Now I'm going to open a terminal and start using the sfdx CLI.
And I'm going to use this new function topic.
So if I run sfdx help function,
it's going to tell me some of the commands that are available.
I can use this to create functions, delete functions, invoke them, and deploy them.
So I'm going to start by creating a function.
I'll call it myfunction.
And I choose the language that I want this function to be written in.
And for this demo, I'm going to use JavaScript.
I can also choose TypeScript though.
So when I run this, it's going to create some directories and some files.
The basic scaffolding of a Salesforce function so
that I can get started very quickly.
So if you can see here, there's a functions directory.
It contains my package.json, some other files, and my index.json.
This is really the core piece of the function.
And so in the first line, you'll see that I'm importing the Salesforce SDK package.
This package provides some utilities that help me
interact with the Salesforce platform and some basic functions that I'll use.
Below here on line 15 is my actual function where I'm declaring it.
You'll see that the function has three arguments.
The first argument is the event.
This is essentially the payload to the function.
So for each invocation of the function, I'm going to get a different event.
The next argument is the context.
This is the environment in which my function is running in.
And that's what I'll use to interact with my org, for example.
And then the last argument is the logger.
This allows me to emit some messages to the console, which I can later on use for
debugging and tracing the performance of my function.
So in this example, I'm simply logging my event data.
So, what's in my payload.
I'm making a query on my org, and I'm taking those results and
logging them, and then I'm returning that back to my client.
So let's return to the CLI and test this out.
The first thing I need to do is start this function.
So when I run function, whoops, I have to first change directories into
my new function directory and then I can run function start.
So when I run this command, it's first going to build and package my function.
It's going to download all the assets that are necessary to do that.
It's going to install Node.js into my image and
all of my NPM packages that this function depends on.
At the end, I'll have a running function that I can actually invoke.
So while we're waiting for that,
I'm going to jump over to another terminal session.
I need to send this function a payload when I invoke it.
So I'm going to create a little payload JSON file.
And then in this file,
I'll put a simple message field as the only data and the value of Hello there,
just so I can see something coming through in my function.
I'm going to set a debug point in my function code.
So I can actually use the standard VS Code debugging facilities to
interact with this code just like I would if it was any other JavaScript program.
So I'm going to put a breakpoint on this last return line so
that we can inspect some of the results.
Okay, now my function is about to start.
So I'm going to connect deep my debugger to that running function.
So I come into the debug console.
And I can click Run.
And in a moment that should connect to that running process there.
I see the debugger has attached.
Okay, now when I return to my other terminal session,
I can run sfdx function: invoke http// localhost 8080.
And then I'm going to send it that payload that I just created.
So there's that payload json file.
So now when I run this, it'll send an invocation to that container.
And it will see my debugger pick it up as it's running through the code.
So over on the left hand panel, I can see all of my local variables,
I can see my data, my event data, there's my message, Hello there.
That's what came in as the payload to the function.
I can see my call stack, and
all the other things I would expect as a JavaScript developer.
Here are my results, which I can see from the Variables pane.
And I'm going to have this run through.
And now I've got a result back from my function,
which is essentially the result of that org query.
So now the next step would be to deploy this function.
And I'm going to turn it over to Asavari,
who's going to show you another example of a CPU-bound example.
Asavari: All right, so with that, let's jump into yet
another demo of how you can use functions.
In this new world of being remote,
customers often want services to be delivered to their doorstep.
And as a provider of one such service, we have here several delivery
partners that we work with, a fleet of vehicles that we use for
the delivery, and the services that we actually deliver.
Today, we'd like to build in Node Salesforce function,
such that given the set of services that we have and fleet of vehicles.
Our function can calculate delivery route and waypoints to help us come up with
a delivery plan that'll help us optimize the time and resources that we have.
This is popularly known as the travelling salesman problem and
is a high compute use case that can benefit from some elastic scale.
So let's go ahead and take a look at our function.
Here we have in a Salesforce project our function that looks very similar
to the function that Joe just showed us.
And the first thing we do in our function is to go ahead and grab the doer name and
the account ID from the incoming platform event payload to our function.
Then we'll go ahead and use the preauthenticated Salesforce
context to the function to query the vehicles that we have and
the services that we have in our org.
Finally, we'll go ahead and
create a new client using the Google Maps NPM library.
Set up the variables for the TSP search and
then go ahead and run the TSP server.
In order to make our updates to Salesforce in a more transactional manner,
we'll go ahead and create a new unit of work instance.
We'll then create a new SObject for the delivery plan that we're going to create.
And similarly, also create the delivery routes and the delivery waypoints.
We'll register these new SObjects to the unit of work that we just created.
And then go ahead and
commit that entire transaction back to our Salesforce org, and that's it.
That's all we need to write our business logic to develop our function.
Now let's see how this function works.
For the purpose of this demo,
I already have this function deployed to the platform.
And guess what?
This function is listening on a route planning platform event,
such that when this event is emitted, we will go ahead and trigger our function.
I also have a flow right here that is watching for
any new deliveries that are created.
When a new delivery is added to an account, our flow will go ahead and
create a new platform event,
which is that very same platform event that our function is listening on.
So let's take a look at how our function works.
Now we'll go back to our accounts and
create a new delivery day for acme deliveries.
Let's call this TDX five drop off.
And when we create this, what happens underneath the covers is that flow that we
just saw gets triggered, which in turn invokes our function.
In a second here,
we should see that our function will produce a new updated delivery plan.
And there we have it.
Our new route for delivery and the route order appears.
And that's really how simple it is to create a function that
can be triggered by an event and help you solve high compute use cases.
And the example that we just saw is that of a node function that is triggered by
a platform event.
You can also write your functions in Java or in Apex.
In fact, these functions can be triggered by not just platform events,
but even CDC events or directly be called by a lightning web
component from within a flow or even from existing Apex code.
Once these functions execute,
they run in a serverless container runtime, and they can seamlessly read or
write data from your Salesforce org as we just saw in our demo.
At the same time, these functions can also orchestrate with data in
standard sequel or Redis, or Kafka data stores.
Now what's really magical about the serverless container runtime
is the scale that it has to offer to us.
So, Joe, why don't you tell us more about
the scaling capabilities of the runtime that we have here?
Joe: Yeah, so there are a lot of different ways in which your Salesforce function can
be invoked.
And you're going to need a platform that can scale out to
handle all those different kinds of requests.
So if we compare this to the on-platform
sort of paradigm that we talked about earlier, you're really limited in scale.
You have fixed CPU, fixed heap limits, and just a fixed capacity.
But on a more elastic platform like Salesforce functions,
your functions can scale out to automatically meet any kind of demand.
And they can do this very rapidly.
So if we take an example of an application that is selling concert tickets.
That application has a very specific window of when it's going to have
a peak traffic, a sort of spike in traffic.
And so you need a platform that's able to very quickly scale up or
scale out by creating more instances of that function handling those concurrently.
But then as soon as the concert tickets are sold out,
it needs to scale back in and go back down to zero so that you're not paying for
resources that you don't need.
So Salesforce functions is really great at handling this kind of elastic capacity,
but it's also good at more prolonged fluctuations.
For example,
retail companies that have large spikes in demand over Black Friday weekend.
But the best part about this is that you're getting that elastic
scalability and you're staying on the platform,
you're able to keep your customer data inside that trust boundary.
Asavari: Okay, with that, we're closing in towards the end of our episode.
If you're interested in signing up to learn more,
please take a look at the interest form.
If you'd like to be a part of the dev preview,
please reach out to your sales team for next steps.
With that, thank you so much for taking the time today.
Hope you have a great TDX.
[MUSIC]
Houssam: [FOREIGN] Doria: [FOREIGN]
Simon: [FOREIGN]
Blanca: Hello, Chicago [FOREIGN]
Sanas: [FOREIGN]
Amanda: Hello.
Heidi: Hello from Canberra.
Christian: [FOREIGN] Neetu: [FOREIGN]
[MUSIC]
Adam: The mission of IBM Salesforce partnership is focused on building AI for
business powered with Watson, Salesforce and Einstein.
Today, Watson assistant enables you to deliver a virtual
assistant with consistent,
automated self service that customers want within Salesforce Service Cloud.
Visit the IBM booth to learn more about how using Watson with
Salesforce Service Cloud can transform your customer service.
[MUSIC]
Marcus: Did you know that an ally is someone who doesn't identify as
an underrepresented group, but seeks to understand the challenges that they face?
At Salesforce, we've distilled becoming an ally into four practices, ask, listen,
show up, and speak up.
Skilling up on equality makes our community stronger.
Learn more on Trailhead and earn your Equality Ally Strategies badge.
[MUSIC]