Alfresco Multi-Tenancy and HPI

This week we had a new client into the office to brainstorm on ways the client could leverage HPI as part of their cloud based content management offering. In addition to the infrastructure and interface discussions, the conversations also involved lots of joint partnership opportunities around selective case studies. This post will share some of our findings for the week with our strategy moving forward.

Geographic locations, Alfresco Licensing, CPU, Cores, Solr…..a flexible approach

On the first day, a significant portion (probably too much) of the discussion surrounded infrastructure decisions around Alfresco and expected volumes. Licensing decisions also come into play as the client was looking for flexibility combining:

• 4 CPU Licenses of Alfresco
• Built in Solr instances of Alfresco
• External Solr instances
• Multi-tenant Alfresco environments
• Single-tenant Alfresco environments
• 3 different geographic installations

In trying to define the exact configurations given volumes and other components, the team decided to take a more agile approach to the infrastructure. This is something we recommend often to clients. Clients often spend considerable amount of time (maybe it is the engineers in all of us) trying to determine what could go wrong regarding volume and how to address it at the beginning of the project. Rather than design and make expensive decisions for speculation on how the system would be used, we determined that we should take a gradual approach and monitor how the system is actually being used. Our plans focused on having a flexible infrastructure that could be adjusted for volumes and clients. Flexible infrastructure components included:

• Ability to cluster in active/passive modes early on and switch to active/active as customers are added and additional capacity is required.
• Ability to add separate Solr instances for given clients based on usage and search performance.
• Ability to add separate Solr instances for full-text searching as capability was added.

Multi-Tenant Alfresco, HPI, Content Model and Document Types

One of the big sticking points with running Alfresco in a multi-tenant environment is a similar concern in running Alfresco for multiple departments.

“How to manage all of the different document types?”

In our typical Alfresco multi-departmental implementations, clients will determine their taxonomy/document types and define Alfresco document types with appropriately named attributes. Two major concerns in regards to multi-tenancy include:

• Every time the content model is changed requires a restart of the Alfresco server (outage)
• Content model can get unwieldly if the goal is to provide the flexibility of each tenant to be able to customize their content model resulting in potentially hundreds of different document types.

To solve the above issue, the team determined to leverage two of HPI’s unique abilities:

• The ability of HPI to have a separate configuration file for each tenant. The configuration file is launched on login and is stored in Alfresco.
• The ability of HPI to give attributes a user-friendly label. In this manner, we could share a similar content model/document type and allow one tenant to use an attribute for one purpose (ex: location) and another tenant to have use the attribute with a different label for a different purpose (ex: plant or district).

Search and Security

One of the major concerns with two tenants sharing the same Alfresco repository is search and security. Making sure that search is quick and efficient is a key user satisfaction metric. Another satisfaction metric is making sure users are only seeing the appropriate content and not seeing other tenants or any documents inappropriately. Focused on our flexible approach, our strategy involves multiple options:

• Each tenant will be separated into separate Alfresco sites. Additionally, each will be a separate tenant within the Alfresco repository, providing for siloed content stores.
• Each tenant will have separate document security allowing for different security per document type or based on attributes.
• Searches could be automatically filtered to support security requirements not addressed above or within tenant users.
• Separate Solr instances could be configured for each tenant if search performance is deemed an issue.

HPI currently provides the ability to search both Alfresco (via normal Alfresco searching) as well a standalone Solr instances.

Web Services

The last major discussion surrounded a method to allow clients to leverage Web Services to access/upload their own documents as part of the service. Alfresco supports CMIS and TSG supports OpenContent as REST based interfaces to access Alfresco. The unique requirement has to do with the shared content model mentioned above. As the tenants will be sharing a content model, search and retrieval will need to take in account the labeling of different attributes. So far we have identified two possible solutions:

• Implement a new web service that wraps either OpenContent or CMIS and accesses the HPI configuration file for the labels as part of the service.
• Provide a mapping for the client developers of which labels represent which attributes to allow the tenants to call Alfresco directly.

Summary

Clients considering a multi-tenant approach with Alfresco should address unique requirements in regards to infrastructure, interface, object model, security and integration requirements. Rather than try to design for every contingency, a good approach relies on flexibility and a variety of options in an agile approach to address issues quickly as they emerge. Let us know your thoughts below.