I read a couple of RSS feeds regularly. Unfortunately, I work across a couple of machines: my laptop, the machine in the office, my wife’s laptop. This rules out using a local RSS reader as I’d have to manage the redundant subscriptions let alone I’d have to remember which feed entries I have already read and which one not. Sure, I could use Google’s feed reader but being mostly eMail centric anyway I’d love to see RSS feed entries in my INBOX. But wait! Mule has RSS support and it can send emails … why not hack this together in Mule?
Polling the feed
Retrieving an RSS feed is easy using the tag that was introduced with Mule 3:
This config snippet polls the feed URL every 10 seconds.
Parsing the feed
The RSS module handles all the parsing and splitting. All we need is a feed splitter:
I did Unit Testing, but the Customer is still not happy
I have this web project. Pretty complex one. The code coverage is over 90%. Awesome! I even have a Continuous Integration set up. My code is built, and my tests make sure that functionally works as expected. I even have a well defined suite of UI tests using an internal renderer that is super fast. But, ohhh… today a Customer filled in a complaint saying that the site is not working well. Buttons are not responding, images are missing and the like. Catastrophe! This may be familiar to you? What am I missing here? I need external, not controlled-by-us browser behavior testing! How do I solve this problem? Or at least have an early warning that Sauron is about to be awake?
Here at Mulesoft, we use Jira for a lot of different things: tracking hiring, IT tasks, reporting product bugs, planning releases, etc.
We recently upgraded our Jira instances to the latest 4.2 version. One of my favorite new features is the ability to create your own search query in a SQL-like syntax. This allows you to customize your searches in all new ways. For example, if you wanted see your list of reported open bugs for the Community edition of Mule ESB, you could go to this page and use this query:
Mule 3.1 introduces a very useful new <logger> element that makes it easy to inspect the content and properties of your messages in Mule while building or debugging a flow. It’s also perfect for logging errors, info messages etc. Mule has always supported logging with the <log-component> but while working with the new orchestration capabilities of Mule 3 flows, we found a real need for fine grained logging. With the new message processor architecture, this was a snap and we were able to put together the new functionality in an afternoon. In this blog post I’ll take you on a quick tour of what you can do with it with some examples.
One of the joys of Mule 3’s new Message Processor (MP for short) architecture is the power that arises from being able to combine message processors into different patterns. To make this as flexible as possible, the routing message processors that were designed to be used in flows each do a single job, making them highly reusable. This allows you to build up a flow piece by piece, or alternatively modify an already working flow, without having to change its basic structure. Let’s look at an example.
A couple of weeks ago I started the integration between Mule ESB and Activiti BPMN. Activiti is a Business Process Management (BPM) and workflow system targeted at business people, developers and system admins. Its core is a super-fast and rock-solid BPMN 2 process engine for Java. It’s open-source and distributed under the Apache license. Activiti is being written from the ground up with the requirement that the engine should be easily embedded and that the project would be aimed at developers not the business. This is a very natural fit for MuleSoft since our approach to middleware starts with the developer. We have been working with the Activiti guys since July focusing in the integration aspects of the project.
The idea behind Mule’s Activiti transport is that you are able to perform several administrative actions in an Activiti server from Mule. For example, let’s suppose that you would like to retrieve the candidate tasks of the user kermit, do some processing and CLAIM a subset of those tasks. The following configuration will work for you:
We all recognize the need for both server and application monitoring in a production environment and Tcat Server makes this easy. However, the development and QA process can also benefit from this feature.
At MuleSoft I’m often asked to write small one-off webapps for different parts of our internal infrastructure — often they are interim solutions or somewhat experimental; since these are somewhat less critical applications, at best I’ll create some unit tests, create a plan on our CI Server, and do some “developer QA” — which amounts to clicking around the basic flow and cajoling some co-workers into basic sanity and acceptance testing. Since I’m also responsible for provisioning the server and deploying the application, I like to take as many shortcuts as I can. Fast and informal is the name of the game here.
However, lately I’ve been using Tcat’s Alerting with these applications in both the production and QA cycles. This has allowed me to spend less time tracking issues and to catch obscure errors and performance issues before I deploy into production.
There are some cool new features in Mule 3 for building AJAX applications. I figured I’d take you through a tour of the GPS Walker, an small example that demonstrates how to use AJAX to communicate from a Mule Service to the browser. This example uses other new features in Mule 3 including automatic JSON bindings, the @Schedule annotation and Flow.
The Mule IDE does not natively support Mule 3’s new application structure yet, but not to worry, with the new 2.1 release of the Mule IDE you can still keep it hot when working in the IDE. Just follow a few simple steps and your apps will be doing the tango with Mule 3 while you code away in Eclipse.
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.