Alfresco Share “DocLib” Portlet for Liferay and JSR168 Portal

October 10, 2010


Our company ( is about to release a new Portlet for the Alfresco Document Management software (next week).

Our new component will especially be tested and supported with IBM WebSphere Portal (and of course Liferay), and will be JSR286 compliant.
The v1.0 open source version will be delivered next week in the Alfresco forge, and the supported (commercial) release is scheduled end of October.

I will describe our Portlet for IBM WPS soon in a next blog post, but before that I would like to present the “Share Portlet” recently published by the Alfresco team: Alfresco Share Portlets for Liferay and JSR-168 Portal

The “Share DocLib Portlet” is already well documented by Alfresco (see all links at the bottom of this article), so I will only give you the main principles:

Functionnaly the purpose of this “DocLib Portlet” is to expose the Share interface into a Portal.
As per the webinar presentation, it seems that almost all the rich document repository browser capabilities of Share have been “portal enabled” so far.

So the Share Portlet is a good choice if you want to fully expose the Share features and look & feel into a portal page (full window view).

Please note that some Share features are not “portal enabled” for the moment, like blog, wiki, etc. Also, as far as I know there is no search feature exposed.

Technically the Alfresco Share Document Library (and surf webscripts) have been “portletized” and can be deployed as a Portlet (.war file) into the Portal runtime.

The Share Portlet is not based on CMIS, but uses the existing Share webscript, because with CMIS it is still not possible to manage advanced feature like versionning, preview, etc (which are exposed in Share UI and in the Share Portlet).

The “DocLib” Portlet will be available for the following Alfresco version:
– Alfresco server components installable against Alfresco Enterprise 3.3.1 (already available).
– Alfresco Community 3.4.x (I think it will be included only in 3.4.c ?).

Initial Supported Stack:
– It will be supported by Alfresco only for Liferay Portal CE & EE 5.2.3 (Others TBD),
– As per the webinar it is not tested on other Portal (like IBM WebSphere), but it seems to mostly works on Weblogic.

The current version use use the standard Liferay ability to pass the portal UserID to Alfresco, and a special authenticator on Alfresco side accepts the credential passed by Liferay.

The webinar demo of the DocLib Portlet was really impressive, and the Alfresco team has done a great work ! Hope you will like it (more info below in the Useful links section).

Useful links:
Alfresco Share Portlets for Liferay and JSR-168 Portal

Read wiki documentation

Watch video, Portlet Installation and Configuration

Webinar recording:

New Portlet Development Options for Alfresco!

Alfresco 3.3 preview – Screen Shots of new features

April 23, 2010

Alfresco 3.3 preview – Screen Shots of new features : here

The full slideshow : here

Some screenshots about the new Data List feature:

Did you know this 3.2r (E) cool feature: Repository Browser from Alfresco Share ?

February 26, 2010

So far (until Share 3.2) you were able to browse only the documents stored in your own “Share Site”.
Now in 3.2r you can browse the full Alfresco DM repository !

For the moment, this Repository Browser feature, provides almost all the standard operations on documents (see below)
but not the “admin” option of the JSF client:
– Upload new files (single or multiple)
– Download
– View
– Edit Metadata
– Upload new versions
– Edit offline
– Copy or Move…
– Delete
– Assign workflow
– Manage aspects
– Change type

One limitation is still that fine grained security management is not exposed in Share.
So modifying the security of documents and spaces which are managed through the repository (from Share) is not supported in 3.2r (should be available in 3.3).
But as Paul Hampton said, most users would use the predefined security applied to the repository (security inheritance can be used on the repository side to simplify the security management tasks in Share).

That means You can browse the ‘Sites’ space to change security settings via the (JSF) Explorer client.
As Paul Hampton said “You just need to think about the implications of any changes that you make”.

For more info, and some screenshots : Paul Hampton’s blog

Alfresco (Share Form) as a WCM inline editing tool for portal ?

February 19, 2010

If you think about using Alfresco to easily manage Web Content, then this webinar is of interest:

Making Web Content Management Easy with Alfresco Share 3.2

Basically the partner Blue Fish has used the new Share form feature to build “inline editing” forms. (inline editing allow contributors to browse the web site, and edit content “in place” whithout being redirected to another tool or interface).

This is quite similar to what portal software (like IBM or Liferay) already propose for authoring….but here the big advantage (in term of infrastructure) is that you can use a remote Alfresco runtime (i.e not coupled with your Portal JVM) to manage WCM…That means you can do content authoring directly from your production portal layer, without impacting performance of your portal front-end layer.

The form that has been demonstrated was really user-friendly and easy to use…this is exactly what contributors need !!!

Some thoughts about extranet design and customer data isolation (Share vs DM multi-tenancy)

February 9, 2010

One problem you might experience when designing an Extranet based on Alfresco plateforme, is how to isolate the data of each customers or business unit using the Extranet (not only documents, but also users accounts and groups, and administration priviledge) ?

Basically, I think Alfresco proposes 2 distinct solutions:
– Multi-Tenancy,
– Share site.


Multi-Tenancy wiki page

The purpose of MT is to manage a single physical Alfresco instance, but to be able to split it in distinct logical tenants (like partition).

With MT, you have 1 shared database, but you can configure several “alf_data” directories (e.g one for each customer).
(this might be based on “Content Storage Policies” but I’m not sure).

This MT design was initially provided by Alfresco for SaaS provider (which tries to mutualize their infra. cost), to
clearly separate each customers context.

As far as I know, MT is not designed for large scale deployment (i.e you should not host more than 20 small customers site on the same instance)…
Also, if you are a SaaS provider, you should probably consider using distinct “VMWare” servers…with low cost virtualized servers, you can achieve the same goal, and also have strictly separated backup, etc.

Share site:

Alfresco Share

As long as you have to deal with Extranet, Share is likely to be a better choice.

Initially, I think it has been designed as a front-end application to address an Extranet need.

Also, regarding the data isolation, you have the following options:
– You can create “private” sites (actually site can be public, private or moderated). So your documents will not be visible by others users,
– You can use your internal LDAP (for internal employees) + invite external users. These external account will be stored locally in the Alfresco DB.
– If you invite external account, you can configure the format of the login.
– If you use your internal LDAP, you can continue to manage your existing Group, and do the mapping with the Share site Groups (nested Groups are supported).
– Also, you can easily create new sites (probably not easy to add a new partition to your MT instance).

So as a customer (which has to deploy an Extranet plateform for both internal Employees and external users) I think Share is clearly the best approach.