Have you ever thought of having high performing, scalable Salesforce application
without any governor limits or writing a code that is not in native apex(salesforce) but does the same work, or a Function as a Service (FaaS) similar to AWS Lambda & Google Cloud Run?
Salesforce Function is somewhat similar to AWS Lambda & Google Cloud Run but not the same. It is a single purpose, on-demand, short live microservice without complex infrastructure. Salesforce Functions is designed to boost developer productivity by reducing your infrastructure responsibilities and enabling you to build and integrate Functions-as-a-Service (FaaS) apps using the languages and tools of your choice.
A Function is your code, run on-demand, in Salesforce Functions elastic trusted computing environments. Upload your complex business logic code, written in your preferred languages and frameworks, and Salesforce Functions takes care of everything else necessary to invoke your code in a secure and self-scaling environment.
Why and where to use Salesforce Function
Innovate with Cross Cloud Open Standards
Develop complex business logic using the languages and tools of your choice.
Scale Elastically on Trusted Infrastructure
Deploy and run your Function in a Salesforce managed elastic compute infrastructure.
You write code in industry-standard programming languages and run your code within the Salesforce trust boundary. When your code runs, it automatically scales with load.
Deliver Connected Experiences
Integrate your Function securely and easily with your org. Your Salesforce Function is automatically authenticated to the org invoking your Function at run-time, meaning that you don’t have to worry about dealing with authentication, or any of the other complexities of making external systems access your org.
No limit on Governor limits
With Salesforce Function, you don't have to worry about any of the governor limits, it runs outside your Salesforce Org, and it scales as per the request.
Architecture Diagram
Salesforce Functions securely and seamlessly works with your existing org resources, making it easy to stay on the Salesforce Customer360 platform. Your Salesforce Function is automatically authenticated to the org invoking your Function at run-time, meaning that you don’t have to worry about dealing with authentication, or any of the other complexities of making an external system access your org.
With Salesforce Functions, you can perform compute-heavy tasks that would be difficult or impossible to do in your org. Salesforce elastically scales compute resources for your Functions for you, meaning you don’t have to manually modify compute resource configurations every time you update your Function.
Salesforce Functions are deployed to, and run in, a secure Salesforce-managed infrastructure separate from your Salesforce org. Your functions are developed and tested in their own testing and production "spaces" that are isolated from the rest of your production environment.
A Salesforce Function is code that performs a specific compute task. You could have a Function that reads your sales data and calculates a sales tax, or a Function that collects data and generates a formatted PDF report file. Functions can securely work with org data but aren’t deployed to your org or run in your org’s infrastructure.
Salesforce Functions Projects are deployed to a Salesforce compute environment. In general, an environment in the Salesforce cloud represents a place where things run. Your org is an environment that runs things like your Apex code or your Flows. A compute environment is where your Functions code runs. A single compute environment contains a single Project, so that Functions in a Project can run in an isolated and dedicated environment
Your Salesforce org can be connected to one or more compute environments. When you deploy your Salesforce DX project that contains Functions, you specify an org that will be invoking the Project Functions. The Functions deploy process will use your org information and the Project name to determine which compute environment to use or create. For example, if you wanted to test your “Billing” Project in a sandbox org, you’d deploy your Project, specifying your sandbox org, and the deploy process would determine the compute environment to use and automatically connect your org to this compute environment.
When you need to invoke a Function from your org, you specify the project name and the Function name. Because your org is already connected to a compute environment, the invocation process knows exactly which compute environment to use. You don’t have to specify the compute environment, which ensures that you can’t, for example, accidentally run your in-development Function in a compute environment connected to your production org.
How to Start with Salesforce Function using JavaScript
Follow up the steps mentioned in the URL to have pre-requisite setup https://developer.salesforce.com/docs/platform/functions/guide/index.html#2.-set-up
Open your VS Code and create a project, CTRL+Shift+P on windows machine, select SFDX: Create Project with Manifest.
Authorize a Salesforce Org by SFDX: Authorize an Org then create a Scratch Org SFDX: Create a Default Scratch Org...
Next use the SFDX: Create Function palette command to create a Function in the current DX project open in VS Code. If you create a JavaScript Function, this command installs package.json dependencies for the created Function.
Check index.js file under your function, this will look something like this.
/* Describe Hellomke here. * * The exported method is the entry point for your code when the function is invoked. * * Following parameters are pre-configured and provided to your function on execution: * @param event: represents the data associated with the occurrence of an event, and * supporting metadata about the source of that occurrence. * @param context: represents the connection to Functions and your Salesforce org. * @param logger: logging handler used to capture application logs and trace specifically * to a given execution of a function. */ module.exports = async function (event, context, logger) { logger.info(`Invoking Hellomke with payload ${JSON.stringify(event.data || {})}`); const results = await context.org.dataApi.query('SELECT Id, Name FROM Account'); logger.info(JSON.stringify(results)); return results; }
In JavaScript and TypeScript, specify and export a execute entry point. The following JavaScript example provides an execute entry point function:
module.exports = async function execute(event, context, logger) {
// function code
};
The SDKs provide context data for the calling org when your Function is invoked. This is passed as a parameter to your Function entry point. Through this context you can query and execute DML on your org data. Record access is controlled using the "Functions" permission set in your org.
Through the context data you can access the DataApi interface to query, insert, and update records. The following JavaScript example uses context.org.dataApi to make a simple query to the org that invoked the Function
module.exports = async function execute(event, context, logger) {
const query = "SELECT Id, Name FROM Account";
const results = await context.org.dataApi.query(query);
logger.info(JSON.stringify(results));
return results;
};
Next use the SFDX: Start Function palette command to start a Function.
Now either you run your function through Terminals, or you can create a payload.json file under your function. This file can be empty, or you can use this to pass your parameter to the function.
Click on Invoke(payload.json) on the top to execute the function. The result will show you all the accounts in your scratch org in the Output.
You can modify your index.js file to create Account by passing account name from payload.json.
/** * Describe Hellomke here. * * The exported method is the entry point for your code when the function is invoked. * * Following parameters are pre-configured and provided to your function on execution: * @param event: represents the data associated with the occurrence of an event, and * supporting metadata about the source of that occurrence. * @param context: represents the connection to Functions and your Salesforce org. * @param logger: logging handler used to capture application logs and trace specifically * to a given execution of a function. */ module.exports = async function (event, context, logger) { logger.info(`Invoking Hellomke with payload ${JSON.stringify(event.data || {})}`);
const accountName=event.data.accountName;
const results = await context.org.dataApi.create({
type:'Account',
fields:{
Name:accountName
}
});
logger.info(JSON.stringify(results));
return results;
}
Before you execute account creation, make sure you use SFDX: Stop Function palette command to stop this Function. Then, use the SFDX: Start Function palette command to start this Function again.
Click on invoke(payload.json) then you can check your output, you will find Account id, check your default org you can find an Account with name “Joey” using this id.
Note-
Currently the infrastructure for Functions compute environments is located in US regions. At this time, compute environments can't be created in EU or APAC regions. This means that if you have an org in the EU or APAC regions that invokes a Function, the Function will run in an infrastructure located in a US region, and access your EU or APAC region org data from the US.
A Salesforce Functions license is required to enable functions for your org. Contact your Salesforce account representative for steps to acquire the license.References-
Comments