IBM and Alfresco partnership : Portal, Collaboration and Social Networking

January 14, 2010

IBM and Alfresco started to work together to provide integration solutions between their respective products.

I do not have more technical details for the moment, but this has been just announced and will be soon at Lotusphere (January 17-21).

As far as I know, the approach is to use the Alfresco DM capabilities to manage the persistency of data created
through IBM UI (Lotus Quickr, Lotus Notes, Lotus Connections and WebSphere Portal). So web UI is provided by IBM software (like Quickr), primary meta-data are stored in IBM layer also, and the document binaries are stored in Alfresco repository. Integration is achieved through REST protocol.

This integration will be available in the spring of 2010.

I think this is a very good opportunity for Alfresco, to be part of such a strong Portal, Collaboration and SN (social networking) set of solutions.

This is also a good news for IBM/Alfresco customers (as we are) because they can leverage their software investments and get the benefits of both world:
– IBM Lotus has a very complete offer in term of “2.0” softwares (Websphere Portal, Lotus Quickr for collab., Connections for SN), but none of these solutions really provide a very highly scalable data repository (as Alfresco do) to store terabyte of documents.
– On the other side, Alfresco is still a young product and is not able (yet) to address SN or portal features. Its web UI are still quite basic, but its core repository is designed to scale up to more than 100 million documents.

I don’t know if IBM also plan to integrate Alfresco with their Portal WCM solution (IBM Lotus Web Content Management)…but this will be a good idea…

As John Newton said at Lotusphere:
“I think the combination of Lotus and Alfresco provides a real SharePoint killer as well. With the combination of the two, there’s nothing that Sharepoint can do that we can’t.”
“It’s an opportunity for IBM as well to have a set of capabilities where Filenet might be too large or complex for a customer”, he added.

Another well known SN competitor is Jive editor. A tighter collaboration between Alfresco and Jive would surely make sense….No doubt that Alfresco is already working on this…

For more info about Alfresco/IBM integration:
Alfresco Content Services for IBM Lotus

Alfresco ECM gilds IBM’s Lotus suite

Alfresco Enterprise CMS Cozies Up With IBM Lotus

Also, if you are interested about integration of Quickr IBM product with other ECM vendors, this is something I have already discussed on my other (portal) blog:

Quickr and ECM relationship

Quickr and ECM integration

3 ways to find and restore a (single) “lost” document stored in Alfresco

December 2, 2009

This week, someone of my team told me he “lost” one document when working in Alfresco.
He told me he did some cut and copy actions using CIFS (windows explorer) and that he experienced some unexpected system behaviour…finally he was not able to find the document anymore in the Alfresco space…
I looked into the trashcan (managed deleted items) => nothing.
I ran a Lucene search on the full repo => nothing.

So yes, the document was not available from the Alfresco interface. But as the document has not been deleted, I was quite sure that it could in an “orphan” state (i.e no meta-data associated with the binaries on the storage file system). Maybe a “transaction failure” might have caused this situation…

Fortunately, the user gave me the following information about the doc:
– Filename : team_metodology
– Document type (MS .ppt document),
– The document topic (it is about “methodology”),
– The last time he saved it in Alfresco (“2009/12/1” at 10 AM).
– The space path is “Company Home/Space1/Space2/Space3”.

In this case, you have several solutions. Please note that none of them is a perfect approach, but these are the only solutions you have with the current 3.2 version.
They are ordered by complexity order (from most complex to less complex):


1/ Restore a full backup of day D-1. This approach requires you have:
– Full backup of database and content store for D-1 (or any backup which contains the doc).
– An Alfresco server dedicated to restore operation (that means it should have the same disk space available as your current production server).

Obviously, if you have a large repository, this is a very “heavy” operation, just to restore a single file.


2/ Restore only a database backup of day D-1:
– With this approach, you will restore only the DB, but not the ContentStore (because you might not have enough disk space to restore all documents),
– Basically, the approach is to:
   – Find the filesytem path of the doc in the DB (like “alfresco/alf_data/contentstore/2009/12/1/hh/mm/”),
   – Try to find the doc in the ContentStore backup based on the previous path,
– I assume here you have a Database server dedicated to restore operation (with enough disk space).
– Of course, you will not be able to use Alfresco application here => you will have to start the
DB only and do some SQL queries to find the corresponding path of the document.
– I never tested this approach, so I cannot give you the corresponding SQL queries. But basically, you should first use the filename (team_metodology.ppt) to find the corresponding entry in DB, and then try to find its path on filesystem (like “2009/12/1/hh/mm/”).

Once again, this has never been tested, so this is a pure theoretical approach…


3/ Search the doc binary on the Alfresco storage (filesystem):
– In our case, we are using a Linux filesystem as Alfresco storage. So the corresponding .bin object we are looking for is somewhere in the “alfresco/alf_data/contentstore/” directory.
– We know that last time user saved the doc in Alfresco was “2009/12/1” at 10 AM.
– We also know that doc is about “methodology” (so I assume here the string “methodology” can be found in the doc content),
– You should know that document filename and extension are modified by Alfresco when stored on filesystem (e.g “team_metodology.ppt” becomes something similar to “f8001f06-ddda-11de-a614-ad54d765801e.bin”).
– So the approach is to:
   – go in directory “alfresco/alf_data/contentstore/2009/12/1/10”,
   – do a grep on “methodology” (grep -ir “methodology” *): you might have several results:
Binary file 3/cc1eaf57-dddc-11de-ba7b-ad54d765801e.bin matches
Binary file 19/f18bad09-dddc-11de-ba7b-ad54d765801e.bin matches
Binary file 10/8b555d79-ddda-11de-a614-ad54d765801e.bin matches
Binary file 11/844c0916-dddd-11de-83bf-ad54d765801e.bin matches
Binary file 5/f8001f06-ddda-11de-a614-ad54d765801e.bin matches

   – Based on the last modification hour, these 2 files are matching:

   Binary file 10/8b555d79-ddda-11de-a614-ad54d765801e.bin matches
   Binary file 11/844c0916-dddd-11de-83bf-ad54d765801e.bin matches

   – Download the files on your computer, and then change the extension to .ppt:


   – Try to open these files (through windows explorer, not through the “winscp” client as this might not work).

   – One of them should be the doc you are looking for !

This last approach has been tested, so I can “guarantee” it is working.
But obviously, this is a “workaround” solution…Also you really need to know the last time
the document has been updated, otherwhise your “grep” search might take too much time.


I did talk with an Alfresco service guy last week, and he agreed that this could be a very useful evolution to be able to quickly find and restore an “orphan” document.

Our company employees are used to work with “Windows server” facilities, and MS do provide such feature to easily find and restore a single file from the backup.

He told me a basic custom dev could help here: each time a file is created/saved, Alfresco could add an entry in a log file to reference the mapping between a doc path (like “Company Home/Space1/Space2/Space3/team_metodology.ppt”)
and the corresponding path on the filesystem (like “alfresco/alf_data/contentstore/2009/12/1/hh/mm/”). This would
greatly simplify the document search into the ContentStore backup (or within the live ContentStore itself).

Of course a more industrialized solution provided by the editor would be even more appropriate…
I think I will open a JIRA for this evolution…