What is Azure Key Vault? A beginner’s guide and use cases
Amplify your security posture with Azure Key Vault.
Finally, Salesforce Functions became generally available in the Salesforce Winter’22 Release. But before we jump into a deeper discussion of the Salesforce Functions, let me highlight how and where the Functions could be helpful.
Do you have a Salesforce organization with heavily customized Apex triggers that reach Salesforce’s transaction limits? Or, maybe you have complex Apex Batch jobs that hit the maximum number of asynchronous Apex limits? Or, your Apex code makes API callouts and, as a response, gets a timeout exception? If these sound familiar, then a new cool feature called Salesforce Function is for you.
Salesforce Function is a service of the platform that lets Salesforce developers create code that connects data and events. It can run on-demand with an elastic scale in a Compute environment and can be integrated with low-code and pro-code services to deliver an agile and unified Salesforce experience.
The Compute environment, aka Evergreen, is a new serverless environment powered by Kubernetes for the Customer 360 platform that integrates Heroku’s decade-long experience in creating extensible container runtimes and highly efficient data stores with Lighting functionality. Salesforce’s Evergreen Function is equivalent to Azure’s Functions and AWS Lambda.
Salesforce Functions extend Salesforce business logic to meet any demand. With Functions, you can write code in industry-standard programming languages like Java or Node.js using SDK, and run your code within the Salesforce trust boundary. 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. When the code runs, it automatically scales with load and doesn’t count against your Salesforce request limits.
With Salesforce Functions, we can perform compute-heavy tasks that would be difficult or impossible to do in Salesforce org. Salesforce elastically scales compute resources, which means that you don’t have to manually adjust compute resource configurations every time you update a Function.
Salesforce Functions are deployed to, and run in, a secure Salesforce-managed infrastructure separate from Salesforce org. This has application lifecycle implications that require an understanding of how Functions are deployed, where they run, and how they’re associated with orgs. Salesforce Function Projects are deployed to a Salesforce compute environment. One Salesforce org can be connected to one or more compute environments.
A Salesforce Function is a code that performs a specific compute task. You can now 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 org or run in org’s infrastructure.
Functions are contained in the functions directory of a Salesforce DX project. One or more Functions can be included in a single Project. For example, you might have a “Billing” Project that contains a “CalculateTax” Function and a “GeneratePDF” Function. Projects are created using Salesforce DX. You create a DX project that contains your Function code, Function configuration files, Apex code, permissions sets, and anything else necessary for deploying and using the Function. You give the Project a name (via a parameter in the DX project configuration file) which helps identify a Project when deployed.
Salesforce Function 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.
Currently, the infrastructure for Functions compute environments is located in the 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.
Salesforce Functions are not supported in Managed Package functionality yet. The Salesforce team works on this part of the functionality and considers a couple of approaches:
The Salesforce team actively collaborates with ISVs partners and collects feedback from other partners to better understand the current needs.
We have heavily customized logic on Salesforce triggers or other Apex tasks that are reaching the Apex transaction limits. You periodically receive a notification that triggers a reached CPU Time limit, Max SOQL query limit, Max DML operation limits, or similar transaction limits.
We have a set of Apex asynchronous jobs in the Salesforce environment that have reached the maximum number of asynchronous Apex method executions (batch Apex, future methods, Queueable Apex, and scheduled Apex) per a 24-hour period that is 250,000 executions or the number of user licenses in your org multiplied by 200, whichever is greater.
→ Our insights on Apex Describe Performance
We have a set of Apex asynchronous jobs in the Salesforce environment that has reached the maximum number of batch Apex jobs in the Apex flex queue that are in a Holding status (limit equals 100), or the maximum number of batch Apex jobs queued or active concurrently (limit equal 5).
We have an outbound Apex API integration in the Salesforce environment that has reached the Maximum cumulative timeout for all callouts (HTTP requests or Web services calls) in a transaction due to complex logic on the external service side.
We have a need to backup a large Salesforce data set. There are a few solutions on the market to back up Salesforce data, but these services work with queries and might reach the set limits. The key advantage of the Salesforce Function is that you won’t reach the limits on system queries. So, if you need to deal with big data volumes for backup, the Function is a good option.
Functions run “outside” of org in an elastic compute infrastructure that frees you from having to worry about many Salesforce org limits. Additionally, when invoking Functions, some Salesforce-side limits, such as API call limits, are adjusted to make sure the Functions can scale to your needs. There are, however, some Salesforce Function limits that you still need to keep in mind while developing your Functions.
Apex code that invokes Functions still runs on your org, and still has the usual Apex limits applied. The following Apex limits have special considerations when applied to Apex code invoking Functions:
|Max timeout for a response from synchronously invoked Function||2 minutes||Currently, API requests from Functions are counted against the maximum API requests for a given org (this applies to the Function’s beta only and may change once the Function is generally available). Use UnitOfWork classes in the SDKs or the Composite Graph API to reduce the number of API requests.|
|Max number of asynchronous Function invocations from Apex||No limits||Long-running requests are requests that take 20 seconds or longer. Consider moving long-running requests into the org — for example, move a complex data operation into Apex and have the Function utilize this code via Apex REST, or perform the complex data operation in the Apex callback code from an asynchronous invocation.|
|Max number of concurrent synchronous long-running (over 5 seconds) Function invocations||No limits||For beta, run-time includes a Function’s execution time, however this will be excluded when Functions is generally available. Consider using an asynchronous invocation instead of synchronous invocations.|
The following table lists the limits for Functions deployed and running in compute environments.
|Execution time||15 minutes||Consider splitting up the work of your Function into separate Functions, or separate phases of the overall workflow you’re trying to accomplish.|
|Process memory||1 GB||Consider splitting up the work of your Function into separate Functions, or separate phases of the overall workflow you’re trying to accomplish.|
|Payload size||6 MB synch, 12 MB async||Large data files, such as image or video files, should not be passed as part of the Function payload. Instead, store the data externally prior to the invocation and reference the data by URL.|
|Response size||6 MB synch, 12 MB async||This only applies to the response data from the Functions sent back to Apex, not to the total amount of data that can be written back to the org.|
The following limits apply to the Salesforce web service API calls your Function’s code makes to the org that invoked the Function. Keep in mind if you’re using the Function’s SDKs, such as the Node.js or Java SDKs, data API methods in the SDKs are using the Salesforce web service APIs as well.
|API requests per 24 hour period per org||For beta, the same as the API limits. It will increase when Functions are generally available.||Currently, API requests from Functions are counted against the maximum API requests for a given org (this applies to the Function’s beta only and may change once the Function is generally available). Use UnitOfWork classes in the SDKs or the Composite Graph API to reduce the number of API requests.|
|Concurrent long-running API requests||The same as the API Limit.||Long-running requests are requests that take 20 seconds or longer. Consider moving long-running requests into the org — for example, move a complex data operation into Apex and have the Function utilize this code via Apex REST, or perform the complex data operation in the Apex callback code from an asynchronous invocation.|
Salesforce Functions are a welcome addition that are well-suited for building integrated and scalable apps. Though not without imperfections, their integration capabilities, elasticity, data accessibility, etc. make it much more comfortable to extend the solutions with custom code applications. Avenga will keep watching the developments of the Salesforce ecosystem and implementing them into first-hand experiences, so that we can ensure our clients get their full Salesforce investment into their quality deployment and timely project implementation.
Amplify your security posture with Azure Key Vault.
Explore the ins and outs of the Salesforce audit process, and find out how to follow the particular steps in preparing and carrying out the audit process.
Explore new ways of enhancing your UI tests with Playwright.
Avenga expands its US presence to drive digital transformation in life sciences. The IT service provider offers custom software development for industry-specific projects.
Discover an in-depth understanding of IT project outsourcing to have a clear perspective on when to approach it and how to do that most effectively.
Discover the latest advancements in blockchain technology and stay ahead of the curve.
Discover the benefits of DevOps outsourcing and the best tips for working an engineering vendor.
Learn how to manage vendors in a project to ensure its future success.
Start a conversation
We’d like to hear from you. Use the contact form below and we’ll get back to you shortly.