Administration Console > Admin > MultiTenancy


This feature requires a Multi-Tenant license. MultiTenancy is not available for the Process Server embedded in Process Developer.
As a prerequisite to this feature, the Process Server must be configured with security roles. Refer to the Process Server help for details on security setup.

What is MultiTenancy

Multitenancy allows separate organizational groups to share a Process Server while maintaining privacy in their business processes. The Process Server administrator creates a tenant profile, which contains tenant administrators, users, and other details. Each tenant develops, deploys and manages their own set of private contributions. All tenants share the same server configuration, but they have access to a subset of configuration and maintenance features for their own use.
The following illustration shows an overview of the multitenant Process Server environment.
multitenant overview

Step 1: Setting Up Identity Service Groups with Security Roles

As a first step, the Identity Service administrator in your organization must assign the tenant security role, abTenantAdmin, to the group who will administer the tenant context on the Process Server and will deploy contributions from Process Developer. This role gives an authenticated administrative user access to tenant-related pages of the Process Console and the authorization to deploy contributions into the tenant context.
In addition, users who will instantiate processes must have the abServiceConsumer role.
Example Security Role Setup
Identity Service Groups/Members
Role and Group Assignments
  • - tenant101Admin1
  • - tenant101Admin2
  • - tenant101Developer1
Tenant101AdminGroup abTenantAdmin abTaskClient
  • - tenant101ProcessInitiator1
  • - tenant101TaskUser2
Tenant101UserGroup abSeviceConsumer
After the tenant admin role is assigned to user groups, and you set up a tenant, a user with abTenantAdmin privileges can log into the tenant context of Process Console as shown in the following example:
Note that access to http://localhost:8080/activevos is denied to any user who does not have the abAdmin role.

Step 2: Setting Up a Tenant Definition

Begin with the following steps:
  1. 1. Login to the Process Console as the System Administrator.
  2. 2. From the Admin page select Tenant Definitions.
  3. 3. On the Tenant Definitions page, select Create Tenant button.
Here is the Create Tenant Dialog:
Tenant Detail/Create Detail dialog
Type or enter the following in this dialog::

Tenant Administration for System Administrators

Any user with an abAdmin security role can login to the Process Console or can login to any tenant context.
For example, a Process Server administrator can log into:
When a Process Server administrator logs into a tenant context, the administrator can read and execute exactly the same Process Console pages and features as a user in a tenant Admin Group.
When a Process Server administrator logs in without using a tenant context, the administrator sees tenant-related data on many Process Server pages and can filter the listings by tenant, including:
Only system administrators are allowed access to Process Server administration tasks.
To manage memory allocation on a tenant basis, create a dispatch service for each tenant. For details, see Dispatch Service.
See also Tenant Administration for Tenant Administrators Deployers.

Tenant Administration for Tenant Administrators Deployers

Any user defined in a tenant Admin Group can log into the tenant context of the Process Console. For example, a context looks like:
Access to other services include the following URLs:
http://localhost:8080/activevos-central/<TENANT Context Id>
http://localhost:8080/active-bpel/services/<TENANT Context Id>/serviceName
http://localhost:8080/active-bpel/catalog/<TENANT Context Id>/locationPath
To create a URN mapping, the tenant context can be added:
http://localhost:8080/active-bpel/services/<TENANT Context Id>${urn.4}
A tenant administrator has access to the following within the tenant context:

Tenant Access to Public Resources

In a MultiTenant environment, each tenant has access to its own resources, and in addition, a tenant has read and execute access to public resources that a system administrator has added to the server. This means that a process can be deployed to a tenant context and invoke another process in the public context or use resources in the public context.
By default, there is one tenant context, $public, that contains common, system-wide deployments.
Any requests without a tenant context id is assumed to be deployed as a public service.