Salesforce introduced the Streaming API with its Spring ‘16 release (API v36). It was a neat feature since Salesforce users don’t have to poll or periodically call Salesforce to check any updates in their objects. One important limitation with API v36 was that the Streaming API (API v36) doesn’t guarantee durability and reliable delivery of notifications. However, Salesforce added message reliability and message durability in its API v37. We are excited to announce the release of Salesforce Connector v8.0.0 which supports the Durable Streaming API. (The Salesforce Connector supporting the API v38 will be released soon.)
The amount of data in the world is growing exponentially. IDC predicted in 2014 that the amount of data on the planet would grow 10-fold in the next six years to 2020 from around 4.4 zettabytes to 44 zettabytes. Additionally, the majority of the recently generated data – like the comments you just made on Facebook – are unstructured or unmanaged.
I’ve always wondered how other software teams work. From the design experiences at Airbnb to the development practices at Spotify – these kinds of backstage stories are a great source of inspiration for me. So when Alex Li, Product Manager of Studio, asked me to write about custom policy support in Studio 6.1, my answer was, “Yes, of course! But I’d love to write about what happened behind the scenes.”
What is a custom policy? In a Mule server, a “policy” is an XML file deployed into the “policies” folder. It contains logic to handle HTTP requests before and after a Mule application. For example, using a policy you can add authentication without changing the API implementation.
Another release, so soon?
Yes, believe it!
With MUnit 1.2.0, we launched Domain Support, and since then, we have been collecting feedback on the release. We take quality very seriously here – after all, we are a testing framework aimed at ensuring the quality of your code. With that in mind, we looked very carefully at what our users were saying and fixed every bug we could find.
Automatically test RAML-defined API
So, is it that all you guys did?
That’s a very good question, and the answer is no!
About three months ago, we released Studio 6.0, which was a significant step towards covering all API-related use cases in one single design environment. Since then, almost half of our active users have embraced Studio 6.x, to define, create, consume and test APIs. Now, we are excited to release Studio 6.1 as another step to make Studio the most powerful and productive API development and integration tool.
Did you know that a new version of MUnit is available? This new MUnit release is a joint release with a new version of the MUnit Runtime (1.2.0) and also, a new version of the MUnit Studio Plugin. Some new features of this release include:
- Multiple suite run
- MUnit nested folders
- Support autocompletion for MUnit’s MEL functions
- Add metadata support to MUnit message processors
- Create coverage reports from inside Studio
- Improved documentation
As part of our Anypoint Platform June 2016 announcement, we are excited to release Anypoint Studio 6.0. We know API development, system orchestration and connectivity are increasingly intertwined tasks. This release is all about unification — with a goal of making our users even more productive in accomplishing these tasks. Anypoint Studio 6.0 provides everything you need to design and build APIs in a single, powerful and newly redesigned IDE.
All API-related use cases in One single design environment
We recently introduced our HowTo blog series, which is designed to present simple use-case tutorials to help you as you evaluate Mulesoft’s Anypoint platform. In this blog post, we show how an organization can use Anypoint Platform to communicate with their partners using a secure file-based solution.
In my blogpost last week, I shared how, in just 5 minutes, you can expose MySQL, DB2, SQLServer, Oracle or SAP datasource as an OData API into Salesforce using Anypoint Data Gateway for Lightning Connect.
But let’s say what Data Gateway offers out-of-the-box is not a perfect fit for what you want to do. Maybe you want to create an OData API for a different datasource, expose a legacy API as an OData API or do data orchestration before exposing data into Salesforce. So what do you do?
Recently we launched a service for MuleSoft employees (Muleys) to be able to manage their stock options online using Charles Schwab’s service. With the solution, there is a requirement to exchange data between our HR system and Schwab in both directions. As you can imagine, accuracy is key where anything financial is concerned and as such, reducing complexity reduces the risk of errors. With over six hundred employees now and forecasting fifty percent growth in headcount this year, we needed to have something automated and efficient. We decided to use our technology to build a solution to help us make this easy for our employees – especially since we needed to launch the solution all at once to our existing employees as well as make it scale over time.