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.
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:
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.
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.
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.
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 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 »
In this post we are going to discuss a few emerging trends within computing including cloud based Database platforms, APIs and Integration Platform as a Service (iPaaS) environments. More specifically we are going to discuss how to:
- Connect to a Microsoft Azure SQL Database using Mule ESB (for the remainder of this post I will call it Azure SQL)
- Expose a simple API around an Azure SQL Database
- Demonstrate the symmetry between Mule ESB On-Premise and its iPaaS equivalent CloudHub
For those not familiar with Azure SQL, it is a fully managed relational database service in Microsoft’s Azure cloud. Since this is a managed service, we are not concerned with the underlying database infrastructure. Microsoft has abstracted all of that for us and we are only concerned with managing our data within our SQL Instance. For more information on Azure SQL please refer to the following link.
In order to complete all of the steps in this blog post we will need a Microsoft Azure account, a MuleSoft CloudHub account and MuleSoft’s AnyPoint Studio – Early Access platform. A free Microsoft trial account can be obtained here and a free CloudHub account can be found here. To enable the database connectivity between MuleSoft’s ESB platform and Azure SQL we will need to download the Microsoft JDBC Driver 4.0 for SQL Server which is available here.
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.
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!
How can long-established enterprise IT vendors adapt to a world of nimble startups and avoid extinction? They can’t.
Bicycles have joined the Internet of Things, providing valuable data for both riders and cities.
The best way to plan your journey to CONNECT is knowing what you’re interested in.
If you’re interested in hearing from thought leaders…
don’t miss the keynotes! CONNECT will host leaders from some of the most innovative companies, including:
- Ross Meyercord, CIO Salesforce
- Jay Vijayan, CIO Tesla
- Ben Hayes, CIO Box
- John Collison, Co-Founder Stripe
- Ross Mason, Founder MuleSoft
- Uri Sarid, CTO MuleSoft
don’t miss our 15 customer case studies, where you’ll hear from customers on how they drive customer engagement, amplify the pace of innovation, and create new revenue channels through integration.
In my post yesterday, we did a brief introduction to the migration pattern. Today we are going to do a similar overview of the broadcast pattern which is a kinetic version of the migration pattern.
Pattern 2: Broadcast
What is it?
Broadcast can also be called “one way sync from one to many”, and it is the act of moving data from a single source system to many destination systems in an ongoing, near real time or real time, basis. Typically “one way sync” implies a 1:1 relationship and to us it is just a instantiation of the broadcast pattern which is a 1:Many relationship, hence we chose the name broadcast even though it will manifest itself as a 1:1 in many integration applications like our Salesforce to Salesforce templates that we recently made available.