In jBPM, a process definition comprises a set of nodes joined together with transitions. For the more mathematically minded, a process definition describes a directed graph of nodes with transitions forming the edges of the graph. There are a number of different types of node that can be used in a process definition. It's worth spending a little time here to look at each type.

The first type of node that all process definitions must include is the start-state. As the name suggests, when the jBPM engine starts a new process using a given process definition, the start state of that process definition is the state that the process enters initially. Every executable process definition has precisely one start-state node.

At the other end of each process are one or more end-state nodes. An end-state node indicates to jBPM that the process has finished. Where a process branches (or forks), an end-state node marks the end of each branch.

As hinted at in the previous paragraph, it is possible to cause a process to fork in to two or more branches by using a fork node. This has the effect of spawning a new thread of execution for each branch. Subsequently, a join node can be used to bring different branches back together again. There are many possible uses for this forking and joining functionality. For example, if an organization is producing a new brochure then it may want the design review to be carried out in parallel with the proofreading. Once both tasks are successfully completed, the brochure can be published. Forking the process allows the parallel tasks to happen, and then joining the parallel branches together again ensures that both are complete prior to entering the publishing activity.

It is often desirable to be able to define rules that dictate which path a particular process should follow. For example, one may wish to use a more rigorous review stage if a document has been flagged as "commercially sensitive" or perhaps take a different path depending on the outcome of a design review. In jBPM, these kinds of choices are modeled using decision nodes. A decision node will normally have more than one transition leaving it, and there are two ways in which the process definition can specify which transition is to be taken. The first approach is to define conditions on each of the transitions. In this case, when executing the decision node, jBPM will evaluate the conditions of each transition in turn and will follow the first transition that returns true (or the default transition if none returns true). The second approach is to define an expression on the decision node that returns the name of the transition that should be followed.

The final types of nodes to look at are also the most widely used: state and task-node. When a process enters a state node it simply waits to be told when to move on. This type of node is typically used when the process needs to wait for another system to do some work before continuing. This other system is expected to notify jBPM when it has finished, thus releasing the process to carry on. Nodes of type task-node are similar to state nodes except that they cause a task to be created and assigned to one or more users of the workflow system. For example, the nodes representing the design review and proofreading activities mentioned earlier are likely to be of the type task-node, with the tasks being assigned to the relevant people. In this case, the person to whom the task has been assigned is responsible for telling jBPM when the task has been completed, and jBPM will then continue executing the process.

Figure 7-2 illustrates a process that includes an example of each type of node.

Figure 7.2. FIGURE 7-2

This process starts and then immediately forks into the Internal Review and External Review nodes. The Internal Review node represents a human activity undertaken by a user who is known to the workflow engine and would, therefore, be modeled as a node of type task-node – when this node starts executing, a task is added to the assigned user's task list. Conversely, the activity represented by the External Review node is undertaken by someone unknown to the workflow engine – perhaps an email is sent to that person with the document attached when this node is executed – so this node is modeled as a plain state node.

Once complete, both the Internal Review and External Review nodes transition into a join node that waits for both branches to reach it. Once this happens, the transition that leads to the Check Review node is followed. The Check Review node is responsible for deciding whether the process can complete or whether some rework is required. Unsurprisingly, this task is best modeled with a decision node. Perhaps, in this case, this node expects a couple of Boolean variables to have been defined, such as internalReviewSuccessful and externalReviewSuccessful, and decides which transition to follow by examining their values. Presumably in this particular case, if either the internal review or external review was unsuccessful, then the transition leading to the Rework node is followed. This is most likely to be a task-node node that adds a task to the original author's task list.

The following XML code snippet illustrates how such a process definition may be described using jPDL.

<?xml version="1.0" encoding="UTF-8"?>
<process-definition name="document-review">

  <start-state>
    <transition to="review fork" />
  </start-state>

  <fork name="review fork">
    <transition name="internal" to="internal review" />
    <transition name="external" to="external review" />
  </fork>

  <task-node name="internal review">
    <task name="review task">
      <assignment actor-id="brian" />
    </task>
    <transition to="review join" />
  </task-node>

  <state name="external review">
    <transition to="review join" />
  </state>

  <join name="review join">
    <transition to="review decision" />
  </join>

  <decision name="review decision">
    <transition to="rework"
      condition="#{!internalReviewSuccessful || !externalReviewSuccessful}" />
    <transition to="end" />
  </decision>

  <task-node name="rework">
    <task name="rework task">
      <assignment actor-id="colin" />
    </task>
    <transition to="review fork" />
  </task-node>

  <end-state name="end" />

</process-definition>

In jBPM, an action is a piece of code that can be executed when certain events occur in a process. For example, it is possible to specify that a particular action should be executed when a given transition is followed, or when the process enters or leaves a node, or when a task is created. Out of the box, jBPM allows actions to be coded in Java or in a scripting language called BeanShell (see www.beanshell.org). In Alfresco, there is a hybrid option: a Java class named AlfrescoJavaScript that allows you to supply a script written against the Alfresco JavaScript API. That will be discussed in more detail later in this chapter.

In the example introduced in the previous section, you may decide that you'd like to email the document being reviewed to the external reviewer when the External Review node is entered. Of course, there is more than one way of achieving this, but for the sake of this example, there is a class named EmailDocToReviewer that performs the required functionality. To cause jBPM to execute an instance of this class at the appropriate point in the process, you modify the way that the External Review node is defined in the previous process definition to add in the event handler:

<state name="external review">
    <event type="node-enter">
      <action class="com.example.jbpm.EmailDocToReviewer" />
    </event>
    <transition to="review join" />
  </state>

These actions will be discussed in more detail later on in this chapter.

If you look closely at the example process definition, you will see that each of the two task-nodes defines a "task." This tells jBPM to create a new task and to assign it to someone. There are a few ways of indicating to whom the task should be assigned, such as identifying the user by name (as is the case here), writing an expression that resolves the user, or writing a custom assignment handler in Java. Another option is to use is a swimlane.

A swimlane identifies a role in a process. It is particularly useful when a process definition defines a number of tasks that should all be carried out by the same user. All such tasks are placed in the same swimlane and the swimlane determines to which user those tasks are assigned. By default, while running a single process, the person who is assigned the first task in a given swimlane will be assigned any other tasks that are in the same swimlane.

Since the example process definition isn't very complex, there isn't much need for swimlanes but, for completeness, here is how one might modify the process definition to use a swimlane for the reviewer:

<?xml version="1.0" encoding="UTF-8"?>
<process-definition name="document-review">

  <swimlane name="reviewer">
    <assignment actor-id="brian" />
  </swimlane>

  <start-state>
    <transition to="review fork" />
  </start-state>
  ...
  <task-node name="internal review">
    <task name="review task" swimlane="reviewer" />

<transition to="review join" />
  </task-node>
  ...
</process-definition>

Timers are another useful feature supported by jBPM. Any number of timers can be placed within any node or task, and each one specifies the time at which it should trigger. In addition, a timer definition may identify a transition that is to be followed, an action to execute, and a repeat interval. All of these optional attributes take effect when the timer first triggers.

For example, if you want to send an email reminder to the internal reviewer every other day until the review is complete, then you could modify the "internal review" task-node in your process definition to look something like this:

<task-node name="internal review">
    <task name="review task" swimlane="reviewer">
      <timer name="internal review timer" duedate="2 business days" repeat="yes">
        <action class="com.example.jbpm.SendReviewReminder" />
      </timer>
    </task>
    <transition to="review join" />
  </task-node>

Note that the previous code snippet assumes that the functionality needed to send out the email reminder has been written as a Java class. This makes the example compact but, in reality, you may choose to use Alfresco's JavaScript API instead. It's also worth pointing out the expression used for the timer's due date: "2 business days." jBPM expects the format of the due date to be [<basedate> +/-] <duration> where the optional basedate can be any expression that resolves to a Date or Calendar object and duration has the form <quantity> [business] <unit> where quantity is a number and unit can be one of second(s), minute(s), hour(s), day(s), week(s), month(s), or year(s). If no base date is provided, then the time starts from the moment the timer is created (when the internal review task starts, in this case). The optional word "business" in the duration causes only business hours to be used when calculating the trigger time.

The final concepts in this overview of jBPM are those of super-states and sub-processes. These are fairly advanced concepts. Though it may well be that you'll never feel the need to use them, it's worth mentioning them for the sake of completeness.

A super-state is used to group a set of nodes together, introducing a hierarchical structure to the process definition. A common usage is to separate the process definition into phases where each phase is composed of more than one task or state. In the example already presented in this section, you may choose to introduce a review phase that encompasses all the nodes that relate to reviewing the document. This is also a good opportunity to take a look at the process definition with all the changes so far:

<?xml version="1.0" encoding="UTF-8"?>
<process-definition name="document-review">

  <swimlane name="reviewer">
    <assignment actor-id="brian" />
  </swimlane>

<start-state>
    <transition to="review" />
  </start-state>

  <super-state name="review">

    <fork name="review fork">
      <transition name="internal" to="internal review" />
      <transition name="external" to="external review" />
    </fork>

    <task-node name="internal review">
      <task name="review task" swimlane="reviewer">
        <timer name="internal review timer" duedate="2 business days" repeat="yes">
          <action class="com.example.jbpm.SendReviewReminder" />
        </timer>
      </task>
      <transition to="review join" />
    </task-node>

    <state name="external review">
      <event type="node-enter">
        <action class="com.example.jbpm.EmailDocToReviewer" />
      </event>
      <transition to="review join" />
    </state>

    <join name="review join">
      <transition to="../review decision" />
    </join>

  </super-state>

  <decision name="review decision">
    <transition to="rework"
      condition="#{!internalReviewSuccessful || !externalReviewSuccessful}" />
    <transition to="end" />
  </decision>

  <task-node name="rework">
    <task name="rework task">
      <assignment actor-id="colin" />
    </task>
    <transition to="review fork" />
  </task-node>

  <end-state name="end" />

</process-definition>

You have now wrapped the fork, internal review, external review, and join in a super-state named "review." The start state now transitions directly to the new super-state, which causes jBPM to start executing the first node in the super-state (the fork). An alternative to this would have been to transition explicitly to the fork by changing the transition from the start state to be review/review fork. The process definition later emerges from the super-state when transitioning out of "review join." Note the way that this is done: specifying the target node with ../review decision. This is interpreted by jBPM as "transition to the node named 'review decision' that is one level up the state hierarchy."

jBPM allows one process to "spawn" another process with the concept of sub-processes. If, for example, you have a mini-process that is used in the context of a number of other different processes, then this way of composing process definitions may be useful to you. Inserting a node of type "process-state" into your process definition causes jBPM to execute a new instance of the specified process definition when a process reaches that node. In the example, you may want to define a sub-process named "process-document" that is executed before the review occurs. Perhaps this extracts metadata from the document, auto-classifies it, and generates a new rendition of it.

To include this sub-process in the process definition, insert a "process-state" node and adjust the start state so that it transitions to this new node:

<process-definition name="document-review">
  ...
  <start-state>
    <transition to="process" />
  </start-state>

  <process-state name="process">
    <sub-process name="process-document" />
    <transition to="review" />
  </process-state>
  ...
</process-definition>

That's all there is to it. It's also possible to pass variables from the parent process into the sub-process, optionally allowing the sub-process to modify their values such that the new values are returned to the parent process.

The Alfresco server can automatically deploy the workflow on startup when configured to do so. To configure Alfresco to deploy a custom workflow definition, you must include a Spring bean in the Spring configuration to extend workflowDeployer. Consider the following example:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC
'-//SPRING//DTD BEAN//EN' 'http://www.springframework.org/dtd/spring-beans.dtd'>

<beans>

   <bean id="myworkflows.workflowBootstrap" parent="workflowDeployer">
      <property name="workflowDefinitions">
         <list>
            <props>
               <prop key="engineId">jbpm</prop>
               <prop key="location">
alfresco/extension/workflow/my_outline_review_and_approve_processdefinition.xml
               </prop>
               <prop key="mimetype">text/xml</prop>
               <prop key="redeploy">true</prop>
            </props>
         </list>
      </property>
   </bean>
</beans>

Code snippet myWorkflowBootstrap-outline-context.xml

The Spring XML configuration file must be placed in the folder installLocationtomcatsharedclassesalfrescoextension and its name must end with -context.xml (such as myWorkflowBootstrap-context.xml). This allows Alfresco to automatically load this configuration when the server starts.

Each process definition to be deployed must include one <props> element and the following specified properties:

Using the workflow console, you can deploy a process definition directly onto a running Alfresco server. You do not need to restart the server.

With Administrator credentials, you can access the workflow console through the Explorer Web client at the following URL:

On the workflow console, type the following command to deploy a process definition:

deploy <process definition file class path location>

In the Review and Approve example, the process definition file location is installLocationsharedclassesalfrescoworkflowmy_outline_review_and_approve_processdefinition.xml, so the command is:

deploy alfresco/extension/workflow/review_processdefinition.xml

After deploying a process definition either through configuration or using hot deployment, check that the process definition has been successfully deployed to the Alfresco server. To do so, perform the following steps:

You should now see the Start Advanced Workflow Wizard listing all available workflows. If you have successfully deployed your process definition, it will be included in this list. For example, if you have just deployed the example process definition you should see three workflow options (as shown in Figure 7-5).

Figure 7.5. FIGURE 7-5

Note that in addition to the example workflow wf:myReviewAndApprove, there is a workflow called Review & Approve. This is Alfresco's built-in workflow for reviewing content and should not be confused with the example. Do not start the workflow at this point, as the workflow is only partially defined and will cause errors.

Try deploying the example process definition now. Use the Spring configuration method to deploy the outline process definition. Call the process definition my_review_and_approve_processdefinition.xml. Then check that the process definition was deployed successfully.

All task definitions extend the base workflow task definition (bpm:workflowTask). The base workflow task definition has several attributes that are inherited by all other task definitions, as follows:

The start task is defined within the <start-state> of a process definition. All start task definitions must inherit from the base start task (bpm:startTask), which in turn inherits from the base workflow task definition. In addition to the attributes inherited from the base workflow task definition, all start task definitions also inherit the following attributes:

The start task is often used to collect the initializing parameters needed to start a workflow. For instance, the review workflow example uses the start task to specify who will review the article. The start task is automatically assigned to the initiator of the workflow when that workflow starts.

Tasks are frequently used as a way of assigning workflow roles (for example, swimlanes) to participants (people or groups). This is most commonly done through the start task, but such assignments can be made at any point in a workflow. To facilitate these assignments, a set of predefined aspects is provided:

Applying any of these aspects to a task definition as a mandatory aspect automatically adds a component to the task property form on the Explorer Web client. This enables the initiator to easily assign workflow roles to people or groups. Looking at the start task definition for the Review and Approve workflow example, notice that it expects an assignment of a single person to a role (the reviewer in this case).

<type name="wf:mySubmitReviewTask">
         <parent>bpm:startTask</parent>
         <mandatory-aspects>
            <aspect>bpm:assignee</aspect>
         </mandatory-aspects>
      </type>

Many of the attributes defined in the base workflow task definition relate to a package. A package is a space within the Alfresco repository dedicated to storing content associated with the workflow instance. Not only does the task have a reference to the package; it also has properties that define access rights to the package for that task through the package action group property (bpm: packageActionGroup) and the package item action group property (bpm: packageItemActionGroup).

The Explorer Web client uses action groups to specify access rights to the package and its contents. Several out-of-the-box action groups are defined in the web-client-config-workflow-actions.xml file in WEB-INFclassesalfresco/. These are:

Setting the default value of the package item action group to one of these action groups (or a custom action group) alters what actions the Explorer Web client makes available to the user during that task. If the default value is explicitly set to be empty, then no actions are possible.

The base workflow task definition specifies an empty default for the package action group and specifies read_package_item_actions as the default for the package item action group. These defaults are inherited by custom workflow task definitions unless they explicitly override these properties. The base start task overrides these properties, having add_package_item_actions as the default package item action group and start_package_item_actions as the default package action group.

Referring back to the example task model, you can see that the review task definition overrides the package item action groups default and sets it to edit_package_item_actions so that the reviewer can edit the article during the review process.

<type name="wf:myReviewTask">
         <parent>bpm:workflowTask</parent>
         <overrides>
            <property name="bpm:packageItemActionGroup">
               <default>edit_package_item_actions</default>
            </property>
         </overrides>
      </type>

You can access all the attributes specified on a task definition from within the process definition. The majority of these attributes are exposed as task variables. However, a colon (:) is not a legal character in task variable names. Instead, the namespace prefix is followed by an underscore(_). Thus, the task definition attribute bpm:assignee would be available as the task variable bpm_assignee.

A number of attributes on the base workflow task do not relate to task variables, but instead relate to specific properties on the jBPM task instance object. These are described as follows:

The jBPM engine keeps track of data associated with a workflow instance as process variables. Process variables are represented as name-value pairs and persisted as part of the process state. jBPM and Alfresco automatically create several process variables, but you can also define your own variables.

By default, these variables effectively have global scope. It is possible, however, to scope a variable to a specific token, making it accessible by only that token. Tokens are how jBPM keeps track of the execution state of an active workflow instance. Every workflow starts with a single root token; however, more child tokens are spawned every time the process forks. When the process reaches a join, these child tokens are merged back into their parent token.

Many process variables have a data type defined by an Alfresco content model. For some of the simpler types this can be directly translated into a BeanShell type (for example, d:text can be represented as a string). Types that are more complex are represented using the ScriptNode class, described in Online Appendix D.

Alfresco provides several out-of-the-box process variables that are always available, as follows:

Once the start-task is complete, several more properties become available:

To demonstrate process variables in action, the following code snippet defines a variable reviewResult and sets it to either accepted or rejected depending on which path the process execution takes. The variable is set using BeanShell scripts.

<node name="approve">
      <event type="node-enter">
         <script>
            <variable name="reviewResult" access="write" />
            <expression>
               reviewResult = "approved";
            </expression>
         </script>
      </event>
      <transition to="completed" />
   </node>

   <node name="reject">
      <event type="node-enter">
         <script>
            <variable name="reviewResult" access="write" />
            <expression>
               reviewResult = "rejected";
            </expression>
         </script>
      </event>
      <transition to="completed" />
   </node>

You can assign tasks and swimlanes to a user by specifying an <assignment> element inside the task or swimlane to be assigned. In Alfresco workflows, you should use the AlfrescoAssignment class to reference users by user name from the Person service. To do this, add the following attribute and value:

class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment"

The assignment must contain an <actor> element specifying the user name of the user to be assigned. You can also assign a task or swimlane to a group of actors by simply replacing the <actor> element with a <pooledactors> element, and specifying the list of user names to be assigned.

Continuing the review workflow example, the reviewer swimlane is now assigned using the process variable bpm_assignee. This variable is typically used to specify swimlane and task assignments and is usually set by the initiator when the workflow is started.

<swimlane name="reviewer">
<assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
<actor>#{bpm_assignee}</actor>
</assignment>
</swimlane>

The Alfresco JavaScript action lets you embed custom JavaScript into process definitions in much the same way that you can embed BeanShell scripts. To do so, simply add an <action> element with the following attribute:

class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript"

Inside the <action> element, include a <script> element that defines the JavaScript to execute. As with the BeanShell script definitions, this <script> element may optionally contain <variable> elements and an <expression> element if you want to limit access to process and task variables.

The Alfresco JavaScript action exposes the full power of the Alfresco JavaScript API, giving access to several useful services and helper classes. The Alfresco JavaScript action also allows you to run the script as a specific user. To do so, include a <runas> element under <action> and specify a user name as the text body of the element, as follows:

<action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
   <runas>admin</runas>
   <script> ...some script... </script>
</action>

The Review and Approve workflow example can have behavior added that will send an email to the author once an article is either approved or rejected. The text of the email is dependent upon the process variable example_reviewResult. The ActionService is used to send the email.

<action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
   <script>
      var mail = actions.create("mail");
      mail.parameters.to =
         initiator.properties["cm:email"];
      mail.parameters.subject =

"Review Task " + bpm_workflowDescription;
      mail.parameters.from =      bpm_assignee.properties["cm:email"];
      mail.parameters.text =
         "The article has been " + example_reviewResult + ".";
      mail.execute(bpm_package);
   </script>
</action>

For some workflow scenarios, it is necessary to support a fork where the number of paths is only known at runtime, as in a parallel review process where the review task is allocated to an arbitrary number of people for review.

A ForEachFork action supports this functionality, whose behavior is similar to a for loop in Java. An array or collection is supplied to the action, creating one subtoken per element in the array or collection and assigning a different process variable to each subtoken representing one element in the array or collection. Each subtoken is then processed in parallel until it reaches a join node or the end-state. Join nodes merge the subtokens back together just as they would for a standard fork node.

The ForEachFork action takes two parameters, both specified as elements directly under the <action> element. The <foreach> parameter specifies the array or collection over which the action iterates. The <var> parameter specifies the name given to the process variable used to hold the individual elements of the array or collection. The action is specified inside a <node>.

The following code snippet demonstrates how you might use the ForEachFork action as part of a parallel review process where each member of a group, named wf_reviewGroup, reviews an article. An array containing each member of wf_reviewGroup is created using the method people.getMembers. This array is then passed to the ForEachFork action as the <foreach> parameter. A task is created for each member of the array with the reviewer variable set to that member. Finally, a join node merges all the subtokens back together once all group members have reviewed the article.

<node name="forEach">
   <action class="org.alfresco.repo.workflow.jbpm.ForEachFork">
      <foreach>#{people.getMembers(wf_reviewGroup)}</foreach>
      <var>reviewer</var>
   </action>
   <transition name="review" to="review" />
</node>

<task-node name="review">
   <task name="wf:reviewTask">
      <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
         <actor>#{reviewer}</actor>
      </assignment>
   </task>
   <transition name="reject" to="merge" />
   <transition name="approve" to="merge" />
</task-node>

<join name="merge">
   <transition to="completed" />
</join>

Alfresco uses standard Java resource bundles to support localization of the workflow user interface. Alfresco supports title and description definitions for all types defined within the task model, as well as four types associated with workflows. These are described in the following sections.

<model prefix>_<model name>.title
<model prefix>_<workflow name>.description

wf_myReviewAndApproveModel.title
wf_myReviewAndApproveModel.description

<model prefix>_<model name>.{<element>.<element prefix>_<element name>}.title
<model prefix>_<model name>.{<element>.<element prefix>_<element name>}.description

wf_myReviewAndApproveModel.type.wf_mySubmitReviewTask.title
wf_myReviewAndApproveModel.type.wf_mySubmitReviewTask.description

example_reviewModel.type.example_submitReviewTask.property.bpm_status.title
example_reviewModel.type.example_submitReviewTask.property.bpm_status.description

<prefix>_<workflow name>.workflow.title
<prefix>_<workflow name>.workflow.description

wf_myReviewAndApprove.workflow.title
wf_myReviewAndApprove.workflow.description

<prefix>_<workflow name>.node.<node name>.title
<prefix>_<workflow name>.node.<node name>.description

wf_myReviewAndApprove.node.start.title
wf_myReviewAndApprove.node.start.description

<prefix>_<workflow name>.node.<node name>.transition.<transition name>.title
<prefix>_<workflow name>.node.<node name>.transition.<transition name>.description

wf_myReviewAndApprove.node.review.transition.approve.title
wf_myReviewAndApprove.node.review.transition.approve.description

<workflow prefix>_<workflow name>.task.<task prefix>_<task name>.title
<workflow prefix>_<workflow name>.task.<task prefix>_<task name>.description

wf_myReviewAndApprove.task.wf_myCompletedTask.title
wf_myReviewAndApprove.task.wf_myCompletedTask.description

# Review & Approve Workflow
wf_myReviewAndApprove.workflow.title = My Review & Approve
wf_myReviewAndApprove.workflow.description = Review & approval of an article

# Review & Approve Task Definitions
wf_myReviewAndApproveModel.title = My Review And Approve Model
wf_myReviewAndApproveModel.description =
Model for Review And Approve workflow.
wf_myReviewAndApproveModel.type.wf_mySubmitReviewTask.title =
Submit Article
wf_myReviewAndApproveModel.type.wf_mySubmitReviewTask.description =
Submit article for review.
wf_myReviewAndApproveModel.type.wf_myReviewTask.title = Review Article
wf_myReviewAndApproveModel.type.wf_myReviewTask.description =
Review article and Approve or Reject it.
wf_myReviewAndApproveModel.type.wf_myCompleteReviewTask.title = Review Completed
wf_myReviewAndApproveModel.type.wf_myCompleteReviewTask.description =
The review process is complete.

# Review & Approve Process Definitions
wf_myReviewAndApprove.node.start.title = Start
wf_myReviewAndApprove.node.start.description = Start
wf_myReviewAndApprove.node.review.title=Review
wf_myReviewAndApprove.node.review.description=Review
wf_myReviewAndApprove.node.review.transition.reject.title=Reject
wf_myReviewAndApprove.node.review.transition.reject.description=Reject
wf_myReviewAndApprove.node.review.transition.approve.title=Approve
wf_myReviewAndApprove.node.review.transition.approve.description=Approve
wf_myReviewAndApprove.node.rejected.title=Rejected
wf_myReviewAndApprove.node.rejected.description=Rejected
wf_myReviewAndApprove.node.approved.title=Approved
wf_myReviewAndApprove.node.approved.description=Approved
wf_myReviewAndApprove.node.completed.title=Completed
wf_myReviewAndApprove.node.completed.description=Completed
wf_myReviewAndApprove.task.wf_myCompletedTask.title=Completed
wf_myReviewAndApprove.task.wf_myCompletedTask.description=Completed
wf_myReviewAndApprove.node.end.title=End
wf_myReviewAndApprove.node.end.description=End