Tag: CMIS

Django + Alfresco was a winning combination for retailer’s intranet

Last week I spent some time with one of our clients talking about what it’s been like to live with their Intranet platform based on Django and Alfresco. The conversation got me really excited about what they’ve been able to do since the original implementation and where they are heading.

The client is a well-known, high-end retailer based in Dallas. About a year ago they engaged Optaros to replatform their intranet from a legacy Java portal product to something more agile. They had seen Alfresco and liked it as a core repository, but needed something for the presentation tier (See “Alfresco User Interface: What are my options?“).

The Optaros team worked with the client to consider many options, including open source Java portal servers. The client felt like they needed something lighter and more flexible than a portal server. They were willing to do a lot of the presentation work themselves in exchange for complete design freedom and yet still be enough of a framework to be highly productive. The winning solution turned out to be Django.

Python? No problem.

I was initially worried that introducing a Python-based framework into a Java shop was going to be a problem but they weren’t married to Java. Our team got them up-to-speed quickly and they never looked back. It also helped that the client’s intranet sites were very communication-centric which matched up well with Django’s newspaper heritage.

Here’s how they use the solution in a nutshell:

  • Content owners use Alfresco Explorer to upload HTML chunks, office documents, and images, set metadata, and submit content for review. This triggers any number of rules that automatically process the changed content (e.g., creating thumbnails, extracting metadata, converting images to a consistent type, creating PDFs from office documents).
  • Content owners and reviewers can use Alfresco’s “custom views” to preview the content chunk in the context of the front-end site.
  • Site designers lay out site pages and create components using the Django template system, CSS, JQuery, and other front-end libraries.
  • Content publishers use the Django administration UI to map areas on the site to categories, folders, and objects in the Alfresco repository–Alfresco has no idea where or how the chunks are being used. This means the repository tier is truly decoupled from the presentation tier, allowing the client to reuse content across multiple areas of the site and across multiple sites within the enterprise.
  • Designers leverage a Django tag library to create dynamic areas of a page (e.g., when the page is rendered, retrieve all of the content chunks in this particular category from the repository). Django calls Alfresco web scripts to get and post data. The web scripts respond with serialized Django XML which Django caches and then deserializes into Django objects that the front-end can work with.

Separate concerns, play to strengths

The thing to notice about the Alfresco piece is how it sticks to core Alfresco capabilities: Metadata, rules, search, basic workflows, transformers/extractors, presentation templates, web scripts, DM repository. This is straight out of the Alfresco best practices playbook and aligns the client well with Alfresco product direction. A nice enhancement would be to refactor the Django-Alfresco integration to use CMIS which is something we are considering for the open source version of the integration (Screencast, Code).

Agile intranet, happy team

Since the initial rollout, the client has been able to make changes and roll out new sites quickly and easily thanks to the productivity inherent in the Django framework and the clean separation between the front-end app and the repository. Unexpected benefits the client mentioned were how fast they can add new features to the administrative UI (a core admin UI gets built for you automatically by Django) and the ease with which the development team can stand up a new environment.

The language the client team used to describe their work since the rollout summed it up best. They were using words like “beautiful” and “a real pleasure to work with”. When was the last time you heard those sentiments expressed about a WCM implementation?

Screencast: Drupal Open Atrium with Alfresco CMIS

UPDATE: Screencast now lives here:

I recorded a quick screencast of a simple integration we did to show Open Atrium leveraging Alfresco as a formal document repository via CMIS. This leverages the CMIS Alfresco module we developed and released on Drupal.org.

As I point out in the screencast, there’s not much to the integration from a technical standpoint. Open Atrium is Drupal and the CMIS module already has a CMIS repository browser. So, all we had to do was expose the module as a “feature”, which is something Open Atrium uses to bundle modules together that create a given chunk of functionality.

Readers familiar with Alfresco Share will instantly recognize the Open Atrium concepts. Instead of “sites” Atrium uses “groups”. Instead of “pages” or “tools”, Atrium uses “features”. The overall purpose, self-provisioned team-based collaboration, is the same and many of the tools/features are the same (blog, calendar, member directory). I’m not advocating using one over the other–as usual, what works best for you depends on a lot of factors. I just thought Atrium provided a nice way to show yet another example of Drupal and Alfresco together (post).

Drupal + Alfresco webinar slides available

People want intranets that are fun and easy to use, full of compelling content relevant to their job, and enabled with social and community features to help them discover connections with other teams, projects, and colleagues. IT wants something that’s lightweight and flexible enough to respond to the needs of the business that won’t cost a fortune.

That’s why Drupal + Alfresco is a great combination for things like intranets like the one Optaros built for Activision and why we had a record-breaking turnout for the Drupal + Alfresco webinar Chris Fuller and I did today. Thanks to everyone who came and asked good questions. I’ve posted the slides. Alfresco recorded the webinar so they’ll make it available soon, I’m sure. When that happens, I’ll update the post with a link. Until then, enjoy the slides.

[UPDATE: Fixed the slideshare link (thanks, David!) and added the links to the webinar recording below]

1. Streaming recording link:
https://alfresco.webex.com/alfresco/lsr.php?AT=pb&SP=TC&rID=42774837&act=pb&rKey=b44130d69cc9ec5f

2. Download recording link:
https://alfresco.webex.com/alfresco/ldr.php?AT=dw&SP=TC&rID=42774837&act=pf&rKey=c50049ac82e1220a

Apache Chemistry: A Proposed Reference CMIS Implementation

Kas Thomas, over at CMSWatch, says a new Apache project is in the works. Chemistry is a reference CMIS implementation that has committers from Day, Alfresco, and Nuxeo. The goal is to provide a vendor-neutral reference implementation and compatibility tests around the proposed CMIS specification.

It looks like this will be a standard set of REST APIs and SOAP services that implement the CMIS spec and hook into a back-end repository. Not surprisingly, the first back-end the Chemistry team plans to support is Apache Jackrabbit, Apache’s reference implementation of the JCR API.

Alfresco User Interface: What are my options?

People often need to build a custom user interface on top of the Alfresco repository and I see a lot of people asking general questions about how to do it. There are lots of options to consider. Here are four options for creating a user interface on top of Alfresco, at a high level:

Option 1: Use your favorite programming language and/or framework to talk to Alfresco via REST or Web Services. PHP? Python? Java? Flex? Whatever, it’s up to you. The REST API is nice because if you can’t find a URL that does what you need it to out-of-the-box, you can always roll-your-own with the web script framework. This option offers the most flexibility and creative freedom, but of course you might end up building constructs or components that you may have gotten “for free” from a higher-level framework. Optaros‘ streamlined web client, DoCASU, built on Ext-JS, is one freely-available example of a custom UI on top of Alfresco but there are others.

Option 2: Use Alfresco’s Surf framework. Alfresco’s Surf framework is just that–it’s a framework. Don’t confuse it with Alfresco Share which is a team-centric collaboration client built on top of Surf. And, don’t assume that just because a piece of functionality is in Share it is available to you in the lower-level Surf framework. You may have to do some extra work to get some of the cool stuff in Share to work in your pure Surf app. Also realize that Surf is brand new and still maturing. You’ll be quickly disappointed if you hold it to the same standard as a more widely-used, well-established framework like Seam or Django. Surf is a good option for quick, Alfresco-centric solutions, especially if you think you might want to leverage Alfresco’s browser-based site assembly tool, Web Studio, at some point in the future. (See Do-it-yourself Alfresco Surf Code Camp).

Option 3: Customize the Alfresco “Explorer” web client. There are varying degrees to which you can customize the web client. On one end of the spectrum you’ve got Freemarker “presentation templates” followed closely by XML configuration. On the other end of the spectrum you’ve got more elaborate enhancements you can make using JavaServer Faces (JSF). Customizing the Alfresco Explorer web client should only be considered if you can keep your enhancements to an absolute minimum because:

  1. Alfresco is moving away from JSF in favor of Surf-based clients. The Explorer client will continue to be around, but I wouldn’t expect major efforts to be focused on that client going forward.
  2. JSF-based customizations of the web client can be time-consuming and potentially complex, particularly if you are new to JSF.
  3. For most solutions, you’ll get more customer satisfaction bang out of your coding buck by building a purpose-built, eye-catching, UI designed with your specific use cases in mind than you will by starting with the general-purpose web client and extending from there.

Option 4: Use a portal, community, or WCM platform. This includes PHP-based projects like Drupal (Drupal CMIS Screencast) or Joomla as well as Java-based projects like Liferay and JBoss Portal. This is a good option if you have requirements that match up well with the built-in (or easily added-on) capabilities of those platforms.

It’s worth talking about Java portal servers specifically. I think people are struggling a bit to find The Best Way to integrate Alfresco with a portal. Of course there probably is no single approach that will fit every situation but I think Alfresco (with help from the community) could do more to provide best practices.

Here are the options you have when integrating with a portal:

Portal Option 1: Configure Alfresco to be the replacement JSR-170 repository for the portal. This option seems like more trouble than it is worth. If all you need is what you can get out of JSR-170, you might as well use the already-integrated Jackrabbit repository that most open source portals ship with these days unless you have good reasons not to. I’m open to having my mind changed on this one, but it seems like if you want to use Alfresco and a portal, you’ve got bigger plans that are probably going to require custom portlets anyway.

Portal Option 2: Run Alfresco and the portal in the same JVM (post). This is NOT recommended if you need to scale beyond a small departmental solution and, really, I think with the de-coupling of the web script engine we should consider this one deprecated at this point.

Portal Option 3: Run the Alfresco web script engine and the portal in the same JVM. Like the previous option, this gives you the ability to write web scripts that are wrapped in a portlet but it cuts down on the size of the web app significantly and it frees up your portal to scale independently of the Alfresco repository tier. It’s a fast development cycle once you get it set up. But I haven’t seen great instructions for setting it up yet. Alfresco should document this on their wiki if they are going to support this pattern.

Portal Option 4: Write your own portlets that make services calls. This is the “cleanest” approach because it treats Alfresco like any other back-end you might want to integrate with from the portal. You write custom portlets and have them talk to Alfresco via REST or SOAP. You’ll have to decide how you want to handle authentication with Alfresco.

What about CMIS?

CMIS fits under the “Option 1: Use your favorite programming language” and “Portal Option 4: Write your own portlets” categories. You can make CMIS calls to Alfresco using both REST and SOAP from your own custom code, portlet or otherwise. The nice thing about CMIS is that you can use it to abstract the underlying repository so that (in theory) your front-end code will work with different CMIS-compliant back-ends. Just realize that CMIS isn’t a fully-ratified standard yet and although a CMIS implementation is in the Enterprise version of Alfresco, it isn’t clear to me whether or not you’d be supported if you had a problem. (The last response I saw on this specific question was a Peter Monks tweet saying, “I don’t think so”).

The CMIS standard should be approved by the end-of-the-year and if Alfresco’s past performance is an indicator of the future, they’ll be the first to market with a production-ready, fully-supported CMIS implementation based on the final spec.

Pick your poison

Those are the options as I see them. Each one has trade-offs. Some may become more or less attractive over time as languages, frameworks, and the state of the art evolve. Ultimately, you’re going to have to evaluate which one fits your situation the best. You may have a hard time making a decision, but you have to admit that having to choose from several options is a nice problem to have.

Screencast: Alfresco-Drupal CMIS Integration Demo

UPDATE: Screencast now lives here:

I’ve created a new screencast that shows the Alfresco-Drupal CMIS integration in action over at Optaros Labs. The screencast shows content moving back-and-forth between Alfresco and Drupal, content being displayed in a Drupal site that lives in Alfresco, and a CMIS CQL query being executed against the Alfresco repository from Drupal.

The Drupal CMIS module and the CMIS Alfresco module are available at Drupal.org.

CMIS, ECM Interoperability, and Services-Oriented Content Management

The emerging Content Management Interoperability Services (CMIS) standard was the main buzz at the AIIM conference in Philadelphia this week (followed closely by social networking and Enterprise 2.0). Why does CMIS garner so much attention? Because as EMC’s David Choy said, “Unless they are starting from scratch, everybody implementing ECM has an interoperability problem.”

The impact of the problem depends on who you are and what you’re trying to do. If you use one ECM repository for email archiving and another to manage the content on your web site, it doesn’t really matter that the two repositories aren’t interoperable. But what if you have a portfolio of web sites and asset repositories across a variety of platforms and you need to share content across all of them? Then it’s a problem.

Customers in this situation have all kinds of issues they have to deal with, but several come down to a few basic needs having to do with interoperability:

  • It needs to be easy for front-ends to store and retrieve content across multiple repositories (different platforms)
  • It needs to be easy to move content between repositories
  • It needs to be easy to find interesting and relevant content (which I may then want to access from the front-end or send to some other repository)

This multi-site/multi-repository problem is common, and at Optaros, we think we can help address it with tools and services that are, in many cases, driven by CMIS.

Front-ends

I’ve met with clients who’ve invested a lot of time and effort in a custom front-end for Vignette, for example. Over time, they’ve added additional systems to manage assets but the front-end is forever tied to Vignette. Sure, they could introduce a services layer that abstracts the repository, but each time they add a new kind of repository, that’s more development they have to do. CMIS provides a standard way of interfacing with all CMIS-compliant repositories, so the amount of repository-specific coding you have to do is reduced.

At Optaros, we’re developing CMIS adapters or integrations and releasing them as open source so that popular front-ends can get to content more easily. (See Drupal CMIS). We think there’s probably also a case to be made for a CMIS-based “content bus” that front-ends and compliant repositories could plug into.

Replication

What if you want to move content between repositories? I’ve talked to folks who have Drupal web sites, but they’d like to take some of the user-generated content that comes from Drupal and treat it more formally–like maybe they want to route it through an internal workflow, tag it, and then make it available to some of the other sites in their portfolio that might or might not be Drupal. CMIS gives us a common way to export and import content (through ATOM XML). Throw a transformation in the middle to handle schema differences and you’ve got yourself a CMIS-based replication engine that can move content between different kinds of repositories.

We’ve built a basic synchronization between Alfresco and Drupal as part of the Drupal CMIS and Alfresco modules, but we think this kind of functionality should be separated out and treated more generically–like a replication server that could sit between any number of CMIS-compliant endpoints.

Feeds & Search

How do you know when new content you might be interested in shows up in one of the numerous repositories you have in your environment? One answer is search. Initially, I was thinking a federated search server based on OpenSearch would be worthwhile but I think at this point, most people are just indexing everything rather than taking a federated approach.

Search is good when you are actively looking for specific content, but people (and systems) need to find content they are interested in as it becomes available. CMIS returns data as ATOM XML. That means you can use the same RSS/ATOM feed aggregation tools and techniques you use to track news to track content updates. This isn’t new–you’ve always been able to bolt on RSS feeds to your content repository by using the repository’s API to query for content and return it formatted as a feed, but CMIS gives us this “for free”.

So as CMIS becomes more widely adopted, we may see a big increase in the amount of ATOM/RSS flowing through the Enterprise as people begin to use feeds to discover new content. An Enterprise RSS server would seem like a good tool to leverage to aggregate the feeds coming from various content repositories across the content domain. It could also be used for other non-CMIS related feeds which will also surely increase as Enterprise 2.0 adoption spreads.

Most of the feed aggregation functionality available today is embedded within broader platforms (RSS portlets, for example). At Optaros, we think that, like replication, feed aggregation should be split out into a dedicated service. Think “Google Reader for the Enterprise”, essentially. There are proprietary systems out that that do this but no open source alternatives that are more than just personal feed aggregators (at least that I could find) so we may have to develop this.

Services-Oriented Content Management

These individual services–CMIS adapters, Replication, and Feeds–are part of a Services-Oriented approach to Content Management. The services are interrelated, and there are others I haven’t discussed, but the idea is that this type of approach can make a multi-silo’d content domain much more manageable and useful. Some of it depends on CMIS and some of it doesn’t. These ideas are still being hammered out so if you have interest in any of it, please let me know.

It’ll be interesting to see what happens as CMIS moves through additional iterations and ultimately becomes ratified hopefully by the end of the year.

For more info, see:

Webinar: Developer’s Intro to Alfresco Part 3: Web Scripts & Surf

Part 3 of the “Developer’s Introduction to Alfresco” webinars is today at 12 Eastern (GMT – 5). I’ll be talking about web scripts, Surf, and CMIS. The format will be the same as the first two parts: you’ll watch a pre-recorded presentation for about 30 minutes, then I’ll do at least a 30 minute live Q&A session.

Also, I know I’ve been slow in getting this posted, but the Part Two presentation and Q&A recordings are available at Alfresco’s on-demand events page.

Alfresco-Drupal integration through CMIS

As I’ve mentioned here and on twitter, we posted our Alfresco-Drupal integration on Drupal.org on Friday. I did a short write-up on it over at Optaros.com that gives the why and the what so I’ll not repeat it here.

We split the integration into two modules: CMIS API has nothing Alfresco-specific–it just knows how to make RESTful CMIS calls to an arbitrary CMIS repository. The Alfresco CMIS module has the Alfresco-specific logic. You need both to make the integration work. If you’ve got Alfresco 3 (Enterprise or Labs) you don’t need to do anything to your Alfresco install to enable the integration because it’s already CMIS compliant.

There is still a lot of work to do on this integration. For example, right now we’re only moving plain text content back-and-forth between Drupal and Alfresco. And we use a “single account” approach so that to Alfresco, every request appears to come from one user instead of passing through the authenticated Drupal credentials. But this is an imporant integration to us so I expect it to evolve substantially in the coming months.

I got good feedback on the recent screencasts I put together for Share (Part 1, Part 2) so if I get some time this week I’ll do one that gives a quick tour of the Drupal integration.