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,
This all began with a very popular request: “We want to be able to throw an Exception from a flow”. The motivation for this is that it’s fairly common to run into “business errors” (errors not related to the handling and transmission of data but the data itself) which should actually be treated in the same way as a connection or system error (things like the remote endpoint is down).
Given the popularity of the request we decided to look into it and started by asking: “which are the use cases in which you would throw an exception?”.
If you have read the Mule ESB 3.7 release notes then you already know what I’m about to say, but just to recap, here we go…
A lot of effort was put in 3.7 to upgrade our libraries stack. That effort actually began in 3.6, and although the list of upgraded libraries is not so big as it was on that release, it’s somehow more significant given that we upgraded some dependencies that we held very close to our hearts and core.
A high-reliability application (one that has zero tolerance for message loss) not only requires the underlying ESB to be reliable, but that reliability needs to extend to individual connections. If your application uses a transactional transport such as JMS, VM, or DB, reliable messaging is ensured by the built-in support for transactions in the transport. This means, for example, that you can configure a transaction on a JMS inbound endpoint that makes sure messages are only removed from the JMS server when the transaction is committed.
Currently, Mule relies on plain old java serialization in order to store objects to files or to replicate them through a Mule cluster. That imposes limitations on:
Sign up for our newsletter
