Workflow Guide
|
|
Workflow Guide |
This chapter introduces basic workflow concepts in the context of the SilverStream eXtend Director Workflow subsystem. It includes these topics:
The Workflow Management Coalition defines Workflow as "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".
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.
Example The figure below shows two business processes: one that models how an organization executes telephone sales orders and one that models the shipping 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 sales example, packing 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.
Workflow and Director applications Director workflow architecture is thoroughly integrated with the Director environment. For example:
You can use Director components and/or JSP pages to create presentation modules for workflow.
You can use the Rule subsystem to provide complex routing logic and behavior.
You can use the Content Management subsystem to store documents used in workflow.
Workflow is just one more important functional area where you can mix and match in Director to create robust Web-based enterprise applications.
The Workflow subsystem provides the plumbing to allow you to create processes out of the business and presentation logic in your Web applications. As shown in the following figure, the Workflow subsystem is comprised of three architectural layers:
Notice the vertical associations among the three layers. A single activity in the engine is associated with zero or more workitems in the queue. A workitem can only be associated with a single activity.
The presentation layer provides the logic and necessary UI for workitems as they move through the queue. Typically, each workitem is associated with a single module of code (or portal component), although this is not a requirement. And each module of code is only concerned with a workitem associated with the current activity.
The top level of the diagram represents the custom business logic and presentation logic unique to your application. This is where you develop your workflow client, which uses the workflow APIs to create and modify workitems. The workflow client provides the UI and necessary logic for processing these items as they move through the workflow queue.
The workflow API allows you to add, change, and delete workitem properties at any activity in the process. The programming patterns for workflow APIs are the same patterns used throughout Director.
The public API for developing the workflow client is contained in the following packages:
For more information, see
Basic Workflow Development.
Customer logic never accesses the workflow engine directly. Between the engine and customer logic is a data persistence layer known as the queue. APIs enable custom code to access the resources of the queue and request engine data and services through the queue. This architecture makes the workflow engine suitable for a wide variety of workflow applications at the department and enterprise levels.
The workflow queue persists workitem data and mediates between workflow clients and the workflow engine. The queue is also responsible for monitoring automatic (or unattended) activities. An automatic activity is logic that is executed in a workflow process without user intervention.
The workflow engine manages and executes workflow processes. Essentially, the engine:
The Director Workflow subsystem is a process-based workflow. A business process is modeled as a series of discrete tasks. A task in a workflow is represented by an activity object. The logic of routing work between activities is modeled by workflow objects called links. In summary, a workflow process is a branching series of activities and links that models a business process.
Integrated into eXtend Workbench is a complete graphing package called Workflow Designer that allows you to quickly and visually create a workflow process. Workflow Designer lets you:
Add automatic activities that execute an unattended task represented by a Java class (no UI)
Set up branching paths based on AND, OR, and XOR (exclusive OR) logic
Save and load workflows into the resource set of Director EARs
When you save a workflow, the Workflow Designer translates your document into an XML-based file called a process definition. The process definition saves the layout and format of your workflow and translates the logic of the layout's flow into a workflow program that the workflow engine can read and execute.
For more information, see
Workflow Designer.
Workflow provides the following runtime administration:
Core workflow administration components for managing the workflow engine, process instances, and workflow activities
Comprehensive exception handling classes with automatic reporting
For more information, see
Workflow Administration.
The Director installation includes a set of core components and sample client applications:
|
Item |
Description |
|---|---|
|
Core components |
Generic Portal components for: |
|
Components that access the Content Management subsystem for: |
|
|
|
|
|
Issue Tracking application |
Uses HTML forms, Portal components and JSP pages. This application introduces core components and basic Workflow concepts |
|
|
|
|
Content Approval application |
Uses core components to access the Content Management subsystem. |
|
|
|
|
Workflow Guide |
Copyright © 2002, SilverStream Software, LLC, a wholly owned subsidiary of Novell, Inc. All rights reserved.
