Multitenancy

Multitenancy refers to having multiple organizations working on a single instance of Process Platform. The runtime multitenancy, wherein all the artifacts are multitenant-aware at runtime, is supported by Process Platform. This ensures that each organization is independent of other organizations; changes made to artifacts in one organization will not impact other organizations that share the same artifacts.

The following aspects define the runtime multitenancy support provided by Process Platform:

Inheritance and override of artifacts

When an application package is deployed in multiple organizations, all the application artifacts are deployed to a shared ‘System space’ from where users in multiple organizations access the artifacts per their privileges. However, if an ‘Organization-specific version’ of any artifact is available, users in that specific organization will access the ‘Organization-specific version’ instead.

‘Organization-specific versions’ of artifacts are created in the following scenarios:

• When an artifact at the ‘System space’ is customized. For example, if specific monitoring settings of a business process model are modified in one organization, an ‘Organization-specific version’ of that artifact is created, which will be accessed by users in that organization.
• When an artifact is published from the Collaborative Workspace (CWS). For example, Scheduler
• When an application package is deployed in a specific organization

Shared  or isolated execution

 A SOAP Web service initiated in one organization is executed by a service container within that specific organization itself. If no service container is found to execute the service, the service is delegated to the ‘System organization’ and executed by a service container there for efficiency and reuse. During execution, the user who initiated the service and the original organization from where the service was initiated is considered.

Original caller context

All functionality is invoked in the context of a user and the organization of that user. All the service containers in the current organization or the ‘System organization’ execute the functionality on behalf of a user in the context of his or her organization. This execution of the functionality is not just limited to the direct instantiation of an artifact, but is also cascaded to the other artifacts that get triggered. So, if a user starts a user interface, it will be in the context of the organization in which the user is a member. If  the user interface invokes a call on a service container, it will execute in the context of that organization and user. Before it is executed, the role of the user is validated against the Access Control List of the service. If the user does not have the required access, the functionality will not be executed.