Tag: webscripts

Confluence Alfresco Integration for the Enterprise

Posted by on October 05, 2010

Today organizations of all sizes are adopting wiki solutions as a way to facilitate communication and collaboration around planning, projects and departmental matters. Wiki solutions allow users to attach documents to pages and to hyperlink to those documents from other pages. This is extremely useful, however documents, which have traditionally been stored and secured on corporate shared drives are now living in separate places. Some now live within the wiki, while others continue to live on file servers. This is an example of an age-old issue in technology; as we bring in new tools that provide us with more options and better ways to work we are faced managing the side effects of a growing technology footprint.

This issue is not new technology, but instead, one of architecture. As our needs grow we need to adjust our architecture to accommodate new demands. In this case, what we need to do to solve the problem is to separate a few concerns. Some users want to access the document through a file server (shared drive) while others want to access it via the wiki. Traditional shared drive technology doesn’t do a great deal to help us accommodate this. Traditional shared drives provide file system access to documents but lack APIs that allow us to get to our content by more sophisticated means. Further, most wiki technology is one sided as well; while a wiki solution may provide web based access via pages and services they tend to lack file system access. Finally, even if the wiki could “project” its store as a shared drive it’s not likely to be the proper system of record for your documents. By separating the issues of storage, management and delivery we can articulate a solution that allows us to serve documents through a traditional shared drive interface via a proper system of record while at the same time, providing APIs that allow us to get to that content as a service so we can incorporate better ways of working with the document through new technologies as they emerge.

Enter Alfresco. Alfresco is architected from the ground up to be a system of record. It’s designed to provide API / service based access to your documents and content, as well as traditional shared drive access. Alfresco supports three different remote programming APIs including SOAP, webscripts and CMIS. And in addition to presenting itself as a file server so users can connect to it as a file share, Alfresco also mimics an FTP server, a WEBDAV server and even a Microsoft Share Point server. Alfresco is designed to store, secure and manage your documents and to provide access to those documents in the way that best suits your users.

If we use Alfresco to store our documents and integrate our wiki solution to read and write documents though Alfresco’s APIs rather to the wiki itself we satisfy our objectives:

  • Store documents in a proper system of record
  • Allow file-share access to the documents
  • Allow API level access to client applications like wiki

confluence attachments integrated with alfresco

hlgh architecture

Alfresco’s capabilities go far beyond security and content retrieval. Once your documents are in Alfresco they can be searched, workflowed, transformed, translated, versioned and so on and so on, no matter how they are accessed; all through stock capabilities provided by Alfresco out of the box.

At Rivet Logic we see real value in allowing knowledge workers to interact with their content though tools and in whatever process that fits their needs best. At the same time, it’s important to manage content or the same efficiencies that are gained through productive tools and well-designed process are lost due to stove-piped information. The need is real, and given that, we set out to create an open source project that demonstrates a more appropriate architecture and provides a stepping-stone for much greater integration going forward. Najy Nicolas, a “Riveter” from our Boston office has integrated one of the most popular wikis, Confluence, with the management capabilities of Alfresco, the leading open source document repository. We’re calling this project the Confluence Alfresco Integration rivet or CAIr for short. CAIr is open source. You can find downloads, source code and documentation here: http://wiki.rivetlogic.com/display/CAIR/Home

Alfresco integration with JSR 168/286 portals

Posted by on April 15, 2009

At Rivet Logic Corporation I’ve been tasked many times to expose Alfresco features through a JSR-168/286 portlet hosted in JBoss Portal or Liferay Portal. Easy right? Not really, and here’s why:

Today Alfresco provides us with a couple of ways to do this:

1. Write a portlet and use Alfresco’s Web services API to expose the Enterprise Content Management (ECMS) features
2. Use Alfresco’s out-of-the-box Web script portlet to expose an Alfresco Web script

The first approach works but in many cases requires that you develop custom Alfresco actions since the Web services API does not cover the full feature set of AFS (Alfresco Foundation Services).

The second approach provides us with more AFS coverage but has one restriction that is not easy to work with. It requires that all of Alfresco be deployed inside the portal as a portlet application. So if you needed to deploy JBoss Portal running an Alfresco Web script portlet that exposes the MySpaces Web script, the deployment would look like this:

The problem with this approach is that it introduces scalability constraints. Namely, if you need to scale the portal you are forced to scale Alfresco with it and vice versa.

For the Web services approach we have an alternative thanks to our Remote Alfresco API rivet (RAAr). With RAAr we are able to make use of Web frameworks like JBoss Seam backed by rich UI component libraries like RichFaces to develop JSR 168/286 portlets that expose most if not all of the AFS features using a Java-based API that uses RESTful communication to provide a secure and scalable interface to Alfresco. One example of a document library portlet that we created using this approach is shown below:

On the other hand, if you need to go with the Web script approach you’re pretty much out of luck unless you’re willing to go with the deployment architecture shown above. The fact that there was no single solution for this problem was all the motivation I needed to create AWPr (Alfresco Web Script Portlet rivet). With this portlet we will be able to have a better deployment architecture that could be represented by the following diagram:

Here the portal and the ECMS are in two separate tiers and can be managed or maintained as such. This not only allows for better flexibility when scaling becomes necessary, it also allows the portal to expose Web scripts that are hosted in different geographic locations.

To make this possible I leveraged a custom authentication component that we wrote called STAr (Secure Token Authentication rivet) that could be plugged into an Alfresco authentication chain. With this in place the portlet can carry the user credentials from the portal to Alfresco, authenticate the user in Alfresco and retrieve a ticket that can be used during all subsequent interactions between the end-user, the portlet and ultimately the Alfresco Web script itself.

We recently released the first public version of AWPr under the GNU Affero General Public License.

The release includes two example Web scripts that, when installed and configured correctly in your portal (e.g. Liferay Portal), will look like this:

If you would like to know more about AWPr you can visit its wiki pages at the following location: http://wiki.rivetlogic.org/display/AWPr/Home