Creating a Custom WCM Workflow for a Group using Alfresco 3

Amita Bhandari

September 2010

(For more resources on Alfresco 3, see here.)

You can define and deploy your own task-oriented workflows in the Alfresco repository. However, you need to follow a particular format to define your workflow and a particular process to deploy it in Alfresco. Workflows can be deployed manually (which requires a restart of the server) and dynamically (without starting the server). For now we will deploy the workflow manually. These customizations are typically deployed via the alfresco/extension folder and require the Alfresco server to be restarted to take effect. In the later examples, we will deploy using the dynamic approach.

As an example, we will configure one workflow. The use case scenario is as follows.

There is a section of Blogs and News on the Cignex website, which needs to be updated monthly. The blog has to be published regularly. In order to publish, one needs to follow some process that can be defined in a workflow. The blog has to be reviewed by three different groups. Each group has different roles. Groups approve the blog one at a time and in order. When the blog is submitted, it will go to the first group. All the users belonging to that group will receive a notification via a task in the My Pooled Tasks dashlet. Any one of the users can take ownership and approve or reject the task. If rejected, it will go to the initiator. On approval it will go to next group and the process will continue for all three groups. Once the process is complete, a notification will be sent to the initiator. Also the blog would be submitted to the Staging box.

For this, create Jennifer Bruce, Kristie Dawid, LeRoy Fuess, Michael Alison, and Jessica Tucker as users. Create three groups: Technical Reviewer, Editorial, and Publisher. Add Jennifer Bruce and Kristie Dawid to Technical Reviewer, add LeRoy Fuess to Editorial, and add Michael Alison and Jessica Tucker to Publisher. Invite Technical Reviewer, Editorial, and Publisher as Reviewer on the Cignex web project.

The custom workflow process is shown in the following diagram:

Defining the workflow process

For any workflow to be deployed you should have the following files:

  1. Task Model: The Task Model provides a description for each of the tasks in the workflow. Each task description consists of Name, Title, Properties, Mandatory Aspects, and Association.
  2. Process Definition: The Process Definition describes the states (steps) and transitions (choices) of a workflow.
  3. Resource Bundle (optional): A workflow Resource Bundle provides all the human-readable messages displayed in the user interface for managing the workflow. Messages include task titles, task property names, task choices, and so on.
  4. web-client-config-custom.xml: Web Client configuration specifies the presentation of Tasks and properties to the user in the Alfresco Explorer.
  5. custom-model-context.xml: The custom model Spring Context file instructs Spring on how to bootstrap or load the Task Model definition file, Process Definition file, and Resource Bundle.
  6. web-client-config-wcm.xml: Web Client configuration specifies the availability of workflow to the web project in the Alfresco Explorer.

Follow these steps to create a custom workflow.

Step 1: Create a Task Model

For each task in the Process Definition (as defined by <task> elements), it is possible to associate a task description. The description specifies information that may be attached to a task, that is properties (name and data type) associations (name and type of associated object), and mandatory aspects. A user may view and edit this information in the Task dialog within the Alfresco Explorer.

The Task Model is expressed as a Content Model, as supported by the Data Dictionary. To create a Task Model, create a new Content Model file for Process Definition with the .xml extension.

  • Define a Content Model name
  • Create a Type for each task
  • Define Properties
  • Define and add Aspects to a Type

Define a Content Model name

Create a new Content Model for the Process Definition. Define the namespace of the model. XML namespaces provide a method for avoiding element name conflicts. If you want to use any other model's task, aspect, or association, then you can use it by importing their namespace. Reusability of Task Model is possible.

<?xml version="1.0" encoding="UTF-8"?>
<model name="bookwcmwf:workflowmodel"
<import uri=""
prefix="wcmwf" />
<import uri="" prefix="bpm">
<namespace uri="" prefix="bookwcmwf" />

Create a Type for each task

For each task we have to define a Content Type. The Type can also be extended as follows:

<type name="bookwcmwf:submitReviewTask">

Define Properties

Within each Type, describe the Properties and Associations (information) required for that task. Properties can also be inherited from other task definitions. Using the previous example all the properties of wcmwf:startTask will be added to this Type.

<type name="bookwcmwf:submitReviewTask">
<property name="wcmwf:submitReviewType">
<title>Serial or Parallel Review</title>
<association name="wcmwf:webproject">

Define Aspect

You can also introduce custom properties by defining an Aspect. An Aspect can be applied to any Content Type. Once applied, the properties are added to that Content Type.

You cannot define a dependency on other Aspects. They cannot be extended.

<type name="bookwcmwf:verifyBrokenLinksTask">
<aspect name="bookwcmwf:reviewInfo">
<property name=" bookwcmwf:reviewerCnt">
<title>Reviewer Count</title>

The following are the advantages of having custom Aspect over custom content:

  • Flexibility: You will have more flexibility. Having a custom Aspect will give you the flexibility to add an additional set of properties to the documents in specific spaces.
  • Efficiency: Since these properties are applied selectively to certain documents only in certain spaces, you will use limited storage in a relational database for these properties.

The following are the disadvantages of having custom Aspect over custom content:

  • High Maintenance: If the custom Aspect (additional properties) is added to documents based on business rules, you need to define it at every space, wherever required.
  • Dependency: You cannot define the dependency with other Aspects. For example, if you need the effectivity aspect to always be associated with the custom aspect, you need to make sure you attach both the Aspects to the documents.

Now that we are familiar with the code, let's develop a complete model file to deploy our case study in action.

For any customization of files you have to develop the files in the extension folder of <install-alfresco>. Create a file book-serial-group-workflow-wcmModel.xml in the specified location <install-alfresco>/tomcat/shared/classes/alfresco/extension. Copy the downloaded content into the file.

For reference, go to

Step 2: Create the Process Definition

A Process Definition represents a formal specification of a business process and is based on a directed graph. The graph is composed of nodes and transitions. Every node in the graph is of a specific Type. The Type of the node defines the runtime behavior. A Process Definition has exactly one Start-state and End-state.

The following table describes some of the key terms used in a Process Definition:

Key term



Swimlane is used to define a role for a user.


Transitions have a source node and a destination node. The source node is represented by the property from and the destination node is represented by the property to. It is used to connect nodes. A Transition can optionally have a name. The name is represented in the UI with a button.


Tasks are associated with a Swimlane. These tasks are defined in the Workflow model files. On the basis of these tasks, the Properties are displayed.


Actions are pieces of Java code that are executed upon events in the process execution. These actions are performed on the basis of these tasks, as defined in the Process Definition.


The jBPM engine will fire Events during the graph execution. Events specify moments in the execution of the process. An Event can be task-create, nodeenter,

task-end, process-end, and so on. When the jBPM engine fires an event, the list of Actions is executed.


Script is executed within Action. Some of the variables that can be available in Script are node, task, execution context, and so on.


Each Node has a specific type. The Node Type determines what will happen when an execution arrives in the Node at runtime.

The following table summarizes the Node Types available in jBPM out of the box.

Node types


Task Node

A Task Node represents one or more tasks that have to be performed by users.


There can be only one Start-state in the Process Definition, which logs the start of the workflow.


The distinction between multiple paths. When the decision between multiples path has to be taken, a decision node is used.


A fork splits one path of execution into multiple concurrent paths of execution.


Joins multiple paths into single path. A join will end every token that enters the join.


The node serves the situation where you want to write your own code in a node.


There can be only one End-state in the Process Definition, which logs the end of the workflow.

There are two ways of building the Process Definition. One is by hand, that is create a jPDL XML document. The second option is by designer, that is use a tool to generate the jPDL XML document. To create a Process Definition, create a new Process Definition file with the extension .xml.

Define a Process Definition name

The Process Definition name is important.

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

In the previous code we have used bookwcmwf:bookworkflow where bookwcmwf is the namespace of the workflow model file defined earlier, which we are going to use in this Process Definition, and bookworkflow can be any name.

Define a Swimlane

Swimlanes are used to declare workflow "roles". Tasks are associated with a Swimlane. Here initiator is the user who is starting the workflow. Likewise, we have some other roles also defined. For example, bpm_assignee (one user to whom the workflow is assigned), bpm_assignees (one or more user), bpm_groupAssignee (single group), and bpm_groupAssignees (one or more groups).

<swimlane name="initiator"/>
<swimlane name="approver">
<swimlane name="assignee">

Associate a task

We have already defined task in the Content Model files. On the basis of these tasks the properties are displayed. Next step is to add these tasks to the workflow process. To start with, add a task to the start node. The Start Task is assigned to the initiator of the workflow. It's used to collect the information (that is the workflow parameters) required for the workflow to proceed.

<start-state name="start">
<task name="bookwcmwf:submitReviewTask" swimlane="initiator"/>
<transition name="" to="initialise"/>
<swimlane name="assignee">

<task-node name="initialise ">
<task name="bookwcmwf:verifyBrokenLinksTask"
swimlane="assignee" />
<transition name="abort" to="end">
var mail = actions.create("mail"); =["cm:email"];
mail.parameters.subject = "Adhoc Task " +
mail.parameters.from =["cm:email"];
mail.parameters.text = "It's done";
<end-state name="end"/>

During runtime, all the properties of the task bookwcmwf:submitReviewTask are visible to the user who is initiating a workflow. Once the properties are filled, the initiator assigns a task to another user or group. In this case, it is assigned to user. Now the task appears in dashlets of assigned user. The Assignee fills the properties of the task bookwcmwf:verifyBrokenLinksTask and clicks on the abort button. The abort transition would call Alfresco JavaScript that sends an e-mail. And an end-state event will log the end of the workflow.

We are now ready to create a Process Definition file and use the workflow model we developed earlier for our case study.

Create a file book-serial-group-processdefinition.xml in the specified location <install-alfresco>/tomcat/shared/classes/alfresco/extension. Copy the downloaded content into the file.

For reference go to

Step 3: Create the workflow Resource Bundles

For localized workflow interaction it is necessary to provide Resource Bundles containing UI labels for each piece of text that is exposed to the user. With the appropriate Resource Bundles, a single workflow instance may spawn tasks where the user interface for each task is rendered in a different language, based on the locale of the user. Specific structure has to be followed in order to define labels for UI in Resource Bundle.


Add all the properties that relate to this Process Definition and model.

bookwcmwf_bookworkflow.workflow.title=Book Workflow
title=Abort Submission
Review Documents to approve or reject them

Create a file in the specified location, <install-alfresco>/tomcat/shared/classes/alfresco/extension. Copy the downloaded content into the file.

Read more about this book

(For more resources on Alfresco 3, see here.)

Step 4: Create the Alfresco Explorer Task dialogs

The custom web client configuration file contains information on how to display these custom Content Types, Aspects, and Associations. You need to make sure that the web client program recognizes this new custom aspect and displays it in the webbased interface. In order to make this happen, you need to configure the web client file, web-client-config-custom.xml, in the extension folder.

Open the web-client-config-custom.xml file from the specified location <install-alfresco>/tomcat/shared/classes/alfresco/extension. Copy the downloaded content into the file.

Step 5: Create a custom model Spring Context file

The custom model context file defines the Spring bean that will be used to bootstrap the definition of your custom Model, Workflow, and Resource Bundle. It lists one or more custom Model files, Workflow files, and Resource Bundles. When Spring starts up, it will instantiate this bean and will load your files from the disk.

Create a custom model context file and name the file as <your-custom-modelname>-context.xml, for example, bookWorkflowModel-context.xml. Create the file in the specified location <install-alfresco>/tomcat/shared/classes/alfresco/extension. Copy the downloaded content in the file.

Download the complete code samples from the Packt website. It is very important for you to note that the Alfresco server recognizes context files.

Step 6: Deploy into WCM project

In order to identify this workflow for WCM, open the web-client-config-wcm.xml file from the specified location <install-alfresco>/tomcat/webapps/alfresco/WEB-INF/classes/alfresco and insert the highlighted XML code within the workflows tag, as follows:

wcmwf:submit ,bookwcmwf:bookworkflow

Test the workflow

Now that we have completed workflow implementation, let's test the workflow.

Follow the steps below to test workflow.

  1. Refer to the Associating workflows to web forms section for how to configure a workflow for Blog web form. You will notice one more workflow is added. Follow the steps as mentioned in the specified section.

  2. Go to Company Home | Web Projects | Cignex.
  3. Select Edit Web Project Settings from the action menu.
  4. Click on Next.
  5. On the next screen, click on Next again.
  6. In the Step Three window, you will notice the added web forms in the panel as shown in the following screenshot. You can see the Configure Workflow button available for the web form. This button is enabled only for those web forms for which we have configured workflows. Notice the attention icon next to the workflow. This indicates a workflow has been selected but not configured.

  7. Configure the workflow and assign it to three groups as shown in the next screenshot. This workflow is a serial one. So it will go to the groups, one by one, only in the series Technical Reviewer, Editorial, and Publisher.

  8. Click on Finish.
  9. Log in as user Mark. Submit the Blog to the Staging box. We will also see how the launch date functions. Click on OK.

  10. On submit, the Submit Items wizard will open as shown in the following screenshot. You can select the launch date as shown in the screenshot. If you want to make changes in the configuration of a workflow you can click on Configure Workflow as well. Click on OK:

  11. Log in as a user of group Technical Reviewer. Consider we have logged in as Jennifer Bruce. Configure the My Pooled Tasks dashlet. This dashlet is required for group workflows. Repeat the same steps for Kristie Dawid. For now, both the users will be able to see the task in their dashlet.

    No other group can see the task, as this workflow is for serial flow. A group will see the task in the order they are assigned.

  12. Any one of the users of the group has to take ownership. Click on Take Ownership.

  13. You will notice that the task now appears in the My Task To Do dashlet.

  14. Open the Manage Task dialog. You are also given the facility to leave the ownership. Click on Return To Pool.

  15. You will find again that the task appears in My Pooled Task. This gives the advantage for both the users to take the ownership and approve the task.
  16. Consider that Jeniffer Bruce has taken the ownership and approved the task. As soon as ownership is taken, the task disappears from the other two users.
  17. Once approved by users of the Technical Reviewer group, log in as user LeRoy Fuess of the Editorial group and approve the items.

  18. Once approved by LeRoy Fuess of the Editorial group, log in as Michael Alison of the Publisher group and approve the items (you can log in with any user of the group, take ownership, and approve the task).
  19. After being approved by all the groups, the task appears in the My Task To Do dashlet of Mark, who has initiated the process for submitting the content. The content is not submitted yet, as the Launch date is 12 December 2009 15:54.

  20. You will find the content in the Staging Sandbox in Content Awaiting Launch item. The content will be automatically submitted on 12 December 2009 15:54.

  21. Open the Manage Task dialog. You can either Abort Submission or Submit Now. If you click on Submit Now, it will submit the content to the Staging box. On clicking Abort Submission, the content will not be submitted.

  22. On clicking Abort Submission, you will notice the task in My Task To Do.

  23. Open the task and click on Task Done. After that you can see the files again in the Modified Items section.

  24. If you have to submit a Blog, start the process again.

Expiring content in WCM

For any changes promoted to the site, specific expiration dates can be set on a global or asset-by-asset basis. Expiration is the only indication that the content is expired. The content is not disabled or hidden in the Staging Sandbox. Upon expiration, end users are automatically assigned the asset as a task so that they can determine whether the asset should be updated or removed from the site.

The repository checks periodically for expired items. When any expired items are found they are added to a workflow and sent to the user that last modified the asset. If multiple items are destined for the same user, they are batched up into a workflow for each website the asset belongs to.

Clicking on the task will launch the Manage Task dialog that lists all of the expired items, from here the assigned user can perform the relevant action on each item. These changes occur in isolation from the user's sandbox, thus not affecting any work that they may currently be doing in their sandbox. The workflow, however, is layered over the user's sandbox so any changes that they have made in their sandbox will be visible.


Configuration for content expiration is in one file—scheduled-jobs-context.xml. You'll find the file in the Alfresco package, that is tomcat-home/webapps/alfresco/WEB-INF/classes/alfresco /scheduled-jobs-context.xml. It contains the configuration for the frequency of expired item checks. By default it is set to check once a day at 3:30 a.m. as can be seen in the following cron expression:

<bean id="avmExpiredContentTrigger" class="org.alfresco.util.
<property name="jobDetail">
<bean id="avmExpiredContentJobDetail"
<property name="jobClass">
<property name="jobDataAsMap">
<entry key="expiredContentProcessor">
<ref bean="avmExpiredContentProcessor" />
<property name="scheduler">
<ref bean="schedulerFactory" />
<!-- trigger at 3:30am each day -->
<property name="cronExpression">
<value>0 30 3 * * ?</value>

You can make the changes for cron expression and check the expiration date functionality.

Changes can be also made directly to these files, but better practice would suggest to make changes in content-expiration-debug-context.xml.sample located at <install-alfresco>/tomcat/shared/classes/alfresco/extension/.

Rename the file to content-expiration-debug-context.xml. Paste the previous code with changes in cron expression as suggested in the following:

<property name="cronExpression">
<value>0 3 * * * ?</value>

This will run the scheduler in every three minutes and will check for the expired item.

Submit any item and apply expiration date as mentioned in the following screenshot:

Process the workflow as explained in the previous sections.

After 14 December 2009 15:45, you will find a task in the My Task To Do dashlet as shown in the following screenshot:

Open the Manage Task dialog. The dialog displays two buttons as shown in the following screenshot. Both signal that all changes have been made and will therefore apply the changes to the user's sandbox. The bottom button, Task Done & Re-Submit All, will immediately launch the Submit dialog so that the users can submit their changes. Whereas the Task Done button will just apply the changes and users can then pick and choose when and which items to submit.


Workflows are an important aspect in Alfresco WCM. Alfresco web project uses workflows to support any set of changes, either automated or user-driven steps, in a business process before final commit to the Staging Sandbox. In this article we have seen the creation of a custom WCM workflow for a group.

Further resources on this subject:

You've been reading an excerpt of:

Alfresco 3 Web Content Management

Explore Title