The following topics are covered in this Business Process Design Overview:

• Overview

• About Business Process Option users

• About the Process Flow Model

• Process definitions

Overview

This chapter is a guide or roadmap to designing business processes using the BEA eLink Business Process Option. It includes a discussion of the different parts of the eLink Process Design Assistant.

Business Interface Window

Use the tools in this window to create interfaces to the applications connected through eLink. The various methods for creating these interfaces are discussed in Chapter 3, "Specifying Business Service Contracts." The operations contained within these interfaces are converted into tasks. Then, the tasks are used to form process flows (in the Business Process Window). Only tasks generated from interfaces defined using the Business Interface Window can be used to form process flows that are valid to use in eLink.

Business Process Window

In this window, tasks generated from interface operations are used to form process flows. The various methods for forming these process flows are discussed in Chapter 4, "Designing Business Processes," and Chapter 5, "Making eLink Processes Work."

About Business Process Option users

People who use the Business Process Option and associated tools fulfill several roles. Each role uses specific applications or utilities

This document describes all the tools shown in Table 2-1, except for the Batch Registry utility, which is described in the eLink Business Process Option Administration Guide.

About the Process Flow Model

The following concepts are key to understanding our process flow model.

A process (also known as a job) is a structured activity involving multiple steps.

A process instance is a business activity in action. A process instance is based on a process definition (also known as a template), and one or more instances of a process definition can be active at any time. A process instance is performed by one or more workers. In the Business Process Option, these workers are eLink software agents.

The performance of a process requires:

• Tasks

• Roles

• Pools

Tasks

Tasks in a process are organized into a hierarchy. For example, the task of sending an insurance policy renewal form can be divided into three subtasks:

• Compute new premium

• Notify local office

• Mail form to customer

When a process is run, tasks go through one of these states:

• Waiting means that the Task is not yet Ready.

• In Process means that a worker has acquired the Task.

• Done means that a worker has completed the Task.

• Skipped means that the Task will never be Ready, but tasks that depend on the Skipped task can become Ready.

• Activated means that the Task has been automatically started without being associated with a worker. This state applies only to Tasks with subtasks.

Roles and pools

A role is a local name for a type of worker (software agent or user) to which tasks are assigned. Every process has an Owner role that is responsible for the process as a whole.

One or more tasks are assigned to a role. The role is assigned to a worker or group of workers by associating the role with a pool. Each task is performed by a worker which is a member of the appropriate pool.

Every user must belong to at least one pool. Users can belong to several pools. In order to manage process instances, a user must be a member of the same pool as the eLink agent which started the process.

The eLink Business Process Option's default configuration makes this relatively transparent.

Process instance life cycle

The life cycle stages of a typical process instance are as follows:

1. Process instance creation. An eLink agent starts a new process based on a process definition.

2. Task performance. Tasks are performed in a specified order, and each task is performed by a worker agent who belongs to the pool that is assigned to the task.

3. Process instance completion and archiving. The process is completed when all tasks are finished, and completed process instances are recorded as necessary.

A process definition organizes tasks into a structure that determines when each task is to be performed. eLink directly supports two kinds of process definitions:

• Flat (default)

• Conditional

Flat definitions

In a typical process definition, related tasks have a common parent. It can be convenient to use the common parent as a gateway task.

You can use a parent task as an organizing tool with no real work associated with it. This "flat" model of process organization is implemented through the task AutoActivate property. The model is called flat because effectively it creates a single-level task hierarchy.

Warning: By default, the Business Process Engine turns on the AutoActivate property for all tasks in a process. The eLink Business Process Option relies on this default behavior. You may also turn off the AutoActivate property for individual tasks, separately from the parent process. Tasks with subtasks must have AutoActivate on for the eLink Business Process Option to work properly.

In the flat model, tasks with subtasks start automatically when they become ready to do (they are in the activated state), and complete automatically when all their subtasks are complete.

Figure 2-1 Flat process definition

Conditional definitions

You may also create process definitions where tasks are performed only under certain circumstances — a so called conditional workflow. For example, it might be company policy to send a second billing notice to a customer when an invoice is more than 60 days overdue or process an insurance claim differently if the claim amount is over a million dollars.

Conditional workflows are implemented through perform conditions. A per-form- condition lets you specify a condition to be tested when a task becomes ready to do. The Business Process Engine can then decide whether to skip the task or let it be performed.

Figure 2-2 shows a process definition with two perform conditions (indicated by the letter "P" within the small boxes). If the perform condition on task B is false, that task is skipped. If the perform condition on task D is false, tasks D, F, and G is skipped. Thus, if a skipped task has subtasks, its subtasks are skipped, too.

Figure 2-2 Conditional process definition

You can also implement branching by defining opposite perform conditions on a pair of sibling tasks. For example, you might set up one task so that it is performed when the cost of an item is greater than a thousand dollars, and another task so that it is performed when the cost is less than or equal to a thousand dollars.

Perform conditions test the value of user-defined information called attributes (for more information, see "About attributes" on page 10).

A perform condition consists of an attribute name, an operator (greater than, equal to), and a value. The value can be another attribute. You can create complex perform conditions by combining tests with logical operators, for example:

CUSTOMER_NAME <> 'Kelly' AND COST > 500

MANAGER_APPROVAL = TRUE OR CLAIM_AMOUNT < 100

Table 2-2 shows examples of perform conditions.

Table 2-2 Example perform conditions

Attribute	Operator	Value
COST	>	1000
CLAIM_AMOUNT	<	CLAIM_MAX
CUSTOMER_NAME	=	`Kelly'
INVOICE_DUE_DATE	>	DATETIME(1995-10-21)
MANAGER_APPROVAL	<>	TRUE

Chapter 5, "Making eLink Processes Work" the Working with Conditions section provides complete information on writing perform conditions.

Task dependencies

The process definitions in Figure 2-1, and Figure 2-2 are incomplete without further indication of the task sequence. In any process definition, subtasks become ready to do only after their parent has been started. (Recall that in a flat process definition, parent tasks start automatically.) This means that subtasks are implicitly dependent on their parent task. But what about sibling tasks?

Typically, some sibling tasks must be completed before others can be started. For example, an insurance company is unlikely to pay a claim before the damage has been appraised. In this case, payment is dependent on the appraisal.

In a task structure, you indicate such an explicit dependency by drawing an arrow from the precedent task to the dependent task, as shown in Figure on page 9. The Business Process Option supports explicit dependencies only between sibling tasks with the same parent.

Figure 2-3 Dependency between sibling tasks

When you start a process, The Business Process Engine does not let a dependent task become ready to do until its predecessor task is complete. The task that is parent to both sibling tasks need only be started, not finished, before its first subtask becomes ready to do. These relationships are illustrated in Figure 2-4.

Figure 2-4 Implicit and explicit dependencies

Kinds of task states

Each task in an active process has a state, which indicates whether its work can be performed at the present time. At any time, a task can be in one of these states:

Waiting

A task is waiting if another task must be performed first. No work can be performed on a waiting task. This is a task's initial state.

Ready

A worker can work on the task. However, no worker has yet started working on the task.

Bypassed or Skipped

The task's perform condition indicates that no work should be performed on the task, or the task was manually skipped.

Activated

As a result of a task's AutoActivate property, the task was started automatically and will be completed automatically when all its subtasks are completed.

In Process or Acquired

A worker is working on the task.

Done

The task is completed. No more work can be done on the task.

Much of the information in the Business Process database is stored in the form of attributes. An attribute is information about a process or particular task within a process. Some attributes are built-in; that is, they are predefined for all systems. Others are user-defined. For example, if you were designing an insurance claims process, you might want to add information about the amount of the claim. You can add this information simply by creating a new attribute.

There is a third type of attribute--generated. These are the task attributes that are created (as part of the palette generation process) from operation parameters in the Business Interface Window within the eLink Process Design Assistant.

Built-in and user-defined attributes are used directly to store information during process execution. Generated attributes are used indirectly to tell the eLink Business Process Option agents how to process the information stored in built-in and user-defined attributes. These generated attributes contain parameter assignment expressions rather than business data.

For more information on parameter attributes and how they are used to implement process flows, see Business Process and Task Parameter Attributes in Chapter 5, "Making eLink Processes Work."

All attributes have two parts: a name and a value. When you create an attribute, you specify both its name and value. For built-in attributes, you specify only the value.

Table 2-3 shows examples of built-in attributes.

Table 2-4 shows examples of user-defined attributes.

Table shows examples of generated attributes.

As these examples suggest, attributes can take several kinds of values: integer, string, datetime, and so forth. When you create a new attribute, you indicate what kind of value it can have.

Distinguishing process and task attributes

A process attribute applies to the process as a whole and, therefore, to all tasks that make up the process. When you set a process attribute, its value is the same in every task. Most user-defined attributes are process attributes. There are also built-in process attributes. For example, the process name is a built-in process attribute that you set when you create a process.

A few built-in process attributes are read-only for all users. This means that only the Business Process Option can assign the attribute value. For example, when you start a process, the Time Created attribute is automatically set to the current time.

Task attributes are unique for each task. Many built-in task attributes are provided; some of these are listed in Table 2-3. You cannot create new task attributes during process design.

You can set some task attributes during process design. Others are read-only. For example, you can set the task Due Date attribute when you design (or start) a process. But only The Business Process Engine can set the Time Started attribute when a worker begins to work on a task.

About process ownership

Every active process must have an owner. The process owner typically is responsible for managing the process and monitoring its activity. eLink agents are the owners of all processes within the Business Process Option.

Therefore, to manage a process manually you must become a member of the owner pool. The owner pool is the pool you assign to the root task.

As shown in Figure 2-5, any pool can be the owner pool. If you do not specify an owner pool in the process definition, it defaults to the process initiator's pool.

Figure 2-5 Owner role and owner pool

Creating Business Processes: An Overview

The following flow chart is an overview that describes the step-by-step procedure for forming an eLink process. This is the only correct procedure for forming an eLink process.