Category: Mule ESB

You probably heard we have been moving into a faster release cadence with the new mountain ranges releases in this post and this one. For many Product Managers or Business Owners releasing faster could be the difference between success and failure. Being able to shorten the cycle between an idea and valuable user feedback enables new companies to understand better market needs and improve based on it. Releasing valuable software earlier is the sweet spot for and Lean methodologies.

Ross Mason on Monday, September 2, 2013

Mule at the Edge of the network

1

Mule is already running on premise and in the cloud and is soon bound to run virtually everywhere thanks to a new project called Edge. This initiative not only focuses on allowing Mule to run on lightweight platforms, like the Raspberry Pi, but also to support protocols and devices relevant to the embedded world, like MQTT and Zigbee. The “Internet of things” had its rabbit, it’s now going to have its Mule!

If you follow this blog, you may remember that we’ve already discussed before. We’ve introduced the Mule connector for this lightweight publish/subscribe protocol with an example where MQTT was used in the context of conference booth QR Code scanners. In this post, we’re circling back to this example but we add a new twist to it: we’re taking it to the Edge!

In the original architecture, Mule was running on a laptop, using its webcam to scan QR Codes but now that Mule is able to run on the Raspberry Pi, we will revisit the example to run on this tiny device. We will also use the brand new blink(1) connector, which will allow us to use this smart USB RGB LED to flash a visual confirmation when the scan correctly happened.

So let’s start by reviewing our architecture diagram and let’s unroll the example from there.

Mariano Gonzalez on Wednesday, August 28, 2013

OAuth 2 just got a bit easier

0

Ever since Devkit made its first entry into the Mule family, a big variety of OAuth enabled Cloud Connectors were made available. Salesforce, Facebook, Twitter, Dropbox, LinkedIn and Google Apps suite are just some of the APIs we’ve connected to using that support.

When we started thinking about the August 2013 release we decided to take it one step forward and make it easier than ever. And now that Mule 3.5-andes is available on , you’ll be able to leverage all these improvements into your integrations. On Premise users will also be able to use when the final version of Mule 3.5.0 is released as GA.

In his “To ESB or not to ESB” series of post, Ross Mason has identified four common architectures for which Mule is a great fit: ESB, Hub’n'Spoke, API/Service Layer and . In this post we are going to detail an example for the latter architecture. We will use Mule to build a scalable image resizing service.

Here is the overall architecture of what we intend to build:

As you can see, we allow end users to upload images to a set of load balanced Mule instances. Behind the scene, we rely on Amazon S3 for storing images waiting to be resized and Amazon SQS as the queuing mechanism for the pending resizing jobs. We integrate with any SMTP server for sending the resized image back to the end user’s email box. As the number of users will grow, we will grow the processing grid simply by adding more and more Mule instances: indeed, each instance is configured exactly the same way so the solution can easily be scaled horizontally.

Read on to discover how easy Mule makes the construction of such a processing grid…

You may have read about our mountain trek, new release cycle, and the increased pace of delivering. We’ve  climbed our first mountain and we’re happy to announce the availability of our first release in our trek: Andes! This delivers major usability improvements around our platform, new connectivity to applications such as Marketo and ZenDesk, and expanded API management capabilities. We’ll summarize what’s new for you here and we’ll be doing deeper dives over the coming days for you to learn more.

john.demic on Tuesday, July 16, 2013

Getting started with JPA and Mule

5

Working with JPA managed entities in Mule applications can be difficult.  Since the JPA session is not propagated between message processors, transformers are typically needed to produce an entity from a message’s payload, pass it to a component for processing, then serialize it back to an un-proxied representation for further processing.

Transactions have been complicated too.  Its difficult to coordinate a transaction between multiple components that are operating with JPA entity payloads.  Finally the lack of support for JPA queries makes it difficult to  load objects without working with raw SQL and the JDBC transport.

In the new enterprise, the “one big database” paradigm is being progressively eroded as it becomes more apparent that the ACID qualities of traditional SQL are not always needed, and can actually get in the way of massive scalability. In order to respond to the imperative of cloud deployments, new data stores have emerged.

One of them is Riak, a highly-available, fault-tolerant and scalable distributed key-value store built by Basho Technologies, Inc. on the design principles laid out in the famous Amazon Dynamo paper. One of the key features of Riak is that it “embraces failure” in the sense that, instead of sweeping under the carpet the problematic scenarios (like net-splits), it provides developers with the tools needed to deal with these issues as part of the normal operation mode instead of a leaving them to a (seldom addressed) failure mode. As such, data in Riak is said to be “eventually consistent” because it is only when all the pending replications have been done and the related conflicts have been resolved that data is consistent.

The new Riak Connector for Mule allows you to interact with this data store from your Mule applications, opening the door to new integration scenarios. Let’s review an example of such a scenario.

On my previous 3-part blog, I showed how Mule ESB can be used to service-enable and orchestrate traditional on-premise technologies like an Oracle database and IBM Websphere MQ. Using Mule ESB, we created a service that accessed employee information from an Oracle database table and transmitted this to IBM WebSphere MQ. An observant customer I was showing this to noticed a security flaw with how sensitive employee information was being transmitted in plain text and also asked how the employee record can be sent to SalesForce.com. This blog will show how these can be easily addressed using MuleSoft’s AnyPoint Platform. We’ll make use of the PGP encryption features from AnyPoint Enterprise Security to encrypt the data before sending it to WebSphere MQ. Then, we’ll create another message flow to retrieve this message, decrypt it and send it to SalesForce.com using the AnyPoint Connector for SalesForce.com.

Mule has a very extensive support for data stores, which covers pretty much the whole spectrum of what’s available out there, from key/value stores to document-oriented . The only piece that was missing in the puzzle was connectivity to a graph database: with the introduction of the Neo4j connector, the gap is now closed.

Popularized by the advent of social media, the need for efficiently storing, indexing, traversing and querying graphs of objects has become prominent in less than a decade. During this time, Neo4j has risen to the number one graph database on the market, with successful deployments across all types of industries and a strong commitment to open source.

The new connector, presented in this blog, allows Mule users to leverage the incredibly rich API that Neo4j offers with convenient configuration elements. Read on to discover a simple example built with this connector.

Have you already tried the Visual Flow Debugger? It’s one of the new shiny features that comes with Mule Studio Enterprise 3.4. Well, if you haven’t used it yet, this post is for you:

1. Message BrowsingAll the information you ever wanted, now at a click’s distance.

Before Visual Debugger, if you wanted to see the contents of the payload at each point you had to clutter your mule configuration with loggers all over the place, well, those days are over. Just put in a breakpoint et voilà!

You can also edit most values dynamically at runtime by clicking them.