Category: Uncategorized

Web CMS and Digital Assets: Crafter Rivet / Alfresco Integration with Adobe Photoshop

Posted by on February 21, 2013

Digital assets are a key component of almost all web experience and customer engagement projects. In today’s era of engagement with all of the additional content targeting, personalization, internationalization and multi-channel publishing the number and permutation of digital assets associated with any given project are growing rapidly.  This trend will only continue as we move forward.  Content workers (authors, designers, content mangers) need to be able to create, locate, modify and manage the growing number of assets easily and efficiently in order to maintain brand quality and deliver projects on time and on budget.

In today’s blog entry we’re going to focus on the creative side of WCM (Web Content Management) and DAM (Digital Asset Management) even though this is only a small portion of the overall set of use cases.

Let’s begin by considering the following example use cases:

  • Create mobile appropriate image resolution variants
  • Create video stills
  • Imprint watermarks
  • Thumbnails for galleries and promotional kickers

Each of these use cases are important ingredients in providing the user with a great experience but they also introduce a lot of additional work for our content teams.  One of the ways to deal with the large volume of asset creation and manipulation responsibilities is to automate them.   The use cases mentioned above and many others like them are a perfect candidate for automation.

Crafter Rivet leverages Alfresco’s enterprise content management services for image transformation. With a few simple rules applied at the repository level it’s possible to provide your content team with image resolution variants, video stills, apply watermarks, to scale and crop thumbnails and then to make these assets available for review by our authors all in an automated fashion with no additional labor required beyond uploading the canonical assets.

Another important way to help our content teams cope with the sheer volume of digital asset related workload is to make sure our teams are able to work with the very best tools at their disposal.  With today’s modern browsers it is possible to provide a fairly decent set of tools / asset manipulation functionality right with-in the browser.  However, while purely web-based tools have their advantages they are often slower and much less powerful than the desktop tools serious content contributors are used to working with.

The biggest productivity boosts are gained when we empower our designers and other content workers on our team with rich, native tools that they are already familiar with and work  with on a daily basis.

Adobe’s creative suite (which contains tools like PhotoShop) is the quintessential software package for image/digital asset creation and manipulation.  Designers are deeply familiar with these tools and are able to leverage their enormous arsenal of capability to accomplish a tremendous amount of work in a short amount of time.  The issue that many organizations often face, is that while the tools themselves are great, the interfaces between the tools and the systems that ultimately store, manage and deliver the assets are either non-existent, human-process based, or have clunky integration. This gap creates a drag on the margin of productivity and introduces room for error.

Fortunately Alfresco, Adobe and Crafter Rivet Web Experience Management have a solution that connects rich, creative desktop tools,  to your systems of record (e.g. repository) and ultimately to your systems of engagement (e.g. website) in a seamless fashion.  Content creators work right with-in the rich, local tools that they are familiar and productive with and those tools are deeply integrated with the repository which means that all of the organization, policies, metadata extraction, and versioning provided by the repository etc are seamlessly integrated and enforced.  Alfresco is a CMIS (Content Management Interoperability Standard) compliant repository.  This standards based interface enables it to communicate with external applications like Adobe’s products in order to interact with and operate on the content, metadata, permissions, versions and so on housed within the repository.   Adobe provides a platform called Adobe Drive which enables its tools to connect in a rich fashion over CMIS to Alfresco.  Once we’ve connected our Adobe tools and our Alfresco repository authors working within Crafter Studio, the authoring and management component of Crafter Rivet can now see content updates coming from the Adobe tools right in context with the work they are doing through in context preview and editing. They can also interact with that content through the web based tools, workflow, versioning, metadata capture and publishing capabilities of Crafter Studio.

By closing the integration gap we can now provide powerful tools for productivity and at the same time do so in a way that makes it seamless and easy for our creative teams to collaborate across the entire process.

Click on the video below to see Adobe and Crafter Rivet WEM / Alfresco in action together!

Video of Photoshop altering images in Crafter Rivet Web CMS and Alfresco

 

Crafter Rivet is a 100% open source, java based web CMS for web experience management and customer engagement.  Learn more about Crafter Rivet at crafterrivet.org

Web CMS Content Enrichment with OpenCalais, Crafter Rivet and Alfresco

Posted by on February 15, 2013

Content enrichment is the process of mining content in order to add additional value to it.  A few examples of content enrichment include: entity extraction, topic detection, SEO (Search Engine Optimization,) and sentiment analysis.  Entity extraction is the process of identifying unique entities like people and places and tagging the content with it.  Topic detection looks at the content and determines to some probabilistic measure what the content is about.  SEO enrichment will look at the content and suggest edits and keywords that will boost the content’s search engine performance. Sentiment analysis can determine the tone or polarity (negative or positive) of the content.

Content enrichment provides an enormous opportunity to improve the effectiveness of your content.  However, it is clear that detailed analysis and the work of adding additional markup and metadata to content can be extremely time consuming for authors and content managers.  Fortunately there are many free and commercial services available that can be used to enrich your content while saving countless hours for authors and content managers.

One such service is OpenCalais from Thompson Reuters.  Open Calais is a toolkit of capabilities that includes state-of-the-art semantic data mining of content via restful services.

In the video below you’ll find a short demonstration of how OpenCalais can quickly be integrated with Crafter Rivet’s authoring platform (Crafter Studio) to make it extremely fast and easy for authors to enrich articles and other types of content with rich, structured metadata.

Coupled vs Decoupled Web CMS Architecture

Posted by on February 10, 2013

Generally speaking there are two main types of Web CMS architectures: coupled and decoupled.  Coupling refers to the relationship between the authoring tools and content delivery of your live site.

The classic example of a coupled CMS architecture is a blog engine. In a coupled system, the underlying store for your content serves both authoring and delivery.  Your authoring capabilities are part of the live delivery system but are available only to those who have permissions.  In a coupled system, the process of making content live is typically a matter of setting a flag in the database.

Coupled CMS Architecture

A decoupled system by contrast is one that puts authoring and delivery in separate applications, and potentially, on separate infrastructure. In a decoupled system, the process of making content live is done through a publishing mechanism where content is pushed from the authoring platform (and underlying content repository) to a content delivery infrastructure.

Decoupled CMS Architecture

So which approach is the right architecture? The reality here there is no single right or wrong answer.  The answer depends on context: alignment with your requirements, your business process and your business goals.  The topic of coupled vs. decoupled is not a new one.  It’s a debate that has been going on for a long time and will continue to go on so long as there continues to be Web CMS platforms, “fan boys” and a perception that one size fits all.  The more appropriate way to approach the question is to analyze the strengths and weaknesses of each approach and then to consider these in the context your own specific use cases.  We’ll see that in different scenarios we come to different conclusions on which architecture to use.

Coupled Architecture

Let’s take a look at the strengths and weaknesses for a coupled CMS architecture.

Strengths

  • Easy to set up and deploy a single instance.
  • Authoring and delivery are on the same infrastructure which can make it easier to build cohesive authoring tools.
  • Relatively easy administration of production system for single sites

Weaknesses

  • SLAs (Service Level Agreements) are coupled — meaning that authoring has to be just as available as the live site.
  • Coupled infrastructures are generally more complex to scale, as they typically depend heavily on database scalability.
  • Content is typically captured in a database schema meant for delivery on the site.  This can make integration and migration difficult.
  • Software complexity is higher because the code base contains both authoring and delivery concerns.  All but the most trivial CMS projects involve some development, and thus becomes an development issue.
  • Pushing content in and out of the CMS to and from third parties takes place in the same system that runs your live site.  Integration is not native to the architecture and it may impact the system’s performance.

Decoupled Architecture

Let’s take a look at the strengths and weaknesses of a decoupled CMS architecture.

Strengths

  • Easier to scale for high traffic websites, and to handle multi-site management.
  • SLAs are decoupled.  Authoring can be down for upgrades without impacting delivery. The reverse is also true.
  • Scale only the components that you need.  If you are not adding more authors then there is no need to scale out authoring.  This affects the complexity of the solution and also license costs where they are involved.
  • Code complexity is isolated within each of the two components (authoring and delivery).  Each piece can be as simple or complex as is needed without impacting the other.
  • Integration is a built in concept, as content is natively published to a the remote delivery system, it is generally straightforward to push to other systems as well. Also note, integration takes place on the authoring tier safely away from the live site protecting stability and performance.
  • Content migration and sharing with other systems is generally much more innate to the architecture.
  • Multi-channel support by nature, as publishing to mobile apps, social channels, and other digital channels is a natural extension of the native publishing capability.
  • Content sharing and syndication are more naturally supported.
  • When complexity is isolated and scaling is simple, it’s easier to develop and deploy rich features to your users.

Weaknesses

  • Setup has more components and can be more complex.
  • Publishing introduces additional points of failure.
  • Sub-division of components can go too far driving up complexity and driving down the cohesion of the user experience.

Making a Choice

It’s clear that each approach has its own strengths and weaknesses.  A coupled approach may work really well in once scenario while a decoupled approach may be much more appropriate in another.

Our analysis reveals that a coupled architecture can work well for websites that need to be set up and put on line in short order and that do not need to be able to scale quickly or to publish content beyond the website itself.  On the other hand, we see that a decoupled architecture is ideal for websites that require high levels of availability and performance, need a lot of tailored functionality, must be integrated with third party business systems and must publish to one or more digital channels beyond the website itself.

Build Engaging Web Pages with Crafter Rivet and Alfresco

Posted by on January 31, 2013

Today’s internet is a noisy.  Our customers are bombarded with content and messaging from all angles.  As a result they learn to filter our anything that is not directly and immediately useful to them.  Thus there is ever growing importance for our websites and services to be up to date with fresh content and on top of that for that content to speak as directly as is possible to any given user.

In this article we’ll explore a number of ways to leverage the Crafter Rivet WEM platform to create a dynamic website that can quickly and effortlessly to keep your content fresh and timely.  We’ll go beyond the basics to show how you can support complex requirements and content production processes and finally we’ll demonstrate how to target your content directly to the visitors on your site.

Author Selected Content

In many cases our authors want to make a specific editorial choice about what content to display on their site. For example, they may want to decide which promotions to show on the home page.

 

To begin let’s keep things simple and start with a use case that has a very basic set of requirements:

  • Authors manage a collection of promotional objects which can be assigned to the home page for display in a carrousel.
  • Authors make a daily decision about which objects to show on the home page from the collection or gallery of objects from within the CMS.
  • All site visitors see the same promotional objects.

To allow authors to hand pick content to be associated with a page, region, or component in Crafter Rivet we must create a content association between the target content and the object that will point to them.  In the case of our example above there is a parent child association between the home page and the promotions.

parent child 1 to many content association

To create this association we use the Content Type Editor in Crafter Studio, which is the authoring environment for Crafter Rivet.

First we create the promotion type.  You can see an example of the fields in the image below.

Next we update our home page type and add a item selector type field and child content data source.

Once we’ve updated our models you can create and link promotion objects to your home page by editing the home page.

Finally we edit our home page template to include code that will walk the list of the associated child content (the promotion objects) and render them.

<#assign promos = model.promos.item />
<#list promos as promo>
 <#assign promoItem = siteItemService.getSiteItem(promo.key) />
 <div>
 <img src="${promoItem.image!''}" />
 <div>
 <h1>${promoItem.headline!""}</h1>
 <p>${promoItem.subhead!""}</p>
 </div>
 </div>
 </#list>

Looking at the code above we see that what we’re doing is getting the key values for the promotional content associated with the home page and the looping over them.  For each item we load the actual content from the SiteItemService and then use the item to build out our markup.

Query Driven Content

Our example of promotional objects on the home page is very simple.  It assumes that every user will get the same content and also that authors will not want to stage more than a single scenario at a time.  This of course may work well for some organizations but it’s far too simplistic for others. Now that we’ve covered the basic mechanics of author managed content associations let’s imagine a use case with much more complex requirements:

  • Our authors need to create different variations of the home page that correspond to marketing campaigns which will take place throughout the year.
  • Editors choose the content that goes with each campaign.
  • A campaign may include a new offering and potentially other associated content that must go out at the same time.
  • Campaign content production doesn’t necessarily happen in sequence.  Each campaign is developed by a different team and may be more or less complex which in turn means campaigns may complete production at vastly different times.  Occasionally a content production will complete right before the campaign starts.
  • Once a campaign is ready it needs to be approved and scheduled for a deployment.  The team assigned to that campaign will move on to the next one.
  • When a campaign is over it needs to stop showing up on the home page

For a set of requirements like the ones we see above we’re going to rely on a number of features on both in both authoring and delivery.

First we need a content model that is going to support our use case.  We need a campaign that can be created independently. The campaign will point to promotional content, products and other relevant content.  Our content model might look something like the following:

We can imagine a campaign might have the following properties

  • A campaign code that matches a code tracked in our CRM system
  • A effective date that indicates when it allowed to begin operating on the site
  • A expiration date that indicates when it must end its operation
  • A disabled flag that would allow it to be shut down even if it is active
  • Associations to all of the content that are related to the campaign.  These content items will be selected by the author exactly as described in our earlier use case.

Next we need to update the home page template to use a campaign. Because a new campaign may come along at any time we will use a query to determine which campaign to show.  At a minimum our query will look at

  • All objects of type campaign
  • That are equal to or beyond the effective date
  • That are not beyond the expiration date
  • That are not disabled.

The template code would look something like the following:

<#assign queryStatement = "content-type:/component/campaign " />
<#assign queryStatement = queryStatement + "AND effective_dt:[TODAY TO *] " />
<#assign queryStatement = queryStatement + "AND expiration_dt:[* TO TODAY] " />
<#assign queryStatement = queryStatement + "AND disabled_b:false " />
<#assign query = searchService.createQuery() />
<#assign query = query.setQuery(queryStatement) />
<#assign query = query.setRows(1) />

<#assign campaign = searchService.search(query).response.documents[1] />

<#list campaign.promos as promo>
 <#assign promoItem = siteItemService.getSiteItem(promo.localId) />
 <div>
 <img src="${promoItem.image!''}" />
 <div>
 <h1>${promoItem.headline!""}</h1>
 <p>${promoItem.subhead!""}</p>
 </div>
 </div>
 </#list>

In the code above we can see above that we are creating a query statement, limiting our results to a single record and then executing the query.  You may recognize that the code after the query which processes the results and shows the promotional content associated to the campaign remains nearly identical to the code in our last example.

Now that we have our mechanics set up teams can begin creating content.  Once campaigns are complete they can be queued up for approval and deployment.  Because a campaign may require product updates that cannot be shown on the site before the start date content managers may leverage scheduled publishing.  Scheduled publishing allows the editorial team to approve content for publish but to delay the deployment of the content until a specific date and time.  Finally, editors can be sure all related updates from associated images to associated products will be deployed because Crafter Studio will seamlessly calculate and deploy the campaign’s dependencies.

Targeted Content

Targeting content is all about getting the right content to the right audience at the right time.  From our last example we’ve seen how facilitate a complex production process and more importantly for this topic how to add metadata to content objects and then how to use that metadata to dynamically determine which content to show on our site.  In essence we’ve covered the “right content at the right time” part of targeting. Now we want to extend our discretion to a specific audiences.  Let’s extend our use case from above with a few additional requirements.

  • All requirements from the previous section hold.
  • Authors may create one or more campaigns that are eligible to be active on the site at any given time
  • Campaigns may be specific to different audiences.  In other words content may be targeted at that audience.  For example: All users,  users of a specific gender.
  • Campaigns that match more specific criteria for a site user (are more targeted) should be preferred for use over less relevant content.

At this point all of our production mechanics will remain the same.  Addressing the new requirements will require the following additional steps:

  • We’ll  add criteria to our campaign definition and then update the content with the appropriate values.
  • We’ll add additional user specific criteria to our query.
  • We’ll provide the capability for our authors to review how well the targeting rules work through Crafter Studio.

Let’s begin by updating our content model for campaign.

  • We’ll add a new targeting section to our form definition for campaign called “Targeting”
  • To our new section we’ll add a grouped check box for Gender and a data source linked to the values: Female, Male, and All

Next we’ll update our existing campaigns with the appropriate targeting data.  Perhaps we mark all existing items with the All value for the gender field.

Now we can turn our attention to the template and our query.  We know we’re going to target some content specifically to women, some to men and some to everyone regardless of gender.  Let’s take a look at the code:

<#assign gender = profile["gender"]!"ALL" />

<#assign queryStatement = "content-type:/component/campaign " />
<#assign queryStatement = queryStatement + "AND effective_dt:[TODAY TO *] " />
<#assign queryStatement = queryStatement + "AND expiration_dt:[* TO TODAY] " />
<#assign queryStatement = queryStatement + "AND disabled_b:false " />
<#assign queryStatement = queryStatement + "AND (gender:\"" + gender + "\"^10 OR gender:\"ALL\") />
<#assign query = searchService.createQuery() />
<#assign query = query.setQuery(queryStatement) />
<#assign query = query.setRows(1) />

<#assign campaign = searchService.search(query).response.documents[1] />

<#list campaign.promos as promo>
 <#assign promoItem = siteItemService.getSiteItem(promo.localId) />
 <div>
 <img src="${promoItem.image!''}" />
 <div>
 <h1>${promoItem.headline!""}</h1>
 <p>${promoItem.subhead!""}</p>
 </div>
 </div>
 </#list>

In the code above we see two new lines of interest.  The first is <#assign gender = profile["gender"]!”ALL” />  This code gets the value for the property gender from the current profile and puts it in to a variable.

The second is line of interest is <#assign queryStatement = queryStatement + “AND (gender:\”" + gender + “\”^10 OR gender:\”ALL\”) />  In this line we see we’re constraining our query by the gender coming from the profile OR  records that have ALL selected.  The key here is that we have ^10 on match for the profile’s gender.  This ensures that any records which match that aspect of the query will be given a higher relevance and thus chosen for display.

As you can see it is quite simple to create solutions for driving dynamic content targeted at specific attributes in a visitor’s profile.

However, as we discussed previously, the other half of the issue is enabling the author to test.  The reality today is that content authors are creating content for different devices, market segments and all sorts of other facets.  With such a dynamic environment they need tools that will help them review and test their work.

Crafter Studio provides targeting tools for authors to address this issue.  The authoring environment can be configured with any number of predefined persona(s). A persona is like a profile, in fact it behaves exactly the same way but instead of setting up and signing in as specific users to test different scenarios authors can simply switch back and forth between the available configured persona(s).   Each persona has a name, image and a description to help authors identify the scenarios they represent.  Authors can also change the property values of a given persona once they have assumed it.

 

Managing Component-based Websites with Alfresco

Posted by on November 04, 2012

From time to time at Rivet Logic we get questions concerning Alfresco‘s ability to build and manage component-based websites due to its file / folder based organization. In many cases this question arises from either a limited look at Alfresco’s features (sometimes sourced from industry analyst reports that lack depth) or a far too simplistic understanding of Alfresco’s core capabilities and established best practices for web content management and dynamic content delivery.

Through this short article I will demonstrate the following:

  • Repository organization has no bearing on website placement of components
  • Primary organization in a file / folder structure is a strength and offers technical capability that differentiates Alfresco from lesser Web CMS platforms.

Decoupled CMS ArchitectureThis article will approach this question with the capabilities of Crafter Rivet, a 100% open source web content and experience management solution built as a plug in for Alfresco.  Crafter Rivet consists of two major subsystems:  1) Crafter Studio, an authoring environment built on top of Alfresco’s content repository and 2) Crafter Engine, a high performance content delivery platform which relies on Apache Solr for dynamic content queries. Crafter Rivet and Alfresco enable a de-coupled content management architecture: Crafter Studio and Alfresco for content authoring, management and workflow, and Crafter Engine for high performance dynamic content delivery.  Content is published from Alfresco to the de-coupled Crafter Engine delivery stack, which is where the website application(s) runs. Once deployed to Crafter Engine, content updates are immediately available and are reflected in a high performance, queryable Apache Solr index to support dynamic content delivery.  Moreover, all content is cached in memory for very low response times.

With this understanding of how the separation of content management from content delivery work in a de-coupled Web CMS platform such as Alfresco, we can now discuss how the content organization within the Alfresco repository facilitates component-based site development. We refer to content organization within the repository as the “primary organization” of the content.  Crafter Rivet allows authors to build component-based websites, and place content components anywhere on the site regardless of the primary organization found inside the Alfresco repository.  Components may be placed in a region of a page explicitly through drag-and-drop construction, or they may be surfaced through a dynamic query.

Explicit placement simply links the content to a page through an ID-based association, completely independent of the underlying file/folder structure. Query-driven content placement leverages a Solr-based index and returns a list of component IDs (and other attributes) based on the given criteria. And in both cases, the primary organization of the content plays no role in the ability for the content to be used in any region of any page of the website.

Primary Content OrganizationWithin the repository and authoring life cycle, primary organization is an extremely useful paradigm.  Authors need to be able to find content quickly.  By putting every content item in a structured location (i.e., folder) it is much easier to find when browsing. Contrast this with the opaque database/data structure approach taken by many other platforms which offer no direct access or ability to browse for content.  In general, we have found it best to remove abstraction as much as possible when modeling content. For site pages, as an example, we model these as files and folders that match the URL. Crafter Engine understands that specifically for pages, the URL and this structure are related.  A change in to the folder structure also changes the URL.  This is extremely helpful to authors as it maps directly to their expectation when thinking about page hierarchy in their information architecture.

Components, on the other hand, tend to be grouped by type or some other such criteria. Authors may create arbitrary folder structure to house components, forming a primary organization that enables them to quickly find and work with content. This primary organization has nothing to do with how, when or where the content will be rendered on the site. Further, Alfresco allows content managers to attach rules, policies and permissions to folders inside the repository.  This is an extremely useful and powerful capability not found in may other Web CMS systems. By leveraging the primary organization of pages and components, content managers can enact specific rules for content transformation, metadata extraction, validation, workflow, and much more throughout the authoring life cycle.

 

As you begin to work with Alfresco for web content management you want to keep in mind that the organization of your content inside the repository and the delivery of that content are two very different things.  Alfresco as a content repository is generally de-coupled from the delivery mechanism as we have seen with Crafter Rivet.  Take advantage of the fact that Alfresco’s file / folder structure has many organizational and technical benefits during the authoring life cycle and has no bearing on the delivery of that content when deployed to a dynamic content delivery engine like Crafter Engine.

“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

Best Practices in Social Business Solutions

Posted by on June 12, 2012

The term “Social Business” has been generating a lot of buzz lately, and many enterprises have set the gears in motion to achieve this. However, just like many other IT initiatives, it’s important to first understand what a social business really means, the drivers behind it, how your organization can stand to benefit, and the strategies behind a successful implementation.

KMWorld‘s June Best Practices White Paper focuses on the topic of Social Business Solutions, with a collection of articles around successful ways of achieving a social business. Rivet Logic participated in this white paper with an article on open and agile social business solutions, and discusses topics including business drivers, what it means to be a social business, social business value creation, and how to open source can help achieve the goal.

The full white paper is available for download on our website, http://rivetlogic.com/resources/information-center.

Resources for Crafter Rivet – Web CMS for Alfresco 4

Posted by on April 16, 2012

Last week was a busy week for those of us working on Crafter Rivet, the WEM/WCM extension for Alfresco 4.0.  We’re extremely excited about this release and are busy scheduling events and demos as word is starting to get out!

You can download Crafter Rivet here:

If you missed our Webinar last week that was co-hosted with Alfresco you can check it out here:
http://www2.alfresco.com/Crafter0412

For existing Alfresco WCM customers on Alfresco version 2 and 3 using the AVM based solution, we’ve put together a couple of blogs to help you think about your migration to Alfresco 4 and the core repository:

For everyone who wants to learn more about this exciting and powerful open source solution for web content and experience management that sits on top of Alfresco, the world’s most open and powerful content management platform, we’re hosting a Crafter Rivet Roadshow in a city near you in May!  Come on out for content packed presentations, demonstrations, Q & A and free lunch!

Sign-up for the Crafter Rivet Roadshow here!

Crafter Roadshow Dates:

San Francisco
Tues. May 8

Los Angeles
Wed. May 9

Chicago
Tues. May 15

New York
Wed. May 16

Boston
Thur. May 17

Washington DC
Tues. May 22

Web CMS on The Alfresco Core Repository (Part 2 of 2)

Posted by on April 10, 2012

In yesterday’s post we covered the fact that Alfresco stopped selling the AVM based WCM solution to new customers.  Existing customers using the AVM based approach will continue to receive support until the AVM reaches end of life status.  New customers looking to Alfresco for WCM/WEM capabilities who read this will naturally wonder what is the approach to WCM on Alfresco.  Existing customers will want to know how to migrate off the AVM and in to Alfresco’s core repository.

As we have seen in yesterday’s post, the core repository has had the benefit of continuous innovation through which it has grown as a platform now capable of supporting use cases critical to WCM/WEM with key features like remote file deployments and form based content capture.  Along with features clearly directed at the WCM use cases, the core repository is host to an amazing array of features and capabilities that make it ideal for all manner of enterprise management, WCM/WEM included.

At Rivet Logic we have made a significant investment in a web content and experience management extension to Alfresco that we call Crafter Rivet. Crafter Rivet is a 100% open source,  full featured application that powers 100s of websites and has over 40 man years of development effort invested in it. Initially Crafter Rivet’s authoring and management capability was based on the AVM. When Alfresco made the decision to direct the full force of its innovation on the core repository we knew it was time to covert. Just released, Crafter Rivet 2.0 is 100% based on the core repository, Solr search and Actviti workflow for Alfresco 4 CE and EE.  Making the switch from the AVM to the core repository required a deep examination of our use cases and the features we would have on hand within the core repository.

Now that we have a background understanding of both the AVM and core repository features we discussed yesterday it is time to look at the use cases that the AVM was designed to address.  We will discuss the use case and how these gaps were addressed by Crafter Rivet.  Let’s get started!

Use Case: Sandboxing
As described in yesterday’s blog, sandboxing is a feature but there are use cases that drive this feature. In a Web CMS context we have times when we need to modify templates, CSS and other assets that have far reaching effects on our sites. There are three common use cases that point to sandboxing:

  • Development:  As a developer I want to work with a template, a CSS file, a JavaScript library, etc. without worrying that the bugs I will inevitably create will interfere with the rest of the teams ability to produce, manage, preview and publish content.
  • Timing: On websites of significant size and complexity, there are often times when projects are created to update the look and feel of the site.  These projects with future delivery dates need to be able to take place without interfering with daily publishing.  Further, it’s important that the project be able keep up with on-going updates to reduce the headache of last minute merges.
  • Playground:  Sometimes we just want to play.  Sandboxes allow us to enable team members to innovate and play around without fear of impacting the live website.

It’s clear that the ability to sandbox (or branch/merge) your website code base can be pretty handy. In my mind there are several key questions:

  • Is the support for this use case a “must have” for my specific environment?  How often do I run in to the use cases above?
  • What granularity of sandboxing do I need?

Many popular Web content management systems do not natively support sandboxing. In a lot of cases the need for the branch merge capability is handled through the development and deployment process. In general I think it safe to say this feature is a rather strong “nice to have” unless you have an site with look and feel components which are literally being constantly updated and where the traditional development process would add too much time to the effort.

When you do need sandboxes the next question is granularity and how sandboxes are used. The AVM UI dictates sandboxes for each user. In my experience accumulated over many Alfresco WCM engagements; is that this was too fined grained for the needs of most engagements.  Most users want to work directly in context with other users.  They need basic locking on individual assets to keep work safe during their edits but they don’t require an entirely separate and parallel universe.  The ability to create a sandbox ad-hoc for a specific purpose maps more directly to the needs we see on the ground. In other words, a sandbox is too granular but a sandbox for a project to update the look and feel of the entire site where users could work together would more aptly address the kind of needs we see.

Crafter Rivet starts with the first finding, that sandboxing is not a “must have” feature and that in-fact when it is applied it should be done so to facilitate specific projects and specific ad-hoc needs. If you look at the way we have structured our content in the core repository you will see we have left room to support one or more draft copies of the site.  In v2.0 we do not support layering in the default configuration; however, Crafter Engine, our content delivery and preview tier, is able to sit over top of multiple hierarchical stores and present them as one store much in the same way the AVM did.

Use Case: History and Reversion in a Web CMS Context
As a user, when I want to preview a version of a specific asset, let’s say a page,  I want to see the page as it was on that day. That means I want to see exactly the same components and assets (images, CSS, js etc) as they were on that given day.  This is a real challenge in the core repository because there is no native support linking assets together under a common version; each asset is individually versioned and the links between objects (associations) do not capture version.

Now to be honest, I have simplified the problem a bit to make a point.  I said that pages, for example, are compound assets and that you are always interested in seeing their dependencies at a given point in time.  This is often the case when we’re talking about images and components that are specific to the page but it’s not really the case when we’re talking about shared assets like templates, CSS, JavaScript, and shared components and shared collateral.  Think for a moment about why users want to look at and ultimately revert to previous versions of content.  They are doing so either:

  • In the short term because they have made a mistake, or
  • in the long term because they need to revert messaging to a previous point in time.

In the first instance there is likely to be no issue.  Common assets are likely going to be the same as they where at the point in time of the version.  However, in the second case, we really want to see the old content in the context of the current templates, etc.  If we revert, it’s to get the older content, but we’re going to deploy it in the context of the latest look and feel of our site.

Handling versioning in Web CMS is a must have, must do capability.

In Crafter Rivet we considered these use cases fully and drew a distinction between two types of relationships.  Those relationships which are page only  and those which are shared commonly amongst other objects in the system.  When you revert a page or any other object, those relationships which are “page only” will revert to a point in time, while other relationships that are common will continue to align to the latest version of the asset.

To accomplish this we leverage both the native versioning capability of the core repository as well as file organization and patterns.  In short, we organize page-only assets in folder structures that represent the page. Page objects are given names that are based on a hash of the object to guarantee a unique name which means in effect that the versioning of the page only object is “horizontal” in the repository. By horizontal I mean that a new file path is used rather than relying on the version store.  Shared objects like pages or other common assets are stored regularly and rely on the native versioning support.  If you revert a page you will revert to an a state where the page points to a different set of file / file paths — achieving a solution for both use cases we mentioned above.

Snapshots
There are several Web CMS use cases that could require snaphsots and version diffs.  For example, some websites have compliance related issues and thus must maintain versions of their sites so that in the event of a dispute over information communicated via the site they can easily prove what the site looked like at a particular moment in time.  The question for snapshots is:

  • Is this something your organization must have?
  • And if so, is it something that the repository has to do for you?

Our experience shows that this feature, for the general market, is a nice to have.  Most customers don’t take advantage of this capability.  When we looked at this capability in Crafter Rivet, we decided it was not important to support natively within the repository itself.  If a customer needs a snapshot every day we simply include a deployment target that would produce a snapshot.

For those wondering about snapshot rollback; our experience has shown that this particular feature is really not relevant to most customers in day to day operation.  The feature has come in handy as a mechanism for bailing out people who have made sweeping changes to a site (100s of files) and deployed them with little or no QA only to find a broken website after the fact.  In such a case, snapshotting a rollback is a life saver.  With a click of a button you can revert 100s of files.

Crafter Rivet, by design is 100% file based. In such a crisis scenario, a simple file based backup could be used to restore a Crafter Rivet based site to a former state.  In the repository, you are unlikely to desire an actual rollback.  It’s more likely that you will want to keep the broken state and simply fix what is wrong and then redeploy the working site.

Moving Forward

Alfresco v4 is an incredible platform and the move to the core repository unlocks all of that capability and innovation. Crafter Rivet is a platform that made use of all of the functionality in the AVM.  And with our new release, we made the move.  You can as well.  More importantly, if you are using the AVM with Alfresco v3 (or even V2), then Crafter Rivet is the perfect solution for your upgrade.  We can provide parity for most needs with a much better user experience that goes way beyond basic Web CMS needs with the coverage of WEM use cases like integrated analytics and reporting, native mobile application authoring, preview, and presentation, content targeting and personalization, multi-channel publishing and much more.  If you’re new customer to Alfresco looking for Web CMS solutions, Crafter Rivet is a comprehensive WCM/WEM solution, with features that rival some of the major players in the industry.

Click here to learn more about Crafter Rivet

Click here to sign up for a our webinar “Crafter Rivet – The WEM Solution for Alfresco 4″ on April 12th at 1pm

Web CMS on The Alfresco Core Repository (Part 1 of 2)

Posted by on April 09, 2012

I was on a call today with a long time Alfresco WCM customer who would like to upgrade from 3.x to 4.x.  They have been using the Alfresco WCM solution provided by Alfresco in 2006 for many years. As many of you know Alfresco’s original WCM solution is based on a technology called the AVM – Alternative Versioning Model.  The AVM is a separate repository and associated user interface that was constructed to handle a number of WCM related use cases. Alfresco has since enhanced their offering in their “Document Management” repository, which now handles WCM use cases.  As a result, Alfresco has now announced that  the AVM will no longer be offered to new customers.  In discussing the upgrade with our clients on the call today. “It’s time to move to the ‘DM’” was the most responsible message to provide. Existing customers won’t lose support over night, but eventually the AVM will hit its end of life.  You want to migrate at your earliest convenience rather than procrastinating and allowing pressure to build.

It’s also important at this point to abandon the use of the term “DM repository”. DM was used to differentiate from the AVM.  At this point there is only one repository.  The “core repository” is much more descriptive of the architecture going forward.  As Jeff points out in his blog and as I will elaborate here, there are differences in the the AVM and the core repository in terms of features. That said, features and use cases should not be confused. The core repository is every bit as capable of providing a platform for Web content management use cases as the AVM.

At Rivet Logic we have made a significant investment in a Web content and experience management application for Alfresco that we call Crafter Rivet. Crafter Rivet is a 100% open source,  full featured environment that powers 100s of websites and has over 40 man years of development effort invested in it. Initially Crafter Rivet’s authoring and management capability was based on the AVM. When Alfresco made the decision to direct the full force of its innovation on the core repository we knew it was time to convert. Crafter Rivet 2.0 is now based on the core repository, Solr search and Activiti workflow for Alfresco 4 CE and EE.  Making the switch from the AVM to the core repository required a deep examination of our use cases and the features we would have on hand within the core repository.

I thought it would be helpful to share some of that thinking.  Today we’ll look at the differences in these repositories and tomorrow, in a second post we’ll discuss the actual Web CMS use cases that need to be addressed and how we addressed them in Crafter Rivet. Let’s explore!

Unique Features of the AVM

The first thing I want to do is address the question of what the AVM can do that the core repository cannot.  Because we’re comparing repository to repository we’re going to discuss features and not use cases. Note that for simplicity, on occasion we’ll collapse the features of the AVM repository, supporting UI and supporting integration into the single term AVM.  It’s also fair to note that what we’ll discuss here are the aspects of the AVM which exposed through the associated user interface and thus applicable to customer engagements.  There are features/capabilities of the AVM repository that were not fully exposed by the UI.

Sandboxing (more accurately, layering)

Sandboxing is the ability for a user to work on any asset or group of assets within the site without interfering with another user’s work.  For example, a user could modify and even break a template or CSS file and no one would know until and unless the user promoted that broken asset out of their work area.  For non-technical readers, a sandbox is best described as your own copy of the website.  For the technical readers, you can think of a sandbox as a long running transaction — in source control terminology, a sandbox is like a checked out branch of the site.

Sandboxing is a high order feature born out a lower level feature called “layering.” The AVM is constructed of lightweight stores.  Stores can be layered one on top of the other.  The store on the top appears as though it contains the assets within the store layered below it.  If a user places an changed in the top store it appears to over-write the asset at the same path below it.  If we have a base store we’ll call “the stage area” and then a store for each user; say Bob and Alice,  and both Bob and Alice’s stores are layered on top of  the staging area you can see how we create the concept of sandbox.  Alice can see everything in the staging area, but nothing in Bob’s store. Alice’s work is in a “sandbox.”  If Alice pushes her change from her store to the staging area, Bob sees it immediately as if it were in his store.

Multi-Asset Versioning

In the AVM, versions are taken at the store level not per asset. When you place a change in the store, a lightweight version is created for all assets at that moment. Because of this, it is possible to know the state of every object at a point in time relative to a given object. For Web CMS applications, we deal with compound assets all the time.  Consider a webpage. A webpage is not typically a single file asset,  it’s a document that points to other documents: components, images, css, javascript, etc.  When you version a page, you generally intend that entire collection of assets to be versioned along with the page.

The core repository manages each individual asset’s version history independently.  If page X points to component Y there is no innate support within the version system to know what version of Y was in use at any given point of X’s history.

Snapshots / Comparison and Rollback

In the AVM you can label a version and compare one version to another. It is easy to see what files have changed.  Because of this it is possible to create “diffs” from one version to another.  Once you have a diff you can roll back entire check-ins very easily.

Content Forms (Now supported in core)

The AVM user interface used to support a forms capability that was not available for the core repository. The forms engine made it simple to create content capture interfaces through mere configuration.  Today the core repository has a forms capability that is more powerful than what was provided for in the AVM user interface.

Content Deployment (Now supported in core)

An AVM project could be configured with remote content receivers.  There was out-of-the-box support for repository to file system deployment (FSR) and repository to repository deployment (ASR).  Today the core repository provides two deployment mechanisms; Transfer Service and Channel Publishing framework, which combined now exceed the capabilities of the AVM content deployment framework.

Unique Features of the Core Repository

Now lets look at what the core repository has going for it that the AVM repository and supporting UI never got around to implementing.  Again we’ll look at features rather than use cases.

Rules Support

The core repository allows you to attach rules to a folder that execute based on lifecycle events and configurable conditions.  This is extremely powerful and its a feature that was sorely absent in AVM.

Stronger Modeling Support

Both repositories allow us to create types and (more commonly) aspects which contain metadata.  However the core repository allows for associations at the modeling layer. In the AVM, associations were kept only as paths within files.  This turns out to be fine for content delivery but bad for managing the content due to move and rename operations because of the unbounded number of updates you may have to perform. Associations in files also makes it difficult for supporting user experience features in your content management platform.   Users expect a platform to understand it’s assets and how they relate to one another in a way that can be quickly accessed through query.  The core repository can do this innately through it’s use of associations.  The AVM cannot.

Strong Transformation and Metadata Extraction

The transformation and metadata extraction frameworks integrated with the core repository greatly exceed the capabilities of the those integrated with the AVM.  The AVM is only integrated with an XML metadata extraction and transformation. The core repository on the other hand has integrated support for all kinds of metadata extraction and transformation including Microsoft Office documents, images, PDF and many many more.

Powerful, Fine-grained Permissions

The core repository gives us the flexibility to create and manage user access to content in a way that best fits an individual engagement through the use of ACLs (Access Control Lists.)  While the AVM was based on a similar scheme under the hood, these were never exposed through the UI and thus it were not practical to deploy on engagements.  Out-of-the-box AVM exposed a few roles that could be applied broadly to the entire site in each sandbox.

API support

The core repository has much better remote API support.  The core repository supports CMIS, webscripts, and RAAr.  AVM only supports a remote API based on RMI.

Workflow Engine

The core repository has 3 workflow engines integrated with it: Simple, JBPM, and Activiti. Activiti is based on standards and has parity with JBPM, but incorporates a far better management console. The AVM provides workflows based on JBPM integration only.

Search

Full text search support is based on indexing. You index a store. In the AVM universe every web project was made up of many (layered) stores.  It was not practical to index every store.  Although you can configure individual stores for indexing, if every author in the system wants to be able to search their sandbox, you will hit obvious limitations to the approach. The core repository content has only one store which is constantly tracked by a search index which means that search is very current with work in progress.  Alfresco 4 has introduced Solr as one of its search subsystems.  Solr provides capabilities that greatly exceed Lucene, the indexing engine used by the AVM.

Integrations

The core repository has many integrations that allow users to interact with content on their own terms, be it email, WEBDAV, FTP, shared drive, Sharepoint and so on.  With exception to the filesystem projections, these are simply not made available in the AVM.

Native support in the UI and APIs for taxonomies, folksonomies and collaboration features

The core repository has repository service and UI support for

  • Hierarchical taxonomies
  • Tags
  • Comments
  • Content lists

Making Sense of the Differences

By this time you should have a pretty good idea of how the repositories compare from a feature perspective.  Two observations are obvious:

  • The core repository has a had the benefit of deep continuous innovation.
  • The AVM has certain features intended for WCM use cases that will need to be addressed in a solution that leverages the core repository.

Join us tomorrow for a blog post that will demonstrate the use cases that these features were intended to cover and how we addressed all the Web CMS use cases with Crafter Rivet using and capturing the full power and innovation of Alfresco 4 and the core repository.

Click here to learn more about Crafter Rivet

Click here to sign up for a our webinar “Crafter Rivet – The WEM Solution for Alfresco 4″ on April 12th at 1pm Eastern for a further discussion and demos!