Extend the features of OpenKM

Multi-tenant

OpenKM is normally configured as a single-instance single-tenant (ST) environment where the tenant (who owns the instance) will run a single instance that is installed on one server or across a cluster of them.

It may also be possible to run multiple OpenKM instances (Multitenant) on the same server; it will allow the instance owners to store different content and create personalized client environments. Some advantages are:

  • Share costs with all tenants.
  • Share support and personnel costs.

Multi-tenancy enables multiple independent tenants to be hosted on a single instance, installed either on a single server or across a cluster of them. The main instance is logically partitioned such that it will appear to each tenant that they are accessing a completely separate instance of OpenKM.

Support provides

  • Enabling MT.
  • Managing tenants.
  • Delegated administration.
  • Tenant customization.
  • Tenant-aware interfaces.
  • Tenant content routing.

The super user 'okmAdmin' has access to complete environment. Tenants will be administered by the super 'okmAdmin' using the Tenant Admin Console.

Once a tenant is created and enabled, then the tenant admin can log in to the OpenKM instance and access the Administration area within the context of their tenant domain. If for example, a tenant/organisation called 'OKM' is created, the tenant admin can log in as 'admin@OKM' and create users such as 'joe@OKM', 'ralph@OKM'.

The admin features currently available

  • Manage system users (including user Usages and Quotas).
  • Manage user groups.
  • Category management.
  • Import.
  • Export.
  • System information.
  • Node browser.
  • Tenant Customization.

It provides tenants the ability to customize their OpenKM environment, including models, workflows and web client UI.

The physical content for each tenant is stored on a separate root directory (possibly a separate mounted drive). This also allows accurate physical disk usage to be derived by measuring the disk used at the root location.

Backup and Restore

Since all tenants share the same database schema, the steps for a cold backup and restore are similar to the simple backup process. The steps also must take the use of tenant-based Content Routing (if applicable) into account.