Time Flies .. we have been very busy here at WSO2 !
I promised I would talk about multi-tenancy , in our on-premises product and there it goes, finally! I recently worked on a packaged demo for a Governance Tutorial at WSO2Con – We illustrated how to prepare applications to separate environment specific data from an application. To simulate isolated Dev and QA environments, I leveraged the multi-tenancy feature of our AppServer ( this feature is part of the Carbon platform, and therefore available on-premises in most of our products).
In order to create a tenant, you need to login as “super-admin” , i.e. out of the box, the default admin/admin credentials. When you log as admin, you are in “super-tenant” mode. Managing tenants is only available in this mode. In the setup above, I have added two tenants: DevAS and QA-AS. Let’s add a third one:
- Domain name, here blogging.com: this is a unique identifier for my domain. I need to use it to log into the admin console and being taken to my specific tenant, and it’s also used in URLs to distinguish one tenant from another.
- Usage Plan : this is inherited from our Stratos PaaS – The idea is that you can limit the capabilities of a tenant using a plan (nb of users, bandwidth, etc.) – The product comes with a predefined list, and you can add your one and/or tailor the existing ones. For on-premises deployment, there is only one default plan, Demo.
Once the tenant is created, you can log out from super tenant mode, log into your tenant, using the admin user you just created, i.e. firstname.lastname@example.org and work on the application server.
You can now deploy, manage and test applications on this tenant, using the specific tenant URL, for example: https://10.0.2.15:9446/services/t/blogging.com/HelloService?tryit.
If you want to experience how this works in our PaaS environment, I encourage you to connect to StratosLive, which is a Stratos environment deployed and managed by WSO2.
That’s all for today !