Alfresco has long supported Multi Tenancy in their enterprise and community ECM releases. Multi Tenancy allows you to logically separate the repository by tenants. Each tenant is assigned and mantained by a specific domain at login. Some thoughts based on recent client experiences in maintaining and planning an upgraded of a client using a Multi Tenant setup.
The most important thing to note about MT in Alfresco is that there are a few features that have not been implemented and some of these may invalidate the use of MT for your organization. To see the latest status of MT’s features you can reference the official docs. As of this post the current features not supported in a MT setup are listed here.
In terms of the logical repository separation you do get some nice features. When creating a tenant you can specify the storage location for a tenants content store. This can be a different location or volume from the standard alfresco content store. If you do not specify a separate location all of the content will be stored together in one content store. When a user logs in with their specific domain the Alfresco API and services are all insulated and can only see their tenants specific content store. Organizations sensitive to security mixups based on standard folder/file security might be in favor of this setup if they can separate large chunks of their organization into separate tenants. You also have the ability to export and import tenants on the fly. However when moving tenants, the Alfresco application version must remain the same.
If you are still using the Alfresco Explorer interface you have some interesting customization options. Alfresco MT supports custom dynamic models and web client updates. This means you can dynamically add a custom model and interface customizations on the fly for a specific tenant. For example, TSG has created a tenant, loaded a custom content model, and customized the advanced search interface all without rebooting the Alfresco application server.
If you are utliziing the Alfresco Share interface you are unfortunately a bit more limited. You can still load dynamic models via the alfresco interface however there is currently no method for scoping share interface customizations to a specific tenant. There does however exist a feature request for this exact functionality here.
If you aren’t as concerned about custom models and interface updates on a per tenant basis the standard classpath deployment works as well. This means that any custom model or interface updates on the classpath are available to all tenants without any extra configuration.
With Alfresco focusing heavily on its Alfresco Cloud offering, it is almost certain that Alfresco engineering has been focused further enhancing Multi Tenancy features, especially within Alfresco Share, to ensure scalability and customizations going forward. We can assume these changes will evenually be incorporated into future Alfresco Enterprise and Communtity releases.
Paras Jethwani says
If the organisations are entirely separate entities – then wouldn’t a dedicated repository based mutli-tenancy model be more suitable?
Also, with the shared repository MT model – can the same set of customisations be shared across tenants – with each tenants data kept separate?
tsgzsiegel says
For all intents and purposes the division of data are very much repository based.
When setting up each tenant you have the option to specify separate data directories for storage. If you don’t set this option then all data will be stored in the Alfresco Data directory mixed together. In terms of tenant UI customization it heavily depends on the primary interface. The old Alfresco JSF interface has the ability for a shared set of customizations across all tenants. You also have the option to deploy customizations that are tenant based using Dynamic Models within each tenant. On the Alfresco Share side you do not have customization at the tenant level, all customizations will be applied and visible to each tenant. There are most certainly ways around this but the OOTB Alfresco xml configurations do not allow for tenant based Share customizations.
It is worth noting that the Alfresco API is tenant aware and you can use the Tenant Service to detect which tenant is currently running and do custom work at that level. In terms of models and namespaces the Alfresco API will first look for the correct models or namepsaces within each tenant, it will then fall back to any configurations that have been defined globally and proceed from there.
abhiram says
Just worndering why WCM is not supported in multi-tenancy ? It could have been a great thing ? Do you know the reason why ?
Tnewman says
Alfresco is not longer supporting WCM. It has been deprecated.
http://wiki.alfresco.com/wiki/WCM_Developer_Documentation
“AVM Deprecation Warning: The AVM is no longer being actively developed by Alfresco Engineering and Enterprise support subscriptions for the AVM are no longer being offered to new customers. New projects requiring Web Content Management features may want to consider leveraging a CMIS-based solution such as Web Quick Start or the File System Transfer Receiver. The topic AVM Decommissioning collects useful information for migrating off of the AVM.”