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.
Tag: Mule ESB
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.
- The give and take of APIs
- A glimpse into the connected revolution
- 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
Date: Thursday, September 20, 2012
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:
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.
After reading this post you should be able to:
- Understand how to add and use Input Arguments
- Test your mappings with the Preview Functionality
The configuration patterns series continues with this new installment!
We’re happy to announce that a new configuration pattern made its way into Mule 3.3. This new pattern, named HTTP Proxy, will come in handy when remote web resources need to be accessed in a controlled manner, for example when it is not desirable to have numerous internal applications depend directly on external services.
It also supports caching, which allows you to reduce the outbound traffic towards regularly (and of course cacheable) web resources.