![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() | ![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Workflow Guide
CHAPTER 1
This chapter introduces the exteNd Director Workflow subsystem. It includes these topics:
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.
A business process:
Has a definite starting point, or entry conditions—In the telephone sales example, a customer phone call on a workday between 9 a.m. and 5 p.m. makes up a common set of entry conditions. Entry conditions trigger the start of a business process.
Accomplishes an objective of the organization—Executing a sale is the objective of the business process triggered by the phone call.
Can be manual, partially automated, or completely automated—In the shipping process, packing the product could be manual, choosing a carrier could be partially automated, and inventory management could be completely automated. Each step is still part of the business process.
Can be broken down into smaller business processes as necessary—In the sales example, the original Ship Order step could be replaced by the shipping business process.
Has a definite ending point, or defined outputs—For example, perhaps the business process cannot conclude until the customer verifies receipt.
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.
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.
Here is what a process looks like in the workflow Modeler:
Here is a summary of the main features of a workflow:
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:
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.
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:
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.
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:
Copyright © 2003 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...