We’re happy to announce the release of Anypoint Studio July 2014 and Mule ESB 3.5.1.  The Anypoint Studio release now contains support for finding Anypoint Templates to help you rapidly integrate systems as well as many usability and productivity improvements. The July 2014 release of Anypoint Studio also contains the Mule ESB 3.5.1 release, which builds on the 3.5.0 release with many bug fixes.

Anypoint Studio July 2014

The July 2014 release Anypoint Studio release contains many improvements targeted at improving your productivity on Anypoint Platform.

Anypoint Templates browser

You can now find Anypoint Templates, templates built to address the most common integration use cases and to help you get successful on Anypoint Platform quickly. You can access the templates by clicking the library button on the toolbar at the top left of Studio.

sumit.sharma on Wednesday, July 16, 2014

The Real World Cup Winner: APIs


What a world cup! I do feel bad for 50% of the MuleSoft team though (given that we’ve got a big office in Buenos Aires). It’s exciting though, because this was a very exhilarating competition that truly reached a fever pitch here in the US where “football” is traditionally a game with pads, helmets, and ball that doesn’t really roll.

What was really interesting was how this was truly a, “World Cup powered by APIs.” World Cup organizer FIFA has stated that more than a billion fans worldwide accessed information about the tournament through its digital platforms. I personally watched many games on my mobile phone, my tablet, and on my laptop. In fact, I distinctly recall being in the middle of a long line and putting on the Brazil – Columbia game that was streaming over a 3G network in San Diego.

“This has been the first truly mobile and social World Cup”

- FIFA president Sepp Blatter.

By unleashing your digital assets, developers flock to consume the digital mana, creating new value for consumers in the API age. The proliferation of both open and closed APIs has created a rich diverse ecosystem which is driving the Internet of Things (IoT) from an idea to a reality. But how do you get the most out of your existing APIs, and/or create new ones nimbly? How do application developers benefit by leveraging them? Can you predict it?

As an example, a good poker player uses the behavior and actions of the other players combined with his own hand and stack of chips  to his/her advantage. This combination of statistical and behavioral “analytics” boost the value of every chip in his/her possession. Without using his/her environment, the intrinsic “value” of his current bank is significantly reduced.

In order to understand how this same philosophy applies to API design, let’s take a step back and look at the lifecycle of an API.

API Development Lifecycle

At Apple’s recent Worldwide Developers’ Conference (WWDC), Craig Federighi, SVP of Software Engineering, Apple, explained the driver for Apple Health and Healthkit as the need for greater interoperability between systems. He said, “Up to now, the information gathered by those (health) applications lives in silos … You can’t get a single, comprehensive picture of your health situation.”

Craig, we couldn’t agree more!

Sure, the continuing development of wearable devices promises a future in which all of us will have a better understanding and ultimately greater ownership of our health. It is a future in which providers are able to extend the point of care beyond the four walls of the hospital ward and monitor patients in real-time, wherever they might be.

Tackling API development with an API first approach allows companies to focus on designing APIs to deliver business, rather than focusing on the nuts and bolts of implementing those APIs. With API first design, businesses can create an application programming interface optimized for adoption and once finalized, use a platform to rapidly implement it by connecting it to backend services. Moreover, teams can work on various elements of an API solution simultaneously, ensuring all that it meets your technical and business expectations.

Starting with an API description is core to this API first approach – a clearly written service description makes it much easier for team members to collaborate from the very beginning. API mocking enables your team to build tests, clients and the server implementation for your API in parallel. From designing to building, to management and testing, approaching application programming interfaces with an API first strategy is crucial to creating successful APIs.

Netflix has decided to shut down public API support for third-party developers. An interesting decision, and in my opinion a bad one.

Launched six years ago, the Netflix API provided developers a way to access content from their streaming and DVD catalog. That helped the company grow and gave developers a way to build new experiences around Netflix content (for example Flixster).

Last year the company said it would stop issuing new API keys to developers and last Friday they announced that their API will stop working on November 14th for most developers, except a few key partners and applications.

Even as SaaS adoption explodes and business processes move to the cloud, organizations still have crucial data locked in on-premises and legacy systems, and they aren’t going anywhere.

More and more companies are seeking new integration strategies to deal with these hybrid environments, and struggling with how and where to integrate them. This Thursday, join MuleSoft’s Chris Purpura, VP of Cloud Integration and Dan Diephouse, Director of Product Management, for a live webinar, “Top 3 Considerations for Integrating Hybrid Environments“, where they’ll give guidance to help you form a hybrid strategy.

This is the third post on the Gradle Plugin Series, and a lot has happened to the plugin since the first article of the series was published. Today, I’m announcing exciting new features useful for tackling enterprise users’ needs. For more information on how to get started on building apps with gradle, please check the previous blog post and specially the project’s readme file. Now let’s get started.

Fine tuning Mule Dependencies

This plugin is designed to be future-proof and still remain concise, so we’ve introduced a DSL for customizing the mule dependencies to be included as part of the build. This allows users to (in a very concise way) fine-tune the modules, transports and connectors included when unit-testing, compiling your code and running your app.

Fact: Batch Jobs are tricky to handle when exceptions raise. The problem is the huge amounts of data that these jobs are designed to take. If you’re processing 1 million records you simply can’t log everything. Logs would become huge and unreadable. Not to mention the performance toll it would take. On the other hand, if you log too little then it’s impossible to know what went wrong, and if 30 thousand records failed, not knowing what’s wrong with them can be a royal pain. This is a trade-off not simple to overcome.

We took the feedback we got from the early releases around this issue, and now that Mule 3.5.0 and the Batch Module finally went GA with the May 2014 release, small but significant improvements took place to help you with these errors. Let’s take a look at some simple scenarios.

I’d like to announce and introduce you to our second set of Anypoint TemplatesSalesforce to Database. This set leverages the newly improved Database connector which allows you to connect with almost any JDBC relational database, consistently using the same interface for every case. Our first set of templates, Salesforce Org to Org integration, and is a good base for any “Salesforce to X”, or, “X to Salesforce” integrations.

If you are new to our templates, they are essentially Anypoint Studio projects (a.k.a. Mule Applications) that were built with the intention of being configured, customized, extended and reused. They’re built on top of five base data integration patterns:





Business Cases for Salesforce and Database Integration

Below are some of the key use cases that we built this set of templates around. Note that each template can serve as a good base even if you are integrating more than just Salesforce and Databases.