For the last five years, our beloved Corrientes Avenue office was home to most of the projects that the company has seen, as our engineering hub is in Buenos Aires. As we’ve gained more customers and taken on bigger technical challenges, we need more people to help us build more innovative products and take on these challenges—time for a bigger space and a fresh new look. Hello, Puerto Madero!
Our Engineering team,
Anyone that has used DevKit to write a Mule extension and then wanted to add it to Studio, may have notice that the extension will appear under the Cloud Connectors category in the palette. This is not a problem when the extension is actually a Cloud Connector, but is sort of a problem when it was something else (for example a component like the LDAP connector).
Mule 3.4 is entering the final lap in the race to the finish line with a GA launch. Rounding the last corner on two-wheels, we are excited to launch a second Early Preview release.
A couple of weeks ago, we released the first Mule 3.4 Early Preview which introduced a whole set of new features; in this second pre-beta release, we have further stabilized the new features and added a few more.
One aspect of Mule DataMapper that makes it a grate data integration tool is its ability to do mappings involving complex and different data structures (XML, Json, POJOs, CSV, Excel files and more). One feature that is really attractive is the possibility to test your mappings without the need to launch your Mule application, so that you can provide sample input data and preview what the result of the DataMapper will be.
There’s no need to state the importance of debuggers for developers, and Mule developers are no exception. The goal of this blog post is to provide you with a few handy tips for debugging your custom Java code in Mule Studio.
Getting started
I will assume you have already created your Studio Project and added a custom Java class (a Transformer, Module, etc.). If you are not there yet,
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.
I spent 2 years of my life working as an Identity Management (IdM) consultant a long time ago, when clouds were related to weather and SAAS sounded like the Scandinavian Airlines. The environment changed an now more and more companies are moving to the cloud relying on applications living outside their firewalls, but there’s something that didn’t change: The need to provision user accounts. This is the main reason why I will like to spend some of my free time the next months trying to build an IdM solution for the cloud on the cloud.
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.
The Mule team is very pleased to announce the availability of Mule ESB 3.1.1, CE and EE. This is a follow-up release to Mule 3.1 and another step forward in innovation, connectivity, and usability.
Mule 3.1.1 adds:
Opposite to men that with the years we get slower (at least that’s my case), the new version of Mule 3 showed an improvement in performance compared to previous Mule ESB versions. In general plenty of effort was put to profile and optimize Mule for high concurrency scenarios, which led to improve the way messages were handled in transports and transformers.
Mule 3.1 performance is in average 10% better than its predecessor version 2.2.7,
