Integrating Alfresco 3.4 in Liferay 6.1 via CMIS 1.0

Alfresco Enterprise 3.4 delivers social content management. This new release delivers on Alfresco’s vision of providing the open platform for social content management by delivering both a more robust content platform for building any kind of content-rich application, along with a more social user-interface for collaboration and document management. Refer to alfresco website.

In previous blogs posts, we have discussed how to integrate Alfresco 3.2/3.3 with Liferay 6 via CMIS. This article is going to continue the discussion of the topic - integrating Alfresco 3.4 in Liferay 6.1 via CMIS.

How to achieve it?

You would be able to integrate Alfresco 3.4 EE via CMIS 1.0 in Liferay portal 6.1 in following steps.

  • Install Liferay portal 6.1 (revision 71867) at $LIFERAY_HOME; Liferay-Tomcat bundle is expressed as $TOMCAT_AS_DIR; and $PORTAL_ROOT_HOME = $TOMCAT_AS_DIR/webapps/ROOT;
  • Locate Alfresco 3.4 EE WAR ${alfresco.war} and Share WAR ${shared.war} at $ALFRESCO_INSTALLATION/ tomcat/webapps
  • Drop ${alfresco.war} and ${shared.war} to $TOMCAT_AS_DIR/webapps;
  • Create a database alfresco in MySQL.

drop database if exists alfresco;
create database alfresco character set utf8;
grant all on alfresco.* to 'alfresco'@'localhost' identified by 'alfresco' with grant option;
grant all on alfresco.* to 'alfresco'@'localhost.localdomain' identified by 'alfresco' with grant option;

  • Optionally, create database lportal in MySQL

drop database if exists lportal;
create database lportal character set utf8;
grant all on lportal.* to 'lportal'@'localhost' identified by 'lportal' with grant option;
grant all on lportal.* to 'lportal'@'localhost.localdomain' identified by 'lportal' with grant option;

  • Create a file named portal-ext.properties at $PORTAL_ROOT_HOME/WEB-INF/classes and add following lines in portal-ext.properties.

dl.hook.impl=com.liferay.documentlibrary.util.CMISHook
cmis.credentials.username=admin
cmis.credentials.password=admin
cmis.repository.url=http://localhost:8080/alfresco/service/api/cmis
cmis.repository.version=1.0
cmis.system.root.dir=Liferay Home

Especially you may install Alfresco 3.4 in different server, call virtual server. In this case, you need to update cmis.repository.url as follows

cmis.repository.url=http://${domain.name}:${port.number}/alfresco/service/api/cmis

In addition, you may have different admin account in alfresco. Thus you need to update cmis.credentials.username and cmis.credentials.password.
cmis.credentials.username=${admin.name}
cmis.credentials.password=${admin.password}

  • Optionally, add database connection in portal-ext.properties.

## MySQL
jdbc.default.driverClassName=com.mysql.jdbc.Driver
jdbc.default.url=jdbc:mysql://localhost:3306/lportal?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false
jdbc.default.username=lportal
jdbc.default.password=lportal

Of course, you can use different database systems.

  • Start the portal

Of course, you can get the latest WAR of Alfresco Community version or Enterprise (Trial) version from Alfresco website

http://www.alfresco.com

Testing by examples

In Control panel of Liferay portal, select default community “liferay.com”; and going to Content->Document Library, upload two documents (pdf and ppt, for example) as shown in following screenshot.

Then logging in to Alfresco as "admin/admin", you would see the folder "Liferay Home" and documents as shown in following screenshot. That is, Alfresco becomes direct repository of Liferay Document Library via CMIS. All real content is stored in Alfresco, while all metadata is stored in Liferay database.


 

Open issues and new features

One known open issue is LPS-12406 - CMIS hook conflicts with plugins hooks. It will get fixed shortly.

And good news – Liferay 6.1 will allow Liferay to act as a CMIS producer, including CMIS Producer support for WCM (LPS-10201); and CMIS consumer Support (LPS-13160) - a ton of thanks to Alex.

Blogs
Thanks for sharing this with us Jonas. I have never used Alfresco before. So just for satisfying my query. Using Alfresco like this makes all the documents saved in Alfreco repository. Is it a filesystem that alfresco saves data to? And what happens when i go for clustering?
Yes, Alfresco stores its binary data in an file system (metadatas are in database).
For clustering, yo can have differents scenarios, but most of the time only the front part of Alfresco is clustered.
For repository clustering, you have to use some database and file replication. (https://intranet.groupe-asten.fr/web/asten-blog/blog/-/blogs/alfresco-:-deploiement-et-scalabilite)
I just attended an Alfresco Lunch & Learn event last Thursday and your post came just in time. Thank you Jonas.
Although storing content through Liferay into Alfresco (or any repository) using CMIS is a nice 'technical' exercise, I don't think CMIS is meant for that. CMIS' power is the combination of metadata and content, not just content.
If you want to enable content from Alfresco, use one of the portlets, that gives you a much richer experience. Using the currently proposed 'integration' leaves Alfresco as a dumb file store. It is impossible to use these documents inside Alfresco, because the metadata (file name??!!) did not come across the line, it is kept in Liferay. That is a pity, all this opportunity thrown away...

It would be nice if this CMIS integration allowed people to use Alfresco for it's purpose, use smart folders, authorisation, workflow, approval, whatever, and publish or access it from Liferay. Meaning the documents and metadata belongs in Alfresco, and Liferay getting and putting stuff in there (content AND metadata) using CMIS. In this manner, CMIS is repsected, Liferay does it's thing, and any repository (for example Alfresco) canuse all it's functionality.

That is what the standard is meant for. In my opinion...
Hi Tjarda,

The current CMISHook integration in Liferay v6.0 is not simply a technical exercise, but it provides people with a different repository protocol that they can leverage if they want to use a particular system to store their files. This is the same reason why JCRHook and S3Hook exist. If you don't want to store things in your filesystem (for a clustered environment, for example) you can move it to another system.

Having said all that, Liferay v6.1 is going to be quite different. If you keep track of Liferay's trunk, you will notice that the document library's backend has gone through a huge change in order to support exactly what you are suggesting. That is, it will provide CMIS integration that carries the metadata and other content from the repository over to Liferay. Having said that, be aware that all protocols are imperfect and do not support vendor-specific features like Alfresco's workflow, smart folders etc. But, we are working on something for that too... more to come in the upcoming months..

Alex
I can agree on the storage story. However, If you put any repository underneath that has rich functionality, keep it there and allow this repository to do the thing they are designed for. That is more than just storing content.

CMIS allows to delegate the storage to this repository. This allows any repository to be used where it is designed for (in its own application), and allows Liferay to be a layer on top, transparently using a repo underneath.

I think the crux of our discussion is that I don't understand why the current implementation in Liferay throws away all possibilities to use the repository functionality by itself (in a meaningfull way). -All- this functionality does not necessarily have to be (re)implemented in Liferay (preferably not!).

For example: The repository can well be a back-office system, and Liferay a front-office or public facing layer. This back office repository has a need for metadata. De content can be developed, stored an be managed in a controlled manner. One or some point in time (all the time?) the content is visible, trackable and maybe editable through Liferay (using CMIS).
Maybe my use case is not what was envisioned for the current implementation...
Agreed. Just met same case, spent one week tring to workaround for customer who expected to use CMIS integration of Liferay and found what it is unusable.
From my point of view - it looks like CMIS integration should be implemented as totally separate implementation of Document Library service (with supporting same interface).
In this case customers will be able to use nice Liferay UI for working with files - but whole Document Library service will be used CMIS (files, folders, versions, metadata and so on and so on).

Any other kind of integration will be compromize like now - and not sure will be usable by real business.
@Tjarda @Alexey

Yes, I think you are basically talking about what I mentioned in my second paragraph. To be clear, Jonas has shown the trunk version of Liferay (which is what v6.1 will eventually be built with) but it is not 6.1 (which will look VERY different).

We will have two separate integration points for the Document Library. The first, is our Hook mechanism. The second, is to bring in repositories that currently exist. And, like Tjarda has suggested, it is basically a front-end to back-ends hosted and managed by external systems. All the metadata, versions, folders, etc. are managed by the repository and DL will become the front-facing UI for that.
Hi Alex. Thanks for confirmation. Any release date for 6.1 with this functionality? It is really quite important for my customer and he currently trying to make decision what to do. In case he will need to wait 6.1 - it should be clear how long to wait.
Our projections right now are 6.1CE for Q2/mid-Q3, 6.1EE late-Q3.
Hi Alex, thanks a lot.

I got a few comments. First, if users access a CMIS repository that has been populated via Liferay directly, they don't see the same folder and file structure that's visible in Liferay, and don't have access to any of the important metadata or ACLs of that content. Lack of ACLs would be a critical security hole.

Second, none of the content created in the CMIS repository outside of Liferay will be visible to Liferay, since Liferay won't have the metadata for that content and doesn't (currently) use the CMIS APIs to discover such content.
Hi Jonas,

Yes, internally in Liferay, we are aware of these two concerns. The first one is not necessarily problem in the hooks paradigm since it is really the exclusive use of one repository for Liferay's backend storage.

The second is something we have been doing a lot of engineering work lately (especially this past week) to try and hammer out. Having said that, the metadata exposed by CMIS protocol is somewhat limited still.
Jonas! Thanks for review and plans for new features for CMIS! But - I really think you need better explain what people will get from this integration.
In current state - such integration then only content in unusable way (since only file content with special structure stored in Alfresco - so, you cannot use these content anyhow from Alfresco side) really confused users.

Just now my customer has BIG problems: he read about CMIS integration - and expected it is "normal" integration - when Liferay utilize wide range of CMIS functionality (folder,s, versioning, metadata and so on) - so, these files may be used from both sides - Liferay (for example to display) and Alfresco - to manage.
He included this CMIS integration in own business plan, he promised to investors what Liferay & Alfresco integration will be done easily with using Liferay's CMIS Hook.
But then I've configured his Liferay to use CMIS and he saw how it works (totally unusable from business point of view) - he was really disapointed with Liferay - because such kind of integration totally brokes his plans.
For now he should wait 6.1 release (then it will be released ??? ) in case he planned to go life in January - and again - he is really disapointed - because real implementation are very far from his expectations.

It is clear - "CMIS integration" is good marketing words for Liferay - you can include in press-releases and white papers.
Of cource you write in your blog: "All real content is stored in Alfresco, while all metadata is stored in Liferay database." - but who reads details and can clearly understand what does it mean from real case? At least picture - displayed what you will get in Alfrescoshould be much bigger to do not confused user.

So at least on current level of integration - such integration has no any real business use - and may produce more and more problems with customers like in my case and produce bad impression about Liferay.
From my point of view - it is better to do not tell about CMIS integration at least until it will not be implemented by level - it will be possible to use in real business projects.
I'm really sorry for your customer Alexey.
On the other hand: open source means release early, release often, and we follow this practice. This is the way how our community will know our direction and progress. And we can get feedback (thanks for that!) to know our community's needs.

Business use is something different, I think.
A technical decision has to be based on technical information. In this case: an experimental technology has to be POC-ed. Only if the POC is successfull, business can be based on that. And you are right, this technology is not-yet business-ready. Of course it is not included in our currently supported (business ready) product either.

As soon as the technology is feature-complete, you will find it in our CE release.

As soon as the technology will pass all the tests needed to be called business-ready, you'll find it in our EE release.
Akos, I'm totally agreed with way Liferay is going - adopting solutions with free CE versions and providing stable full-features solutions in EE. I think it is really great - because provided customers flexibility and choise - depending from importance and budget customer may choose version they stay.

But speaking about this "CMIS integration" here is few problems:
1. This article (as well as same article described CMIS integration in 6.0) is not describe clearly what it is "technical" - not "business" case.
2. "CMIS Integration" in it's current state already in 6.0 EE - so, Liferay sell it
3. As well as "CMIS integration" in EE datasheets (ok, not advertised as major feature, but CMIS support listed in EE datasheet)

Sol Liferay already sell this "CMIS integration" in EE, even it is not business ready and just a "adoption of technology"

Real CMIS Integration planned for 6.1 - I think it will be one of the killer feature. As well as it is truly Enterprise feature and for me I do not see problem if it will be available only in EE version - pretty sure many customers will ready to pay money only for it.
And of course it is clear what partners role is to clearly explain customers which features are business ready and which is not. Unfortunately in my case I wasn't involved on the "decision making stage" and all decisions was made before we were involved into project.
Thank you all. Your comments and feedback are very helpful for CMIS enterprise integration in Liferay. The goal here is to make CMIS integration piece perfect.

I am trying to get more feedback from CMIS producers, customers, communities, etc. Hopefully that CMIS integration would be perfect in near future.

@Alexey, thanks. Do you have a wish-list on CMIS integration?

As mentioned by Alex, there will be two separate integration points for the Document Library:

1) hooks
2) CMIS as a direct repository
Try these proprieties for LR 6.1

dl.store.impl=com.liferay.portlet.documentlibrary.store.CMISStore
dl.store.cmis.credentials.username=admin
dl.store.cmis.credentials.password=admin
Yes, Thanks.

Full settings are here:
#
# Set the name of a class that implements
# com.liferay.portlet.documentlibrary.store.Store. The
# document library server will use this to persist documents.
#
#dl.store.impl=com.liferay.portlet.documentlibrary.store.AdvancedFileSystemStore
#dl.store.impl=com.liferay.portlet.documentlibrary.store.CMISStore
#dl.store.impl=com.liferay.portlet.documentlibrary.store.DBStore
dl.store.impl=com.liferay.portlet.documentlibrary.store.FileSystemStore
#dl.store.impl=com.liferay.portlet.documentlibrary.store.JCRStore
#dl.store.impl=com.liferay.portlet.documentlibrary.store.S3Store


#
# CMISStore
#
dl.store.cmis.credentials.username=none
dl.store.cmis.credentials.password=none
dl.store.cmis.repository.url=http://localhost:8080/alfresco/service/api/cmis
dl.store.cmis.system.root.dir=Liferay Home