Creating a custom WCM Workflow for a group

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. For more information about creating a group and users refer to Chapter 3,Getting Started with Alfresco WCM.

The custom workflow process is shown in the following diagram:

Creating a custom WCM Workflow for a group

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.
    Defining the workflow process

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"
xmlns="http://www.alfresco.org/model/dictionary/1.0">
<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.

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, node-enter, 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 xmlns="urn:jbpm.org:jpdl-3.1" 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.

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.

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 web-based 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-model-name>-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.

Note

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:

<workflows>
wcmwf:submit ,bookwcmwf:bookworkflow
</workflows>

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.
    Test the workflow
  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.
    Test the workflow
  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.
    Test the workflow
  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.
    Test the workflow
  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:
    Test the workflow
  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.

    Note

    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.

    Test the workflow
  12. Any one of the users of the group has to take ownership. Click on Take Ownership.
    Test the workflow
  13. You will notice that the task now appears in the My Task To Do dashlet.
    Test the workflow
  14. Open the Manage Task dialog. You are also given the facility to leave the ownership. Click on Return To Pool.
    Test the workflow
  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.
    Test the workflow
  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.
    Test the workflow
  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.
    Test the workflow
  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.
    Test the workflow
  22. On clicking Abort Submission, you will notice the task in My Task To Do.
    Test the workflow
  23. Open the task and click on Task Done. After that you can see the files again in the Modified Items section.
    Test the workflow
  24. If you have to submit a Blog, start the process again.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset