If you ever been in Java and .Net development and have moved to salesforce then you must had been missing one feature which is Session Management. This is something which every Salesforce developer waited for so long. It’s quite close to what we have in other server programming languages but with some limitations due to the multitenant environment of Salesforce. Platform cache is a new arrow in SF dev’s quiver to increase the performance of an application. View state has been an issue if it comes to mobile development. Now, it is a part of Salesforce since Winter’16 release so I thought to write a post about this.
Caching of data is primarily used to increase the app performance, for situations where you want to use same data across the multiple transactions. To solve this purpose, we have been using Visualforce view state and sometimes custom setting or custom objects but these ways have their own cost like decreasing the app performance. Platform cache is built on the application layer of the Salesforce infrastructure which abstracts away all the tedious stuff. Platform cache would be very significant in many use cases and few of them which I can think of at the moment are the following –
- To display data based on filters applied by any user over initially queried data
- To manage the menus in navigation bars based on the user profiles
- To create the custom login functionality on force.com sites as cookies are not a secure way to achieve it
- To keep user-specific information across the Visualforce pages
- To store access token in OAuth 2.0 implementation of 3rd party apps
- Wherever passing values in URLs are not secure
Platform Cache can be controlled using a simple API in apex. It also provides a built-in way to retrieve cached values in Visualforce page and in declarative formulas. Platform cache comes with 2 different varieties and each has its own features and its beauty of salesforce.
Session Cache – For each user with their own space and persistence
As the name implies, the Session cache is built for the individual user session where each user has their own space and can not be altered by any other user. This can be used where you want to keep the information related to logged in user for temporary uses. As a developer, you don’t need to store that information mapped with user’s session Id as Platform API take care of that. For example, your app is used by the field users very frequently to get the work order details. To increase the performance, you can get the data queried initially and keep that data in the Session cache for further filtration. Session cache expires when its specified time-to-live (ttlsecs value) is reached or when the session expires after eight hours, whichever comes first.
Org Cache – For all the users with shared space and persistence
This cache type is available for all the users and can be used across the application. This is useful where you want to have the same set of data for all the users. For example, Keeping the access token which is frequently used in a API call to the third party system. Org cache expires when its specified time-to-live (ttlsecs value) is reached.
Cache Management – To manage your cache uses
Platform cache can be divided into a partition and each partition can be used for a specific purpose. It’s same as we used to have the different partition of a HDD in our windows machine. Salesforce imposed some limitations to better utilization of this feature due to its multitenant environment. You can use up to 10 MB overall cache in the enterprise edition.
Platform cache API – Get/Put values in apex
Platform API uses Cache namespace in which there are some classes are defined. Org and Session class is one of them which have get and put methods.
Put value in Org and Session cache Cache.Org.put(KEY, VALUE, TIME_IN_SECONDS); - Store a value in Org cache Cache.Session.put(KEY, VALUE, TIME_IN_SECONDS); - Store a value in Session cache
Get value from Org and Session cache Cache.Org.get('KEY') - Returns an object which can be typecast Cache.Session.get('KEY') - Returns an object which can be typecast
Platform cache should be used wherever it’s necessary and retrieving values are expensive. Instead of cached everything, this should be used wisely like this your last weapon on your list.
In next post, I will use a common use case where this can be used. Stay tuned with SFCure 🙂