Anypoint Studio 6.1 Release: Enhanced API Development Support

August 24 2016

2 comments 0
anypoint studio logo

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.

This release improves the user experience for the  API sync feature and also includes RAML 1.0 support introduced in 6.0. We are also excited to extend Studio’s support for a new use case – development of API custom policies.

New: Support for developing API custom policies in Studio (Beta feature)

Whether you are API’fying your internal integration or proxying external-facing APIs, applying appropriate policies is essential, for security (e.g. OAuth), mediation (e.g. message parsing and validation) and traffic control (e.g. quota). While Anypoint Platform provides many commonly-used policies out of the box, there are still cases where our customers need to develop, test and apply custom policies for particular scenarios. Now you can build a custom API policy using Mule code, configure the policy, attach it to an API, and run it locally, all within Anypoint Studio 6.1.

The user can follow a new project wizard called “API Custom Policy Project (Beta),” to edit an XML file that defines a policy with Mule code, and a YAML file that configures the policy parameters. The beta feature provides auto-completion and validation for XML editing.

api cutom policy project

Rather than requiring the user to upload a policy to Anypoint Platform, Studio 6.1 allows users to attach a policy to an API implementation inside Studio and run it locally, with API Console and logs to help you debug.

api console

We are working with customers to design and implement this beta feature with the goal of making the development of custom policies as frictionless as creating Mule applications and APIs in Studio. In the future, we plan to add a GUI and MUnit support. We welcome you to try it out and provide us with feedback.

Improved experience for synchronization between Studio and API Designer

In 6.0, we introduced the API Sync view, the ability to import and synchronize RAML files from Anypoint Platform to local workspace in Studio. Based on customer feedback, we have made some changes to improve the user experience. Now, if you have a local RAML file, you can create a synchronization link to a remote API spec hosted on Anypoint Platform without going through new project wizard. You can also switch users and disconnect inside Studio. These improvements will make it easier to collaborate in a team setting.

api manager

And more …

In addition to these updates, this release includes updates on few other areas around API development, including:

  • Improved RAML 1.0 support in embedded editor and DataSense
  • Better MUnit RAML-to-test scaffolding support

We look forward to hearing from you, especially on how we can improve API custom policy support inside Studio. Nearly all of our new features are shaped by feedback from our users, so I look forward to continuing to evolve Studio with you.

Reference Documentation:


Sign up for our blog newsletter on the top right corner of the page to stay up to date on all of our releases and posts!


We'd love to hear your opinion on this post

2 Responses to “Anypoint Studio 6.1 Release: Enhanced API Development Support”

  1. I’ve developed my first custom policy in Studio 6.1. Went pretty well considering I’m not a Java developer. See my write-up here: https://github.com/n2ygk/oauth2-introspect-policy-validation

    The policy testing was easy to use. I look forward to (I hope) a future flow view so I can drag-n-drop icons and add debugger breakpoints in the policy code. There were/are one or two items where the policy worked in Studio what didn’t work when uploaded: 1) apparently requiring min/max int values in the YAML, and 2) mustaches are considered to be strings by Eclipse and it flags use of them as a syntax error. For example: “`
    “` the {{OAuthPort}} shows:
    – cvc-datatype-valid.1.2.3: ‘{{OAuthPort}}’ is not a valid value of union type ‘substitutableInt’.
    – cvc-attribute.3: The value ‘{{OAuthPort}}’ of attribute ‘port’ on element ‘http:request-config’ is not valid with respect to its type,
    ‘substitutableInt’.

    Agree(4)Disagree(0)Comment
    • Hey Alan,

      Wow, thanks for trying it out and also with the great feedback. We’ll definitely take your suggestions for the future release.

      Agree(1)Disagree(0)Comment