Flow References and Properties
|
Not to be confused with a Flow Reference Component. This article is meant to present the properties of a flow and how it is represented in XML and on the visual editor. |
Flow properties
Flows have three different properties:
name
A mandatory nonBlankString value that is used to identify the Flow.
The name value will be used to reference the flow within your application.
processingStrategy
Determines the strategy used to process the configured message processor that starts the flow. This attribute accepts either one of the enumerated strategies with default configuration options or a reference to a globally defined strategy.
-
synchronous
Use a synchronous model as a processing strategy. This allows you to handle messages in the same thread where they are received.
This property is fully explained in the processing strategy settings page and on its specific section in the Flow and subflows page. -
asynchronous
Use an asynchronous model as a processing strategy. An asynchronous flow will handle a message every time it gets triggered by another flow and can process it simultaneously with its triggering flow since it does not need to return any value to it.
This property is fully explained in the processing strategy settings page and a detailed example of how an asynchronous processing strategy works can be found in its specific section within the Flow and subflows page. -
non-blocking
Use an evented non-blocking model as a processing strategy. This enables for both request and response phases to be executed in different threads.
A more detailed explanation of how this property works within Mule can be found in the processing strategy settings page. -
queued-asynchronous
Use a queue-managed receiver model as a processing strategy. It places a queue that separates the flow’s receiver from the rest of the steps in the flow through a VM transport component.
A more detailed explanation of how this property works within Mule can be found in the processing strategy settings page. -
thread-per-processor
Use a thread-per-processor model as a processing strategy. Although it does not apply to most use cases, this strategy simply runs every processor in the flow’s scope in a new thread. -
queued-thread-per-processor
Use a queue-managed model to your thread-per-processor strategy. This strategy does not apply to most use cases, but in essence simply posts a message in a queue and then each processor in the flow’s scope runs in a new thread.
initialState
The initial state of the flow.
There are two available options for this property: started and stopped
Usually a flow is "started" automatically and has this value set by default, but this attribute can be used to disable initial startup by setting this property to "stopped".
|
You can define a "stopped" initial state in order to pause a flow until certain event triggers it. |
Subflows
A subflow is a chain of message processors processed synchronously that can be referenced and reused through a Flow Reference Component.
A flow can reference several subflows to complete synchronous processing tasks, and a subflow can have several triggering flows.
The only property that a subflow node can take is name. This is a mandatory nonBlankString value that is used to identify the subflow in order to reference it from your flow reference component.
XML Editor or Standalone
A representation of a subflow in XML looks something like this.
<flow name="mainFlow">
<flow-ref name="subFlow" doc:name="Flow Reference"/>
</flow>
<sub-flow name="subFlow">
</sub-flow>Note that the Flow Reference connector points to the sub-flow node named subFlow.
See Also
-
NEXT STEP: Learn about Flow Processing Strategies.