Cache Scope
|
Standard Support for Mule 4.1 ended on November 2, 2020, and this version of Mule reached its End of Life on November 2, 2022, when Extended Support ended. Deployments of new applications to CloudHub that use this version of Mule are no longer allowed. Only in-place updates to applications are permitted. MuleSoft recommends that you upgrade to the latest version of Mule 4 that is in Standard Support so that your applications run with the latest fixes and security enhancements. |
The Cache scope is for storing and reusing frequently called data. You can use a Cache scope to reduce the processing load on the Mule instance and to increase the speed of message processing within a flow. It is particularly effective for these tasks:
-
Processing repeated requests for the same information.
-
Processing requests for information that involve large, non-consumable payloads.
When a message processor in a Mule app sends a message to the Cache scope, the parent flow expects an output. The Cache scope processes the message payload, delivers the output to the parent flow, and saves the output (that is, caches the response). The next time the Cache scope receives the same kind of message payload, the scope can offer a cached response rather than invoking a potentially time-consuming process again.
For instance, you can use a Cache scope to manage customer requests for flight information. Many customers might request the same pricing information about flights from San Francisco to Buenos Aires. Rather than using a lot of processing power to send separate requests to several airline databases with each customer query, you can use a Cache scope to arrange to send a request to the databases fewer times – say, once every ten minutes – and present users with the cached flight pricing information. Where timeliness of data is not critical, Cache scope can save time and processing power.
Note that you can put any number of message processors (such as connectors or components) into a Cache scope and configure the Caching Strategy to store the responses (which contain the payload of the response message) produced by the processing that occurs within the scope.
Caching Process
The Cache scope only caches non-consumable payloads. It does not cache consumable payloads (such as a streaming payload), which can only be read once before they are lost.
In general, the caching process follows this sequence:
-
A message enters the Cache scope.
-
Cache scope determines whether the message payload is consumable.
-
The Cache scope generates a key to identify the message’s payload.
By default, Mule uses an SHA256KeyGenerator and a SHA256 digest to generate a unique key for the message payload. However, you can set up your own key through a Custom Caching Strategy.
-
The Cache scope compares the newly generated key to cached responses that it has previously processed and saves it in the ObjectStore you set up (recommended) or in the default
InMemoryObjectStore.-
If there is no cached response event (a cache miss), the Cache scope processes the new message and produces a response.
It also saves the resulting response in the object store (if the response is non-consumable).
-
If there is a cached response event (a cache hit), the Caching Strategy generates a response that combines data from both the new request and the cached response.
Note that if the generated response has a consumable payload, it does not cache the response.
-
-
The Cache scope pushes the response out into the parent flow for continued processing.
Caching Strategy
A Caching Strategy defines the actions a Cache scope takes when a message enters its sub-flow. By default, the Cache scope uses a Caching Strategy that stores data in an InMemoryObjectStore instead of an ObjectStore. MuleSoft recommends that you only use the default for non-production purposes, such as testing. For production environments, you should set up a Caching Strategy that uses the ObjectStore.
Your Caching Strategy can also reference these customizations:
-
Event Key for the ObjectStore, which is a DataWeave expression or Java object used to create the key to use for storing the payload in the ObjectStore.
-
Response Generator for your strategy, which is a reference to a Java object that is used to create the responses returned by the Caching Strategy.
-
Event Copy Strategy for mutable or immutable data.
Filters
Instead of processing all message payloads that it receives, the Cache scope can exclude specific payloads from the Cache scope flow based on an DataWeave expression.
Example
In Anypoint Studio, you can download and open the example project Cache Scope with Salesforce Contacts from Anypoint Exchange to learn more about how to use the Cache scope. This example caches fetched data from Salesforce. When a query is issued to request the data again, results are returned from cache and a new call to Salesforce is not made.
To download and open this example project while you are in Anypoint Studio, click the Exchange icon in the upper-left corner. Then, in the window that opens, log into Anypoint Exchange and search on the name of the project.