Introducing Mule 4 and Anypoint Studio 7 Beta

July 26 2017

19 comments 0
mule 4

Today, we released Mule 4 beta, which adds vastly more power, higher speeds, and greater simplicity into the famously small footprint of Mule – the industry’s leading all-purpose engine for building application networks. I couldn’t be more excited.  With Mule 4, we’ve delivered a simplified language for connectivity, transparent data access and streaming, automatic performance tuning and smoother upgrades. It’s a major evolution of the core runtime of Anypoint Platform.

Why Mule 4?

Mule 3 achieved amazing popularity in the 7 years since 3.0 was released. It is used by over 1100 enterprise customers located in more than 60 countries across every major industry, and has a community of over 175K developers. So, as we looked to Mule 4, we knew it needed to live up to Mule 3’s strong reputation.

As we started planning Mule 4, we really went back to the fundamentals of how to make your life easier. How do we make Mule even easier to use? How do we simplify common tasks? How do we ensure the runtime runs at its best, without manual tuning? And how do we reduce long-term maintenance costs by simplifying operations and upgrades?

Mule 4 has to deliver on these innovations, while keeping all the things users love about Mule 3 – including its lightweight runtime and extensibility. With this release, whether you’re a new user, or long time Muley, I think you’ll see that it delivers.

So, how did we do this? We’ll be doing a series of in-depth blog posts on Mule 4 features and benefits, but I’ll summarize the highlights here:

  • 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

We’ve also put significant work into our tooling around Mule. With Mule 4, there’s a new release of Studio 7 which introduces many new improvements:

mule palette

  • Improved palette user experience, including the ability to save favorites
  • Holistic Exchange experience, making APIs and Mule connectors/modules more accessible
  • Deeper Maven integration
  • Quick navigation between XML and visual views
  • Collapsable scopes
  • Improved metadata support, making it easier to commit and merge

Alright, so let’s get into more of the details!

Simplified core concepts and language

We’ve evolved the core language to make it easier to learn and do common tasks:

  • Mule 4 introduces a simplified Event and Message model. 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 – query parameters, file size or last modified date. Messages simplify many common tasks since you can now save not just the payload, but also attributes in variables.
  • 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.
  • Enrich in fewer steps – 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.
  • All connectors now follow the same model of operations and connector configurations
  • Revamped File, FTP, JMS, and Email connectors
  • Transformations can be embedded directly in connector operations, removing unnecessary steps in your flow or the need to put data in temporary variables.

mule 4

Transparent data access and streaming

There are incredible improvements in the way that Mule 4 enables you to process, access, transform and stream data. First, DataWeave is now the expression language in Mule 4. Combined with the new automatic streaming capabilities, this simplifies many common tasks:

  • Events can be routed based on payload data, without first needing to convert to Java objects.
  • Binary data can easily be queried from an expression anywhere in your flow (i.e. when logging).
  • Larger than memory access to data happens transparently.
  • Data can be read multiple times or accessed randomly with the DataWeave expression language without side effects.
  • Data can be sent to multiple places, without the user caching that data in memory first.

Beyond this, we’ve also enhanced DataWeave to make it simpler to learn and provide deeper integration with the Java ecosystem.

Non-blocking, self-tuning runtime

There’s a new execution engine in Mule 4 that is based on a non-blocking, reactive runtime. This is a task-oriented execution model allowing you to take advantage of non-blocking IO calls and avoiding performance problems due to incorrect processing strategy configurations.

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. As a result, Mule 4 removes complex tuning requirements to achieve optimum performance.

Simplified error handling and new ‘Try’ scope

Mule 4 includes a simplified way to manage errors. Instead of dealing with Java Exceptions directly, there is now an ‘error’ concept built directly into Mule. Furthermore, 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.

mule 4 beta

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, or the errors can be re-propagated.

There is also a new ‘try’ scope, This allows you to catch errors in the middle of a flow, without having to create a new flow, specifically to catch that error.

Frictionless upgrades

In Mule 4, we wanted to make it easier for you to get new enhancements with little to no work on your part. In Mule 3, if you were using Mule’s internal Java libraries, this could be difficult, as libraries often changed from release to release.

  • There is classloader isolation between your application, the runtime and connectors, so that any library changes that happen internally will not affect your app.
  • Connectors are now distributed outside the runtime, making it possible to:
    • Get connector enhancements and fixes without having to upgrade your runtime.
    • Upgrade your runtime version without breaking compatibility with other modules.
  • There is now a well defined Mule API, so you can be sure you’re using supported APIs.

Get Started

All of this is available now as part of our public beta. Get started today, by simply filling out the beta form and downloading Studio 7 beta with an embedded Mule 4 beta runtime.

We think you’ll also find the following resources helpful as you get started:

Finally, be sure to check out our webinar on the new Mule 4 release where you’ll see Studio 7 and Mule 4 firsthand.


 


We'd love to hear your opinion on this post

19 Responses to “Introducing Mule 4 and Anypoint Studio 7 Beta”

  1. Hi,

    I’m not able to download any core modules, http/file/salesforce

    Agree(1)Disagree(0)Comment
    • This can happen if you only have a JRE installed. Please install a full JDK: http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

      We’re working on a fix for this soon. Thanks!

      Agree(0)Disagree(0)Comment
      • Thanks after updating JRe to point to JDK, I see this error while dwonloading http 0.8.1
        An internal error occurred during: “Downloading local project dependencies org.mule.connectors:mule-sockets-connector:0.8.1, org.mule.connectors:mule-http-connector:0.8.1”.
        Duplicate key org.mule.tooling.ui.properties.internal.AssetSelectionAdapter@4490b093

        Agree(1)Disagree(0)Comment
  2. What is the plan for users running MMC to manage Mule 3.x to upgrade to Mule 4, managed by ARM?

    Agree(0)Disagree(0)Comment
  3. I was able to download and run the studio. For some reason, I cannot find HTTP “Listener” / Poll Scope components from the new palette. Is this a known issue? If yes, how to fix that?

    Thanks

    Agree(0)Disagree(0)Comment
  4. The anypoint studio’s runtime 4.0.0 still used spring 4.1.9 release,
    Can it use a more higher spring edition?

    Agree(0)Disagree(0)Comment
    • This is something we’re working on still. We’re also hoping to decouple the core runtime so that you can choose what spring version you want – although this may happen in a 4.x release.

      Agree(0)Disagree(0)Comment
  5. How do I use a RAML for a HTTP request? In AnypointStudio 6.x there was an “API Configuration” field where I could put the url to the RAML I want to consume.

    I can’t find this field in 7.0.0 Beta.

    Agree(1)Disagree(0)Comment
    • Right now, the HTTP requester doesn’t support using RAML for DataSense. However, I think we have something better now: REST connect. When you publish a RAML into Exchange, you’ll get a connector generated. You can then add that to your project using the “Add Module” button in the Studio palette. For more details: https://docs.mulesoft.com/release-notes/rest-connect-release-notes

      Agree(0)Disagree(1)Comment
      • Are there plans on bringing this feature back to the HTTP requester?

        Agree(0)Disagree(0)Comment
        • Something we’re thinking about. We’re listening to what users say during the beta to determine next steps.

          Agree(0)Disagree(0)Comment
  6. Deeper Maven integration ?

    There is no more a “Update Project Dependencies” button and changing the pom.xml does not regenerate .classpath.

    Window Preferences Anypoint Maven looks fine:

    Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
    Maven home: C:\swd\maven\currentMaven\bin\..
    Java version: 1.8.0_121, vendor: Oracle Corporation
    Java home: c:\programs\currentJdk8\jre
    Default locale: en_US, platform encoding: Cp1252
    OS name: “windows 7”, version: “6.1”, arch: “amd64”, family: “dos”

    Agree(0)Disagree(0)Comment
  7. According to https://beta-anypt.docs-stgx.mulesoft.com/mule-user-guide/v/4.0/mule-4-changes under Unsupported Components in Mule 4.0, lots of components that are not marked deprecated right. for eg. until-success. Is this just for the beta release or is it for the full 4.0 release

    Agree(0)Disagree(0)Comment
    • We’re merging until-successful with the new scope – so you can handle all aspects of error handling in one block! I will update the docs to better articulate this.

      Agree(0)Disagree(0)Comment
  8. Really good additions and much simpler flows since the new target feature in the elements. Keep it up!

    Agree(0)Disagree(0)Comment
  9. May be something wrong on our side, but attempting to use the Beta and we are having similar issues as Suyog. Using jdk, and any attempts to add modules for functionality fail. Attempt to add file modules and get a failure that seems to indicated dependency http is needed. Attempt http module, similar failure for socket. Attempt socket, get failure for duplicate registration key.

    I would also tend to suggest that a common core list of components such as file, http, etc. that almost anyone if going to want be loaded and then people be allowed to remove rather than almost all modules needing to be added.

    Agree(0)Disagree(0)Comment
    • Hi Dennis, thanks – if the JDK is not the first item on the path, the components won’t show in the palette. This is an issue we’re working on fixing. In the mean time, you can take the following actions:

      • Set JAVA_HOME to point to the JDK
      • If you’re on Windows, set your Path variable to have %JAVA_HOME\bin; at the very front
      • If you’re on MacOS/*nix, set your PATH variable to have $JAVA_HOME/bin at the very front
      • Stop and start Studio again.

      If you’re still having problems, please email us at mule4-beta@mulesoft.com

      Agree(0)Disagree(1)Comment
      • Thanks to Dan and the Beta Support, we are up in running, so sharing the fix for anyone else hit by the same issue. While the above did not get us through, following the instructions as in this eclipse wiki page did: https://wiki.eclipse.org/Eclipse.ini This instructions are for eclipse.ini, but the same applies to the AnyPoint.ini as it is built on eclipse. These instructions are to set the .ini file to use a specific jvm. Without it, in our setup at least, the IDE was defaulting to the JRE and over-riding the setting we gave it. With the changes, it is still defaulting, but to the JDK path we want it to use and then the modules are correctly found.

        Agree(1)Disagree(0)Comment