Cloud Blog

All posts by Dmitry Sotnikov

Dmitry Sotnikov is Vice President of Cloud solutions at WSO2. Prior to WSO2, Dmitry worked at Quest Software (now part of Dell) as Director of Cloud Solutions, and later co-founded Jelastic PaaS and led Jelastic's sales, marketing, customer and partner relationships. Dmitry has been a featured speaker at multiple industry events including Microsoft TechEd, VMware VMWorld, Parallels Summit, Quest Innovate, and Technology Experts Conference (TEC).

Device Cloud agent needs to be reinstalled

Last Friday, March 24 and this Wednesday, March 29 we have rolled out updates to WSO2 Device Cloud.

The new features and fixes include:

  • Ability to use Android emulator instead of a real device:

  • Improved device location map rendering,
  • Ability to rename devices,
  • Role filtering,
  • Agent distributed and updated through Google Play Store.

Unfortunately, the previous version of the device cloud agent is not compatible with the changes that were made.

Therefore, if you installed the agent before March 24th, you need to reinstall it:

  1. Uninstall WSO2 Agent application from devices: Settings / Applications / WSO2 Agent / Uninstall.  (Note: If the Uninstall button is grayed out, revoke the administrative rights granted to the application. This is typically done in Settings / Security / Device Administrator but might vary depending on your device model and operating system version.)
  2. Install the new agent by scanning the QR code or following the Get it on Google Play link on WSO2 Device Cloud / Devices / Add / Android – these will take you to the Google Play Store where you can get the new agent.
  3. When you start the agent, make sure to use the Organization Name and Username listed on that page (scroll down the enrollment page for the instructions).

Now, as the agent is distributed via Google Play Store, we manage the agent updates through it. Therefore, you do not need to manually re-install the agent in the future.

Swapping version and context in API URLs

By default, APIs published in WSO2 API Cloud get URLs like http://{base-gateway-URL}/{API context}/{API version}/{API resources and parameters}. For example, if the custom URL that you assigned to your gateway is api.my.domain, you might get something like http://api.my.domain/stats/1.0/countries/us.

But what if you want to place the version number first and have something like http://api.my.domain/1.0/stats/countries/us instead? This is trivial too. Simply type {version}/stats (or whatever your API context is) instead of just stats as the context on the first step of API creation:

And you can remove the version number altogether by selecting the Make this the Default Version checkbox on the 3rd step of API creation:

WSO2 API Cloud is a powerful API management platform that allows you to easily create the exact API program you need!

Multi-file upload for ESB projects

Integration projects can be complex and include multiple services.

In the world of WSO2 ESB, these services are created and uploaded as CAR files.

We have rolled out a nice little Integration Cloud improvement that makes hosting such projects easier. Any ESB app in Integration Cloud can now have multiple CAR files uploaded and running.

When you create a new ESB app or a new version of an existing app in Integration Cloud and you have multiple CAR files, simply browse to each of them one at a time, and the system will get all of them uploaded and added to the runtime:

When you scale this application to multiple instances, each new instance automatically gets all the CAR files that you uploaded.

And you also save money and compute resources because the same ESB instances are reused across the projects.

Happy integrations!

Device Cloud Launched

It is getting better all the time – today I am happy to announce that we have launched WSO2 Device Cloud.

Device Cloud allows administrators to enroll corporate mobile devices (company-provided or employee-owned) and start managing them remotely from the cloud-based console:

  • You improve security: all devices get centrally applied policies and start conforming to your corporate security, lost devices can be located and/or wiped,
  • Save on costs: Device Cloud is cloud-based so there is no upfront investment and just monthly pay-as-you-go plans,
  • Make your employees more productive: employees no longer have to spend time managing their phones and tablets, and they automatically get the applications they need to do their job!

The service is in free beta right now and is scheduled to go fully production later in H1 2017.

At the moment, it still has quite a few “rough edges” and only supports Android devices. But it is based on WSO2 IoT Server, and we will gradually fix all the glitches and roll out the full power of the underlying platform including iOS- and other device type support, and much more.

Check out our tutorials here.

Give it a try and let us know what you think!

Identity Cloud Launched

I am happy to announce that we have launched the free beta of WSO2 Identity Cloud.

WSO2 Identity Cloud is based on the open-source WSO2 Identity Server product. It helps companies set up single sign-on (SSO) from their local enterprise directories to web applications.

You also get a brandable application catalog page for easy application discovery.

As result:

  • You improve your corporate security:
    • Users no longer access web apps when their enterprise credentials are disabled.
    • You can see who accesses which applications.
    • Your password security is enforced across all applications.
  • You make your employees more productive:
    • They no longer have to maintain multiple passwords,
    • They can find the applications available to them.
  • You can reduce costs:
    • Reports let you see which applications are actually in use by whom.

Here’s how you can get started:

1. Log into Identity Cloud,

2. Download the agent to connect the cloud to your local user store,

3. Add applications to the catalog (with predefined templates, uploaded definition files, or manual settings):

That’s it! Your users can access the applications directly or via a nice application catalog page:

See more information in Identity Cloud documentation and let us know what you think!

Change in internal username format

I have a quick announcement to make today. After a recent update of WSO2 Cloud, the internal representation of usernames changed and we no longer replace the @ sign with a dot in them.

With that change, your fully qualified username now looks like email@organization_domain. For example, if my email is user@wso2.com and my organization domain in WSO2 Cloud is wso2cloud my fully qualified username would be user@wso2.com@wso2cloud

As you know, in most cases, you simply log into WSO2 Cloud with your email address. This is not changing in any way.

However, there are a few cases in which the internal, fully qualified login comes into the picture:

As I already mentioned, nothing changes for regular cloud login process: you simply keep using your email address there. The change only applies to the 5 advanced scenarios listed above.

Let us know if you have any questions or concerns.

Commercial Availability of WSO2 Integration Cloud

I am happy to announce that we have just commercially launched WSO2 Integration Cloud: our platform for hosting your integration projects and API backends.

There are 5 easy monthly tiers to pick from depending on the required scale and functionality:

  • Starter is the smallest tier that can be used to host simple microservice-based project as well as Java (including JAX-RS and JAX-WS) and PHP implementations.
  • Getting Traction adds support for WSO2 Enterprise Service Bus (ESB) and Data Services, and increases the amount of resources available.
  • Medium tier lets you select your hosting region (from 12 locations around the globe), ability to scale up your applications, and gives custom docker image support,
  • Large gives multi-region support, 5 GB databases, and 48 GB of RAM for up to 16 applications.
  • Extra-Large is the enterprise package that lets you scale up to 32 applications, 192 GB of RAM, and 10 databases 10 GB each.

With all plans you can set up a VPN connection for $498 / month.

Get started with WSO2 Integration Cloud today!

WSO2 Integration Cloud Launched

We have just launched WSO2 Integration Cloud Beta. This is a service that lets you host your:

  • Cloud-to-Cloud and Cloud-to-On-Premises integration projects based on WSO2 Enterprise Service Bus (ESB) and Data Services Server (DSS),
  • Proxy services,
  • API backends developed using the integration technologies, JAX-RS, JAX-WS, or Java microservices (MSF4J),
  • Java and PHP applications,
  • MySQL databases.

You can VPN your projects to your network or leave them on the internet. You can make the service URLs public (including your custom URLs) or hide them from the internet and only access them from other services and API gateway.

We have also published documentation and tutorials to help you get started.

The service is based on WSO2 App Cloud and inherits its functionality: if you had your projects and databases in App Cloud – they have all been safely migrated to Integration Cloud.

The service is currently in free beta but will launch commercially shortly – we are literally putting in place the last changes required to make it happen.

Try WSO2 Integration Cloud today and let us know what you think via blog comments or Support menu inside the service!

Separating Development, Test, and Production

API programs typically have multiple teams involved: developers, quality assurance, acceptance testing, operations, and so on. Let us talk about the possible approaches to separating WSO2 API Cloud environments in order to give these teams the access they need while preventing them from interfering with each other’s work.

There are two main approaches that we see our customers take:

A. Setting up isolated API Cloud organizations,

B. Segregating API visibility within one organization.

Let’s look into these in detail.

Isolated API Cloud organizations

Separate API environments by provisioning separate organizations

Use this approach if you want to give your teams (for example, Developers and QC) full autonomy and reduce the risk of one team accidentally interfering with the work of another.

  1. You simply purchase separate WSO2 API Cloud subscriptions for the environments that you need. To create these extra organizations in WSO2 Cloud, click the Organization menu (in the 9-dot menu in the top-right corner) and click the Add Organization button.
  2. Upgrade each of the organizations,
  3. Invite team members to the organizations that they need.

Notes:

  • You can use different subscription levels for different organizations. For example, you might need the Large subscription plan for Production but pick Starter for the Developer organization in order to optimize costs.
  • One can be a member of multiple organizations. In that case, they will be prompted to choose their organization at login.
  • You can use Export / Import functionality to move APIs between the environments.

Segregate API visibility within one organization

Separate APIs by assigning roles and setting API visibility

Choose this option if you want to fit the implementation within one subscription and are planning to assign team members to proper roles and ensure proper permissions set for each API.

  1. Create the roles that your organization has such as Developers, QA, Operations,
  2. Assign these roles to your team members,
  3. When publishing APIs, you set visibility to these roles: for example, if there is a new version of an API that is in testing, maybe only QC sees it.

In that scenario, all team members will be sharing the same WSO2 Cloud organization but the APIs and API versions that they see will depend on their role membership.

If you need any help from WSO2 on deciding which option is right for you, simply click the Support menu and ask for assistance.

 

Trace API calls and responses

To effectively troubleshoot APIs you need to know how your calls get transmitted to the backend and what the backend sends back. We have made this easy with the new gateway log access and tracing mediators. Here’s how.

1. Open for editing the API that you want to trace,

2. Go to step 2 (Implement),

3. Click the Enable Message Mediation checkbox and then select the debug_ sequences from the dropdowns for all 3 flows below it as shown in the picture:

enable-debug-tracing-mediators-for-an-api

4. Click the Next: Manage button at the bottom of the screen,

5. Click Save & Publish at the bottom of the last step of the editing wizard.

6. Open the live log by clicking the Configure / Admin Dashboard menu, and then clicking Log Analyzer / Live Log Viewer in Admin Dashboard’s left-hand menu pane.

Admin Dashboard log viewer

7. Now invoke the API (for example, in the API Store‘s API Console for that API).

8. You will see detailed information on the API request and response in the log:

call-and-response-trace-in-api-gateway-log

9. When you are done troubleshooting, disable the message mediation that you enabled in step 3.

Try it in API Cloud today!

Categories

Recent Posts

Most Popular Posts