Optimize Resource Utilization with Mule Shared Resources


In 3.5 we introduced the concept of domains in the Mule container. You can now set up a domain and associate your Mule applications with a domain. Within a domain project you can define a set of resources (and the libraries required by those resources) to share between the applications that belong to the domain.

Within the mule-domain-config.xml you can define a JMS broker connector that can be reused by all the Mule applications that belong to that domain.

Pass the salsa – 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!

Chips and Salsa? Find Them On the ‘Hybrid Cloud’ Aisle

Many enterprises wonder whether to make new investments in public cloud technology or continue investing in their private cloud infrastructure. In reality, the answer is “both” and the solution is hybrid cloud.

Infographic: The API Revolution

There’s an app for everything today, but to do all of this your phone needs to connect to other programs and servers. Welcome to the API revolution.

Mule Meets Zuul: A Centralized Properties Management – Part II, Client side


Before reading on, please take a look at Part 1 of this post.

Connecting Mule application to Zuul server requires two additional jars in the application class path. One of them is jasypt library which can be downloaded here. The second one is zuul-spring-client. You can download the source and build the jar using Maven.

To configure Zuul client, first add zuul namespace to the mule tag. You will also need spring and context namespaces.

Mule Meets Zuul: A Centralized Properties Management – Part I, Server side


It is always recommended to use Spring properties with Mule, to externalize any configuration parameters (URLs, ports, user names, passwords, etc.). For example, the Acme API from my previous post connects to an external database. So instead of hard-coding connectivity options inside my application code, I would create a properties file, e.g. [[code]]czoxNTpcImFjbWUucHJvcGVydGllc1wiO3tbJiomXX0=[[/code]], as follows:

Obviously, as a developer, I would use a test instance of Acme database to test my application. I’d commit the code to the version control system, including the properties file. Then my application would begin its journey from the automated build system to the Dev environment, to QA, Pre-Prod, and finally Prod – and fail to deploy on production because it wouldn’t be able to connect to the test database! Or even worse, it would connect to the test database and use it and no one would notice the problem until customers placed $0 order for an Acme widget which would normally cost $1000, all because the test database didn’t contain actual prices!

What do the Kiwis really know about APIs?


It turns out quite a bit.

Media companies, postal services, newspapers and other print publishers have been talking about monetizing digital assets both to create new revenue opportunities and, quite frankly, to remain relevant in the age of the digital prosumer.

In a connected world, the atmosphere is made of smart dust


I came across this article recently that highlights where connectivity could go, even beyond the 50 billion connected things expected to be on the planet by 2020.

The author described something called Smart Dust. Tiny microscopic sensors floating through our cities, tracking and collecting all kinds of data.

“He and his team use Dust, portable packets of sensors that float in the air throughout the entire city and track movement, biometric indicators, temperature change and chemical composition of everything in their city.“

Sweet & Simple: Using SOQL Relationship Queries with Salesforce.com Connector


The best things in life are often sweet and simple. However, “S & S” is an easy concept to understand and appreciate but often hard to implement. For example, a sweet and simple way to attract traffic to our blog would be to show women in bikinis playing with cats. In reality that is rather hard to pull off for a technical site. There simply is no budget to publish anything like “API Illustrated, Swimsuit Edition” or “ESBN, the Body Issue”. Instead, this article will focus on sweet and simple features in our products that can make life easier for integration developers.

With 100,000+ customers, Salesforce.com is one of the most popular integration endpoints for ESB implementations.  There are a couple of commonly asked questions when it comes to Salesforce.com: how do you reduce the number of API calls since there are daily limits per instance, and how do you retrieve all the related records in one query?  The SOQL Relationship Queries help accomplish both goals, as a developer can make just one API call against different SObject types that are also related.

Enabling Transactions in Node.js using Domains


At Mulesoft we have open source software deep in our DNA: Our core product source code is on github. We have hundreds of public projects there as well, and we have contributed to many open source projects including Node.js itself. We’re excited about Node.js and have several large, sophisticated Node.js projects in development. Our use of cutting edge Node.js features has resulted in both a lot of knowledge gained and, no surprise, a lot of pain experienced.

MuleSoft Powers Box’s Cloud Connect


Box is one of the leading content and collaboration providers for enterprise, giving users the ability to store and share files from both personal computers and mobile devices like smartphones and tablets. With over 200,000 business clients and enterprise grade security and architecture, Box is a great example of how rising Silicon Valley stars use MuleSoft’s Anypoint Platform for internal and external integration needs.

As Box is onboarding an ever increasing number of Global Fortune 500 companies, the need for MS SharePoint integration is growing rapidly. These large companies have traditionally made large investments in SharePoint, but are now looking to Box to meet the needs of a more mobile, collaborative workforce. For most organizations with both SharePoint and Box, integration is difficult or non-existent.

Parallel Multicasting in Mule Made Easy


A common integration scenario is where a single message needs to be sent through multiple routes.

Take for example a case in which you’re receiving a message about a new client’s on-boarding. The message needs to be routed through the CRM to create the client, to marketing who will want to know how the client heard about the company, and finally passed to provisioning and stock systems so they can work their magic as well.

In this case, the message is broadcasted in a “fire and forget” fashion, meaning you don’t need a response from any of these systems to continue your processing. Each of those systems are responsible for handling their own logic and their own errors. In Mule ESB, you could do this like this:

There are other cases, however, in which you do need the response from the routes. Suppose you’re using a travel booking application and somebody wants a direct flight from Buenos Aires to San Francisco. Your app needs to contact all known airline brokers, get availability for those flights and choose the cheapest one. The <async> scope is insufficient for you in that case because you want the thread processing the request to actually wait for the responses to arrive. Sounds like a job for a multicasting router!