VoiceObjects supports multi-tenant environments through the concept of sites. A site corresponds e.g. to a single corporate customer on a hosted platform, or to a department within an enterprise.

This chapter describes the concept of sites, and how to work with them. For the basics on user management, refer to Chapter 2 - User Management - Basic Topics.

The Site Concept

When different groups of users work within a single VoiceObjects installation, it is sometimes desirable to let each of these groups work in its own “walled garden”, without access to any of the work the other groups are doing. This is possible through the concept of sites.

A site is a virtual container that groups servers, services, projects, and users. By default, there is one special site called system. This is the site in which all Server Administrators and Server Controllers operate. In addition to the system site, any number of custom sites may be created.

The following diagram shows a sample use case for sites in a Managed Service Environment (MSE). Three different customers work on the same VoiceObjects installation with different teams, utilizing different user roles within each site.

In addition to users, a site may also contain projects, libraries, servers and services.

In general, objects within any one site are hidden from all other sites. This is referred to as site containment, and makes it possible for multiple tenants to coexist on a single VoiceObjects installation without interference. Each tenant may use the platform as though he were the only client. Built-in security mechanisms ensure that different tenants cannot influence each other’s operations, and cannot access each other’s objects. The only exception is made for the system site, which may share servers or services with custom sites. For more information, refer to the section on Sharing Objects.

The following diagram shows the relationship between the different user roles:

Server Administrators, Server Controllers, and User Managers from the system site are responsible for maintaining an entire VoiceObjects installation. They have access to all objects in all sites. Observers from the system site have read-only access to the same information as Server Controllers.
Users with these roles would typically be created at the level of a hosting provider, which may be within a single enterprise serving multiple departments, or across different enterprises.

Site Administrators, Site Controllers, and User Managers from a custom site are responsible for maintaining a specific custom site. They have access to objects in their own site, as well as potential restricted access to shared objects from the system site. Observers from a custom site have read-only access to the same information as Site Controllers.
Users with these roles would be created for each tenant using a VoiceObjects installation. These tenants may be e.g. different departments within a single enterprise, or different enterprises using the services of a hosted platform.

Service Controllers, Designers, and Reviewers work within one given site (either custom or system). Typically, they only have access to objects from within their site. Service Controllers may, however, also have restricted access to shared objects from the system site.
Users with these roles would be created for each tenant using a VoiceObjects installation.

Creating a Site

A site is implicitly defined through its root Site Administrator. Therefore, when creating a new custom site you must follow these steps in this order:

1.     After logging in as a Server Administrator or User Manager in the system site, create a new Site Administrator. This Site Administrator will become the root Site Administrator who implicitly defines the new site, but this user should not be used for actual administration purposes.
Root Site Administrators are distinguished in the Repository Browser by the Crown icon .

2.     Optionally, define site settings such as resource paths, session and seat limitations, etc.

3.     Log in as the new root Site Administrator and create an additional Site Administrator. This is the Site Administrator you should use to actually administer the new site.
Alternatively, you can create at least two User Managers. They can then jointly administer the new site.

4.     Log in as the new Site Administrator or User Manager created in step 3, and create additional users as required.

8     Caution: You must follow these steps in this order. Failure to do so may result in an invalid site, and may break the site containment described in The Site Concept.

Note that the names and reference IDs of Server, Service, and User objects must be unique across all sites.

Site Assignment

Configuration objects (projects, libraries, servers, services, and users) belong to the site in which they have been created. Since objects are always created by users, this means that every object created by a user from site S also belongs to site S. When objects are imported, they belong to the user who imported them.

Once created, objects cannot be moved between sites. It is possible to share certain objects from the system site with other sites (see Sharing Objects for more details), but these objects still remain within the system site. Thus, it is important to consider the correct site assignment before creating a new configuration object.

Managing a Site

General properties of a custom site can be configured within the Site Settings in the Security section of the root Site Administrator for this site. These are particularly relevant in Managed Service Environments, in which each tenant has a specific data area for resources (audio files, grammar files, utterance recordings, etc.) as well as a specific Service Level Agreement (SLA) that defines the number of Desktop seats and concurrent dialog sessions available to him.

For more information on Service Level Agreements (SLA) see Chapter 9 – Service Level Agreements (SLA) in the Deployment Guide.

For more information on utterance recording see Chapter 6 – Recording of Utterances in the Deployment Guide.

The following parameters can be configured:

·          Site ID
Defines a symbolic ID for the site that is shown whenever the site is referenced (e.g. in the Control Center). If not specified, the user ID of the root Site Administrator is used as the site ID.
The site ID must not contain blanks or special characters other than underscores, and it is limited to 40 characters in length.
Site IDs must be unique within a VoiceObjects installation.

·          Resource Locator path
Defines a prefix for the physical path of all resource locators in applications of this site. This should be used to restrict the site to a certain data area, and to keep different sites separate from each other.
You should never use back-slashes in this field, especially when defining paths to a network machine (like in file:///\\172.22.23.29/Site1). Use forward slashes instead, which are accepted by both Linux and Windows machines. The above example would then be written as file://///172.22.23.29/Site1.

·          Resource Locator URL
Defines a prefix for the URL of all resource locators for Audio, Video, Grammar, and Plug-In objects in applications of this site. This should be used to restrict the site to a certain data area, and to keep different sites separate from each other.
Note that when using custom formatting algorithms through the Formatting bus, this URL will not be used. For the predefined formatting types, this setting is interpreted, though.

·          Utterance recording path
Defines the physical path to a directory that will be used to store all utterance recordings of this site. This should be used to restrict the site to a certain recording area, and to keep different sites separate from each other.
You should never use back-slashes in this field, especially when defining paths to a network machine (like in file:///\\172.22.23.29/Site1). Use forward slashes instead, which are accepted by both Linux and Windows machines. The above example would then be written as file://///172.22.23.29/Site1.

·          Utterance recording URL
Defines the URL to a directory that contains all utterance recordings of this site. This URL can be used for instance within VoiceObjects Analyzer reports to access the recordings and to playback their content.

·          Backend URL
Defines a prefix for the URL of all resource locators for Script and Connector objects in applications of this site. This should be used to restrict the site to a certain back-end area, and to keep different sites separate from each other.

·          Import/Export path
Defines a prefix for the import/export path used by this site. This should be used to restrict the site to certain file system folders for export and import, and to keep different sites separate from each other.
i8 Note: When working with Desktop for Eclipse file browsing is only possible on the local machine (or any mounted network drive) and thus does not have to be restricted depending on site settings. These restrictions are only relevant when working with Desktop for Web, where file browsing takes place on the machine running the VoiceObjects Desktop process and therefore needs to be restricted.

·          Start object path
Defines a prefix for the start object path used in service definitions in this site. This should be used to restrict the site to a certain data area, and to keep different sites separate from each other.

·          Session guarantee
Defines the guaranteed number of concurrent dialog sessions for this site. Guaranteed sessions are set aside for this site and cannot be claimed by any other site.
If not defined, there is no guaranteed number of concurrent dialog sessions.

·          Session limit
Defines the maximum number of concurrent dialog sessions available to the site. If this limit is reached, additional dialog requests for any service within this site will be rejected.
If not defined, the limit on the maximum number of concurrent dialog sessions for the site coincides with the one in the license key for the VoiceObjects installation.

·          Servers
Defines the maximum number of servers belonging to the site that may simultaneously be active.
If not defined, there is no limit on the maximum number of servers.

·          Services
Defines the maximum number of services belonging to the site that may simultaneously be deployed.
If not defined, there is no limit on the maximum number of services.

·          Desktop seats
Defines the total number of Desktop seats available to the site.
If not defined, the limit on the number of Desktop seats for the site coincides with the one in the license key for the VoiceObjects installation.
If defined, both Designer seats and Site seats must also be defined.

·          Designer seats
Defines the number of designer-level seats available to the site. This applies to the roles of Designer, Reviewer, and Service Controller.
Note that the sum of Designer seats and Site seats must not exceed the number of Desktop seats.

·          Site seats
Defines the number of site-level seats available to the site. This applies to the roles of Site Controller and Site Administrator as well as Observers and User Managers from custom sites.
Note that the sum of Designer seats and Site seats must not exceed the number of Desktop seats.

·          OSDM integration
Defines whether OSDM integration is available to this site.
By default, this check box is clear. Note that OSDM integration can only be made available to a site if it is available in the license key for the VoiceObjects installation.

·          Infostore
Defines whether Infostore is available to this site.
By default, this check box is clear. Note that Infostore can only be made available to a site if it is available in the license key for the VoiceObjects installation.

Changes made to Desktop-related settings (e.g. number of available seats) take effect immediately after changing the User object.
Changes made to deployment-related settings (e.g. guaranteed sessions) take place as soon as at least one service belonging to the site is redeployed.

Sharing Objects

It is possible to share servers and services between the system site and custom sites. It is not possible to share anything between two different custom sites, and it is not possible to share projects, libraries, or users between the system site and custom sites.

This is true regardless of the access control list settings, so even a Server Administrator cannot deliberately break the site containment.

Servers

To share a server created in the system site with a custom site, all users who are intended to have access to the server must individually be placed on the access control list for the Server object. This must be done by a Server Administrator or a Server Controller.

 

The respective users may then access the server according to their roles. As usual, they do not have access to the Security section. In addition, they are also prevented from changing the configuration parameters for the server. On the list of hosted services, they only see the subset of services that they have access to.

Services

To share a service created in the system site with a custom site, all users who are intended to have access to the service must individually be placed on the access control list for the Service object. This must be done by a Server Administrator or a Server Controller.

 

The respective users may then access the server according to their roles. As usual, they do not have access to the Security section. In addition, they are also prevented from changing the communication parameters for the service.

Removing a Site

When removing a custom site, it is required to first remove all projects, services, and servers in the site. Then, all users except for the root Site Administrator must be deleted. Finally, delete the root Site Administrator defining the site.

Administrative Tasks

In a multi-site setup with shared resources, it is relevant to know which operations impact only individual sites and which operations impact all sites running on the installation.

The following tasks require VoiceObjects Server restarts and thereby create dependencies in a shared environment. Those changes should only be applied in a scheduled maintenance window.

l Major server configuration changes
E.g. enabling/disabling SNMP notifications, changing password policies, changing HTTP request routing, changing TTA bus implementation

l Database changes
E.g. switching the metadata, Infostore, or custom DB logging repository

l Cluster setup changes
E.g. adding new server instances

The following VoiceObjects Server configuration tasks can be performed without a server restart and thus do not create cross-site dependencies.

l License upgrade
Changing the license key

l Adjusting log levels
E.g. increasing or decreasing logging levels

l Adjusting session partitioning policies on server level
E.g. moving the boundaries between guaranteed sessions and shared sessions

l Server instance maintenance
E.g. taking a server instance out of service for hardware maintenance

The following frequent operations can be performed independently for each site without any downtime of the system or an individual application.

l Monitoring
Each site can independently monitor deployed applications in terms of call traffic, problems, etc.

l Adding / removing / modifying applications (services)
Each site can independently develop, deploy, modify, and un-deploy applications.

l Adjusting Infostore filtering levels
Each site can independently configure their use of Infostore. Settings can be adjusted at application level.

l Adjusting session partitioning policies
Each site can independently specify session partitioning policies for their respective applications.

l Logging
Each site has independent access to log information for their respective applications.