Have you ever wanted to learn best practices from MuleSoft’s technical experts? Are you an architect, developer, or manager looking to implement your first MuleSoft use case? Want to experience a one-of-a-kind integration workshop AND have tasty cocktails?
In the Getting Started with DataWeave: Part 1, we introduced you to DataWeave and its canonical format, the result of every expression you execute in the language. We now continue to explore our new transformation engine, aiming to give you enough grounding to tackle real-world use-cases.
As we did in Part 1, we will continue to show the results of each expression in the DataWeave canonical format.
Ever wanted to get certified on our Anypoint Platform, but discovered that you didn’t have the training?
We’d like to introduce MuleSoft.U: self-study, public, FREE certification courses that will enable developers to learn core MuleSoft skills. At a significant cost per seat for a public class, instructor-led training is unattainable for most independent developers. With MuleSoft.U, independent developers can get up and running in no time.
Handling endpoints with disparate speed when the platform is in the cloud
A fairly common integration requirement is to accumulate data coming in real-time or near real-time, hold and consolidate the records, then send the transformed messages to another system on a fixed schedule (e.g. daily etc.) for business reasons, especially if the endpoints are legacy systems. For on-premises integration platforms, this use case is rather straightforward to implement.
Anypoint Platform is fast. The legacy systems that it often connects to? Not so much.
Therefore, in real world use cases, the requirements often call for limiting the message throughput to protect the endpoint systems from being overwhelmed by traffic. Architectural designs that support message throttling commonly incorporate some elements of message queues to stage and hold messages in-flight, so that the endpoints can process them at a steadier pace.
Join us for the latest installment in the MuleSoft webinar series as we sit down with Julie Craig, Research Director at Enterprise Management Associates, and Reza Shafii, Director of Product Management, MuleSoft to discuss some of the common pitfalls and questions businesses have when developing their API strategy. Craig and Shafii will talk about the essentials of an API-led approach to design,
In this post we’re going to continue the discussion started our last post “A sneak peek into Mule 3.7’s deepest internals” about how Mule’s registry, lifecycle and dependency injection mechanism are being overhauled in Mule 3.7. In this case, we’re going to take a deep dive into how we managed to unify the registries while keeping backwards compatibility and all the implications of such maneuvers.
Mule 3.7 is approaching, and among other things we decided to put a lot of focus on the experience of the guy coding custom components (Devkit based or not). For this, the first 3.7 milestone is incorporating big changes in terms of the how Mule Lifecycle and Dependency Injection are applied.
As I said, these changes are BIG, so for clarity reasons we’ll cover them in a series of post starting with this one.
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.