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.
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