Where’s your API?

Reading Time: 2 minutes

It has been a week since we’ve launched APIhub, and we’ve seen phenomenal responses from the ecosystem. Whether it is publishers claiming APIs for themselves to manage, or developers testing the interactive consoles – we are thrilled that the community is sharing the same excitement as we are! It is also testament to the fact that awareness of APIs are a necessity in today’s way of doing business – that API’s are not a nice to have today. Here at MuleSoft, we are seeing the New Enterprise continue to embrace APIs in everything they do – and this is only going to continue in 2013.

API Infographic

Announcing CloudHub Insight – Real Time Visibility, Message Replay and Root Cause Analysis

Reading Time: 7 minutes

We’re excited to announce the general availability of CloudHub Insight, a new CloudHub platform service. Today’s application integration requires a new kind of integration intelligence to answer questions about how your business is running, diagnose complex problems, and recover from cloud “thunderstorms.” CloudHub Insight provides a new level of visibility by tracking everything your data does, making it instantly searchable and provides advanced error recovery through Message Replay, taking the complexity out of addressing the real life challenges of SaaS integration.

Continue reading

Upcoming Webinar – Hybrid Cloud Integration is Coming: Are You Ready?

Reading Time: 2 minutes

The massive growth of APIs and SaaS applications has created a need to integrate anything, anywhere. This integration wave presents unique challenges for organizations looking to integrate both in the cloud and on-premise. Join Ross Mason, Founder & CTO of MuleSoft, as he discusses the emerging hybrid architectures designed to manage this challenge.

In this webinar, you will:

  • Hear what the API explosion means to you
  • Identify where your integration project falls in the hybrid use case spectrum
  • Learn cloud/on-premise integration best practices
  • Explore the MuleSoft solution: integrate anything, everywhere

Presenter: Ross Mason,  Founder and CTO, MuleSoft, Inc.

Date: Thursday, December 11, 2012

Time: 8 AM PST / 11 PM EST

Register now >>

Mule Component Bindings

Reading Time: 10 minutes

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.

Component Bindings provides a mechanism for Java components hosted in a Mule Flow or Service to make outbound calls to the ESB without needing to integrate with proprietary MuleSoft interfaces. With Component Bindings, you can define a Java interface that meets your requirements and your Java component is written to integrate with that interface. A Component Binding can be used to make a Mule outbound-endpoint the “implementation” for the interface, allowing you to write fully portable (and testable) Java components which can leverage the ESB without being “aware” of the ESB. Figure 1 shows the call flow when using a Component Binding.

Figure 1: Component Binding Call Flow

Using Component Bindings, you can easily create a clean separation of duties where Java code handles business logic and orchestrations, essentially acting as a “controller”, while the ESB handles inbound and outbound integration concerns (transports, transformations, security, transactions, etc). Here are a few benefits of this approach:

  • Since it creates a clean separation of duties, it can be easier to debug an implementation.
  • Because Java code is used for flow control instead of the ESB, it reduces the learning curve of Mule, while still getting the benefits of it for integration concerns. For large organizations, like Express Scripts, that need to make new developers effective quickly, this can be significant.
  • It makes it easier to test business logic and orchestrations using standard tools that many developers are familiar with, like JUnit.
  • It allows the Java code to be hosted outside of Mule, if need be.

Let’s take a look at an example. The sample project that I created for this post was inspired by a NPR story that I recently heard about the potential role that social media can play as a data point in predicting stock performance. It’s an intriguing idea for sure, but I won’t be making portfolio changes anytime soon based solely on Twitter.

The sample project exposes a RESTful API, using Mule’s Jersey Module, for fetching stock stats including both financial and social data. The diagram below shows the architecture. The API client provides a stock symbol and an as-of date. The implementation first fetches the financial information using the Stocklytics API. Next, the implementation gets up to 1000 tweets from Twitter using Twitter’s relatively new $ “cashtag” for stocks. The Twitter integration uses Mule’s Twitter Cloud Connector. Finally, the implementation batches all tweets and determines the sentiment for each of them by making a single call to the Sentiment140 API.

Figure 2: Sample Project Overview

Figure 3: Sample Project Request/Response

The heart of the sample project is in the stockstats.impl.StockStatsResourceImpl Java class which contains all of the business logic and orchestration code. (See the unit test for this class in StockStatsResourceImplTest.java.) This class integrates with three Java interfaces: StockService, TwitterService and SentimentService. The StockService and SentimentService interfaces have implementations that integrate with the Stocklytics and Sentiment140 APIs respectively. These implementations are injected into the StockStatsResourceImpl class using Spring Framework. A Component Binding is used to implement the TwitterService interface and inject it into the StockStatsResourceImpl class.

Figure 4: Component Binding Example

The snippet from the StockStats.mflow file shown in Figure 4 provides an example of creating the Component Binding for the TwitterService interface. In this example, we define a Component which is tied to a Spring bean called “stockStatsResource” which is an instance of stockstats.impl.StockStatsResourceImpl and is defined earlier in the file. The “binding” node tells Mule to create a Component Binding for the TwitterService interface and inject it into the stockStatsResource bean. Mule will forward any calls to the TwitterService.search method to the outbound-endpoint specified. In this example, the VM outbound-endpoint delegates to another flow which then uses Mule’s Twitter Cloud Connector to integrate with the Twitter API. Figure 5 shows the call flow at runtime.

Figure 5: TwitterService Binding Call Flow

There are a few noteworthy items about Component Bindings:

  • Component Bindings are not yet supported by Mule Studio, so you’ll need to edit the Flow XML directly in order to use them.
  • It is important that exceptions that occur downstream of the Component Binding are bubbled up into the Java tier. You should test this. Versions of Mule prior to 3.0 may not handle this as you would expect.
  • You are limited to injecting bindings into Java Components that Mule knows about, but wouldn’t it be great to have the ability to inject a binding into any Spring bean — even beans that Mule has no direct visibility to? At Express Scripts, we developed a feature that we call “Global Interface Bindings” to do exactly that. Look for this feature to become available, either on Mule Forge or part of the core ESB, in the future.

Complete project can be viewed from Github.

Hopefully this post has demonstrated the potential benefits and technical details of Mule’s Component Bindings feature. The ability to host portable Java code that can leverage the ESB for integration concerns without being tied to proprietary APIs is a key feature for Mule in the ESB space.

This is a guest post from Mule community member Steven Sefton. Steve is a Tech Lead at Express Scripts with over 14 years of IT experience. He has been a proponent of Mule since 2009. Thank you Steve. You bagged yourself a cool T-Shirt.  If anyone else in the Mule community would like to write a guest post, please email us.

Mule School: The MuleMessage, Property Scopes and Variables

Reading Time: 10 minutes

Last updated: August 11, 2016

Overview

Mule Properties and Flow Variables are one of the most widely used features in Mule. Nevertheless, Mule newcomers may have a hard time understanding how the different property scopes and variables compare to each other, and how to choose the right one for their use cases.

The idea behind this blog post is to clarify those differences, comparing side by side INBOUND, OUTBOUND, INVOCATION and SESSION property scopes. We will also cover “flow variables” and “session variables”. For more detailed information, you can go to each scope´s section in the User’s Manual.

Quick Recap: Mule Message Anatomy

The MuleMessage is the object used to pass any data through Mule.  It enables universal access to any type of message format an encapsulates properties and attachments associated with the current event being processed. Let’s do a quick review of what a Mule message looks like:

mule message anatomy

A Mule message consists of three parts

  • the header, which contains sets of named properties, partitioned into scopes
  • the payload, which consists of business-specific data
  • optional attachments
You can find more information in this document.

In this article, we will focus on the message properties contained in the message header and how to choose the right scope for them.

The Transport Barrier

One key concept you must bear in mind to understand what follows is something I will call “transport barrier.” It´s just a fancy way of saying we are sending a message across a transport. Calling subflows, for example, does not cross the “transport barrier”. Sending a message across an endpoint does cross the “transport barrier”.

In the following examples, we will use a VM transport as a “barrier”.

Mule Inbound Properties

  • Inbound properties can’t be set by you.
  • Message sources (such as inbound endpoints) set them for you when they receive a message.
  • Inbound properties are lost when crossing a “transport barrier.”

Mule Outbound Properties

  • Outbound properties can be set by you.
  • When crossing a “transport barrier”, outbound properties are automatically turned into inbound properties, and no longer exist as outbound properties.

Mule Invocation Properties

  • Invocation properties can be set by you.
  • Invocation properties are lost when crossing a “transport barrier”.

Mule Session Properties

  • Session Properties can be set by you.
  • Session properties are preserved when crossing a “transport barrier”.

Mule Flow Variables

  • They behave like instance properties.

Mule Session Variables

  • They behave like session properties.

Examples

The following examples are contained in the Mule Scopes Demo App. Feel free to download it and examine its configuration (we suggest using Mule Studio to import the example project).
All examples use a similar structure:
  • An HTTP call is received.
  • Optionally set some properties/variables (with different scopes).
  • Log the message contents to see which properties/variables are present.
  • Cross a VM “transport barrier”
  • Log the message contents on the other side to show the effects on the different scoped properties/variables of crossing the “transport barrier”.

Inbound-Scoped Properties Example

See flows “MuleScopesFlow1” and “MuleScopesFlow2”.
Since inbound properties cannot be set by you, we will just use the ones that have already been set for us by the HTTP Inbound Endpoint. Let’s take “http.method” as an example.
With your app running, open the following URL (or use curl): http://localhost:8081/inbound
  • The first flow log entry will contain http.method as an inbound property.
  • The second flow log entry will not contain http.method, since it was lost crossing the “transport barrier”.
Therefore, this property will be accessible in the areas highlighted below.
Inbound Property Example

Outbound-Scoped Properties Example

See flows “MuleScopesFlow3” and “MuleScopesFlow4”.
We will set an outbound property called “Meal” to “Soylent Green” and see what happens.
With your app running, open the following URL (or use curl): http://localhost:8081/outbound
  • The first flow log entry will contain “Meal” as an outbound property.
  • The second flow log entry will also contain “Meal”, but this time as an inbound property, since it was converted crossing the “transport barrier”.
Therefore, this property will be accessible in the areas highlighted below.
Outbound Property Example

Invocation-Scoped Properties Example

See flows “MuleScopesFlow5” and “MuleScopesFlow6”.
We will set an invocation property called “Organism” to “Plankton” and see what happens.
With your app running, open the following URL (or use curl): http://localhost:8081/invocation
  • The first flow log entry will contain “Organism” as an invocation property.
  • The second flow log entry will not contain “Organism” since it was lost crossing the “transport barrier”.
Therefore, this property will be accessible in the areas highlighted below.
Invocation Property Example

Session-Scoped Properties Example

See flows “MuleScopesFlow7” and “MuleScopesFlow8”.
We will set a session property called “Profession” to “Therapist” and see what happens.
With your app running, open the following URL (or use curl): http://localhost:8081/session
  • The first flow log entry will contain “Profession” as a session property.
  • The second flow log entry will also contain “Profession” as a session property since it was preserved when crossing the “transport barrier”.
Therefore, this property will be accessible in the areas highlighted below.
Session Property Example

Flow and Session Variables Example

See flows “MuleScopesFlow9” and “MuleScopesFlow10”.
Remember, flow and session variables behave just like invocation-scoped and session-scoped properties, respectively. We will set a flow variable called “Years” to “7500000” and a session variable called “Answer” to “42”, and see what happens.
With your app running, open the following URL (or use curl): http://localhost:8081/variables
  • The first flow log entry will contain “Years” as an invocation-scoped property (this is correct since “flow variables” is just a friendlier name for invocation properties).
  • The second flow log entry will not contain “Years” since it was lost when crossing the “transport barrier”.
  • The first flow log entry will contain “Answer” as a session-scoped property (this is correct since “session variables” is just a friendlier name for session properties).
  • The second flow log entry will also contain “Answer” as a session-scoped property (this is correct, since “session variables” is just a friendlier name for session properties) since it was preserved when crossing the “transport barrier”.
Therefore, these variables will be accessible in the areas highlighted in the two diagrams below.
Flow Variables Example
Session Variables Example
I hope this helps you understand how the MuleMessage works as well as aiding you to choose the right scope for your properties and variables.

Making SFTP testing portable

Reading Time: 2 minutes

Our integration tests should be portable, meaning that if we shared our project, everyone would be able to run our tests on any platform without needing to install any framework or application. This is a very common issue when we test flows that have an SFTP outbound endpoint. In order to do an integration test of our flow, we need to start an SFTP server on our machine or use a public SFTP server, which implies adding network overhead to our tests.

A simple solution to portable SFTP testing is embedding an SFTP server into our tests. A good and really light weight framework to do so is Apache Mina.

Let’s suppose we want to test the following flow:

Could not embed GitHub Gist 1667047: Not Found

We want our test to look something like this:

Could not embed GitHub Gist 1667086: Not Found

With Apache Mina we can make this test portable by creating this class:

Could not embed GitHub Gist 1667101: Not Found

And calling it from our functional test:

Could not embed GitHub Gist 1667122: Not Found

Now you can share your flow test with the world.

How to Build Multi-Tenant iApps using Mule Studio

Reading Time: 7 minutes

When building applications in the cloud, a common challenge is to create applications that can serve multiple customers with just one instance of the application running.  Now with Mule Studio and CloudHub, the effort required to do just that has been greatly reduced.  Here I will like to walk through one example to illustrate how easily it can be done.  For this example, we will use Zuora, a popular SaaS billing system for subscription services, and Amazon RDS MySQL to demonstrate the steps involved.  We will build a simple Data Warehousing integration App (iApp) that will retrieve invoice records for different Zuora customers and store them in a relational database (e.g. for reporting purpose).   Please note that the information presented here is general enough that the same basic configuration can work with other SaaS systems.

Continue reading

Cross domain REST calls using CORS

Reading Time: 7 minutes

To fight XSS attacks, the web browser imposes the same origin policy for HTTP requests made by JavaScript code:

But there are a lot of use cases where this kind of cross domain HTTP request is desired, so developers came up with some workarounds:

  • Server side proxy: the idea is to avoid cross domain requests in the browser by doing them on the server:To do that in Mule you can use the HTTP proxy pattern as explained in this post.
  • JSONP: it consists of adding a <SCRIPT> tag dynamically. The src attribute of the script tag can point to another domain, and the browser will load and execute the JavaScript code that comes from it. But here is the twist: since the script can be generated dynamically on the server, you can use it to pass data to the JavaScript program in the browser.
    The suffix means padding, because the server needs to pad the returned JSON with a function call to make it a executable JavaScript code.Then your JavaScript code provides the definition of the function that gets called with the data.
    Clever trick right? But it has some limitations: only GET requests can be done in this way.

Is there another option?

Fortunately, yes. Modern browsers supports a W3C Working Draft  called CORS: Cross-Origin Resource Sharing, and probably the browser that you are using to see this page already supports it.

How CORS works?

The browser sends the request adding the Origin header:

If the origin is accepted by the  HTTP server it adds the Access-Control-Allow-Origin header to the response:

When the browser receives this header it continues reading the payload of the HTTP response, if not the request is rejected.

How it looks in your JavaScript code? If you use jQuery is business as usual:

jQuery is smart enough to detect the kind of CORS support that your browser has and uses XMLHttpRequest or XDomainRequest if the page is running in IE8.

“You’re allowed a wand…”

In Harry Potter and the Goblet of Fire movie, there is an scene were Harry is about to fight a dragon, and he best chance to win is to flight with the broom:

Harry: – But I’m not allowed a broom.
Professor Moody: – You’re allowed a wand…

Having access to an external domain in your JavaScript code, is like having a wand. Even if your web server is limited to deliver static HTML content, you can create powerful web applications using JavaScript and REST APIs located elsewhere.

I’m going to show you that with a simple example. It consist of a HTML file shared on Dropbox, which is not a hosting service but allows you to share static content. And from that file we are going to call a service hosted in Cloudhub.

Create a Cloudhub application using MuleStudio

Create a new project with MuleStudio and add a flow with a HTTP endpoint. To make it work with Cloudhub you have to use ${http.port} as port number for the endpoint:

Expose your REST API

In this example I’m going to use a JAX-RS, just because I’ve a background on Java programming and I’ve used JAX-RS services before. But, a good alternative to try is the REST module from MuleForge.

Following the JAX-RS way of things, we need a Java class to define the resources:

Then we need to wire it into the flow using a REST component:

Add Access-Control-Allow-Origin header to the response

An here comes the most important part, we need to add the Access-Control-Allow-Origin header to the response. To do that we are going to use a HTTP Response Builder:

In this case we are using https://dl.dropbox.com. Take account that: you can put multiple origins separated by space, and that http is a different origin than https.

Deploy to Cloudhub

On MuleStudio, right click into the project and choose “Deploy to Cloudhub…”

Fill up the credentials, and we are done with the service. Next step the client code.

Client code

The client code is straight forward:

This example takes the list returned by the server and shows a list from it.

You can see the running example here. That’s all folks!

Love your dataloader even more – New Dataloader.io October Release

Reading Time: 7 minutes

I’m very excited to announce that the October release of Dataloader.io is now available! It includes many  new features,  UI enhancements and bug fixes, which we hope it’ll make you love your data loader even more.

Continue reading

Migrating Subversion projects to Github

Reading Time: 3 minutes

Picking up where Dirk Olmes left off in the post, Migrating a MuleForge project to Github, we now suggest a utility to facilitate the migration: svn2git.

svn2git is a tiny utility for migrating projects from Subversion to Git while keeping the trunk, branches and tags where they should be.

This involves three basic steps:

  1. Getting the svn repository
  2. Creating a Git repository
  3. Pushing the trunk, tags and branches (previously added)

Step 1 is where svn2git is very appropriate.  To use it, you just need to execute the command “svn2git” followed by the url of the svn repository and the utility does the rest. Great, isn’t it?

Step 2 is really easy. You simply go to github.com and, after logging in with a github account, create a repo following the help.github guide.

What Step 3 first requires you to add the directory to the git repository by executing

Next, the only thing left is to push all by executing

In most cases that’s it! The work is done. But we had some trouble while migrating our project. After executing Step 1, we received this error message:

After checking the process in more detail (adding –v to the command) we found the specific place where the mistake appeared:

To solve this, you only need to execute the fetch this way:

Problem solved!

Hope this helps. Good luck.