A little while ago we decided that it was time to include the option of asynchronous loggers in Mule ESB.

The asynchronous implementation is faster than the synchronous one because the process waits for IO on a different thread, instead of on the main execution thread, allowing it to continue its execution.

After some research, we decided to use LogBack or Log4j2, both are successors of the Log4j framework.

To choose between the two, we ran performance tests in our performance lab comparing Log4j, Logj2, LogBack and no-logging. The following Mule app was created and used in all the tests.

Sometimes pre-built connectors can solve your integration challenges; other times you might need a connector with a specific functionality or you might want to connect to a system without an available pre-built connector. In these cases, building your own connector may be the better route to take.

While getting started on building a connector from scratch can seem daunting at first, the challenge often becomes much more manageable when you understand the tools and resources that are available.

On Wednesday, February 25th, MuleSoft released a major update to our Anypoint Data Gateway for Salesforce Lightning Connect. Since unveiling in November 2014, we have enhanced the product to include several key capabilities that accelerate time-to-value in connecting Salesforce to external data sources. Our goal is for business users to easily configure basic integrations and better align the actual data used for business needs and use cases. We’re also very focused on the need to provide governance for data and integrations, while supporting the on-going trend of providing IT tools as a service. Let’s take a look at some of the features of this release:

Steven Camina on Friday, February 27, 2015

Light Up the Internet of Things


IoT Lights demo @ MuleSoft HQ

To liven up the 2nd floor of the MuleSoft SF office, we decided to showcase a slightly modified version of the IoT demo we gave in last year’s Chicago and New York MuleSoft Summits. The demo we have listens for any mentions of @mulesoft on Twitter. If found, a Mule app running on a Raspberry Pi makes the lights glow. Initially dim, the lights glow brighter with more mentions.

Now let’s dive into the specifics of this fun little demo we’ve created.

The genesis of this demo was a brainstorming session for a MuleSoft Summit keynote presentation. We wanted to show something that showcased IoT in conjunction with MuleSoft technology. We decided to simulate home automation via APIs, which essentially means using Internet of Things APIs to control the “things” around one’s home. In our case, the “things” we were controlling were Philips Hue light strips (which we shaped to form the MuleSoft logo). In addition, as is typical in many IoT architectures, we used a “controller” closely located to these “things” – think of how a Nest device (controller) manages the heaters (things) around a home. In our case, the controller we used was a lightweight Mule app running on a Raspberry Pi, which connects to both the external network to receive information, and to the internal network to control the lights.

oprahAnypoint Exchange is home to integration best practices, hosting the complete listing of MuleSoft’s connectors, templates and examples. With our latest release, we are thrilled to give customers the ability to curate their own exchange.

Preloaded with MuleSoft’s assets – connectors, templates and examples – to help you get started, customers can extend the exchange by adding customized information that will increase adoption of internal best practices and encourage collaboration across the organization. Any assets added by customers will be kept private to their individual organization.

This is the second of a series of blog posts around the new Mule agent. For an overview of the new Mule agent, be sure to read Introducing the new Mule agent. In this post, I’ll talk about the new agent in relation to the Mule Enterprise Management Console (also known as MMC).

Readers of this post are probably familiar with MMC, which is MuleSoft’s current on-premises management/monitoring solution. The agent is a first step in the development of MuleSoft’s next generation management and monitoring solution. Think of this solution as more than just MMC 2.0. Over the next few Anypoint Platform releases, this agent will unify management and monitoring of Mule ESB, CloudHub, and API Gateway to provide MuleSoft customers with unparalleled visibility and control over their connectivity landscape. And because we’re taking an API-led connectivity approach to developing the agent, it will be highly extensible.

I am extremely happy to announce a significant set of updates to Anypoint Platform for APIs that were introduced this month. These updates will make it easier for API owners and administrators to publish their APIs in a way that is sure to further their successful adoption. The sections below describe the core new capabilities introduced in this release.

Instant management through automatic deployment

The management of APIs with Anypoint Platform consists of the deployment of a proxy application to an API gateway runtime. The platform makes it easy to generate such proxies through a simple configuration wizard. Since generated proxies are simply Mule applications themselves, this allows API platform users to extend them through the rich capabilities offered by Anypoint Studio and Mule integration components.

The general guiding principles of the Zen philosophy can actually be quite helpful in designing the Anypoint Platform for APIs‘ deployment architecture. The emphasis on having a holistic approach, while striving for simplicity, symmetry, and minimalism, works as well for meditation as for coming up with a stable, robust and secure architecture. Here, we will outline the four most common models in use today that dovetail with the teachings of the Zen philosophy.

1. On-premises

The first model is a pure on-premises configuration.

Mike Stowe on Friday, February 20, 2015

API Best Practices: The Wrap Up


Check out all the posts in the API design best practices series »
Or, start with part one: Plan Your API.

Looking Back

Unfortunately, this series of API Best Practices has come to a close. Over the last several months we’ve taken a look at how to design a flexible, extensible, and usable API. These steps included:

1. Planning Your API – The first and most basic step, is understanding what it is that you’re actually building. Understand what your customers want (this means involving them), understand what different types of APIs there are out there, and why you are building the kind you are (REST, REST-like, SOAP, RPC). Lastly, it’s important to map out the functionality that your users need – and to not get stuck in a resources/CRUD mindset when doing so.


This post is brought to you by Pablo Cibraro. Pablo is a Software Architect focused on MuleSoft’s solutions for Microsoft.


As part of our on-going effort to make Anypoint Platform even more accessible and intuitive for .NET developers, we are thrilled to introduce a RAML parser and Visual Studio extensions that make it easy to consume and implement APIs using RAML.

What is RAML?

RESTful API Modeling Language (RAML) is a language for describing a Web API in terms of resources, methods and implemented patterns (security, paging, filtering, projections, etc). RAML is based on YAML and leverages other open standards such as JSON or XML to document the schema of the resource representations. In short, RAML allows you to do the following for your API:

  • Write Human-readable documentation using Markdown
  • Define supported resources and HTTP methods
  • Reuse common usage patterns such as data paging or filtering
  • Describe expected responses for multiple media types with schemas and examples for each
  • Define security aspects

Here’s an example of a RAML document describing a very simple API for browsing a movie catalog: