What is different in Mule 4

Mule 4 has several changes in both operational and management perspective, Below are few of the key changes we see

  1. Making error handling easier:
    1. In Mule 3 error handling was based on java errors and there was no way to identify the nature of the error. However, in Mule 4 the error is property typed and the difference in error namespace(error source) and identifier(the type of error) per connectors made it easy to identify the error source.

    2. The introduction of try scope has helped in grouping a piece of elements inside flow and put a specific error handling for them rather than always using a centralized error handling.

    3. The auto-created error blocks for RAML based projects got a new error type for apikit error with namespace APIKIT. Also, a new error of type apikit:not_implemented introduced in mule 4, which was not part of mule 3.

  2. Simplified connectors: Connectors are now separated operation based. Earlier in mule 3, we used to have multiple operations per connector. This simplification helps in designing and managing the operations.
  3. Self-Tuning: Mule 4 engine does various jobs like configuring thread pooling, threading profiles, processing strategies itself depending upon the runtime conditions, and sets them automatically to achieve maximum performance. This was not the case in Mule 3, where a user has to manually set thread pool, processing strategies, etc.
  4. Project structure: Mule 4 uses the benefits of maven by making all the applications maven based which was optional in Mule 3. Also, Mule supports only jar type as deployable where mule 3 supports zip. In Mule 4 Runtime update and connector updates are separated, we see separate sections for every connector we use along with the version. Also, mule-artifcat.json works as an application description that describes the app, configure settings, the required mule version, class loader configurations.

  5. Dataweave 2: The data transformation language mule 4 supports is  dataweave 2. Also, MEL(Mule Expression language) does not exist in Mule 4 and they should be replaced by dataweave 2. Below are the few of the changes in the dataweave language we have –
    1. The syntax for all header components like dw version, the output type, variable and function declarations
    2. Change of conditional logic
    3. Operations are now functions
    4. Various changes in syntax for data-type, key-value pair etc.
    5. Additional function added . For the complete list of changes and examples click here
  6. Transform message: In Mule 3 Router components we were required to have java type as output from a transform message component to be used for a router component. However in Mule 4 that is not the case. Datawevae 2.0 does not work only as transform message but expression language as well. It can read the expression in any language and do the job.
  7. Message model: There is a significant change in the mule event in mule 3 and mule 4.

    1. The mule message structure has been more simplified in mule 3 where inbound and outbound properties are now part of attributes. Attributes do work as metadata about the payload and it will contain a different type of data depending upon the type of the connector being used.
    2. The attachment is part of payload now in mule 4 which was a separate component in mule 3
    3. The exception payload in mule 3 was referred to as ‘exception’, in mule 4 it is now ‘error’.
  8. Message enrichment: There was a message enricher component in mule 3, which is not more available in mule 4. In mule 4 there is a way of storing the new payload by setting the target variable. By this, the actual payload does not get change and the new payload gets stored in a local variable. Using this combination we can enrich the existing payload. We can set this to both connectors and flow-ref components.

  9. Connectors update: The updates of connectors are separated from runtime upgrade. This brings a huge change as there is no need to wait for a runtime upgrade to have fixed in the connector. Also one can update the whole runtime to get the cumulative fix for all connectors or can upgrade only the connector is being used. Also, one can upgrade or downgrade the version of the connector by referring the version in exchange, and matching against the runtime is being used.

There are a few more changes that keep on coming with every upgrade of the version in Mule 4.  Look at the release notes for the same.

By – Soumitra Giri
LinkedIn

Tags: No tags

Leave A Comment

Your email address will not be published. Required fields are marked *