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.
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 |
|---|
Tenant101AdminGroup | abTenantAdminabTaskClient |
- - tenant101Admin1
- - tenant101Admin2
- - tenant101Developer1
| Tenant101AdminGroup abTenantAdmin abTaskClient |
Tenant101UserGroup | abSeviceConsumerabTaskClient |
- - tenant101ProcessInitiator1
- - tenant101TaskUser2
| Tenant101UserGroup abSeviceConsumer abTaskClient |
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:
http://localhost:8080/activevos/tenant101
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. Login to the Process Console as the System Administrator.
- 2. From the Admin page select Tenant Definitions.
- 3. On the Tenant Definitions page, select Create Tenant button.
Here is the Create Tenant Dialog:
Type or enter the following in this dialog::
- •Context Id. This Id is used in the URL to login to the Process Server, deploy contributions, and access services. For example, a tenant administrator would login to the Process Console at the following URL:
http://localhost:8080/activevos/tenant101
- •Console URL: The URL that is used to invoke the tenant's Process Console.
- •Central URL: The URL that is used to invoke the tenant's Process Central.
- •SOAP services URL: The URL to which a SOAP request is sent.
- •REST services URL: The URL to which a REST request is sent.
- •Tenant Name. This descriptive name is for system administrator use.
- •Activity Execution Limit: Set a value for the maximum number of activities that can execute In order to avoid infinite loops and resource draining processes. The default value is approximately 10,000. When this maximum is reached, the process is suspended. Suspended processes must be resumed manually. The processes count is reset to zero when it is reset. You can get around this limitation by using an agent to run your process.
- •Process Logging Level: By default, Process Server generates an execution log for running processes. You can view or download an execution log for a running or completed process. An execution log provides start and end times for activity execution and helps you troubleshoot faulted processes. The logging levels are:
- - Execution (default)—All execution statements are logged, except for Will Not Execute statements. Using this setting can greatly decrease the size of the log file.
- - Execution with Data—All execution statements are logged, except for Will Not Execute statements, but including variable, expression, and partner link data. Using this setting can increase the size of the log file.
- - Execution with Service Data—All execution and fault information, as well as some WSIO activty information. For execution information, information such as deadpath states, terminations, ready-to-execute and the like. For WSIO, this includes invokes, picks, and receives. WSIO information related to data assignment and changes is excluded.
- - None—You can disable logging to enhance engine performance.
- - Full—All execution statements are logged, including the Will Not Execute statements for deadpath activities. For example, all fault handling statements that are not executed are logged.
- •Process Retention (seconds): Specify how many second to keep completed and faulted processes are retained before they are deleted.
- •Message TTL (seconds). Specifies the amount of time between the time a message reaches the Process Server and the time when it is about to get dispatched to the target process. Default is 24 hours.
When you configure the message time to live (TTL) period and invoke a process by using the REST or SOAP endpoints, if the HTTP message is not dispatched within the message time to live period, the request fails. You see the HTTP error 503 Service Unavailable with the following error message:
Message discarded having exceeded the defined TTL.
The message TTL is applicable to the endpoints with the following entries:
- - /active-bpel/services/
- - /active-bpel/public/rt/
- - /active-bpel/rt/
- - /active-bpel/public/soap/
- - /active-bpel/soap/
- - /active-bpel/odata/repository/v4/OdataRepository/Execute
Note: If the message TTL is not configured for the tenant, the message TTL configured for the Process Server applies.
- •Message with attachments size limit. Sets the maximum size of the payload for a multi-part message that has attachments.
If you use the Informatica Cloud Server, you can set a maximum message payload size of 5 MB. The maximum size for attachments is also 5 MB.
If you use a Secure Agent, the default message payload size is 5 MB and the default attachment size is 5 MB. You can change the default sizes to set higher or lower values.
- •Tenant Description. These details are for system administrator use.
- •Admin Group: Security Roles:
- - abTenantAdmin (Required for the group and each user in the group)
- - abTaskClient (Required for each user in the group for access to Process Central)
- - Not needed: abDeployer or abServiceConsumer
- - abDeveloper (Allows remote debugging from Process Developer. Alternately, tenant admins can perform debugging in the Process Console.)
Privileges associated with abTenantAdmin:
- •Service Consumer Groups: Security Roles:
- - abServiceConsumer (Required for the group and each user in the group)
- - abTaskClient (Required for each user in the group for access to Process Central)
Privileges: Start processes, work on tasks in Process Central within the tenant context
- •Tenant Data. This data is not currently used.
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:
http://localhost:8080/activevos/tenant101
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:
- •Active Processes
- •Contributions
- •Process Definitions
- •Service Definitions
- •Catalog Resources
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.
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:
http://localhost:8080/activevos/tenant101
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:
- •Deploy BPRs into their context
- •View Catalog Resources. There is full control for tenant listings and read-only view of public listings.
- •Active Processes
- •Active Tasks
- •Deployment Logs
- •URN Mappings
- •Scheduled Processes
- •Reports
- •Server Status
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.
- •Public resources can include:
- •Contributions including processes and related resources
- •Catalog resources, such as a common XSL file for the doXSLTransform function that might be used in tenant processes
- •Services created from system services, such as a Shell Command
- •Process Central configuration files and properties
- •Global custom functions
Any requests without a tenant context id is assumed to be deployed as a public service.
