An ObjectStore is a Mule component which allows for simple key-value storage. Although it can serve a wide variety of use cases, it’s mainly designed for:
If you are a Mule 3 user, then you’re already familiar with this concept. However, we feel that creating and defining these stores could be made much simpler.
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.
We recently released new connectors for FTP and SFTP connectivity in Mule 4, now available in Anypoint Exchange. Even though FTP and SFTP are two very different protocols, we crafted these connectors to be practically identical, providing an easy and consistent experience. As a result, the same use cases are addressed in a similar way in both protocols.
And it gets better! Remember the new file connector we discussed a while ago?
The Mule 4 Release Candidate is here and, with it, the updated version of the batch module!
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!
There’s a brand new Mule 4 Anypoint Connector for Database (DB) that you can use to connect to any relational Database engine. Unlike other connectors such as File or FTP, this connector has a pretty similar UX compared to the one in Mule 3.x, with some considerable improvements, including:
Mule 4 Beta is out and we have a completely new File Connector, which replaces the old transport. This connector greatly enhances Mule’s capability to handle files and folders on a locally mounted File System.
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.
Welcome to the final post in the three post series about batch improvements on Mule 3.8!
The last new feature we have is a simple one which comes quite handy when you need to read through logs. As you know, batch jobs are just programs processed in batch mode, and each time the job is triggered, a new job instance is created and tracked separately. Each of those instances is unique and therefore has a unique ID.
Welcome back! Following the series about new batch features in Mule 3.8, the second most common request was being able to configure the batch block size.
What’s the block size?
In a traditional online processing model, each request is usually mapped to a worker thread. Regardless of the processing being synchronous, asynchronous, one-way, request-response, or even if the requests are temporarily buffered before being processed (like in the Disruptor or SEDA models),
Hello there! If you’ve been using Mule for a while now, you probably remember that the batch module was introduced back in the 3.5 release. If you’re not familiar with it, you can familiarize yourself by following these links:
We received a lot of love for this feature,
