If you share your code on GitHub with other developers, you may want to be notified about commits. GitHub has a built in feature to provide notifications or send an e-mail about these commits. I wanted to see, if I could leverage MuleSoft to introduce notifications through alternative channels, particularly through Twitter.
I implemented two solutions. Each has some pros and cons. You need to decide, which one works better for you. The description of the first one comes in this post.
IoT Lights demo @ MuleSoft HQ
To liven up the 2nd floor of the MuleSoft SF office, we decided to showcase a slightly modified version of the IoT demo we gave in last year’s Chicago and New York MuleSoft Summits. The demo we have listens for any mentions of @mulesoft on Twitter. If found, a Mule app running on a Raspberry Pi makes the lights glow. Initially dim, the lights glow brighter with more mentions.
Now let’s dive into the specifics of this fun little demo we’ve created.
The genesis of this demo was a brainstorming session for a MuleSoft Summit keynote presentation. We wanted to show something that showcased IoT in conjunction with MuleSoft technology. We decided to simulate home automation via APIs, which essentially means using Internet of Things APIs to control the “things” around one’s home. In our case, the “things” we were controlling were Philips Hue light strips (which we shaped to form the MuleSoft logo). In addition, as is typical in many IoT architectures, we used a “controller” closely located to these “things” – think of how a Nest device (controller) manages the heaters (things) around a home. In our case, the controller we used was a lightweight Mule app running on a Raspberry Pi, which connects to both the external network to receive information, and to the internal network to control the lights.
I had the privilege of speaking at the Mule Summit in Chicago a few weeks ago. During my presentation, I covered some key Mule ESB features we leverage at Express Scripts: Component Bindings and Custom Configuration Patterns. Few conference attendees were familiar with these features, so we thought blog posts would help share information about these features with a broader audience. In this post, I’ll focus on Component Bindings. A future post will cover Custom Configuration Patterns.
This tutorial is the first in a series of blog posts that explain how to integrate Mule and Social Media.
Today’s post will focus on connecting to Twitter and sending a tweet (if you don’t know what Twitter is read this). Subsequent tutorials will cover:
Complex event processing engines are a natural fit for event driven platforms like Mule. Native CEP support has been available in Mule since version 3.2 by way of the Drools Module. The Esper Module now offers an alternate way to leverage CEP in your integration applications. Esper is a robust, performant, open source, complex event processing engine. Let’s take a look at how to use Esper with Mule and then see how it compares to Drools’ CEP support.
Here at MuleSoft, every few months we take a couple days off and hold a company Hackathon. Usually these are individual efforts to build something unique and interesting using the technology and products that we create at MuleSoft.
To kick off the new year, we decided to sponsor a team event and see if we could get some creative new ideas that might be more then a single person could implement in a day. The goal was to develop an iApp that demonstrated the power of the Mule iON platform. iApps are integration solutions developed on iON that solve a common problem and can be provisioned for use by different customers. The results were pretty inspiring making it difficult for those of us on the judging panel to choose a single winner.
There was a lot of buzz a few years ago around real-time web and since then it has been bubbling along. I have a financial/enterprise background so real-time has a very different meaning to me; time is measured in microseconds. Web real-time seems to be measured as sub 1 second . My issue with real time web to date is only parts of the web are web-real time. While the data can be delivered to the browser using push technologies such as comet and web sockets, the vast majority of REST and soap API that provide access to application data still use the HTTP request response model.
That’s starting to change with more public streaming APIs appearing. A streaming API (aka HTTP Push) works by the client opening a socket, providing some criteria of the data it wants to receive and the server will deliver new data as it is received over the open socket. For those familiar with publish-subscribe models of delivering data, this all sounds familiar.
The Mule team is very pleased to announce the general availability of Mule ESB 3.1. This release packs a lot of new shiny awesomeness.
We received loads of great feedback on Mule Cloud Connect and the team has been working hard on new improvements. Cloud Connectors now have specific XML schemas making it really easy to orchestrate data services between cloud and enterprise applications. This means Cloud Connectors can now be used in flows. For example, to create a new Twitter component for use in a flow use the following:
Most websites offer RSS or ATOM feeds for news or updates, and iBeans makes it easy to consume these feeds. In this example, I will create a simple object that will read new entries from my blog and publish a summary of them on Twitter. Note that the example assumes that you have iBeans installed.