Private vs. Sub Flow in Mule

Mule has the concept of Private and Sub flows. In this article, both of them will be discussed.

Sub Flow

A subflow is a normal flow without any message source. Here is how it looks in XML configuration.

<sub-flow name="subFlow">
        <scripting:component doc:name="Groovy">
            <scripting:script engine="Groovy"><![CDATA[throw new Exception("Sub Flow Exception");]]></scripting:script>
        </scripting:component>
</sub-flow>

A subflow can be called by the flow-reference element of Mule. When the main flow (calling) calls the subflow using the flow-reference element, it passes the whole message structure (message properties, payload, attachments, etc) and the context (session, transaction, etc). In the same way, when the processing of the message is done in the subflow, the complete message and context are returned to the main calling flow. In other words, everything in the subflow behaves as if it were in the same flow. It's important to note that the message is executed in the same thread.

Usage

Subflows can be used when some block of code (components) can be reused across the application and you don't want to handle the exceptions of the subflow separately from the main calling flow.  

Private Flow

Private flows are same as standard flows without the message source. They can also be called using the flow-reference element. This is how it looks in XML configuration:

 <flow name="privateFlow" processingStrategy="synchronous">

 </flow>

Private flows are different from subflows in terms of Threading and Exception Handling. They have their own Exception Handling. The exception will be trapped by the local Exception Handling and it will not be propagated to the main flow. It means that if an exception occurs in a Private flow and it is handled properly when the call goes back to the main calling flow, the next message processors continue executing. 

Private flows also receive the same message structure from the main calling flow. But Private flows create a new execution context.

Conclusion 

To summarize, subflow is always recommended, except when the exception needs to be handled in a separate exception handling flow different from the main flow or if you are implementing an asynchronous pattern.