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.
Testing using an external API can be a PITA, especially if the API uses any HTTP Callbacks or redirects such as OAuth or WebHooks. If your using any callback functionality like this then the Service Provider needs a way to callback your application and therefore be accessible to the public Internet.
When you start integrating these APIs, it’s much easier to work on your local development machine, but these are usually behind firewalls, NAT, or are otherwise not able to provide a public URL and it’s not really feasible to push to a staging environment every time you want to test something.
So we need a way to make our local applications available to the Internet; there are a few good services and tools out there to help with this such as: Tunnlr, ProxyLocal, showoff.io or you can setup your own reverse SSH Tunnel if you already have a remote system to forward you requests.
In this post, I am going to use a service called LocalTunnel and show how we can share a local Mule application with the world and customize some Cloud Connectors to receive Callbacks locally.
Those of you who are regular visitors to this blog are no doubt familiar with Mule Community edition. With this blog I’d like to introduce you to MuleSoft and our Enterprise version of Mule, I think its important to understand everything that mule can offer you.
Reason for Success
So why do companies rely so heavily on Mule? Well, consider the legacy integration ESBs and Brokers. Most of them were built over fifteen years ago, so they solve only a subset of todays integration challenges. These were and remain heavyweight stacks expensive to rollout and maintain and stubbornly resistent to change. MuleSoft in stark contrast is now leading the way with Mule Enterprise which was built to be agile in its ability to adapt to the changes which necessarily occur in any company’s business processes. Mule’s success can be attributed to the following characteristics: