Testing with MuleSoft’s MUnit: Part 2

mulesoft munit testing

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,

Using advanced file filters in File Inbound endpoint

Using advanced file filters in File Inbound endpoint

Mule ESB allows you to connect to anything and anywhere using a wide range of connectors and endpoints. File connector is one of the commonly used connectors that allows you to read/write files with file systems. There are two ways to use file connector –

  • Inbound Endpoint – When file connector is used at the beginning of the flow, it acts as an inbound endpoint where you can receive files for processing.

Weaving it with Dataweave expression

We all know how powerful Dataweave Transform Message component is. This is such a powerful template engine that allows us to transform data to and from any format (XML, CSV, JSON, Pojos, Maps, etc. basically ).

So if we need to transform we need a Dataweave component in our flow. But wait! Dataweave also provides us a function called Dataweave function that helps us to execute Dataweave language outside a Dataweave transform component.

The top 6 facts about Mule ESB

September 14 2016

3 comments 0
what-is-mule-esb

An Enterprise Service Bus (ESB) is a set of principles and rules for connecting applications together over a bus-like infrastructure. ESB products enable users to build this architecture, but they differ in their methodology and the capabilities they provide.  Mule as an ESB is the runtime engine of Anypoint Platform

The core concepts of Mule ESB

The core concept of the ESB architecture is that applications are integrated by putting a communication bus between them and then enabling each application to talk to the bus.

Custom batch job instance IDs in Mule 3.8

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.

Configurable batch block size in Mule 3.8

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?

largeIn 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),

Batch improvements in Mule 3.8 – Mutable commit blocks

motif

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,

Introducing the Validations Module

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?”.

Libraries upgrade recap for Mule 3.7

motif

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.

Reliable Acquisition using the Sftp connector

motif

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.