Alfresco and Jive social software integration (some screenshots)

January 26, 2011


Our company ( just released in production – for one of our customer – a new component to integrate Jive (Enterprise Social Networking solution) with Alfresco document management solution.

I will published a detailed blog post in a few days, but I can’t wait to share with you some early screenshot of the interface (see below).

In this case, Jive is used as the front-end solution (for social collaboration around document), and Alfresco is used as the document repository.
From the Jive interface, people can upload documents into Alfresco, and then get the corresponding link to collaborate around it using the Jive features.

Basically, a concrete example of integration with Social software !

01 – widget selection wizard – jive alfresco

03 – widget configuration screen – jive alfresco

04 – Working Layout – jive alfresco

05 – Menu folder – jive alfresco

06 – Menu document – jive alfresco

07 – upload – jive alfresco

08 – New folder – jive alfresco

09 – Tooltip – jive alfresco

10 – Copy a link without Flash – jive alfresco

11 – Search Results – jive alfresco

More info coming soon….

1 reason to choose Alfresco vs Quickr for document management : scalability

January 26, 2011

More and more people are asking me the same questions about IBM Quickr vs Alfresco Document Management solution.

– what are the main technical and/or functional differences between Quickr and Alfresco ?
– When should I use Quickr, when is Alfresco more appropriate ?
– What is the best solution for document management ?
– etc.

I have already published a few blog post about this topic (see list below), but to summarize:
– Alfresco is a Document Management system, Quickr is not.
– Alfresco is a scalable solution, Quickr is not.

OK…let me give you more details 🙂

– Alfresco is designed as a highly scalable document repository, and can store huge volume of documents, Quickr cannot.
– Alfresco has a very light and robust software infrastructure, which allow to support a lots of concurrent users. Quickr is much more limited.
– From the hardware point of view, Alfresco can run on a very small server, with a few CPU/RAM resources. Quickr relies on a portal application architecture, so it is a quite heavy solution.
– Quickr is primarily a collaboration tool, Alfresco (now with Alfresco Share) also offers collaboration capabilities.

As you can see reasons seem more technical than functional, and that’s true.

If you study the respective DM features of each product, a high level functional analysis might show that these 2 solutions seem to offer the “same” level of service (versioning, security management, checkIn-Out, tagging, etc).

OK, but what if your end-users request (in the middle/long term) more advanced features like workflows/BPM, automated rules, archiving, etc…Then Alfresco will be more adapted.

If you are already using Quickr for document management/collaboration, for a limited number of users, and with a *very* small volume of data (50 GB, 100 GB ?), then you might think that switching to Alfresco does not make sense (due to cost of migration) in the short term…

OK, but I’m almost sure that your volume of document is growing quickly each day…right ?
(Even if it is not the case, just from the infrastructure cost perspective, you should consider Alfresco to reduce your hardware budget…).

So one of the main reason to choose Alfresco is its capacity to manage a huge volume of documents.
Scalability is the key argument. Be sure that, whatever the DM system you will implement in your company, people will very quickly adopt it (just because so far they had no other place to store their data), and the number of documents in your repository will grow faster and faster. Not only documents, but also images, videos, blogs, wiki, etc.
So sooner or later (but most likely sooner that you would expect), you will have to deal with hundreds of gigabyte of data or terabyte of data…and this is clearly not something Quickr is able to support.

Finally, I’m not saying that Quickr is not a good solution. My point of view here is that it is more a portal/collaborative solution, than a DM system.
So IBM Quickr could be an appropriate solution, for collaboration use-cases, portal integration, etc, but not as a document management solution.

Related posts:

Quickr and ECM relationship

Quickr and ECM integration

IBM and Alfresco partnership : Portal, Collaboration and Social Networking

Alfresco Portlet for IBM WebSphere Portal (JSR-286)

October 17, 2010


Alfresco document management features now available for IBM WebSphere Portal

Alfstore ( is proud to announce the release of a new Portlet for Alfresco that has been certified to run on IBM WebSphere Portal, and other JSR-286 Portal containers (as Liferay).

The treeview portlet exposes the content of an Alfresco space in the tree-view way. It provides all in-line editing features for documents and folders.

The user can then easily access to his/her documents, through a portal, using an ajax-style view. Only the common document management operations are exposed, to make the interface as simple as possible:

Actions on documents:
– Create (upload), Update, Delete,
– Edit : user can edit and save a document directly online from the portal (using the CIFS or the WebDAV protocols).

Actions on folders:
– Create, Delete, Refresh, Rename.

An advanced configuration mode allowing flexible appearance and functionality tuning. For example, the CIFS protocol can be disabled, and the user can select a specific space as the “root folder” to start the navigation.

So the “complexity” of the Alfresco standard interface is hidden, and this Portlet can really be used by none advanced users.

The Portlet layout is light and small so it can be integrated on a multi-column page with others portlets.

– This Portlet was written for the IBM’s WebSphere Portal first of all (and fully tested on it), but does not use any WebSphere specific functionality, so it can run on others JSR-286 portals.
– The Portlet uses the standard Alfresco Web Service, and is compliant with Alfresco DM v2.x, 3.x.

– A free (not supported) open source version can be downloaded on Alfresco forge (
– A basic SSO mechanism is provided, so Portlet can be easily tested.
– The Enterprise version will be available shortly (end of Oct. 2010)for Alfresco customers.
– The Enterprise version will be fully supported by Alfstore and will be updated in lock-step with new versions of Alfresco and/or WebSphere Portal.

Enterprise version:
– Along with a professional support, the commercial version will include more advanced features, like:   
– Support for Enterprise SSO solutions (SSO CAS, IBM, Siteminder),
– Search features (search Alfresco documents from Portal),
– Multi-file upload,
– etc.

Learn More:
– Please feel free to contact us ( for more information.
– The detailed roadmap of this component will be updated on the Alfresco wiki.
– A webinar will also be presented in the near future.
– Company website :

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!

Confluence (WIKI) to Alfresco connector now available

August 4, 2010

When contributing to wiki pages, one has often to refer to a more structured document (like .doc, .ppt, etc) stored elsewhere, for instance in a Document Management system.

In most WIKI tool, you can of course upload such doc directly into the WIKI repository: but this mean you will create a duplicated copy, which will likely never be updated in the WIKI.
So the best practice is of course to include hypertexte links pointing to the document URL in Document Management system. But this can be a tedious task if you have several links to refer to…

So this is the purpose of this “Wiki to Alfresco connector” to ease your life, if you have a Confluence Wiki (Atlassian software).

The Confluence (WIKI) to Alfresco connector is now available here.
Basically, this connector enables Alfresco system to be integrated with Confluence.

Integration means that Alfresco documents can be listed, accessed, edited, and/or deleted from within Confluence. Or they can be in a read-only repository, if appropriate.

Documents in Alfresco are stored in different Alfresco spaces; the Confluence macros can be placed in different Confluence pages with mappings to different Alfresco CMS spaces.

You can also directly try the connector online, through this test page.

I tried to upload a new document from this test wiki page:  it has been stored automatically into Alfresco, and then displayed directly into the wiki page…integration seems to work well !

Alfresco permission management: how to know on which spaces a Group has access ?

July 30, 2010

In Alfresco, you can create Groups (i.e group of users), and use them to manage permission on spaces. This is obviously a best practice to assign permission through Groups, not Users.

If you have a LDAP, you can also easily synchronized your Groups and Users from LDAP to Alfresco, using the standard synchro job provided by Alfresco.

But once the Group has been applied on several spaces ACL (as Coordinator, Contributor, etc), you have currently no possibility to know the corresponding space list…So what if you want to check on which spaces/documents the Group has access and also which rights have been granted to this Group ? This is the purpose of the SQL query provided hereafter…

Actually we had this need, because we had to rename the Group name in Alfresco into upper case (due to some upper/lower case conflict between the Group name in our LDAP and in Alfresco).
Basically, (our) LDAP is case “unsensitive” (I mean we cannot create 2 Groups with the same name but distinct case, like “My_Group” and “MY_GROUP”), but Alfresco is case “sensitive” (so you can create 2 Groups with the same name but distinct case, like “My_Group” and “MY_GROUP”).

Also, what you should know is that there is no way to change the Group name in Alfresco programatically….(validated with support ; see

This query will return the list of spaces, on which the Group “My_Group” has access (explicitely, not through inheritance), and also the level of access granted (Coordinator, Contributor, etc):

SELECT ap.node_id, ap.string_value, acl.inherits,
FROM alf_node an, alf_node_properties ap, alf_acl_member acl_m,alf_access_control_entry ace,alf_authority alfauth, alf_access_control_list acl, alf_permission aperm
WHERE = ap.node_id AND ap.qname_id= 90
AND an.acl_id = acl_m.acl_id AND alfauth.authority LIKE ‘%My_Group’
AND acl_m.ace_id = AND = ace.authority_id
AND = acl_m.acl_id AND = ace.permission_id
AND acl_m.pos=0;

Some explanation about the parameters used:
ap.node_id (space id)
ap.string_value (space name)
acl.inherits (Inherit Parent Permission check box : value 1- true, 0- false) (Permission role : value Coordinator, Collaborator, Consumer, Editor etc)

Then with the node id retrieved from above query you could get the exact path of the space, with this other query:

SELECT parent_node_id, child_node_id, child_node_name
FROM alf_child_assoc
start with child_node_id = 66469
CONNECT BY PRIOR parent_node_id = child_node_id
order by parent_node_id;

If you want to get also the corresponding inherited permission (i.e sub-spaces and documents which inherits from the parent space ACL), you just have to remove the filtering condition ” AND acl_m.pos=0; “.

Note1: these queries has been tested with version 3.2 E.

Note2: if the 3.2 Alfresco instance has been installed from scratch (empty), you should use the value : “ap.qname_id= 90”.
Otherwhise, if the instance has been upgraded (e.g from v2.x to 3.2) then you might have to get the proper qname_id value with this query:

Alfresco use-case: paperless project for insurance

June 13, 2010

This article was posted May 2009, but for those who did not read it already, I think it is a very good example of what could be the benefits of implementing Alfresco, and all the typical ECM use-cases for a company (insurance):

Allianz removes walls of paper with open source ECM

It describes the Allianz paperless project (in Australia) and how paper-based processes have been replaced with the Alfresco ECM system.

Here is a synthesis and an extract of the key points:

Some typical use-cases:
– Customer needs ECM (enterprise content management) for functionality that is “more than just storage”.
– Paperless: no more need to copy documents around. Lots of documents can be scanned and then stored in Alfresco where one can find them easily.
– BPM: ECM gives the possibility to control the process of workflow and sign-off.
– “Record management” like feature: ECM system allows document lifecycle management strategy, especially for documents that need to be retained for X years after closure and that have to be kept for compliance reasons.
– OCR is also a big focus because usually a lot of documents are stored, but not necessarily indexed.

As per Allianz, the criterias to choose Alfresco were:
– “key criteria were cost, agility, capability, technology fit, integration options, and functionality.”
– Allianz representative also praised the speed of implementation: “The Alfresco part only took a few weeks, including load testing.” (…) “We have an ECM up and running quickly, our costs are low and have a lot of growth and future.”

– “We went in with 250,000 documents on day one. Alfresco does what it says on the box.
– “Since going live about 12 months ago Allianz now has almost one million documents stored in the ECM system for a total of 500GB of data.”

– In terms of purchase cost, Allianz representative was “not allowed to give figures”, but was happy with Alfresco and says it was “a lot less than going down another path”.
– Regarding custom developments: Allianz has two developers working on Alfresco so it doesn’t have a lot of resources on a day-to-day basis and allows them to concentrate on “enhancements, not maintenance”.