Caching has long been a hot topic when it comes to the Portals technology – so much so that it’s used in the name of top-rated Power Apps Portals podcast “Refresh the Cache” hosted by MVPs Nick Doelman and Colin Vermander. So, what is caching, why is it important for Power Apps Portals, and what’s changed about it recently?
One of the challenges with caching is figuring out what to do when the source changes. For example, if your computer has cached the fact that microsoft.com points to 22.214.171.124, but then Microsoft changes it, how does your computer know to get the updated value? In general, caching often relies on remembering information for a certain period of time, and then it will go back to the original source.
Your Power Apps Portal is hosted on a web application, that is hosted on Azure, separate from the CDS database. Querying the CDS database takes time, so rather than querying every time, the Portal application code caching the answer to those queries in memory and uses those instead of always asking.
Have you ever noticed how long the first page load takes after restarting your Portal? This is because nothing is cached. If caching wasn’t used, every page load would take that long. And nobody would use it.
The challenge with caching for Portals is when data is updated directly in CDS, without going through the Portal. In those cases, the Portal isn’t aware that anything has changed, and so has no reason not to trust the responses to the queries it has stored in its cache. So how does the Portal find out about the changes?
The process of letting the Portal know that its cache needs updating is also known as cache invalidation. We’ve gone through a few iterations now of cache invalidation techniques:
Now Microsoft has moved to a slightly different model, with the biggest change being that not all entities are treated equally. For the techniques mentioned above, all entities were treated the same (as long as you configured the plugins or Change Tracking). In this new model, Microsoft has split the entities into two types: configuration and non-configuration entities.
Configuration entities are the core Portal entities like Web Page and Web Template. For a full list, see this blog post from Microsoft announcing the change. For these entities, there is no automatic invalidation of the cache – any changes to those records via the CRM API or the Portal Management Model-Driven App require you to manually clear the cache.
Any entity that is not in that list is considered a non-configuration entity, and the cache will be invalidated automatically. The official SLA for cache invalidation for these entities, as mentioned in that same blog post, is 15 minutes.
How do you go about clearing the cache for the configuration entities? You’ve got a few options:
It’s important to note that any changes made via the legacy front-side editing, or via the new “Maker” experience shouldn’t require you to clear the config cache. It should only be necessary when making changes via the Model-Drive App, or via the CRM API (which includes tools like the Portal Code Editor for the XrmToolBox, which use the CRM API).