Introduction of Mule 4 and Anypoint Studio 7 Beta
Mule 4 has to deliver on new innovations while keeping all the things users love about Mule 3.
Join the DZone community and get the full member experience.Join For Free
Mule 4 Overview
Mule 3 achieved amazing popularity in the last 7 years since 3.0 was released. It has a community of over 175,000 developers. As we started planning Mule 4, we really went back to the fundamentals of how to make your life easier. Mule 4 has to deliver on these innovations while keeping all the things users love about Mule 3. Some of the Mule 4 new features are summarized below:
- Simplified core concepts and language
- Transparent data access and streaming
- Non-blocking, self-tuning runtime
- Simplified error handling and introduced a new ‘Try’ scope
- Frictionless upgrades
- Revamped core connectors such as FTP, File, Email, and JMS
- Improved palette user experience, including the ability to save favorites
- Holistic Exchange experience, making APIs and Mule connectors/modules more accessible
- Palette is totally changed. Now you can also set your favorite components. If you not able to find any component, you can download it from exchange.
- Quick navigation between the flow and XML.
- All mule projects now integrated with maven. Every project has pom.xml
- Mule message only contains two things. Payload and attributes.
- No payload transformation (Object to JSON, Object to String etc.) is required now, It is automatically taken care by Mule.
- MEL expression is totally replaced by dataweave 2.0
- All the flows are now collapsible.
- Mule 4 has .jar deployable archive.
- Improved metadata support, making it easier to commit and merge
Making Core Concepts Easier
Message structure got changed in Mule 4. The Mule 4 Message can hold payloads and attributes. The payload is the main thing being processed — HTTP body, file contents, etc. Attributes are the metadata about the payload.
Message collections now are much simpler — they’re just an array of Messages. This means you can easily transform them or store them in a variable.
Embedded Enricher — for any given connector/module operation, it is now possible to define a target, which saves the result directly in a variable. No need for enrichers anymore.
Transformations can be embedded directly in connector operations, removing unnecessary steps in your flow or the need to put data in temporary variables.
Self Tuning in Runtime — Non-Blocking
Each Mule event processor can now inform the runtime if it is a CPU intensive, CPU light, or IO intensive operation. This allows the runtime to self-tune for different workloads dynamically, removing the need for you to manage thread pools manually.
Modified Error Handling Mechanism and New "Try" Scope
Mule Modules and Connectors declare what errors may occur for any given operation. This makes it easy for you to discover possible errors at design time and catch them. Exception strategies are replaced by error handlers, allowing you to catch errors based on both type and arbitrary expressions. You can configure your error handlers to catch errors so that the flow can keep processing.
There is also a new "try" scope, which allows you to catch errors in the middle of a flow — without having to create a new flow — specifically to catch that error.
In Mule 3, if you were using Mule’s internal Java libraries, this could be difficult, as libraries often changed from release to release. In Mule 4, there is classloader isolation between your application, the runtime, and connectors so that any library changes that happen internally will not affect your app.
Opinions expressed by DZone contributors are their own.