Workflow Guide
CHAPTER 2
This chapter describes how to get started with workflow and introduces some workflow deign concepts. It includes these topics:
Before you begin to develop a workflow you might want to look at the installed Content Life Cycle application. This workflow follows a document through several activities, including document assignment, authoring, approval, and publishing to the Content Management subsystem. It also uses the installed WorkflowStartProcess portlet and WorkflowQueue portlet to start the process and queue workitems for User activity addressees.
For information about running the application and accessing the sources, see Content Life Cycle Application.
You should get familiar with the Workflow Modeler by opening the Content Life Cycle process or by creating your own process. If you have used the exteNd Director Pageflow modeler, you will find the design environment is similar.
For more information, see Workflow Modeler.
The Workflow subsystem allows you to create two basic flow structures:
In a single-branch structure, the workflow engine forwards a single workitem from one activity to the next until the process finishes. The installed Content Life Cycle workflow is an example of a single-branch flow:
For more complex requirements, you can split the flow to allow for parallel or exclusive work by different process branches. In parallel execution the process follows two or more paths so that different work can be executed at the same time. for example, you might have two documents in the workitem that require different processing. Here is an example of parallel execution:
In this example, it is assumed that work is being forwarded on both branches following the Start activity. In the case of conditional branching like this, you must merge the branches using the Synchronize Merge activity.
Here is how the workflow engine synchronizes multiple branches:
When encountering a split, the engine forwards the workitem to the next activity in each branch, where the link evaluates to true.
The work is processed by each branch activity and forwarded according to the flow logic, until each one reaches the Synchronize Merge activity.
The workflow engine waits until work is completed on all branches and forwards the workitem to the next activity.
This example illustrates how to handle multiple splits. You must merge each split before proceeding to another split:
The next example illustrates two more points:
When your logic dictates that only one of multiple branches will execute exclusively, a Synchronize Merge activity is not necessary.
You can loop back to a split that occurs earlier in the process as long as you return to an activity that is executed before the split.
In this example, it is assumed that the split after the last activity will proceed exclusively to the Finish activity or loop back to the first activity before the split:
For more information, see Synchronize Merge activity.
exteNd Director supports the integration of pageflows and workflows. The Pageflow activity in the Workflow Modeler allows you to specify a pageflow to run as a presentation activity within a workflow. This allows you to incorporate the rich client features of the exteNd Director Pageflow Modeler in your workflow process.
To use a pageflow in a workflow you need to implement these components:
Here is what a Pageflow activity looks like in a workflow process:
Here is what a pageflow that the Pageflow activity points to might look like:
This example shows how you can handle a common requirement in a workflow: allow a user to edit a workitem with the option to forward or not forward but persist the current state of the workitem for another session. For example, one link might be followed when the user selects a Save and Forward button and the other when the user selects Save without Forwarding.
The Workflow Return activity handles the first requirement. To address the second requirement this example uses an HTML activity that does nothing more than close the window:
<script>self.close()</script>
Being able to lock and unlock a workitem for workflow users at runtime is a basic workflow requirement. The workflow API provides lock() and unlock() methods on EbiWorkitemDelegate for this purpose. For pageflows running in a workflow, there are some Flow scope properties you can use to lock and unlock workitems:
The locking and unlocking of work takes place within the pageflow activity. As a rule, you want to lock the workitem when you start the pageflow, and unlock it before the Workflow Return activity is executed.
Suppose you have a Pageflow activity in a workflow calling the pageflow shown above, and you want to lock the workitem when the addressee accesses it from the queue. This is the basic procedure to follow:
NOTE: This section does not describe the mechanics of copying scoped paths in the Workflow Modeler. For more information, see Workflow Modeler. For more information about scoped paths, see the chapter on using scoped paths in Developing exteNd Director Applications
Use Flow/lock to lock the workitem and copy the return value to another location. For example:
Flow/lock ---> Flow/property/lockSuccess
You could do the copy scope before or after the Mode activity.
Test the return value and handle both cases.
If the return value is false, you could display a message that tells the user that the workitem is already locked by another user, as shown in Link 1 in the example
If the return value is true, provide the flow logic that lets the user update the workitem, as shown in link 2. When finished, link to a Workflow Return activity.
Use Flow/unlock to unlock the workitem before it is returned to the workflow. For example:
Flow/unlock ---> Flow/property/unlockSuccess
You could do the copy scope before the Workflow Return activity.
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...