Introduction
Alfresco (the open-source enterprise content management system) provides support for recording system activity out of the box.
The majority of user actions are captured by the activity system, and corresponding activity entries are stored within the database. These entries are then compiled into feeds in a variety of formats which are accessible via the URLs of multiple ‘webscripts’. These feeds can be consumed by a ‘dashlet’ located on a user or site dashboard, providing users with an up to date view of system activity. The dashlets provide various filtering options to give users control over which updates they are shown.
Out of the box, Alfresco provides two main formats for activity feeds: AtomPub and JSON. Whilst both of these feeds themselves are standard formats, the structure of the activity entries within the feeds do not follow any standard (they are a proprietary structure created by Alfresco).
This is sufficient for internal use, as the client knows the structure to expect. However, this is very much a bespoke activity solution, specific to Alfresco. In order to share this information with external applications, a common standard for activities is required.
ActivityStreams standard
The ActivityStreams standard is a specification that describes system activity in a common way so that it can be interpreted and consumed by other applications, without requiring specific knowledge of the source. This means that inter-application communication is much easier as the message structure is already established. In turn, this means that developer effort is reduced as less application-specific development is required to consume feeds from external sources.
As a result, ActivityStreams has seen a good level of adoption, even amongst some major organisations such as Facebook, MySpace and BBC. Given this level of uptake, ActivityStreams appears to be the favoured standard for activity structure.
Our aim
ActivityStreams supports AtomPub and JSON as feed formats, which matches the Alfresco out of the box feeds. This match, combined with ActivityStreams’ prominence in this space means that we would like to introduce ActivityStream support into the Alfresco activity system.
Alfresco’s activity system (Out of the box)
As it stands, the various components which make up Alfresco (blog, wiki, document library etc) all interact with the activity service when a user action has occurred. The activity service then records this action as a post entry in the database.
Shortly afterwards, an asynchronous job (known as the feed generator) runs, which processes all of these posts, producing a ‘feed entry’ for each user or site that the system deems to have access to this activity. Each feed entry is produced by passing the relevant data into a freemarker template for formatting.
These feed entries are then collated into feeds tailored for each user or site, and are then consumed by a dashlet as explained previously.
Required changes
On the face of it, this change is quite simple due to Alfresco’s easy to use freemarker templating system. We initially anticipated that it would just be a case of producing another set of templates which produce ActivityStream compliant feed entries. However, on investigation, we have found several aspects of the Alfresco activity system that complicate the design.
Firstly, we noticed that not all activity post entries store a node reference to the content the activity relates to. This means that customisation of formats is more difficult as there is no easy handle to obtain additional content information (which may be required for the other formats). Making the node reference available in both the post and feed entries allows any customisations to perform additional processing at any stage of the system.
The second difficulty is that the asynchronous feed generator job, which converts the activity posts into feed entries, has a guard in place to check the feed format being requested. This guard dictates which activity data passes through to the template. This means that some formats (infact, any format other than JSON) do not have access to all activity data. As we are proposing to add another format, and need the activity data present, we would need this guard to be removed.
Once these changes have been made, we would then be in the position to produce another set of freemarker templates to format the activity entries in an ActivityStream compliant fashion.
As far as we can tell, there is no significant reason as to why activity data is restricted to only JSON templates (other than potentially a minor performance improvement). Due to this, we feel that this guard is not required and would best be removed from the system. In a similar vein, we also feel there would be substantial benefit in providing a node reference with each activity update (post and feed entry), as any extensions would easily be able to access any additional data they made require for formatting or post-processing (making the activity system would be much more adaptable).
As we feel that these changes would improve Alfresco for the community, we have initiated discussions with the Alfresco team about the possibility of including them in the core product. However, such changes can take time to be realised. In the meantime, we are producing an Alfresco extension (AMP) to patch these ‘issues’, alongside our freemarker templates, to add support for ActivityStream compliant updates in Alfresco. Once this is complete we hope to release this to the community.
Going forward, it would be good if Alfresco could consider supporting ActivityStream compliant updates out of the box in place of their proprietary format. Given that they are similar in the content they include, I don’t see this introducing any significant issues, but would improve Alfresco’s capability in terms of application interoperability.
