A few days ago, we proudly announced the GA release of Mule 4 and Studio 7, a major evolution of the core runtime behind Anypoint Platform. Mule 4 enhances application development velocity with up to 50% fewer steps and concepts to learn, including a simplified language for connectivity, clear access to data, automatic tuning, and smoother upgrade processes.
Earlier this year, we started a new blog series, highlighting great contributions from MuleSoft Developers that are willing to share knowledge with the community. February was another busy month for Mule developers, and we want to share some of the amazing work they have been doing for the community.
We are lucky to have some great contributors in the MuleSoft community. And we’d like to highlight the things they do to make our community so fantastic. From the forums to in-person events and video tutorials, we see great community contributions from MuleSoft Developers willing to share their knowledge with others. Today, we want to recognize the great work of MuleSoft Developers in January 2018 and share it with you.
One of the more challenging aspects of integration work is dealing with various security protocols. This holds true both as a consumer of a secured service and as a producer of a service that must enforce the security protocol.
Logging is arguably one of the most neglected tasks on any given project. It’s not uncommon for teams to consider logging as a second-class citizen and it is usually taken for granted; until, of course, the team goes live and try to troubleshoot anything.
As a MuleSoft Certified Architect, Designer and Developer, I recently worked on API implementations for one of our clients using MuleSoft’s CloudHub. One common feature that we used across our APIs implementations is reading a properties file in Mule flows.
Before we get started with this blog, if you haven’t checked out Part 1 of this Dev Guide series, make sure you work through that first, where we went through developing a resilient, governable, and flexible API layer on top of your source systems—what we call system APIs.
The batch module was first introduced in Mule 3.5 and it aims to simplify integration use cases where basic ETL functionality is needed. If you’re unfamiliar with it, I recommend you look at this post before continuing. If you are already old friends with batch, then keep reading for a breakdown of all the changes!
At MuleSoft, we are fortunate to have a community of developers that answer questions about Mule, share best practices, and organize meetups. Their knowledge and effort make building solutions with MuleSoft simpler and more rewarding.
In my last post, I discussed DataWeave 2.0 header and body (iterative functions) changes in Mule 4 Beta. In this post, I will dive deeper into the topic by discussing operator changes (within the body) as well as other changes.
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.