Showing posts with label MuleSoft. Show all posts
Showing posts with label MuleSoft. Show all posts

Thursday, July 27, 2017

VM connector in the flow

VM connector creates a transport barrier in the flow: 

In a transport barrier, your Mule message goes through an entire serialization and deserialization process which results in a new Mule message with the same payload. 

Read about the effect of transport barrier on a mule message here.

When one would prefer to use a VM transport over a flow reference?


One case would be that VM endpoints enable message redelivery strategies to be configured in your exception handling blocks – this is not possible with flow-refs. 

VMs can do this because they internally use a queue to hold messages while flow-refs are similar to simple method calls.

Difference between flow, sub flow and private flow in MuleSoft

All three Flow types can be referenced from a Flow Reference component.

Flow is a message processing block that has its own processing strategy and exception handling strategy. Used in integration tasks, data processing, connecting applications, event processing, etc.

Subflow always processes messages synchronously but inherits processing strategy and exception handling strategy from the calling flow. It can be used to split common logic and be reused by other flows.

Private flow does not have source define. It can be synchronous or asynchronous based on the processing strategy selected. Also, they have their own exception handling strategy. Allows you to define different threading profile.

====

Processing strategy
While sub-flow is always synchronous the private flow behavior depends on the processing strategy
Performance
Sub-flow has a better performance when using request-response exchange pattern as they are actually a new processor chain injected in the flow at configuration time. Private flows are instead useful for asynchronous call provided you configured their processing strategy properly
Exception strategy
Private flow: the exception will be trapped by the local ES the exception will not be propagated to that main flow.
Sub-flow: will use the exception strategy defined in the main flow and it will have the exception got in the sub-flow.
Message Properties
In both case all properties, regardless their scope, are preserved from the main flow.
Threading profile
Private flows: allows you to define a different threading profile, but if you don't they will use the default one, not inherit the invoking flow one 
Sub-flows: they will share the parent flow threading profile configuration
Overall
Sub-flows run within the same execution context (exception handler, transaction, properties) of its main flow, while private flow will initiate a new execution context.
To summarize, sub-flow is always recommended except in the case the exception needs to be handled in a separate flow different from the main flow or you are implementing an asynchronous pattern

AnyPoint Studio 7 Beta


 These are some of new features and improvements in Studio 7 beta:

* Improved palette which enables users to more quickly discover what they’re looking for by searching directly for operations and saving favorites.
* Users can now explicitly manage which connectors and modules are associated with a project.
* Connectors and modules are now managed directly by Anypoint Studio, and do not require users to manage update sites.
* Easily navigate to code from visual view by right clicking on a component and clicking “View XML”
* Maven is now embedded out of the box inside Studio. Additionally, every project now has a Maven POM, making it easier to incorporate projects into CI/CD systems.
* Flows and scopes are now collapsable.
* Updated icons make flows easier to read.
* DataSense metadata is now stored in a human readable format this is easier to share, commit and merge.
* Support for importing API specifications from Design Center
* Improved user experience for connector and modules
* Simplified experience to manage credentials when logging into the Anypoint Platform