Pattern-Based Configuration: Hello HTTP Proxy!


The configuration patterns series continues with this new installment!

We’re happy to announce that a new configuration pattern made its way into Mule 3.3. This new pattern, named HTTP Proxy, will come in handy when remote web resources need to be accessed in a controlled manner, for example when it is not desirable to have numerous internal applications depend directly on external services.

It also supports caching,

Mule Configuration Inheritance


We often see the need to reuse a component configuration between 2 applications deployed to Mule. For example, let’s say you have two Mule applications deployed in your Mule server. The first one, called  AppA, gets information from Salesforce and stores it in a database. The second AppB modifies your Salesforce campaign information. Both applications share the same Salesforce credentials, so what happens if those credentials change?

Mule Tip: Multiple PropertyPlaceholders in same Mule Configuration


If you want to avoid including configuration parameters (probably connection related parameters) in your Mule configuration, you can use property placeholders, which will allow you to upload these parameters from a properties file. This enables you, for example, to have different property files for different environments (Dev, QA, Prod) or allows you to reuse the same value in different parts of your configuration.

Agent-Based Synchronous HTTP Request Handling (A Recipe)


In the vast majority of cases, HTTP requests are processed synchronously: the operation that the client wants to perform on the targeted resource is executed by the same thread and the result is returned right away. This is usually done by connecting the HTTP layer directly to the service layer.

This post demonstrates a slightly different approach where HTTP requests are first sent to a messaging layer, then processed by dedicated agents whose responses are eventually returned synchronously to the client that is blocked waiting.

Pimp your Mule Flow debugging session


Mule Management Console 3.1 ships with the brand new Flow Analyzer. Select your server, interesting flows, click start and enjoy seeing real-time messages passing through mule! Click on an debug event and you will see the payload before and after each message processor of your flow.

Out of the box MMC will convert the payload to a string representation using custom toString method if any or by reflectively inspecting its individual fields.

Go with the Flow with Mule 3.1!


Mule 3 underwent some significant architectural improvements, I talked about this back when Mule 3.0 was released in my “Mule 3 Architecture: Back to Basics” blog post.  These improvements  enable a much simpler way of configuring Mule that is more powerful while at the same time much more intuitive.  As we release Mule 3.1 I really want to encourage everyone to “Go with the Flow!!”

In this post we’ll cover the basics of “Mule Flow”;

Re-use: Accomplished! Configuration Patterns Catalog for Mule


If you follow this blog or what’s happening in Mule 3, you’ve heard about the newly introduced configuration mechanism based on patterns. In the coming releases of Mule, we will keep adding new patterns based on users feedback and requests.

But this doesn’t mean your experience with configuration patterns will be limited to the ones that come with Mule distributions: we have made it easy for you to create your own patterns and,

Mule Speaks Java: Towards a programmatic configuration of Mule


True to our goal of simplifying the configuration of Mule, we will be adding the capacity to programmatically configure Mule 3 in the coming releases.

With configuration patterns aiming at reducing the amount of XML configuration and a new IDE in the works for graphically configuring Mule, the third angle we wanted to take on simplification was the creation of an API fluent enough that it becomes possible to configure Mule with your favorite JVM language.

Pattern-Based Configuration: Hello Validator!


The pattern-based configuration series continues! After a first set of fairly generic patterns, this new addition will demonstrate how highly specialized patterns can provide value too.

When processing messages, a certain format is always assumed to have been respected so that the required data can be retrieved. It is possible and oftentimes desirable to be very liberal with the data representation used by incoming messages: as long as you can find the needed pieces of information,

Pattern-Based Configuration: Hello Bridge!


Web Service Proxy was the last configuration pattern presented in this blog. Time for a new one!

Connecting systems together is one of the most essential task of integration. Mule ESB offers the necessary building blocks for achieving such connections. One of these building blocks allows establishing bridges between message sources and destinations. Known as the messaging bridge pattern, this building block is available in Mule 3 as the newly introduced Bridge configuration element.