Workflow Guide

CHAPTER 1

About Workflow in exteNd Director

This chapter introduces the exteNd Director Workflow subsystem. It includes these topics:

 
Top of page

What is workflow?

Workflow is the automation of a business process, in whole or part, during which documents, information, or tasks are passed from one participant to another for action, according to a set of procedural rules. Workflow can apply to business-to-customer, business-to-business, or internal processes.

Before you decide to implement workflow, your organization might be executing its work manually, with minimal automation if any. By studying the current work, a business analyst can isolate one or more procedures that together achieve an objective of the organization. Workflow designers call this set of procedures a business process.

The figure below shows two business processes: one that models how an organization executes telephone sales orders and one that models the shipping process.

wfBusinessProcess

A business process:

Workflow automates the routing of work from activity to activity according to procedural rules. Work is expressed as a dynamic set of documents (data) associated with data that characterizes the set of documents (metadata). Taken together, the data and metadata are called a workitem. Users can act on the information in the workitem, accomplish tasks, update workitem information, and trigger the continuation of the workitem in the workflow.

The exteNd Director Workflow Subsystem provides the framework and resources for creating and running a workflow application using Java and XML technologies.

 
Top of page

About the Workflow Modeler

The core of a workflow application is the process definition, an XML file that you create visually using the Workflow Modeler. A workflow process is the visual representation of the process descriptor in the Workflow Modeler.

The Workflow Modeler that allows you to quickly and visually create a workflow process. The Workflow Modeler allows you to:

When you save a workflow process, the Workflow Modeler translates it into an XML-based file called a process definition. The process definition saves the layout and format of your workflow and translates the flow logic into a program the workflow engine can read and execute.

 
Top of section

About the workflow process

Here is what a process looks like in the workflow Modeler:

wfProcessExample

Here is a summary of the main features of a workflow:

Process component

Description

Activity

Each process has a set of activities that control the runtime execution of the flow. The Workflow Modeler provides activities that present information to the user and respond to user interactions (User and Pageflow activites in the example above) and system activities that perform background tasks that are not visible to the user (Java activity in the example). Two of the system activities are required in every workflow:

  • Start activity: represents the Workflow subsystem functions necessary to create a new workitem and optionally to assign an initial document to the workitem.

  • Finish activity: represents the Workflow subsystem functions necessary to bring a workflow process to a normal end.

Link

Links are what tie the activities in a workflow together (Links are represented by arrows in the workflow process). A link is a single logical path between two activities. An activity can have multiple source (incoming) links and multiple destination (outgoing) links. The Workflow Modeler provides two types of links:

  • Simple link: allows you to specify expressions that evaluate to true or false. When the expression for a simple link evaluates to true, the link is followed to the next activity.

  • Condition macro link: allows you to specify one or more conditions that are evaluated by the Rules subsystem. When a condition link evaluates to true, the link is followed to the next activity.

Scoped path

Scoped paths is a core exteNd Director feature that provides a syntax for accessing application data. exteNd Director includes a scoped path called flow that lets you access workitem data from the Workflow modeler. The example above shows the Java activity accessing the copy scoped paths feature.

 
Top of page

Workflow subsystem architecture

The Workflow subsystem consists of two principal architectural components, the workflow engine and the workflow queue. These components interact with other workflow components, as shown in this diagram:

Wfarchitecture

Workflow engine   The workflow engine is responsible for executing and managing workflow processes. The diagram shows the execution of a single process instance. The workflow engine uses the process descriptor created with the Workflow Modeler to:

Workflow queue   The workflow queue consists of the queue itself and a queue manager, which coordinates traffic between the workflow engine and workitems.

The queue persists workitems so they can be made available to workflow users. The queue stores workitem instances and data associated with them, such as the addressee (user) and the addressee type (user or security role). When the activity is completed, the queue manager tells the engine to forward the workitem to the next activity. System type activities that do not require user intervention (like Java activities) are not queued: They are executed in line by the workflow engine.

The diagram illustrates a single process instance, but in a real application there are likely to be many processes instances running at any given time. The queue can contain up to the number of active process instances for an activity (assuming that a workitem has reached the activity in each process).

About workitems   The workitem is a container for the application data. It represents the state of the data at any given point in a process instance. In a typical workflow scenario, the workflow engine moves a workitem from activity to activity according to the link logic. (The workitem should not be confused with the data itself, which is typically modified by each activity.)

About the workflow client   The workflow client provides access to the engine, queue and workitems through the workflow API. The diagram shows how a workflow queue delegate (instance of EbiQueueDelegate) accesses queued items for a specified addressee.

NOTE:   exteNd Director includes core portlets for starting the workflow engine and accessing the queue. For more information, see Content Life Cycle Application.

 
Top of page

Workflow and pageflow

It might be helpful to understand workflow by contrasting it with the exteNd Director pageflow model. A workflow and a pageflow are modeled in a similar manner, but a workflow application has some distinguishing features, as shown in this comparison:

Workflow

Pageflow

Process-based

Workflow is a linear business process that might span several days, or even weeks.

Session-based

A pageflow is open-ended and the duration is controlled by a single user.

Definite starting point

Some specific event or condition triggers a process instance. This can be a system-generated event, like a monthly notification, or user-generated.

Designed entry point

The entry point is determined by the flow itself, and is typically not triggered by an external event.

Multiple users

A workflow assumes multiple users are performing discrete tasks at each activity.

Single user

A pageflow application is driven by a single user.

Persistent data

Instance data must be stored outside the session so workitems can be passed to subsequent users.

Session data

A pageflow relies principally on instance data stored in the current session, although the application can access persistent data.

Definite ending point

Some specific event or condition ends the process instance.

User-controlled exit point

The user chooses when to end the session, although some specific action could trigger a work flow.

NOTE:   Although workflow and pageflow are used to build different types of applications, the Workflow subsystem provides facilities for integrating them. See Pageflow in a workflow.

 
Top of page

About the Workflow API

The Workflow API lets clients access workitems and define application logic for Java activities and User Activities. You can also use the APIs to access the engine and queue.Most of the classes for developing business logic are contained in the com.sssw.wf.api and com.sssw.wf.client packages. Here are some key classes:

Interface

Description

EbiWorkitemDelegate

Used by clients to interact with workitems. It provides methods for accessing workitem properties and associated documents, and for locking and unlocking workitems for users or user sessions.

EbiContext

Provides access to the workflow context for process instances.

EbiDocumentManager

Provides access to documents and document properties.

EbiQueueDelegate

Provides operations for accessing, forwarding, and reassigning queued workitems.

EbiWorkflowEngineDelegate

Provides methods for starting a process instance.


EbiJavaActivity

Provides methods for coding a Java Activity.

EbiActivity

Provides methods for accessing the behavior of activities at runtime.




Copyright © 2003 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved.  more ...