Brazil Ecuador France Greece Hungary Italy Malaysia México Middle East Poland Paraguay Portugal Romania Serbia Spain USA USA ( Español )
Contact

Extend the OpenKM features

Multi-tenant

Normally OpenKM is configured like a single-instance single-tenant (ST) environment where each tenant (Instance owner) will run a single instance that is installed on one server or across a cluster of them.

Although it may also be possible to run multiple OpenKM instances on the same server, separating content stores and creating a personalized clients environments. Some advantages are:

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

The Multi-tenancy enables multiple independent tenants to be hosted on a single instance, which can be 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.

Contact us

CAPTCHA ImageRefresh Image

Don't hesitate to contact us

OpenKM in 5 minutes!