Object Store in Mulesoft

Overview

Object Store in MuleSoft is a built-in storage mechanism that allows applications to store and retrieve data in a key-value format. It is particularly useful for persisting states, caching data, managing synchronization across flows, and handling information that needs to survive beyond a single message processing. MuleSoft provides both an in-memory store (for short-lived, transient data) and a persistent store (for long-lived data that remains available even after application restarts).

With Object Store, developers can easily implement patterns such as idempotent message processing, distributed throttling, and session tracking without the need for an external database. MuleSoft also offers Object Store v2 (OSv2), a fully managed cloud service that provides scalable, persistent, and encrypted storage for Mule applications running on CloudHub.

In short, Object Store simplifies state management within integrations, making it easier to build reliable, fault-tolerant, and high-performing MuleSoft solutions.

Implementation

Create a Mule project with name ‘object-store-demo‘ and add ‘Object Store‘ module into your project.

• Once the ObjectStore module is added to your Mule project, the first step is to configure a Listener. Drag and drop the Listener component from the HTTP module onto your flow.
  Next, configure the connector:
  • Path: Set the path as /store. This ensures that your Mule flow will be triggered whenever an HTTP request is sent to the /store resource.
  • Allowed Methods: Navigate to the Allowed Methods section and set it to POST. By doing this, your flow will only accept POST requests for the /store endpoint.This configuration essentially establishes the entry point for your Mule application, ensuring that only valid POST requests to /store will invoke the flow.
• Once the HTTP Listener is ready, the next step is to save some data into the Object Store. For this, simply drag the Store operation from the Object Store module into your flow. In the configuration, set the key as attributes.queryParams.osKey and the value as attributes.queryParams.osValue. What this does is pretty straightforward — whenever a request comes in, Mule picks up the osKey and osValue from the query parameter and store it into the ObjectStore,.
• We need to return http response so drag ‘Transform Message’ and set the output payload to below

  %dw 2.0
  output application/json
  ---
  {
  	"Message":((attributes.queryParams.osKey default "Key") 
      ++ " is stored in Object Store with value " ++ 
   (attributes.queryParams.osValue default "Value"))
  }

We first created a flow that retrieves the key and value from the request query parameters and stores them in the Object Store. Now, we’ll add another flow that looks up the value for a given key and returns it to the client.

• Drag and drop the Listener component from the HTTP module onto your flow.
  Next, configure the connector:
  • Path: Set the path as /retrieve. This ensures that your Mule flow will be triggered whenever an HTTP request is sent to the /retrieve resource.
  • Allowed Methods: Navigate to the Allowed Methods section and set it to GET. By doing this, your flow will only accept POST requests for the /retrieve endpoint. Mule application, ensuring that only valid GET requests to /retrieve will invoke the flow.
• Drag ‘Retrive’ step from the ObjectStore module and set the Key to attributes.queryParams.osKey and Default Value to ‘No Such Key available in the ObjectStore’.

If you have followed everything step by step now your code should look like below else you can also copy and paste the xml content into the ‘Configure XML’ section of your mule flow.

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

<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core" xmlns:os="http://www.mulesoft.org/schema/mule/os"
	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/os http://www.mulesoft.org/schema/mule/os/current/mule-os.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd">
	<http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener config" doc:id="3e4f0865-f792-4cf8-9e32-a0052dcb8fe5" >
		<http:listener-connection host="0.0.0.0" port="8081" />
	</http:listener-config>
	<flow name="object-store-demoFlow" doc:id="4ffb425e-7161-4905-9b2c-2ed20111c6cb" >
		<http:listener doc:name="Listener" doc:id="569440d8-6c3a-4162-91f2-ba105a159a7e" config-ref="HTTP_Listener_config" path="/store" allowedMethods="POST"/>
		<os:store doc:name="Store" doc:id="6b1f918a-3dc1-45b1-8eaf-16b0f4f76a9f" key="#[attributes.queryParams.osKey]">
			<os:value ><![CDATA[#[attributes.queryParams.osValue]]]></os:value>
		</os:store>
		<ee:transform doc:name="Transform Message" doc:id="fa03605e-21fe-4704-bab1-1c4743f9d6fe" >
			<ee:message >
				<ee:set-payload ><![CDATA[%dw 2.0
output application/json
---
{
	"Message":((attributes.queryParams.osKey default "Key") 
    ++ " is stored in Object Store with value " ++ 
 (attributes.queryParams.osValue default "Value"))
}]]></ee:set-payload>
			</ee:message>
		</ee:transform>
	</flow>
	<flow name="object-store-demoFlow1" doc:id="48e220cd-e9eb-4aee-86f5-8e0ff0f04463" >
		<http:listener doc:name="Listener" doc:id="ddcacfba-c3a7-4820-8722-68e413efe05d" config-ref="HTTP_Listener_config" path="/retrieve" allowedMethods="GET"/>
		<os:retrieve doc:name="Retrieve" doc:id="2c6a5b4e-1aea-454b-ba59-f5f164cc8652" key="#[attributes.queryParams.osKey]">
			<os:default-value ><![CDATA[No Such Key available in the ObjectStore]]></os:default-value>
		</os:retrieve>
	</flow>
</mule>

Storing a Value (POST Request)

To save data to the ObjectStore, you’ll make a POST request. Think of this as adding a new entry.

• URL: http://localhost:8081/store?osKey=A&osValue=C

When you send this request, the system stores the key A and its associated value C. It’s that simple!

Retrieving a Value (GET Request)

To get data back from the ObjectStore, you’ll make a GET request. This is how you look up a specific entry.

• URL: http://localhost:8081/retrieve?osKey=A

This command will retrieve the value for key A from the store. If the key exists, the response will be C.

If you try to retrieve a key that hasn’t been stored, like osKey=B, the system will respond with a helpful message: “No Such Key available in the ObjectStore.”

Now we can conclude that the Object Store is Persistent by default, but the next question is — where exactly is this data being stored? To check this, go to the Console tab in Anypoint Studio and scroll all the way to the top. There, you’ll find the Mule Home directory, as shown below.

Navigate to your Mule Home directory and you’ll find a folder named .mule. Inside this folder, all your Mule projects are listed. Open your project’s folder and you’ll see an objectstore directory. This is where Mule stores the key-value pairs for your Object Store.

If you stop the mule project and delete these files from backend and restart the mule project , you won’t be able to retrieve the key value pairs that you have stored before.

In-Memory ObjectStore

You can create exactly same mule flow or let’s change this flow itself to make it In-Memory.

• Click on the ObjectStore ‘store’ step and in  the properties click on the plus icon right to ‘Object store’ 
• This will open a popup to configure the Object Store.
• In the name field give the ObjectStore a name.
• Uncheck the Persistent to make it In-Memory.
• Additionally, you can configure the maximum number of key-value pairs allowed in the Object Store, as well as set a time-to-live (TTL) for each entry. One important thing to note is that if the maximum entry limit is reached, the Object Store will automatically remove the oldest entry to make room for the new one.
• You can also configure expiry based on your requirement.
• We’ve configured the Object Store to save the key-value pairs, we also need to make sure the Retrieve step points to the same store in order to fetch the values. To do this, click on the Retrieve step and, in the properties panel, select the appropriate Object Store.

Once you are done with the configuration your mule configuration XML should look like below.

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

<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core" xmlns:os="http://www.mulesoft.org/schema/mule/os"
	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/os http://www.mulesoft.org/schema/mule/os/current/mule-os.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd">
	<http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener config" doc:id="3e4f0865-f792-4cf8-9e32-a0052dcb8fe5" >
		<http:listener-connection host="0.0.0.0" port="8081" />
	</http:listener-config>
	<os:object-store name="Object_store" doc:name="Object store" doc:id="a859a6a1-3b03-48be-ad83-8cd08b32b5ae" persistent="false" />
	<flow name="object-store-demoFlow" doc:id="4ffb425e-7161-4905-9b2c-2ed20111c6cb" >
		<http:listener doc:name="Listener" doc:id="569440d8-6c3a-4162-91f2-ba105a159a7e" config-ref="HTTP_Listener_config" path="/store" allowedMethods="POST"/>
		<os:store doc:name="Store" doc:id="6b1f918a-3dc1-45b1-8eaf-16b0f4f76a9f" key="#[attributes.queryParams.osKey]" objectStore="Object_store">
			<os:value ><![CDATA[#[attributes.queryParams.osValue]]]></os:value>
		</os:store>
		<ee:transform doc:name="Transform Message" doc:id="fa03605e-21fe-4704-bab1-1c4743f9d6fe" >
			<ee:message >
				<ee:set-payload ><![CDATA[%dw 2.0
output application/json
---
{
	"Message":((attributes.queryParams.osKey default "Key") 
    ++ " is stored in Object Store with value " ++ 
 (attributes.queryParams.osValue default "Value"))
}]]></ee:set-payload>
			</ee:message>
		</ee:transform>
	</flow>
	<flow name="object-store-demoFlow1" doc:id="48e220cd-e9eb-4aee-86f5-8e0ff0f04463" >
		<http:listener doc:name="Listener" doc:id="ddcacfba-c3a7-4820-8722-68e413efe05d" config-ref="HTTP_Listener_config" path="/retrieve" allowedMethods="GET"/>
		<os:retrieve doc:name="Retrieve" doc:id="2c6a5b4e-1aea-454b-ba59-f5f164cc8652" key="#[attributes.queryParams.osKey]" objectStore="Object_store">
			<os:default-value ><![CDATA[No Such Key available in the ObjectStore]]></os:default-value>
		</os:retrieve>
	</flow>
</mule>

Start the Mule project and try invoking the endpoints to store and retrieve key-value pairs. Then, restart the Mule project and attempt to retrieve the value you stored earlier. You’ll notice that the key-value pair no longer exists, which confirms that this is an In-Memory Object Store.

How ObjectStore work when we deploy Mule App in CloudHUB

When you deploy a Mule application to CloudHub, MuleSoft provisions a dedicated worker, which is essentially a lightweight virtual machine that runs both the Mule Runtime and your application. Each worker comes with its own allocated CPU, memory, and storage based on the worker size you choose. When you restart or redeploy the application, the worker is re-initialized, and in many cases, MuleSoft spins up a new instance behind the scenes. This means that any in-memory data or local file system storage is lost after a restart even if persistent ObjectStore is configured.

To resolve this issue, Mule provides ObjectStore V2, a fully managed, persistent, and highly available storage service. Unlike in-memory or local storage, ObjectStore V2 is external to the worker, which means the data you store is not tied to the lifecycle of the application instance. Even if the worker restarts or a new instance is created, your key-value pairs remain intact in ObjectStore V2. This ensures that applications can reliably store and retrieve stateful information, such as tokens, user sessions, or configuration data, across restarts, redeployments, and scaling events in CloudHub.

When deploying a Mule application to CloudHub, you’ll see an option called “Use Object Store V2”. If you check this option during deployment, your application will take advantage of the full flexibility of ObjectStore V2. If you leave it unchecked, the application will instead use the default in-memory ObjectStore.

Click here to clone the code from GitHub