Too many times throughout my career have I heard “this website is slow”, “can’t you make it any faster?”, “why is it so slow?”. Most of the questions have been valid, but it’s not always that we, developers, have control over all aspects of a system.
What is caching?
First off, what is cache? Cache is data that’s temporarily stored in RAM. Being able to access data directly from the RAM allows the system to be respond much quicker, which in turn allows you to get your data, much quicker. Salesforce gives you two options for caching: session cache and org cache. In this example we’re going to discuss org cache.
When to use caching?
if you’ve built an app that relies on data from another system and you’re at the hands of another developer’s web service. That web service may not be the most efficient and/or be communicating with a database that’s not optimized, resulting in slow data retrieval and ultimately a costly job of you interfacing with that web service. As it turns out, the data you’re retrieving only changes once a week and doesn’t need to be retrieved from its source all of the time. As the developer of the Salesforce app, you now have options to improve upon the user experience. Here’s where leveraging Salesforce’s platform cache comes into play.
The first thing you’re going to need to do is enable caching in your org if you haven’t done so already.
How?
From Setup, search “Cache” in order to access Platform Cache.
Next you’ll want to create a partition. Think of this as splitting up your available cache into sections. From a scalability perspective, I would choose your naming and allocation percentages carefully. In this example we’re creating a “settings” partition. This will enable us to use this partition a bit more generically and the naming convention still making sense to others who may need to maintain the codebase with you.
In my example you’re seeing “Trial” getting the allocation and not the Organization. This is due to me leveraging my developer org and accessing a trial of platform cache. In your enterprise Salesforce org, you’ll be allocating within the Organization block.
Notice how I’m not allocating anything to session cache. This can be changed later on, but for right now we’re not going to bother with it.
Now the good part – the code! Thankfully this is quite simple, but the hard part is truly understanding when it makes sense to leverage cache. Below is an example of storing an app’s settings in cache.
//retrieve/set your data you want to cache
Map<String,String> settingsMap = new Map<String,String>{
'PageSize' => '5',
'Name' => 'My App',
'Access' => 'Admin'
};
//check to see if the cache exists
if(!Cache.Org.contains('local.settings.myApp')){
Cache.Org.put('local.settings.myApp', settingsMap);
}
//get the cache
Map<String,String> myDataFromCache = (Map<String,String>)Cache.Org.get('local.settings.myApp');
System.debug(myDataFromCache);Assuming you’ve created a partition called “settings”, you can go ahead and copy this code into your sandbox/developer org in the anonymous Apex window and review the logs.
If you’re already familiar with Apex, then you’ll know that this looks family – it looks and sounds like a Map. That’s because it essentially is. Like any Map you’re accessing within your Salesforce code, you’ll want to verify the key exists prior to retrieving it and I’ve gone ahead and done that for you in the above code sample.
From here, you can start building upon this example and incorporate caching into your app!
Benefits:
- Can be helpful to mitigate SOQL limits
- Increase the speed of your apps
- Mitigate web service callouts
More information about Salesforce’s platform cache can be found here.
Let me know some sample applications you’ve leveraged platform cache for in the comments below!