10 ways Mule 4 will make your life easier

By now, you have probably heard a lot about how Mule 4 makes it easier to leverage the power of Mule in your integrations. In fact, many of our customers are already adopting Mule 4––providing great feedback about how they can on-ramp new developers much faster.

But we don’t want you to just take our word for it, so let’s see at 10 quick examples of Mule 4 features in action!

1. Seamless access to data

In Mule 4, we’re leveraging DataWeave not only as a transformation language, but as our expression language as well. This means that you can harness the power of DataWeave in any of your expressions, no matter what component you’re using it in. This is particularly handy when accessing data. Suppose you have a flow in which the following JSON payload is posted through HTTP:

{
	persons: [
		{
			name: "John Doe",
			age: 35
		},
		{
			name: "Jane Doe",
			age: 32
		},
		{
			name: "John Jr.",
			age: 7
		}
	]
}

This is how a Mule 4 flow, which iterates through those persons, looks like:

<flow name="prersons">
	<http:listener path="person" method="POST" config-ref="httpListener" />
	<foreach collection="#[payload.persons]">
		<choice>
			<when expression="#[payload.age > 21"]>
				<logger message="#['$(payload.name) is an adult']" />
			</when>
			<otherwise>
				<logger message="#['$(payload.name) is a minor.']" />
			</otherwise>
		</choice>
	</foreach>
</flow>

So what makes the above features great?

• At no point do you have to worry about the fact the data is in JSON format. Mule figures that out automatically and knows how to access that format. In fact, the exact same flow works in a similar manner even if the data structure was in XML or Java.
• A <foreach> statement can now split records from a JSON array. You no longer need to add transformations just to make sure that <foreach> obtains a Java collection.
• You can leverage DataWeave to access data both in the <foreach> and <choice> components. Again, you are only required to know the structure of the data, never the format.

2. New error handling features

This feature has already been covered at length in this  blog post and you can read more great material about it in the documentation. However, I’d like to focus on not only how the “try..catch” semantics make it easier to deal with errors, but how Anypoint Studio helps you discover possible errors during the design time.

Below, you can see an image of a flow that uses the try scope to deal with different errors in different ways. What’s great is that when you add an error handler, Studio allows you to specify the type of error you’d like to catch. There’s a magnifying glass icon on the right corner, which you can click on to obtain a complete list of all the possible errors for that particular try scope. In the image below, notice how Studio has aggregated the errors from the different connectors, and how self-describing these errors are.

3. Repeatable streaming 

Repeatable streaming is another great feature we added, which we have previously discussed in blog posts and documentation. Repeatable streaming completely hides the concept of streaming from you. You don’t have to know which components perform streaming, or worry about streams being consumed more than once. You don’t even need to know what streaming is at all!

You will no longer need to enable or disable streaming features in connectors like FTP or Database, because Mule will automatically stream whenever it’s applicable. You also don’t need to add <object-to-string> transformers or avoid logging part of your message, as the full content of the stream will always be available––even if it is the stream is consumed in parallel like in the example below:

4. Triggers

Triggers are a new way of starting the execution of your flow. They are Message Sources that have common use cases built-in so that you don’t have to manually build them. For example, suppose you want to poll an SFTP folder for new files. This task would roughly imply that you:

1. Set up a scheduler
2. List the contents of the folder,
3. Process the files, and
4. Move/delete the processed files or update a watermark so that the files are not processed again in the next poll.

There’s a trigger in the new SFTP connector which already does all of the above in one single step, and you can read all about it in the documentation.

Connectors that currently support triggers include the File, FTP, FTPS, Database, and Salesforce connectors––and the list keeps growing!

5. Frictionless upgrades

It was critical for us to make it easy for users to move across versions in this latest release. We achieved this by adding classloading isolation, which ensures that changes in Mule Runtime and a connector’s internal implementations do not affect your application. We also achieved this by decoupling the release cycles of Mule Runtime with those of its modules.

For example, imagine that we release a new version of the HTTP connector with some new feature you’d like to use in one of your applications or a bug fix. Because connectors are now released and versioned separately from the runtime, you can just get the upgrade from Exchange and only update the connector you install. In other words, you will not need to move to an entirely new version of Mule Runtime, which would also impact other connectors and require more sanity checks.

The same logic works the other way around!. Imagine you want to take advantage of a new Runtime capability around management. You can now upgrade the Runtime knowing that all the connectors in your application will not change or require any upgrades.

6. Self-tuning capabilities

Performance and scalability are paramount––regardless of the use case. Mule 4 ships with a brand new execution engine. The reactive and non-blocking nature of this engine make it really scalable, using a short amount of threads.

We also gave the engine the ability to self-tune. You will no longer need to configure thread pools, threading profiles, exchange patterns, and processing strategies in order to get the most out of your flows. With this release, Mule 4 now analyzes runtime conditions and makes adjustments automatically.

7. Simplified message model

The Mule message has been simplified. Besides the payload, there’s now the concept of Attributes, which is a strongly typed object that holds metadata about that payload. For example, if your payload is a file, then the payload will hold the contents of that file, while the Attributes object will hold the file’s path, size, timestamps, etc.

If the message was an HTTP request, then the payload will hold the body, while you’ll find the request path, query params, headers, remote address, etc in the Attributes. All of these changes remove the need for the inbound, outbound, and session scopes in Mule 3, while providing strongly typed data that is easier to deal with and discover. You can find more information about the simplified message model in Part I and Part II of this blog series.

8. New connectors

We completely revamped most of our core connectors. They’re now more powerful and easier to use, and, most of all, they’re consistent. Before we had transport- and operation-based connectors, and now we standardized the latter in order to provide a consistent and predictable experience. This means that if you learn how to use one connector, you will know how to use them all. You can see some examples by looking at the following posts:

• The new Database connector in Mule 4
• The new File connector in Mule 4

9. Simplified enrichment

We also simplified enrichments. Enrichers are useful when you want to execute actions to obtain a new piece of data, but you want to do so without losing the data you already have in your payload. To make this easy, Mule adds a target parameter to all operations which return data. You can use this parameter to redirect the output of that operation to a variable of your liking––preserving all other data in your current message. You can apply enrichers not only to connector operations, but to <flow-ref> as well. For example:

<flow name="getStockInfo">
	<http:listener path="stock" method="GET" config-ref="httpListener">
		<http:response>
			<http:body>
				<![CDATA[
	                %dw 2.0
	                output application/json
	                ---
	                {
	                    "ticker": attributes.queryParams.ticker,
	                    "price": vars.price as Number,
	                    "variation": vars.variation as Number
	                }
        		]]>
			</http:body>
		</http:response>
	</http:listener>
	
	<http:request path="price" config-ref="httpRequester" target="price">
		<http:query-params>#[{'ticker': attributes.queryParams.ticker}]</http:query-params>
	</http:request>

	<http:request path="variation" config-ref="httpRequester" target="price">
		<http:query-params>#[{'ticker': attributes.queryParams.ticker}]</http:query-params>
	</http:request>	
</flow>

10. Migration tools

We also want to make the migration to Mule 4 as easy as possible. We recently announced the Beta release of the DevKit Migration Tool. This tool makes it really easy to migrate a Mule 3 DevKit project into a Mule SDK project that can be used with Mule 4. We’re proud to announce that the tool is now officially GA. Please check out the documentation for more information and instructions.

We’re also really happy to announce that a Mule 3 to Mule 4 migration tool will be available soon. This tool will take a Mule 3 application and transform it into a Mule 4 application. Although this tool will be able to automatically migrate a large number of use cases, it won’t be able to migrate everything.

The tool will generate a migration report, which will give users clear insights into all components that could not be migrated automatically. At the same time, the tool will also provide clear instructions on how to complete the migration yourself.

Conclusion

Overall, making Mule easier to use and learn was the driving principle of this release. Join the customers that are already taking advantage of these improvements by trying Mule 4 today!