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:
For any workflow to be deployed you should have the following files:
Follow these steps to create a custom workflow.
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.
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>
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>
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>
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:
The following are the disadvantages of having custom Aspect over custom content:
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.
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 |
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.
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.
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>
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.
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.
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.
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.
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>
Now that we have completed workflow implementation, let's test the workflow.
Follow the steps below to test workflow.