(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"
     >
  <imports>
    <import uri="http://www.alfresco.org/model/wcmworkflow/1.0"
      prefix="wcmwf" />
    <import uri="http://www.alfresco.org/model/bpm/1.0" prefix="bpm">
  </imports>
  <namespaces>
    <namespace uri="http://book.com" prefix="bookwcmwf" />
  </namespaces>
</model>

Create a Type for each task

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

<types>
  <type name="bookwcmwf:submitReviewTask">
    <parent>wcmwf:startTask</parent>
  </type>
</types>

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">
  <parent>wcmwf:startTask</parent>
  <properties>
   <property name="wcmwf:submitReviewType">
     <title>Serial or Parallel Review</title>
     <type>d:text</type>
   </property>
  </properties>
  <associations>
    <association name="wcmwf:webproject">
     <source>
       <mandatory>false</mandatory>
       <many>false</many>
     </source>
     <target>
        <class>wca:webfolder</class>
        <mandatory>true</mandatory>
        <many>false</many>
     </target>
   </association>
  </associations>
</type>

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">
  <parent>wcmwf:workflowTask</parent>
   <mandatory-aspects>
     <aspect>bookwcmwf:reviewInfo</aspect>
     <aspect>bpm:assignee</aspect>
   </mandatory-aspects>
</type>
  <aspects>
    <aspect name="bookwcmwf:reviewInfo">
  <properties>
    <property name=" bookwcmwf:reviewerCnt">
      <title>Reviewer Count</title>
      <type>d:int</type>
     <mandatory>true</mandatory>
    </property>
   </properties>
  </aspect>
</aspects>

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 http://wiki.alfresco.com/wiki/Data_Dictionary_Guide#Content_Types.

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	Description
Swimlane	Swimlane is used to define a role for a user.
Transition	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.
Task	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	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.
Events	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.
Scripts	Script is executed within Action. Some of the variables that can be available in Script are node, task, execution context, and so on.
Nodes	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	Description
Task Node	A Task Node represents one or more tasks that have to be performed by users.
Start-state	There can be only one Start-state in the Process Definition, which logs the start of the workflow.
decision	The distinction between multiple paths. When the decision between multiples path has to be taken, a decision node is used.
fork	A fork splits one path of execution into multiple concurrent paths of execution.
join	Joins multiple paths into single path. A join will end every token that enters the join.
node	The node serves the situation where you want to write your own code in a node.
End-state	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 
     name="bookwcmwf:bookworkflow">

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">
  <assignment
    class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
    <pooledactors>#{bpm_groupAssignee}</pooledactors>
  </assignment>
</swimlane>
<swimlane name="assignee">
  <assignment
    class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
    <actor>#{bpm_assignee}</actor>
  </assignment>
</swimlane>

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"/>
</start-state>
<swimlane name="assignee">
  <assignment
    class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
      <actor>#{bpm_assignee}</actor>
  </assignment>
</swimlane>

 <task-node name="initialise ">
 <task name="bookwcmwf:verifyBrokenLinksTask"
   swimlane="assignee" />
   <transition name="abort" to="end">
    <action
     class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
       <script>
        var mail = actions.create("mail");
          mail.parameters.to =
            initiator.properties["cm:email"];
          mail.parameters.subject = "Adhoc Task " +
            bpm_workflowDescription;
          mail.parameters.from =
            bpm_assignee.properties["cm:email"];
          mail.parameters.text = "It's done";
          mail.execute(bpm_package);
      </script>
     </action>
   </task-node>
  <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 http://wiki.alfresco.com/wiki/WorkflowAdministration.

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.

<model_prefix>_<model_name>.[title|description]
<model_prefix>_<model_name>.<model_element>.<element_prefix>_
     <element_name>.[title|description]

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

bookwcmwf_bookworkflow.workflow.title=Book Workflow
     bookwcmwf_bookworkflow.node.verifybrokenlinks.transition.abort.
title=Abort Submission
     bookwcmwf_workflowmodel.type.bookwcmwf_reviewTask.description=
Review Documents to approve or reject them

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