API Manager 1.6.0 - tanancy

Came across a question on API Manager tenancy ...

As per docs [1]
"WSO2 API Manager supports creating multiple tenants and managing APIs in a tenant-isolated manner. When you create multiple tenants in an API Manager deployment, the API Stores of each tenant will be displayed in a muti-tenanted view for all users to browse and permitted users to subscribe to. "

Let's try it and see !!

Step 1 - Create a tenant

• Login to management console - https://localhost:9443/carbon/
• Create a new tenant from Home > Configure > Multitenancy > Add New Tenant - lets say my tenant is yumani.com. 
• Now if you check in API Store, you will see tenant domains there.

When you click on yumani.com above, you will be taken to yumani.com's API store.

Lets try working within a tenant and see;

Step 2 - Create users within the tenant

We need 3 user roles - creator, publisher and subscriber

• Login to management console, using tenant admin's credentials
• Create a new user role from Home > Configure > Users and Roles > Roles
• name - creator
• permissions - as given in [2]
• Create a role for subscriber
• name -subscriber
• permissions - login, Manage -> API ->Subscribe [3]
• Create a role for publisher
• name -publisher
• permissions -login, Manage -> API ->Publish [4]
• Create 3 users and assign them to each role.

Small test - if the permissions are correctly set as per above;

 

-  when you login to publisher (https://localhost:9443/publisher/) from creator's login- you should see an option to add APIs

 

 - When you login from publisher's login, you should not see an option to add APIs. You will only be able to list APIs and publish them.

 

- Finally, you will not have sufficient privileges to login to publisher using subscriber's login. 

Step 3 - Create and publish API

• Login to 'API Publisher' from creator's account and create a new API.

 Step 4 - View the API from store

• Now login to API Store using subscriber's account
• You will see the above API.

Another test: 

- Create another tenant, try login to tenant 1's (yumani.com) store, you are not allowed!

 

- Login to tenan 3's store and see if you see any of tenant 1's APIs. No! because of tenancy.

NOTE: In earlier versions of APIM (APIM-1.4.0), we had a concept of allowing selected tenant's view other tenant's APIs. But it is not available in latest releases.

 

[1] - http://docs.wso2.org/display/AM160/Configuring+Multiple+Tenants 

[2]- http://docs.wso2.org/display/AM160/User+Roles+in+the+API+Manager#UserRolesintheAPIManager-Addingthe creator role
[3] - http://docs.wso2.org/display/AM160/User+Roles+in+the+API+Manager#UserRolesintheAPIManager-Thedefault subscriber role
[4] - http://docs.wso2.org/display/AM160/User+Roles+in+the+API+Manager#UserRolesintheAPIManager-Addingthe publisher role

List of general rules about artifact.xml

Below is a list of general rules which Harshana (WSO2 Tooling guru) mentioned while he was supporting us with customer queries.

1. artifact.xml files in Dev Studio Projects as well as in Composite Application Archive (CAR) files are to manage Artifact metadata. Hence they should not be manipulated manually by users.

2. artifacts list in the artifacts.xml represents the order of artifacts getting deployed in Carbon 4.2.0 based servers including ESB 4.8.0.

3. If there are ESB Message Stores and Message Processors, then Message Stores will be placed before the Message Processors in the artifacts.xml. This process is automatically happens with Dev Studio 3.5.9 version.

4. If you are using Proxy services with Publish WSDL option where the WSDL itself is included in the CAR file in form of Registry Resource or Local entry, that entry need to appear before the Proxy itself because at the time of the Deployment of the proxy, it will use the wsdl pointed as the Publish WSDL.

5. In general the order of the artifacts in artifacts.xml will be Registry Resources, Local entries, Message Stores, Message Processors, other artifact types.

How to remove these UI bundles from worker node

To remove these UI bundles from worker node, you need to run the following command from [PRODUCT_HOME]/bin:

ant createWorker

The ant task createWorker removes the following set of UI bundles:

org.wso2.carbon.*ui_*
org.wso2.carbon.*stub_*
org.wso2.stratos.*ui_*
org.wso2.stratos.*stub_*
org.jaggeryjs.*ui_*
org.jaggeryjs.*stub_*
org.wso2.carbon.ui.menu.*
org.wso2.*styles_*
org.wso2.carbon.authenticator.proxy_*


A situation where this might not work is;

If you have used -DapplyPatches parameter to start ESB node at some point!! If so it will backup the original jar files in [PRODUCT_HOME]/repository/components/plugins to [PRODUCT_HOME]/repository/components/patches/patch0000 folder. In the next server startup these jars will get replaced in [PRODUCT_HOME]/repository/components/plugins. Hence, the UI bundles could appear again. If this is the case, you need to remove the UI bundles (mentioned in above comment) manually from [PRODUCT_HOME]/repository/components/patches/patch0000 folder.