Caching in Mule

by

Overview

Contents hide
1 Overview
2 Why caching is needed?
3 Scenario for Understanding
4 Implementation

Caching in Mule is a mechanism that helps improve performance and efficiency by temporarily storing frequently accessed data so that it can be reused without making repeated calls to external systems or services. Instead of invoking a backend API, database, or service every time a request comes in, Mule can store the response in ObjectStore and return it directly for subsequent requests.

This reduces the number of redundant network calls, saves processing time, and enhances the overall throughput of the integration flows. Mule provides the Cache Scope to implement caching seamlessly in its applications.

Why caching is needed?

  • Performance Optimization: Avoids repeated calls to slow or resource-intensive systems.
  • Reduced Latency: Clients get faster responses since data is served directly from the cache.
  • Cost Efficiency: Minimizes calls to paid APIs or cloud services, reducing operational costs.
  • Resource Management: Reduces the load on backend systems, preventing performance bottlenecks.

Caching is particularly useful in scenarios where data does not change frequently and can safely be reused for a period of time.

Scenario for Understanding

Imagine you have a Mule application that fetches currency exchange rates from an external API. If hundreds of users request conversion rates every second, Mule will repeatedly call the API, leading to unnecessary overhead and possible throttling by the provider.

Instead, you can use Cache Scope to store the exchange rate response for, say, 10 minutes. During that time, any request for exchange rates will be served directly from the cache. Once the cache expires, Mule will fetch fresh data from the API again and update the cache.

This approach ensures:

  • Faster response times for end users.
  • Reduced number of calls to the external exchange rate API.
  • Optimized use of resources within the integration layer.

Implementation

As part of this cache implementation we will be connecting to MySql database to extract employee information so execute below sql queries in your mysql environment to create employee table and insert few employee information.

create database mulesoft_dev;

use mulesoft_dev;

CREATE TABLE employee (
    emp_id INT PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50),
    department VARCHAR(50),
    salary DECIMAL(10,2),
    hire_date DATE
);

INSERT INTO employee (emp_id, first_name, last_name, department, salary, hire_date) 
VALUES 
(1, 'John', 'Doe', 'IT', 60000.00, '2020-05-15'),
(2, 'Jane', 'Smith', 'HR', 55000.00, '2021-01-10'),
(3, 'Michael', 'Brown', 'Finance', 75000.00, '2019-11-23'),
(4, 'Emily', 'Davis', 'Marketing', 50000.00, '2022-07-01'),
(5, 'David', 'Wilson', 'IT', 65000.00, '2018-03-12');



select * from employee;
    • Open you Mulesoft Anypoint studio and create a mule project with name ‘cache-demo‘.
    • We will connect to a MySQL database and implement caching using ObjectStore to store the data. For this, we need to add both the Database module and the ObjectStore module to the project. To do this, open the Mule Palette, click Add Module, and then add the Database and ObjectStore modules to your project.
    • Create new ‘Mule Configuration File‘ and name it ‘global-config‘, in this file we will manage the database connection configuration and caching configuration.
    • Open the ‘global-config‘ file and navigate to ‘Global Elements‘ tab.
    • Click on ‘Create‘ button and serch for ‘Database Config‘ and follow below video to configure the MySql connection.
    • For caching, we need to create ‘Caching Strategy‘ so follow the below video for the implementation.
    • In ‘global-config‘ , again click on create and search for http listener and keep everything as default and click save until you want to choose different port and base path.
    • Open the cache-demo Mule configuration file. Drag and drop an HTTP Listener onto the Mule canvas, then select the connector configuration as Http_Listener_config and set the Path to /cachedemo, navigate to the Advanced tab and set the Allowed Methods to GET.
    • Drag ‘select‘ step from the ‘Database‘ module into the canvas and configure below to extract employee information from database using employee id.
      Database select in Mule
    • Now drag and drop transform message step into canvas and set the output payload as below to convert the output payload as json.
      %dw 2.0
output application/json
---
payload
    • Run the Mule project and invoke the URL http://localhost:8081/cachedemo?empID=1. You will see the result as a JSON response in the body. If you make any changes in the employee table and invoke the same endpoint again, you will see the updated result reflected in the response.
    • Now we need to store the database result in to cache so follow below video to implement caching and testing it. 

    • While configuring the caching strategy, we set the key as attributes.queryParams.empID. This means the employee ID will be used as the key to store the payload in the ObjectStore.

      If you change the empID while invoking the API, the response will be fetched from the database and then cached. However, if you update the employee information for the same empID, the response will still be served from the cache and not from the database until the cache entry expires or is refreshed.

    • If you want to clear the cache, you can delete the ObjectStore data in the same way we did in the earlier article, which you can find here.
    • If you have followed everything step by step then your mule flow will look like below if not you can use below xml to create your flow.

      <?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core" xmlns:db="http://www.mulesoft.org/schema/mule/db"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/db http://www.mulesoft.org/schema/mule/db/current/mule-db.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd">
	<flow name="cache-demoFlow" doc:id="5bbfde7e-cd28-4d77-9217-a6f23f91c7b3" >
		<http:listener doc:name="Listener" doc:id="b2adaca6-efa7-4e9d-9569-41bc0758b99f" config-ref="HTTP_Listener_config" path="/cachedemo" allowedMethods="GET"/>
		<ee:cache doc:name="Cache" doc:id="47bb3d72-475e-4124-bf6f-a4de7925060f" cachingStrategy-ref="Caching_Strategy">
			<db:select doc:name="Select" doc:id="246cefe7-1942-4e7a-8797-a1f698e2c28f" config-ref="Database_Config">
			<db:sql><![CDATA[select * from employee where emp_id = :empID]]></db:sql>
			<db:input-parameters><![CDATA[#[{
	empID: attributes.queryParams.empID
}]]]></db:input-parameters>
		</db:select>
		</ee:cache>
		<ee:transform doc:name="Transform Message" doc:id="d3ceb79d-ada7-4d71-894b-237560f184c0" >
			<ee:message >
				<ee:set-payload ><![CDATA[%dw 2.0
output application/json
---
payload]]></ee:set-payload>
			</ee:message>
		</ee:transform>
	</flow>
</mule>

       

Post Views: 45

Leave a Comment