Cloud Blog

What’s new in App Cloud

We’ve been busy improving WSO2 Integration Cloud (formerly also known as App Cloud), so in case you have not tried it lately, here is a quick summary of what we have rolled out recently.

Custom URL and Default Version

Not just designate which version of the application you want to be invoked by default, but also map a custom URL that you own (such as http://foo.bar.com) to it.

This was when you roll out a new release and want your users to switch to it, all you need to do is set that new version as default, and all the traffic will be routed to it:

app-cloud-production-URL

See documentation for details.

Endpoint Information for Apps

We made endpoint information for application more useful.

For Java, PHP, and Jaggery, it is still just the URL (with the context to which you deployed):

Web app endpoint

For Java Microservices, we show the URL of the Swagger API definition for the exposed interface:

Microservices Swagger Endpoint

For Data Services, it is the WSDL definition of the exposed SOAP endpoint:

Data Services SOAP endpoint

Bulk Variable Upload

Instead of providing environment variable for your application one by one, you can upload them all as a JSON file:

JSON variables upload

Search by Tags

If you use tags for your applications or their versions (for example, tier:frontend), you can now search by them in the App Cloud home page with the tag: prefix (for example, tag:tier:frontend).

Faster Containers, More Options

We updated runtimes to the latest version (redeploy your applications to take advantage of them):

  • MSF4J 2.0.0 runtime for Microservices applications
  • WSO2AS 6.0.0 M3 runtime for Java Web applications
  • WSO2AS 6.0.0 M3 runtime for Jaggery applications

We changed Java runtimes to Alpine images to improve the start-up time and increase efficiency.

We added more container size options:

  • 128MB RAM and 0.1x vCPU
  • 256MB RAM and 0.2x vCPU
  • 512MB RAM and 0.3x vCPU
  • 1024MB RAM and 0.5x vCPU

If your project needs more resources just click the Support menu and let us know the details.

Tweaked Trial Limitations

We used to have a limit of 3 applications per free trial account. Now you can create any number of applications as long as you keep only 3 of them running. If your project needs more – just click the Support menu and let us know the details.

New Documentation

Check out the new features in WSO2 Integration Cloud today and let us know what you think!

 

 

Hiding APIs from Developer Portal

API Cloud lets you control not only who can subscribe to your APIs and invoke them, but even who sees each of the APIs in your API Store (Developer Portal).

The visibility level is set on the first step of the API editing and there are three levels available:

  • Public,
  • Visible to my domain,
  • Restricted by roles

Set API visibility level

Public

Public visibility means that the API will be shown on the Developer Portal to everyone, including not authenticated site visitors.

This is the mode most frequently used for public API programs when you want to have everything available on the website and indexed by search engines, so your API program can attract as big of a community as possible.

Visible to my domain

This option basically means “authenticated users”. Only people who log into your portal can see APIs with this visibility level.

Note that you can control who can do this because the only ways to get an account are to either get explicitly invited by you or to go through self-signup, and the self-signup feature is off by default and can be configured to require approval.

Restricted by roles

This is the strictest visibility control option that lets you narrow down API visibility to a specific group of users.

For example, before making an API publicly visible, you can limit its access to internal developers and quality assurance team.

Or you might have a scenario in which some APIs are visible to the wide ecosystem, more APIs are available to select close partners, and even more are being used internally.

Notes:

  • If you want to use default roles for the visibility – note that their internal names are different from the display names being used in the Members dialog box. So if you want to restrict visibility to publishers only (Members dialog box calls this group: APICloudPublisher) restrict access to publisher role.
  • APICloudSubscriber role is internally simply called subscriber but, in reality, you would rarely use it for restrictions by roles because in most cases the effect of that level of visibility is identical to simply setting Visible to my domain.

Note: API Versions

This visibility control system can be very powerful in combination with API versioning because Visibility setting is applied on the individual version level. For example, you might have version 1.0 of an API Publicly visible, and at the same time only have version 2.0 visible to your Quality Assurance and Beta Testers group, and version 3.0 only visible to Internal Developers.

Categories

Recent Posts

Most Popular Posts