Month: October 2012

“Content Enabling” your 3rd party Applications with Crafter Rivet

Posted by on October 29, 2012

This article covers the various ways you can integrate your 3rd party applications with content managed and deployed by Crafter Studio and Alfresco.

Before we dig in to the specific approaches let’s take a quick look at the high level architecture of Crafter Rivet.

The architecture for Crafter Rivet is decoupled.  This means that by design your authoring and delivery infrastructures are separate infrastructure.  With Crafter Rivet authors work in a safe environment equipped with the tools they need to create and manage content.  When content has been approved via workflow it is then and only then published to entirely separate production environment where your live audience can access it.

We have put this architecture in place for several reasons:

  • Authoring and delivery systems serve different purposes and audiences and thus they have different SLAs, security, performance requirements and so on.
  • By decoupling the delivery environment we allow an implementation to use the authoring (Crafter Studio) and delivery (Crafter Engine) components independent of one another.  We have seen several cases where only Studio or Engine was used to meet specific need.
  • By decoupling the delivery environment we natively enable multi-channel publishing.

As a direct result of its architecture, Crafter Rivet, through its authoring component known as Crafter Studio can be used not only to manage content served directly by a Crafter Engine environment but also to 3rd party systems.

Now that we have architectural context, let’s take a look at a number of approaches for content enabling your 3rd party applications using Crafter Rivet.

Content Enable Your Existing Application via Crafter Core

At the heart of Crafter Engine is a Spring MVC application integrated with a middle-ware library we call Crafter Core.  Crafter Core is the main integration between the delivery tier and Alfresco. The Crafter Core library provides services that understand how to consume content (xml) and assets published Crafter Studio and Alfresco and to make them available to your application through a service oriented architecture.

To illustrate this architecture consider the diagram on the right which demonstrates this model though the architecture of Crafter Engine.

While Crafter Engine is constructed with Spring MVC and a Freemarker based presentation tier, Rivet Logic has previously content integrated many platforms including:

  • JBoss Seam & JSF Facelets / Spring Bean Framework
  • JSP / Pojo / Spring Bean Framework
  • JRuby / Spring Bean Framework
  • Quercus PHP / Spring Bean Framework
  • Grails / Spring Bean Framework

All that is required for integration is that you include the Crafter Core library, properly instantiate the content services and then tie the services to the view layer either directly or through your controller layer.  If you choose to use Spring Bean factory with in your application, instantiation is all but taken care of for you by existing Spring context files which are packaged with-in the jar.  You can find the binaries for the jar as well as Maven package details here.

This type of integration is typically done for existing applications which require deep integration with content and where there is a need to have exact control of the placement and presentation of the content across the entire application.

Content Enable your application via Crafter Engine’s ReST APIs

Crafter Engine provides access to content, metadata and structure through a ReSTful API.  You can find documentation for this API here.

As we can see from the diagram above the architecture uses Crafter Engine to provide the content services for content deployed from Alfresco which is then surfaced with in the 3rd party application via ReSTful API.  The 3rd party application may consume the ReSTful services on either the client layer (via JavaScript) or from with in the application.

This architecture is usually see when lightweight development is required and/or when it is adventitious to create a solution which can be integrated on one or more sites via the same code base.

When To Serve Content Directly From Alfresco

There is no hard and fast rule about when to serve your content to your application or website directly from Alfresco and when you should not.  Because Alfresco is an enterprise class content platform we typically find that it is the system of record for many different types of content including web, documents, records and so on.  For this reason we also find Alfresco is typically found behind one or more firewalls when the installation is on-premise.

When your site serves content from Alfresco directly you create a dependency on Alfresco in doing so you link the SLA (Service Level Agreements) of both your site/application and Alfresco.  This approach may have an impact to your IT requirements and infrastructure, licensing, and security. The decision to undertake this approach needs to be made deliberately with these factors in mind.

The main use case we see for applications and in particular applications pulling content from Alfresco directly centers around document management like use cases typically with-in an intranet.  When surfacing documents and interacting with workflow it is natural to link directly to the repository.

If you do decide to content enable your application this way there are several mechanisms for interacting with the repository:

  • Via custom web scripts: Using Alfresco’s web script facility is it possible to construct extremely lightweight, purpose built services for your 3rd party application.
  • CMIS (Content Management Interoperability Standard): Alfresco has extensive support for CMIS standards based ReSTful interface.
  • RAAr (Remote Alfresco API rivet): RAAr is a remote interface that provides your Java based applications with the exact same interfaces Alfresco provides for in-process integration.  You can learn more and download RAAr here.
  • File System projection: For simple integration you can read and write to and from Alfresco as if it were a standard file system.  Out of the box Alfresco supports the following file system projections:  CIFS / Shared Drive, FTP, WebDAV

Extending Crafter Engine with Java backed functionality

Posted by on October 06, 2012

Crafter Engine is the high-performance website / web app delivery engine for Crafter Rivet Web Experience Management. Out of the box Crafter Engine ships with support for many of the types of engaging functionality you have come to expect from a WCM/WEM platform.  However, there are times when we want to add additional capabilities to integrate with internal and 3rd party systems to meet specific business objectives.  In this article we’ll demonstrate how you can create Java backed plug-ins for Crafter Engine.

To illustrate the integration process we’ll integrate a simple RSS reader based on the ROME RSS processing library
You can download this example (and others) at the following SVN location:

To begin let’s start with some background on Crafter Rivet, Crafter Engine and how a plug-in is organized structurally:

Crafter Rivet

Crafter Rivet is web experience management solution based on the Alfresco Content Management platform with a de-coupled architecture.  This means that the authoring environment and the production delivery environment are separate infrastructure integrated by workflow and deployment from authoring to delivery.  Crafter Rivet components power some of the internet’s largest websites.  A decouple architecture makes things easier to support, more flexible and very scalable.

Crafter Engine

Crafter Engine owes its performance characteristics to its simplicity.  Content is stored on disk and is served from memory.  Dynamic support is backed by Apache Solr. At the heart of Crafter Engine is Spring MVC, a simple, high performance application framework based on one of the world’s most popular technologies: Spring framework.

What is a Crafter Engine Plug-in

A Crafter Plug-in is a mechanism for extending the core capabilities of Crafter Engine, the delivery component of Crafter Rivet. Plug-ins allow you to add additional services and make them available to your template / presentation layer.

An example plug-in as we suggested above might be an XML reader which would function as specified below:

  • The plugin would expose a in-process Java based service like Feed RssReaderService.getFeed(String url)
  • Your your presentation templates would then simply call <#assign feedItems = RssReaderService.getFeed(“”) />

Anatomy of a Crafter Engine Plug-in

You will note from the diagram above that plug-ins are simple JAR files that contain both Java code, configuration and an Spring bean factory XML file that loads and registers the services with Crafter Engine.

Loading the plug-in

1. When the container loads the Crafter Engine WAR the shared classes lib folder is included in the class path.

2. When the Crafter Engine WAR starts up it will scan the class path for its own spring files and any available plug-ins. At this time the services described in the Spring bean XML file with in your plug-in will be loaded. Your service interfaces are now available in the presentation layer.

Interacting with your service

A. The user makes a request for a given URL

B. Crafter Engine will load all of the content descriptors from disk for the page and components needed to render the specific URL. Once the descriptors are loaded the templates for the page and components will loaded from disk.

C. The templates may now call your service interfaces to render from and interact with your back-end code. Your Java backed service may then do whatever it was intended to do, returning the results to the template for processing. Once complete, the responses are then returned to the user in the form of a rendered web page.

A simple Example

Now that we have a bit of background, let’s get down to the nuts and bolts of the matter and build, install and configure our RSS reader integration.

The Java Service

 * Reads a RSS or Atom feed from a specified URL and returns a data structure that can be accessed from a template.
public class RssReaderService {

    public SyndFeed getFeed(String url) throws IOException, FeedException {
        SyndFeedInput input = new SyndFeedInput();
        XmlReader reader = new XmlReader(new URL(url));

        try {
        } finally {
            try {
            } catch (IOException err) {
                // handle error

The Configuration


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""

    <bean id="rssReaderService" class="org.rivetlogic.crafter.engine.rss.RssReaderService" />

Packaging and Install

The compiled class and spring configuration file must be found in the class path.  To facilitate this we build these objects and their dependencies in to a single JAR file.  You can find the build process for these at the SVN location above.  Place the JAR file that is produced by the build process in to your shared class path for example: /TOMCAT-HOME/shared/lib and restart the application.

Now that you have restarted the application your service is available to your presentation layer.  This means that in any template you can now add the following:

<#assign feedItems = RssReaderService.getFeed(“”) />

Using the Plug-in:

Web Ninja: Create a RSS Feed Component for Authors

Create a new content type as a component:

Create a template for the RSS Widget by clicking on the type canvas and editing the template property:

Author: create and configure a RSS Component

Modify the component properties through the content type form:

And insert the widget in to a web page:

Save and close and the configured component is now showing on your web page!