Hippo cms workflow with events

Hippo is an opensource content management system. Hippo has created a cms on top of the Jackrabbit repository. Hippo is not the only cms that does this trick, but it is a big one. With version 7 out there, you can now use some nice features that they have created. This post discusses one of these features in detail, Workflow. I’ll explain what it is, what is can be used for and how you can extend it with business events.

I do want to stress that this is an idea I have about how this can be implemented. I did try it out, but do not consider this as a best practise (yet). See it as inspiration to your own extensions and maybe Hippo will contain something like this in the future.

The idea behind this post came from talks with Allard and Jeroen Reijn, who will write a blog post about a specific part of the solution as I will describe in the post later on.

The problem

Let me start by describing the reason why I wanted a solution like this. For a project we are doing, we want the content of the repository to be available in a Solr instance. Yes I know Hippo comes with Lucene out of the box, but we have have chosen to use solr. The reason behind this is not important for the scope of this blog post. Because of this we need to have information about content in the repository. Of course there are multiple mechanisms available to do this. I have blogged before about repository listeners. There is a big disadvantage with these listeners, they are not part of the repository. They are part of a client that connect to the repository. These listeners are also very low level, they respond to nodes being added or changed. We are more interested in the business events that take place. An example would be the publication of a document. We want to integrate with the workflow in the cms/repository.

The design

The following image gives an overview of the design for the solution.

Let’s start with the WorkflowEventDaemon, this is a class that get’s instantiated by hippo during initialization of the repository. This daemon queries the repository for nodes of type cust:workflowevent. These nodes contain a reference to the implemented EventListeners. The daemon uses these nodes to register event listeners with the EventManager. Next up are the workflow implementations. Currently the provided workflows do not raise events. Luckily it is fairly easy to extend these workflows so they do create the events. The workflow implementations use EventDispatcher instances to actually send an event to the EventManager. Using these events, the EventManager will call the listeners.

That is the basic idea about the solution, let’s focus on the implementation now.

The implementation

Node type defintion

First we need to tell the repository about the new type. This is done using CND file. The file looks like this.

Hippo has created a mechanism to load nodes into the repository during startup. If you provide a file with the name hippoecm-extension.xml, hippo picks it up and puts these nodes in the repository. To load the CND file we add the following configuration

WorkflowEventListener

If you are interested in WorkflowEvents, you need to register a listener. Configuration of these listeners is done in the repository. We can add a node during startup. This is done by adding the following configuration to the hippo-extension.xml file.

This references the workflowsevents.xml file. The following code shows this file that actually contains a node of type cust:workflowevent containing a reference to a very easy Logging implementation of the WorkflowEventListener interface

Now we have the nodes in the repository that daemon queries for. So let’s have a look at the daemon.

The daemon

Now we have come to the part where Jeroen helped me out. It turns out that hippo looks on it’s classpath for all MANIFEST.MF files. If such a file contains an entry for the property Hippo-Modules, hippo expects a space delimited number of classes that are implementations of the DeamonModule interface. If you are using maven, this is very easy to accomplish using the jar plugin.

Dispatching events

I already mentioned I want to dispatch events from workflow components. It is a bit out of scope of this blog item to discuss workflows in Hippo very detailed. To be honest, I would not be the right person to do that. Still I want to give you a very short introduction.

The default workflow for promoting content from draft into publication is the Reviewed actions workflow. This workflow is provided in the default installation. Workflow items in here define what needs to happen when an author opens a document in edit mode or when an editor can do. These kind of workflow items are initiated by the frontend plugins. These plugins are wicket components that put a save and cancel button on the screen. In this blog item I’ll describe the way to extend such a workflow and how to configure the repository/cms to use our custom workflow item.

The workflow items are configured in the repository in the following path/hippo:configuration/hippo:workflows/. For the specific BasicReviewedActionsWorkflow we need to change two locations. In the following two locations we need to change the property hippo:classname:

/hippo:configuration/hippo:workflows/default/authorreviewedactions

/hippo:configuration/hippo:workflows/editing/reviewedactions

There is one thing left to do, hippo uses jpox to enrich the worklfow. This enriching needs to be done using the jpox maven plugin. The following code block gives an example:

4 thoughts on “Hippo cms workflow with events”

Hi Jettro, cool stuff!
It might be nice to know how to make this dynamic, i.e. such that one can add and remove listeners at runtime.
You could do this by creating a separate type (cust:workfloweventfolder?) for the folder that contains the cust:workflowevent nodes. In the daemon code, register a jcr listener for this node (by type, so that there can be multiple folders) and (un)register a workflow event listener when node added/removed events are received.
Administrators might appreciate such functionality…

He Freddie, good to be in your territory now :-). If I understand you correctly I can say: Yes. JackRabbit does have the concept of document types. If you check the first code block with the CND file, this is a type definition for the nodes in the repository. With these types you can specify what a certain item looks like. You can use inheritance within types as well as aggregation relations.

Meta-data is handled using normal properties except for a few basic properties like Node name, creation date, etc.

I have a question. Is JackRabbit truly a Repository or is it just a sexy name for an Archive?

According to the literature a Reposítory contains the definitions of the What in your own words CLASS DEFINITIONS and not Instances. To me Content is an Instance of a certain type and described by NOT what everyone think is META-DATA but should be called Attributes. META-DATA describes the structure, rules, entities (ontologie). Content instances are stored in an Archive (for short or long term).

Curious to hear from you

Comments are closed.

Welcome

Welcome to our blog about all kind of topics that are related to software development. We blog about:

SOA, BPM, EDA, ECM and all the other buzz words. Beware some post might not be so common as you think. We are not scared to go against main stream thoughts.

Technologies like java, maven, springframework, OSGi and front end technologies and frameworks like jQuery, DWR, Flex.

Finally to make this happen we need tools and of course a Mac (well some of us do). So we blog about that as well.