This is part 2 of a series on changes to the Mule Message in Mule 4 Beta, read part 1!
The Mule 4 Beta release has significant internal improvements to Mule runtime. In the last post, we talked about immutability and collections with Mule Messages. In this post, I will go into detail on inbound and outbound properties in Mule Messages, as well as variables and other changes.
The Mule 4 Beta release has a lot of new and improved functionality such as DataWeave and a refreshed Anypoint Studio experience, but we’ve also been busy under the hood making internal improvements to Mule runtime. In this series of posts, we’ll give a behind the scenes insight into what we have changed under the hood and why, along with the lowdown on what users need to know about the changes from an application design perspective.
The long-term success of a technology ultimately lies on the strength of its community. At MuleSoft, we are fortunate to have a vibrant community that has many members who contribute by answering questions, sharing best practices, and organizing meetups. Their knowledge and effort made the experience of building solutions with MuleSoft simpler and more rewarding.
This post was written by one of the stars in our developer community, Kian Ting. Read this post to learn how to use a Mule app to retrieve legacy data and sync it to a new destination endpoint with the poll scope method.
As integration developers, we are always faced with the need to poll a legacy resource to retrieve new data and to sync it over to another destination endpoint.
This post was written by one of the stars in our developer community, Manik Magar
Mule 4 beta is already out. One of the major change in Mule 4 is making DataWeave a default expression language over Mule 3’s default Mule Expression Language (MEL). The XML namespace of DataWeave is moved from dw to ee (core), and the DataWeave version has changed from 1.0 to 2.0 in Mule 4.
If you ever used Mule 3, then there are probably two things about error handling you already know:
- It’s really Java exception handling
- It’s a “trial and error” experience
In this post, I’ll explain the major changes introduced in Mule 4 around error handling, including easier routing and the introduction of our new try scope.
In many ways,
Streaming in Mule 4 is now as easy as drinking beer!
There are incredible improvements in the way that Mule 4 enables you to process, access, transform, and stream data. For streaming specifically, Mule 4 enables multiple parallel data reads without side effects and without the user caching that data in memory first.
All hail DataWeave!
One of the major changes in Mule 4 is the introduction of DataWeave as our primary expression language. Although this may seem like a radical change, I’ll explain some of the reasons behind our decision, and why this represents a major leap forward. I’ll also share some examples and answer a question that is likely on many readers’ minds: “what about MEL?”
Why We Chose DataWeave
In this article, we will see how Mule can intercept messages on the TCP/IP socket for real-time communication. You will first receive messages on the TCP/IP socket and then transform the messages from byte to object, then from object to XML, and then, finally, from XML to JSON––all using out-of-the-box Mule transformers.
The TCP transport allows users to send or receive messages over TCP connections. TCP is a layer above the IP.
This tutorial continues from Part 1.
Mock is a feature provided by MUnit to mock the behavior of the message processor. Basically, MUnit replaces the actual behavior of message processor with the behavior defined by the user.
There are various scenarios where we can use the Mock Message processor. Imagine we have completed the development of a Mule application and need to test it,