Whether you are just starting out or you’re an experienced MuleSoft developer, getting the flows right in your Mule application can be complicated and difficult. A proper understanding of the types of flows and how the scope of variables and attributes changes depends on the way flows are invoked is essential to building functional Mule applications.
This blog will walk you through the types of flows, behavior with the scope of attributes, payload, and variables.
Introduction to flow types in Mule
A Mule event contains the core information processed by the runtime. It travels through components inside your Mule app following the configured application logic. A Mule event consists of three components — payload, attributes, and variable — as shown in the figure below.
A Mule message contains a message payload and its associated attributes. Variables are Mule event metadata that you can use in your flow. A Message source, such as the Scheduler, HTTP Listener, or On New or Updated File component, triggers the generation of a Mule event and dispatches that event to the flow.
In order to understand the scope of variables across the flows, we first need to review the three types of flows based on the source, processor, and error-handling sections. The table below summarizes the types of flows:
Each flow must have at least one processor unit.
Flow(Public flow) is a message processing block that has its own processing and exception handling. This flow is typically used in connecting applications, data and event processing etc.
Subflow inherits processing strategy and exception handling strategy from the calling flow. Subflows are used to modularize the overall design of the Mule application,
Private flow has their own exception handling strategy which allows you to define different threading profiles.
All three can be referenced from a flow-reference.
Calling and observing Mule flows
To understand the working of Mule flows, consider these four scenarios that use the flow reference component to call different flows. The state of attributes, payload, and variables will be the focus parameter in each case. The key below explains the terminology used to describe the state of each.
Now that you understand the types of flows, let’s review the following four scenarios to observe the scope of variables and attributes as they navigate across flow invocations.
Calling Sub Flow from Public Flow
The first scenario is calling the sub flow from public flow using a flow reference component. The table below summarizes the observations:
Note that the Sub_Flow-2 attributes, payload, and variables are returned to the Public_Flow-2 and are accessible there.
Calling Private Flow from Public Flow
Using flow reference component, the Public_Flow-2 now calls private_Flow-2 as shown in the image above. The table below summarizes the observations:
The attributes of the event this time remain unchanged throughout the parent flow and the child flow. However, the payload and variables are modified because of the Set Payload and Set Variables components in the private flow.
Calling Sub Flow from Private Flow
Building upon scenario two, the attributes, payload, and variables are now passed to the Sub_Flow-2 as the private flow calls the sub flow using flow reference component.
The modified attributes, payload, and variables are returned to the private flow from where the event moves to the Public_Flow-2. Note that the private_Flow-2 was called from the Public_Flow-2 and the Sub_Flow-2 was called as a part of the private_Flow-2.
Calling Public Flow from another Public Flow
The last scenario in this Mule application is the calling of Public_Flow-A from the Public_Flow-2. The observations are as follows:
The attributes, payload, and variables from Public-Flow-A are returned to the Public_Flow-2, from where the application reaches the complete execution.
Calling a child flow via an HTTP request
When passing from parent flow to child flow using HTTP Request, attributes, and payload are passed to child flow but variables are not passed as HTTP request has only attributes and payload in its body. As a variable is not passed, it cannot be accessed or modified from child flow. When the call is returned to the parent flow, new attributes, modified payload, and variable (which was not passed to child flow) can be accessed and modified in the parent flow.
Summary
The major difference between a flow reference component and the HTTP request is that the latter does not pass variables to the child flow. A flow reference component allows attributes, payload, and variables to be accessed in the child flow. Therefore, any modifications in the payload and variables in the child flow are also reflected in the parent flow. For additional details, refer to the documentation.
