Mule 4 Variables by Scope
Mulesoft lexicon uses the term “Variable” in multiple ways. This blog explores the scope and persistence of store locations in Mule 4.
PREAMBLE
The other day while researching a Mulesoft coding problem with google I noticed that among the top results that came was “Mule 4 Variable Scope”. I thought this was odd at first but then I realised that the Mulesoft nomenclature uses the term “variable” in different contexts and possibly causing confusion regarding their traits and scope.
This blog was written to outline the different value store locations in Mule. It is suitable for beginners getting familiar with Dataweave, the Mule Message Structure and Mule Flows or those experienced wanting a refresher.
INTRODUCTION
In Mule lexicon, each variable is classified by its scope. They are:
- DataWeave Variables
- Mule Application Variables
- Object Store Key-Value Pairs
DATAWEAVE VARIABLES
These are the variables you define in your DataWeave scripts. They persist only during the execution of the script and cannot be referred to in later message processors. Furthermore they are immutable and the Value cannot be changed once set to a Key.
Example
Suppose we have the following flow:
Here we have the Transform Message processor creating local (defined in the script body, i.e num2) and global (defined Variables: in the script header, i.e num1) DataWeave
These variables exists solely within the execution of this script and are not added to the Mule Message structure.
MULE APPLICATION VARIABLES
These variables persist to the application for the lifetime of the event. They can be shared between flow references but not when crossing transport boundaries (eg when calling another Mule application via HTTP). Just like DataWeave variables, Mule Application Variables are technically immutable. However, they can be updated as behind the scenes the Variable is recreated with the new value.
Example
Suppose we have the following flow:
Here we have the Set Variable message processor creating an Application Variable:
This then gets put into the Variables section of the Mule Message Structure:
Note: Sometimes you may see these referred to as “Message Flow” variables. This is a misnomer as these variables can persist between different flows through flow reference calls. Thus, their scope is not limited to a Message Flow but an application.
OBJECT STORE KEY-VALUE PAIRS
Though not called variables, these are similar as they act as storage locations. They are set and retrieved by using the Object Store connector (for Cloudhub deployments) or the REST API (for Cloudhub or On-Premise deployments).
Example
Suppose we have the following flow:
Here we have he Retrieve processor retrieving the value of a specified key:
You can further choose where you want to store this value in the Mule Message Structure, either setting it as the payload (as per below) or as its own variable. In this way, Object Store objects can created as variables in the Mule Message structure.
CONCLUSION
Mule have created variable types that align with specific scopes. In this way variables can cross Script, Message Flow and even Application boundaries. Hopefully this blog has made all these distinctions clear.
Get in contact to book a workshop to see how Syntegrity can help you.
Keshav Bhrugubanda is an Integration Consultant at Syntegrity Solutions certified as a Mulesoft Developer.