A frequent issue I come across writing integration applications with Mule is deciding how to communicate back and forth between my front end application, typically a web or mobile application, and a flow hosted on Mule.
I could use web services and do something like annotate a component with JAX-RS and expose this out over HTTP. This is potentially overkill, particularly if I only want to host a few methods, the methods are asynchronous or I don’t want to deal with the overhead of HTTP. It also could be a lot of extra effort if the only consumers of the API, at least initially, are internal facing applications.
Today I would like to talk a little bit about releasing a new version of your Mule extensions. As you may know Mule is a an extensible platform with well defined integration points for plugging in your own connectors transformations, components and even routers. Suppose you have used The Mule Devkit to create your very own extension or cloud connector, and your project is so cool that it was accepted on MuleForge.
What happens if you make changes to you project and it moves from version 1.0 to 1.1? We’ll take a very quick look at how to do that in this post.
First, modify your pom.xml to increase your version number. In this case, we’ll go from 1.0 to 1.1:
The Jenkins build systemhas an open API which means we can do stuff with it. Today we’re going to automate the deployment of an application with a specific stable version. Jenkins has a great UI, it’s very flexible indeed, but sometimes is not enough. For instance, for CloudHub we deploy a Jenkins build to our QA environment, according the period in our development cycle, and we also need to execute automated tests. However, we can create a quick web application to choose a version of an application in Jenkins to deploy, using Mule Studio and CloudHub.
The explosion of APIs, SaaS applications, and mobile devices has created a massive integration wave. The resulting shift in the way we connect is forcing an IT mega change unlike anything we’ve seen before. As the development model moves from writing reams of code to composing APIs together, a new generation of middle tier application architecture is being born. What does this mean for you? Ross Mason, MuleSoft’s Founder and CTO, will provide his perspective on the future of this growing movement.
Data mapping and transformation are essential elements of many application integration projects. Integrated in the Mule Studio graphical design environment, DataMapper brings powerful data integration capabilities to Mule. Join Dave Eason, MuleSoft Solutions Consultant, for a demo-focused webinar covering DataMapper’s basic and advanced features.
An overview of DataMapper in Mule 3.3.1
Live build and test of a simple mapping
Demonstration of a complex mapping with multiple rules, input arguments, and lookups
Data mapping best practices
Presenter: Dave Eason, Solutions Consultant, MuleSoft
Its that time of year again when we take the Mule team on the road for Mule Summit. In previous Summits we’ve had guest speakers from Forbes, Intuit, Facebook, Sky and the National Lottery all talking candidly about their use of Mule. The next round of Mule Summit events will be visiting even more cities with even more speakers.
Sign up today to join the core Mule development team and successful Mule users at the premier integration event of the year! Meet the experts and kickstart your integration project at Mule Summit, where you’ll have the opportunity to influence product direction and get hands on with Mule ESB and Mule Studio in our interactive labs.
Mule ESB 3.3.1 represents a significant amount of effort on the back of Mule ESB 3.3 and our happiness with the result is multiplied by the number of products that are part of this release. We are releasing new versions with multiple enhancements and bug fixes to all of the major stack components in our Enterprise Edition. This includes:
We put a lot of effort in Mule 3.3 to improve error handling in Mule ESB. One of the most common requirements during error handling was the ability to continue processing the same message that was being processed at the time of the exception. And that’s why that is the default behavior for the new exception strategies shipped with Mule 3.3.
Another very common use case was the need to differentiate between handled and unhandled exceptions within a flow. In this case we are going to focus on handled exception and the new catch exception strategy.