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!
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). This is not an issue anymore since DevKit 3.3.2, as you can now use the @Category annotation at class definition level (Connector or Module) to select under which category you want your extension to be listed in:
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. Just to recap, the list below enumerates the highlights of the the first Early Preview release:
This second early preview has incorporated early-adopter feedback and offers even 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, you should probably read Getting Started with Mule Studio.
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.
Let me give you an easy example. I can bet that you have accounts in one or more of the following applications: email (google, yahoo, hotmail), Facebook, Twitter, Amazon, eBay, etc. In all those applications at least you provided your email address, username, first name, last name, password, etc. What will happen if you want to change your name? You will need to go to each application and change it. This is not a real world example as it doesn’t cover not even 10% of what IdM is meant for (It doesn’t make too much sense using IdM for personal use), but the fact is that people use different applications and have different accounts in each of them.
Companies have employees, customers and providers and in many cases each of them need access to different applications in order to be able to do their work. The challenges the company then face are:
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:
We really appreciate the feedback, bug reports, suggestions and blogs on Mule 3 so far so please keep them coming. Mule 3.1.1 can be downloaded here.
We made a big change to the examples that ship with Mule making it easier run examples, test them out and view the source. For those who don’t have a lot of time to spend taking a look at README files, startup guides or product documents in order to test Mule, you can now start Mule 3.1.1 in a new mode that will deploy examples and launch a web application to interact with them.
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, performing better when the number of concurrent consumers gets bigger and much better when dealing with XSLT transformations (around 15% better).
The test cases and setup were similar as the ones used some time ago to benchmark Mule 2.0.2. For more details on these benchmarks please refer to Whitepaper Perf Test Results.
Sign up for our newsletter
