APIs Can Be Copyrighted… Now What?

May 13 2014

6 comments 0

The battle between software giants Oracle and Google hit close to home again last week, when a Federal Court of Appeals overturned a 2-year-old ruling by a lower court and established that APIs are entitled to copyright protection. The first reaction from most people is: how strange! After all, APIs are just the specification of how a software system or service behaves – call it this way, send it this information, get back that information – so how is that possibly something copyrightable? It’s not like a book, or a painting, or even software… And the second reaction, from many in the API world, is: no!!!

[Podcast] How to Integrate Buyer Data – The 500 Billion Dollar Question


Overcoming challenges with integration is no easy feat. Data driven by SaaS, Cloud Computing and Mobility results in an abundance of customer information. The challenge no longer lies in obtaining buyer information, but in integrating all of the data endpoints.

Integration across disparate systems is crucial to better understand customers, observe behavior, analyze data and create the optimal customer experience. However, not all marketing tools are designed to communicate with others. A whopping 500 billion dollars a year is spent trying to solve this problem.

Crimson Marketing, experts in marketing technology, sat down with MuleSoft’s Mahau Ma, VP of Marketing to chat about this problem and how it manifests itself:

  • MuleSoft for example, uses over 100 SaaS applications, a website on Drupal, a blog on WordPress, interactions though Marketo and Salesforce, a content engine on Insightera, and customer forums, to name just a few demand generation tools.
  • Retail “Omni Channel” operations: A company might have SAP at the core, legacy EDI systems, modern API technologies, social marketing channels, mobile channels, an E-commerce engine, a payments engine and interactions in a brick and mortar store as individual components of their product marketing machine.
  • The Healthcare industry: Having a 360° view of the buyer can literally be a matter of life and death. Ma details a case where his top five Pharma clients had to maintain product marketing data from over 8,000 websites, social channels, mobile apps and physician channels to ensure not only a great buyer experience and optimized demand generation, but also to avoid potentially fatal errors.

Listen to the entire podcast »

Anatomy of an Anypoint Template


Templates are simple solutions to start building your own integration applications that help to accelerate ‘time to value’ for your company. We focused on creating templates in a particular way to meet a high quality bar and to help you maintain that bar when you choose to extend our templates or build your own. In this post, I wanted to run you through our principles, structure, and provide some advice when using one of our templates.

5 (Internet of) Things you can Hack


There may well be 50 billion device coming, but the most exciting things in the Internet of Things are the ones you can hack. I’ve developed a new weekend hobby of connecting and hacking devices. Here are my top 5:

Philips Hue
These connected lights bulbs have an HTTP API that is really easy to use and allows you to control single and groups of lights. You can control the colour range, brights and hue of course.  Furthermore your partner will love the pretty colours and you’ll convince your kids you can do magic.


Google Glass
Yes this is the device that is paradoxically cool not cool. It has a REST API that gives you access to post items to the Glass timeline and subscribe to location and updates from it.  The REST API is pretty limited, but luckily Glass runs Android and has a GDK for writing apps for the device itself, which greatly extends the possibilities.

Intro to Data Integration Patterns – Aggregation


In this post I want to close the loop on introducing you to the last of the five initial patterns that we are basing our Anypoint Templates on. I’m sure we’ll continue creating templates and we’re going to continue discovering new data integration patterns. If you are just entering at this post, I would recommend that you look through the previous four posts to understand the other patterns. I generally do not repeat things that overlap between a patterns, so I would encourage you to work your way through all five posts if interested.

Pattern 5: Aggregation

What is it?

Aggregation is the act of taking or receiving data from multiple systems and inserting into one. For example, lets say I have my customer data in three different systems, and I wanted to generate a report which uses data from all three of those systems. I could create a daily migration from each of those systems to a data repository and then query against that database. But then I would have a whole other database to worry about and keep synchronized. As things change in the three other systems, I would have to constantly make sure that I am keeping the data repository up to date. Another downside is that the data would be a day old, so if I wanted to see what was going on today, I would have to either initiate the migrations manually or wait. If I set up three broadcast applications, I could achieve a situation where the reporting database is always up to date with the most recent changes in each of the systems. Still, I would need to maintain this database whose only purpose is to store replicated data so that I can query it every so often. Not to mention the number of wasted API calls to ensure that the database is always up to x minutes from reality. This is where the aggregation pattern is really handy. If you build an application, or use one of our templates that is built on it, you will notice that you can just on demand query multiple systems merge the data set, and do as you please with it. So in our example above, you can build an integration app which queries the various systems, merges the data and then produces a report. This way you avoid having a separate database, you can have the report arrive in a format like .csv, or format of your choice. Similarly, if there is a system where you store reports, you can place the report there directly.

Intro to Data Integration Patterns – Correlation


So far, in this series, we have covered Migration, Broadcast, Bi-Directional Sync, and today we are going to cover a new integration pattern: Correlation. In an effort to avoid repeating myself, for those who are reading through the whole series, I will omit a lot of relevant information which is shared between the patterns that I have previously covered. I urge you to read at least the previous post about bi-directional sync as correlation can be viewed as a variation of bi-directional sync. Also, note that this is the only one of the five patterns that we have not released any templates around, this was done in the interest of time, and due to the belief that this may be the least common pattern for Salesforce to Salesforce integration. We are however looking to create and release templates using the correlation pattern in the next few months.

Pattern 4: Correlation

What is it?

The correlation pattern is a design that identifies the intersection of two data sets and does a bi-directional synchronization of that scoped dataset only if that item occurs in both systems naturally. Similar to how the bi-directional pattern synchronizes the union of the scoped dataset, correlation synchronizes the intersection. Notice in the diagram below that the only items which will be meet the scope and synchronized are the items that match the filter criteria and are found in both systems. Whereas with the bi-directional sync will capture items that exist either in one or both of the systems and synchronize. In the case of the correlation pattern, those items that reside in both systems may have been manually created in each of those systems, like two sales representatives entering same contact in both CRM systems. Or they may have been brought in as part of a different integration. The correlation pattern will not care where those objects came from, it will agnostically synchronize them as long as they are found in both systems. Another way to think about Correlation is that is like a bi-directional sync that only does updates existing matches, rather than creates or updates.

CONNECT 2014: Join the Integration Revolution


CONNECT 2014 is only a month away and the tempo is picking up pace. It’s going to rock and here at MuleSoft, we’re getting pretty excited! 

Come see how you can amplify innovation:

  • Hear from thought leaders from the most innovative companies (Salesforce, Tesla, Box, Stripe and more!)
  • Gain insight from over 15 customer case studies and 30 unique breakout sessions – we’ve got everything from business transformation strategy to hands-on product demos and workshops.
  • Problem-solve with MuleSoft employees and technology partners

And the icing on the conference cake? How about seminal rockers … CAKE! Come party into the night and be a part of the integration revolution! 

Still not convinced? Check out this video and start daydreaming today »

Follow the conversation on Twitter with #CONNECT14


Building APIs around Microsoft Azure SQL Databases

April 30 2014

4 comments 0
  • Connect to Microsoft Azure SQL Database using MuleESB
  • Expose a simple API around our Microsoft Azure SQL Database (for the remainder of this post I will call it Azure SQL)

Intro to Data Integration Patterns – Bi-Directional Sync


In this post I will continue talking about the various integration patterns that we used as the basis for our Anypoint Templates. The next pattern to discuss is bi-directional sync. Since bi-directional sync can be also accomplished as two, 1:1 broadcast applications combined and pointed in opposite directions, I would recommend reading my last post on the broadcast pattern before digging into this one since I will omit a lot of the same content.

Pattern 3: Bi-Directional Sync

What is it?

Bi-directional sync is the act of unioning two datasets in two different systems to behave as one while respecting their need to exist as different datasets. The main driver for this type of integration need comes from having different tools or different systems for accomplishing different functions on the same data set. For example, you may have a system for taking and managing orders and a different system for customer support. For one reason or another, you find that these two systems are best of breed and it is important to use them rather than a suite which supports both functions and has a shared database. Using bi-directional sync to share the dataset will enable you to use both systems while maintaining a consistent real time view of the data in both systems.

Dinosaurs in the Land of APIs – Top Integration and API Articles of the Week


Here’s our weekly roundup of the top 5 integration and API articles of the week.  Take a look, let us know if we missed any, and share your thoughts in the comments.  Don’t forget to follow @MuleSoft to stay up-to-date on integration & APIs!

If you’re interested in Integration and APIs, don’t miss CONNECT 2014 – the event behind the integration revolution!

Un-API Dinosaurs Can’t Leap The Legacy Chasm

How can long-established enterprise IT vendors adapt to a world of nimble startups and avoid extinction? They can’t.


Transform Your Bicycle Into A Connected E-Bike

Bicycles have joined the Internet of Things, providing valuable data for both riders and cities.