Bpf Workflow

Siebel Business Process
Framework: Workflow
Guide
Version 8.0
December 2006

Copyright © 2005, 2006, Oracle. All rights reserved.

The Programs (which include both the software and documentation) contain proprietary information;
they are provided under a license agreement containing restrictions on use and disclosure and are also
protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering,
disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability
with other independently created software or as specified by law, is prohibited.

The information contained in this document is subject to change without notice. If you find any problems
in the documentation, please report them to us in writing. This document is not warranted to be error-
free. Except as may be expressly permitted in your license agreement for these Programs, no part of
these Programs may be reproduced or transmitted in any form or by any means, electronic or
mechanical, for any purpose.

PRODUCT MODULES AND OPTIONS. This guide contains descriptions of modules that are optional and
for which you may not have purchased a license. Siebel’s Sample Database also includes data related to
these optional modules. As a result, your software implementation may differ from descriptions in this
guide. To find out more about the modules your organization has purchased, see your corporate
purchasing agent or your Siebel sales representative.

If the Programs are delivered to the United States Government or anyone licensing or using the Programs
on behalf of the United States Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS. Programs, software, databases, and related documentation and technical
data delivered to U.S. Government customers are "commercial computer software" or "commercial
technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific
supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the
Programs, including documentation and technical data, shall be subject to the licensing restrictions set
forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set
forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA,
Inc., 500 Oracle Parkway, Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently
dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup,
redundancy and other measures to ensure the safe use of such applications if the Programs are used for
such purposes, and we disclaim liability for any damages caused by such use of the Programs.

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.

The Programs may provide links to Web sites and access to content, products, and services from third
parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites.
You bear all risks associated with the use of such content. If you choose to purchase any products or
services from a third party, the relationship is directly between you and the third party. Oracle is not
responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of
the agreement with the third party, including delivery of products or services and warranty obligations
related to purchased products or services. Oracle is not responsible for any loss or damage of any sort
that you may incur from dealing with any third party.

Contents

Chapter 1: What’s New in This Release

Chapter 2: Overview of Siebel Workflow
General Principles of Workflow 18
Understanding the Workflow Processes Module 19
Understanding the Workflow Policies Module 21
Workflow Roles 25

Chapter 3: Introduction to Workflow Processes
Overview of the Workflow Architecture 27
Workflow Processes Development Lifecycle 28
Analyzing Process Requirements 28
Defining Workflows 31
Identifying and Building Exception Handling 37
Testing and Troubleshooting Workflows 39
Migrating Workflows to Production 40
Deploying Workflows in Production 42
Monitoring Workflow Execution 42
Design-Time Architecture of Workflow 43
Simulation Architecture of Workflow 45
Deployment Architecture of Workflow 46
Run-Time Architecture of Workflow 47
Workflow Interaction with Other Siebel Components 52

Chapter 4: Planning Workflow Processes
Gathering Information for Workflow Process Planning 55
Understanding Workflow Process Requirements 56
Seeded Workflow Processes 57
Considering Business Objects and Business Services When Planning Workflow
Processes 57
Defining a Primary Business Component for a Business Object 57
Enabling a Business Service for Workflow Processes 58

Siebel Business Process Framework: Workflow Guide Version 8.0 3

Contents ■

Defining a Test and Migration Strategy for Workflow Processes 58
Verifying Workflow Policies Installation 59
Verifying the Repository Setting for Workflow Policies Installation 59
Verifying the Workflow Setup for Workflow Policies Installation 59
Upgrading Siebel Workflow 60

Chapter 5: For Developers: Basics of Building Workflow
Processes
Overview of Developing a Workflow Process 61
Siebel Tools and Workflow Processes 62
Using Process Designer in Siebel Tools 64
About the Design Functions of the Process Designer 64
About the Multi Value Property Window 65
Field Descriptions: Workflow Processes 66
Field Descriptions: Process Properties for Workflows 71
Process Designer Palette Items 73
About Defining Workflow Process Parameters and Steps 75
Reviewing Existing Workflow Processes 76
Defining a New Workflow Process 76
Naming Conventions for Workflow Processes, Steps, Branches, and Process Properties
77
Modifying Existing Process Definitions 78
Tutorial: Using Process Designer in Siebel Tools 79

Chapter 6: For Developers: Workflow Process Steps
About the Workflow Processes OBLE in Siebel Tools 89
Diagramming a Workflow Process 90
Defining Step Details for a Workflow Process 91
Deleting a Workflow Step 92
Deleting a Workflow Process 92
Copying a Workflow Process 92
About Process Properties 93
Process Properties Versus Property Sets 95
Passing Property Sets by Reference 96
Defining Process Properties 96
Concatenating Process Properties 97
Passing Process Properties In and Out of Steps 98
Field Descriptions for Defining Workflow Process Steps 99
Field Descriptions: Workflow Steps 99

4 Siebel Business Process Framework: Workflow Guide Version 8.0

Contents ■

Field Descriptions: Workflow Branches 102
Field Descriptions: Compose Condition Criteria Dialog Box 105
About Start Steps 107
Defining a Start Step 107
Defining Next Step Branches for Start Steps 108
About Conditions and Values 108
Building Expressions with Expression Builder 109
About Decision Points 112
Defining a Decision Point 113
Defining Decision Branches 113
About Conditions and Values for Decision Points 114
About Business Service Steps 114
Field Descriptions: Input Arguments for Business Service Steps, Subprocess Steps, and
Wait Steps 115
Field Descriptions: Output Arguments for Business Service Steps, Subprocess Steps, and
Siebel Operation Steps 116
Defining a Business Service Step 118
Defining Input Arguments for Business Service Steps 119
Defining Output Arguments for Business Service Steps 119
Enabling the Pass By Reference Feature for Business Services That Support It 119
About Subprocess Steps 120
Field Descriptions: Step Recipients 120
Field Descriptions: Subprocess Steps 121
Defining a Subprocess Step 122
Defining Input Arguments for Subprocess Steps 122
Defining Output Arguments for Subprocess Steps 123
Defining Recipients for Subprocess Steps 123
Enabling a Subprocess to Support Pass By Reference 123
About Siebel Operation Steps 124
Defining a Siebel Operation Step 125
Defining Fields for a Siebel Operation Step 126
Defining Siebel Operation Search Specifications 126
Defining Siebel Operation Step Output Arguments 127
Field Descriptions: Search Specifications 128
Updating a Field Based on a Multi-Value Group 129
Traversing a Record Set 129
About Wait Steps 130
Defining a Wait Step 130
About User Interact Steps 131
Defining a User Interact Step 132


Contents ■

Defining User Interact Next Step Branches 133
About Conditions and Values for User Interact Next Step Branches 133
Creating Substitute View Names with Process Properties 134
About Task Steps 134
Defining a Task Step 134
About Stop Steps 137
Defining a Stop Step 138
Defining Stop Step Input Arguments 138
About End Steps 139
Defining an End Step 139

Chapter 7: For Developers: Understanding How Workflow
Processes Are Designed
About Workflow Modes 141
About 7.0 Workflow Processes 143
About Long-Running Workflow Processes 143
About Interactive Workflow Processes 144
About Service Workflow Processes 144
Building Long-Running Workflow Processes 145
Assigning Subprocesses to End Users to Create Collaborative Long-Running Workflows
145
Configuring Long-Running Workflows to Invoke Tasks 146
Building Interactive Workflow Processes 146
Creating Synthetic Event Buttons to Control User Navigation 147
About Suspension and Resumption of Interactive Workflow Processes 151
About Forward and Backward Navigation between Views 153
Using Workflow Persistence 154
About Workflow Persistence 154
Enabling Workflow Persistence 155
Handling Events 155
Using Run-Time Events 155
About the Workflow User Event Business Service 157
Generating User Events with the User Event Business Service 158
Configuring Long-Running Workflow Processes to Wait for User Events 159
Workflow and Global Implementations 159
Configuring Workflows in a Multilingual Environment 159
Defining Expressions for Workflows Running in a Multilingual Environment 160
Wait Steps and Global Time Calculations in Workflow 160
Handling Errors 161


Contents ■

Using Error Processes to Handle Errors 161
Passing User-Defined Process Properties and Property Sets to Error Processes 162
Assigning Error Processes to Subprocesses 162
Using Exceptions to Handle Errors 163
Defining Exceptions 163
Recovering Workflow Processes 164
Automatic Recovery of Workflow Process Instances 164
Manual Recovery of Workflow Process Instances 165
Invoking Workflow Processes 165
About Invoking a Workflow Process 165
Invoking a Workflow Process from a Workflow Policy 166
Invoking a Workflow Process from a Script 167
Example: Invoking a Workflow from a Script in Object Manager 168
Example: Invoking a Workflow from a Script to Pass Field Values to Process Properties
168
Invoking a Workflow Process from a Run-Time Event 169
Invoking a Workflow Process through a Configured Business Service 170
Running a Workflow Process in the Workflow Process Manager 171
Running a Workflow Process in the Application Object Manager 172
Running a Workflow Process in Batch Mode 172

Chapter 8: For Developers: Testing Workflow Processes
Using the Validate Tool to Correct Errors in Workflow Processes 175
Testing Workflow Processes with the Process Simulator 176
About the Process Simulator and Supported Modes for Simulation 177
Running the Process Simulator 178
Troubleshooting Workflow Process Simulation 180
Testing Workflows That Involve Server Components 180

Chapter 9: For Administrators: Administering Workflow
Processes
About Deploying Workflow Processes 181
Deploying Workflow Processes 182
Deploying Workflow Processes to Mobile Clients 184
Restricting Mobile Client Routing 184
Deploying Workflow Processes on Regional Nodes 184
Migrating Workflow Processes from Development to Production 185
Importing or Exporting a Process Definition 187
Administering Workflow Processes in the Run-Time Client 188


Contents ■

Viewing Run-time Instances of a Workflow Process 190
Stopping a Workflow Process Instance 190
Stopping All Workflow Process Instances of a Specific Process Definition 190
Deactivating a Workflow Process Instance 191
Expiring a Workflow Process Instance 192
Purging a Workflow Process Instance from the Log 192
Activating Fields Used by Workflow Processes 193
Monitoring and Troubleshooting Workflow Processes in Production 193
About Workflow Process Monitoring 193
Setting Workflow Process Monitoring Levels 195
Setting Tracing and Event Log Levels 196
Capturing Data with Siebel Application Response Management (Siebel ARM) 197
Recording Behavior with Siebel Flight Data Recorder (FDR) Files 198
Troubleshooting Workflow Processes in a Production Environment 198

Chapter 10: Workflow Policies
About Planning Workflow Policies 203
Planning Workflow Policy Groups 203
Planning Workflow Policies 204
Determining What to Monitor When Planning Policies 205
Planning Policies and Conditions 205
Planning Workflow Policy Actions 206
Scenario for Planning Workflow Policies: Notification for 30%+ Discounts 206
Scenario for Planning Workflow Policies: Notification for Large Number of Open Service
Requests 208
Defining a Test and Migration Strategy for Workflow Policies 209
About Creating Workflow Policies 209
About the Workflow Policies Views 210
Defining Workflow Policy Actions 210
About the Actions Applet in the Workflow Policies Action View 211
About the Arguments Applet in the Workflow Policies Action View 211
Using the Send Page Program Type 212
Using the Send Message Program Type 213
Using the Message Broadcast Program Type 214
Using the Run External Programs Type 215
Using the Database Operation Program Type 215
About the Recipients Applet 217
Creating a Workflow Policy Action 218
Example of a Workflow Policy Action: Creating a Send Page Action 219
Example of a Workflow Policy Action: Creating a Send Email Action with a Repeating
Message 220


Contents ■

Example of a Workflow Policy Action: Creating a Send Message Broadcast Action 221
Example of a Workflow Policy Action: Creating a Database Operation Action 222
Example of a Workflow Policy Action: Creating a Run External Program Action 222
Creating Workflow Policy Groups 224
About the Workflow Groups Applet 225
About the Workflow Policies Applet 225
Creating Workflow Policies 225
About the Policies List Applet 228
About the Conditions Applet 229
About the Actions Applet 233
Example of a Workflow Policy: Creating a Send Page Workflow Policy 234
Example of a Workflow Policy: Creating a Send Email Workflow Policy 234
About Customizing Workflow Policies with Siebel Tools 235
Siebel Tools and Workflow Policies 236
Siebel Tools Definitions in the Workflow Policies Views 237
About Workflow Policy Objects 238
Creating a Workflow Policy Object 238
Workflow Policies and the Siebel Tools Views 239
About the Workflow Policy Column List View 240
Configuring a Workflow Condition Based on a Foreign Key 241
About the Workflow Policy Object List View 242
About the Workflow Policy Component List View 242
About the Workflow Policy Component Columns View 244
Defining a Workflow Policy Column 245
Defining a Workflow Policy Component 246
Defining a Workflow Policy Object 246
Modifying Policy Column Names 247
Adding Policy Columns to a Workflow Policy Object 247
Associating a Column with a Workflow Policy Component 248
About the Validate Tool in Siebel Tools 248
Modifying an Existing Workflow Policy Object 248
About Workflow Policy Programs 251
About the Program List View 252
About the Workflow Policy Program Argument List View 252
Creating a Workflow Policy Program 256
Example of Creating a Workflow Policy Program Argument: Send Opportunity Email 258
Creating SQL Statements for Workflow Policies Program Arguments 258
About Predefined Workflow Policy Programs 259
Example of Using a Predefined Workflow Policy Program: Change SR Close Date to Today
259
Example of Using a Predefined Workflow Policy Program: Change SR Owner 260


Contents ■

Example of Using a Predefined Workflow Policy Program: Change SR Owner to Manager
261
Example of Using a Predefined Workflow Policy Program: Send Quote Page 262
Making Object Types Available in the Siebel Client 263
About Workflow Policies Server Administration 263
Creating Database Triggers 263
About Database Triggers and Database Administration 265
Running Generate Triggers 266
Running the SQL Script File 267
About Database Triggers and Remote Users 268
Setting Up the Siebel Server for Email Manager 268
Setting Up the Communications Profile to Send Email through Workflow 268
Starting Email Manager 269
Setting Up the Siebel Server for Page Manager 270
Troubleshooting the Email and Page Managers 272
Executing Workflow Policies with Workflow Monitor Agent 273
Using Workflow Monitor Agent 275
Using Workflow Action Agent 281
Starting Workflow Agent Processes Automatically with Siebel Server 283
Deleting Expired Workflow Policies 283
About Workflow Policies and Siebel Server Task Trace Files 285
Viewing Trace Files in Siebel Server Administration 285
Viewing Trace Files in the Siebel Server Log Directory 286
About Tracing and Event Log Levels 286
About Workflow Policies Analysis Charts and Reports 286
Using the Policy Frequency or Trend Analysis Chart 286
Using Workflow Policies Reports 287
About Workflow Policies and Siebel Marketing 287
Using Workflow Policy Programs for Campaign Execution 287
Using the Send Campaign Email Workflow Policy Program 288
Using the Create Email Activity Workflow Policy Program 288
Using the Assign to Campaign Workflow Policy Program 289
Scenario for Creating a Marketing Campaign with Workflow Policies 289
About Testing Workflow Policies 292
Testing New Policies and Monitoring the Results 293
Troubleshooting Workflow Policies 293
Workflow Policies and Tracing 294
Migrating Policies to the Production Environment 294
Predefined Programs 295


Contents ■

Chapter 11: Reference Materials for Siebel Workflow
Siebel Workflow Terminology 298
Examples of Creating Workflow Processes 301
Example: Attach an Activity Plan to an Opportunity and Test with the Process Simulator
and the Run-time Client 301
Example: Creating a Workflow Process Triggered by a Run-time Event 313
Example: Creating a Service Flow Workflow 316
Example: Run-time Event Workflow with User Interact Step to Navigate the End User to a
View 321
Example: Externalize Parameters to be Used by Siebel Workflow 324
Predefined Business Services 328
FINS Data Transfer Utilities Business Service 329
FINS Validator Business Service 329
FINS Dynamic UI Business Service 329
Outbound Communications Manager Business Service 329
Report Business Service 329
Synchronous Assignment Manager Requests Business Service 329
Server Requests Business Service 330
Workflow Utilities Business Service 333
Workflow Administration Service 333
Passing Parameters to and from Workflow and Data Manipulation within Workflows
336
Manipulating Data Within Workflows 336
Passing Parameters to and from Workflow with the Workflow Process Manager Business
Service 339
Example Script: Invoking Workflow Programmatically and Constructing an Input Property
Set 340
Example Script: Defining Property Sets for the Input Property Set 340
Example Script: Constructing Property Sets 340
Example Script: Assembling Properties and Child Property Sets into the Input Property Set
341
Example Script: Invoking the Workflow Process Manager Business Service and Passing It
the Input Property Set 341
Passing Parameters from Workflow to Global Variables (Profile Attributes) 342
Using Expressions with Workflow Processes 342
Using the Timestamp Argument 343

Index


Contents ■


1 What’s New in This Release

What’s New in Siebel Business Process Framework: Workflow Guide,
Version 8.0
In this release, the title of this guide has been changed to Siebel Business Process Framework:
Workflow Guide from its previous title of Siebel Business Process Designer Administration Guide.

Table 1 lists changes described in this version of the documentation to support release 8.0 of the
software.

Table 1. New Product Features in Siebel Business Process Framework: Workflow Guide, Version
8.0

Topic Description

Multiple-Document Interface Oracle’s Siebel Tools is now a multiple-document interface
(MDI) application. This means that when you use Siebel Workflow,
you can have multiple object editors open at any given time
See Using Siebel Tools.
displaying not only workflow processes, but other objects as
well.

Debug toolbar This toolbar contains buttons that let you access Siebel VB
and Siebel eScript debugging tools. The relevant button for
Siebel Workflow is the Watch button that lets your monitor
the contents of program variables in the Variable window
when simulating a workflow from Siebel Tools.

WF/New Task Editor toolbar In this release, you can use the debug toolbar to publish,
activate, revise, and expire workflows/tasks.
Automatic Revisions Workflow and task configuration options that ensure you are
See Using Siebel Tools. working on the most current workflow/task version.

Three-way merge for upgrades Siebel Tools now supports three-way merge during upgrades
for Workflow objects. This merge makes sure that the
See “Upgrading Siebel Workflow” on
customer's extensions to these objects carry forward to the
page 60.
new version.

Multi-value Properties Window In this release, the Multi-value Properties Window (MVPW)
replaces the list applet in most cases within the Siebel Tools
See “About the Multi Value Property
side of the Business Process Designer. You use the MVPW to
Window” on page 65.
view, create, and delete process properties to store data for
a workflow process. You can also create, delete, and assign
input/output arguments for a process step.

The MVPW is context-sensitive; it displays the appropriate set
of properties based on the object selected.


What’s New in This Release ■

8.0

Topic Description

State Management Type field In this release, a new feature for Siebel Order Management—
setting required for all Web Channel session state management—requires that all
workflow processes business services are marked with a setting describing the
Object Manager client-session mode when making a request
See “Field Descriptions: Workflow
to the Siebel server.
Processes” on page 66.
Because the Workflow engine is a business service, this new
For more information on the Web
feature means the addition of a new property field, called
Channel session state
State Management Type, for all workflow processes. By
management feature, see Siebel
default, this property is set to Stateless. You can set this field
Web UI Dynamic Developer Kit
to indicate whether a workflow process is stateless or
Guide.
stateful.

Strongly typed integration This is a new data type for defining process properties specifically
object data type used by web services. Strongly typed objects allow you more
functional scripts and better performance.
See “Field Descriptions: Process
Properties for Workflows” on
page 71.

Process Designer naming Siebel Workflow automatically assigns a name and sequence
conventions for workflow steps number to each step and connector that you create within a
and branches workflow process. The name given is based on the type of
step or connector. The sequence number differentiates
See “Naming Conventions for
instances of the same type of step or connector.
Workflow Processes, Steps,
Branches, and Process Properties” When a new step of the same type is added to the workflow,
on page 77. if there is a gap between the sequence numbers for the type
(gaps can be created when steps are deleted), the first
sequence number in the first gap interval for the step type
will be the sequence assigned to the new step.

Pass By Reference feature Subprocess methods tasked with modifying large amounts of
data must copy large quantities of data. This can negatively
See “Passing Property Sets by
impact performance and scalability of these method
Reference” on page 96.
invocations. Pass By Reference is a feature that allows you to
avoid passing large property sets, by passing just a pointer
to the property sets. This feature employs a new user
property, Business Service User Prop, which is represented by
a new child object of the Business Service object.

Enhancement to Subprocess Subprocesses now support passing property sets by
step reference with a new Workflow Process attribute called Pass
By Ref Hierarchy Argument. This attribute specifies whether
See “Enabling a Subprocess to
subprocesses within the workflow process are enabled for use
Support Pass By Reference” on
with the Pass By Reference feature. The default setting is
page 123.
FALSE.



8.0

Topic Description

New operation types In this release, the following operations were added: Delete,
NextRecord, PrevRecord, and QueryBiDirectional.
See “Defining a Siebel Operation
Step” on page 125.

Task step The Task step has been introduced to accommodate the new
Siebel Task UI feature in this release, which is integrated with
See “About Task Steps” on
Siebel Workflow. You use the Task step to launch tasks from
page 134.
within a workflow process.
For information on the new task
feature, see Siebel Business
Process Framework: Task UI
Guide.

Improved Process Simulator The Watch window allows you to see object and variable
Watch window values during simulation. In this release, if the variable is
editable, you can update it in the Watch window to feed a
See “About the Process Simulator
value to the simulation.
and Supported Modes for
Simulation” on page 177.

Application Deployment ADM is an automated deployment framework that provides a
Manager (ADM) enhancements mechanism to migrate enterprise customization data (views,
responsibilities, assignment rules, and so on) from one Siebel
See “Migrating Workflow Processes
application environment to another.
from Development to Production”
on page 185. In this release, workflow processes and workflow policies are
data types newly available for migration through ADM. Using
See “Migrating Policies to the
ADM, you can perform bulk migration and activation of
Production Environment” on
workflows, and you can migrate policies in batch as well.
page 294.

Also see Siebel Application
Deployment Manager Guide.

Workflow Admin Service Business A new business service that allows you to perform batch
Service import/export, deployment, and activation of multiple
workflow processes by way of a search specification.
See “Migrating Workflow Processes Alternatively, you can perform client-side batch activation
from Development to Production” and expiration by way of the File menu in the application.
on page 185.

New child views in the In the enhanced Workflow Deployment view (Administration -
Workflow Deployment view Business Process), administrators can now view the parent-
child relationship between a workflow process definition and
See “Administering Workflow
its run-time records.
Processes in the Run-Time Client”
on page 188. Administrators can use the multi-select function in the list
views to perform activation, deletion, and expiration of
workflow processes in batch.


2 Overview of Siebel Workflow

This chapter provides a conceptual overview of Siebel Workflow. Siebel Workflow is a customizable
business application that allows you to define, manage, and enforce your business processes—
creating process automation within the Siebel application.

Siebel Workflow orchestrates the various Siebel process-automation technologies. Workflow
processes graphically sequence a series of automation steps that support a process, and they specify
inputs and outputs for individual steps and for the process as a whole.

Using Siebel Workflow to manage business processes in your organization, you can address such
challenges as:

■ Automating escalation of events and notification of appropriate parties

■ Routing and assigning work

■ Processing work

■ Enforcing authorization and transition rules

This chapter is organized as follows:

■ “General Principles of Workflow” on page 18

■ “Understanding the Workflow Processes Module” on page 19

■ “Understanding the Workflow Policies Module” on page 21

■ “Workflow Roles” on page 25

Siebel Workflow and Process Automation
Siebel Workflow brings together Workflow Processes and all other repository configuration objects,
including the Workflow Policies module, for creating a comprehensive workflow design. The process-
automation technologies in Siebel include:

■ Workflow Processes. Allows you to define your company’s business processes using a familiar
flowcharting interface. A workflow process consists of one or more process steps such as start
steps, subprocesses, decision points, and tasks. Workflow Processes is the key technology behind
building business processes in the Siebel application.

■ Workflow Policies. Allows you to define policies that can act as triggers to execute a process.
A policy consists of conditions and actions. When policy conditions are met, the policy action
executes the relevant process. Workflow Policies generates events based on database operations.
Workflow Policies is effective for performing simple actions such as sending email, or creating an
activity or assignment.


Overview of Siebel Workflow ■ General Principles of Workflow

■ Tasks. Allows you to create wizard-like user interfaces with multiple-step, interactive operations
that can include branching and decision logic to guide end users through task execution. Siebel
Task UI allows navigation both backward and forward within task execution, and allows task
execution to be paused and resumed as needed.

For more information about Siebel Task UI, see Siebel Business Process Framework: Task UI
Guide.

■ Assignment Manager. Expresses rules to assign records to people. Enables assignment of
records based on skills, workload, and availability. Supports ownership transitions within a
process. For more information on Assignment Manager, see Siebel Assignment Manager
Administration Guide.

■ SmartScript. Guides users through data-entry activities. SmartScript is effective for call
scripting and includes basic support for transaction-level commits. For more information on
SmartScript, see Siebel SmartScript Administration Guide.

■ Activity Template. Provides a pre-defined series of steps to be completed. Activity Template is
effective for handling asynchronous/offline work. For more information on Activity Template, see
Siebel Applications Administration Guide.

■ State Models. Restricts transition of record status based on a current value and the position of
the user. State Models can also enforce directional progression of status, so that, for example,
Opportunities move forward but not backward through a pipeline. For more information on State
Models, see Siebel Applications Administration Guide.

While each of the above technologies provide specific functionality to allow business-process
automation in the Siebel application, it is Workflow Processes that orchestrates many of the services
the technologies perform. A workflow process orchestrates services either by directly invoking each
technology, or by interacting with the other technologies through the Siebel event model.

General Principles of Workflow
In theory, businesses are managed according to policies and procedures that allow efficiency, quality
service, adherence to contractual agreements, and profitability. These policies enforce business
processes such as:

■ Allowing that response time objectives are met for customer callbacks and open service requests

■ Specifying review policies for important processes like contracts, quotes, or product shipments

■ Monitoring service requests or opportunities over time

In practice, the benefits of policies often are not realized because policies are not consistently
enforced. This may be because of the large number of processes or because of the dynamic nature
of the information being monitored.

The management of important events is central to the enforcement of business workflow. Workflow
is the timely management of an event to allow proper handling. For example, service departments
have procedures for managing an open service request or making sure that response times are met.
A workflow can increase the visibility of these processes within an organization and check that they
are correctly handled.



Service departments have sets of defined rules that match their policies and service agreements such
as:

■ Standards for processing calls. For example, when a Severity 1 call is assigned, the new
owner is automatically paged.

■ Contracted service agreements that must be adhered to. For example, customers may
purchase a support agreement guaranteeing a callback in two hours and problem resolution in
four hours.

Sales departments also have rules to enforce desired business practices, such as:

■ Discount authority. If a sales representative quotes a discount exceeding the maximum
discount allowed, it requires the approval of the district sales manager or VP of Sales.

■ Pipeline management. Each sales representative manages his or her pipeline to ensure
sufficient levels of prospects at each stage of the sales cycle. If an area of the pipeline needs
attention, the representative or manager should be alerted.

■ Forecasting accuracy. Opportunities that are forecasted but never closed or forecasts having
wide discrepancies with the actual revenue need to be flagged.

Understanding the Workflow Processes Module
Workflow Processes is the module in Siebel Workflow that you use to create and administer workflow
processes.

Workflow Processes Configuration Overview
Workflow Processes allows you to define your company’s business processes using the Process
Designer in Siebel Tools. Hosting the Process Designer in Siebel Tools provides an integrated
development environment to configure Workflow along with other Siebel objects. This integrated
development environment allows a top-down development framework for building business logic,
starting with the creation of a workflow process, then providing pluggable services and data objects
that make the process executable.

You define a process that consists of process steps such as Start steps, Decision Points, Subprocess
steps, or Business Service steps to complete work. Work can be completed with either a predefined
business service or a custom business service. Predefined actions include updates to the Siebel
database, notifications (such as an email or page), integration messages to external systems, and
calls to invoke server tasks. Custom actions can be defined by using Siebel VB or Siebel eScript.

Workflow Processes Administration Overview
Workflow Processes can vary from a simple process such as entering a product order to a complex
process such as managing call center workflow. Complex processes can comprise multiple smaller
processes.

Workflow Processes are administered through the Administration - Business Process views in the
Siebel Client. Instructions for accessing and using the Administration - Business Process views are
in Chapter 9, “For Administrators: Administering Workflow Processes.”



Invoking Workflow Processes
Workflow processes can be invoked from events in the Siebel application or from external systems.
Within the Siebel application, a process can be invoked from a workflow policy, an event (such as an
insert of a record or a button click), or a server component.

From an external system, processes can be invoked using COM or CORBA. For information on
invoking a workflow process, see “About Invoking a Workflow Process” on page 165.

Sample Workflow Process Scenario
To help you understand how the Workflow Processes module works, see the usage scenario
“Scenario: New Service Request”. You can view sample workflow processes in detail by selecting the
project Workflow - Samples in Siebel Tools.

Scenario: New Service Request
Prior to implementing Siebel Call Center, ABC Computing found itself unable to resolve many
customer issues in a timely manner. To better track and manage service requests, ABC implements
the Service Request module and automates the company’s service-request management process.

The goal is to meet a service-level agreement (SLA) commitment by making sure that all newly-
logged service requests (SRs) are resolved within a specific amount of time. ABC Computing wants
the SRs to be assigned by the system to the best representative based on availability and matching
skills. If the SR needs immediate attention, the company wants to notify the owner of the SR.

This automation is achieved using Siebel Business Process Designer. When an SR is logged, a
workflow process is triggered. The workflow process calls Siebel Assignment Manager to assign the
SR to the best available service representative. Based on the severity of the SR, Workflow might then
send email notification to the representative, using Siebel Communications Server. Automating this
process helps ABC Computing achieve faster turnaround time to resolve SRs and meet the company’s
SLA commitment.

ABC Computing defines its business process for a new service request with the Process Designer.
Figure 1 on page 21 illustrates a diagram of the process as drawn in the Process Designer.

The diagram demonstrates the steps and decision points involved when a new service request comes
into the organization. The steps and decision points are displayed in the diagram in such a way that
the flow of the work is clear.

NOTE: The steps explained below are not generic; they refer specifically to the workflow process
illustrated in Figure 1 on page 21.

Each step is interpreted as follows:

■ Start. This is the start step initiating the process instance. The work item is the new service
request.

■ Assign Service Request. This is a subprocess action. The service request is assigned to the
appropriate agent based on the assignment rules defined in the Assign Service Request
subprocess.

■ Severity. This is a decision step. The service request severity determines the next step in the
process instance of the three possible paths: Critical, High, or Medium.



■ Send Email. This is an automated business service action. If the service request priority is
critical, an email is sent to the assigned agent. This action calls the Outbound Communications
Manager business service.

■ Priority High. This is a Siebel Operation update action. This step updates the service request
priority to High.

■ Substatus Assigned. This is a Siebel Operation update action. This step updates the sub status
to Assigned.
■ Email Error Activity. This is a Siebel Operation insert action. This action is triggered if an error
is returned in the Send Email action.

■ Priority Very High and Dispatch. This is a Siebel Operation update action. This step changes
the service request priority to Very High and the substatus to Dispatch.

■ End. This step defines the completion of the process.

Figure 1. New Service Request Workflow Process

Understanding the Workflow Policies Module
The Workflow Policies module allows you to define policies that can act as triggers to execute a
workflow process.

NOTE: The name Workflow Policies replaces the name Workflow Manager, which was used to refer
to the Siebel Business Process automation tool in earlier releases.

A policy consists of one or more policy conditions. When the policy conditions are met, the policy
action is executed.

NOTE: A number of the functions available with Workflow Policies can be supported using Workflow
Processes. It is recommended that Workflow Policies be used to define conditions for invoking
workflow processes. Use Workflow Processes for defining the actions.



Workflow Policies Structure
The basic underlying construct of Workflow Policies is the rule. The structure of a rule is: if all
conditions are true, then an action occurs. The rule contains a policy condition and a policy action.
This means when the conditions of the workflow policy are met, an action is triggered.

A workflow policy represents the rules the database monitors. A workflow policy, based on the
Workflow Policies rule structure, is composed of conditions and actions. A workflow policy condition
is a trigger—a circumstance or situation that causes something to happen. A workflow policy action
is an action invoked by a policy condition being fulfilled. You can also have a duration, which is the
period of time for which all policy conditions exist for the conditions of the policy to be met.

Workflow Policy Conditions
A policy condition expresses an object/attribute relationship to a value. For example, a policy
condition may target data such as Service Request Severity. The policy condition compares that data
to a value, such as 1-Critical. The combination of the data element (Service Request Severity), a
comparison operation (=), and the value (1-Critical) make up the policy condition.

The fact that a Service Request Severity is 1-Critical may be an issue only if the policy condition
remains valid for some extended period of time, such as two hours. If this is the case, a duration can
be set for two hours on the workflow policy. The duration becomes part of the policy condition. The
policy actions are not executed until the policy conditions are met for the specified duration.

Policy actions can also occur when time duration is not set. For example, email is automatically sent
to a sales manager each time a sales representative quotes a discount rate exceeding 25 percent on
revenue less than $100,000.

Policies frequently have more than one condition. All the conditions of the policy must be met before
an action can occur. A service request with a severity of 1-High and a duration of two hours may be
important only if another comparison is also valid, such as the Service Request Status is Open. The
policy condition becomes the combination of these two comparison operations:

SR Severity = 1-Critical AND SR Status = Open

Siebel Workflow Policies supports only AND linkages between policy conditions, not OR linkages. If
you need to monitor the SR Severity to be 1-Critical or 2-High and the SR Status is Open, you can
use the IN operand to evaluate the OR of the SR Severity Condition.

SR Severity IN (’1-Critical’, ’2-High’) AND SR Status = Open

Alternatively, OR linkages can be simulated by creating multiple policies for each key policy
condition. The combination of workflow policies will act like an OR linkage. For more discussion on
comparisons, see “Using Comparison Values in the Conditions Applet” on page 229.

Workflow Policy Actions
A workflow policy action contains two parts: the action and the action parameters. An action is a type
of request, such as “Send an Urgent Page.” Action parameters are the arguments, such as the name
of the recipient of the page and the alphanumeric text transmitted with the page.



You can specify several actions for one workflow policy, such as sending a page to one person and
an email to another. You can reuse actions in multiple workflow policies. See “About Customizing
Workflow Policies with Siebel Tools” on page 235 for a discussion of actions and their parameters.

NOTE: In most cases, use workflow policy actions to run a workflow process.

Figure 2 illustrates the key parts of a workflow policy.

Figure 2. Key Parts of a Workflow Policy

Workflow Policy Action Program Types
Workflow policy actions are based on underlying predefined programs in Siebel Tools and inherit all
the arguments of the program. Workflow policy action programs can be one of the following types:

■ Send Message. A program of this type sends an email to one or more recipients.

■ Send Page. A program of this type sends a page to one or more recipients.

■ Send Message Broadcast. A program of this type inserts a message broadcast for one or more
recipients.

■ DB Operation. A program of this type either inserts or updates the data records of a Siebel
database table for selected workflow policy components.

NOTE: Often, when some data changes, other data must be changed in accordance. This data
dependency logic is typically implemented at the Object Manager layer through business
component definitions and run-time events. DB operations by workflow policies provide an
alternative that works at the database-record level. DB operations should be used only when the
data dependency involved centers around database records rather than around business
components. For example, use DB operations when one database record must always be updated
if another database record is inserted, regardless of which business components the two
database records belong to, or whether the two database records belong to any business
components at all.



■ External Program. A program of this type allows you to run an executable.

■ Assignment Request. For internal use only.

■ Generic Request Server. A program of this type submits a server request to a designated
server component.
NOTE: Most functionality included in workflow policy action programs can be executed using
Workflow Processes.

You can use programs in multiple action definitions and you can use action definitions in multiple
workflow policies. “Predefined Programs” on page 295 contains a list of the predefined programs.

Workflow Policy Groups
Workflow policies are organized into groups. A workflow policy group is a collection of workflow
policies to facilitate load balancing on the servers. Workflow policy groups allow you to manage and
optimize Workflow Agent process performance by grouping similar policies to run under one Workflow
Agent process.

Architecture of Workflow Policies
The key elements of the Workflow Policies module are workflow policy object creation in Siebel Tools,
workflow policy creation in the run-time client, and policy execution by the Siebel Server Workflow
Components.

The Workflow Policies architecture is illustrated in Figure 3.

Figure 3. Architecture of Workflow Policies


Overview of Siebel Workflow ■ Workflow Roles

Workflow Policies enforces policies at the data layer, through database triggers. When a particular
policy’s conditions are met, underlying database triggers capture the database event into a Workflow
Policy Manager queuing table (S_ESCL_REQ). A Workflow Policy Manager component (the Workflow
Monitor Agent) polls this table and processes requests by taking the actions defined. In some cases,
an action defined might be to invoke the Workflow Process Manager.

Workflow Policy Manager provides scalability by using an additional component called Workflow
Action Agent. Workflow Action Agent can be executed on a different application server within the
Siebel Enterprise.

Workflow Policies Administration Overview
The Workflow Policies module is administered through Siebel Workflow in the run-time client.
Instructions for accessing and using the Workflow Policies views are in “About Customizing Workflow
Policies with Siebel Tools” on page 235.

Workflow Roles
The job roles associated with Siebel Workflow are the following:

■ The Business Analyst considers your organization’s business requirements and determines the
processes to be automated using the Siebel application.

■ The Workflow Configurator uses Siebel Tools to develop workflow processes and to define
objects, business services, and programs.

Your organization can use the predefined objects, business services, or programs provided in the
application; or, the Workflow Configurator can define customized objects, business services, and
programs in Siebel Tools.

NOTE: Business services can also be defined in the Siebel client. For more information, see
Integration Platform Technologies: Siebel Enterprise Application Integration.

■ The Workflow Administrator monitors workflow processes in the Siebel client using Siebel
Workflow. The Workflow Administrator also activates workflow policies by generating database
triggers in a script and creating them in the Siebel database. The Workflow Administrator then
starts Siebel Server processes that execute workflow processes and policies. This person is
typically a system administrator, database administrator, or someone from the Information
Services department.

■ The End User uses the system and executes workflow processes and policies. This person is
typically an employee of your organization, and can also be a customer.


Overview of Siebel Workflow ■ Workflow Roles


3 Introduction to Workflow
Processes

Siebel Workflow is an interactive software tool that lets you automate how your organization handles
workflow processes. It uses as its basic model the same processes that organizations use in their
sales, marketing, and service departments that determine business workflow. You can use Siebel
Workflow to promote consistency and adherence to processes through the automatic enforcement of
business policies and procedures.

The Siebel Workflow product provides a graphical user interface featuring a familiar flowcharting
methodology for designing workflow processes.

This chapter is organized as follows:

■ “Overview of the Workflow Architecture” on page 27

■ “Workflow Processes Development Lifecycle” on page 28

■ “Design-Time Architecture of Workflow” on page 43

■ “Simulation Architecture of Workflow” on page 45

■ “Deployment Architecture of Workflow” on page 46

■ “Run-Time Architecture of Workflow” on page 47

■ “Workflow Interaction with Other Siebel Components” on page 52

Overview of the Workflow Architecture
Siebel Workflow works with all Siebel Business Applications and involves the following architectural
components:

■ Siebel Tools. Siebel Tools is an integrated environment for configuring all aspects of a Siebel
application. The Workflow Process Designer resides in Siebel Tools. You use the Process Designer
to build your workflow processes.

■ Siebel Client. Workflow Processes and Workflow Policies are administered through the
Administration - Business Process views in the Siebel client (Mobile Web Client).

■ Siebel Server. Siebel Server manages the Siebel Workflow components that automate business
policies.

■ Siebel Database. A relational database containing the set of data that Workflow Policies act
against.

For a complete description of the Siebel Server architecture, refer to Siebel System Administration
Guide.

Siebel Tools provides the design interface and the debugging interface of Siebel Workflow. After
workflow processes are designed and debugged, they are written to repository tables for deployment
from the administrative interface in the run-time client.


Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle

Workflow Processes Development
Lifecycle
Figure 4 depicts the development and deployment lifecycle for a workflow process.

NOTE: While the lifecycle shown is a linear flow, the typical development cycle of a workflow process
is iterative.

Figure 4. Development and Deployment Lifecycle of Workflow Processes

The development and deployment steps shown in Figure 4 are covered in greater detail in the
following topics:

■ “Analyzing Process Requirements” on page 28

■ “Defining Workflows” on page 31

■ “Identifying and Building Exception Handling” on page 37

■ “Testing and Troubleshooting Workflows” on page 39

■ “Migrating Workflows to Production” on page 40

■ “Monitoring Workflow Execution” on page 42

Analyzing Process Requirements
The first part of a workflow’s development entails analysis of your business requirements and the
rules and processes to be automated.



An implementation project team typically spends a fair amount of time on requirements analysis. It
is not unusual for this to be about 30% of the of the total implementation time. A Business Analyst
defines the processes to be automated using the Siebel application. A developer (the Workflow
Configurator) reviews these processes. When making design decisions on how to implement the
processes, the Workflow Configurator looks for the following areas as candidates to be implemented
using Siebel Workflow:

■ Repetitive, manual processing

■ Need for timely processing of an event

■ Escalations and notifications

When making implementation decisions about automating processes, a Workflow configurator should
consider the options summarized in Table 2.

Table 2. Using Siebel Workflow for Automation Versus Using Other Siebel Mechanisms

Framework Key Advantages Limitations

Workflow Processes ■ Visual representation of The semantics for control are not as rich
business logic is as with scripting. Specific limitations
relatively simple to include:
understand and
■ Limited control of flow for
maintain.
iteration through record sets
■ Remote synchronous
■ Limited direct access to object
and asynchronous
methods
execution enable broad
horizontal scalability and
long-running
transactions.



Table 2. Using Siebel Workflow for Automation Versus Using Other Siebel Mechanisms

Framework Key Advantages Limitations

Workflow Policies ■ Policies respond to ■ Changes to policies may require
database events database downtime to implement.
regardless of whether
■ Policies are more difficult to
they are initiated by an
configure that other alternatives.
Object Manager
component or by a non- ■ Policies allow a limited range of
Object Manager executable actions.
component.

■ Policies may get higher
transaction throughput
on a given set of
hardware for simple
transactions.

Siebel Script ■ Script is familiar to most Widespread scripting degrades:
developers.
■ Ease of maintenance
■ Script provides a
■ Ease of upgrade
complete set of
semantics. ■ Performance
■ Script is highly flexible.

When Workflow Policies Offers a Better Automation Choice than
Workflow Processes
When deciding whether to implement a workflow policy versus a workflow process there are some
additional things you may want to consider, such as:

■ whether the data and business logic involved are at the data layer or the business logic layer of
the Siebel architecture

■ which features your automation will need to implement.

Workflow Process Manager and run-time events capture business-layer logic. Workflow Policy
Manager captures data-layer logic.

Data coming into Siebel via the data layer—for example EIM or MQ channels—cannot be captured
via the business layer. This typically presents a good candidate for a workflow policy. Some features
not supported by workflow processes—such as email consolidation, duration, and quantity—are also
candidates for workflow policies.

Workflow processes, however, provide a better platform for development and deployment, complex
comparison logic, and flow management (IF, THEN, ELSE, or CASE). Workflows can invoke business
services. Workflows provide pause, stop, and error-handling capabilities.

Workflow Policy Manager is the better alternative in scenarios such as a case when bulk data uploads
happen using EIM, or during Data Quality cleaning in the data layer.



For more information on Workflow Policies, see Chapter 10, “Workflow Policies”. For more detail on
analyzing requirements for process automation, see Chapter 4, “Planning Workflow Processes.”

Defining Workflows
With Siebel Workflow, the run-time engine manages process flow, application flow, and integration
flow. Basic constructs such as Start/Wait/End steps, Decision Points, Subprocesses, and Connectors
are available to define your workflow processes. (For details on how to implement each of these
constructs, see Chapter 6, “For Developers: Workflow Process Steps.”)

The key elements of run-time execution are:

■ Events. Workflow processes can be invoked from events in the Siebel application or in external
systems. Events can pass context from the caller—a user session, for example—to a workflow
process using a row-id.

■ Rules. The flow control for a workflow process is determined by decision rules. Rules can be
based on business component data or on local variables known as process properties. Rule
expressions are defined using Siebel Query Language.

■ Actions. Workflow process actions can perform database record operations, they can invoke
business services, and they can cause a pause in the workflow process.

■ Data. Data is created or updated as the workflow process executes. There are three main types
of data a workflow process operates on:

■ Business component data

■ Process properties

■ Siebel Common Object data.

Think of process properties as local variables that are active during the workflow process. The
variables are used as inputs and outputs to the various steps in a process. With every workflow
process, there is a set of predefined process properties that are automatically generated when you
define the workflow. One example of these predefined process properties is the Process Instance Id.
For more information on process properties, see “About Process Properties” on page 93.



Some of the basic constructs of Siebel Workflow are shown in Figure 5.

Figure 5. Basic Constructs of Siebel Workflow

Events
Using events is one of three main ways to invoke a workflow process. The other two invocation
mechanisms are Workflow Policies and Tools object events (script). For more information on workflow
invocation mechanisms, see “Invocation Mechanisms” on page 49.



Rules
There are several ways to implement decision rules in a workflow process. Table 3 describes the main
ways and discusses their usefulness and limitations.

Table 3. Ways to Implement Rules in Workflow Processes for Enforcing Business Logic

Type Description When Useful Limitations

Workflow A step in a workflow that When you need a Conditional
Decision Point arbitrates between one or simple articulation of expressions lack
more alternative branches in whether one or more support for some key
the flow. alternative actions in operators including:
flow should be taken.
Each branch out of a ■ AND
decision step has one or
■ OR
more conditions. If all
evaluate to TRUE for the ■ Order of
branch, the flow continues precedence
down that branch. control (that is,
parentheses)

Scripted Script within a business When Workflow Undermines the
Business Service service action step that decision point readability and
evaluates a potentially semantics are not simplicity of the
complex set of inputs and sufficiently expressive workflow by hiding
returns a simplified output to encapsulate logic within a business
that can be evaluated by a decision criteria. service.
workflow decision point.

Other Other rule frameworks that When it is deemed Limitations vary
Specialized Rule may be used directly or appropriate to use a depending on the rule
Frameworks indirectly by a workflow, specialized rule framework used.
such as personalization framework, such as
rules, assignment rules, EAI when you need to
Dispatch Service, or the assign work to people
Siebel rules engine that is based on their
new in this release. workload.

The Siebel rules engine
allows you to maintain
business process logic
declaratively and in a
location external to your
Siebel applications. For
information on
implementing rules in Siebel
Workflow, see Siebel
Business Rules
Administration Guide.



Decision Points
Decision points exit with multiple branches. For each branch, a conditional statement is evaluated.
A conditional statement compares any two of the following:

■ process properties

■ business component fields

■ literal values

The terms of comparison include:

■ two values are equivalent

■ one value exists among a series of others (for example, child record values, One Must Match, or
All Must Match
■ Greater Than (>) or Less Than (<)

■ Between or Not Between

■ Null or Not Null

For an example of a Compose Condition Criteria dialog box showing decision criteria, see Figure 23
on page 105. For descriptions of the fields in the Compose Condition Criteria dialog box, see Table 11
on page 106.



Actions
There are several ways to effect actions in a workflow. With a workflow process action, data is taken
as an input, then a transformation takes place, and data is produced as output. Table 4 shows the
main ways to cause various transformations, and describes their usefulness and limitations.

Table 4. Actions in Siebel Workflow

Action Type Description When Useful Limitations

Business Service A workflow step that invokes When you need Creating and destroying
Step a method of a business to execute a business services can be
service. potentially expensive. Overhead can be
complex, but reduced through caching.
The business service may be
reusable set of
a prebuilt Siebel service or a Incorporating too much logic
logic.
scripted business service. within a business service
may limit its reusability and
the transparency of the
workflow.

Database A workflow step that When you need While it is possible to update
Operation performs inserts, updates, to execute multiple records based on a
(Siebel and queries against Siebel simple record search specification, it is not
Operation Step) business components. operations within possible to retrieve and
the workflow. iterate through a set of
records such that
subsequent workflow actions
can execute for each record.

Wait Step A workflow step that puts When you need The releasing event must be
the workflow into a holding to support time- triggered through the Object
pattern until a releasing based Manager.
event is fired or a timeout escalations or
occurs. long-running
flows that may
last for days or
weeks (for
example, waiting
for a customer
response)

Business Service Step
Business Service steps execute predefined or custom methods. Typical predefined business services
used include Assignment Manager requests, notification through the Communications Server, server
requests, and integration requests (from Siebel EAI). Custom business services can be written in
Siebel VB or eScript. When defining a Business Service step, you must specify the business service,
the business service method, input arguments (pass in a process property, business component data,
or a literal value) and output arguments.

Some commonly used business services for workflow processes include:



■ FINS Data Transfer Utilities

■ FINS Validator

■ FINS Dynamic UI

■ Outbound Communications Manager

■ Report Business Service

■ Synchronous Assignment Manager Requests

■ Server Requests

■ Business Rule Service

■ Audit Trail Engine

■ EAI business services (such as EAI Siebel Adapter, EAI XML Converter, and so on)

For more information on these business services, see “Predefined Business Services” on page 328.

Siebel Operation Step
Siebel Operation steps allow you to perform database operations of Insert, Update, Query, Delete,
NextRecord, PreviousRecord, and QueryBiDirectional. These steps are performed on business
components. Once you have defined the Siebel Operation step, you can use the Search Specification
child object to locate the records you want to work on.

Examples of Siebel Operations steps include creating an Activity record when a new SR is opened,
or updating a comment field if an SR has been open too long.

Wait Step
Wait steps allow you to suspend workflow process execution for a specified period of time or until a
specific event occurs. Figure 6 shows the definition of a timeout based on time defined as literal
values in input arguments.

Figure 6. Example Wait Step Definition

About Developing Workflow Processes in Siebel Tools
You develop workflow processes in Siebel Tools, on a local database. Siebel Workflow is a repository
object. A workflow belongs to a project.



Though compiling a Siebel Repository File is a standard practice for other repository objects, Siebel
Workflow has its own deployment mechanism. You do not compile a SRF after you have developed
workflow processes. For more information on Workflow deployment, see “About Deploying Workflow
Processes” on page 181.

Siebel Workflow does not participate in the behaviors that follow, though these behaviors are
standard for other repository objects.

■ Merge. Siebel Workflow does not participate in three-way merge. When workflow definitions are
imported into the repository, they maintain versioning provided by Siebel Workflow.

■ Object Comparison. This is disabled in this release.

■ Archive. Workflows do not participate in .sif archive. Instead, workflows can be archived as XML
files using the Workflow export utility.

Typically, developers use a local database to develop workflows. When using a local database, you
must check out workflow definitions from the master repository.

When developing workflows on a local database, the local database must have all the referenced data
objects. For those data objects that are not docked and hence not packaged as part of the database
extract, developers must import them into the local database. The following objects are not docked
and are referenced by Workflow:

■ Data maps. To import data maps to the local database, you use the dedicated client connected
to the local database, and the client-side import utility.

■ Message tables. You can copy message tables over to the local database. Alternatively, you can
define messages using the unbounded picklist. While this allows for the creation of messages, it
does not check the validity of the message at definition time.

If you choose, you can also develop or modify workflows using Siebel Tools connected to the
development database, by locking the project in the master repository. This way, you do not need to
make sure that all the lists of values are made available to the local database.

Identifying and Building Exception Handling
An exception represents a deviation from the normal processing flow: an error. An exception can be
a system error or a user-defined error. You can use exception handling to notify the user of an error
and terminate the workflow process instance. There are three ways of handling exceptions:

■ Using a Stop step

■ Using Exception branches

■ Using a universal exception handler

Using a Stop Step
Use a Stop step to show a particular error message while processing. Examples for use include real-
time processing for credit card authorization or for order validation. This type of exception handler
provides customizable error messages including expressions. For more information on Stop steps,
see “About Stop Steps” on page 137.



Using Exception Branches
You can programmatically handle errors and change the flow depending on when errors are
encountered. You do this using Exception branches. This provides a granular approach to handling
exceptions at each step. In the example shown in Figure 7, when the Get Organization ID step is
unable to get data, the workflow is programmed to continue to the Lookup Sender by Org step and
if this fails, to take the red Exception branch and send an email (the Send Lookup Error Email step).

Figure 7. Example of a Workflow That Uses Exception Branches to Programmatically Handle
Exceptions

For more information on handling exceptions with Exception branches, see “Using Exceptions to
Handle Errors” on page 163.

Using a Universal Exception Handler
You can define a universal exception handler at the workflow level by setting Error Process Name on
the workflow to be used as the error process.This error process workflow is then invoked for any
exception that happens on the workflow attached to it.

Use a universal exception handler when you need a uniform exception handler across multiple steps
in a workflow or across multiple workflows. This type of exception handling also helps to reduce
clutter on the workflow diagram itself.

For more information on using error processes as uniform exception handlers, see “Using Error
Processes to Handle Errors” on page 161.



Testing and Troubleshooting Workflows
There are two ways of testing and troubleshooting a workflow: simulating the workflow, and using
event logs.

Simulating Workflows
Two simulators allow you to simulate workflows:

Process Simulator. Most workflows can be tested and debugged using the Process Simulator, which
is hosted in Siebel Tools. To use the simulator, you need to have the Siebel mobile client installed.
The mobile client can connect to any database (that is, either development or local) that has the test
data required to debug a workflow.

In this release, you can test interactive workflows and runtime-event-based workflows using the
Process Simulator. Long-running workflows and those workflows that invoke server components
cannot be debugged using the Process Simulator. During the debugging, the process variables are
displayed by the dynamic watch window.

Business Service Simulator. Workflow can be run as a business service from the Business Service
Simulator in the Siebel client. The workflows must be published and activated before testing them
with the Business Service simulator. To use the simulator, the following conditions must first be met:

■ Siebel Mobile Client installed

■ Workflows exported from Siebel Tools

■ Workflows imported by way of the client

NOTE: Alternatively, you can publish and activate to the Mobile Web Client directly from Siebel Tools.

Use the Business Service simulator when you need to debug script in conjunction with a workflow.
Set breakpoints in the script and execute the workflow in the mobile client. When the workflow
executes a service for which a breakpoint is set, control is returned to the Script Debugger in Siebel
Tools.

Using Event Logs
For more detailed information on the execution of a workflow, set event logs so that you can view
the log files.

NOTE: This method is useful if you cannot perform real-time debugging or do not have the Process
Simulator readily available. However, use of this method may result in large log files that must be
analyzed. For information on using the Log File Analyzer, see Siebel System Monitoring and
Diagnostics Guide.

Events used for logging are as follows:

■ Workflow Engine Invoked (EngInv). Traces methods invoked and arguments passed to the
Workflow engine.

■ Workflow Definition Loading (DfnLoad). Traces process and step definitions loaded into
memory.



■ Workflow Process Execution (PrcExec). Traces process instance creation and completion.
Traces the process property get/set.

■ Workflow Step Execution (StpExec). Traces step creation and completion, branch condition
evaluation, business service invocation, and business component insert/update.

■ Workflow Performance (WfPerf). Traces process and step execution time, as well as overall
process execution time.

■ Workflow Recovery (WfRecv). Traces instance recovery status and progress, as well as
instance recovery details. (Applicable only to the Workflow Recovery Manager server
component).

For information on how to set event log levels, see “Setting Tracing and Event Log Levels” on page 196.

Migrating Workflows to Production
Once you have tested your workflows, they are ready to be migrated.

Workflow definitions can be migrated across environments—for example, from development to
production—using one of three migration utilities:

■ Application Deployment Manager (ADM). ADM automates the process of migrating
enterprise customization data (views, responsibilities, assignment rules, workflow processes,
workflow policies, and so on) from one Siebel application environment to another, including from
a development environment to a testing environment.

■ Repository Import/Export Utility (REPIMPEXP). This utility allows export/import of all
repository objects. This utility is best used to migrate all repository objects including your
workflows when your organization is ready to roll out the release (that is, migrate all repository
objects).

■ Workflow Import/Export Utility (Import/Export). This utility allows incremental migration
of workflow definitions. Using Siebel Tools, you export the workflow from one environment and
import the workflow to another environment.

Import of workflows can be done in one of the following ways:



■ Using Siebel Tools for importing workflows. Using Siebel Tools, you import the
definitions into the repository of the target environment, then you mark the workflows for
deployment by clicking the Publish button. After this, the definitions are ready to be
activated. This approach makes sure that the versions of the workflow definitions that exist
in the repository tables and the run-time tables are the same. Figure 8 shows an incremental
deployment using the Import/Export utility and Siebel Tools.

Figure 8. Incremental Deployment Using Import/Export

■ Using the Siebel client for importing workflows. You can import the workflow definitions
directly into the run-time tables. From your point of view, this approach bypasses the steps
of writing the definitions into the repository tables of the target environment and activation
from the Siebel client (although these steps are still performed behind the scenes by the
Workflow engine). This approach causes the latest version of the workflow definition in the
run-time tables (used by the Workflow engine) to be different from the version that resides
in the repository tables.

NOTE: This approach is a good one for testing a workflow in a different environment, but as
a best practice, it should not be used for general migration of workflows across environments.

Figure 9 shows an incremental deployment using Import/Export to export from Siebel Tools
and import from the Siebel client.

Figure 9. Incremental Deployment Using Import/Export to Export from Siebel Tools and Import
from the Siebel Client



For more information on migration utilities, see “Migrating Workflow Processes from Development to
Production” on page 185.

Deploying Workflows in Production
After migrating your workflows to a production environment, you may need to deploy them (publish
them) before you can run them. Whether or not you must deploy them depends on which migration
tools you used. Deployment of workflows happens as follows:

■ ADM automatically deploys all migrated workflows. If you have used ADM to migrate your
workflows to production, you do not manually deploy them.

■ If you have used REPIMPEXP or Import/Export to migrate your workflows to production, you must
manually deploy the workflows.

Manual Deployment of Workflows
You can publish workflows—that is, deploy them—manually from within Siebel Tools, or from within
the run-time client. To deploy workflows manually in Siebel Tools, you use the Publish button or the
Publish/Activate button found in the WF/Task Editor toolbar. Using the Publish/Activate button, you
can both deploy and activate a workflow process with one click. If you choose to publish a workflow
but not activate it, you can still use the run-time client to activate the workflow with the Activate
button in the Workflow Deployment view.

NOTE: In this release, deployment of workflows takes place using buttons in Siebel Tools called
“Publish” and “Publish/Activate.” In earlier releases, the terminology on this button action was called
“Deploy.” In earlier releases, activation could only take place in the run-time client. In this release,
you can activate a workflow in Siebel Tools, given you have set the VerCheckTime parameter in the
Workflow section of the .cfg file to -1 ([Workflow] VerCheckTime = -1).

When you click either the Publish button or the Publish/Activate button, the workflow process is
validated before it is deployed (published). If there are any validation errors for the workflow, a
dialog box appears, giving you the opportunity to correct any errors before deployment (publishing).
This dialog box is modeless, meaning that you may keep it open to see the error messages while
working on the workflow using the Process Designer to correct the problems reported. However, you
can proceed with the deployment despite problems (validation errors) if you choose to do so.

If there are no validation errors, you do not see this dialog box, nor do you see a message stating
that the validation was successful. The validation is carried out without user visibility, unless errors
are detected.

Monitoring Workflow Execution
You monitor and control workflow process execution in the Administration - Business Process views
of the run-time client. You can monitor and troubleshoot Siebel Workflow in the production
environment considering progress and status information, operation details, performance-
measurement data, and failure-analysis records.


Introduction to Workflow Processes ■ Design-Time Architecture of Workflow

For more information, see “Monitoring and Troubleshooting Workflow Processes in Production” on
page 193.

Design-Time Architecture of Workflow
Workflow components and definitions are defined as Siebel Tools objects and are stored in the Siebel
Tools repository. Before you can run a workflow process as a server task or from the Siebel Web
Client, you must first publish the workflow process from Siebel Tools, then activate the workflow
process from the Siebel Web Client.

NOTE: If you use the Publish/Activate button (rather than the Publish button) to publish the
workflow process in Siebel Tools, there is no need to separately activate the workflow in the run-time
application.

The Workflow Process repository object is a top-level object in the Object Explorer of Siebel Tools.
You use the Object List Editor (OBLE) to create Workflow processes. Workflow processes belong to a
project. There is no SRF compile required for deployment of workflow processes. There is no merge
required. There is independent versioning of workflow processes in Siebel Tools and in the run-time
client.

Configuration data is available at design time, but run-time data is not available at design time. You
use process properties to create workflow definitions, or alternatively, you can enter data through
unbounded picklists.

The following Siebel Tools features are not applicable to Workflow objects:

■ SIF export and import

■ Object Compare

■ Three-way merge during upgrades

Because Siebel Tools excludes Workflow objects from these features, it is important to use the
Workflow import and export feature for backing up and restoring workflow definitions. For example,
if you archive a project in Siebel Tools, the Workflow objects within that project are not archived.

CAUTION: If you delete all the objects from a project expecting that they can be restored from the
SIF, it is important to keep in mind that Workflow objects are an exception, and cannot be restored
from the SIF. Use the Workflow import and export feature to back up and restore workflow
definitions.


Introduction to Workflow Processes ■ Design-Time Architecture of Workflow

Use the Process Designer in Siebel Tools to develop workflow processes. Workflow processes are
stored in the Siebel system in the repository and runtime tables. When you edit the processes in Siebel
Tools, they are stored in the repository tables. When you publish and activate the processes, they are
also inserted into the runtime tables. Figure 10 shows the design-time architecture of Workflow.

Figure 10. Design-time Architecture of Siebel Workflow

Figure 10 shows the following points:

■ Workflow processes in development are stored in the Siebel repository as repository tables and
runtime tables

■ There are two methods of exporting workflow processes from the Process Designer in Siebel Tools
as files:

■ As a workflow process file (.xml)

■ As a Siebel archived file (.sif)

NOTE: Although not shown in Figure 10, you can also use ADM to migrate workflow processes from
one Siebel environment to another. For more information about ADM, see Siebel Application
Deployment Manager Guide.


Introduction to Workflow Processes ■ Simulation Architecture of Workflow

Simulation Architecture of Workflow
After designing your workflow processes, you test them using the Process Simulator. Testing your
workflow processes before migrating them to your production environment verifies that resulting
actions are accurate and useful and the results are exactly what you want.

Figure 11 shows the simulation architecture of Workflow.

Figure 11. Simulation Architecture of Siebel Workflow


Introduction to Workflow Processes ■ Deployment Architecture of Workflow

Deployment Architecture of Workflow
After designing your workflow processes and testing them, it is time for deployment. Figure 12 shows
the relationship of Siebel Tools and the run-time client in the deploying of workflow processes.

Figure 12. Deployment of Workflow Processes

Figure 12 illustrates that workflow definitions are read from the repository, then when a workflow is
activated, its definitions are written to run-time tables.


Introduction to Workflow Processes ■ Run-Time Architecture of Workflow

Run-Time Architecture of Workflow
The Workflow run-time architecture is based on the Siebel Object Manager layer and the server
infrastructure layer of the Siebel Business applications architecture. The run-time environment is
available both as a business service and as a server component. The run-time architecture supports
three invocation modes for invoking and resuming workflow processes: Local Synchronous, Remote
Synchronous, and Remote Asynchronous. Figure 13 shows the run-time architecture of Workflow.

Figure 13. Run-time Architecture of Workflow

Workflow Process Types
Siebel Workflow has four types of workflow processes that characterize run-time behavior. The
processing type is set in the Workflow Processes list editor of Siebel Tools, using the Workflow Mode
field. The workflow process types are as follows:

■ 7.0 Flow. A 7.0 workflow process provides backward compatibility for existing Siebel 7 (pre-7.7)
workflows. For more information, see “About 7.0 Workflow Processes” on page 143.

■ Long Running Flow. A long-running workflow process is a persistent workflow that can last for
hours, days, or months. For more information, see “About Long-Running Workflow Processes” on
page 143.

■ Interactive Flow. An interactive workflow process navigates the user across Siebel views. For
more information, see “About Interactive Workflow Processes” on page 144.

■ Service Flow. A service workflow process executes a set of operations upon event invocation.
For more information, see “About Service Workflow Processes” on page 144.


Bpf Workflow

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Bpf Workflow

Semelhante a Bpf Workflow (20)

Último

Último (20)

Bpf Workflow