Cisco Cisco Meeting Server 2000 开发者指南
Cisco Meeting Server Release 2.0 : API Reference Guide
127
12 Multi-tenancy
The Meeting Server supports multi-tenancy; this refers to sub-dividing its capacity into a set of
“islands” where each island has all of the functionality of the unit as a whole, but has no access
to the resources (for instance users, coSpaces, or active calls) of other tenants.
“islands” where each island has all of the functionality of the unit as a whole, but has no access
to the resources (for instance users, coSpaces, or active calls) of other tenants.
There are two main implications of multi-tenancy on the API:
n
The API allows tenants to be created, modified and removed, and is the primary means by
which tenants are managed
which tenants are managed
n
The API can return results to a specific tenant.
In multi-tenancy mode, typically each coSpace, call and user is keyed to (“owned by”) a
tenant; when retrieving information on a specific user, coSpace or call object, the API
includes which tenant owns that object, and enumeration-based retrievals include the tenant
information for each object in the returned list.
Equally GET methods can be filtered to only include information for a specific tenant
In multi-tenancy mode, typically each coSpace, call and user is keyed to (“owned by”) a
tenant; when retrieving information on a specific user, coSpace or call object, the API
includes which tenant owns that object, and enumeration-based retrievals include the tenant
information for each object in the returned list.
Equally GET methods can be filtered to only include information for a specific tenant
The majority of the API methods detailed earlier in this document also work in multi-tenancy
mode. In most cases, this equates to supplying a tenant ID in creation (POST) methods via the
form parameters, such that the system knows which tenant a new object is to be associated
with. For instance, creating a coSpace when not in multi-tenant mode would involve a POST
method to “/api/v1/coSpaces” with parameters such as “name” as form parameters. To create
a coSpace for a specific tenant, the POST would again be to “/api/v1/coSpaces”, but
additionally include a tenant=<tenant id>” in the form parameters, where “<tenant id>” would
have been learnt either as the result of a previous tenant creation or via an earlier enumeration.
mode. In most cases, this equates to supplying a tenant ID in creation (POST) methods via the
form parameters, such that the system knows which tenant a new object is to be associated
with. For instance, creating a coSpace when not in multi-tenant mode would involve a POST
method to “/api/v1/coSpaces” with parameters such as “name” as form parameters. To create
a coSpace for a specific tenant, the POST would again be to “/api/v1/coSpaces”, but
additionally include a tenant=<tenant id>” in the form parameters, where “<tenant id>” would
have been learnt either as the result of a previous tenant creation or via an earlier enumeration.
In any initial POST method, an absent “tenant” parameter or a zero-length value are treated as
equivalent. The effect is that there is that the object is not associated with any tenant.
equivalent. The effect is that there is that the object is not associated with any tenant.
According to the rules above, <tenant id> values are valid in creation and modification (POST
and PUT) methods for the following objects (see Figure 3):
and PUT) methods for the following objects (see Figure 3):
n
coSpaces (“/coSpaces” or “/coSpaces/<coSpace ID>”)
n
LDAP sources (“/ldapSources” or “/ldapSources/<ldap source id>”)
n
forwarding dial plan rules (“/forwardingDialPlanRules” or
“/forwardingDialPlanRules/<forwarding dial plan rule ID>”)
“/forwardingDialPlanRules/<forwarding dial plan rule ID>”)
n
outbound dial plan rules (“/outboundDialPlanRules” or “/outboundDialPlanRules/<outbound
dial plan rule ID>”)
dial plan rule ID>”)
<tenant id> values are returned by the Meeting Server in retrieval (GET) methods for the
following objects:
following objects:
12 Multi-tenancy