Mule Management Console 3 ships with both mule2 and mule3 agents. You can monitor all your mule instances from latest MMC and benefit from UI improvements and bug fixes even if you didn’t upgrade to mule3.
MMC 3.1 takes it to another level by introducing backward compatibility support for both agents. Safely upgrades your MMC console without touching mule instances! Everything you already configured will still work and UI will provide access to features depending on agent capacities.
Logging. An old friend. So critical for a production deployment and so hidden away. Much has been said and done in this area, and we’ve seen both success and total domination by log4j, as well as an abysmal failure of java.util.logging (still hearing the chorus of WTFs and raised eye brows).
With the introduction of Mule 3 the playing field has changed dramatically, but something was still missing. Multiple applications in runtime were still writing to the same single log file. And while it was easy to split out log entries for your custom classes and packages, in practice it had little value without the larger context of Mule and 3rd-party library log entries. Besides, re-configuring logging at runtime wasn’t quite possible. And with multiple applications running in a single Mule instance, one-config-fits-all was no longer an ideal choice.
So, without further ado, welcome the new Logging in Mule 3.1.2. No, it’s not a rewrite, and you aren’t locked into any logging API in your code either (same as before). However, those extra 20% of functionality and usability which often are never implemented make up for a huge difference. Below are some highlights of what to expect.
Continue reading When an issue arises in production it can be quite daunting to reproduce it in a test environment. Ideally one debugs the live application. But logs don’t tell the whole story. And a severe issue may require the application be taken down. How can it be stopped and debugged at the same time? With Mule composite sources and Mule Management Console (MMC) end-point control you can eat your cake and have it, too.
The composite-source element of a Mule flow can contain one or more inbound end-points. Use one or more for production and any number of others for debugging; then set up the debug end-points to provide detailed visibility into your mule application. MMC can then be used to control which end-points are enabled. With this approach you won’t need to waste time setting up a reproduction environment when problems occur nor will you need to shut down the application to diagnose problems.
Continue reading I was recently tasked with revamping the developer documentation’s information architecture to address reader comments that it was too hard to find needed information. I worked with a team of people at MuleSoft to make the new information architecture a reality, as well as to write some new content that helped explain Mule ESB 3 concepts for new users, as well as to improve the quality of key topics in the docs and to write a new document, Hello, Mule!, to help new users quickly download and install Mule CE and the IDE and to get their Mule installation up and running in minutes. Here’s a link to the new documentation.
Continue reading Ok. Face the music. Let’s debug.
Check list:
What is happening here?
Continue reading One of the more common usages of Mule is as the integration piece of a larger SOA architecture. Mule has traditionally never attempted to offer a complete SOA suite/stack of products as some of its larger competitors do, but has rather focused on the thing it does best, which is integration. Other aspects of an SOA architecture (messaging backbone, data storage, governance, etc.) are generally provided by other best-of-breed solutions for those areas, and Mule allows you to integrate with as many different options as possible.
Continue reading A few days ago I decided to do the exercise of migrating an existing transport (JPA) to be compliant with Mule 3.1.1, and after a couple of hours reading and a few minutes of coding I finally got it working. I would like to share some tips that may help you to migrate your own transport.
Continue reading Flow has transformed Mule and provides a very powerful way to configure many types of integration scenarios. However, I wanted to make it clear The <service> model from Mule 2 is not being deprecated or removed. If you already use Mule 2.x you may be wondering whether to stick with <service> or go with the <flow>.
Continue reading Mule 3 defined a simple, universal structure for Mule ESB applications. It’s a simpler version of war file format, consisting of a zip file with three sorts of entries:
We also created a maven plugin to build Mule apps. And we haven’t forgotten about the Ant fans in our community. There are two new Ant tasks to make creating and working with Mule applications a snap.
The first task packages up Mule applications. For example:
This isn’t an industry that needs more acronyms but there is no stopping the cloud *aaS rocket ship so its better to clearly define new categories that get created as we fly towards the clouds. Integration Platform as a Service (iPaaS) is a new type of service tailored specifically for integration applications. The term ‘PaaS’ is a layer of cloud software that deals with the platform for building applications (if you are not familiar with PaaS take a look at my previous post). This layer is analogous with ‘middleware’ and in the same way middleware was broken into categories such as App Server, ESB and messaging, PaaS will also get broken down.
Gartner released a report earlier this year that broke PaaS down into application Platform as a Service (aPaaS) and integration Platform as a Service (iPaaS). The aPaaS category is the one that most folks are familiar with numerous services including Heroku, Elastic BeanStalk, CloudBees, Azure with some platforms being more aligned with PaaS concepts than others. The iPaaS category is very new with Mule iON announcing earlier this year and others such as WorkDay have started to emerge.