BPFWorkflow

Siebel Business Process Framework: Workflow GuideVersion 8.1, Rev AJuly 2009

Copyright © 2005, 2009 Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. 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, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications which may create a risk of personal injury. If you use this software in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of this software. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software in dangerous applications.

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.

Siebel Business Process Framework: Workflow Guide Version 8.1, Rev A 3

Contents

Siebel Business Process Framework: Workflow Guide 1

Chapter 1: What’s New in This Release

Chapter 2: Overview of Siebel WorkflowAbout Siebel Workflow 15

Business Requirements That Can Be Addressed by Managing a Business Process 15Overview of Technologies That Are Used to Automate a Business Process 16Overview of Objects That Are Used with a Workflow Process 18Scenario to Promote Timely Resolution of a Service Request 19Viewing Example Workflow Processes 21

Overview of How a Workflow Process Is Developed 22

Chapter 3: Architecture of a Workflow ProcessAbout the Architecture of a Workflow Process 25

Development Architecture of a Workflow Process 26Simulation Architecture of a Workflow Process 28Deployment Architecture of a Workflow Process 30Run-Time Architecture of a Workflow Process 31

How a Workflow Process Interacts with Other Siebel Components 36

Chapter 4: Environment for Developing a Workflow Process

About the Object Hierarchy of a Workflow Process 39Properties of an Object 41Relations Between Object Types of a Workflow Process 42Locating a Workflow Process in the Workflow Processes Object List Editor 43

About the Process Designer 44

About the Process Property 47Process Property and the Property Set 48Arguments of the Step of a Workflow Process 49Multi Value Property Window 50Process Properties That Are Predefined 54Manipulating a Process Property 57

About the WF/Task Editor Toolbar 62

Siebel Business Process Framework: Workflow Guide Version 8.1, Rev A

Contents ■

4

Chapter 5: Steps and Connectors of a Workflow ProcessOverview of Workflow Process Steps 65

Adding a Step to a Workflow Process 66Name of a Step in a Workflow Process or a Process Property 67How Properties Are Defined for a Step in a Workflow Process 68Sequence Number for a Step in a Workflow Process 68

Types of Steps of a Workflow Process 69About the Start Step 69About the Business Service Step 70About the Decision Point 72About the Sub Process Step 73About the Siebel Operation Step 75About the Task Step 84About the User Interact Step 85About the Wait Step 87About the Stop Step 88About the End Step 90About the Workflow Connector 91

Defining a Decision Condition 92Defining a Branch Connector 92Defining a Decision Condition on a Branch Connector 95

Chapter 6: Developing a Workflow ProcessRoadmap for Developing a Workflow Process 97

Process of Analyzing Business Requirements 99Gathering Information for Planning a Workflow Process 99Identifying Actions That a Business Process Performs 100Identifying an Automation Solution 101

Process of Planning a Workflow Process 104Determining the Mode of the Workflow Process 104Determining How the Workflow Process Is Started 105Determining Decision Logic of a Workflow Process 107Determining Actions of a Workflow Process 109Determining Error Handling 111Examining Seed Workflow Processes 111Determining Requirements for Managing the Development of Objects 112Addressing Other Business Requirements 113

Job Roles That Are Involved in Developing a Workflow Process 114

Contents ■


Chapter 7: Process of Building a Workflow ProcessPreparing Siebel Tools to Develop a Workflow Process 115

Exposing Object Types That Are Used to Develop a Workflow Process 116

Defining a Workflow Process 117Reviewing Workflow Processes 117Copying a Workflow Process 118Modifying a Workflow Process 118Revising a Workflow Process 119Defining a New Workflow Process 120Naming a Workflow Process 120Externalizing Workflow Properties 120Making a Workflow Process Editable 120Deleting a Workflow Process 121

Diagramming a Workflow Process 122Displaying the Label for a Connector 122Adding or Removing a Point in a Connector 123

Defining a Process Property for a Workflow Process 124

Defining a Property for the Step of a Workflow Process 126

Chapter 8: Options for Developing a Workflow ProcessAbout the Workflow Mode Property 127

Types of Modes for a Workflow Process 127Options for the Workflow Mode Property 129Options for an Interactive Workflow Process 130Options for a Long-Running Workflow Process 139Workflow Persistence 141

Starting a Workflow Process 143Starting a Workflow Process from a Workflow Policy 143Starting a Workflow Process from a Run-Time Event 144Starting a Workflow Process from a Business Service 147Starting a Workflow Process from Another Workflow Process 149Starting a Workflow Process Through the Workflow Process Manager 150Starting a Workflow Process Through the Application Object Manager 152Starting a Workflow Process Through a Script 152Example of Starting a Workflow Process from a Custom Toolbar 154Other Techniques for Starting a Workflow Process 156

About Events 157Run-Time Event 157About the User Event 161


Contents ■

6

Handling Errors 164Using an Error Exception Connector to Handle Errors 164Using a Stop Step to Handle Errors 168Error Handling with an Error-Workflow Process 168Recovery for a Workflow Process That Has Failed 171

Using Batch Processing 172

Defining a Workflow Process for a Multilingual Environment 175Defining a Workflow Process to Function in a Multilingual Environment 175Expressions in a Multilingual Environment 176Wait Step and Global Time Calculations 176Local Code Parameter and Data Format 177

Chapter 9: Manipulating DataAccessing Data From a Run-Time Event From a Workflow Process 179

Passing Data to and from a Workflow Process 182Passing an Input to a Workflow Process 182Passing an Output From a Workflow Process 183Passing a Parameter from a Workflow Process to a Global Variable 183Passing a Constant from a Workflow Policy Action into a Workflow Process 183Examples of Scripts That Pass Data to and from a Workflow Process 184

Timestamp Usage 188

Decision Conditions for a Workflow Process 188Fields in the Compose Condition Criteria Dialog Box 189Expressions in the Expression Builder 190

Chapter 10: Testing a Workflow ProcessAbout the Testing Tools 197

Validate Tool 197Process Simulator 198Business Service Simulator 201Event Logs 201

Process of Testing a Workflow 202Validating the Workflow Process 202Preparing to Use the Process Simulator 203Using the Process Simulator 204Verifying Functionality 206

Troubleshooting Validation and Simulation Problems 208

Contents ■


Chapter 11: Administering a Workflow ProcessProcess of Deploying a Workflow Process 211

Preparing the Run-Time Environment 212Publishing a Workflow Process 216Activating a Workflow Process 216

Process of Migrating a Workflow Process 218Developing a Migration Strategy 218Migrating a Workflow Process 223

Process of Administering a Workflow Process 227Viewing Run-Time Instances of a Workflow Process 227Using the Workflow Instance Admin View 228Stopping an Instance of a Workflow Process 229Deactivating the Instance of a Workflow Process 230Removing a Workflow Process From the Run-Time Environment 231

Monitoring a Workflow Process 233Overview of Monitoring and Troubleshooting Tools 233Setting Monitoring Levels for a Workflow Process 233Setting Monitoring Levels for Tracing and the Event Log 236Defining Metrics for a Workflow Process 237Capturing Data with Siebel Application Response Measurement 238Recording Behavior with the Siebel Flight Data Recorder 239

Diagnosing a Workflow Process That Has Failed 240Diagnosing a Workflow Process That Has Failed in a Production Environment 240Troubleshooting Execution Problems with a Workflow Process 243About the Workflow Recovery Manager 246

About Upgrading a Workflow Process 253

Chapter 12: Examples of Defining a Workflow ProcessExample of Defining a Workflow Process That Creates an Activity for a Sales Representative 255

Defining the Workflow Process 256Testing the Workflow Process 262Deploying and Verifying the Workflow Process 263

Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete 264

Example of Defining a Workflow Process That Attaches an Activity Plan to an Opportunity 281

Example of Defining a Workflow Process That Manages Research Activities for a Service Request 288


Contents ■

8

Example of Defining a Workflow Process That Manages Creation of a Service Request 292

Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the User 301

Chapter 13: Examples of Using a Business Service with a Workflow Process

Examples of Using the Server Requests Business Service 305Example of Using the Server Requests Business Service to Start a Workflow Process from a Script 305Example of Using the Server Requests Business Service to Call EIM 306

Examples of Using the Outbound Communications Manager Business Service 309Example of Defining a Substitution when Using the Outbound Communications Manager

309Example of Using the Outbound Communications Manager to Send an Email to the Owner of a Product Defect 310

Example of Externalizing Properties when Using a Business Service 316

Chapter 14: Defining a Custom Workflow PolicyAbout Workflow Policies 323

Overview of Workflow Policy Objects 323Structure of a Workflow Policy 327Sequence of a Workflow Policy 330Hierarchy of Workflow Policy Objects 331

Process of Planning a Workflow Policy 332Planning a Workflow Policy Group 332Planning a Workflow Policy 333Planning Objects to Monitor with a Workflow Policy 334Planning the Workflow Policy and Workflow Policy Conditions 334Planning the Workflow Policy Action 335Examining Workflow Policies and Workflow Policy Programs That Are Predefined 335Planning a Test and Migration Strategy for a Workflow Policy 336Examples of Planning a Workflow Policy 336

Process of Defining a Workflow Policy 340Defining a Workflow Policy Group 340Defining a Workflow Policy Action 341Defining a Workflow Policy 346

Examples of Defining Workflow Policy Configurations 349Examples of Defining a Workflow Policy Action 349Examples of Defining a Workflow Policy 357

Contents ■


Customizing Workflow Policy Objects 360Display of Workflow Policy Objects 360Defining a Customized Workflow Policy Object 361

Conditions for a Workflow Policy 370Standard Comparisons in the Conditions List 370A Field That Is Not Known Is Interpreted as Null 371Specialized Comparisons in the Conditions List 371Date Calculations in the Conditions List 375

Chapter 15: Using a Predefined Workflow PolicyConfiguring a Predefined Workflow Policy 377

Configuring a Predefined Workflow Policy for Messaging 377Identifying the Source Table When Modifying an Existing Workflow Policy 378

Types of Workflow Policy Programs That Are Predefined 381

Examples of Workflow Policy Programs That Are Predefined 388

Workflow Policy Programs that Are Predefined for Siebel Marketing 393Example of Developing a Workflow Policy That Manages a Marketing Campaign 394

Chapter 16: Administering a Workflow PolicyAdministering a Workflow Policy 401

Confirming the Installation of Workflow Policies 401Administering Database Triggers on the Workflow Policy Server 402Administering Email Manager and Page Manager 409Executing a Workflow Policy with the Workflow Action Agent 415Executing a Workflow Policy with Workflow Monitor Agent 417Defining a Workflow Policy to Run in Batch Mode 428Moving a Workflow Policy to a Different Group 431Expiring a Workflow Policy 432Deleting a Workflow Policy That Is Obsolete 434Tracing and Reporting a Workflow Policy 436Guidelines for Converting a Workflow Policy to a Workflow Process 439

Testing, Troubleshooting, and Migrating a Workflow Policy 440Testing a Workflow Policy 440Troubleshooting a Workflow Policy 442Migrating Workflow Policies to the Production Environment 443

Appendix A: Reference Materials for Siebel WorkflowProperties of Siebel Workflow 445

Properties of a Workflow Process 445


Contents ■

10

Properties of the Step and Connector of a Workflow Process 450Fields and Arguments of Process Properties 462

Properties of Workflow Policies 470Properties of the Workflow Policy Column 470Properties of the Workflow Policy Object 471Properties of the Workflow Policy Component 472Properties of the Workflow Policy Component Column 474Properties of the Workflow Policy Program 475Properties of the Workflow Policy Program Argument 476

Predefined Business Services 482Server Requests Business Service 482Workflow User Event Service Business Service 486Workflow Utilities Business Service 487Workflow Admin Service Business Service 489Other Business Services That Are Used with a Workflow Process 491

Appendix B: GlossarySiebel Workflow Glossary 495

Index


1 What’s New in This Release

What’s New in Oracle’s Siebel Business Process Framework: Workflow Guide, Version Version 8.1, Rev ATable 1 lists changes in this version of the documentation to support release Version 8.1, Rev A of the software.

Table 1. Documentation Changes in Siebel Business Process Framework: Workflow Guide, Version 8.1

Topic Description

“Passing a Process Property to an Error-Workflow Process” on page 58

Describes a procedure for passing a user-defined process property to an error-workflow process.

“Referencing a Process Property” on page 60

A process property can be used as a substitution variable within an expression.

“Copying a Value from a Parent Workflow Process to a Sub Workflow Process” on page 74

You can copy a value to a record being updated or inserted in a subprocess by defining a process property in the subprocess and assigning the value to it.

“Example of Defining a Siebel Operation Search Specification” on page 77

An expression for a Search Specification can be defined with a compound expression and substitution from a process property or field.

“Updating the Field of a Nonprimary Business Component” on page 78

You can update a field in a nonprimary business component.

“Updating a Process Property with a Siebel Operation Step” on page 80

You can use a Siebel operation step to update a process property.

“How the Upsert Operation Is Used with the Siebel Operation Step” on page 82

The Upsert Operation provides a way to perform either an insert or update operation, based on whether a record exists in the database.

“Comparison of Branching Declaratively to Programming with a Script” on page 93

You can implement branching declaratively. For example, with multiple branches that emanate from a single step in a workflow process. In some cases, you can achieve the same result through a script. For example, with a script on a business service.

“Comparison of Using a Run-Time Event to a Using a Workflow Policy” on page 145

Describes example scenarios for using a workflow policy compared with a run-time event.

“Identifying A Predefined Workflow Process That Is Started by a Run-Time Event” on page 147

You can use the Siebel client to identify predefined workflow processes that appear in the Action Set Field of the Administration-Runtime Events screen.


What’s New in This Release ■

12

“Key Based Routing with Workflow Process Manager” on page 150

Key Based Enabled can be defined for the Workflow Process Manager to assist with routing and recovery.

“Defining an Error Exception Connector to Handle an Update Conflict” on page 166

You can define an error exception connector to handle an update conflict that occurs when multiple attempts are made to write to the same record at the same time.

“Usage of the Repeating Component Request” on page 173

You can use the Repeating Component Request feature with the workflow process to schedule the workflow to execute at a predetermined time.

“Usage of the Workflow Process Batch Manager with Primary and Nonprimary Business Components” on page 173

Use the Workflow Process Batch Manager server component when you must run the workflow process for every record of a particular business component.

“Passing a Constant from a Workflow Policy Action into a Workflow Process” on page 183

You can use the Run Workflow Process program to pass a constant from a workflow policy action into a workflow process.

“Using the Watch Window” on page 199

Describes the Watch window, including how to use it within the context of an example.

“Using the Process Simulator” on page 204

Describes Process Simulator usage.

“Notification to Mobile Users Who Are Not Synchronized” on page 214

You can define a workflow process to send a notification email to mobile users who are not synchronized.

“Deploying a Workflow Process as a Web Service” on page 215

Describes how a workflow process can be deployed as a Web service.

“About the Workflow Recovery Manager” on page 246

You can use the Workflow Recovery Manager to recover an interrupted workflow process.

“Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete” on page 264

Provides a detailed example that describes how to traverse a record set.

“Example of Using the Server Requests Business Service to Start a Workflow Process from a Script” on page 305

You can use the Server Requests business service to start a workflow process from a script and to pass field values to process properties.

“Example of Using the Server Requests Business Service to Call EIM” on page 306

You can use the Server Requests business service to call EIM.


Topic Description



Additional ChangesVersion 8.1, Rev A of Siebel Business Process Framework: Workflow Guide includes style changes to the content, such as topic organization and heading arrangement, and revisions to procedures.

NOTE: The Siebel Bookshelf is available on Oracle Technology Network (OTN) and Oracle E-Delivery. It can also be installed locally on your intranet or on a network location.

“Example of Defining a Substitution when Using the Outbound Communications Manager” on page 309

You can define a substitution variable when calling the Outbound Communications Manager business service from a workflow process.

“Example of Using the Outbound Communications Manager to Send an Email to the Owner of a Product Defect” on page 310

You can use the Outbound Communications Manager to send an email to the owner of a product defect.

“Example of Externalizing Properties when Using a Business Service” on page 316

Removed references to Universal Application Network (UAN), which is no longer supported.

“Table Monitoring with a Workflow Policy” on page 326

Workflow Policies can monitor only Siebel tables. Do not use a workflow policy to monitor database tables that are external to the Siebel application, or to monitor certain Enterprise Integration Manager (EIM) tables.

“Configuring a Predefined Workflow Policy for Messaging” on page 377

You can use a predefined messaging policy to display a message in a pop-up dialog box in the Siebel client.

“How an Email Can Be Sent to an Email Address That is Held in a Custom Field” on page 384

Workflow Manager can be defined to send an email message to an email address that is stored in a column other than S_EMPLOYEE.EMAIL_ADDR.

“Defining a New Workflow Monitor Agent Server Component” on page 419

Procedure removed. Workflow Monitor Agent can no longer be run from the Siebel client. You must start Workflow Monitor Agent from the Server Manager command line interface.

“Properties of the Step and Connector of a Workflow Process” on page 450

Provides reference information for the properties of the various step types that are used in Siebel Workflow.


Topic Description



14


2 Overview of Siebel Workflow

This chapter describes a conceptual overview of Oracle’s Siebel Workflow. It includes the following topics:

■ About Siebel Workflow on page 15

■ Overview of How a Workflow Process Is Developed on page 22

About Siebel WorkflowSiebel Workflow is a customizable business application that allows you to define, manage, and enforce your business processes, thereby establishing process automation within Oracle’s Siebel applications. Siebel Workflow orchestrates the various Siebel process automation technologies. A workflow process graphically sequences a series of automation steps that support a business process, and it specifies inputs and outputs for individual steps and for the workflow process as a whole. A workflow process can be simple, such as entering a product order, or complex, such as managing a call center workflow. A complex workflow process can include multiple subprocesses.

Challenges you can address when using Siebel Workflow to manage a business process in your organization include:

■ Automating the escalation of events and notification of appropriate Siebel Workflow parties

■ Routing and assigning work

■ Processing work

■ Enforcing authorization and transition rules

Business Requirements That Can Be Addressed by Managing a Business ProcessIn theory, a business is managed according to the business processes that enforce efficiency, quality of service, adherence to contractual agreements, and profitability. The following are some examples of these business processes:

■ Allow objectives for response time to be met for customer callbacks and open service requests

■ Define review policies for important processes, such as contracts, quotes, or product shipments

■ Monitor service requests or opportunities over time

In practice, the benefits of a business process are often not realized because the business process is not consistently enforced. This situation can exist due to the large number of business processes that exist in the business environment, or because of the dynamic nature of the information being monitored.


Overview of Siebel Workflow ■ About Siebel Workflow

16

Managing important events is central to the enforcement of a business process. Workflow Management is the timely management of an event in order to allow proper handling. For example, a service department uses procedures for managing an open service request or for making sure a measurable response time is met. A workflow process can increase the visibility of these business processes within an organization and check that they are handled correctly.

A service department uses business rules that match the requirements of the business:

■ 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, a customer can purchase a support agreement that guarantees a callback within two hours and problem resolution within four hours.

A sales department uses business rules to enforce the required practices of the business:

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

■ Pipeline management. Each sales representative manages their pipeline in order to promote sufficient levels of prospects at each stage of the sales cycle. If an area of the pipeline requires attention, then the representative or manager must be alerted.

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

Overview of Technologies That Are Used to Automate a Business ProcessSiebel Workflow brings together Workflow Processes and other repository configuration objects, including the Workflow Policies module, to establish a comprehensive workflow design. Some of the technologies for automating a business process that are available to a Siebel application are described briefly in this topic. While each of these technologies provide specific functionality to automate a business process in the Siebel application, Workflow Processes can orchestrate many of the services that the technologies perform. A workflow process orchestrates services by directly calling each technology, or by interacting with other technologies through the Siebel event model.



Table 2 describes automation technologies.

Table 2. Automation Technologies

Automation Technology Description

Workflow Process Allows you to define business processes for your company by using a familiar flowcharting interface. Consists of one or more process steps, such as a start step, subprocess step, decision point, and task. Workflow Processes is the key technology behind building business processes in the Siebel application.

Workflow Policy Allows you to define workflow policy conditions and actions that can start a workflow process. If workflow policy conditions are met, then the policy action executes the relevant workflow process. A workflow policy generates an event based on a database operation. A workflow policy is effective for performing a simple action, such as sending email, or generating an activity or assignment.

Siebel Task UI Allows you to define a user interface with multiple step, interactive operations that can include branching and decision logic to guide an end user through Siebel Task UI execution. Allows navigation backward and forward within task UI execution, and allows a task UI to pause and resume. For more information, see Siebel Business Process Framework: Task UI Guide.

Assignment Manager Expresses rules to assign records to people. Allows assignment of records based on skill, workload, and availability. Supports ownership transition within a business process. For more information, see Siebel Assignment Manager Administration Guide.

SmartScript Guides the end user through data entry activities. Effective for call scripting and includes basic support for transaction level commits. For more information, see Siebel SmartScript Administration Guide.

Activity Template Provides a predefined series of steps to be performed. Effective for handling asynchronous and offline work. For more information on Activity Template, see Siebel Applications Administration Guide.

State Model Restricts transition of record status based on a current value and the position of the user. Can also enforce directional progression of status. For example, opportunities move forward but not backward through a pipeline. For more information on the State Model, see Siebel Applications Administration Guide.



18

Overview of Objects That Are Used with a Workflow ProcessTo plan for building a workflow process, it is important to understand the basic objects that can be defined. With Siebel Workflow, the run-time engine manages process flow, application flow, and integration flow. Basic objects such as a start step, decision point, Siebel operation step, and connectors are available to build your workflow process. Some of the basic objects for a workflow process are illustrated in Figure 1.

The basic objects of a workflow process include:

1 Workflow Events. A workflow process can be started from a run-time event in the Siebel application, a workflow policy, or through a script. An event can pass context from the caller, for example a user session, to a workflow process by using a row ID. For more information, see “Determining How the Workflow Process Is Started” on page 105.

2 Workflow Rules. A workflow decision rule is a rule that guides the flow of control within the workflow process. It can be based on business component data or on a local variable in the workflow process that is known as a process property. A rule expression is defined using Siebel Query Language. For more information, see “Determining Decision Logic of a Workflow Process” on page 107.

3 Workflow Actions. A workflow action is an action in a workflow process that performs some form of data manipulation, where data is used as input, a transformation occurs or data is examined, then data is produced as output. A workflow action can perform an operation on a database record or call a business service. For more information, see “Determining Actions of a Workflow Process” on page 109.

Figure 1. Basic Objects of a Workflow Process



Scenario to Promote Timely Resolution of a Service RequestThis topic gives one example of how a workflow process can be used to resolve a service request in a timely fashion. You might use workflow processes differently, depending on your business model.

This scenario demonstrates how basic concepts for a workflow process can be used to automate a business process. Prior to implementing Siebel Call Center, a service manager for a high volume service agency felt her organization was unable to resolve many customer issues in a timely manner. To better track and manage service requests, the service manager decides to implement the service request module in order to automate the service request management process.

The goal is to meet a Service Level Agreement commitment by making sure newly logged service requests (SRs) are resolved within a specific amount of time. The service manager requires the SRs to be assigned by the Siebel application to the most appropriate representative based on the availability and skill of the representative. If the SR requires immediate attention, then the owner of the SR is notified.

The developer uses the Process Designer in Siebel Tools to define the business process for a new service request. Figure 2 illustrates how the process is displayed in the Process Designer. The diagram includes the steps and decision point that are involved when a new service request comes into the organization. For information on how this workflow fits within the development architecture, see “Overview of How a Workflow Process Is Developed” on page 22.

Figure 2. New Service Request Workflow Process in the Process Designer



20

If an SR is logged, then the workflow process is started. The workflow calls Siebel Assignment Manager to assign the SR to the service representative who is available and possesses the skills required to resolve the SR. Based on the severity of the SR, the workflow can use the Siebel Communications Server to send email notification to the representative. Automating this process helps the company achieve faster turnaround time in order to resolve SRs and to meet service commitments.

Steps That Are Used in the ScenarioTable 3 describes each step that is used in the service request scenario.

Table 3. Steps in the New Service Request Scenario

Step Name Step Type Description

Start Start Every workflow process contains a start step that is used to start the process. The condition that starts a workflow is defined on the connector that emanates out of the start step.

Open SR Branch Connector The workflow is started by the creation of a new service request.

Assign Service Request

Sub Process The service request is assigned to the appropriate service representative, based on assignment rules that are executed in the subprocess.

Severity? Decision Point The decision point uses the severity of the service request to determine the next step that is executed: Critical, High, or Medium.

Send Email Business Service If the priority for the service request is critical, then the business service step sends an email to the assigned service representative.

Set Priority to High Siebel Operation The service request priority is set to High.

Assign Substatus Siebel Operation The sub status is set to Assigned.

Email Error Error Exception Connector

If the email is undeliverable or if the Send Email business service step returns some other error, then an error exception connector is executed.

Generate Error Activity

Siebel Operation An activity is generated to manage the error.

Set Priority Very High then Dispatch

Siebel Operation The service request priority is set to Very High and the substatus is set to Dispatch.

End End The workflow process ends.



Viewing Example Workflow ProcessesTo examine examples that ground the concepts discussed in this chapter, see Chapter 12, “Examples of Defining a Workflow Process.” There are also a number of predefined workflow processes you can peruse. For more information, see “Examining Seed Workflow Processes” on page 111.

You can also view example workflow processes.

To view example workflow processes

1 In Siebel Tools, navigate to the Workflow Processes Object List Editor (OBLE).

2 Query the Comments property for *Sample*.

3 Right-click a record in the Workflow Processes OBLE, then choose Edit Workflow Process.


Overview of Siebel Workflow ■ Overview of How a Workflow Process Is Developed

22

Overview of How a Workflow Process Is DevelopedFigure 3 illustrates an overview of components that are involved when you develop a workflow process.

Components involved when developing a workflow process include:

1 Siebel Tools. Siebel Tools provides an integrated development environment for configuring various aspects of a Siebel application. The Process Designer, which resides in Siebel Tools, is used to build a workflow process. These modifications are saved in the Siebel Repository File (SRF).

Siebel Tools provides the design interface and the debugging interface to Siebel Workflow. After a workflow process is designed and tested, it is written to repository tables for deployment from the administrative interface in the Siebel client.

2 Siebel Server. The Object Manager in the Siebel Server manages the workflow process components that automate business policies.

3 Database Server. A relational database provides the set of data that Workflow Policies act against.

4 Siebel Client. Workflow processes and workflow policies are administered through the Administration-Business Process screen in the Siebel client.

For more information, see Chapter 3, “Architecture of a Workflow Process.” For a description of the Siebel Server architecture, see Siebel System Administration Guide.

Figure 3. Overview of Workflow Development



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

You define a workflow process that consists of process steps, such as a start step, decision point, subprocess step, or business service step. Work can be finished with a predefined business service or a custom business service. A predefined action can include an update to the Siebel database, a notification, such as an email or page, an integration message to an external system, or a call to a server task. A custom action can be defined by using Siebel VB or Siebel eScript.

For more information, see Chapter 6, “Developing a Workflow Process.”

A workflow process is administered through the Administration-Business Process screen in the Siebel client. For more information, see Chapter 11, “Administering a Workflow Process.”



24


3 Architecture of a Workflow Process

This chapter describes architectures that are used with Siebel Workflow. It includes the following topics:

■ About the Architecture of a Workflow Process on page 25

■ How a Workflow Process Interacts with Other Siebel Components on page 36

Siebel Workflow is an interactive software tool that allows you to automate how your organization handles workflow processes. The basic model for a workflow process is similar to the process model that an organization uses in sales, marketing, and service departments that determine business workflow. You can use a workflow process to promote consistency and adherence to a business process through the automatic enforcement of business policies and procedures.

About the Architecture of a Workflow ProcessThis topic describes the workflow process architecture. It includes the following topics:

■ Development Architecture of a Workflow Process on page 26

■ Simulation Architecture of a Workflow Process on page 28

■ Deployment Architecture of a Workflow Process on page 30

■ Run-Time Architecture of a Workflow Process on page 31

The following topics also include information of an architectural nature:

■ About the Object Hierarchy of a Workflow Process on page 39

■ Overview of Workflow Policy Objects on page 323

■ Sequence of a Workflow Policy on page 330


Architecture of a Workflow Process ■ About the Architecture of a Workflow Process

26

Development Architecture of a Workflow ProcessFigure 4 illustrates the development architecture of a workflow process.

The following architectural components are used to develop a workflow process:

1 Siebel Tools. The repository object for a workflow process is a top level object in the Object Explorer of Siebel Tools. You use the Object List Editor (OBLE) to define the object definition for a workflow process. A workflow process belongs to a project. There is independent versioning of a workflow process in Siebel Tools and in the Siebel client.

You use the Process Designer in Siebel Tools to develop a workflow process. In the Process Designer, you use process properties to define a workflow, or alternatively, you can enter data through unbounded picklists. In the Process Designer, configuration data is available, but run-time data is not available.

2 Repository Tables. A workflow process that is under development is stored in the Siebel repository tables and run-time tables. When you edit the workflow in Siebel Tools, it is stored in the repository tables. When you deploy a workflow, it is also inserted into the run-time tables. To deploy a workflow, you publish, then activate it.

3 XML file. A workflow process can be exported as an XML file.

4 SIF File. A workflow process can be exported as a sif file (Siebel archive file).

Figure 4. Development Architecture of a Workflow Process



You can also use Application Deployment Manager (ADM) to migrate workflow processes from one Siebel environment to another.

For more information, see:

■ Migration with Application Deployment Manager on page 219

■ Overview of How a Workflow Process Is Developed on page 22

Functional View of Developing a Workflow ProcessFigure 5 illustrates a typical approach for developing a workflow process.

This approach outlines activities typically performed when a workflow process is developed:

1 Define. Siebel Tools is used to define the workflow process.

When defining a workflow process, you define the object definition for the workflow process, define process properties, add steps and connectors, and so forth.

2 Save. The workflow process is frequently saved to the local database.

Figure 5. Typical Approach to Developing a Workflow Process



28

3 Test. The Siebel client is used to test the workflow process.

4 Debug. Siebel Tools, the Siebel client, and the local master or test database are used to publish, activate, and debug the workflow process.

The workflow is checked out from the repository into the local database, where it is modified and debugged locally before checking in to the master repository. Debugging against a server or test database instead of debugging locally allows the Workflow Engine to access server components, such as the Server Request Broker. During the development effort, work that you can optionally perform in Siebel Tools include:

■ Check the workflow process into and out of your master database.

■ Export the workflow process to an XML file for backup purposes, or import the workflow process from an XML file to restore it.

5 Verify. To verify that the workflow process implements the functionality described during the planning phase, the workflow process is run from the Siebel client by using the local master or test database.

6 Migrate. The workflow process is migrated from the master database to the staging or production database.

Simulation Architecture of a Workflow ProcessAfter you define a workflow process, you can test it by using the Process Simulator. Testing your workflow before migrating it to the production environment verifies that the resulting actions are accurate and useful, and that the results meet your business requirements.



Figure 6 illustrates the architecture to simulate a workflow process.

Architectural components to simulate a workflow process include:

1 The Process Simulator accesses object definitions that are part of the workflow process or that are referenced by the workflow process.

2 Depending on how the workflow is defined, user data in the run-time database, such as data that resides in various fields of an opportunity, is accessed or manipulated during the simulation.

If the workflow process is run from the Process Simulator, then it runs in the application object manager. The workflow can be started in the application object manager or in a server session of the Workflow Process Manager, depending on specific parameters.

For more information, see “About the Testing Tools” on page 197.

Figure 6. Architecture to Simulate a Workflow Process



30

Deployment Architecture of a Workflow ProcessAfter you define and test a workflow process, it is deployed. Deploying includes performing the following work:

1 Publishing. Reading object definitions for a workflow process that exist in the Siebel repository tables, then writing those definitions, along with deployment parameters, into the run-time tables.

2 Activating. Making the workflow process available for use in the Siebel client.

Figure 7 illustrates the relationship between Siebel Tools and the Siebel client when deploying a workflow process.

The following process is used to deploy a workflow process:

1 The workflow process is marked Completed for deployment.

2 The workflow process is read from the repository.

3 When activated, the workflow process is written to the run-time tables.

4 Some parameters of the deployed workflow process can be modified in the Siebel client.

Figure 7. Architecture to Deploy a Workflow Process



To deploy a workflow process, it is not necessary to compile the SRF, nor is a merge required. Workflow components and definitions are defined in Siebel Tools and are stored in the repository that is used by Siebel Tools. Before you can run a workflow as a server task or from the Siebel client, you must first publish the workflow from Siebel Tools, then activate the workflow from the Siebel client. If you use Publish/Activate in Siebel Tools rather than Publish, then it is not necessary to separately activate the workflow in the Siebel client.

Run-Time Architecture of a Workflow ProcessThis topic includes the following topics:

■ Overview of the Run-Time Architecture of a Workflow Process on page 31

■ Workflow Process Manager on page 32

■ Modes of a Workflow Process on page 35

■ How a Workflow Process Is Started on page 35

■ Administration and Monitoring of a Workflow Process on page 35

Overview of the Run-Time Architecture of a Workflow ProcessThe run-time architecture for Siebel Workflow is based on the Siebel Object Manager layer and the server infrastructure layer of the architecture for Siebel Business applications. The run-time environment is available both as a business service and as a server component. The following modes are used to start and resume a workflow process:

■ Local Synchronous

■ Remote Synchronous

■ Remote Asynchronous



32

Figure 8 illustrates the run-time architecture for a workflow process.

Workflow Process ManagerThe Workflow Process Manager (WfProcMgr) is a server component that uses the Siebel Object Manager framework and runs a workflow process as a business service. The Workflow Process Manager, which hosts the Business Object layer and the Data Object layer provides the ability to run multiple object managers and multiple server tasks for each object manager. The term Workflow Process Manager refers to both the Workflow Engine and the workflow server components.

The Workflow Process Manager is in an Online status it is considered active and can receive and process requests. The Workflow Process Manager is inactive in other statuses, such as Shutdown and Offline. In such cases, requests to the Workflow Process Manager and Workflow Process Batch Manager (WfProcBatchMgr) server components cannot be processed. For example, if a request is saved to the database, and if the request is submitted in DirectDB, then the request can be submitted later when the Workflow Process Manager comes back online. Otherwise, the request is lost.

For more information, see “Starting a Workflow Process Through the Workflow Process Manager” on page 150.

How Siebel Workflow is Run as a Business ServiceExecution for Siebel Workflow in an application object manager is started as a business service. The Workflow Process Manager business service and the Workflow Process Manager (Server Request) business service are referred to collectively as the Workflow Engine. As a business service, the Workflow Engine uses input arguments and returns output arguments.

Figure 8. Run-Time Architecture for a Workflow Process



Table 4 describes how the business service determines where the workflow process is run.

How Siebel Workflow is Run in the Workflow Process Manager Server ComponentA workflow process can be executed in the background by using a Workflow Process Manager server component that is configured and optimized to run the Workflow Process Manager business service. The Workflow Process Manager server component acts as the object manager to run the workflow process, including application logic within the workflow process.

The Workflow Process Manager accepts the process name in the following ways:

■ Through the Process Name component parameter. For example, when starting a server task from Server Manager or (Repeating) Server Component Requests.

■ Through the Encoded Args component parameter. For example, when a request is submitted from the Workflow Monitor Agent business service or the Server Requests business service.

If a workflow policy starts a workflow process, then the Workflow Monitor Agent typically uses Encoded Input Arguments to pass input arguments to the Workflow Process Manager. However, setting Encoded Input Arguments in the Component Request Parameters applet fails because it is not in a format that can be recognized by the Workflow Process Manager server component.

Table 4. How the Business Service Determines Where the Workflow Process Is Run

Business Service Location Where Workflow Process Is Run

Workflow Process Manager The object manager of the application that is called.

Workflow Process Manager (Server Request)

The Workflow Process Manager server component.



34

Components in the Workflow Management Server Component GroupTable 5 describes server components that are used in the Workflow Management server component group.

Table 5. Components in the Workflow Management Server Component Group

Server Component Alias Description

Workflow Process Manager

WfProcMgr The following functionality is provided by the Workflow Process Manager and Workflow Process Batch Manager server components:

■ Acts as the application object manager to run workflows

■ Are specialized server components configured and tuned to run workflow processes

■ Similar to server components, provides a multi threaded environment

Workflow Process Batch Manager

WfProcBatchMgr

Workflow Monitor Agent

WorkMon Executes and monitors workflow policies, then executes actions when the conditions of a workflow policy are met.

Workflow Action Agent

WorkActn Process requests are logged in the action request table, S_ESCL_ACTN_REQ, for a policy group and calls actions that are linked with the workflow policy that is being processed.

Workflow Recovery Manager

WfRecvMgr Polls the Workflow Engine to check for instances of workflow processes that are running on the server. Recovers failed instances and resumes instances that are waiting beyond a due date. For more information, see “About the Workflow Recovery Manager” on page 246.

Generate Triggers

GenTrig The following functionality is provided by the Generate Triggers component:

■ Allows you to define database triggers that Workflow Policies uses to identify records that match the conditions of a workflow policy

■ Must be rerun when a new policy is defined or deleted, and when an existing policy is updated

■ Can be run from either the Server Manager graphical user interface, or through a command line interface



Modes of a Workflow ProcessThe following modes of a workflow process characterize run-time behavior:

■ Service Flow. A workflow process that executes a set of operations upon calling an event.

■ Interactive Flow. A workflow process that assists the end user in navigating across Siebel views.

■ Long-Running Flow. A persistent workflow process that can last for hours, days, or months.

■ 7.0 Flow. A workflow process that provides backward compatibility for a workflow that was defined earlier than version 7.7.

The mode is set through the Workflow Mode property in the Workflow Processes OBLE in Siebel Tools. For more information, see “Types of Modes for a Workflow Process” on page 127.

How a Workflow Process Is StartedA workflow process can be started from an event in the Siebel application or from an external system. The ways that a workflow process can be started within the Siebel application include:

■ From a workflow policy

■ From an event, such as an insert of a record or a button click

■ By a server component

This book describes how to start a workflow process through these mechanisms. For more information, see “Starting a Workflow Process” on page 143.

Administration and Monitoring of a Workflow ProcessYou can use the Administration-Business Process views in the Siebel client to administer and monitor a workflow process. The following work that can be performed in these views:

■ Stop a workflow process

■ Delete a workflow process instance

■ Purge a workflow process instance from the database

■ Monitor a workflow process that is running

■ Recover a workflow process that is interrupted

For more information, see “Process of Administering a Workflow Process” on page 227.


Architecture of a Workflow Process ■ How a Workflow Process Interacts with Other Siebel Components

36

How a Workflow Process Interacts with Other Siebel ComponentsThis topic describes how Siebel Workflow interacts some other Siebel components.

Siebel Server ComponentsThe Workflow Engine interacts with other server components through the Server Request Broker. Working as a business service, the Workflow Engine calls server components. To call a server component that is exposed as a specialized service, the Workflow Engine calls the signature for the service. For example, to send an email, the Workflow Engine calls the Communications Server as the Outbound Communications Manager business service. To assign an object to a user, it calls the Assignment Manager component as the Synchronous Assignment Manager Requests business service.

To call a server component that is not exposed as a specialized service, the Workflow Engine uses the predefined Server Requests business service. This business service sends a generic request to the Server Request Broker. For more information, see “Server Requests Business Service” on page 482.

Server Request BrokerThe Workflow Engine sends a request to the Server Request Broker, synchronously or asynchronously, and the Server Request Broker brokers the request to the appropriate component. The following work is performed:

■ Sending asynchronous messages from an interactive server component to the Workflow Engine

■ Communicating, synchronously and asynchronously, between the Workflow Engine and batch components

■ Scheduling repeated server tasks that are executed periodically in the Workflow Engine

The Server Request Broker also performs load balancing. If the Server Request Broker receives a request, then it routes the request to the server component in the current server. For a workflow process, if the component is not available in the current server, then the Server Request Broker sends it to other servers on a round robin basis where the Workflow Process Manager component is activated.

A workflow process also uses Server Request Broker to resume a waiting workflow process. The Server Request Broker queries a database table on a regular basis in order to identify server tasks that must be resumed.

For more information, see “Server Requests Business Service” on page 482, and Siebel System Administration Guide.

Architecture of a Workflow Process ■ How a Workflow Process Interacts with Other SiebelComponents


Personalization EngineThe Personalization engine handles run-time events, such as application events, applet events, and business component events. A workflow process handles run-time events through integration with the Personalization engine. A workflow started or resumed by a run-time event registers itself with the Personalization engine when the process is activated. If a run-time event occurs in a user session, then the Personalization engine calls Siebel Workflow in the local object manager.

InboxThe Inbox is a single screen in Siebel Business Applications that displays approval and notification items and instances for Siebel Task UI that are assigned to an end user regardless of the screen where the item originated. The Inbox displays enough detailed information about the item so that the end user can act on the item from the Inbox and not be required to navigate to other screens. For more information, see Siebel Applications Administration Guide.

Siebel Task UISiebel Task UI allows you to define a user interface that is similar to a wizard, with multiple step, interactive operations that can include branching and decision logic to guide an end user through the execution of a task UI . Siebel Task UI allows navigation both backward and forward within a task UI, and allows a task UI to be paused and resumed, as required. You can call a task UI from within in a workflow process by including a task step. For more information, see “About the Task Step” on page 84, and Siebel Business Process Framework: Task UI Guide.


Architecture of a Workflow Process ■ How a Workflow Process Interacts with Other Siebel Components

38


4 Environment for Developing a Workflow Process

This chapter describes the workflow process development environment. It includes the following topics:

■ About the Object Hierarchy of a Workflow Process on page 39

■ About the Process Designer on page 44

■ About the Process Property on page 47

■ About the WF/Task Editor Toolbar on page 62

About the Object Hierarchy of a Workflow ProcessThe object hierarchy that is used with objects for a workflow process can be viewed in Siebel Tools. You use Siebel Tools to modify standard Siebel objects and to define new objects in order to meet a business requirement for your organization. Just as you use Siebel Tools to extend the data model, modify business logic, and to define the user interface, you also use Siebel Tools to define a workflow that the Siebel application uses to automate a business process for your organization.


Environment for Developing a Workflow Process ■ About the Object Hierarchy of a Workflow Process

40

Siebel Tools consists of an Object Explorer (OE) window and one or more Object List Editor (OBLE) windows, as illustrated in Figure 9.

The Object Explorer provides navigation between each group of object definitions of a particular object type.

An object type is an entity that is displayed as an element in the Object Explorer. An object type contains a predefined set of properties and is used as the template from which object definitions are defined. Workflow Process is one object type.

An object definition implements one piece of the software. This object definition consists of object properties, which are characteristics of that piece of the software.

If the Workflow Process object type is not visible in the Object Explorer, then you must expose it. For more information, see “Exposing Object Types That Are Used to Develop a Workflow Process” on page 116.

Figure 9. Object Explorer and Object List Editor (OBLE)

Object List Editor (OBLE)Object Explorer (OE)

Environment for Developing a Workflow Process ■ About the Object Hierarchy of aWorkflow Process


Properties of an ObjectIf the Workflow Process object type is chosen in the Object Explorer (OE), then the Workflow Processes Object List Editor (OBLE) displays a list of workflow processes that are currently defined in the SRF. One row in the Workflow Processes OBLE represents one object definition. For example, values in the properties in the workflow process named Contact-New Order constitute one object definition. Properties of the object definition can be edited in the OBLE.

Object properties are represented as columns in the OBLE. Information entered into the columns of an OBLE window represent values. You edit properties of the currently chosen object definition in an OBLE window by changing values in the columns. You can change the property values in an object definition. You cannot change the set of properties that constitute an object definition.

You can also use the Properties window to edit the properties of the currently chosen object definition. Changing the value of a property in the Properties window also changes the corresponding value of that property in the Object List Editor window, and conversely.


Environment for Developing a Workflow Process ■ About the Object Hierarchy of a Workflow Process

42

Relations Between Object Types of a Workflow ProcessA parent and child relationship is a type of hierarchical relationship that exists between one Object Type and another Object Type. The parent and child relationship is represented in the Object Explorer as a hierarchical tree, as illustrated in Figure 10.

When the Types tab is chosen in the Object Explorer, the arrangement of folder icons is hierarchical. An object type that is beneath and slightly to the right of another object type is the child of the parent and child relationship. The object type that is above the child object type is the parent object type for the child. A parent object type can contain multiple child object types. For example, WF Process Metric, WF Process Prop, and WF Step is each a child object type of the Workflow Process object type.

Figure 10. Parent and Child Relationship Between Object Types in the Object Explorer

Parent and child relationship between the Workflow Process parent object type and the WF Step child object type.

Environment for Developing a Workflow Process ■ About the Object Hierarchy of aWorkflow Process


This guide assumes that you understand the basics of using Siebel Tools. The skills you must possess include:

■ Using the Siebel Tools application, particularly Object Explorer and Object List Editor usage

■ Defining object properties, applets, and applet controls

■ Using the Siebel Tools menu bar

■ Checking out and checking in projects

■ Working with projects

For more information, see Using Siebel Tools, and Configuring Siebel Business Applications.

Locating a Workflow Process in the Workflow Processes Object List EditorThis topic describes how to locate the object definition for a workflow process in the OBLE.

To locate a workflow process in the Workflow Processes object list editor

1 Open Siebel Tools.

2 If necessary, expose the workflow process object hierarchy.

For more information, see “Preparing Siebel Tools to Develop a Workflow Process” on page 115.

3 In the Object Explorer, click Workflow Process.

4 In the Workflow Processes OBLE, query the Process Name property for the workflow process you must modify.

If the workflow process exists, then the object definition for the workflow displays in the OBLE. Querying for the workflow in this way results in a single, isolated record being displayed. This technique helps to make sure that the correct workflow is chosen in the OBLE when you modify child objects for the workflow or when you perform other work, such as publishing or revising.


Environment for Developing a Workflow Process ■ About the Process Designer

44

About the Process DesignerThis topic describes the Process Designer that is used to define a workflow process in Siebel Tools. It includes the following topics:

■ Graphical User Interface of the Process Designer on page 44

■ Data That Is Available for Configuration on page 46

Graphical User Interface of the Process DesignerFigure 11 illustrates the main elements of the GUI (Graphical User Interface) of the Process Designer.

Figure 11. Graphical User Interface of the Process Designer



The Process Designer includes elements you use frequently when building a workflow process:

1 Process Designer Canvas. A work area where you build the workflow process. You right-click the canvas in order to access a context sensitive menu that allows you to perform various work on the workflow that is displayed in the canvas.

2 Workflow Designer Palette. A window that contains icons that represent the various step types you can add to a workflow process. To add a step to a workflow, you drag, then drop an object from the palette to the canvas.

3 Multi Value Property Window (MVPW). A window that allows you to define properties for a workflow process, and arguments for a step in a workflow. For more information, see “Multi Value Property Window” on page 50.

4 Properties Window. A window that allows you to define properties for an individual step in a workflow process, or for the overall workflow. The window is context sensitive. If a step or connector is chosen in the canvas, then properties for the step or connector are displayed in the Properties window. If no step or connector is chosen in the canvas, then properties for the workflow process are displayed in the Properties window. For more information, see “Overview of Workflow Process Steps” on page 65.

Functionality of the Process DesignerYou use the Process Designer in Siebel Tools to build your workflow process. The following work can be performed in the Process Designer:

■ Copy and paste. Copy and paste objects in the canvas of the Workflow Designer as you are building the workflow process.

■ Edit shape properties and layout. Define shape colors and other attributes, such as the look of the line, the fill pattern, and the font for labels. Establish consistency by controlling alignment of shapes and by making shapes the same size as other shapes in the workflow process.

■ Zoom. Zoom in and out on the canvas of the Process Designer in order to view the workflow process at various magnifications.

■ Copy drawings. Copy a workflow process into another application, such as a Microsoft Word document. In the canvas, you right-click, then choose Copy Drawing.

■ Print. Print the workflow process.

■ Hide connector and error exception connector names. You can choose to hide the names of connectors and error exception connectors within a workflow process. Hiding a connector name can be helpful in order to clarify the meaning of conditional branching that emanates from a start step or a decision point.

The copy and paste functionality works the same as with a typical Windows applications. For example, by using the CTRL+C and CTRL+V keyboard combinations. Other functionality is employed by right-clicking the canvas of the Process Designer.



46

How the Process Designer Indicates Whether a Workflow Process Is EditableThe canvas color in the Process Designer indicates whether the workflow process is editable:

■ A yellow canvas indicates the workflow process cannot be edited

■ A white canvas with a grid indicates the workflow process can be edited

If a workflow process is editable, then you can modify the workflow in a variety of ways, such as adding and removing steps and connectors, or changing step and connector properties. For more information, see “Making a Workflow Process Editable” on page 120.

Data That Is Available for ConfigurationBecause the Process Designer is in Siebel Tools, data objects are available for use as you design your workflow process. A change in the repository data is immediately available for use in a workflow without the requirement to compile the SRF. You can use configuration data, such as a business component field or other repository information, while you are building your workflow.

For example, if a List of Values (LOV), such as Account Status, contains values of Gold, Silver, and Bronze, then you can use a newly added LOV in a decision condition of your workflow process as you define it. For another example, if you add a field to a business component, then that new field is readily available for use in the Process Designer.

The type of data that is not available for use in designing a workflow process is run-time data, such as an account name or a ZIP code, and other transactional data. To use run-time data while you are building a workflow process, make the data available through a process property. If necessary, you can also hard code run-time data into your workflow by using an unbounded picklist. For more information, see “About the Process Property” on page 47.

Environment for Developing a Workflow Process ■ About the Process Property


About the Process PropertyThis topic describes information about process properties. It includes the following topics:

■ Process Property and the Property Set on page 48

■ Arguments of the Step of a Workflow Process on page 49

■ Multi Value Property Window on page 50

■ Process Properties That Are Predefined on page 54

■ Manipulating a Process Property on page 57

A process property is a container that stores a value that the workflow process retrieves from the database or derives before or during processing. You can use the value that is stored in a process property in the following ways:

■ Pass information between objects. For example, between steps in a workflow process, between a workflow process and a subprocess, or between a workflow and a business service. The process property is defined as an input or output argument for a workflow step.

■ Base a decision branch on the value in a process property.

■ Use the value in a process property in an expression.

When a workflow process finishes, the final value of each process property is available as a separate output argument that can be passed to another object.

For more information about:

■ How a process property is defined in Siebel Tools, see “Defining a Process Property for a Workflow Process” on page 124

■ An example that uses a process property, see “Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete” on page 264

■ Arguments that are used with a process property, see “Fields and Arguments of Process Properties” on page 462

■ A detailed description of property sets, see Integration Platform Technologies: Siebel Enterprise Application Integration



48

Process Property and the Property SetA property set is a hierarchical structure that contains name and value pairs, known as properties, at each level in the hierarchy. The process property stores data that is associated with the property set. A workflow process uses a property set in order to pass data to and from a step that exists within a workflow process.

Figure 12 illustrates how a process property can be used within a workflow process.

Example usage within a workflow process is described in the following sequence:

1 A process property is used to send data to Workflow Step 1 as an input argument.

2 Workflow Step 1 manipulates the data according to the configuration for Step 1.

3 An output argument on Workflow Step 1 sends data from the step to the process property.

4 An input argument on Workflow Step 2 brings the data that is manipulated in Step 1 into Workflow Step 2, where it can be manipulated according to the internal configuration that is defined for workflow Step 2.

The process property and step arguments are defined in the Multi Value Property Window. For more information, see “Multi Value Property Window” on page 50.

Initial Values of a Process PropertyWhen a workflow process is started, a process property that is of type string, number, or date with an In/Out type of In or In/Out is initialized to the input property with the same name, if one exists. A hierarchy process property with an In/Out type of In or In/Out is initialized with child input property sets that contain a matching name. A process property that contains a Default String set to [Value] is initialized with the value in the Value property of the input property set.

Figure 12. How a Process Property Can Be Used within a Workflow Process



Concluded Values of a Process PropertyWhen a workflow process concludes, a process property that is of type string, number, or date with an In/Out type of In or In/Out is stored as a property in the output property set. A hierarchy process property with an In/Out type of In or In/Out is stored as a child property set. If a process property with the name [Value] is defined, then the value of the property is stored in the Value property of the output property set.

NOTE: The process property [Value] can also be used to pass binary data in a sub process step. The input argument [Value] of the subprocess can be initialized with data in the main process, then retrieved in the sub process step.

For more information, see “Passing Data to and from a Workflow Process” on page 182.

Arguments of the Step of a Workflow ProcessAn argument is a part of the process property hierarchy that allows you to define values for fields. An argument field is a variable on an argument that allows you to define a value that shapes the parameters of a process property.

Table 6 describes how an argument can be defined in the MVPW in order to pass data to and from an individual step in a workflow process.

A step for a workflow process can contain several types of arguments. The type of step determines the possible arguments that can be defined. The Type field for an argument affects other fields in the argument that must be defined. For more information, see “Defining an Argument of a Step in the MVPW” on page 53.

Input Arguments of the Business Service Step, Sub Process Step, and Wait StepAn input argument allows you to define the value for a field that you must pass to the method of a business service. There are many methods that require an input argument. For more information, see “Fields of an Input Argument of a Process Property” on page 465.

Table 6. Arguments That Can Be Defined on a Workflow Process Step

Argument Description

Input Argument Used to bring data into a workflow process step.

Output Argument Used to send data out of a workflow process step.

Search Specification Used to define a search specification for a Siebel operation step.

Recipient Used to define a recipient for a task step or a sub process step.



50

Output Arguments of the Business Service Step, Sub Process Step, and Siebel Operation StepAn Output argument can be the result of work that is performed by the method of a business service. An output argument can be stored in a process property. A calculated field is not available as a value for an input or an output argument. If you must use a calculated value, then use an expression. For more information, see “Fields of an Output Argument of a Process Property” on page 466.

Process Properties of the Business Service StepProcess properties for the business service step include a data type of hierarchy, integration object, or strongly typed integration object, and can be used as an input or output argument for the method of a business service that includes a data type of hierarchy, integration object, or strongly typed integration object. If you must call a workflow process through a business service, then you can map the data that is contained in the input and output property sets to and from a process property. This technique is useful when you must run a workflow within a script.

Multi Value Property WindowThe Multi Value Property Window (MVPW) is a window that can be used to define a process property. It can also be used to define an argument for a workflow process step. Table 7 describes this usage.

For an example that uses the MVPW, see “Defining the Workflow Process” on page 266.

MVPW Usage with the Process PropertyProcess properties appear when the canvas is first opened for editing, or when no object is chosen in the Process Designer. For more information about the following:

■ An illustration of the MVPW that displays a predefined process property, see Figure 11 on page 44.

■ A description of how the process property and the step argument work in conjunction with one another, see “Process Property and the Property Set” on page 48.

Table 7. How the Multi Value Property Window Is Used

Object Description How Defined

Process Property Used to store values that apply to the entire workflow process.

Click the canvas of the Process Designer, then use the MVPW.

Step Argument Used to communicate information between a process property and an individual step in a workflow process.

Click a workflow process step, then use the MVPW.



MVPW Usage with the Step ArgumentFigure 13 illustrates the MVPW displaying arguments for an object in the workflow process. These arguments are displayed when an object is chosen. In this example, the Set Commit Time in 1 Hour Siebel operation step is chosen. Three input arguments for the step are displayed in the MVPW.

Elements displayed in the MVPW when an object is chosen include:

1 Argument tab. The argument tabs change based on the type of step that is chosen.

2 Field. A field in the MVPW is a parameter you can specify that provides instructions for the argument. Figure 13 displays the Field Name, Sequence, Type and Value fields.

3 Argument. Each row in the MVPW represents a single argument. The collection of fields for a row constitute the definition for the argument.

Figure 13. Multi Value Property Window Displaying Arguments for an Object



52

Viewing the Definition of an Argument in the Object ExplorerThe definition of an input or output argument that is displayed in the MVPW when an object is chosen in the Process Designer is also visible through the Object Explorer.

To view the definition of an argument in the object explorer

1 Locate the workflow process.

For more information, see “Locating a Workflow Process in the Workflow Processes Object List Editor” on page 43.

2 In the Object Explorer, expand the Workflow Process tree.

3 Expand the WF Step tree.

4 In the WF Steps OBLE, choose the workflow process step of interest.

5 In the Object Explorer, click WF Step I/O Argument.

The definitions for the input and output arguments that are defined for the step are displayed in the WF Step I/O Arguments OBLE.

Viewing a Process Property in the MVPWIf you click the canvas with no step or connector chosen, then the child objects of the overall workflow process are displayed. The Process Properties tab in the MVPW displays the definitions of the process properties.

To view a process property in the MVPW

1 If necessary, expose the MVPW by choosing, from the application-level menu, the View menu, Windows, then the Multi Value Property Window menu item.

2 In the Process Designer, click the canvas of the workflow process.

3 Make sure no steps or connectors are chosen.

4 In the MVPW, make sure the Process Properties tab is chosen.

5 Examine the records that are displayed in the MVPW.

Viewing an Argument of a Step in the MVPWIf you click a step in the canvas of the Process Designer, then the input and output arguments for the step are displayed in the MVPW. Depending on the type of step chosen, the MVPW displays one or a combination of tabs.



To view an argument of a step in the MVPW

1 Click a step in the process designer.

If necessary, expose the MVPW by choosing, from the application-level menu, the View menu, Windows, then the Multi Value Property Window menu item.

2 Choose the required tab in the MVPW, then examine the arguments that are displayed.

Defining an Argument of a Step in the MVPWYou can define an input or output argument for a step in the MVPW.

To define an argument of a step in the MVPW

1 In the Process Designer, click the step on which you must define an argument.

2 In the MVPW, click an arguments tab.

3 In the MVPW, right-click anywhere below the column headings, then choose New Record.

4 Define the argument field.

For example, if you are defining an input argument on a Siebel operation step, then define the Field Input Argument.

5 Define the Type field and other fields, as necessary.

For more information, see “How the Type Field Affects Other Fields of a Step Argument” on page 53.

How the Type Field Affects Other Fields of a Step ArgumentThe value you choose in the Type field for a step argument determines how you define other fields of the argument in the MVPW.



54

Table 8 describes how to define an argument based on the type you choose.

Changes for Siebel CRM Version 8.0With Siebel CRM version 8.0, the Multi Value Properties Window (MVPW) replaces the list applet in most cases in the Process Designer. Rather than viewing properties for a step by clicking the step, then accessing a list applet below the canvas, you view properties for the step in the Properties window and child items for the step in the MVPW. Rather than right-clicking a step to view input and output arguments for the step, you view them in the MVPW. You can add and delete values from within the MVPW in the same manner as was performed in earlier releases in the list applets.

Process Properties That Are PredefinedThe following list includes some of the default process properties that are automatically defined for each workflow process:

■ Object Id. The Siebel row ID of the record against which the workflow process is started.

■ Error Code. An error symbol of the instance of the workflow process if a step returns an error. This process property is automatically populated when an error occurs.

■ Error Message. A text error message of the instance of the workflow process if a step returns an error. This process property is automatically populated when an error occurs.

Table 8. How to Define an Argument in the MVPW Based on the Type You Choose

Type You Chose Work You Perform

Business Component Choose a business component from the picklist in the field for the Business Component Name, then choose a business component field from the picklist in the field for the Business Component Field.

Expression Type an expression into the Value field.

Alternatively, you can click the dropdown button to launch the Expression Builder. The expression you enter is evaluated at run time to determine the value.

Literal Type a string into the Value field.

The value you enter defines the literal value for the argument.

Process Property Choose a Property Name from the pick applet for the Property Name field.

Process Property is only available for an input argument.

Output Argument Choose a property from the picklist in the Output Argument field.

The picklist allows you to choose process properties that are of type In/Out or Out. Output Argument is only available for an output argument.



■ Siebel Operation Object Id. The Siebel row ID of the record that is updated, created, or queried during a Siebel operation step. This process property is automatically populated when a Siebel operation step is executed.

■ Process Instance Id. A unique number that is assigned to the currently running instance of the workflow process. This process property is automatically populated when a workflow is executed and persistence is activated.

Object Id Process PropertyThe Object Id process property is the Siebel Row Id of the primary business component record against which a workflow process is started.

Run-Time Event BehaviorIf a workflow process is started by a run-time event, then the instance of the active business component that started the run-time event is automatically passed to Siebel Workflow. A run-time event is received on the row that is defined by the Object Id property. Siebel Workflow receives and processes this event only when the business object that the instance of the active business component belongs to is the same as the business object in the definition for the workflow process. If Siebel Workflow can receive this event, then the Object Id process property is automatically set to the active row of the primary record in the business object.

If the business component that started the run-time event is not the primary business component, then the active row of the business component is not reflected in the Object Id process property, and it must be retrieved through some extra processing.

Behavior for Long-Running, Interactive, and Service Workflow ProcessesThe following list describes behavior of the long-running, interactive, and service workflow processes:

■ The Object Id must match the Row ID of the active row for the primary business component. The Workflow Engine does not allow the active row of the primary business component to be different from the Object Id process property. If the Object Id process property is different from the active row, then the primary business component is executed again to make the active row the same as the Object Id.

■ It is possible to change the active row by assigning a new Row Id to the Object Id property. If Siebel Workflow detects that an assignment is made to the Object Id process property, then Siebel Workflow executes the business component again and makes the new Row ID the active row.

■ If you set the Object Id to an empty string, then Siebel Workflow does not enforce the must match rule. However, the parts of Siebel Workflow that require an Object Id, such as the run-time event and Siebel operation step, cannot be used until the Object Id is set to a new Row ID.



56

Changing the Active Row in a Workflow Process StepYou can add a step that performs an operation that results in a change of the active row.

To change the active row in the step of a workflow process

1 Add a Siebel operation or business service step that performs an operation that results in a change of the active row.

2 Update the Object Id process property to the new active Row ID in the output argument of the workflow process step you added in Step 1.

After a workflow process step finishes and output arguments are evaluated, Siebel Workflow checks to make sure the Object Id matches the active row. Therefore, a change to the active row must be reflected in the Object Id property within the affected step.

In/Out Process PropertyIf necessary, you can run a workflow process and avoid receiving response data back. For example, to avoid inserts to the S_SRM_DATA table that can cause a heavy backlog. Configuration within a workflow process determines whether response data is returned. If the type of a process property is Out or In/Out, then outputs are returned to the caller. For example, outputs are returned to the Server Request Processor. If the caller receives a response that is not null from a callee, then it writes the response into the S_SRM_DATA table. If no response data is received, then the response is not written into the S_SRM_DATA table.

If a request is inserted into the S_SRM_REQUEST table, then one or more rows are inserted into the S_SRM_DATA table for the component request parameters and input arguments that are used by the request. During submission of a request, the S_SRM_DATA table column MSG_TYPE_CD contains a value of REQ_DATA, which indicates the type of data is to request data or inputs for the request. If the request finishes execution, then a set of rows is also inserted into the S_SRM_DATA table with the MSG_TYPE_CD column having a value of REQ_RESPONSE, which indicates that the request returned a response back to the caller. In this case, because the request is in the S_SRM_REQUEST table, the caller is the Server Request Processor component.

Running a Workflow Process to Avoid a Response Data InsertYou can run a workflow process to avoid response data inserts.

To run a workflow process to avoid a response data insert

1 Define one of the following options:

■ Until immediately upstream of the end of the workflow process, leave the In/Out property of the process property set to In/Out.

■ Immediately upstream of the end of the workflow process, call another step that nulls out values that are stored in the process properties. In this way, the Server Request Processor receives no response text and an insert is not made into the S_SRM_DATA table.

2 Review process properties for the workflow process, then set the In/Out property to NONE.



Manipulating a Process PropertyThis topic describes how a process property is manipulated. It includes the following topics:

■ Passing a Process Property In and Out of a Step of a Workflow Process on page 57

■ Passing a Process Property by Reference on page 58

■ Passing a Process Property to an Error-Workflow Process on page 58

■ Concatenating a Process Property on page 59

■ Referencing a Process Property on page 60

Passing a Process Property In and Out of a Step of a Workflow ProcessIn a long-running, interactive, or service workflow process, when a hierarchical process property is passed to a step in a workflow process, the Type field of the top level process property is overwritten by Siebel Workflow for the duration of the call in order to match the name of the argument, as defined by the configuration for the input argument.

For example, assume MyTree is a process property with data type Hierarchy. MyBusSvc is a business service that contains a hierarchical Input Argument named SomeTree. Consider the process property described in Table 9.

If the input argument is defined with the values that are displayed in Table 9, then the call into MyBusSvc receives a child in the input process property for the argument with the Process Property Type field set to SomeTree , instead of MyTree. The rest of the data in the child process property is the same as the contents of the MyTree process property.

Similarly, Siebel Workflow expects an output argument of a step in a workflow process that passes out a hierarchy to send it out as a child of the output property set. Siebel Workflow locates the child by examining the Type field of the child.

The string in the Type field must match the name for the Output Argument, as defined in the output argument applet of the step. After Siebel Workflow finds such a child, the data is copied into the indicated destination process property. However, the Type field on the incoming hierarchy is discarded, and instead the name of the process property overwrites the Type field.

To summarize, when passing a hierarchy into and out of a step, the Type field of the top level of the data is used as the name of the argument.

NOTE: It is recommended the Type field of the top level of a hierarchical argument not contain data.

Table 9. Example of a Process Property in the MVPW

Input Argument Type Property Name

SomeTree Process Property MyTree



58

Passing a Process Property by ReferenceA subprocess that modifies a large amount of data must copy a large amount of data through input and output arguments. This situation can negatively affect the performance and scalability. If you can avoid unnecessary copying of data, then you can achieve improvements in performance and scalability.

Pass By Reference is a feature that allows you to avoid passing a large property set by passing just a pointer to the property set. You can use Pass By Reference for a workflow process by using a sub process step. For more information, see “Pass By Reference Feature for a Business Service” on page 71.

Passing a Process Property to an Error-Workflow ProcessYou can pass more than just a system defined process property to an error-workflow process. The following conditions apply when a process property is passed to an error-workflow process:

■ To pass the original instance of a workflow process to a process property that is defined by the user to the error workflow, you must explicitly redefine those user-defined process properties in your error workflow, giving them the same name and data type.

■ To pass a property set from the original workflow process to the error workflow, you must define a common user-defined hierarchy process property in the original workflow and in the error workflow, then use this common hierarchy property to pass the property set.

■ To get the name of the original workflow process, you must define a common user-defined process property in the original workflow and in the error workflow, then pass the original name for the workflow through this common user-defined process property.

To pass a process property to an error-workflow process

1 Define an error exception connector.

For more information, see “Defining an Error Exception Connector” on page 165.

2 Click the stop step, then define an input argument in the MVPW using values from the following table.

3 In the Workflow Processes OBLE, define a new workflow process that references the error-workflow process.

Field Value

Name %1

Type Literal

Value Error Message (or a valid string)



Concatenating a Process PropertyYou can use values for a process property in an expression by concatenating properties of a workflow process with other process properties or with text. The following example illustrates how four process properties can be used in a workflow to concatenate three string values. The three process properties contain values in the Default String property of Welcome, to, and Siebel.

To concatenate a process property

1 In Siebel Tools, in the Workflow Processes OBLE, define a new workflow process using values from the following table.

For an example, see “Defining the New Workflow Process” on page 256.

2 Open the Process Designer for the workflow process you defined in Step 1, then define the flow to resemble the following diagram:

For more information, see “Overview of Workflow Process Steps” on page 65, and “Diagramming a Workflow Process” on page 122.

3 In the MVPW, define four process properties using values from the following table.

For more information, see “Multi Value Property Window” on page 50.

4 Click the wait step, then click the Output Arguments tab in the MVPW.

The wait step is often used for testing and development. For more information, see “About the Wait Step” on page 87.

Property Value

Process Name Concatenate

Business Object Account

Workflow Mode Interactive Flow

Name In/OutBusiness Object Default String Data Type

ProcessProperty1 In/Out Account Welcome String

ProcessProperty2 In/Out Account to String

ProcessProperty3 In/Out Account Siebel String

ProcessProperty4 In/Out Account (no value) String



60

5 Define an Output Argument for the wait step using values from the following table.

The ampersand (&) identifies the text that immediately follows the ampersand as the name of a process property. The process property you indicate can also be the name of a field in a business component. ProcessProperty1, ProcessProperty2, and ProcessProperty3 can be of different types, such as string or date.

The Data Type property for the process property in this example must be set to String. Because an error might occur when a binary type is used with an expression, you cannot use an expression in order to set a process property whose Data Type property is set to binary. An example error in this situation is a process property that includes truncated data.

6 Validate, then simulate the workflow process.

For more information, see “Process of Testing a Workflow” on page 202.

7 After control returns to Tools, right-click the Simulation window, then choose Watch Window.

8 In the Watch window, expand PS:Property Set.

9 Note the values for the four process properties that you defined in Step 3.

10 Click Simulate Next.

In the Watch window, ProcessProperty4 now contains a concatenation of values from ProcessProperty1, ProcessProperty2, and ProcessProperty3.

Referencing a Process PropertyA process property can be referenced from within an expression. The syntax is [&PropName]. For example:

[&Object Id] like '99-28B1T'

where:

■ & indicates a process property

■ Object Id is the name of the process property

Type Output Arguments Value

Expression ProcessProperty4 [&ProcessProperty1]+' '+[&ProcessProperty2]+' '+[&ProcessProperty3]



The following example illustrates how a process property can be used as a substitution variable within a more complex expression. This example uses an input argument to establish a message body:

The Activity #" + [&Object Id] + ", owned by " + [&First Name]+" "+[&Last Name] + " is three days past the Due Date.

where:

■ Object Id, First Name, and Last Name are defined as process properties.

For more examples of using a process property as a substitution variable, see “Example of Defining a Siebel Operation Search Specification” on page 77 and “Substitution Variables That Are Commonly Used in an Expression” on page 194.


Environment for Developing a Workflow Process ■ About the WF/Task Editor Toolbar

62

About the WF/Task Editor ToolbarThe WF/Task Editor Toolbar is used to manage deployment of a workflow process. Figure 14 illustrates how the toolbar is displayed in Siebel Tools.

For procedural information on publishing and activating a workflow process, see “Process of Deploying a Workflow Process” on page 211.

Buttons on the WF/Task Editor ToolbarTable 10 describes buttons on the WF/Task Editor Toolbar. To identify a button in the WF/Task Editor Toolbar, position your mouse over an icon in the toolbar, then note the name for the button when it is displayed in a small pop-up message.

Figure 14. WF/Task Editor Toolbar in Siebel Tools

Table 10. Buttons on the WF/Task Editor Toolbar

Button Name Description

Publish Moves the definition of a workflow process from the repository tables into the run-time tables of the Siebel client.

If you click Publish, then the status of the workflow process changes from In Progress to Completed, and is available in the following situations:

■ If you are connected to the server data source, then the finished workflow process is ready to be activated at run time.

■ If you are connected to the local data source, then check in the workflow process. After you check in the workflow, it is ready to be activated at run time.

Publish/Activate Publishes and activates the workflow process with a single button click from within Siebel Tools while in local mode. If you use Publish/Activate rather than Publish to publish the workflow, then it is not necessary to separately activate the workflow in the Siebel client.

To use this feature, you must also set the [Workflow] VerCheckTime parameter to -1 (negative 1) for the Siebel client on which you are testing. For more information, see “Preparing Siebel Tools to Develop a Workflow Process” on page 115.



Exposing the WF/Task Editor ToolbarUpon first use of the toolbar, you must expose it. For more information, see “Preparing Siebel Tools to Develop a Workflow Process” on page 115.

Activate Button in the Siebel ClientIf you choose to publish a workflow process but not activate it in Siebel Tools, then you must use the Siebel client to activate the workflow by clicking Activate in the Workflow Deployment view. Activate adds a new record that is visible in the Active Workflow Processes list. Activate performs the following:

1 Checks the syntax for validity.

2 Registers run-time events, if used.

3 Changes the status of the workflow process to Active.

4 If the workflow process was previously activated, then Activate changes the status of the previous active version to Outdated.

Activate chooses the active version of the workflow process in the run-time tables. Only one version of a workflow can be active at a time for a Siebel Enterprise.

Activate provides version control to address an environment where multiple developers can publish multiple versions of the same workflow process. Activation occurs from within the Siebel client, where multi select is supported.

For more information, see “Activating a Workflow Process” on page 216.

Validation of a Workflow ProcessIf you click Publish or Publish/Activate in the WF/Task Editor toolbar, then the workflow process is validated before it is published. For more information, see “Validate Tool” on page 197.

Revise Creates a new version of the workflow process for editing. The new version displays in the Workflow Processes OBLE with the version property incremented by 1.

Expire Sets the status for the workflow process to Not In Use. After the workflow is expired, it can no longer be edited, published or activated. However, it can be revised.

Table 10. Buttons on the WF/Task Editor Toolbar

Button Name Description



64

Deployment Changes Beginning with Siebel CRM Version 8.0A workflow process is deployed by using buttons in Siebel Tools labeled Publish and Publish/Activate. In both releases, the button was labeled Deploy, and activation can only occur in the Siebel client. Beginning with Siebel CRM version 8.0, if you set the VerCheckTime parameter in the Workflow section of the .cfg file to -1 ([Workflow] VerCheckTime = -1), then you can activate a workflow in Siebel Tools. For more information, see “Preparing Siebel Tools to Develop a Workflow Process” on page 115.

If there are no validation errors, then neither the Validate dialog box nor the message stating that the validation was successful is displayed. The validation is executed implicitly without visibility to you, unless an error is detected.

Copying Instead of Revising a Workflow ProcessIn some cases, you can copy an existing workflow process rather than revising it. The copy feature allows you to continue to work on the original workflow. For an example, see “Modifying the Existing Workflow Process” on page 301.


5 Steps and Connectors of a Workflow Process

This chapter describes the types of steps that can be defined in a workflow process. It includes the following topics:

■ Overview of Workflow Process Steps on page 65

■ Types of Steps of a Workflow Process on page 69

■ Defining a Decision Condition on page 92

Overview of Workflow Process StepsThis topic describes an overview of steps that are used in a workflow process . It includes the following topics:

■ Adding a Step to a Workflow Process on page 66

■ Name of a Step in a Workflow Process or a Process Property on page 67

■ How Properties Are Defined for a Step in a Workflow Process on page 68

■ Sequence Number for a Step in a Workflow Process on page 68

For more information, see “Types of Steps of a Workflow Process” on page 69.

Figure 15 displays the Workflow Designer Palette.

Figure 15. Steps and Connectors in the Workflow Designer Palette


Steps and Connectors of a Workflow Process ■ Overview of Workflow Process Steps

66

Table 11 describes the types of steps and connectors that are available in the Workflow Designer Palette.

Adding a Step to a Workflow ProcessYou use the Process Designer to add a step to a workflow process. After you add a step, you can use the Properties window to define properties for the step. In some cases, you can use the WF Steps OBLE to define properties for a step. After you save a workflow, a record for the new step displays in the WF Steps OBLE, where you can modify properties.

Table 11. Types of Steps and Connectors in the Workflow Designer Palette

Step Type Description

Start Defines the decision condition that must be met in order to execute an instance of a business process. The condition is defined on the connector that emanates from the start step, and not on the start step itself.

Business Service

Calls a business service that allows you to execute actions that are predefined or custom in a workflow process.

Decision Point Evaluates a decision condition in order to determine the next step to execute.

Sub Process Calls a workflow process. The called workflow can be a standalone workflow, with a separate object definition and separate flow of workflow steps.

Siebel Operation

Performs actions on a business component, such as Insert, Update, or Query.

Task Calls a Siebel Task UI.

User Interact Controls the flow of Siebel views within an application. Guides the end user through a defined flow of Siebel views based on the user action, or executes a defined set of actions.

Wait Suspends execution of the workflow process for a specific amount of time or until a specific event occurs.

Stop Terminates the workflow process instance. Presents an error message to the end user.

End Indicates when execution for the workflow process is finished.

Connector Determines direction of flow between steps in a workflow process.

Error Exception Connector

Traps for a deviation from normal processing, such as an error that is generated by the system or an error that is generated by an end user.



To add a step to a workflow process

1 Locate the workflow process you must modify.


If the status of the workflow process is Completed or Not In Use, then click Revise in the WF/Task Editor toolbar.

For more information, see “About the Process Property” on page 47.

2 Right-click the workflow process in the Workflow Processes OBLE, then choose Edit Workflow Process.

The Workflow Designer Palette and Properties windows open along with the Process Designer. The workflow is editable. If the palette is not visible, then you can display it by choosing, from the application-level menu, the View menu, Windows, then the Palette menu item.

3 Drag, then drop the step type that you must add from the Workflow Designer Palette to the canvas.

4 In the Properties window, enter or modify the Name property.

If you step out of the property, then the name updates on the step in the canvas. For more information, see “Name of a Step in a Workflow Process or a Process Property” on page 67.

5 (Optional) Enter a description of the purpose of the step.

6 Define other properties for the workflow process step, as necessary.

For more information, see “Properties of the Step and Connector of a Workflow Process” on page 450.

Name of a Step in a Workflow Process or a Process PropertyThe name for a step in a workflow process or for a process property must be unique within the workflow. When you define a new step, the Name property for the step is automatically populated with a name and number combination that you can change. If you change the name, then the new name, including the number, must be unique from the names of the other steps in the workflow.

The name that is defined automatically for a step or a connector is based on the step or type for the connector. For example Business Service 0 for a business service step, or Siebel Operation 0 for a Siebel operation step. The number that is defined automatically in the name for a step or a connector is an integer, such as 0, 1, 2, 3, and so forth. This number differentiates instances of the same type of step or connector. For example, Business Service 0, and Business Service 1. This number, named sequence, is stored as part of the name.

Some symbols, such as the period (.), cannot be used in the name of a process property.



68

How Properties Are Defined for a Step in a Workflow ProcessYou can define properties for a step in a workflow process. If you are working in the Process Designer, then some of these properties can be defined in the Properties window. If working in the Object List Editor (OBLE), then properties can be defined in the WF Steps OBLE.


■ Reference information about properties for a step in a workflow process, see Table 86 on page 459.

■ An inventory of properties for each type of step and connector, see “Properties of the Step and Connector of a Workflow Process” on page 450.

Sequence Number for a Step in a Workflow ProcessIf a new step of the same type is added to the workflow process, and if there is no gap between the sequence numbers for the type, then the next number in the sequence is used. Otherwise, the first sequence number in the first gap for the step type is the sequence assigned to the new step. A gap can be created when a step is deleted.

For example, assume there are five business service steps in a workflow process: Business Service 0, Business Service 1, Business Service 2, Business Service 3, Business Service 4. If Business Service 1 and Business Service 2 are deleted, then the next business service step assumes the sequence number 1, and it is automatically named Business Service 1. The same approach for sequencing is used for connectors.

Steps and Connectors of a Workflow Process ■ Types of Steps of a Workflow Process


Types of Steps of a Workflow ProcessThis topic describes each type of step that can be defined in a workflow process. It includes the following topics:

■ About the Start Step on page 69

■ About the Business Service Step on page 70

■ About the Decision Point on page 72

■ About the Sub Process Step on page 73

■ About the Siebel Operation Step on page 75

■ About the Task Step on page 84

■ About the User Interact Step on page 85

■ About the Wait Step on page 87

■ About the Stop Step on page 88

■ About the End Step on page 90

■ About the Workflow Connector on page 91

For more information, see “Overview of Workflow Process Steps” on page 65.

About the Start StepA start step is a type of step in a workflow process that indicates the starting point for the workflow. A workflow can contain only one start step. A decision condition and a run-time event can be defined on the connector that emanates from the start step, but not on the start step itself. You can define the connector that emanates from a start step to perform the following work:

■ To establish the decision conditions that must be met in order for the workflow process to execute. For example, to handle an open service request, you can define a condition of Status equals Open on the connector. For more information, see “Defining a Decision Condition” on page 92.

■ To define a run-time event that is used to start the workflow process. For example, to generate an activity when the revenue for an opportunity is greater than $10,000, you can define a WriteRecord run-time event, then define a workflow that inserts the activity when an opportunity is saved that meets the decision condition. For more information, see “Starting a Workflow Process from a Run-Time Event” on page 144. For an example that uses a run-time event, see “Example of Defining a Workflow Process That Creates an Activity for a Sales Representative” on page 255.

Defining a Start StepYou define a start step in the Process Designer in Siebel Tools.



70

To define a start step

1 Add a start step to a workflow process.

For more information, see “Adding a Step to a Workflow Process” on page 66.

2 If a run-time event is used to start the workflow process, then attach a connector to the start step, and then define the run-time event on that connector.

About the Business Service StepA business service step is a type of step in a workflow process that allows you to execute a predefined or custom action in a workflow. Some examples of predefined business services include:

■ Notification. A notification can be sent to an employee or contact by using the Outbound Communication Server business service.

■ Assignment. Assignment Manager can assign an object in a workflow process by calling the Synchronous Assignment Manager Request business service.

■ Server task. You can run a server component task by using either the Asynchronous Server Requests or the Synchronous Server Requests business service.

For a list of some of the more commonly used predefined business services, see “Predefined Business Services” on page 482.

You can also define your own custom business service by using Siebel Tools or the Administration-business service view in the Siebel client. You can use Siebel VB or Siebel eScript to define your own custom business service that you call from within a workflow process.

CAUTION: A business service that is called from within a workflow process cannot include a browser script. A business service only works with a server script. If a business service with a browser script is executed from within a workflow process on the Siebel Server, then the business service fails.

Defining a Business Service StepYou define a business service step in the Process Designer in Siebel Tools.

To define a business service step

1 Add a business service step to a workflow process.


2 Make sure the step you added in Step 1 is still chosen in the Process Designer.

3 From the picklist of the Business Service Name property, pick the name of the business service to be called.

The picklist contains the business services that are defined in Siebel Tools or the Siebel client.

For more information about defining a custom business service, see Integration Platform Technologies: Siebel Enterprise Application Integration.



4 In the Business Service Method property, choose the method that calls the service. The choices available for this property depend on the business service you defined in Step 3.

5 Make sure the business service step is chosen.

6 Use the MVPW to define input and output arguments.

For more information, see “Defining an Argument of a Step in the MVPW” on page 53.

Making a Business Service Visible to a Workflow ProcessA business service object, which includes the business service, business service method, and business service method argument, contains Display Name and Hidden properties in Siebel Tools. For this object to be displayed in a picklist, the Hidden flag for the object must be set to FALSE. For example, the methods and arguments you define in your business service appear in the picklists in the Arguments list applets for the business service. By default, a business service that is defined in the Siebel client is not hidden.

When you define a workflow process in Siebel Tools, the value that is defined for the Name property for a business services object is the value that is also displayed in the picklists.

To make a business service visible to a workflow process

1 In Siebel Tools, in the Object Explorer, click Business Service.

A list of business services that are predefined displays.

2 In the Business Services OBLE, click the business service you must modify.

3 In the Properties window, change the Hidden property to FALSE.

4 In the Object Explorer, expand the Business Service tree, then click Business Service Method.

5 In the Business Service Methods OBLE, click the method you must modify, then change the Hidden property to FALSE in the properties window.

6 Repeat Step 5 for each method, if applicable.

7 In the Object Explorer, expand the Business Service Method tree, then click Business Service Method Arg.

8 In the Business Service Method Arguments OBLE, click the argument you must modify.

9 In the Properties window, change the Hidden property to FALSE.

10 Repeat Step 9 for each method argument, if applicable.

Pass By Reference Feature for a Business ServiceThe SupportsPassByRef user property is available for use on a Siebel business service. You cannot add this user property to a custom business service. If, in a workflow process, you define a business service step that is not marked for Pass By Reference, then the Workflow Engine returns an error.



72

For the Workflow Engine to use Pass By Reference, the following configuration must exist:

■ The Business Service User Prop must be set to TRUE for the business service.

■ The business service step in the workflow process must be marked for Pass By Reference.

CAUTION: Use of the Pass By Reference feature is not supported for a custom business service.

For more information, see “Defining a Subprocess to Support Pass By Reference” on page 74.

Business Service Calls to a UNIX Shell ScriptA Siebel process that runs on UNIX runs as the user that launches Siebel Services. If a workflow process calls a business service that calls a UNIX shell script, then the shell script runs as the Siebel Service Owner account.

About the Decision PointA decision point is a type of step in a workflow process that evaluates one or more decision conditions in order to determine the next step that is executed in the workflow. A decision point evaluates the user data of a business component in a record when the workflow is executed. For example, assume the workflow is started by a workflow policy and multiple violations of a workflow policy condition occur during the action interval of the Workflow Monitor Agent. In this case, when the workflow is executed, the decision point determines which branch to pursue, based on the current value of the field of the business component.

Branch Logic in a Workflow PolicyIf the logic of a branch connector is moved from the workflow process to the workflow policy level, then the workflow policy generates unique events within the defined action interval. In this way, the workflow is started by the violation of a workflow policy. For more information, see “Expressions in the Expression Builder” on page 190.

Defining a Decision PointYou define a decision point in the Process Designer in Siebel Tools.

To define a decision point

1 Add a decision point to a workflow process.


2 Define a decision condition for the decision point.

For more information, see “Defining a Decision Condition on a Branch Connector” on page 95.



About the Sub Process StepA sub process step is a type of step in a workflow process that allows you to start a separate workflow from within a workflow. A workflow can contain one or more sub process steps. You can also define a sub process step to support Pass By Reference. For more information, see “Passing a Process Property In and Out of a Step of a Workflow Process” on page 57 and “Defining a Subprocess to Support Pass By Reference” on page 74.

If using the Process Simulator, then you must publish and activate a subprocess that is called by the workflow process you are simulating prior to calling the simulator. For more information, see “Using the Process Simulator” on page 204.

For a description of properties of the sub process step, see Table 79 on page 456.

Defining a Sub Process StepAfter a sub process step is added to a workflow process, you can edit the subprocess by double clicking the sub process step. You can also right-click the sub process step, then choose Edit Sub Process.

To define a sub process step

1 Make sure the workflow process that is called by the sub process step is defined.

An object definition for the workflow process that is started by the sub process step must exist. If it does not, then you must define it before proceeding. For more information, see “Defining a Workflow Process” on page 117.

2 Add a sub process step to a workflow process.



4 Use the Subprocess Name property in the Properties window in order to choose the name of the workflow process that the sub process step calls.

5 In the MVPW, define new input and output arguments.

For more information, see “Defining an Argument of a Step in the MVPW” on page 53 and “Defining an Input Argument on a Sub Process Step” on page 74.

6 Define recipient arguments in the MVPW.

For more information, see “Fields of a Recipient Argument of a Process Property” on page 468.



74

Defining an Input Argument on a Sub Process StepYou can define an input argument on a sub process step. This input argument allows you to populate a process property in the sub process step. For example, the Object Id is passed from the main workflow process to the subprocess through an input argument. If the subprocess is based on a different business object, then you must pass the relevant row ID of the target object as the subprocess Object Id Process Property.

NOTE: If the subprocess generates a child object, then the Object Id that is passed to a subprocess must not contain the Object Id of the parent process. If a subprocess generates a child object, then it is recommended that the Object Id that is passed to a subprocess be null.

To define an input argument on a sub process step■ Define an input argument on a sub process step.

For more information, see “Defining an Argument of a Step in the MVPW” on page 53.

Copying a Value from a Parent Workflow Process to a Sub Workflow ProcessYou can copy a value to a record that is updated or inserted by a subprocess by defining a process property in the subprocess, then assigning the value to it through an Input Argument on the sub process step. The process property can then be used in the Siebel operation step of the subprocess. In the following example, you copy the Order Name for an order into the Name field of a newly created opportunity.

To copy a value from a parent process to a subprocess

1 Add a process property to the subprocess named Opportunity Name.

For more information, see “Defining a Process Property for a Workflow Process” on page 124.

2 In the Sub Process step, map Order Parent Product Name to Opportunity Name.

3 Assign Opportunity Name to the Name field of the opportunity that is created within the Siebel operation step.

Defining a Subprocess to Support Pass By ReferenceIf a subprocess modifies a large amount of data, then the subprocess must copy large quantities of data, thus resulting in a negative affect on performance and scalability. In such cases, you can use the Pass By Reference feature so that a pointer to the data is passed, but not the data itself.



Figure 16 illustrates an example workflow process that passes a large property set that is created by the Create Siebel Message step to the 11i Process Order step.

If you define a sub process step to support Pass By Reference, then it is not necessary to map the output argument in the sub process step for the hierarchical properties that you are passing. The sub process step overwrites the passed input hierarchical argument. Optionally, you can define the sub process step to modify the passed input hierarchical argument.

To define a sub process step to support pass by reference

1 In the Workflow Processes list, choose the workflow process that is your subprocess.

2 In the Properties window, set the Pass By Ref Hierarchy Argument process property to TRUE.

In the Worfklow Process list, the Pass by Ref Hierarchy property is now checked for the child workflow.

About the Siebel Operation StepThe Siebel operation step is a type of step in a workflow process that performs operations, such as Insert, Update, or Query. The operation is performed on a business component. This topic includes the following topics:

■ Defining a Siebel Operation Step on page 76

■ How the Search Specification Is Used with a Siebel Operation on page 77

■ Updating the Field of a Nonprimary Business Component on page 78

■ Updating a Field That Is Based on a Multi-Value Group on page 78

■ How the Calculated Field Is Used with a Siebel Operation Step on page 79

■ How the Siebel Operation Step Is Used to Traverse a Record Set on page 79

■ Updating a Process Property with a Siebel Operation Step on page 80

■ How the Object Id Process Property Is Used with the Siebel Operation Step on page 82

■ How the Upsert Operation Is Used with the Siebel Operation Step on page 82

■ Relations Between a Siebel Operation Step and the Siebel Object Hierarchy on page 83

■ Defining a Primary Business Component for a Business Object on page 83

Figure 16. Example Workflow for Which Pass By Reference with a Sub Process Step is Useful



76

Defining a Siebel Operation StepYou can define a Siebel operation step for a business component that is associated with the business object defined for the workflow process. If you must update a business component that is not associated with the business object, then you can use Siebel Tools to start a subprocess or associate the business component to the business object.

To define a Siebel operation step

1 Add a Siebel operation step to a workflow process.



3 In the Operation property, choose the type of operation.

For an update or insert to a field that contains a dependency, make sure the field is valid. For example, if a service request process and a workflow process updates the area and sub area fields, then you must make sure the values chosen for the subarea field are valid for that associated area.

4 For the Business Component property, choose the name of the business component on whose data the Siebel operation performs an operation.

5 (Optional) In the MVPW, define new input and output arguments.

If an Insert or Upsert operation is performed, then make sure you add the required arguments in the MVPW. Make sure you define the name of the field to be updated in the Field Name field. In the Type field, choose an input argument type, then define other fields, depending on the type you define. For more information, see “Arguments of the Step of a Workflow Process” on page 49.

6 (Optional) Define a search specification in the MVPW:

a In the Type field, choose a search specification type, as described in the following table.

b In the Search Specification field, enter a search specification.

c If the search specification Type is Expression, then choose the applicable name of the business component.

For more information, see “How the Search Specification Is Used with a Siebel Operation” on page 77.

Type Description

Literal A static string where the run-time value is the same as the value defined in the Process Designer.

Expression A Siebel expression, often based on other run-time variables, where the run-time value can only be determined at run time by evaluating the expression.



How the Search Specification Is Used with a Siebel OperationYou can define a search specification to identify the specific data on which to perform the operation. A search specification is used when the business component contains multiple records and you must perform the operation on only some of the records. For example, if a workflow process for the account object must update only those opportunities that possess a lead quality of Poor, then you define a search specification to access only those opportunities.

CAUTION: Define your search specification for a Siebel operation as efficiently as possible, so that only the smallest necessary set of rows match. A search specification that results in a large set of rows can cause severe performance degradation.

For search specification usage in an example workflow, see “Defining the Workflow Process” on page 266.

How a Literal Search Specification is DefinedA search specification of type Literal is executed as written. For example, [Status] LIKE '*Open*'. A search specification of type Expression allows you to build a search specification dynamically. For example, if the New ID process property is 1-ABC at run time, then "[Contact ID] = ' " + [&New ID] + " ' " is evaluated to [Contact ID] = '1-ABC'.

How a Business Component Field is ReferencedBoth sides of an expression can reference a business component field. The Filter Business Component defines the business component that is referenced on the left side, and the Expression Business Component defines the business component that is referenced on the right side. For example, consider the configuration described in Table 12.

In this example, the expression evaluates as described in the following syntax:

"[Account.Id] = [Contact.Account Id]"

Example of Defining a Siebel Operation Search SpecificationAn expression for a search specification can be defined with compound expressions and substitutions from process properties or fields. For example, consider the following generic syntax:

"([Field1] > '" + [&Process Property Name] + "') OR ([Field2] IS NULL) OR ([Field3] IS NULL)"

Table 12. Example of Arguments That Are Used in a Search Specification

Field Value

Filter Business Component Account

Expression Business Component Contact

Expression "[Id] = [Account Id]"



78

This syntax is translated to:

([Field1] > 'value') OR ([Field2] IS NULL) OR ([Field3] IS NULL)

Expressions that now include literal representations of the business component fields, where dFromDate is a custom process property, include:

■ "([Open] > '" + [&dFromDate] + "') OR ([Open] IS NULL)"

■ "([Open] > '" + [&dFromDate] + "') AND ([Status] IS NULL)"

For more information about using a process property as a substitution variable, see “Referencing a Process Property” on page 60.

Updating the Field of a Nonprimary Business ComponentYou can update the field of a nonprimary business component.

To update the field of a nonprimary business component■ Make sure one of the following situations exists:

■ A join exists between the base table for the primary business component and the field you must update.

■ A link exists between the primary business component and the business component that contains the field you must update.

For example, assume you must update sales stage data in a workflow process whose business object property is set to Opportunity. The predefined Sales Stage join on the opportunity business component provides the capability to update the sales stage field.

Guidelines for Using Joins and LinksGuidelines for using joins and links include:

■ If a predefined join or link does not exist, then you can define one.

■ In some cases, to update a field in a nonprimary business component, you can copy an existing business object, then define it in the business object property of a workflow process. If you choose a different business component as the primary business component for this business object, then you must make sure link or join information that is defined for that business component is removed or corrected. Otherwise, an error can result.


■ Defining a business component, see “Defining a Primary Business Component for a Business Object” on page 83

■ Modifying joins and links, see Configuring Siebel Business Applications

Updating a Field That Is Based on a Multi-Value GroupYou can update a field that is based on a multi-value group.



To update a field that is based on a multi-value group

1 Define a business component for the field.

2 Link the business component to the object that is using Siebel Tools.

For example, assume you must update the Account Team business component field. Account Team is based on a multi-value group, so it cannot be updated by choosing the Account business component. However, you can define a business component named Account Team, then associate it with the Account business object by using Siebel Tools. You can then choose Account Team as the business component to update with the Siebel operation step.

For more information about multi-value groups, see Configuring Siebel Business Applications.

How the Calculated Field Is Used with a Siebel Operation StepA Siebel operation step cannot be used to update a calculated field because, typically, the calculated field requires values from the fields of another business component. Instead, use an expression to perform calculations.

How the Siebel Operation Step Is Used to Traverse a Record SetThe NextRecord, PrevRecord, and QueryBiDirectional operations on the Siebel operation step are used in conjunction with the Update, Query, and Insert operations to traverse a record set. Using NextRecord and PrevRecord, you can navigate through the records of a child business component of the business object that is associated with the workflow process:

■ The NextRecord operation changes the active row of the target business component to the next record in the current workset.

■ The PrevRecord operation changes the active row to the previous record.

You must perform a query on the target business component before using subsequent Next Record and Previous Record operations. If the workflow process is traversing active records, or if your workflow uses the PreviousRecord operation, then query bidirectionally. Otherwise, use the standard Siebel query operation.

NextRecord, PrevRecord, and QueryBiDirectional cannot be used to navigate through records of the primary business component. These operations are designed to navigate records of a child business component in a workflow process. Therefore you must use a child business component.

For a detailed example that uses the traversing a record set technique, see “Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete” on page 264.

Output Arguments That Are Used with Traversing a Record SetIf you use Next Record and Previous Record to traverse records of a child business component, then an output argument named NoMoreRecords in the Siebel operation is set to TRUE when the Siebel operation attempts to read the next record but finds there are no more records in the record set to traverse. NoMoreRecords is set to TRUE in the forward direction for Next Record or in the backward direction for Previous Record.



80

NoMoreRecords can be assigned to a process property, and in conjunction with a decision point, can be used to exit the loop after navigating through every record in the record set. To support this output argument, the Process Designer displays an Output Argument column in the output arguments tab for the Siebel operation step.

Another output argument, NumAffRows (Number of AFFected Rows) exists for Query, Update and Upsert operations:

■ If used with Query, then NumAffRows provides the number of rows that are returned as a result of the query

■ If used with Update and Upsert, then NumAffRows provides the number of rows that are updated

Updating a Process Property with a Siebel Operation StepYou can define a test workflow process that uses a Siebel operation in order to update a process property. This technique can be useful during development. For example, you can use the sum of two business component integer fields that provide input to a decision that is downstream in the workflow process. By updating a process property in the Siebel operation step with the sum of the two required fields, you can use this property on a subsequent branch connector.

To update a process property with a Siebel operation step

1 In Siebel Tools, define a new workflow process using values from the following table.


2 Add steps and connectors until your workflow process resembles the workflow illustrated in the following figure:


3 Click the canvas, making sure no workflow process step or connector is chosen.

Property Value

Process Name Updating a Process Property

Business Object Action

Workflow Mode Service Flow



4 In the MVPW, right-click, then add a new process property using values from the following table.


5 Click the Update Process Property step, then click the Search Spec Input Arguments tab in the MVPW.

6 Right-click, choose New Record, then define a new record using values from the following table.

7 Make sure the Update Process Property step is chosen in the Process Designer.

8 Click the Output Arguments tab in the MVPW.




11 Implement this technique in your production workflow process.

Field Value

Name Custom Process Property

Display Name Custom Process Property

In/Out In/Out

Business Object Action

Field Value

Expression Business Component List of Values

Filter Business Component Query

Search Specification [Name] = 'Personal' AND [Type] = 'TODO_TYPE'

Type Literal

Field Value

Property Name Custom Process Property

Type Expression

Value [Class Code]

Business Component Name List Of Values



82

How the Object Id Process Property Is Used with the Siebel Operation StepAfter an Insert or Upsert operation is executed, the Siebel Operation Object Id process property automatically stores the row ID of the record that was created. The Object Id for the workflow process is automatically passed to Siebel operation step. Because this automatic passing occurs, it is not necessary to define a search specification unless you are updating child records. For example, if a workflow that is based on the service request business object must update the service request, then it is not necessary for you to enter a search specification. However, if you must update activity records for the service request, then you can enter a search specification to query the specific activity you must update. Otherwise, the update step updates every activity that is associated with the service request.

If you execute a Siebel operation, then the Object Id cannot be null, unless you insert into the primary Object Id. If the workflow process contains no Object Id, then the Siebel operation step returns an error.

Values returned by the Siebel Operation Object Id process property when a query operation is performed for child records include:

■ The row ID if one record matches.

■ Null and no value if no records match.

■ An asterisk (*) if multiple records match. This result is provided in order to distinguish from a value that returns a unique record or no record. Typically, either a unique record matches or no records match. In most cases, multiple records do not match and an asterisk is returned.

The only option returns the row ID of a matching row. The Insert, Update and Upsert operations update the Siebel Operation Object Id process property of the row ID for the record.

How the Upsert Operation Is Used with the Siebel Operation StepThe Upsert Operation provides a way to perform either an insert or update operation based on whether a record or records exist in the database. Hence the name, Upsert. The operation can perform an update or insert operation. For example, assume a search specification on a Siebel operation step queries the database. Table 13 describes how Upsert works in this case.

Table 13. Example of Work That the Upsert Operation Performs

Situation Work Performed by Upsert

A record exists in the database

Upsert performs similar to an Update operation, and updates each record with modified values as determined by the workflow process.

If a record does not exist in the database

Upsert performs similar to an Insert operation and inserts a new record.



Examples Where Upsert Is UsefulIn the Siebel client, assume the end user is navigated to a view where the user clicks a checkbox to create a new contact, then enters the relevant contact information. Assume the Yes default for the checkbox creates a new contact. If the user creates a new contact, navigates away from the view, then returns to the view, when the user returns there is the potential that another contact is created. In this example, an evaluation must be made whether the contact already exists or not. If a contact does exist, then the contact must be updated. If the contact does not exist, then a new contact must be created.

In another example, assume a workflow runs in the background at midnight, processing orders that are submitted from an external system. If an order does not exist, then Upsert creates a new record. If an order already exists but must be updated, then Upsert updates the record.

Relations Between a Siebel Operation Step and the Siebel Object HierarchyThe workflow policy program and the Siebel operation step use different object layers in order to update data. For example, you can define a workflow policy that calls a workflow policy program to update a service request. This technique proceeds through the data layer, where the state model does not apply. Conversely, if you define a workflow policy that calls a workflow process action, and in the workflow process you define a Siebel operation step to update a service request, then this technique proceeds through the object layer, where the state model does apply.

Defining a Primary Business Component for a Business ObjectThe business object that is defined for a workflow process must contain a primary business component.

To define a primary business component for a business object

1 In Siebel Tools, in the Object Explorer, click Business Object.

2 In the Business Objects OBLE, query the Name property for the business object you must modify.

3 In the Properties window, use the picklist in the Primary Business Component property to pick the appropriate component name.

Define a primary business component by choosing the key business component for the specific business object.

4 Compile the SRF.

After a primary business component is defined, the business object displays in the Workflow Processes OBLE.



84

About the Task StepA task step is a type of step in a workflow process that launches a task UI from within a workflow process. After a workflow process calls a task UI, the task UI is visible in the Inbox for the end user. Until the user finishes the task UI, the workflow is in a waiting state. After the task UI finishes, the workflow moves to the next step in the workflow, and continues execution of the workflow.

The main parts of defining a task step for a workflow process include:

■ Defining input arguments for the task step, including associating the task step with a task UI

■ Defining output arguments for the task step

■ Assigning a recipient for the task UI

After you define a task step in the Process Designer and you associate the task step with a task UI, you can open the Task Editor by double clicking the task step in the Process Designer.

Requirements for using a task step include:

■ To define a task step in a workflow process, the task UI that is called by the task step must already be defined. For information on defining a task UI, see Siebel Business Process Framework: Task UI Guide.

■ If the workflow process launches a task UI, then the Mode property for the workflow must be set to Long Running Flow.

Defining a Task StepYou define a task step in the Process Designer in Siebel Tools.

To define a task step

1 Add a task step to a workflow process.



3 In the Task Name property, use the picklist to choose a task UI in order to associate the task UI with the task step.

4 In the Properties window, make sure the Inactive property is set to FALSE.

5 In the MVPW, define new input, output, and recipient arguments.

For more information, see “About the Process Property” on page 47, and Siebel Business Process Framework: Task UI Guide.



About the User Interact StepThe user interact step is a type step in a workflow process that provides a way to define the flow of Siebel views within an application. Siebel Workflow guides the end user through a defined flow of Siebel views based on interactions with the end user, or executes a defined set of actions. This flow can be modified as the business environment changes.

The user interact step can use a process property as an input argument. In this way, you can dynamically set view names as you design your interactive workflow process. The view name property is set in the View property, an unbounded picklist, of the user interact step.

Behaviors of the User Interact StepBehaviors of the user interact step include:

■ The user intact step sends a request to the Siebel Web Engine to build the view, then brings up the required view in the user session.

Only one view can be built at a time. You cannot combine a user interact step with another action, such as bringing up a message box or building another view simultaneously. Also, you cannot use both a UserInteract step and start a task UI.

■ The user interact step waits in the memory of the user session for a run-time event to resume processing. When there is no run-time event defined, the workflow process continues to the end.

■ If, after a user interact step, the end user manually navigates out of the view, then the workflow process remains in the memory of the user session. The instance of the workflow is deleted when the user session is terminated or when another workflow process is instantiated in the same user session.

■ If not already in the executed state, then the user interact step automatically queries the primary business component of the business object for the workflow process. The query searches for a record where the ID matches the value of the Object Id property.

■ The workflow process is resumed after a user interact step only if the ID of the record where the run-time event that is registered in the decision conditions that are defined on the connector match the value of the Object Id process property.

Restrictions for the User Interact StepRestrictions when defining a user interact step include:

■ A workflow process running in the Workflow Process Manager server component must not contain a user interact step. That is, if the workflow is running in background mode or in batch mode, then it cannot include a user interact step. In this situation, if the Workflow Process Manager encounters a user interact step, then an error results.

■ The user interact step is only supported if the workflow process is started through a script or a run-time event and the workflow is run locally in the application object manager.

■ It is not possible to use a user interact step in a workflow process in order to move to a view and start the Search Center.



86

■ The user interact step, or another activity that is started from the background, cannot interfere with the activity of an end user. Because the end user controls work performed in the Siebel client, a workflow process that is running in the background cannot disturb work that is performed by the end user.

Defining a User Interact StepYou define a user interact step in the Process Designer in Siebel Tools.

To define a user interact step

1 Add a user interact step to a workflow process.



3 In the Properties window, use the picklist in the User Interact View property to define the view name to which you must navigate the end user.

4 In the Description property, enter a description of the purpose of the user interact step.

5 If the user interact step requires conditional logic, then define a decision condition.

A decision condition can be defined on one or more connectors that emanate from the user interact step. For more information, see “Defining a Decision Condition” on page 92.

Defining a Run-Time Event with a User Interact StepA branch that emanates from a user interact step in an interactive workflow must be associated with a run-time event. An error occurs during validation if both of the following statements are true:

■ The mode property for the workflow process is set to Interactive Flow

■ The workflow process contains a user interact step that does not contain a run-time event defined on the outgoing branch

To avoid this error, if the run-time event is not required or not used in the user interact step, then change the Workflow Mode property of the workflow process to 7.0 Flow. For more information, see “About the Workflow Mode Property” on page 127.

Using a User Interact Step to Dynamically Set the Name of a View You can associate the name of a view with a process property so that the view name can be set dynamically at run time. You do this by assigning the name of the view to the run-time value of a process property.



To use a user interact step to dynamically set the name of a view■ In the User Interact View property of a user interact step, type the following string:

[&ProcessPropertyName]

The Workflow Engine recognizes this string and assigns the view name at run time.

About the Wait StepThe wait step is a type of step in a workflow process that allows you to suspend execution of the process for a specific amount of time, or until a specific event occurs. You can pause the instance of a process in units of seconds, minutes, hours, or days. In addition, you can define a service calendar to account for business hours and days.

If a workflow process includes a wait step, then by default it is persistent.

The wait step is often used for testing and development purposes. Unlike the Siebel operation step, the wait step can be used without affecting metadata of the business component or user data. For an example that uses the wait step for testing, see “Defining a Run-Time Event within a Many to One Relationship” on page 158.

Defining a Wait StepYou can define a wait step to pause the instance of a workflow process.

To define a wait step

1 Add a wait step to a workflow process.



3 Make sure the Workflow Mode property for the workflow process is set to Interactive Flow.

A wait step can only be used in an Interactive Flow. For more information, see “About the Workflow Mode Property” on page 127.

4 Make sure the wait step is chosen in the Process Designer.

5 Define input and output arguments for the wait step in the MVPW.


If defining a duration argument that is greater than 60 seconds, then define minutes or a larger unit of measure so that data of the business component is refreshed. The workflow process is resumed from the Workflow Process Manager when units of minutes or higher are defined. A wait step with a duration that is measured in something other than seconds is automatically persistent.



88

SleepMode and the 7.0 Workflow ProcessIf the Workflow Mode property for a workflow process is set to 7.0 Flow, then the SleepMode input argument allows you to define how the wait step resumes the workflow:

■ If set to the default Local value, then the workflow process is resumed within the session that launched the workflow.

■ If set to Remote, then the workflow process is resumed on the server by the Workflow Process Manager server component. A component request for the Workflow Process Manager server component is created that runs at the time determined by the Duration input argument on the wait step.

If the Workflow Mode property for a workflow process is set to something other than 7.0 Flow, then the SleepMode input argument is ignored and the mode is Remote. For more information, see “About the Workflow Mode Property” on page 127.

Processing Mode Property of a Wait StepThere are performance considerations when choosing between synchronous and asynchronous for the Processing Mode property on the wait step. For more information, see “Server Requests Business Service” on page 482.

SetFieldValue and the Processing ModeIt is recommended that when SetFieldValue is used to start a workflow process that the Processing Mode property be set to Local Synchronous. SetFieldValue can occur without committing data. Therefore, setting the Processing Mode to Remote Synchronous or Remote Asynchronous when using SetFieldValue can result in a workflow running out of process, and the workflow is not able to access the uncommitted data for the workflow.

About the Stop StepThe stop step is a type of step in a workflow process that is used to display an error to the end user and terminate the instance of the workflow. The main parts of defining a stop step for a workflow process include:

1 Defining a Stop Step on page 89

2 Defining a Custom Error Message on a Stop Step on page 90

NOTE: If using a stop step in a subprocess, then the stop step stops the subprocess and it also stops the parent workflow process that starts the subprocess. It is not necessary to define a stop step in the parent workflow in order to stop the subprocess from executing.



Table 14 describes the way the stop step is handled, depending on how it is called and in which object manager it is running.

Defining a Stop StepThis topic describes how to define a stop step.

To define a stop step

1 Add a stop step to a workflow process.



3 In the Properties window, In the Error Code property, choose a predefined error code from the picklist.

For information, see “Defining a Custom Error Message on a Stop Step” on page 90.

4 In the Error Message property, enter an error message.

5 Define input arguments for the step in the MVPW.

For more information, see “Arguments of the Step of a Workflow Process” on page 49.

No picklist is available for the Name field. The input arguments for a stop step are the substitution variables that appear in the error message. Substitution variables are identified by a percent sign (%). To define the substitution value, enter it in the Name field for the input argument. For example: %1.

Calling the Stop StepIt is recommended that the stop step be used only in a workflow process that is started from a script. For example, consider a workflow that displays a custom error message in a stop step. When the workflow is run, the custom error message displays that includes stack information that you must suppress. It is not possible to suppress stack information with a stop step.

Table 14. How Workflow Process Manager Handles a Stop Step

Situation Where Process RunsWork Performed by the Workflow Process Manager

A workflow policy calls a workflow process that contains a stop step.

Not applicable Exits. Writes an error message to the log file.

A script or a run-time event calls a workflow process that contains a stop step.

Workflow Process Manager Object Manager

Writes an error message to the log file.

Application Object Manager Displays an error message to the end user.



90

However, a workflow process that is started from a script can contain an end step that defines the error message in a process property. If the workflow encounters the required decision condition, then the process property that contains the error message is sent. Because the subsequent step is an end step that does not display messages, control is returned to the calling script that checks for the value that is set in the process property, then uses RaiseErrorText() to display the message. The error dialog displays the error text but does not display workflow or stack trace information.

Defining a Custom Error Message on a Stop StepIf none of the predefined error messages that are provided in the Error Code property on the stop Step meet your requirements, then you can define a custom error message on the stop step.

To define a custom error message on a stop step

1 Add a stop step to your workflow process.

2 Click the stop step, then use the Properties window to set the Error Code property to WF_ERR_CUSTOM_1.

The Error Message property defaults to %1.

3 Define a new input argument in the MVPW for the stop step.


4 Set the Name field to the value that is displayed in the Error Message property in the Properties window.

In this case, that value is %1.

5 Enter the custom text message in the Value field.

If you define the input argument in this way, then the value you define is used in the %1 variable.

Multiple Custom Error Messages for a Stop StepSeveral customizable codes are available in the Error Code property on the stop step. These are indicated by WF_ERR_CUSTOM_x. Because each WF_ERR_CUSTOM_x is unique, it can only be used for a one time, specific purpose. If you must display multiple custom error messages, then use WF_ERR_CUSTOM_2, WF_ERR_CUSTOM_3, and so forth, instead of using %1, %2 for the same WF_ERR_CUSTOM_x.

About the End StepAn end step is a type of step in a workflow process that specifies when the instance of a workflow process is finished. It also provides one last chance to store output arguments to a process property. Each workflow must contain at least one end step. For more information, see “Defining an End Step” on page 91.



Differences Between the End Step and the Stop StepAn important difference between the stop step and the end step is that the stop step sets the state for the workflow process to In Error, while the end step sets the state to Completed. It is important to consider this situation if you use the Workflow Monitor Agent to call a workflow. If the Ignore Errors parameter of the Workflow Monitor Agent is set to False, then a workflow that encounters a stop step causes Workflow Monitor Agent to exit with error. If the workflow encounters an end step, then Workflow Monitor Agent does not exit with error.

Defining an End StepYou define an end step in the Process Designer in Siebel Tools.

To define an end step

1 Add an end step to a workflow process.



3 Define output arguments for the step in the MVPW.


About the Workflow ConnectorYou can define properties for the connector in a workflow process by using the Properties window from within the Process Designer. For information about the properties of a connector, see Table 86 on page 459. For information about defining a run-time event on a connector, see “Starting a Workflow Process from a Run-Time Event” on page 144.


Steps and Connectors of a Workflow Process ■ Defining a Decision Condition

92

Defining a Decision ConditionThis topic includes the following topics:

■ Defining a Branch Connector on page 92

■ Defining a Decision Condition on a Branch Connector on page 95

Conditional logic for a workflow process is implemented by defining conditions and values that affect the flow of the workflow. Different actions can occur depending on which path is followed. For example, you can define a decision condition that is based on the value of a priority field so that if the priority is equal to high, then the workflow pursues a branch that leads to an action that sends an email to a vice president. However, if the priority is equal to medium, then the email is sent to an engineer. Steps of a workflow where a decision condition can be defined include:

■ Start step

■ Decision point

■ Wait step

■ User interact step

Table 15 describes example workflow processes you can view that use a decision condition.

Defining a Branch ConnectorA branch connector is a type of connector in a workflow process that can contain a decision condition. Conditional logic is defined on a connector that emanates out of the step, and not on the step itself. Typically, a branch connector emanates from a start step, decision point, wait step, or user interact step.

Table 15. Examples of Workflow Processes that Use a Decision Condition

Conditional Logic Work Performed Location

An IF/THEN decision condition, where flow is determined by the Revenue field in the Opportunity business component being greater than $10,000.

Insert an activity for the parent opportunity.

“Defining a Decision Condition for the Decision Point” on page 259

A CASE statement, where one of several different branches is pursued, depending on the value of the Priority field in the Service Request business component.

Insert an activity with a value of a commit time that is based on the result of the CASE statement.

“Example of Defining a Workflow Process That Manages Creation of a Service Request” on page 292



To define a branch connector

1 Drag, then drop a connector from the palette to the canvas, connecting the decision point with the new next step.

Make sure that the connector is correctly attached. For more information, see “Diagramming a Workflow Process” on page 122.

2 Make sure the connector you added in Step 1 is still chosen in the Process Designer.

3 In the Properties window, enter or modify the connector name.

The connector name must be unique to the workflow process. If it is not unique, then you cannot commit the record.

4 Choose a connector Type.

In most cases, this value is Condition or Default. If you define a decision condition on the connector, then choose Condition. If the connector is used as an exit route, then choose Default. Other values can also be set. For more information, see Table 86 on page 459.

If you define multiple branches on this step, then, for caution information, see “Defining Multiple Branches on a Single Step” on page 93.

5 Enter comments.

6 Define the decision condition, if necessary.

If the connector is used to incorporate conditional logic, then use the Compose Condition Criteria dialog box. For more information, see “Defining a Decision Condition on a Branch Connector” on page 95.

Defining Multiple Branches on a Single StepA start step, decision point, wait step, or user interact step can each reference multiple branch connectors.

CAUTION: If you define multiple branch connectors, then make sure to define at least one connector with the Type property set to Default, thereby providing an exit route in case a work item does not meet any of the decision conditions.

To define multiple branches for a single step in a workflow process■ Perform the procedure described in “Defining a Branch Connector” on page 92 for each branch that

you must define for the step. Each branch can contain a separate decision condition.

Comparison of Branching Declaratively to Programming with a ScriptYou can implement branching declaratively, as in multiple branches that emanate from a single step in a workflow process. In some cases, you can achieve the same result through a script, as in scripting on a business service.



94

For example, assume a STATUS field references a List of Values (LOV), and this LOV itself contains 120 values. If the user updates the STATUS field, then a workflow process performs 100 different updates in three related business components. This workflow contains a start step that checks for 120 decision conditions, then uses 100 different branches that, in turn, update the relevant business component.

As an alternative, you can define a workflow process that contains a scripted business service. In this workflow, the STATUS is sent to the business service. The business service computes, then propagates the outcome to the business components either through the same business service or through a separate Siebel operation step in the workflow process.

Conclusions that can be drawn from this example include:

■ Effectively, there are no limitations on the number of outgoing branches on a start step or a decision step.

■ One hundred and twenty steps with 120 branches in a workflow process can provide the same performance as implementing the same logic through eScript on a business service.

■ For this kind of programmatically intense operation, eScript is probably a better choice. A workflow process with 120 branches is cluttered, while the implementation would be cleaner and easier to maintain in eScript. Conversely, it is recommended to use a declarative technique to address more common requirements.

Branching and Parallel ProcessingParallel processing is not supported with Siebel Workflow. Make sure you define decision conditions so that the workflow can only proceed along one connector. If conditions are defined in such a way that flow can proceed simultaneously along multiple connectors, then the exact run-time behavior of the Workflow Engine cannot be accurately predicted.



Defining a Decision Condition on a Branch ConnectorYou define a decision condition on a branch connector by using the Compose Condition Criteria dialog box. A branch connector can be a connector that emanates from a start step, decision point, wait step, or user interact step. Values listed in the Compose Condition Criteria dialog box are constrained by the value that is defined in the Business Object property for the workflow process. For an example that uses conditional logic on a connector, see “Defining a Decision Condition for the Decision Point” on page 259.

To define a decision condition on a branch connector

1 In the Process Designer, right-click the connector on which you must define a decision condition.

2 Choose Edit Conditions.

The Compose Condition Criteria dialog box displays.

3 Compose a condition.

For more information, see “Decision Conditions for a Workflow Process” on page 188.

4 Click OK.



96


6 Developing a Workflow Process

This chapter describes how to develop a workflow process. It includes the following topics:

■ Roadmap for Developing a Workflow Process on page 97

■ Process of Analyzing Business Requirements on page 99

■ Process of Planning a Workflow Process on page 104

■ Job Roles That Are Involved in Developing a Workflow Process on page 114

Roadmap for Developing a Workflow ProcessFigure 17 illustrates the lifecycle for planning and developing a workflow process.

The steps for developing a workflow process include:

Figure 17. Lifecycle for Planning and Developing a Workflow Process


Developing a Workflow Process ■ Roadmap for Developing a Workflow Process

98

1 Analyze. Analyze your business requirements and the business rules and processes to be automated.

2 Plan. Plan for building the workflow process.

3 Build. Build the workflow process by defining workflow objects in Siebel Tools. Example objects include the object definition for the workflow process, process properties, and workflow steps.

4 Test. Test your workflow process to make sure the objects you defined meet the business requirements. Testing includes validating and simulating the workflow process, then verifying functionality.

5 Deploy. Deploy your workflow process by publishing object definitions of the workflow from the repository tables to the run-time tables, then activating the workflow for use in the Siebel client.

6 Migrate. Migrate the tested workflow process to the production environment. You can use a utility, such as ADM, REPIMEXP, or Import/Export.

7 Administer. Administer, monitor and troubleshoot the migrated workflow process in the production environment.

The lifecycle illustrated uses a linear flow, whereas the typical development cycle of a workflow process is iterative.

Processes That Are Involved in Developing a Workflow ProcessTo develop a workflow process, perform the following processes:

1 Process of Analyzing Business Requirements on page 99

2 Process of Planning a Workflow Process on page 104

3 Process of Building a Workflow Process on page 115

4 Process of Testing a Workflow on page 202

5 Process of Deploying a Workflow Process on page 211

6 Process of Migrating a Workflow Process on page 218

7 Process of Administering a Workflow Process on page 227

Developing a Workflow Process ■ Process of Analyzing Business Requirements


Process of Analyzing Business RequirementsThis process is a step in “Roadmap for Developing a Workflow Process” on page 97.

To analyze business requirements, perform the following tasks:

1 Gathering Information for Planning a Workflow Process on page 99

2 Identifying Actions That a Business Process Performs on page 100

3 Identifying an Automation Solution on page 101

The first step in developing a workflow process includes analyzing your business requirements, where you determine the business rules and business processes that are automated by a workflow process. An implementation project team typically spends a significant amount of time performing requirements analysis, with this step requiring as much as 30% of the of the total implementation effort. A business analyst uses the Siebel application to define the processes to be automated, then determines the most appropriate automation solution. The developer who defines the workflow process often participates as a technical consultant during this analysis.

Gathering Information for Planning a Workflow ProcessThis task is a step in “Process of Analyzing Business Requirements” on page 99.

You can gather information for workflow process planning.

To gather information for planning a workflow process

1 Gather existing as is information about the business process by looking at how your organization currently handles business processes.

For more information, see “Analyzing Existing Performance of a Business Process” on page 99.

2 Gather desired should be information about how the business process must operate.

For more information, see “Determining Areas for Improvement” on page 100.

Analyzing Existing Performance of a Business ProcessCurrent business processes provide the basis of what you define when you use Siebel Workflow. If you currently use an automated system, then you must gather information on the business processes that are handled by that system. It is also important to understand the limitations or problems of the current system that you must address with a workflow process.

To analyze existing performance of a business process■ Research the following areas for your current business process:

■ Existing process information

■ Measures for improvement or new process requirements



100

The following sources might contain existing process information:

■ Current business processes that are automated

■ Management guidelines

■ Written guidelines for business process rules or approval paths

■ Written or unwritten internal procedures

For example, assume you must document the lifecycle for a new work item, such as a service request, from the moment the service request is opened to the moment it is closed. Include information about decision points in the business process, such as when a service request must be escalated or which approval path an order pursues when it is high priority compared with low priority.

Determining Areas for ImprovementAfter you gather the required information about existing business processes, review the information to determine if there are areas for improvement in the business process or whether a new business process is required.

To determine areas for improvement■ Consider each of the following areas for improvement:

■ New management guidelines or business requirements that must be addressed

■ Current problems that must be solved

■ Areas you must make more visible

■ Customer satisfaction issues

■ Workflow processes you must automate

Identifying Actions That a Business Process PerformsThis task is a step in “Process of Analyzing Business Requirements” on page 99.

A business process consists of various actions that must be performed in order to meet business requirements. Siebel CRM provides a number of predefined actions. Some example predefined actions include:

■ Notifications. Send an email, page, or fax.

■ Siebel Operations. Insert or update information in the Siebel database.

■ Integration Messages. Request to send or receive data from an external system.

■ Assignment. Request Assignment Manager to assign an object.

■ Navigation. Navigate a user to a specific view through a user interact step or a call to Siebel Task UI.

■ Server Request. Request the Siebel Server Request Broker to run a server process.



Except for Siebel operations, these actions are started by calling a method on a business service. A predefined business service can be used to implement an action in a variety of settings and technical configurations. You might identify a specialized action that you are interested in calling in your workflow process, such as calculate credit risk. A specialized action can be added by defining a custom business service. A workflow process can call both a predefined and a custom business service. For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration.

To identify actions a business process performs■ Map the requirements you identified in “Gathering Information for Planning a Workflow Process” on

page 99 to potential predefined Siebel actions.

Identifying an Automation SolutionThis task is a step in “Process of Analyzing Business Requirements” on page 99.

After you determine business process requirements and the actions that must be performed to meet those requirements, you can identify an automation solution.

To identify an automation solution

1 Map the business process requirement to the advantages and limitations of each solution.

For more information, see “Comparison of a Workflow Process to Other Solutions” on page 102.

2 Determine whether the requirement can be addressed with a workflow process or a workflow policy.

For more information, see “Requirement Mapping to a Workflow Process or Workflow Policy” on page 103.



102

Comparison of a Workflow Process to Other SolutionsTable 16 compares a workflow process to other Siebel automation solutions.

Table 16. Comparison of a Workflow Process to Other Siebel Automation Solutions

Solution Advantages Limitations

Workflow Process

Advantages include:

■ Visual representation of business logic is relatively simple to understand and maintain

■ Remote synchronous and asynchronous execution allows compatibility across Siebel Business Applications for scalability and long-running transactions

Limitations include:

■ The semantics for control are not as rich as with scripting

■ Limited control of flow for iteration through record sets

■ Limited direct access to object methods

Workflow Policy

Advantages include:

■ Responds to a database event regardless of whether it is initiated by an Object Manager component or by a non Object Manager component

■ Can realize higher transaction throughput on a set of hardware for a simple transaction


■ Changes to a policy can require database downtime to implement

■ More difficult to define than other alternatives

■ Allows a limited range of executable actions

Siebel Script Advantages include:

■ Familiar to many developers

■ Provides a set of semantics

■ Is flexible


■ Ease of maintenance

■ Ease of upgrade

■ Performance



Requirement Mapping to a Workflow Process or Workflow PolicyTable 17 summarizes some common requirements and recommends a workflow process or a workflow policy. For more information, see Chapter 14, “Defining a Custom Workflow Policy.”

Table 17. Requirement Mapping to a Workflow Process or Workflow Policy

Requirement Possible Solution Description

Capture business layer logic.

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

Capture data layer logic.

Workflow Policy Workflow Policy Manager captures data layer logic.

Data coming into the Siebel application through the data layer, for example EIM or MQ channels, is not captured through the business layer. This requirement typically indicates a potential candidate for a workflow policy.

Implement features supported by a workflow policy but not a workflow process.

Workflow Policy A workflow policy can support some features that are not available or would be more difficult to implement with a workflow process. For example, email consolidation, duration, and quantity.

Implement features supported by a workflow process but not a workflow policy.

Workflow Process A workflow process can provide pause, stop, and error handling capabilities.

Implement complex comparison logic, or flow management.

Workflow Process A workflow process provides a better platform for development and deployment, complex comparison logic, and flow management, such as IF, THEN, ELSE, or CASE.

Call a business service. Workflow Process A workflow process can call a business service.

Perform bulk data uploads.

Workflow Policy Workflow Policy Manager is the better alternative when bulk data uploads occur through EIM.

Perform data quality cleaning in the data layer.

Workflow Policy Workflow Policy Manager is the most appropriate solution for working at the data layer.

Use a repeating component request.

Workflow Process You can setup a workflow process from a repeating component request but not from a workflow policy.

Repetitive, manual processing.

Workflow Process The structure of a workflow process provides a superior solution for repetition, timeliness, and cross functional routing through a business process.

Process an event in a timely fashion.

Workflow Process

Perform escalations and notifications.

Workflow Process


Developing a Workflow Process ■ Process of Planning a Workflow Process

104

Process of Planning a Workflow ProcessThis process is a step in “Roadmap for Developing a Workflow Process” on page 97.

To plan a workflow process, perform the following tasks:

1 Determining the Mode of the Workflow Process on page 104

2 Determining How the Workflow Process Is Started on page 105

3 Determining Decision Logic of a Workflow Process on page 107

4 Determining Actions of a Workflow Process on page 109

5 Determining Error Handling on page 111

6 Examining Seed Workflow Processes on page 111

7 Determining Requirements for Managing the Development of Objects on page 112

8 Addressing Other Business Requirements on page 113

If your work in “Process of Analyzing Business Requirements” on page 99 determined that the workflow process is the most appropriate automation solution, then you can continue planning the workflow process. When planning a workflow process you determine how the process is built, including making design decisions, such as which workflow mode to use, the events to define, the rules to define, actions that the workflow process executes, and so forth.

Determining the Mode of the Workflow ProcessThis task is a step in “Process of Planning a Workflow Process” on page 104.

A workflow process can persist for just a few moments, such as aiding a user with generating an email, or it can span days and job functions, such as creating a quote to cash. This characterization is handled by the Workflow Mode property of the workflow process.

To determine the mode of the workflow process■ Map the business requirements to the most appropriate workflow mode.

For more information, see “About the Workflow Mode Property” on page 127.



Determining How the Workflow Process Is StartedThis task is a step in “Process of Planning a Workflow Process” on page 104.

During the planning phase of a development effort you can determine if the workflow process is started by a run-time event, user event, workflow policy, or a script. For more information, see “Starting a Workflow Process” on page 143.

To determine how the workflow process is started■ Consider the advantages and limitations of each mechanism that is available for starting a

workflow process that are described in this topic, then choose the mechanism that most closely matches the business requirements.

Using a a Workflow Policy to Start a Workflow ProcessA workflow policy starts a workflow process after a database change. If the workflow policy conditions are met, then an action occurs. In some cases, the action calls the Workflow Process Manager server component to execute a workflow process.

Processing that is started by a workflow policy does not occur in real time. Typical uses of a workflow policy include:

■ EIM batch processing

■ Siebel EAI inserts and updates

■ Manual changes from the user interface

■ Assignment Manager assignments

■ Siebel Remote synchronization

Using an Event to Start a Workflow ProcessTypes of events used by a workflow process include:

■ Run-time event. A run-time event is based in the Object Manager and occurs when a change is encountered by the user interface or in the business component layer. Processing that is started by a run-time event occurs in real time.

■ User event. A user event is a unique event that is internal to Siebel Workflow that starts or resumes a long-running workflow process. A user event is generated by the User Event business service.

An event belongs to three object types: Application object, Applet object, and Business Component object. An event can be defined from the administrative interface.



106

Using a Script to Start a Workflow ProcessA script can start a workflow process programmatically as a business service. Using a script, you can start a workflow from an external system. The Workflow Process Manager server component provides APIs for using programmatic techniques to start a workflow. A script is raised by the Object Manager. A script can be associated with one of the following objects: application, applet, business component, and business service.

Summary of Mechanisms for Starting a Workflow ProcessTable 18 summarizes the main uses and limitations for each of the mechanisms that are available to start a workflow process.

Table 18. Uses and Limitations of Mechanisms for Starting a Workflow Process

Starting Mechanism Uses Limitations

Workflow Policy

Uses include:

■ You must detect and react to data changes made outside of the Object Manager. For example, by Siebel Remote or by Siebel EIM


■ Making changes requires database downtime

■ Relatively complex to define

Event Uses include:

■ You must implement a basic entry point for a workflow or a simple custom action

■ You must avoid distributing the Siebel Repository File (SRF). For example, because of the burden created for mobile users


■ Cannot directly respond to an event by scripting against the event object

■ Can be more difficult to pass the event context to business logic

■ Does not trap data changes made by non Object Manager components

Script Uses include:

■ You require flexibility to write a script directly in response to an event

■ You require access to an applet event that is only exposed in Siebel Tools


■ Changes must be distributed through a new Siebel Repository File (SRF)

■ Does not detect data changes made by non Object Manager components. For a workflow, the script is implemented on a Siebel Tools Object Event.



Determining Decision Logic of a Workflow ProcessThis task is a step in “Process of Planning a Workflow Process” on page 104.

When planning to build a workflow process, you can determine the decision logic that guides the flow of control within the process.

To determine decision logic of a workflow process

1 Examine the business analysis work conducted thus far to identify what decision conditions, if any, are inherent in the business process.

For more information, see “Overview of Objects That Are Used with a Workflow Process” on page 18.

2 Map the requirements to the workflow process decision logic.

For more information, see “Ways to Implement Decision Logic in a Workflow Process” on page 107.

Ways to Implement Decision Logic in a Workflow ProcessTable 19 describes some ways to implement decision logic in a workflow process.

Table 19. Ways to Implement Decision Logic in a Workflow Process

Type Description Uses Limitations

Workflow Decision Point

A step in a workflow process that arbitrates between one or more alternative branches in the flow of the workflow.

Each connector that emanates from a decision point can contain one or more decision conditions. If the conditions evaluate TRUE for the connector, then flow proceeds down the branch represented by the connector.

When you require a simple articulation of whether one or more alternative branches in the flow must be executed.

Conditional expressions lack support for some key operators, including:

■ AND operator

■ OR operator

■ Order of precedence control, as determined by parentheses

Scripted Business Service

A script within a business service action step that evaluates a potentially complex set of inputs and returns a simplified output that can be evaluated by a workflow decision point.

When decision point semantics for a workflow process are not sufficiently expressive to encapsulate the required decision logic.

Undermines the readability and simplicity of the workflow by hiding decision logic within a business service.



108

Decision Conditions with the Decision PointA decision condition is used to evaluate the logical flow that must be taken on a branch in a workflow process. A decision point can exist with multiple connectors that represent logical branches. For each connector that provides branching, a decision condition is evaluated. A decision condition makes a comparison between two of the items in the following list:

■ 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.

Wait Step The wait step allows you to suspend the execution of a workflow process for a defined amount of time or until a specific event occurs.

When you must support a time based escalation or a long-running workflow that can last for days or weeks. For example, waiting for a customer response.

The releasing event must be called through the Object Manager.

Other Specialized Decision Frameworks

Other decision frameworks can be used directly or indirectly by a workflow process, such as personalization rules, assignment rules, EAI Dispatch Service, or the Siebel rules engine.

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

When it is deemed appropriate to use a specialized decision framework, such as when you must assign work to a person based on the workload for the person.

Limitations vary depending on the decision framework that is used.

Table 19. Ways to Implement Decision Logic in a Workflow Process

Type Description Uses Limitations



For an example of the Compose Condition Criteria dialog box that displays decision criteria, see “Defining a Decision Condition for the Decision Point” on page 259. For a description of properties in the Compose Condition Criteria dialog box, see “Defining a Decision Condition on a Branch Connector” on page 95.

Determining Actions of a Workflow ProcessThis task is a step in “Process of Planning a Workflow Process” on page 104.

You can determine the actions that the workflow process must execute.

To determine actions of a workflow process■ Identify the type of workflow actions that are required in order to meet the business

requirements.

For more information, see “Overview of Objects That Are Used with a Workflow Process” on page 18, and “Data Manipulation in a Workflow Process” on page 109.

Data Manipulation in a Workflow ProcessA workflow process operates on business objects and business components. Typically, a workflow process is associated with a single business object. Within the context of these data layer objects, data is generated or updated as the workflow executes. The main types of data a workflow manipulates include:

■ Business component data

■ Process property data

■ Siebel Common Object data

A process property can be thought of as a local variable that is active during execution of the instance of the workflow process. The process property can be used as input and output to the various steps in a workflow. A set of predefined process properties is automatically generated when you define the workflow. The Process Instance Id is one example of a predefined process property. For more information, see “About the Process Property” on page 47.



110

Uses and Limitations of an Action in a Workflow ProcessTable 20 describes the uses and limitations of an action in a workflow process.

Actions with the Business Service StepThe business service step executes predefined or custom business service methods. Typical business services that are predefined 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. If defining a business service step, then you must define the business service, the business service method, and input arguments and output arguments. Input arguments are passed in a process property, business component data, or a literal value.

The following list describes some business services that commonly used in a workflow process:

■ Outbound Communications Manager

■ Synchronous Assignment Manager Requests

■ Server Requests

■ Business Rule Service

■ Report Business Service

■ Audit Trail Engine

■ EAI business services, such as EAI Siebel Adapter, EAI XML Converter, and so forth

Table 20. Uses and Limitations of an Action in a Workflow Process

Action Type Description Uses Limitations

Business Service Step

A workflow step that calls a method of a business service.

The business service can be a prebuilt Siebel service or a scripted business service.

When you must execute a potentially complex, but reusable set of logic.

Defining and destroying business services can be expensive. Overhead can be reduced through caching.

Incorporating too much logic within a business service can limit reusability for the business service and the transparency of the workflow.

Siebel Operation Step

A workflow step that performs inserts, updates, and queries against Siebel business components.

When you must execute simple record operations within the workflow.

While it is possible to update multiple records based on a search specification, it is not possible to retrieve and iterate through a set of records such that subsequent actions for the workflow process can execute for each record.



■ FINS Data Transfer Utilities and FINS Validator

For more information, see “About the Business Service Step” on page 70, and “Predefined Business Services” on page 482.

If you require specialized functionality, then you can define a custom business service for the specific activity. A business service can be defined in Siebel Tools or in the administration screens of the Siebel client. For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration.

Actions with the Siebel Operation StepThe Siebel operation step allows you to perform database operations, such as Insert, Update, Upsert, Query, Delete, NextRecord, PreviousRecord, and QueryBiDirectional. The Siebel operation step is based on a single business component. After you define the Siebel operation step, you can use the Search Specification to locate the records that you must manipulate. Examples of a Siebel operation step include generating an activity when a new SR is created, or updating a comment field if an SR is open too long. For more information, see “About the Siebel Operation Step” on page 75.

Determining Error HandlingThis task is a step in “Process of Planning a Workflow Process” on page 104.

Error handling options range from a simple solution of using a stop step in a workflow process, to defining a separate error-workflow process. The planning phase is an appropriate time to plan for how to recover from a failed workflow. For more information, see“Handling Errors” on page 164.

To determine error handling

1 Determine what, if any, error handling is necessary to meet the business requirements.

2 Identify the error handling action that is required to meet the business requirements.

Examining Seed Workflow ProcessesThis task is a step in “Process of Planning a Workflow Process” on page 104.

A seed workflow process is a workflow process that comes predefined with the product. Before building a new workflow, you can determine whether a seed workflow already exists that meets your business requirements.



112

To examine seed workflow processes

1 In Siebel Tools, click Workflow Process in the Object Explorer.

2 Scroll through the Workflow Processes OBLE, scanning the Process Name property for a potential candidate.

Seed workflow processes include workflows that appear in the Workflow Processes OBLE immediately after Tools is installed but prior to new workflow processes being defined.

3 Use the Process Designer in Siebel Tools to further examine potential candidates that you identify in Step 2.

To determine whether or not it is appropriate to use a copy of the seed workflow process, consider the level of modification that is necessary to meet the business requirements.

4 If you identify a candidate workflow process, then make a copy of it and modify the copy.

Because seed workflow processes are used to execute some of the base functionality of the Siebel application, they must not be edited. Instead, create a copy of the seed workflow, then edit the copy. For more information, see “Copying a Workflow Process” on page 118.

Determining Requirements for Managing the Development of ObjectsThis task is a step in “Process of Planning a Workflow Process” on page 104.

When planning a workflow process, you can determine requirements for managing the development of objects, such as whether there are special requirements for merging, archiving, and importing data maps, or copying message tables. If a team of developers is involved in the development environment, then you can consider how project check in and check out can be used.

To determine requirements for managing the development of objects

1 Consider the number of developers that are involved in the project and the requirements of their development environments.

2 Choose a mechanism for managing objects.

For more information, see “Object Management in Siebel Tools” on page 112.

Object Management in Siebel ToolsWhen you develop a workflow process in Siebel Tools, you work on a local database where Siebel Workflow is a repository object, and where a workflow belongs to a project.

Though compiling a Siebel Repository File is a standard practice for other repository objects, a workflow process uses a different deployment mechanism. You do not compile an SRF after you develop a workflow. For more information, see “Process of Deploying a Workflow Process” on page 211.



Although these behaviors are standard for other repository objects, the behaviors that a workflow process does not participate in include:

■ Merge. A workflow process does not participate in three way merge. If a workflow is imported into the repository, then it maintains versioning provided by the workflow.

■ Object Comparison. The object comparison mechanism is disabled in Siebel CRM version 8.0.

■ Archive. A workflow process does not participate in the usage of sif files for archiving. Instead, a workflow can be archived as an XML file using the Siebel Workflow export utility.

Typically, a developer uses a local database to develop a workflow process. If you are using a local database, then you must check out the workflow from the master repository.

If you are developing a workflow process on a local database, then the local database must contain the referenced data objects. For those data objects that are not docked and hence not packaged as part of the database extract, the developer must import them into the local database. Objects not docked or referenced by Siebel Workflow include:

■ Data maps. To import a data map to the local database, you use the Siebel Developer Web Client connected to the local database, and the import utility on the client.

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

By locking the project in the master repository, you can also develop or modify a workflow process by using Siebel Tools that is connected to the development database. This way, it is not necessary for you to make sure lists of values are made available to the local database.

Addressing Other Business RequirementsThis task is a step in “Process of Planning a Workflow Process” on page 104.

Consider your development and implementation environment in order to determine whether you must address other business requirements.

To address other business requirements■ Consider some of the other business requirements you can address during the planning phase:

a Use the Workflow Process Batch Manager to run a workflow process against records in a business component at a predetermined interval.

For more information, see “Using Batch Processing” on page 172.

b If the workflow process is implemented in a multilingual environment, then address globalization.

For more information, see “Defining a Workflow Process for a Multilingual Environment” on page 175.


Developing a Workflow Process ■ Job Roles That Are Involved in Developing a Workflow Process

114

Job Roles That Are Involved in Developing a Workflow ProcessJob roles are presented in this topic in order to assist with describing the design and development efforts that required to implement a workflow process . Job roles, job titles, and division of labor might vary significantly for your organization. The following job roles are associated with developing a workflow process:

■ The business analyst considers business requirements for your organization and determines the processes to be automated.

■ The workflow configurator uses Siebel Tools to build a workflow process and to define objects, business services, and programs. Your organization can use the predefined objects, business services, or programs that are provided in the application. The workflow configurator can also define custom objects, business services, and programs in Siebel Tools. A business service can also be defined in the Siebel client. For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration.

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

■ The end user uses the Siebel client and causes the workflow process and policy to execute. This person is typically an employee of your organization, and can also be a customer.


7 Process of Building a Workflow Process

This chapter describes the process you must perform to build a workflow process. This process is a step in “Roadmap for Developing a Workflow Process” on page 97.

To build a workflow process, perform the following tasks:

1 Preparing Siebel Tools to Develop a Workflow Process on page 115

2 Defining a Workflow Process on page 117

3 Diagramming a Workflow Process on page 122

4 Defining a Process Property for a Workflow Process on page 124

5 Defining a Property for the Step of a Workflow Process on page 126

For an example that details how these steps are performed, see “Example of Defining a Workflow Process That Creates an Activity for a Sales Representative” on page 255.

Preparing Siebel Tools to Develop a Workflow ProcessTo develop a workflow process, you begin by preparing Siebel tools.

To prepare Siebel Tools to develop a workflow process

1 Set the following parameter in the [Workflow] section of the configuration file of the application:

VerCheckTime = -1

Setting VerCheckTime to -1 allows you to use the Publish/Activate button. The configuration file is typically in the language directory for the client. For example:

Siebel\81\21031\MWC\BIN\ENU\uagent.cfg

where:

■ ENU is the language directory

■ uagent.cfg is the configuration file

For more information, see “Buttons on the WF/Task Editor Toolbar” on page 62.

2 Log in to Siebel Tools.

3 From the application-level menu, choose the View menu, Toolbars, then the WF/Task Editor Toolbar menu item.

4 From the application-level menu, choose the View menu, Toolbars, then the Simulate menu item.


Process of Building a Workflow Process ■ Preparing Siebel Tools to Develop a Workflow Process

116

5 Expose the object types that are used to develop a workflow process.

For more information, see “Exposing Object Types That Are Used to Develop a Workflow Process” on page 116.

6 If necessary, expose business service objects.

A business service object can contain hidden properties. In order for a business service, business service method, or business service method argument to be displayed on a dropdown list in Siebel Tools, the Hidden property for the object must be set to FALSE.

Exposing Object Types That Are Used to Develop a Workflow ProcessThis topic describes how to expose object types in the Object Explorer that are used to develop a workflow process.

To expose object types that are used to develop a workflow process

1 Log in to Siebel Tools.

2 From the application-level menu, choose the View menu, then the Options menu item.

3 Click the Object Explorer tab.

4 Scroll down through the Object Explorer Hierarchy window to locate the Workflow Process object type, then expose it by making sure the Workflow Process object and all child objects for it contain a checkmark.

5 Repeat Step 4 for the Workflow Policy Object object type.

6 Repeat Step 4 for the Workflow Policy Program object type.

7 Make sure the Workflow Policy Column object contains a checkmark.

8 (Optional) Expose other object types that might be used to develop a workflow process:

■ Expose the Command object type.

■ Expose the Toolbars object type.

■ Repeat Step 4 for the Business Object object type.

9 Click OK.

Process of Building a Workflow Process ■ Defining a Workflow Process


Defining a Workflow ProcessThis task is a step in “Process of Building a Workflow Process” on page 115.

The first part of building a workflow process is to define the top level object definition for the workflow. This topic includes the following topics, each of which describes a possible option for defining a workflow:

■ Reviewing Workflow Processes on page 117

■ Copying a Workflow Process on page 118

■ Modifying a Workflow Process on page 118

■ Revising a Workflow Process on page 119

■ Defining a New Workflow Process on page 120

This topic also includes the following related topics:

■ Naming a Workflow Process on page 120

■ Externalizing Workflow Properties on page 120

■ Making a Workflow Process Editable on page 120

■ Deleting a Workflow Process on page 121

For more information, see “About the Object Hierarchy of a Workflow Process” on page 39.

Reviewing Workflow ProcessesReview existing workflow processes to determine if the workflow you require is already available, or if a similar workflow exists that you can copy and modify in order to meet your requirements. The Object List Editor (OBLE) for Workflow Processes displays a list of object definitions for workflows. You can access the Workflow Processes OBLE in Siebel Tools.

To review existing workflow processes

1 In Siebel Tools, in the Object Explorer, click Workflow Process.

The right pane displays the Workflow Processes OBLE, which lists object definitions for the workflow processes.

2 Examine the list of existing workflow processes, perusing the Process Name, Business Object and Workflow Mode properties for a combination of properties that meet your business requirements.

3 If you find a workflow process that is a potential candidate, then right-click the workflow in the Workflow Processes OBLE, choose Edit Workflow Process, then use the Process Designer to examine the flow of steps as well as process and step properties.

4 If you find a workflow process that you must copy as the basis for a new workflow, then right-click the workflow, and then choose Copy Record.

For more information, see “Copying a Workflow Process” on page 118.



118

Copying a Workflow ProcessIf your intent is to define a different workflow process, with a different name and a different purpose, then you can copy an existing workflow. The copied workflow does not replace the original workflow. In contrast to revising a workflow, when you copy a workflow, you define a new workflow that is identical to the original one, except that a unique name, such as 04-K88GQ, is generated for it. The version of a new, copied workflow is 0. If you revise a workflow, then the version is the next integer that is subsequent to the version number of the original workflow that is being revised.

To copy a workflow process

1 Locate the workflow process you must copy.


2 Right-click the workflow process in the Workflow Processes OBLE, then chose Copy Record.

A new copy of the workflow process is generated and displayed in the Workflow Processes OBLE and a unique numeric identifier appears in the Process Name property.

3 Update the Process Name property so it is meaningful.

4 Modify the other properties, as necessary, for the new workflow process.

Modifying a Workflow ProcessYou can modify an existing workflow process without restarting the Workflow Process Manager. A workflow is refreshed in the process memory as soon as it is activated. If a new workflow is deployed, then the cache is refreshed, so a new instance picks up the newly deployed workflow. To modify a workflow process, you must make it editable. For more information, see “Making a Workflow Process Editable” on page 120.

Cache Refresh for a Workflow ProcessThe timing of when a workflow process is activated affects the process cache:

■ The caches of threads in the same workflow process are refreshed and these threads get the updated workflow immediately.

■ The caches of threads in other workflow processes are not refreshed until the interval defined by the server parameter named VerCheckTime expires.

For a mobile client and a development client, the server parameter named Workflow Version Checking Interval (VerCheckTime) controls how often the server component checks for new active versions of each workflow process. If a new workflow is activated, then an incoming workflow instance that is created during the interval that is determined by Workflow Version Checking Interval uses the new definition for the workflow. An instance of the workflow is initiated before the interval uses the previous definition for the workflow.



Scenarios to consider include:

■ Activation in a thin client. If a workflow process is activated from a thin client, such as the Call Center application, then user sessions in the same Call Center application server process get the updated workflow immediately. However, user sessions in other server processes must wait for the VerCheckTime interval that is defined in the server process configuration before they receive the updated workflow.

■ Activation in a mobile or development client. Each mobile or development client constitutes a separate process. The particular mobile or development client receives the updated workflow process immediately. Other mobile or development clients must wait for the VerCheckTime interval that is defined in their configuration files before they can receive the updated workflow.

■ Publish/Activate in Siebel Tools. The Siebel Tools application constitutes a separate process. A thin client and mobile or development client must wait for the VerCheckTime interval before the client can receive the updated workflow process.

Reloading Run-Time EventsRefreshing the workflow process cache is necessary but not sufficient for running the updated workflow process correctly. If the workflow contains a run-time event, then the run-time event cache must also be refreshed.

To reload run-time events for a thin client

1 In the Siebel client, navigate to the Administration-Runtime Events view.

2 Right-click the context menu, then choose Reload Runtime Events.

To reload run-time events for a mobile client■ Log out of, then log back in to, the mobile client.

This guarantees that the cache of the workflow process is refreshed.

Revising a Workflow ProcessTo revise a workflow process, you modify the existing object definition for the workflow. If you revise a workflow, then the new workflow that is generated is the same as the original, with the same name, except that the version for the workflow is incremented by one, the Status is In Progress rather than Completed, and the workflow is editable. The revised workflow replaces the original workflow.

To revise a workflow process





120

2 In the WF/Task Editor toolbar, click Revise.


3 Right-click the new workflow process, then choose Edit Workflow Process.

4 Modify this new version, as necessary.

Defining a New Workflow ProcessIf you cannot locate an existing workflow process that meets your requirements, then you can define a new one. For an example, see “Defining the New Workflow Process” on page 256.

Naming a Workflow ProcessWhen naming a workflow process, the combination of workflow process name and version must be unique. That is, two workflow processes can contain the same name as long as their version numbers are unique.

Externalizing Workflow PropertiesWhen developing a workflow process, it is recommended that you define properties for the workflow that are externalized and that are not hard coded. Hard coding a property in a workflow requires you to change the definitions when the workflow is deployed between environments. For example, if a workflow sends an email to a list of customers and the property is hard coded with the customer list, then the workflow does not execute correctly in the production environment. You must make sure such input arguments are read dynamically.

For more information, see “Example of Externalizing Properties when Using a Business Service” on page 316.

Making a Workflow Process EditableThe canvas color in the Process Designer indicates whether the workflow process is editable. For more information, see “About the Process Designer” on page 44.

To make a workflow process editable

1 Make sure the workflow process is either checked out or is locked by the developer who is currently attempting to edit the workflow process.

2 Make sure the project that is defined in the Project property for the workflow process is locked.

3 If the workflow process is a seed workflow, then make a copy of the workflow and edit the copy.

For more information, see “Examining Seed Workflow Processes” on page 111.



4 If you still cannot edit an existing workflow process, then export the workflow to your desktop, and then import the workflow.

The Version property for the editable version increments by 1. For more information, see “Importing and Exporting a Workflow Process” on page 224.

Deleting a Workflow ProcessYou can delete a workflow process in the Object List Editor in Siebel Tools.

To delete a workflow process

1 Locate the workflow process you must delete.


2 Right-click the workflow process, then choose Delete Record.

You cannot delete a seed workflow process. For more information, see “Examining Seed Workflow Processes” on page 111.


Process of Building a Workflow Process ■ Diagramming a Workflow Process

122

Diagramming a Workflow ProcessThis task is a step in “Process of Building a Workflow Process” on page 115.

Diagramming process steps is an important part of defining a functioning workflow process. The flowchart interface of the Process Designer allows you to build a visual representation of the entire flow, including decision points and conditional logic. You can choose to define the details for each step as you define each step in the Workflow Designer, or you can define the entire flow, then enter details for each step. For more information, see “About the Process Designer” on page 44.

To diagram a workflow process

1 Drag, then drop a Start step from the palette to the canvas.

A workflow process must contain only one Start step. For more information, see “About the Start Step” on page 69.

2 Drag, then drop one or more middle steps from the palette to the canvas.

A workflow process can contain one or more steps that perform an action, such as a business service, decision point, sub process, task, stop, wait, or Siebel operation. There can be more than one of each type of step in a workflow. For more information, see “Types of Steps of a Workflow Process” on page 69.

3 Drag, then drop an end step from the palette to the canvas.

A workflow process must contain at least one end step. For more information, see “About the End Step” on page 90.

4 Define the flow and path of the workflow process by dragging and dropping a connector from the palette to the canvas. Position one end of the connector on one side of a step, then drag the connector handle to connect the other end of the connector to the next step in the flow.

NOTE: A connector end point that is colored white is not connected correctly to a step. A red end point indicates that the connector is correctly connected. Make sure both ends of every connector in the workflow process is colored red.

5 Repeat Step 4 until every step in the workflow process is connected correctly.

A connector that emanates from certain step types can provide conditional logic for the workflow process. For more information, see “Defining a Branch Connector” on page 92.

Displaying the Label for a ConnectorYou can hide or display the text that is displayed as a label on a connector. In some cases, you might prefer to suppress this text. For example, you can hide the text label for the connector that emanates from the Start step, which defaults to Connector 0.

Process of Building a Workflow Process ■ Diagramming a Workflow Process


To display the label for a connector

1 In the Process Designer, right-click the connector on which you must display or hide the label.

2 From the pop-up menu, choose the Edit menu, then the Hide Text menu item.

The label for the connector is hidden.

3 To display the label, repeat Step 2.

Adding or Removing a Point in a ConnectorYou can add or remove a point in a connector.

To add or remove a point in a connector

1 Click the connector or error exception connector.

2 Right-click, then choose one of the following options:

■ Choose the Edit menu, then the Add Point menu item

■ Choose the Edit menu, then the Remove Point menu item


Process of Building a Workflow Process ■ Defining a Process Property for a Workflow Process

124

Defining a Process Property for a Workflow ProcessThis task is a step in “Process of Building a Workflow Process” on page 115.

You can define a process properties in either the Multi Value Property Window (MVPW) or in the WF Process Props OBLE. You can define process properties as you diagram a workflow process, or you can diagram the entire workflow, then define properties for individual steps. However, it is recommended that you define process properties before defining an input or output argument on an individual step because some of those arguments can reference a process property. For more information, see “About the Process Property” on page 47.

To define a process property for a workflow process



2 Right-click the workflow process, then choose Edit Workflow Process.

3 From the application-level menu, choose the View menu, Windows, then the Multi Value Property Window menu item.



5 In the MVPW, make sure the Process Properties tab is chosen.

6 In the MVPW, right-click in the window that is located below the Process Properties tab, then choose New Record.

7 Enter a name for the process property.

For more information, see “Name of a Step in a Workflow Process or a Process Property” on page 67.

Process of Building a Workflow Process ■ Defining a Process Property for a WorkflowProcess


8 Define the Data Type field, using values from the following table.

The String data type code is appropriate for strings, text data, and non XML data, even though XML data can also be stored as string data. It is assumed that string data in a workflow process is UTF 16 String encoded. Literal or Expression data types are UTF 16 String.

NOTE: After a data type is chosen, it cannot be modified.

9 Define the Default String, Default Date, or Default Number property, if applicable.

The value you define in one of these properties is the value that is used at the beginning of execution for a workflow process. If the corresponding data type for the value is chosen, then you only define one of these default values. For example, if you define the Date data type, then you can define a Default Date.

10 Repeat Step 5 through Step 9 to define more process properties, as necessary.

Data Type Type of Data the Process Property Holds

String Character value.

Number Numeric value.

Date Date value.

Hierarchy Hierarchical data, as in a property set.

Binary Binary value.

Binary data is encoded in the original character set in which it was entered. This data type code is appropriate for data that is self describing , such as XML.

Integration Object

Integration object.

The Siebel SRF uses the integration object definition for this object..

Strongly Typed Integration Obj

Strongly typed integration object.

Alias XPath notation for pointing to a child in a hierarchical process property.


Process of Building a Workflow Process ■ Defining a Property for the Step of a Workflow Process

126

Defining a Property for the Step of a Workflow ProcessThis task is a step in “Process of Building a Workflow Process” on page 115.

The properties of a step in a workflow process can include input and output arguments, search specifications, operations, and so forth. You can use the WF Steps OBLE to define some of these properties. You can also use the Properties window and the MVPW from within the Process Designer to define the properties for a step. Properties of a step must be defined one step at a time.

To define a property for the step of a workflow process

1 With the Process Designer open, click the step whose properties must be defined.

2 Use the Properties window to define properties for the step.

If the Properties window is not displayed, then right-click and choose View Properties Window. For more information, see “Overview of Workflow Process Steps” on page 65.

3 Use the MVPW to define input arguments, output arguments, and search specifications.



8 Options for Developing a Workflow Process

This chapter describes options for developing a workflow process. It includes the following topics:

■ About the Workflow Mode Property on page 127

■ Starting a Workflow Process on page 143

■ About Events on page 157

■ Handling Errors on page 164

■ Using Batch Processing on page 172

■ Defining a Workflow Process for a Multilingual Environment on page 175

For other related topics, see Chapter 9, “Manipulating Data.”

About the Workflow Mode PropertyThis topic includes the following topics:

■ Types of Modes for a Workflow Process on page 127

■ Options for the Workflow Mode Property on page 129

■ Options for an Interactive Workflow Process on page 130

■ Options for a Long-Running Workflow Process on page 139

■ Workflow Persistence on page 141

Types of Modes for a Workflow ProcessThis topic includes the following topics:

■ About the Service Workflow Process on page 128

■ About the Interactive Workflow Process on page 128

■ About the Long-Running Workflow Process on page 129

■ About the 7.0 Workflow Process on page 129

There are four modes that can be used to characterize the run-time behavior of a workflow process. The mode is set by modifying the Workflow Mode property in the Workflow Processes Object List Editor (OBLE).


Options for Developing a Workflow Process ■ About the Workflow Mode Property

128

The types of modes for a workflow process that are described in this topic include:

■ Service Flow

■ Interactive Flow

■ Long Running Flow

■ 7.0 Flow

About the Service Workflow ProcessThe service workflow process is a type of workflow process that executes a set of operations, performing a unit of work from beginning to end. A service workflow is a transient workflow, which is a workflow that runs to completion in a short amount of time without stopping or pausing for an event or activity. A service workflow is the lowest common denominator of the types of modes for a workflow in that no special behavior is associated with it, and it can be a subprocess in another service workflow, an interactive workflow, or a long-running workflow, but not a 7.0 workflow. The service workflow mode simply executes a set of operations upon calling an event.

Restrictions when using a service workflow process include:

■ A service workflow process cannot wait for a run-time event or pause for a time.

■ A service workflow process cannot contain a user interact step or a wait step. The Process Designer does not allow you to add a user interact step or a wait step to a service workflow process.

For an example service workflow process, see “Example of Defining a Workflow Process That Creates an Activity for a Sales Representative” on page 255.

About the Interactive Workflow ProcessThe interactive workflow process is a type of workflow process that assists and controls navigation for an end user across Siebel views and screens. An interactive workflow includes one or more user interact steps, and usually includes a run-time event.

For an example, see “Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the User” on page 301.

For more information, see “Options for an Interactive Workflow Process” on page 130.

Interactive Workflow Process in a UI ContextAn interactive workflow process can run only in the context of an end user session. An interactive workflow cannot run in the Workflow Process Manager server component, nor in other server components that do not contain a UI context, such as Business Integration Manager. To run in the context of a session for an end user means the workflow must run within an Application Object Manager that contains UI context, such as Siebel Call Center, Siebel Service, Siebel eSales, or Siebel eService. These applications support view navigation, view display, and so forth, which is necessary when using an interactive workflow because they perform view display through the user interact step, and they require interaction with the end user for clicking buttons and hyperlinks.



About the Long-Running Workflow ProcessThe long-running workflow process is a type of workflow process that is persistent and that can last for hours, days, or months. One example of a long-running workflow is Send Order to External. In this example, the workflow sends an order to an external system, then waits for a response.

You can use the Long Running Flow mode to define a single workflow process in order to handle an entire business process transaction to coordinate between multiple subprocesses. The Quote to Cash business process is an example transaction where a long-running workflow is useful.

You can build a long-running workflow process that is collaborative by assigning a subprocess to an end user. You do this by employing the Workflow User Event Service business service, which generates a user event that can span from one user or session to another user or session. For more information, see “Workflow User Event Service Business Service” on page 486.

You cannot use a user interact step in a long-running workflow process. However, you can add an interactive workflow as a sub process step in a long-running workflow. Also, you cannot use the Process Simulator in Siebel Tools to simulate a long-running workflow.

For more information, see “Options for a Long-Running Workflow Process” on page 139 and “Defining a Subprocess that Assigns a Long-Running Workflow Process” on page 140.

About the 7.0 Workflow ProcessThe 7.0 workflow process is a type of workflow process that provides backward compatibility for an existing workflow that was defined in a Siebel release earlier than Siebel CRM version 7.7. If an existing workflow was defined earlier than version 7.7, and you upgrade to version 7.7, then the existing workflow becomes a 7.0 Flow by default. For a new workflow that you define, you must use the service, interactive, or long-running workflow mode.

If you must upgrade a workflow process that was defined earlier than Siebel CRM version 7.7 to version 8.0, then the workflow must first be defined as a 7.0 workflow because a pre 7.7 workflow must first be upgraded to version 7.7 before the upgrade to version 8.0.

NOTE: It is strongly recommended that you do not use the 7.0 Flow workflow mode when you define a new workflow process. Earlier than Siebel CRM version 8.1, if you do not define a workflow mode, then the mode is assumed to be 7.0 Flow. When you define a new workflow process, be sure to define a Workflow Mode other than 7.0 Flow so that 7.0 Flow is not assumed as the default mode. In Siebel version 8.1, when you define a new workflow process, the Workflow Mode defaults to Service Flow.

Options for the Workflow Mode PropertyThis topic describes how the workflow mode determines the types of steps a workflow process can contain.

Workflow Mode Usage with the Wait Step and the User Interact StepThe mode property for a workflow process must be set to Interactive Flow when the workflow includes a user interact step. Such a workflow can contain a wait step that waits for an event. In some cases, a wait is not required. For example, a dummy wait step is used to assign values for process properties.



130

A workflow process with a wait step is a long-running workflow only when the wait step waits for a amount of time, after which the workflow must be resumed from the Workflow Process Manager. In other cases, if the wait step waits for a run-time event in the same session for an end user, then the workflow is not a long-running workflow. This type of workflow can contain end user interact steps, which make it an interactive workflow.

Workflow Mode Usage with the Sub Process StepA workflow process can call multiple subprocesses, but the workflow mode of the calling workflow process must be consistent with the workflow mode for the subprocess.

Table 21 describes the allowed pairings between the calling workflow process and the subprocess.

Options for an Interactive Workflow ProcessThis topic includes the following topics:

■ About the Synthetic Event on page 131

■ Suspension and Resumption of an Interactive Workflow Process on page 137

For examples of an interactive workflow processes, see:

■ Example of Defining a Workflow Process That Attaches an Activity Plan to an Opportunity on page 281

■ Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the User on page 301

Table 21. Workflow Modes That Are Allowed Between the Calling Workflow Process and the Subprocess

Mode of the Calling Workflow Process Workflow Mode That is Allowed For the Subprocess

Service Flow Service Flow

Interactive Flow Any of the following modes can be used:

■ Service Flow


Long Running Flow Any of the following modes can be used:

■ Service Flow



7.0 Flow 7.0 Flow



About the Synthetic EventA synthetic event is a specialized run-time event that is dedicated to controlling navigation for a workflow process. Examples of synthetic events include Suspend, Resume, Next, and Back. Associated with buttons on the user interface, these synthetic events are interpreted by the Workflow Engine to control workflow navigation by navigating the end user back or forward, and by suspending or resuming a workflow process. For example, assume the Siebel application contains an Account Note view with an Account Entry Applet that includes Back, Next, and SaveWorkflow synthetic events. These buttons allow the end user to move forward or backward from the Account Note view, or to suspend an interactive workflow process, then return later to resume the workflow.

After you define the buttons, you associate methods within the interactive workflow process. For example, with Back and Next synthetic events, you associate methods to outgoing connectors on the user interact step. You set the method name for the synthetic event in the MethodInvoked property of the button controls.

Comparison of a Synthetic Event to a User EventA synthetic event differs from a user event. A user event is an event that is internal to Siebel Workflow which is used purely to resume a workflow process from the Workflow Process Manager server process. A user event can be used only in a long-running workflow.

A synthetic event is a run-time event and is used to resume a workflow process from the application object manager where the synthetic events are generated. Therefore, a synthetic event can only be used with an interactive workflow and a 7.0 workflow.

Forward and Backward Navigation Between ViewsYou can use a synthetic event to define an interactive workflow process so that when the user clicks Next or Back, the user is navigated to the next or previous view in the sequence without losing the context of the instance of the workflow.

NOTE: Use a synthetic event to allow the user to navigate backward through views. A run-time event allows forward navigation, but not backward navigation.

Requirements that must be met in order for a workflow process to navigate back and forth include:

■ The resumed workflow process must be an interactive workflow or a 7.0 workflow.

■ The calling event must be a navigation event of a workflow process. That is, an event with a name such as InvokeMethod, and a sub event with a name such as FrameEventMethodWFBFxxxx or EventMethodWFBFxxxx, where xxxx is the name of the event, such as Next.



132

Table 22 describes backward and forward navigation that is available for workflow modes.

Guidelines for Backward NavigationGuidelines for deciding whether to allow backward navigation in your workflow process include:

■ The backward navigation feature does not undo the effect of the workflow process. Backward navigation only modifies the current step counter to point to a previous step.

■ The workflow configuration must make sure the segment of the workflow process that can be repeated by the backward navigation feature is idempotent. That is, acts as if used only one time, even if it is used multiple times.

Methods of a Synthetic EventTable 23 describes methods of a synthetic event.

Table 22. Backward and Forward Navigation with Workflow Modes

Workflow Mode Supported Workflow Mode Not Supported

Modes that are supported with backward and forward navigation include:


■ 7.0 Flow

Modes that are not supported with backward and forward navigation include:

■ Service Flow


Table 23. Methods of a Synthetic Event

Synthetic Event Method Description

FrameEventMethodWFNext Moves the end user forward in the interactive workflow process by using an applet.

You can also give the method name a prefix of BF, as in FrameEventMethodWFBFxxxx. Use this optional BF prefix to define backward and forward behavior of the synthetic event. A synthetic event with this prefix can be used to resume a workflow process from a step that is different from the current step at which the workflow is waiting.

EventMethodWFNext Operates the same as FrameEventMethodWFNext, except navigation is through the business component.

FrameEventMethodWFBack

EventMethodWFBack

Moves the user backward in the interactive workflow process.



Defining a Synthetic Event Button for Next and Back EventsThis topic describes how to define a synthetic event button for next and back events.

To define a synthetic event button for next and back events

1 In Siebel Tools, identify a view to which a user interact step must navigate the end user.

2 Define a Next button or a Back button on an applet where the event is called.

The button must be exposed in the applet that is based on the primary business component that is associated with the business object defined for the workflow process. For example, if the workflow process is based on the Service Request business object, and if the view displays activities associated with a service request, then the button must be exposed in the applet that is based on the Service Request business component. In this example, if the button is exposed in the applet that is based on the Activities business component, then the synthetic event button does not work. For more information, see Using Siebel Tools.

3 Define the MethodInvoked property of the button control as the name of the associated event. For example, FrameEventMethodWFBack for backward navigation.

SaveWorkflow Suspends and saves the interactive workflow process and makes it appear in the Inbox for the end user.

ResumeLastIntFlow Resumes the last executed interactive workflow process.

ResumeLastIntFlow is different from the other events in that it is not tied to a specific workflow process and can be called from elsewhere in the Siebel application. That is, the button corresponding to this event can be put in an applet, including the task bar where the Site Map icon is located, which is the recommended location for this button.

Table 23. Methods of a Synthetic Event

Synthetic Event Method Description



134

4 In the Process Designer, associate the applet type run-time event.

For example, assign FrameEventMethodWFBack to the outgoing connectors of the user interact step in the workflow process that receives the event. Assign the event using values from the following table.

TIP: It is not necessary for you to manually define buttons for each applet. You can copy a button that you define to other applets by using the Applet Comparison feature in Siebel Tools. Also, if you add the applet button controls to the HTML Model Controls applet, then when you define a new applet with the New Applet Wizard you can choose the method buttons that are related to a workflow process.

Defining a Synthetic Event Button for the SaveWorkflow EventThis topic describes how to define a synthetic event button for the saveworkflow event.

To define a synthetic event button for the saveworkflow event


2 Define a Save button on an applet where the event is called.

For more information, see Using Siebel Tools.

3 Define the MethodInvoked property of the button control as the name of the associated event, SaveWorkflow.

4 Use the following script to call the event handler for Siebel Workflow to handle the button click event. The script also passes to the Siebel Workflow event handler the contextual information for the event, which is the name of the view where the event occurs. It is not necessary for you to define the event in the workflow process.

function WebApplet_InvokeMethod (MethodName)

{

return (ContinueOperation);

}

function WebApplet_PreCanInvokeMethod (MethodName, &CanInvoke)

{

Property Value

Event Type Applet

Event Obj AppletName

Event InvokeMethod

Sub Event [Method Name] For example, FrameEventMethodWFBack.



// Recognize SaveWorkflow event, which is

// used to save Interactive flow

if (MethodName == "SaveWorkflow")

{

CanInvoke = "TRUE";

return (CancelOperation);

}


}

function WebApplet_PreInvokeMethod (MethodName)

{

// Handle SaveWorkflow event.

// Call Workflow Process Manager to save the interactive

// flow(s) that is waiting in the current view.

if (MethodName == "SaveWorkflow")

{

var Inputs= TheApplication().NewPropertySet();

var Outputs = TheApplication().NewPropertySet();

// Event name ("SaveWorkflow"), view name, and the rowId

// of the active row of the underlying buscomp are

// three required parameters for handling the event

Inputs.SetProperty("Event Name", MethodName);

var viewName= TheApplication().ActiveViewName();

Inputs.SetProperty("Sub Event", viewName);

var bc = BusComp ();

var bcId = bc.GetFieldValue ("Id");

Inputs.SetProperty("RowId", bcId);



136

var workflowSvc= TheApplication().GetService("Workflow Process Manager");

workflowSvc.InvokeMethod("_HandleSpecialEvent", Inputs, Outputs);


}


}

Defining a Synthetic Event Button for the Resumelastintflow EventThis topic describes how to define a synthetic event button for the resumelastintflow event.

To define a synthetic event button for the resumelastintflow event


2 Define a Resume button on the applet where the event is called.


3 Define the MethodInvoked property of the button control as the name of the associated event, ResumeLastIntFlow.

4 Use the following script to call the event handler for Siebel Workflow in order to handle the button click event. The script also passes to the event handler the contextual information for the event, which is the name of the view where the event occurs. It is not necessary for you to define the event in the workflow process.

function WebApplet_InvokeMethod (MethodName)

{


}

function WebApplet_PreCanInvokeMethod (MethodName, &CanInvoke)

{

if (MethodName == "ResumeLastIntFlow")



{

CanInvoke = "TRUE";


}


}

function WebApplet_PreInvokeMethod (MethodName)

{

// Call Workflow Process Manager to resume the last-executed interactive flow

if (MethodName == "ResumeLastIntFlow")

{

var Inputs= TheApplication().NewPropertySet();

var Outputs = TheApplication().NewPropertySet();

var workflowSvc= TheApplication().GetService("Workflow Process Manager");

workflowSvc.InvokeMethod("_ResumeLastInteractFlow", Inputs, Outputs);


}


Suspension and Resumption of an Interactive Workflow ProcessAn interactive workflow process that is suspended can be resumed from within the Inbox for the end user. The user can navigate out of an interactive workflow, then navigate back into the workflow and continue where the user suspended the workflow.



138

For example, assume a transaction that involves the end user, an insurance agent, cannot be finished because some information is missing, such as the social security number for a spouse that is required for an insurance policy quote to be considered finished. In this example, when the insurance agent eventually obtains the social security number after suspending the interactive workflow process, the insurance agent can resume the workflow from within the Inbox, then enter the social security number to finish the entry of the quote. After the workflow is finished, the Workflow Engine removes the interactive workflow from the Inbox.

An interactive workflow process that is suspended is placed in the Inbox in order to allow the owner of the workflow to track and explicitly resume the workflow.

Table 24 describes work that is performed when a workflow process is suspended.

Items to consider include:

■ To realize the behavior described in Table 24, the Auto Persist flag for the suspended workflow process must contain a check mark.

■ An interactive workflow process that is suspended in the Inbox is removed from the Inbox after the workflow finishes, then terminates.

Comparison of Suspension to Persistence of a Workflow ProcessThere is a difference between suspending a workflow process and persisting a workflow process. If a workflow is suspended, and if the Auto Persist flag for the workflow is set to TRUE, then the workflow can be persistent.

For example, with implicit suspension, if an end user leaves a view that the workflow process navigated the user to, then the instance of the workflow is saved in the in-memory cache. In this case, no Inbox item is generated. If the user logs out, and if the Auto Persist flag set to TRUE, then an Inbox item is generated in the cache for the workflow. Therefore, the Inbox item is visible only when the user logs out, then logs back in.

Table 24. Work That Is Performed When a Workflow Process Is Suspended

Suspension Description Result

Explicit suspension. The user clicks Suspend.

The workflow process is saved to the database and placed in the Inbox.

Implicit suspension. The user leaves a view that is part of the workflow process.

If the workflow process must be removed from the in-memory cache, then:

■ The workflow is placed in the Inbox

■ The workflow is saved to the database

Examples of when the workflow must be removed from the in-memory cache is when the cache is full, or when the end user logs out.



In-Memory Cache of an Interactive Workflow Process That Is SuspendedAn end user often navigates out of an interactive workflow process because the workflow is set up to address a specific business requirement. If the user navigates in this way, then the interactive workflow remains in memory so it can be resumed later in the same user session. As it is uncommon for a user to possess a large number of unfinished work items, there can be a maximum of eight instances of an interactive workflow that is suspended in the memory cache. This limit applies to an individual user session. The limit is eight instances total for interactive workflows that are initiated from within the user session, not eight instances for each interactive workflow. This eight instance limit is not configurable.

The user session is one connection on the Application Object Manager component, regardless of whether this thread is logged as a single user. If the eight instance limit is reached, then a new interactive workflow process is not prevented from running. Instead, if the user initiates another interactive workflow after eight instances are already cached in memory, and if this ninth instance must be saved to the cache, and if the AutoPersist flag for the workflow is set, then the oldest instance is either pushed into the database or it is dropped if the memory cache reaches the cache limit.

Event Handling with an Interactive Workflow Process That Is SuspendedSiebel Workflow handles events in the following sequence:

1 Checks the in-memory cache to determine if there are instances for a workflow process in the cache that can receive an event, using the matching criteria defined by the event.

2 Checks the database to determine if there are persistent instances for a workflow process that can receive an event.

3 Resumes instances found in Step 1 and Step 2.

Handling the User Logout Event for an Interactive Workflow Process That Is SuspendedUpon receiving the event for the user logout , the Workflow Engine proceeds through the interactive workflow processes that are suspended in the in-memory cache. Each workflow with the Auto Persist flag checked is saved as an Inbox item. Other workflows are deleted.

Options for a Long-Running Workflow ProcessThis topic includes the following topics:

■ Defining a Subprocess that Assigns a Long-Running Workflow Process on page 140

■ Defining a Long-Running Workflow Process to Assign a Siebel Task UI to an End User on page 140

A long-running workflow process is a persistent workflow that can last for hours, days, or months. An example of a long-running workflow is an approval process that sends an order to an external system, then waits for a response. For more information, see “About the Long-Running Workflow Process” on page 129.

NOTE: If building a long-running workflow process, then use a user event and not a run-time event to start the workflow process and to resume the instance of the workflow.



140

Defining a Subprocess that Assigns a Long-Running Workflow ProcessYou can define a workflow process that assigns an interactive subprocess to an end user of a collaborative workflow. An example of a collaborative workflow is one that includes a requirement for approvals. The path that the workflow pursues as it moves through the logic of the workflow is a path across multiple users who work in collaboration in order to finish the work that is required by the workflow.

You use the Recipients properties on a sub process step in order to define a collaborative workflow process. Assignment occurs based on the login name, not on the Position or User ID. This login name can be a literal value, it can be held in a process property or a field of a business component, or it can be the result of an expression.

NOTE: The Process Designer cannot validate the data that is supplied to make sure it represents a valid login name at design time.

To define a subprocess that assigns a long-running workflow process

1 Define a sub process step.

For more information, see “About the Sub Process Step” on page 73.

2 In the Recipients tab of the MVPW, set the Recipient Name field to the login name of the user who is assigned to the subprocess.

For more information, see “About the Process Property” on page 47, and “Fields of a Recipient Argument of a Process Property” on page 468.

Defining a Long-Running Workflow Process to Assign a Siebel Task UI to an End UserYou can use a long-running workflow process to assign a task UI to an end user, then generate an inbox item for the task UI and push it to the Inbox for the user. The user can then click the inbox item in order to create a new instance of the task UI and run it. For example, in an Expense Report Approval long-running workflow, after the employee submits an expense report, a new task UI named Review Expense Report is generated and assigned to the manager for the employee. Because this case is a one-to-one assignment, the assignment can be made simply by looking up the ID for the manager from the business component for the user. After the ID for the manager is retrieved, a new item is generated in the Inbox for the manager that references the Review Expense Report task UI.



To define a long-running workflow process to assign a task UI to an end user

1 In the long-running workflow process, at the point where the task UI must be called, determine the ID of the end user to whom the new task UI instance is to be assigned.

This logic is dependent on your business requirements, and it can be implemented as a Siebel operation if the ID is already present in a business component. The logic can also be implemented as a call to a business service.

If the assignment logic implies application of assignment rules, then a business service interface to Siebel Assignment Manager can be used. The input to the service is variable, depending on the context that is required for the assignment. The output, however, is simply the ID of the end user to whom the task UI is assigned.

2 Use the Owner Id input argument in order to define a task step that generates a new item in the Inbox for the user to which the task UI is assigned.

3 Add a task step to the workflow process.

If you add a task step to a workflow process, then the workflow generates a new instance of the task UI and assigns it to an end user. For more information, see “Defining a Task Step” on page 84.

Workflow PersistenceWorkflow persistence is a property of a workflow process that is used to store the state of an instance of a workflow and the steps and process properties for the workflow. Thus, supporting, within a single workflow, transactions that are long lived. By using workflow persistence to store the state of a workflow, you can build an end-to-end workflow that includes a wait step, sub process step, and other interruptions. Persistence also maintains the active state of a workflow over short or long periods of time, with activity occurring in various parts of your enterprise.

The state of the workflow process and process properties are saved in the S_WFA_INSTANCE and S_WFA_INST_PROP tables.

How Workflow Persistence Can be Used to Resume a Workflow ProcessWorkflow persistence allows resumption of a workflow process after a pause or a server failure. Workflow persistence saves and restores data when the workflow is resumed. If persistence is set to TRUE, then a user can continue a workflow that is suspended. The suspended workflow displays in the Inbox for the user. For example, with persistence set on an interactive workflow process, a user of the workflow can take a work break. If the workflow persistence parameter times out, then the workflow displays in the Inbox for the user and is ready for resumption when the user returns.

The workflow persistence setting applies to the long-running workflow process, interactive workflow process, and 7.0 workflow process. You cannot use workflow persistence with a service workflow. The persistence property uses a YES or NO setting. For a long-running workflow, persistence is automatically set by the server at execution time. For an interactive workflow, you set the persistence property by using the Auto Persist flag in the Workflow Processes OBLE in Siebel Tools.



142

How Workflow Persistence Functions with Different Workflow Process ModesBehavior for persistence includes:

■ A long-running workflow process is automatically persistent.

■ If the Auto Persist flag is set, then an interactive workflow process is persistent on suspension.

You control workflow persistence by setting the Auto Persist flag. If the Auto Persist flag is set to YES, and if a session times out or if an end user logs out of a Web session, then a workflow process is persistent and can be resumed from the Universal Inbox.

■ A 7.0 workflow process with persistence marked as Auto Persist and is persistent.

NOTE: In some releases earlier than Siebel CRM version 8.0, workflow persistence was used for monitoring a workflow process, and persistence was controlled by adjusting two settings that can apply to individual steps of a workflow: frequency and level. With version 8.0 and higher, process monitoring is separate from workflow persistence, and it is not necessary for persistence to be set for a long-running workflow because the long-running workflow is set by default. For a 7.0 workflow that had persistence set, the Auto Persist flag is automatically set to YES during upgrade and import.

A persistent workflow process is automatically purged after it finishes running.

Defining Persistence for a Workflow ProcessFor a long-running workflow process, persistence occurs by default. For an interactive workflow process, you set the Auto Persist flag in the Process Designer.

CAUTION: Defining Workflow Persistence for a large number of workflow processes can result in the creation of a large number of records in the S_WF_PROP_VAL table. For more information, see “Avoiding Excessive Records in the S_WF_PROP_VAL Table” on page 242.

To define persistence for a workflow process



2 In the Auto Persist property, choose YES by using the drop down picklist.

Options for Developing a Workflow Process ■ Starting a Workflow Process


Starting a Workflow ProcessThis topic describes different ways to start a workflow process. It includes the following topics:

■ Starting a Workflow Process from a Workflow Policy on page 143

■ Starting a Workflow Process from a Run-Time Event on page 144

■ Starting a Workflow Process from a Business Service on page 147

■ Starting a Workflow Process from Another Workflow Process on page 149

■ Starting a Workflow Process Through the Workflow Process Manager on page 150

■ Starting a Workflow Process Through the Application Object Manager on page 152

■ Starting a Workflow Process Through a Script on page 152

■ Example of Starting a Workflow Process from a Custom Toolbar on page 154

■ Other Techniques for Starting a Workflow Process on page 156

Starting a Workflow Process from a Workflow PolicyTo start a workflow process from a workflow policy, you define a workflow policy action that uses the Run Workflow Process workflow policy program. Alternatively, you can define a custom workflow policy program by copying Run Workflow Process, then adding program arguments that correspond to workflow process properties. This way, you can use the policy program to pass data to the workflow process properties. For more information, see Chapter 14, “Defining a Custom Workflow Policy.”

To start a workflow process from a workflow policy

1 In the Siebel client, navigate to the Administration-Business Process screen, then the Actions view.

2 In the Actions list, click New to define a new action.

3 In the Program field, use the picklist to choose the Run Workflow Process program.

4 In the Arguments list, click New to define a new Argument.

5 In the Argument field, choose ProcessName from the picklist.

6 In the Value property, enter the name of the workflow process you must start.

7 Navigate to the Administration-Business Process screen, then the Policy Groups view.

8 In the Policy Groups list, click New to define a new group, then name it.

9 Navigate to the Administration-Business Process screen, then the Policies view.

10 In the list for the Policies List, click New to define a new policy.

11 In the Conditions list, click New to define a workflow policy condition for the policy that must be met to start the workflow process.



144

12 In the Actions list, click New to define a new action, then enter the name of the action you defined in Step 2.

13 Run the Generate Triggers server component.

For more information, see “Overview of Generating Database Triggers” on page 403.

14 If you are using the Run Workflow Process program, then make sure the Workflow Process Manager server component is online.

15 Run Workflow Monitor Agent.

For more information, see “Executing a Workflow Policy with Workflow Monitor Agent” on page 417.

16 Violate the policy.

The violation starts the workflow process.

Starting a Workflow Process from a Run-Time EventThis topic describes how to use a run-time event to start a workflow process. For more information, see “Run-Time Event” on page 157.

How a Run-Time Event Starts a Workflow ProcessThis topic describes an overview of the process that the Siebel application uses in order to start a workflow process by using a run-time event. For this example, assume the PreWriteRecord event is used to start the workflow.

The steps that occur when a run-time event starts a workflow process include:

1 The PreWriteRecord run-time event is detected by components of the Application Object Manager.

2 Because the PreWriteRecord run-time event is defined on the connector that emanates out of the start step, the workflow process is started.

3 The object manager internally calls the Workflow Engine. At the time of the call, the business object that caused the run-time event is passed to the Workflow Engine.

4 The Workflow Engine uses the active rows on the business object for data operations.

5 If the rows are not already active, then the Workflow Engine sets up the rows, which is applicable for an object manager that generates run-time events.

Siebel Workflow runs with the local thread, and if SWE is present, then user interacts are allowed. The parameters used include:

■ Context, a CSV string that is internally registered by Siebel Workflow

■ The business component that causes the run-time event



Choosing Between a Run-Time Event and a Workflow PolicyIn cases where it is necessary to detect a database event, use a workflow policy, not a run-time event. For example, if using the UI, then use a run-time event in order to start a workflow process. If using the Siebel EAI Adapter or the EAI UI Data Adapter, which performs numerous WriteRecord events, then use a workflow policy. For more information, see “Starting a Workflow Process from a Workflow Policy” on page 143.

Comparison of Using a Run-Time Event to a Using a Workflow PolicyTable 25 describes two different requirements for using a run-time event compared to a workflow policy.

Defining a Button That Starts a Workflow ProcessYou can use Siebel Tools to define a button on an applet that calls the run-time event that starts a workflow process.

To define a button that starts a workflow process

1 From Siebel Tools, define a button on an applet and define the MethodInvoked property.


2 Override the PreCanInvokeMethod property.

3 Edit the server script and compile your changes.

Table 25. Examples of Requirements for Using a Run-Time Event Compared to a Workflow Policy

Requirement Recommended Technique

Set the priority to ASAP and send a notification email when a new service request is created.

Using a workflow policy is a more appropriate way to detect the database event.

Generate a text file with some information when a particular entry applet is viewed.

Using a run-time event is more appropriate. Define a workflow process with the InvokeMethod run-time event defined on the start step that detects when the Entry Applet is viewed. Use a business service step in this workflow process to generate the text file.



146

The following example is specific to Siebel VB:

Function WebApplet_PreCanInvokeMethod (MethodName As String, CanInvoke As String) As Integer

If MethodName = "<Name>" Then

CanInvoke = "True"

WebApplet_PreCanInvokeMethod = CancelOperation

Else

WebApplet_PreCanInvokeMethod = ContinueOperation

End If

End Function

4 Define a workflow process.

5 Choose a mechanism to start the workflow process.

To start this workflow process from a button click, you must define a run-time event on a connector. Choose from one of the following mechanisms to start the workflow:

■ To start this workflow process, define the run-time event on the connector that emanates from the start step.

■ To resume this workflow process if it is paused as the result of a button click, define the run-time event in a user interact step or a wait step.

6 Define the run-time event using values from the following table.

7 Activate the workflow process.

8 In the Siebel client, navigate to the Administration-Runtime Events screen, then the Events view.

Property Value

Event PreInvokeMethod

Event Cancel Flag True.

If this flag is not checked, then an error results when the workflow process is run.

Event Object Name of the business component on which the applet that contains the button is based.

Event Object Type BusComp

Sub Event Name of the method you set in step Step 1.

The Sub Event name must be unique.

Type (Required) Condition



9 Click Menu on the Events applet, then choose Reload Runtime Events.

order for the change to take effect, you must reload personalization after a workflow process is activated that registers a run-time event.

Avoiding the Cannot Resume Workflow Process ErrorIf all of the following situations exist, then an error occurs when a user clicks a button that starts a workflow process:

■ The workflow process is an interactive flow

■ The workflow process is started at least one time in the current user session

■ An event is fired and there is no instance of a workflow process that is waiting to handle the event

The event is discarded and the end user receives an error message.

To avoid the cannot resume workflow process error■ Require the end user to run a workflow process in order to access this view.

For example, you can define a workflow process that includes the user interact step. You can handle the error by defining an error exception connector or error process.

Identifying A Predefined Workflow Process That Is Started by a Run-Time EventFor your implementation, it is possible that some predefined workflow processes are started by a run-time event. You can use the Action Set Name field of the Runtime Events administration screen in the Siebel client to identify a predefined workflow process that is started by a run-time event.

To identify a predefined workflow process that is started by a run-time event

1 In the Siebel client, navigate to the Administration-Runtime Events screen, then the Events view.

2 Note the value of the row ID in the Action Set Name field.

For example, if Workflow_1-2APXH is displayed in the Action Set Name field, then 1-2APXH is the row ID of the workflow process that is referenced.

3 Navigate to the Administration-Business Process screen, then the Workflow Processes view.

4 Query the Name field for the row ID of the workflow process you noted in Step 2.

For example, [Id]='1-2APXH'.

The query returns the record for the workflow process.

Starting a Workflow Process from a Business ServiceYou can start a workflow process from a business service. Items to consider include:



148

■ With a business service, such as Workflow Process Manager (Server Request), it is not necessary for you to define parameters for the Server Request Broker (SRBroker).

■ If you call the server requests directly, then you must define parameters for the Server Request Broker.

■ Server Request Broker and Server Request Processor (SRProc) are required in order to run a business service that calls a server component.

■ To use Workflow Process Manager (Server Request), Server Request Processor and Server Request Broker must be running.

For more information, see Siebel System Administration Guide. For more information on calling a business service, see Siebel Object Interfaces Reference.

To start a workflow process from a business service

1 In Siebel Tools, in the Object Explorer, click Business Service.

2 In the Business Services OBLE, add a new business service using values from the following table.

3 In the Object Explorer, expand the Business Service tree, then click Business Service User Prop.

4 In the Business Service User Props OBLE, add two new objects using values from the following table.

5 (Optional) Enter more user properties pertaining to Server Request Broker.

For more information, see “Server Request Broker” on page 36.

6 In the Object Explorer, click Business Service Method.

7 In the Business Service Methods OBLE, add a new object using values from the following table.

Property Value

Name (This is the name that you can reference in scripting.)

Class CSSSrmService

Display Name (This is the name that you see in workflow views.)

Property Value

Component (Short name of the server component. For example, WfProcMgr.)

Mode (Mode of the server request. For example, Async.)

Property Value

Name (This is the name that you can reference in scripting.)

Display Name (This is the name that you see in workflow views.)



8 In the Object Explorer, expand the Business Service Method tree, then click Business Service Method Arg.

9 In the Business Service Method Arguments OBLE, add records that are specific to the component that is called.

For example, ProcessName for WfProcMgr. The name is the short name of the server component parameter.

Starting a Workflow Process from Another Workflow ProcessYou can define a workflow process so that it asynchronously starts another workflow directly. You start a workflow, which calls a custom business service, which in turn starts the second workflow by using the Asynchronous Server Requests business service.

To start a workflow process from another workflow process

1 In Siebel Tools, in the Process Designer, add a business service step to your workflow process.

2 Make sure the new business service step is chosen.

3 Use the properties window to set values described in the following table.

4 In the MVPW, click the Input Arguments tab, then add three new input arguments using values from the following table.


5 To set component parameters, such as Workflow Process Name, define the Input Argument Name as [ComponentAlias].[Business Service Method Arg Name].

If the workflow process is executed in the Process Simulator, then a request is inserted into the S_SRM_REQUEST table and a Workflow Process Manager task is started on the server.

Property Value

Business Service Asynchronous Server Requests

Method SubmitRequest

Input Argument Type Value Property Name

Component Literal WfProcMgr (leave empty)

WfProcMgr.ProcessName Literal AG Simple Test (leave empty)

WfProcMgr.RowId Process Property (leave empty) Siebel Operation Object Id



150

Starting a Workflow Process Through the Workflow Process ManagerA workflow process can be run within the Workflow Process Manager server component. The ways in which a workflow process can be started on the server include:

■ From a workflow policy that executes on the server. For more information, see “Starting a Workflow Process from a Workflow Policy” on page 143.

■ From a script that specifies the Server Request parameter. For more information, see “Starting a Workflow Process Through a Script” on page 152.

■ From a run-time event with the Processing Mode property set to Remote Synchronous or Remote Asynchronous. For more information, see “Starting a Workflow Process from a Run-Time Event” on page 144.

If you compiled a custom SRF file by using Siebel Tools, then this file must be added to the Objects directory on the Siebel Server. In addition, you must update the siebel.cfg file that is referenced in the Server parameters in order to reflect the custom SRF file. The siebel.cfg file is the default configuration file for Workflow Process Manager server components.


■ A workflow process that is started from a script is performed in synchronous mode.

■ A business service that calls a UI element, including navigation functionality, such as the user interact step, is not supported when the workflow process runs on the server.

For more information, see “Workflow Process Manager” on page 32.

Remote Synchronous ProcessingIf an end user starts a workflow process that runs on the server within the Workflow Process Manager server component, then the workflow executes only if the user is connected to the server. If the user is not connected to the server, then the request is queued and executes when the user synchronizes or when the server is available. For more information, see “Server Requests Business Service” on page 482.

Key Based Routing with Workflow Process ManagerA server key map is a map that defines the rule groups that load and process for each server. You can configure a server to load multiple rule groups. If you define a server key map, then you are dividing the rules among the different servers. A server key map is defined in the Server Key Map view in the Assignment Administration screen.

You submit an assignment request by defining the AsgnKey parameter, where the AsgnKey parameter is the row ID of the assignment rule group that is associated with the rules you must evaluate. If using AsgnSrvr, then the AsgnKey parameter must be the row ID of one of the rule groups that is defined for the server in the Server Key Mappings view. The Assignment Server (AsgnSrvr) first looks for entries in the server key map for a specific server, then loads rules for only those rule groups that are associated with that server key map. Assignment Manager uses key based routing in order to route the request to a particular instance of Assignment Manager where the rules are loaded for that rule group.



You can define multiple servers to load the same rule group. Assignment Manager routes requests to one of the servers where that rule group is based on load balancing metrics

Environments in which the server key mapping feature is supported include:

■ Where there is an interactive and dynamic assignment

■ Where a script or workflow process calls a business service

Reasons for using Key Based Enabled include:

■ Routing. You can setup the RequestKey parameter on the Workflow Process Manager so that when Siebel Workflow comes up, it registers this key. This way, you can control the routing of Workflow Process Manager requests.

■ Recovery. To target the ping messages, each Workflow Process Manager registers a unique key. The recovery manager uses these keys to keep track of which Workflow Process Manager is alive and what Workflow Process Manager is processing.

In general, if Recovery Manager is activated, then the Key Based Enabled parameter for Workflow Process Manager must be set to true.

For more information on key based routing, see Siebel Assignment Manager Administration Guide.

Workflow Process Manager and Automatic Record InsertionIf the Workflow Process Manager inserts a record, then, by default, the system generated CREATED_BY field is set to 0-1, which is the ROW_ID for employee SADMIN. In some cases, it can be desirable to set the CREATED_BY field to a value other than the Id for SADMIN.

For example, assume a workflow process inserts an activity when an end user performs an action in the Siebel client. Because this workflow is started by the Asynchronous Server Requests business service, the workflow is executed by the Workflow Process Manager on the server, and CREATED_BY is set to SADMIN, although the business requirement is to set CREATED_BY to the user who caused the workflow to start.

In this situation, work you can perform includes:

■ Instead of starting the workflow process on the server by using Workflow Process Manager, start the workflow so that it runs locally. As a result, the session for the end user creates the record and CREATED_BY is set to the Id for the user. In this case, the workflow is executed synchronously.

■ If the requirement is to record which end user caused a record to be inserted, then you can pass the Login Id or Login Name of the user to the workflow process on the server, then write it to an extension field in the business component. You can obtain the Login Id or Login Name for the user in a script by using the standard LoginId () or LoginName () functions. For information about how to pass data to a custom process property of a workflow when a server request is submitted, see “Server Requests Business Service” on page 482.



152

Starting a Workflow Process Through the Application Object ManagerRunning a workflow process in the Application Object Manager can be useful for enforcing a business process with a mobile user or for defining a business process that involves navigation by the end user.

To start a workflow process that runs in the application object manager■ Start the workflow process in one of the following ways:

■ From the Process Simulator

■ From a script that is defined to run locally in the application object manager

■ From a run-time event with the Processing Mode defined as local synchronous

Starting a Workflow Process Through a ScriptA workflow process can be started from a script by using Siebel VB or Siebel eScript. By using a script, a workflow can be started from most locations in the Siebel application or from an external program. If a workflow is started from a script, then you can define the workflow to run on the server or in the object manager. A workflow that is started from a script is executed in Synchronous mode.

To run a workflow process on the server■ Call the Workflow Process Manager (Server Request) service.

To run a workflow process in the application object manager■ Call the Workflow Process Manager service.

Example of Starting a Workflow Process from a Script in the Object ManagerThis topic gives one example of starting a workflow process from a script in the object manager. You might use this feature differently, depending on your business model.



The following is an example of a script that starts a workflow process named My Account Process. In this example, the process is started in the object manager.

/ Example: Starting a Workflow Process through scriptingfunction Invoke_Process(){var svc = TheApplication().GetService("Workflow Process Manager");var Input = TheApplication().NewPropertySet();var Output = TheApplication().NewPropertySet();var bo = TheApplication().ActiveBusObject();var bc = bo.GetBusComp("Account");var rowId = bc.GetFieldValue("Id");

Input.SetProperty("ProcessName", "My Account Process");Input.SetProperty("Object Id", rowId);

svc.InvokeMethod("RunProcess", Input, Output);}

Example of Starting a Workflow Process from a Script to Pass Field Values to Process PropertiesThis topic gives one example of starting a workflow process from a script in order to pass field values to process properties. You might use this feature differently, depending on your business model.

The following script starts a workflow process that is named My Opportunity Process. In this example, the workflow process is started in the object manager. Field values are passed to process properties that are defined in the workflow.

//Example: Passing Field Values to Process Propertiesfunction Invoke_Process(){

var svc = TheApplication().GetService("Workflow Process Manager");var Input = TheApplication().NewPropertySet();var Output = TheApplication().NewPropertySet();var bo = TheApplication().ActiveBusObject();var bc = bo.GetBusComp("Opportunity");

var rowId = bc.GetFieldValue("Id");var accountId = bc.GetFieldValue("Account Id");

Input.SetProperty("ProcessName", "My Opportunity Process");Input.SetProperty("Object Id", rowId);

// Pass the value of the Account Id field to the Account Id process propertyInput.SetProperty("Account Id", accountId);

svc.InvokeMethod("RunProcess", Input, Output);



154

Starting a Workflow Process from a Script by Using the Server Requests Business ServiceYou can asynchronously start a workflow process from a script by using the Server Requests business service. For more information, see “Example of Using the Server Requests Business Service to Start a Workflow Process from a Script” on page 305.

Example of Starting a Workflow Process from a Custom ToolbarThis topic gives one example of starting a workflow process from a custom toolbar. You might use this feature differently, depending on your business model.

To start a workflow process from a custom toolbar

1 In Siebel Tools, navigate to the Business Services OBLE, then define a new business service using values from the following table.

2 Navigate to the Commands OBLE, then define a new command using values from the following table.

If necessary, expose the Command object in the Object Explorer. For more information, see “Exposing Object Types That Are Used to Develop a Workflow Process” on page 116.

3 In the Object Explorer, click Toolbar, then query the Name property in the Toolbars OBLE for HIMain.

If necessary, expose the Toolbars object. For more information, see “Exposing Object Types That Are Used to Develop a Workflow Process” on page 116.

4 In the Object Explorer, expand the Toolbar tree, then click Toolbar Item.

Property Value

Name TestTBItem

Server Enabled TRUE

Property Value

Name TestTBItem

Business Service TestTBItem

Method TestTBItem

Target Server



5 In the Toolbar Items OBLE, add a new record using values from the following table.

6 In the Siebel client, define a workflow process and make sure it can be run successfully from the process simulator.

For more information, see “Preparing to Use the Process Simulator” on page 203.

7 Add the following server script to the business service that you defined in Step 1.

NOTE: The name of the workflow process that you used in Step 6 must be used in the script.

function Service_PreCanInvokeMethod (MethodName, &CanInvoke)

{

if ( MethodName == "TestTBItem" )

{

CanInvoke = "TRUE";

return( CancelOperation );

}


}

function Service_PreInvokeMethod (MethodName, Inputs, Outputs)

{

if ( MethodName == "TestTBItem" )

{

var input = TheApplication().NewPropertySet();

var output = TheApplication().NewPropertySet();

var svc = TheApplication().GetService( "Workflow Process Manager" );

Property Value

Name TestTBItem

Command TestTBItem

DisplayName TestTB Item

Type Button

HTML Type Button

Position 20



156

input.SetProperty("ProcessName", "<WF Process Name Created in Step 4>");

svc.InvokeMethod("RunProcess", input, output);

input = null;

output = null;

svc = null;


}


}

8 Compile the changes, then log in to the Siebel client.

Your new custom button displays in the custom toolbar. If you click it, then the corresponding workflow process is started.

Other Techniques for Starting a Workflow ProcessInformation sources for other techniques that can be used to start a workflow process include:

■ For starting from a synthetic event, see “About the Synthetic Event” on page 131

■ For starting from a user event, see “About the User Event” on page 161

■ For starting from the Process Simulator, see “About the Testing Tools” on page 197

■ For starting from a server component, see Overview: Siebel Enterprise Application Integration and Siebel eMail Response Administration Guide

You can use these techniques in order to test a workflow process in your test environment before you deploy it to the production environment. When testing, being able to start a workflow from a workflow policy is important because it tests starting a workflow on the server. You can also use these techniques to start a workflow in your production environment.

Business Integration ManagerIt is recommended that you do not use Business Integration Manager or Business Integration Batch Manager:

■ If you are using Business Integration Manager, then you must replace it with Workflow Process Manager

■ If you are using Business Integration Batch Manager, then you must replace it with Workflow Process Batch Manager

Options for Developing a Workflow Process ■ About Events


About EventsThis topic describes run-time events and user events that can be used with a workflow process. It includes the following topics:

■ Run-Time Event on page 157

■ About the User Event on page 161

Run-Time EventA workflow process can integrate with the run-time events engine in order to provide a simplified way to automate a business process. Benefits provided by this technique include:

■ Allows real time monitoring of events

■ Minimizes scripting and calling for a workflow policy

The types of events that can be used include:

■ Application

■ Business Component

■ Applet

A run-time event allows the Siebel application to respond in real time to an interaction that is initiated by an end user. A run-time event can be defined on a connector that emanates from a start, wait, or user interact step in order to start or resume a workflow process. The properties of the WF Step Branch that are used to define a run-time event include:

■ Event Object Type

■ Event Object

■ Event

■ Sub Event

■ Event Cancel Flag

For more information, see “Starting a Workflow Process” on page 143, and Siebel Personalization Administration Guide.

Run-Time Event Usage with a Long-Running Workflow ProcessNOTE: It is recommended that a run-time event not be used to start a long-running workflow process because a run-time event is specifically attached to a single user and a single session.

A run-time event is only for a single, distinct end user because it originates from Personalization functionality. Instead, use an interactive workflow or a service workflow to handle the run-time event. Then, after processing and validating the workflow, generate a user event in order to notify a long-running workflow.



158

Run-Time Event Usage with the User Interact StepEvents not supported with the user interact step include:

■ The DisplayRecord event

■ The DisplayApplet event

■ The Login event. Use the WebSessionStart event instead

The event supported with the user interact step includes:

■ The SetFieldValue event for a field with the Immediate Post Changes property set to TRUE.

Immediate Post Changes is a property on a business component field that causes an immediate roundtrip to the server if a change is made to the field, which results in an immediate calculation of the field or a refresh of the view. If Immediate Post Changes is set to True, then the PreSetFieldValue event in the browser script is bypassed. For more information, see Configuring Siebel Business Applications.

Run-Time Event Usage within a Business Object ContextA workflow process that references a run-time event is only started when the run-time event is detected from within the same Business Object context in which the workflow process is based. For example, assume a workflow process is started by the WriteRecord run-time event and the Business Object property for the workflow is set to Service Request. To update the record, the user clicks the Service Requests List screen tab, updates the Status field, then steps off the record. In this case, the record is written in the context of the Service Request business object, and the run-time event that is defined on the workflow fires.

However, if the Status field is updated within a non service request business object context, then the run-time event does not fire. For example, assume the user drills down on a Contact, clicks the Service Requests view tab, updates the Status field, then steps off the record. In this case, the service request record is written in the context of the Contact Business Object, and the run-time event does not fire.

Defining a Run-Time Event within a Many to One RelationshipIf defining a run-time event to start a workflow process based on a modification made to a record that contains a many to one relationship with a parent, then you must start the workflow based on the ROW_ID for the child. For example, assume you must start a workflow process when a field in the activity for a service request is updated. Because a service request can contain one or many activities, you must start the workflow based on the ROW_ID for the activity, not the service request. If you start the workflow based on the ROW_ID of the service request, then a change that is made in the form applet for the service request starts the workflow, but a change made in the activities list applet does not.

To examine a one to many relationship

1 In the Siebel client, navigate to the Service Request screen, then the Service Request List view.

2 Create a new service request.



3 Drill down by clicking the SR# field.

4 Use the Activities list to create two new activities.

5 In the Activities list view, the top service request form displays fields for the parent service request, while the bottom activities list displays multiple activities for the parent.

To define a run-time event within a many to one relationship

1 In Siebel Tools, in the Workflow Processes OBLE, define a new workflow process using values in the following table.

The workflow process is based on the Service Request business object. The run-time event that is used in this workflow occurs on the start step and is based on the Action business component, which is a child of the Service Request business object. The wait step, used in this workflow for testing purposes, requires an Interactive Flow. For more information, see “About the Wait Step” on page 87. For an example, see “Defining the New Workflow Process” on page 256.

2 Open the Process Designer for the workflow process you defined in Step 1, then define a workflow that resembles the workflow in the following figure.


3 Click the Id Triggered connector, then use the Properties window to define values described in the following table.


Property Value

Process Name Update Service Request

Business Object Service Request


Property Value


Event WriteRecord

Event Object Action



160

5 In the MVPW, right-click, then add a new process property using values from the following table.


To capture the ROW_ID of the activity, you define a process property, then use a wait step which can read a field from the child business component into the process property in the output argument for the wait step without modifying the underlying data.

6 Click the Get Activity Id step, then click the Output Arguments tab in the MVPW.


For testing purposes, this step reads the ROW_ID of the activity, which is the Id field, into the ActionBCRowId% process property. No input arguments are defined for the wait step.



9 Implement this technique in your production workflow.

This example demonstrates how you can start a workflow process based on changes made to a child in a many to one relationship. It includes steps to test the technique. In a production environment, if it is not necessary to capture the ROW_ID of the child, then you can simply define the trigger of the run-time event on the connector that emanates from the start step, as described in Step 3.

Run-Time Event Usage with the Updated By FieldIf a step in a workflow process contains a run-time event with a processing mode that is defined to run locally to either start or resume a workflow, then the value in the Updated By field describes the end user who is currently logged into the application.

Field Value

Name ActionBCRowId%

In/Out In/Out


Field Value

Property Name ActionBCRowId%

Type Expression

Value Id

Business Component Name Action



Run-Time Events That Cannot Be Used to Start a Workflow ProcessBecause a workflow process can be started only within the context of a record for a business component, if there is no business component record context, then it is not possible to start the workflow, and attempting to start the workflow using the BusComp Query event fails. Therefore, a run-time event with the possibility of returning no results cannot be used to start a workflow.

Repeat Usage of a Run-time EventYou cannot use the same run-time event more than one time within a given workflow process.

About the User EventWhile a run-time event acts on a workflow process from within the application object manager, a user event is internal to the workflow. A user event initiates and resumes a long-running workflow process in the Workflow Process Manager (WFProcMgr) server component.

NOTE: A user event can be used only in a long-running workflow process. A long-running workflow resumes on Workflow Process Manager. The behavior cannot be modified in order to cause a long-running workflow to resume on a custom workflow server component.

While a run-time event can be used in a workflow process that runs within a single user session, a user event is for use in a long-running workflow that spans multiple users. A user event can be used to start a workflow when the user event is attached to a start step, or to resume an instance of workflow that is waiting when the user event is attached to a step that can receive an input argument. A user event can also bring data into the instance of a workflow which can contain user data. This data comes in the form of the payload for the user event.

User Event Generation with the Workflow User Event Service Business ServiceA user event requires use of the Workflow User Event Service business service in order to communicate with the Workflow Process Manager. A user event is an event that is internal to Siebel Workflow which is used to resume a long-running workflow process from the Workflow Process Manager. To generate a user event, you call the Workflow User Event Service business service.

NOTE: A long-running workflow process must use only a user event, and not a run-time event.

The Workflow User Event Service business service is a standard Siebel business service that can be used wherever a Siebel business service can be used. You call the Workflow User Event Service business service by defining a business service step that calls it.

The User Event business service can be called by supported techniques, such as scripting, COM interfaces, and Java interfaces, which is the recommended way to communicate externally with a workflow process.



162

A typical example occurs when a 7.0 workflow, an interactive workflow, or a service workflow initiates a user event. A business service step calls the Workflow User Event Service business service to communicate to a long-running workflow that is running in the background.

NOTE: While most types of workflow processes or business services can generate a user event, it is recommended that only a long-running workflow process be defined to receive a user event.

For more information, see “Workflow User Event Service Business Service” on page 486.

Starting the Workflow User Event Service Business ServiceThis topic describes how to call the Workflow User Event Service business service in order to generate a user event.

To call the Workflow User Event Service business service

1 Add a business service step to a workflow process,

2 Click the business service step you added in Step 1, then use the Properties window to define values described in the following table.

3 In the MVPW, define a new input argument for the step.


4 In the Input Argument field, choose Payload from the picklist, then define the other fields, as appropriate.

5 Repeat Step 3 and Step 4, choosing Correlator Value from the picklist.

6 Repeat Step 3 and Step 4 again, choosing User Event Name from the picklist.

Defining a Long-Running Workflow Process to Wait for a User EventIf using a user event in your workflow process, then keep in mind that only a long-running workflow process can wait for a user event. Other types of workflows cannot wait for a user event, though they can generate a user event. A long-running workflow must be defined with a user event only, not a run-time event.

To define a long-running workflow process to wait for a user event

1 Open the Process Designer for the workflow process in which you must define a user event.

2 In the MVPW, establish one of the process properties for the workflow process as the correlator by setting the Correlator Flag for the property to TRUE.


Property Value

Business Service Name Workflow User Event Service

Business Service Method GenerateEvent



3 On the branch of the step that handles the event, such as a start step or a wait step, use the Properties window to define values described in the following table.

NOTE: A user event is not queued. If no recipient is waiting to accept the user event with the defined correlator, then the event is discarded.

Property Value

Type Condition

If Type is set to Default rather than to Condition, then the user event is never called.

User Event Name (The name of the workflow you defined for the Value property in Step 6 on page 162.)

User Event Timeout (The timeout period for the user event.)

User Event Timeout works in a way that is similar to the timeout setting for a run-time event. If no user event is received during the timeout period, then the workflow process is resumed after the timeout period.

User Event Storage (The name of the process property that holds the payload that is passed in from the user event.)


Options for Developing a Workflow Process ■ Handling Errors

164

Handling ErrorsThis topic includes the following topics:

■ Using an Error Exception Connector to Handle Errors on page 164

■ Using a Stop Step to Handle Errors on page 168

■ Error Handling with an Error-Workflow Process on page 168

■ Recovery for a Workflow Process That Has Failed on page 171

An error is a deviation from the normal or expected flow of a workflow process. An error can be generated by the system or by an end user. You can use error handling to notify the end user of an error and terminate the instance of a workflow.

For information about using a process property when handling errors, see “Passing a Process Property to an Error-Workflow Process” on page 58.

Using an Error Exception Connector to Handle ErrorsAn error exception connector is a type of connector that is designed to handle system and user generated errors. An example of an error that is generated by the system is a failure that occurs when an email notification is sent. An example of an error that is generated by an end user is an attempt to submit an order that is not complete.

You can use an error exception connector to programmatically handle errors and change the flow that is pursued in a workflow process, depending on whether an error is encountered. This technique provides a granular approach to handling an exception at each step.

If an error occurs, then the error code and error message are automatically populated in the Error Code and Error Message process properties. An error exception connector allows you to set up a decision condition by using values in these properties.

In the Process Designer, an error exception connector is displayed as a red connector between two steps. If you click an error exception connector, then the Properties window displays the WF Step Branch properties for the connector.

Similar to other cases where a decision condition is used in a workflow process, exception logic for a step is evaluated after the step finishes. If you must evaluate an exception before execution of a step, then you must attach the error exception connector to the prior step in the workflow.

Example of Error Exception HandlingThis topic gives one example of defining error exception handling. You might use this feature differently, depending on your business model.



In the example displayed in Figure 18, If the Get Organization ID step is unable to get data, then the workflow process continues to the Lookup Sender by Org step. If Lookup Sender by Org fails, then the workflow pursues the red exception connector, and sends an email by using the Send Lookup Error Email step.

Defining an Error Exception ConnectorAn error exception connector is defined in the Process Designer.

To define an error exception connector




3 In the Process Designer, drag, then drop an error exception connector from the palette to the canvas, attaching one end of the connector to an existing step for which you must trap errors.

Some example step types where you might trap for an error decision condition includes the business service step and the Siebel operation step.

Figure 18. Example of a Workflow That Uses Error Exception Connectors to Programmatically Handle Exceptions



166

4 Make sure that the end of the connector is attached to the step.

5 Drag, then drop a stop step from the palette to the canvas.

6 Attach the unconnected end of the error exception connector to the stop step.

7 Make sure the error exception connector is chosen in the Process Designer.

8 Enter a value in the Name property in the Properties window.

9 In the Type property, choose Error Exception or User Defined Exception.

10 In the Process Designer, double click the error exception connector to access the Compose Condition Criteria dialog box.

11 Define decision conditions that apply for the exception.


Defining an Error Exception Connector to Handle an Update ConflictYou can define an error exception connector to handle an update conflict that occurs when multiple attempts are made to write to the same record at the same time. If the Workflow Monitor Agent (WMA) is used to start a workflow process, which in turn updates a record, then the WMA can fail if a workflow attempts to update a record that is updated by another user or by a WMA task since it was initially retrieved by the workflow. In this case, an error message, such as The selected record has been modified by another user since it was retrieved, is displayed. To prevent the WMA task from failing, you can define an error exception connector to handle an update conflict that occurs while the workflow is running.

To define an error exception connector to handle an update conflict



Property Value

Process Name Error Exception Example


Business Object Opportunity



2 Add steps and connectors until your workflow process resembles the workflow illustrated in the following figure.


3 Click the Update Opportunity business service step, then use the Properties window to define properties described in the following table.

4 Make sure the Update Opportunity business service step is still chosen in the Process Designer.

5 Define an input argument in the MVPW using values from the following table.


Property Value

Business Service Name ABC Update Opty

Business Service Method Update Opty

Field Value

Input Argument Opportunity Id

Type Process Property

Property Name Object Id

Property Data Type String



168

6 Define a decision condition on the error exception connector named Interim Write Error using values from the following table.

0x8137 -- 0x6f74 is the error code that is returned with the following error message:

The selected record has been modified by another user since it was retrieved


7 Define the Update Opportunity Again business service step, using the same values you used in Step 3 and Step 4. For the Name property, use Update Opportunity Again.



9 Implement this technique in your production workflow process.

The Update Opportunity Again step provides a way to write to the opportunity again in the case where the first attempt to update the opportunity fails due to the update conflict error. This example uses a business service step that updates opportunities. The same technique can be used with other step types that update a record, such as a Siebel operation or a sub process step, and with other types of records, such as accounts or contacts.

Using a Stop Step to Handle ErrorsA stop step is used to display a particular error message while processing. Example usage includes 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, see “About the Stop Step” on page 88.

Error Handling with an Error-Workflow ProcessYou can use an error-workflow process to handle errors. An error-workflow process is a standard workflow that becomes an error workflow when you associate it to another, main workflow. The association is established by defining the Error Process Name property in the Workflow Processes OBLE for the main workflow. If an error occurs in the main workflow, then the error exception connector calls the error workflow.

Property Value

Compare to Process Property

Operation One Must Match (Ignore Case)

Object Error Code

Values 0x8137 -- 0x6f74



The workflow process that is defined in the Error Process Name property is called when the main workflow reaches an error state. Execution of the main workflow stops, the main workflow passes system defined process properties to the error workflow, then the error workflow commences.

Restrictions when using an error-workflow process include:

■ An error-workflow process does not return values back to the originating workflow that failed. If you require that the state of the main workflow be changed by the error handling actions, then use an error exception connector.

■ An error-workflow process can be associated with a workflow that is a subprocess. However, an error workflow cannot itself contain a subprocess.

Benefits of Using an Error-Workflow ProcessA universal exception handler is an error-workflow process that is used when you must handle errors across multiple steps in a workflow or across multiple workflows. This type of exception handling can be used to reduce clutter in the workflow diagram, and to reduce the requirement to define a large number of error workflows by reusing a single or a small set of error workflows.

How Errors Are HandledThis topic describes how error handling varies for a workflow process and how errors are handled for a subprocess.

How Errors Are Handled for a Workflow ProcessIf an error is encountered in a workflow process that does not contain an error workflow that is defined in the Error Process Name property, then the workflow remains in the In Error state. The original error code is returned to the caller of the workflow.



170

If the main workflow process encounters an error and there is an error workflow defined for the main workflow process in the Error Process Name property, then the error workflow finishes with one of the outcomes described in Table 26.

Table 26. Error Handling When an Error-Workflow Process Is Defined for a Workflow Process

SituationError Process State Error Code Result

The error-workflow process handles the error successfully.

Completed No error code is returned to the caller of the workflow process.

If the error-workflow process arrives at an end step, then error handling is considered successful.

The error-workflow process terminates immediately with a Completed state.

The error-workflow process tries to handle the error, but fails with a different error.

Error A new error code, which you defined in the stop step, is returned to the caller of the error-workflow process.

If the error-workflow process arrives at a stop step, then error handling is considered failed.

The workflow process remains in the In Error state.

The error-workflow process cannot handle the error.

Error The original error code is returned to the caller of the workflow process.

If no start decision conditions are satisfied, then the error-workflow process ends immediately.

The workflow process remains in the In Error state.



How Errors Are Handled for a SubprocessIf a subprocess encounters an error, and if there is an error-workflow process defined for the subprocess in the Error Process Name property, then the error-workflow process finishes with one of the outcomes described in Table 27.

Recovery for a Workflow Process That Has FailedFor information about how to define recovery for a failed workflow process, see “About the Workflow Recovery Manager” on page 246.

Table 27. Error Handling When an Error-Workflow Process Is Defined for a Subprocess

SituationError Process State Error Code Result

The error-workflow process handles the error successfully.

Completed Not applicable If the error-workflow process arrives at an end step, then error handling is considered successful.

The subprocess also terminates with a Completed state, then control returns to the main workflow process.

The main workflow process continues to execute from the next step.

The error-workflow process tries to handle the error, but fails with a different error.

In Error The new error code, which you defined in the stop step, is returned to the subprocess.

If the error-workflow process arrives at a stop step, then error handling is considered failed.

Both the error-workflow process and the main workflow terminate with the In Error state.


Options for Developing a Workflow Process ■ Using Batch Processing

172

Using Batch ProcessingA workflow process can be run in batch by running the Workflow Process Batch Manager (WfProcBatchMgr) server component. Executing a workflow in batch allows you to execute the actions in a workflow for multiple records. If using the Workflow Process Batch Manager, then be sure to define the business object with which the workflow process is associated. You must also use a search specification in order to locate the business component records that are referenced or manipulated.

NOTE: It is recommended that only a service workflow process or a 7.0 workflow process be run in batch mode.

Table 28 describes parameters for the Workflow Process Batch Manager.

For more information on running a workflow process in batch, see Siebel System Administration Guide.

Issuing a Component Request to Schedule a Batch WorkflowYou can set up a batch to run a workflow process at a defined interval. For example, a workflow that runs at 7 A.M. every Monday. A component request is issued in order to schedule a batch workflow.

To issue a component request to schedule a batch workflow

1 In the Siebel client, navigate to the Administration-Server Configuration screen, Enterprises, then the Component Definitions view.

2 In the Component Request form, click New.

3 In the Component/Job field, click the selection button.

The Component/Jobs dialog box displays.

4 Choose Workflow Process Batch Manager.

5 In the Component Request Parameters form, click New.

6 In the Name field, click the selection button, then choose Workflow Process Name from the dialog box.

Table 28. Parameters of the Workflow Process Batch Manager

Display Name Description

Workflow Process Name Required. Name of the workflow process to execute.

Search Specification Search specification that identifies the work items to process.

The Search Specification parameter is a generic parameter that is shared by Workflow Management server components. However, this parameter is only used by the Workflow Process Batch Manager component. A Search Specification parameter that is defined for a component other than Workflow Process Batch Manager is not used.



7 In the Value field, type in the name of the workflow process to execute.

8 Click New to add another parameter.

9 In the Name field, click the selection button.

10 Choose Search Specification.

11 In the Value field, provide a search specification.

Usage of the Repeating Component RequestYou can use the Repeating Component Request feature in conjunction with the workflow process to schedule the workflow component to be executed at a predetermined time. For an example workflow that benefits from a repeating component request, see “Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete” on page 264. For more information, see Siebel Server Administration Guide.

Usage of the Search Specification ParameterYou can define a search specification to limit the number of records that are evaluated when a workflow process is run in batch. If you do not define a search specification, then the Workflow Process Batch Manager executes the workflow for each record of a particular type in the Siebel application. For example, if there are 100 SRs, then the Workflow Process Batch Manager executes the workflow 100 times, one time against each SR.

The Search Specification parameter on the Workflow Process Batch Manager is used to execute the search specification on the primary business component of the business object that is defined in the Business Object property of the workflow process. For each fetched record, the Workflow Process Batch Manager starts the workflow and sets the Object Id process property as the current active row.

Usage of the Workflow Process Batch Manager with Primary and Nonprimary Business ComponentsIf running Workflow Process Batch Manager, and if the Link Specification property is set to TRUE on a field of the primary business component, then the number of records returned can be more than expected. This situation can affect performance, which is due to the fact that the value for the field is passed as a default value to a field in the nonprimary business component through a link.

This situation occurs when the primary business component contains a link relationship with one or more nonprimary business components, as established through a Link on the current business object. Therefore, it is important to be careful when the business component is accessed by querying records in a custom business service or when running Workflow Process Batch Manager.



174

Comparison of Workflow Process Batch Manager to Workflow Process ManagerUse the Workflow Process Batch Manager server component when you must run the workflow process for every record of a particular business component. Workflow Process Batch Manager considers the primary business component that is associated with the business object property on the workflow. Workflow Process Batch Manager then runs the workflow on every record within that primary business component.

Considerations When Using a Custom Business ServiceThe situation can change when the workflow process involves a custom business service. For example, assume the custom business service contains a loop that processes every record and executes the business service code on each record that is returned from the code itself. Table 29 compares how the two process managers compare in this situation.

Table 29. Comparison of Using Workflow Process Manager to Workflow Process Batch Manager

Manager Used Description

Workflow Process Manager The business service, and the loop, handle every record at one time. This technique is the recommended way to execute this business service and workflow process.

Workflow Process Batch Manager

Because the business service for the workflow process already contains a loop, using Workflow Process Batch Manager causes the business service loop to execute for every record in the primary business component. This situation leads to undesirable duplicate and repeated execution.

Options for Developing a Workflow Process ■ Defining a Workflow Process for aMultilingual Environment


Defining a Workflow Process for a Multilingual EnvironmentThis topic describes how to define a workflow process to function correctly in a multilingual environment. It includes the following topics:

■ Defining a Workflow Process to Function in a Multilingual Environment on page 175

■ Expressions in a Multilingual Environment on page 176

■ Wait Step and Global Time Calculations on page 176

■ Local Code Parameter and Data Format on page 177

For more information, see Siebel Global Deployment Guide.

Defining a Workflow Process to Function in a Multilingual EnvironmentTo define a workflow process to function correctly in a language other than the base language, be sure your database is capable of handling Multilingual Lists Of Values (MLOV) for the type of non base language. For example, if you must modify a workflow to use FRA and the base language is ENU, then be sure that List of Values entries exist for the FRA language type.

Defining a workflow to function in a multilingual environment

1 In the Siebel client, navigate to the Administration-Data screen, then the List of Values view.

2 Run the following query: Type = "WF_*".

3 Run the MLOV upgrade utility to make sure the database is capable of handling a multilingual list of values.

For more information, see Configuring Siebel Business Applications.

4 In the List of Values list, make sure the Active flag is set.

Literal Values in a Dynamic PicklistBecause a literal value is language dependent, a workflow process that references a literal value becomes language dependent and cannot be run in a multilingual environment. A literal value in a dynamic picklist potentially contains content that is created by the end user at run-time. Because these values are content based rather than metadata or LOV based, the makeup of this content is variable and, therefore, cannot be predictably interpreted by the workflow. For more information, see “Deployment of a Workflow Process in a Multilingual Environment” on page 214 and Siebel Global Deployment Guide.


Options for Developing a Workflow Process ■ Defining a Workflow Process for a Multilingual Environment

176

Expressions in a Multilingual EnvironmentA workflow process uses the Display value to fetch records from tables. In a multilingual deployment, data in the tables is stored in Language Independent Code (LIC). To run a workflow in a multilingual environment, use the LookupValue function to fetch the LIC based on the Display value.

Decision Point ExampleAssume a decision point compares Account Status to Active. The Account Status field is bounded by the Account Status picklist. You can set the Compare To property to Expression, and set the Expression property to the following code:

[Account Status] = LookupValue ("ACCOUNT_STATUS", "Active")

Business Service ExampleAssume a business service step calls the Outbound Communications Manager to send an email message to Expense Approver. The Recipient Group argument is bounded by the Comm Recipient Group picklist. You can set the Type property to Expression, and set the Value property to the following code:

LookupValue ("COMM_RECIP_SRC", "Comm Employee")

For more information on globalization, see Siebel Global Deployment Guide. For more information on defining Siebel Workflow to use MLOV capable fields, see Configuring Siebel Business Applications.

Wait Step and Global Time CalculationsTypes of wait steps include:

■ An absolute wait, which is a wait period governed solely by the duration that is defined. For example, an absolute wait that is set for 30 minutes waits 30 minutes from the time the wait is initiated by a wait step.

■ A service calendar wait, which is not absolute. For example, a service calendar wait can be set to begin at 6 P.M., but if the service hours for the organization are 9 A.M. to 6 P.M., then the wait does not initiate until 9 A.M. the next morning. Therefore, it runs from 9 to 9:30 instead of 6 to 6:30.

Time Zone Setting with a Wait StepIf a workflow process is executing as a server task, then you must shut down, and then restart the Workflow Process Manager after making changes to the Time Zone user preference for the SADMIN user. The changes only go into effect after the Workflow Process Manager is restarted, which is important if you are implementing UTC, because it can be necessary for you to set the Time Zone user preference.

Relations between the type of wait step and time zone settings include:

Options for Developing a Workflow Process ■ Defining a Workflow Process for aMultilingual Environment


■ An absolute wait is not affected by time zone settings, including server and user time zone preferences. Use UTC with the database server. For more information, see Siebel Global Deployment Guide.

■ A service calendar wait step requires a time zone for delay computations. In this case, the time zone for the current user is used.

Local Code Parameter and Data FormatThe Workflow Process Manager (WfProcMgr) server component, similar to other server components, contains a parameter named Local Code which defines formats for data, such as dates, times, numbers, and currency. Note the following logic:

■ If a workflow process runs within the Workflow Process Manager, then the Workflow Process Manager respects the Local Code setting and formats the data appropriately.

■ If the workflow process communicates with an external application or writes data to a file, then date, time, number, and currency data is passed according to the format that is defined in Local Code.


Options for Developing a Workflow Process ■ Defining a Workflow Process for a Multilingual Environment

178


9 Manipulating Data

This chapter describes reference information for manipulating and processing data with a workflow process. It includes the following topics:

■ Accessing Data From a Run-Time Event From a Workflow Process on page 179

■ Passing Data to and from a Workflow Process on page 182

■ Timestamp Usage on page 188

■ Decision Conditions for a Workflow Process on page 188

For information on manipulating data validation rules, see Siebel Order Management Infrastructure Guide.

Accessing Data From a Run-Time Event From a Workflow ProcessThis topic explains how to access run-time event data from a workflow process.

To access data from a run-time event from a workflow process

1 If necessary, expose the WF Step Branch object type in the Object Explorer.


2 In the WF Step Branch OBLE, define the properties for a WF Step Branch using values described in the following table.

Property Value

Name Enter a name for the branch.

Type Condition

Event Object Type Applet

Event InvokeMethod

Event Object Choose the name of the event object that starts the workflow process.

Sub Event NewRecord

Comments Optional

Event Cancel Flag The default is blank.


Manipulating Data ■ Accessing Data From a Run-Time Event From a Workflow Process

180

3 Set up process properties in the Process Designer.

For information, see “About the Process Property” on page 47.

4 Click the first step in your workflow process, then add a new output argument for each process property you must populate that references the run-time event.

To add a new output argument, enter values into the fields that are displayed under the Output Arguments tab in the MVPW. Use the example values described in the following table.


For more information, see “Process of Deploying a Workflow Process” on page 211.

6 Because the workflow process references run-time events, you must load the run-time events:

a Navigate to the Administration-Runtime Events screen, then the Events view.

b On the Events list, click Menu, then choose Reload Runtime Events.

7 Query the Event field for the run-time event you defined in Step 4.

8 Drill down on the Action Set Name field.

9 Add a new Action for each process property that is populated by using the run-time event.

For example, you can define a new action to set the ACU Transaction ID and name it Set ACU Trans ID. Work you must perform for each new action includes:

■ Set the Action Type property to Attribute Set.

■ Set the Profile Attribute to match the value you used in the GetProfileAttr call in the Process Designer in Step 4, such as TransType.

■ Set the Set Operator value to Set.

■ Use the expression builder to assign the Value field an appropriate value, such as the literal string FA-0001.

Field Value

Property Name Enter a name for the property.

Type Expression

Value GetProfileAttr("RestrucOut")

When you define the Profile Attribute field, note the name you give to each of the property values for the Profile Attributes. These are used in Step 9.

Output Argument Leave default value.

Business Component Name Leave default value.

Business Component Field Leave default value.

Comments Optional

Manipulating Data ■ Accessing Data From a Run-Time Event From a Workflow Process


■ Set the Sequence for the action to be less than the default sequence for the Workflow_XXXXXXX Action.

■ Make sure the Sequence setting of the Workflow_XXXXXXX Action is the highest number so that this action happens after every other action.

NOTE: If you modify the workflow process, then you must repeat this step because when a workflow is modified the sequence for the workflow action is reset to 1.

10 From the applet menu, choose Reload Runtime Events.


Manipulating Data ■ Passing Data to and from a Workflow Process

182

Passing Data to and from a Workflow ProcessThis topic describes information about passing data to a workflow process and obtaining data from a workflow process. It includes the following topics:

■ Passing an Input to a Workflow Process on page 182

■ Passing an Output From a Workflow Process on page 183

■ Passing a Parameter from a Workflow Process to a Global Variable on page 183

■ Passing a Constant from a Workflow Policy Action into a Workflow Process on page 183

■ Examples of Scripts That Pass Data to and from a Workflow Process on page 184

The Workflow Engine can be started by calling a business service. The Workflow Process Manager business service is a standard business service that is used for this purpose. If you run a workflow process by calling the Workflow Process Manager business service, then you can pass inputs to Siebel Workflow, and in some cases, obtain outputs from Siebel Workflow.

While this topic discusses passing data to and from a business service step, keep in mind that the sub process step uses the same conventions for passing a property set. For more information, see “In/Out Process Property” on page 56.

Passing an Input to a Workflow ProcessThe input property set is required in order to contain the property named ProcessName, which specifies the name of the workflow process to be run. In addition to the ProcessName property, you can put other values, such as strings, numbers, and property sets, into the property set. These values are passed to the workflow process by the Workflow Process Manager business service.

If the input property set contains a property in the top level property set with a name that matches the name of the property for the workflow process, then simple data type process properties, such as String, Number, and DateTime, that are marked In or In/Out, are initialized. The value of such a property in the input property set initializes the value of the matching process property for the workflow.

If the input property set contains a child whose property set Type field contains a string that matches the name of the hierarchical process property for the workflow process, then hierarchical data type process properties that are marked In or In/Out are initialized. If such a match is found, then the matching child and everything below the child in the input property set is copied into the process property.

Multiple variables can be passed into SQL Program Arguments. For more information, see “Passing Multiple Variables to SQL Program Arguments” on page 479.



Passing an Output From a Workflow ProcessIt is possible that a workflow process that is started programmatically does not return an output. For example, an interactive workflow can be started programmatically, but because it can pause, the output from the call to start the workflow might reflect the state at an intermediate point. For this reason, only a workflow that is guaranteed to run to completion in one call, that is, a service workflow, can be expected to provide output in the output arguments of the call into the Workflow Process Manager business service.

An output argument uses the same convention as an input argument. Simple workflow process properties, such as String, Number, and DateTime, that are marked Out or In/Out, appear as properties on the top level property set. Hierarchical process properties appear as children of the output property set. Hierarchical process properties can be located by examining the Type field of the child, which matches the name for the process property.

Passing a Parameter from a Workflow Process to a Global VariableYou can use a business service to access and pass a parameter from a workflow process to a global variable. If an update is made to a global variable by using a Batch Manager task, then each Batch Manager task is, in essence, a separate user session. Therefore, an update that is made to a global variable by using a Batch Manager task might not be visible to a subsequent Workflow Process Batch Manager task. For more information, see “Example of a Script That Accesses Parameters for a Workflow Process” on page 186.

Passing a Constant from a Workflow Policy Action into a Workflow ProcessYou can use the Run Workflow Process program to pass a constant from a workflow policy action into a workflow process.

To pass a constant from a workflow policy action into a workflow process

1 In Siebel Tools, navigate to the Workflow Policy Program OBLE, then query the Name property for Run Workflow Process.

2 Navigate to the Workflow Policy Program Arguments OBLE.

3 Add a new argument.

4 From the application-level menu, choose the File menu, then the Save menu item.

For example, add a new argument with the Name property set to IOName. Make sure the Visible property contains a check mark.

5 In the Workflow Policy Program OBLE, click the Run Workflow Process object.

6 From the application-level menu, choose the Tools menu, then the Compile Selected Object menu item.



184

7 Click Compile in the Object Compiler dialog.

In the Siebel client, this argument is displayed in the Arguments list in the Workflow Policy Actions view.

8 Set the default value.

The default value varies according to IOName.

9 Open the Process Designer for the workflow to which the constant is passed.

10 In the MVPW, define a new record with the Name argument set to the same name defined in the argument in Step 3.

For example, Name must be the same as IOName. For more information, see “About the Process Property” on page 47.

11 Call the workflow policy.

For more information, see “Starting a Workflow Process from a Workflow Policy” on page 143.

Examples of Scripts That Pass Data to and from a Workflow ProcessThis topic describes examples of using a script to start a workflow process and for passing parameters.

Example of a Script That Starts a Workflow Process and Builds an Input Property SetThis topic gives one example of using a script to start a workflow process and to build an input property set. You might use this feature differently, depending on your business model.

The following is an example script that calls the Workflow Process Manager business service that builds an input property set, psInputs, for the business service. This script defines strings that are put into the input property set as properties:

var msgName = "Siebel Agent Authorization Retrieval";

var reqSubType = "CICS Services Request";

var reqType = "AgentAuthorizationReq";

var CICSServiceName = "Consumer Auto Agent Authorization Retrieval";

var processName = "Consumer Auto VBC VBC Template";

var reqFileName = "C:\\sea752\\XMLMessages\\AgentAuthorizationVBCReq-final.xml"

var resFileName = "C:\\sea752\\XMLMessages\\AgentAuthorizationVBCResponse-final.xml"



Example of a Script That Defines Property Sets for the Input Property SetThis topic gives one example of using a script to define property sets for the input property set. You might use this feature differently, depending on your business model.

The following is an example script that defines property sets, which are put into the input property set as child property sets:

//Request PS

var psRequest = app.NewPropertySet();

var psAgentNumTag = app.NewPropertySet();

var psType = app.NewPropertySet();

var sAgentID;

Example of a Script That Builds Property SetsThis topic gives one example of using a script to build property sets. You might use this feature differently, depending on your business model.

The following is an example script that builds property sets:

//Build property set hierarchy

sAgentID = app.LoginName();

psRequest.SetType("XMLHierarchy");

psAgentNumTag.SetType("DataAgentNumber");

psAgentNumTag.SetValue(sAgentID);

psRequest.AddChild(psAgentNumTag);

Example of a Script That Assembles Properties and Child Property Sets into the Input Property SetThis topic gives one example of using a script to assemble properties and child property sets in the input property set. You might use this feature differently, depending on your business model.

The following is an example script that assembles properties and child property sets into the input property set:

psInputs.AddChild(psRequest);//Pass in Property Set

psInputs.SetProperty("RequestURLTemplate", requestURLTemplate);//Pass in string

psInputs.SetProperty("RequestSubType", reqSubType);

psInputs.SetProperty("ReqType", reqType);

psInputs.SetProperty("MessageName", msgName);



186

psInputs.SetProperty("CICSServiceName", CICSServiceName);

psInputs.SetProperty("ProcessName", processName);

psInputs.SetProperty("Request File Name", reqFileName);

psInputs.SetProperty("Response File Name", resFileName);

Example of a Script That Calls the Workflow Process Manager Business Service and Passes the Input Property SetThis topic gives one example of using a script to call the workflow process manager business service and pass the input property set. You might use this feature differently, depending on your business model.

The following is an example script that calls the Workflow Process Manager business service and passes the input property set to the Workflow Process Manager business service:

var svc = TheApplication(). GetService(“Workflow Process Manager”);

svc.InvokeMethod("RunProcess", psInputs, psOutputs);//Call the Workflow

var sErr = psOutputs.GetProperty("sErr");//Check the Workflow status

Example of a Script That Accesses Parameters for a Workflow ProcessThis topic describes how to use a script to access workflow parameters for a running workflow process.

To define a script that accesses parameters for a workflow process

1 Define a business service that includes the relevant methods and parameters.

2 Access the business service from the workflow process.

3 In the business service step in the workflow process, pass the workflow process properties to the business service method arguments.

For more information, see “Passing a Process Property In and Out of a Step of a Workflow Process” on page 57.

4 Use the following script to use the values of the business service argument and assign them to Profile Attributes:


{

if( MethodName == "XXX" ) {

var isWorkflowRunning, viewValidCurrent, viewValidNext;

// read the input arguments into profile attributes

isWorkflowRunning = Inputs.GetProperty("Workflow Running");



viewValidCurrent = Inputs.GetProperty("Valid View Current");

viewValidNext = Inputs.GetProperty("Valid View Next");

TheApplication().SetProfileAttr("WFRunning", isWorkflowRunning);

TheApplication().SetProfileAttr("WFViewCurrent", viewValidCurrent);

TheApplication().SetProfileAttr("WFViewNext", viewValidNext);

}

5 Use the profile attributes for more processing.

The necessary information is put into the profile attributes of the application. You can use the standard procedures for accessing the profile attributes to extract this information. For more information, see Siebel Personalization Administration Guide.


Manipulating Data ■ Timestamp Usage

188

Timestamp UsageYou can use the timestamp to get the current system time and to do time arithmetic based on the current time. The arithmetic that involves time information for a workflow process is different from that for a workflow policy program. The second operand of the Timestamp () function must be provided in a scale of minutes, that is, as a fraction of the whole day. For example, if the intended result of an arithmetic operation is 30 minutes, then the argument is displayed according to the following syntax:

Timestamp()+0.021

The operation is explained as follows:

■ 0.021 is equal to 30 divided by (24 multiplied by 60)

■ 24 multiplied by 60 represents a whole day in minutes

■ 30 represents the required number of minutes

For more information, see “Date Calculations in the Conditions List” on page 375.

Decision Conditions for a Workflow ProcessThis topic describes information about using the Compose Condition Criteria dialog box in order to define decision conditions for a workflow process. It includes the following topics:

■ Fields in the Compose Condition Criteria Dialog Box on page 189

■ Expressions in the Expression Builder on page 190

Manipulating Data ■ Decision Conditions for a Workflow Process


Fields in the Compose Condition Criteria Dialog BoxTable 30 describes fields you set in the Compose Condition Criteria dialog box in order to define a decision condition. For more information, see “Expressions in the Expression Builder” on page 190.

Table 30. Fields in the Compose Condition Criteria Dialog Box

Field Description Possible Value

Compare To

Indicates where the comparison value is coming from.

(Required). The following choices are available:


■ Process Property

■ Expression

■ Applet

Operation Identifies the comparison operation.

The following choices are available:

■ This Must Match. The current value must match exactly, including case.

■ One Must Match. One or more values must match exactly, including case.

■ All Must Match. All of the values must match exactly, including case.

■ None Can Match. None of the values can match exactly, including case.

■ This Must Match (ignore case). The current value must match without regard to case.

■ One Must Match (ignore case). One or more values must match without regard to case.

■ All Must Match (ignore case). All of the values must match without regard to case.

■ None Can Match (ignore case). None of the values can match without regard to case.

■ Greater Than. Value must be greater than the comparison value.

■ Less Than. Value must be less than the comparison value.

■ Between. Value must be between a range of values.

■ Not Between. Value cannot be between a range of values.

■ Is Null. Value must be null.

■ Is Not Null. Value cannot be null.



190

Expressions in the Expression BuilderThe Compose Condition Criteria dialog box uses the Expression Builder to define a decision condition. This topic describes parts of the Expression Builder, including Compare To options, operations, and patterns.

Compare To OptionsTable 31 describes Compare To options and their required and optional values.

Object The name of the associated business object.

This value is chosen from a picklist of business objects.

Field A required value when Applet is the Compare To value.

The name of the field within the named applet.

Values Not applicable The Values property is dynamic based on the Compare To property. The Values property is used for storing data to be used in evaluating the decision condition.

Table 31. Compare To Options in the Compose Condition Criteria Dialog Box

Compare To Operation Object Field Value

Applet. Compare the run-time value of an applet column to a literal.

Comparison operation. All operations are allowed.

The name of the applet.

The column in the applet.

One or more literals for comparison.

Business Component. Compare the run-time value of a buscomp field to a literal.


The name of the business component.

The field in the business component.


Table 30. Fields in the Compose Condition Criteria Dialog Box




Expression. Evaluate expressions and determine whether they return true.

Specifies how effects of multiple expressions stack. Only applicable when multiple values are defined in the Values property.

The following choices are available:

■ All Must Match

■ None Can Match

■ One Must Match

■ This Must Match

For more information, see “Simple Comparison Operation” on page 192 and “Substitution Variables That Are Commonly Used in an Expression” on page 194.

(Optional) If the field of a business component is referenced in the expression, then the object is the name of a business component. Fields of at most one business component can be referenced in the expressions.

Not applicable

One or more expressions.

Process Property. Compare the run-time value of a process property to a literal.


The name of the process property.

Not applicable


Table 31. Compare To Options in the Compose Condition Criteria Dialog Box

Compare To Operation Object Field Value



192

Simple Comparison OperationA simple comparison operation involves a comparison that can be expressed in a simple expression without the requirement for an iterative operation. Table 32 describes values for a simple comparison operation.

Iterative Comparison OperationAn iterative comparison operation involves multiple iterations on the literal values or expressions in the Values property, or iterations on child business component records, in order to derive a Boolean result.

The following ways can be defined that result in different iterative behavior:

■ When multiple values are defined in the Values property.

■ When multiple records of the child business component exist in the current workset. A child business component is a business component that is not the primary business component in the current business object on which the workflow process is working. If the Compare To option is set to Business Component or Expression, and the Object field is defined as the name of a child business component, then a child business component is involved in the comparison. If multiple records were returned when the child business component was last executed, then multiple records can exist in the current workset of the child business component.

Table 32. Values for Simple Comparison Operations

Comparison

Run-Time Value That Results in a Successful Comparison Description

Between Between two predefined literal values.

This comparison requires two values in the Values property, which is enforced by the Process Designer.

Not Between Not between two predefined literal values.

This comparison requires two values in the Values property, which is enforced by the Process Designer.

Greater Than Greater than a predefined literal value.

Logically, only one value is required in the Values property.

Less Than Less than a predefined literal value.

Logically, only one value is required in the Values property.

Is Null Null or empty. No value is required in the Values property.

Is Not Null Not null or empty. No value is required in the Values property.



All Must Match OperationThe following options are available for the All Must Match operation:

■ Multiple value behavior. If the Compare To option is something other than Expression, and if at least one value matches, then a literal is defined and this comparison succeeds. If the Compare To option is Expression, and if each expression evaluates to true, then this comparison succeeds.

■ Multiple child buscomp record behavior. If the comparison succeeds for every one of the records, then child business component records are used for comparison and the overall comparison succeeds.

Consider an example where All Must Match and multiple child business components are used. In this example, Account is the business object, and the decision condition is described in the following table.

In this example, records for the Contact business component in the current workset must contain a first name of Jane or Julie in order for the comparison to succeed. In this example, the workset is the child contact record for the particular account record that the workflow process is processing.

This Must Match OperationFor the comparison to succeed, field values of the active row of the current instance of the child business component must match the values for the decision condition that is defined for the connector.

If Remote Asynchronous is used, then the workflow process is resumed from the Workflow Process Manager. Because the instance of the child business component is not preserved in the Workflow Process Manager, the active row for the child business component is lost. For this reason, the branch connector stops working. If you must use Remote Asynchronous, then use an operation other than This Must Match. Otherwise, use Local Synchronous.

Options for the This Must Match operation include:

■ Multiple value behavior. If the values involved are literal values, and at least one value matches, then the comparison succeeds. If the values involved are expressions, and if at least one expression is evaluated to true, then the comparison succeeds.

■ Multiple child buscomp record behavior. If the comparison succeeds for the current record, then only the current record of the child business component is used for comparison and the overall comparison succeeds.

Compare To Operation Object Field Values

Business Component All Must Match Contact First Name Jane, Julie



194

None Can Match OperationOptions for the None Can Match operation include:

■ Multiple value behavior. If the values involved are literal values, and if none of the values match, then the comparison succeeds. If the values involved are expressions, and if none of the expressions evaluate to true, then the comparison succeeds.

■ Multiple child buscomp record behavior. If the comparison fails for every one of the records, then records of the child business component are used for the comparison and the overall comparison succeeds.

One Must Match OperationOptions for the One Must Match operation include:

■ Multiple value behavior. If the values involved are literal values, and if at least one value matches, then the comparison succeeds. If the values involved are expressions, and if at least one expression is evaluated to true, which is the same as This Must Match, then the comparison succeeds.

■ Multiple child buscomp record behavior. If the comparison succeeds for at least one of the records, then records of the child business component are used for comparison and the overall comparison succeeds.

Other Iterative Comparison OperatorsOther iterative comparison operators include:

■ All Must Match (Ignore Case)

Same as All Must Match except string comparisons are case insensitive.

■ This Must Match (Ignore Case)

Same as This Must Match except string comparisons are case insensitive.

■ None Can Match (Ignore Case)

Same as None Can Match except string comparisons are case insensitive.

■ One Must Match (Ignore Case)

Same as One Must Match except string comparisons are case insensitive.

Substitution Variables That Are Commonly Used in an ExpressionA process property or a field in a business component is often used as a substitution variable in an expression. For more information see “Referencing a Process Property” on page 60 and “Referencing a Field in a Business Component” on page 195.

For more information about the operators, expressions, and decision conditions that can be used in a workflow process, see Siebel Developer’s Reference.



Referencing a Field in a Business Component The syntax is [FieldName]. For example, the following syntax is used for the business component named Contact:

[First Name] like 'Jane'

where:

■ First Name is the name of the field

The business component itself is defined in the Object field of the Expression Builder.

Example of Using an Expression to Compare ValuesAn expression can be used to compare the value of a process property Object Id to that of the Contact business component and Account Id field, as described in the following table.

Compare To Operation Object Values

Expression This Must Match Contact [Account Id] like [&Object Id]



196


10 Testing a Workflow Process

This chapter describes how to test your workflow process. It includes the following topics:

■ About the Testing Tools on page 197

■ Process of Testing a Workflow on page 202

■ Troubleshooting Validation and Simulation Problems on page 208

For more information about developing planning strategies for testing the Siebel application, see Testing Siebel Business Applications.

About the Testing ToolsThis topic describes tools you can use to test a workflow process. It includes the following topics:

■ Validate Tool on page 197

■ Process Simulator on page 198

■ Business Service Simulator on page 201

■ Event Logs on page 201

Validate ToolThe Validate Tool is an error correction tool you can use before you simulate and deploy a workflow process. Validation enforces the semantic consistency of a workflow that otherwise cannot be readily enforced by structural constraints. For example, by using validation, you can make sure an error-workflow process does not itself contain an error-workflow process. When you validate a workflow, warnings are displayed that describe errors that the workflow contains. You can then correct the errors before running the Process Simulator.

If there are validation errors, then a dialog box displays, which provides you an opportunity to correct errors before publishing. This dialog box is modeless, meaning that you can keep it open to view the error messages while using the Process Designer to correct the problems reported. You can proceed with deployment despite validation errors if you choose to do so.

The ways that you can launch the validate tool for a workflow process include:

■ Use the context sensitive right-click menu in either the Process Designer or the Workflow Processes Object List Editor (OBLE)

■ Use the Publish or Publish/Activate buttons on the WF/Task Editor Toolbar


Testing a Workflow Process ■ About the Testing Tools

198


■ Validating the Workflow Process on page 202

■ Troubleshooting Problems That Occur During Validation on page 208

Process SimulatorThe Process Simulator is a simulation tool that allows you to step through a workflow process while you view the results of each step. Simulating your workflow process before deploying it to your production environment helps to verify that the workflow produces the expected results.


■ How the Process Simulator works, see “Simulation Architecture of a Workflow Process” on page 28

■ How to use the Process Simulator, see “Preparing to Use the Process Simulator” on page 203

■ Using the Business Service Simulator in cases where the process simulator cannot be used, see “Business Service Simulator” on page 201

Workflow Mode and the Process SimulatorMost workflow processes can be tested and debugged using the Process Simulator, which is hosted in Siebel Tools. You can use the Process Simulator to test a workflow that runs in the Siebel client, including a service workflow, a 7.0 workflow, an interactive workflow, and a workflow that is based on a run-time event. You cannot use the Process Simulator to test a long-running workflow or a workflow that involves a server component.

Workflow Process Testing with a Server ComponentYou cannot use the Process Simulator to test a workflow process that involves a server component, such as Workflow Process Manager, Server Request Broker, Assignment Manager, or Communications Server. If a workflow process that involves a server component is run in the Process Simulator, then incorrect behavior results. To test a workflow that involves a server component, the workflow must be deployed to the run-time environment and tested by using the application server.

For example, if you must test a workflow process that calls Siebel Assignment Manager, then deploy the workflow to the run-time environment. You export the workflow from Siebel Tools and import it to the Siebel client. Then you test the workflow in real time with the working server components.

Starting a Workflow Process with the Process SimulatorOf the various ways to start a workflow process, starting a workflow from the Process Simulator is an easy way to test and debug a workflow. You can debug steps of the workflow as you define them in Siebel Tools, where the Process Designer and the Process Simulator both reside.



When the workflow process is run from the Process Simulator, it runs in the Application Object Manager (AOM). The workflow can be started in the Application Object Manager or in the Workflow Process Manager server session, depending on specific parameters. Because some workflows that can run in the Workflow Process Manager server session might not be able to run in the application object manager, it is possible that every workflow cannot be simulated.

Other ways to start a workflow process involve starting the workflow outside of Siebel Workflow. For more information, see “Starting a Workflow Process” on page 143. For information about starting a workflow from a server component, see Overview: Siebel Enterprise Application Integration and Siebel eMail Response Administration Guide.

Preparing the Simulator for Use with a ScriptYou can use the Process Simulator with a workflow process that references a business service or business component that contains a script. However, if that script contains a breakpoint, and if the Arguments field in the Siebel Tools debug configuration contains /h, then the Simulator might not perform as expected. A breakpoint is a marker on a line of Basic code that tells Basic to suspend execution at that line so that the state of the program can be examined by using the Siebel Debugger. The /h argument directs the Siebel debugger to open the Watch window.

To prepare the simulator for use with a script

1 Remove every breakpoint from the script on a business service or a business component that is referenced by the workflow process.

2 Remove the /h argument from the Siebel Tools debug configuration:

a From the Tools application-level menu, choose the View menu, then the Options menu item.

b Click the Debug tab.

c Remove the /h argument from the Argument field.


Using the Watch WindowThe Process Simulator includes a Watch window that dynamically displays values for the business component and process property of the workflow process. These values are associated with and are manipulated by the workflow that is simulated.


■ An example that uses the watch window, see “Testing the Workflow Process” on page 274

■ Using the watch window in conjunction with the Workflow Utilities business service, see “Workflow Utilities Business Service” on page 487



200

To use the watch window

1 From within the Process Designer for the workflow process you must simulate, right-click the canvas, then choose Simulate.

2 Click Start Simulation, then wait for the Siebel client to launch and return control to Siebel Tools.

3 Right-click the canvas of the Process Simulator, then choose Watch Window.

In the Watch window, the left column displays the name of the property set type. The right column displays the current value for the property.

The Watch window is not available until after you perform Step 2. You must start the simulation and wait for control to return to Tools prior to opening the Watch window.

Guidelines for Using the Watch WindowGuidelines when using the Watch window include:

■ You can hide the Watch window by right-clicking, then choosing Hide Watch Window.

■ If the Watch window is empty, then right-click the canvas of the Process Simulator, and then choose Watch Window, thus refreshing the display.

■ In addition to opening the Watch window from within the Process Simulator, you can also open the Watch window by choosing, from application-level menu, the View menu, Debug Windows, then the Watch menu item.

Property Set of the Watch WindowA value that is manipulated by the simulation is dynamically updated and displayed in the Watch window as each step finishes during the simulation. Table 33 describes information that is available in the Watch window.

Table 33. Property Set of the Watch Window

PropertySet Description

Simulator Status Displays real-time status information for the simulation.

For example, Step Completed, or Simulation Ended Successfully.

Process Properties Displays the current value for each process property that is defined for the workflow process.

For example, the value 7-4HWSV displays for the Object Id process property.

BusComp Displays business component user data for fields in the business component for the record that is currently processed by the simulator.

For example, the value 40000 displays for the Revenue field.



Business Service SimulatorA workflow process can be run as a business service from the Business Service Simulator in the Siebel client. Use the Business Service Simulator when you must debug a script in conjunction with a workflow. You can set breakpoints in the script, then execute the workflow in the Siebel Mobile Web Client. If the workflow executes a service for which a breakpoint is set, then control is returned to the Script Debugger in Siebel Tools.

The workflow process must be published and activated before the workflow can be tested with the Business Service Simulator. The requirements to use the simulator include:

■ The Siebel Mobile Web Client must be installed

■ The workflow process must be exported from Siebel Tools

■ The workflow process must be imported to the Siebel client

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

For more information about using the Business Service Simulator, see “Diagnosing a Workflow Process That Has Failed” on page 240.

Event LogsYou can set monitoring levels for event logs so that you can view detailed information about the execution of a workflow process. This technique is useful if you cannot perform real-time debugging or if the Process Simulator is not readily available. However, using this technique can result in large log files that must be analyzed. For more information, see “Setting Monitoring Levels for Tracing and the Event Log” on page 236. For information on using the Log File Analyzer, see Siebel System Monitoring and Diagnostics Guide.


Testing a Workflow Process ■ Process of Testing a Workflow

202

Process of Testing a WorkflowThis process is a step in “Roadmap for Developing a Workflow Process” on page 97.

To test a workflow process, perform the following tasks:

1 Validating the Workflow Process on page 202

2 Preparing to Use the Process Simulator on page 203

3 Using the Process Simulator on page 204

4 Verifying Functionality on page 206

Before you deploy a workflow process, you must test it in a test environment. Testing a workflow verifies that the workflow you release into the production environment executes properly and does not cause conflicts with another workflow.

Guidelines for setting up your test environment include:

■ Make sure your test environment and production environment contain identical versions of the software

■ Use realistic data by using a partial or full copy of the production database


■ Validation and simulation tools, see “About the Testing Tools” on page 197

■ Example that includes detailed instructions, see “Testing the Workflow Process” on page 274

Validating the Workflow ProcessThis task is a step in “Process of Testing a Workflow” on page 202.

You can validate a workflow process.

To validate a workflow process



2 Right-click the workflow process, then choose Validate.

The Validate dialog box displays.

3 Click Start.

Starting validation displays in the bottom left corner of the Validate dialog box.

4 If the validation is successful, then there are no errors to report and a message displays in the bottom left corner of the dialog box, Total tests failed: 0.



5 If the validation is not successful, then a list of errors are displayed along with the rules that each error violates. In this case, perform one of the following actions:

a Click the error to view the message in the Details window of the dialog box.

b Save the errors to a log file by clicking Save As at the bottom of the validation panel.

Every error is not fatal. Some errors are only warnings.

For more information, see “Troubleshooting Problems That Occur During Validation” on page 208.

Preparing to Use the Process SimulatorThis task is a step in “Process of Testing a Workflow” on page 202.

In this task, you prepare to use the process simulator.

To prepare to use the process simulator

1 Make sure the Siebel Mobile Web Client is installed.

The Siebel Mobile Web Client can connect to a development or local database that contains the test data that is required to debug a workflow.

2 If necessary, publish subprocesses that are called by the workflow process you are simulating.

To avoid a validation error, you must publish and activate subprocesses that are called by the workflow process you are simulating prior to calling the simulator. For more information, see “Publishing a Workflow Process” on page 216.

3 If necessary, expose the simulate toolbar.

For more information, see “Preparing Siebel Tools to Develop a Workflow Process” on page 115.


5 Click the Debug tab.

6 Define the fields in the Debug tab using values from the following table, where $ represents settings that are specific to your setup.

Field Value

Executable $SiebelClient\BIN\siebel.exe

Make sure you enter the full path for the siebel.exe executable file.

CFG file $SiebelClient\BIN\ENU\uagent.cfg

Make sure you enter the full path for the uagent.cfg configuration file.

Browser $\Program Files\Internet Explorer\iexplore.exe

Working directory $SiebelClient\BIN

Arguments /h



204

7 Click OK.

Using the Process SimulatorThis task is a step in “Process of Testing a Workflow” on page 202.

In this task, you run the Process Simulator on a workflow process.


■ Usage guidelines, see “Guidelines for Using the Process Simulator” on page 206

■ Examples that use the simulator, see “Testing the Workflow Process” on page 274, and “Testing the Workflow Process” on page 283

CAUTION: If testing a workflow process by using the Process Simulator, then it is important to note that the workflow runs just as if it were called in a production environment. For instance, if the workflow includes a Siebel operation, such as update or add, then records in the database are modified when you run the Process Simulator. Also, your test environment and production environment must contain identical software versions.

To use the process simulator

1 Close every Siebel client session.

To avoid encountering a multiple client session error, you must close every client session prior to launching the Process Simulator. If a Siebel client session is running, then you cannot start the Process Simulator.

2 Make sure there are no Siebel client icons in the Task Bar.



4 Right-click the Workflow Process.

As an alternative, you can launch the simulator from within the Process Designer. To do so, launch the Process Designer for the workflow process you must simulate, right-click the canvas of the Process Designer, then choose Simulate.

User name $username

Password $password

Data source $datasource

Field Value



5 Choose Simulate Workflow Process.

The Process Simulator opens. A read only version of the workflow process displays with a pale yellow canvas, the start step is highlighted, and the Start Simulation button on the Simulate toolbar is active.

6 In the Simulate toolbar, click Start Simulation to begin the simulation.

The Simulation In Progress dialog box displays momentarily.

7 Observe the Siebel client launch, then wait for control to return to Tools.

A new instance of the Siebel client launches according to the debug settings you entered in “Preparing to Use the Process Simulator” on page 203. You use this Siebel client instance as the run-time environment for the simulation. There is no other work you must perform in this Siebel client instance unless the simulated workflow process is an interactive workflow. For more information, see “Simulating an Interactive Workflow Process” on page 206

After the Siebel client initializes, the Simulation In Progress dialog box disappears, control passes back to Siebel Tools, the start step executes, then control pauses at the next step in the workflow process. If the first step executes as expected, then the next step of the workflow is highlighted in the Process Simulator view.

8 In the Simulate toolbar, click Simulate Next to execute the highlighted step.

9 Continue clicking Simulate Next until the last step finishes.

As you step through the workflow process, examine results of each step in the Watch window until the workflow process finishes. For more information, see “Using the Watch Window” on page 199.

10 If the workflow process does not execute as expected, then correct the problem, and then restart the simulation at Step 6.

For more information, see “Troubleshooting Problems That Occur During Simulation” on page 209.

11 (Optional) Examine test results in the Siebel client.

If your workflow process manipulates record data, you might be able to examine test results in the Siebel client. For an example, see “Testing the Workflow Process” on page 262.

12 Close the Simulator window.

After the last step of the workflow process executes, the simulation automatically ends. You can also use the Stop Simulation button to halt the simulation before the last step executes.



206

Guidelines for Using the Process SimulatorGuidelines when using the Process Simulator include:

■ In the Siebel client, if the workflow process does not contain a user interact step, then do not navigate or click UI elements while using the Process Simulator. If you must navigate in the Siebel client, then it might be necessary to close the Siebel client and Siebel Tools, then open Siebel Tools to rerun the Simulator.

■ In Siebel Tools, do not navigate outside of the Process Designer while the Process Simulator is running.

■ After the Siebel client launches, it might be necessary to ALT+TAB back to Siebel Tools to proceed with the simulation.

■ You can use the Process Designer to make changes to step properties, then return to the Process Simulator to test the workflow process. To make changes to step properties, first stop the Process Simulator, then restart the simulation after changes are made.

■ You can hide the Object Explorer and the Properties window to better view your work in Siebel Tools. You can also resize the Siebel Tools window so that it covers only a part of the visible display area.

■ If a wait step is defined in seconds, then the Workflow Process Simulator simulates a wait period. However, if the unit of time is defined in minutes or greater, then the Simulator simply moves on to the next step.

■ It is not necessary for a workflow process to be active in order to run it in the Process Simulator. The simulator ignores activation date, expiration date, and status.

Simulating an Interactive Workflow ProcessIf using the process simulator with an interactive workflow process, then you must perform some actions in the Siebel client while the simulator is running.

To simulate an interactive workflow process

1 While running the process simulator, when the highlighted step is a user interact step, click Simulate Next.

The corresponding view that is defined for the step displays in the Siebel client.

2 Switch to the Siebel client, then make sure the run-time event is executed in the client according to the definition for the user interact step.

After the user interact step is executed successfully in the Siebel client, control is passed back to Siebel Tools, and the highlight moves to the next step in the workflow process.

Verifying FunctionalityThis task is a step in “Process of Testing a Workflow” on page 202.



To finish testing a workflow process, you can verify that the workflow implements the functionality that is necessary to meet your business requirements. Verification is often performed by manipulating data in the Siebel client, then verifying that execution of the workflow matches the functionality that was defined during the planning phase. For an example, see “Verifying Functionality of the Workflow Process” on page 303.


Testing a Workflow Process ■ Troubleshooting Validation and Simulation Problems

208

Troubleshooting Validation and Simulation ProblemsThis topic describes guidelines for resolving validation and simulation problems with a workflow process.

Troubleshooting Problems That Occur During ValidationTo resolve a problem that is detected by the Validate tool, look for it in the list of Symptoms/Error messages in Table 34.

Table 34. Problems That Occur During Validation

Symptom or Error Message Diagnostic Steps or Cause Solution

Connector is not attached correctly.

Not applicable Make sure connectors for the workflow process are connected correctly.

Conditional branch not is defined for a Decision point.

Not applicable Make sure you define at least one conditional branch that emanates from each Decision point in the workflow process.

Business service and business service method are not defined for a business service step.

Not applicable Make sure each business service step in the workflow process is not missing a business service or a business service method.

Business component is missing from a Siebel Operation step.

Not applicable Make sure you define the business component upon which each Siebel operation step acts.

Name of the subprocess is not defined for a sub process step.

Not applicable Make sure each sub process step specifies the appropriate subprocess that is called by the workflow process.



Troubleshooting Problems That Occur During SimulationTo resolve a problem that is detected by the Simulation tool, look for it in the list of Symptoms/Error messages in Table 34.

Table 35. Problems That Occur During Simulation

Symptom or Error Message Diagnostic Steps or Cause Solution

When attempting to simulate a workflow process, upon starting the workflow process, the process simulator does not run.

If a run-time event is defined on the connector that emanates from a start step, then the simulator waits for the event and never reaches the next step.

Choose one of the following:

■ Remove the run-time event from the simulation.

■ Add a Default branch.

NOTE: It is recommended you define two branches: one with Type set to Condition, to wait for the run-time event, and the other with Type set to Default.

When attempting to rerun the process simulator, an error dialog displays Still waiting on Workflow Process Simulator, or The run-time client is not responding.

Navigating in the Siebel client during or after running the process simulator can cause a failure during subsequent attempts at running the simulator.

Do not navigate in the Siebel client while the process simulator is running or after the simulation ends. For more information, see “Guidelines for Using the Process Simulator” on page 206.

After completing the user interact step, the process simulator fails to proceed down the workflow process.

A branch out of a user interact step might be missing an associated run-time event.

Make sure the branches out of the user interact step contain the respective run-time events that are associated with actions performed on the user interact step.

After the Siebel client launches, control does not return to Siebel Tools, or a dialog in Siebel Tools indicates that the client is still launching, even after a long wait.

Not applicable Restart processes that are currently running. For more information, see “Restarting the dbeng9.exe and siebel.exe Processes” on page 210.

An error message displays while the simulation is executing, similar to Error loading siebel operation step definition [step name]. The defined step definition is not valid.

Errors in the configuration of the workflow process are revealed during the simulation, which can include errors in how objects are defined or how objects are used by the workflow.

Close the process simulator, correct the configuration errors, then run the simulation again.



210

Restarting the dbeng9.exe and siebel.exe ProcessesThis topic describes how to restart the dbeng9.exe and siebel.exe processes.

To restart the dbeng9.exe and siebel.exe processes

1 Log out of the Siebel client session and close Siebel Tools.

2 Open Windows task manager.

3 Click the Processes tab, right-click the dbeng9.exe Image Name, choose End Process, then click Yes.

4 Right-click the siebel.exe Image Name, choose End Process, then click Yes.

5 Restart Siebel Tools, then run the simulation again.


11 Administering a Workflow Process

This chapter describes how to administer a workflow process. It includes the following topics:

■ Process of Deploying a Workflow Process on page 211

■ Process of Migrating a Workflow Process on page 218

■ Process of Administering a Workflow Process on page 227

■ Monitoring a Workflow Process on page 233

■ Diagnosing a Workflow Process That Has Failed on page 240

■ About Upgrading a Workflow Process on page 253

Process of Deploying a Workflow ProcessThis process is a step in “Roadmap for Developing a Workflow Process” on page 97.

To deploy a workflow process, perform the following tasks:

1 Preparing the Run-Time Environment on page 212

2 Publishing a Workflow Process on page 216

3 Activating a Workflow Process on page 216

Defining and deploying a workflow process can occur separately. After you define a workflow in the Process Designer in Siebel Tools, you deploy it by preparing the run-time environment, publishing it in Siebel Tools, then activating it in the Siebel client.

When deploying, the workflow process is read from the repository, then Siebel Workflow writes it to the run-time environment as XML. You can use the Replication, Activation Date, Expiration Date, and Monitoring Level parameters during deployment. For more information, see “Setting Monitoring Levels for a Workflow Process” on page 233.

For a conceptual overview of this topic, see “Deployment Architecture of a Workflow Process” on page 30.


Administering a Workflow Process ■ Process of Deploying a Workflow Process

212

Preparing the Run-Time EnvironmentThis task is a step in “Process of Deploying a Workflow Process” on page 211.

This topic describes work you must perform in order to make sure the run-time environment is capable of running the workflow process. It includes the following topics:

■ Making Sure an Object That Is Referenced by the Workflow Process Is Current on page 212

■ Activating a Field That Is Used by a Workflow Process on page 212

■ Deploying a Workflow Process to the Siebel Mobile Web Client on page 213

■ Deploying a Workflow Process on a Regional Node on page 214

■ Deployment of a Workflow Process in a Multilingual Environment on page 214

■ Deploying a Workflow Process as a Web Service on page 215

Although it is not required that you perform these topics in the order presented, you must consider each topic to determine if it applies to the workflow process you are deploying.

Making Sure an Object That Is Referenced by the Workflow Process Is CurrentIf the workflow process you are deploying contains a sub process step or references a new repository object, such as a business component, business service, or view, then you must make sure the subprocess or repository object is available to the workflow you are deploying.

To make sure an object that is referenced by the workflow process is current■ Perform one of the following:

■ In the case of a sub process step, deploy the subprocess before you deploy the parent workflow process so that the subprocess is accessible to the parent.

■ In the case of new repository objects, first compile the new repository objects so they are accessible to the workflow process you are deploying.

Activating a Field That Is Used by a Workflow ProcessA field that is not activated by the Object Manager must be activated for Siebel Workflow in order to reference and use it. Note the following:

■ If a field is exposed on the user interface, then it is activated by the Object Manager, and a workflow process that runs on the Object Manager that references this field can run properly.

■ If a field is not exposed on the user interface, then it is not activated by the Object Manager. In this case, a workflow process that runs on the Object Manager cannot use the field, and an error is generated.



To activate a field that is used by a workflow process■ Perform one of the following:

■ In Siebel Tools, in the Fields Object List Editor (OBLE), explicitly activate the field by setting the Force Active property of the field to TRUE.

■ Expose the field on the user interface.

■ Activate the field through a script, such as a business service that activates the field to be used before the workflow process uses it.

Deploying a Workflow Process to the Siebel Mobile Web ClientThe Replication field in the Workflow Deployment view allows you to choose whether to route a workflow process to your Siebel Mobile Web Client (MWC). Routing only the workflow that your Siebel Mobile Web Client requires allows you to reduce the amount of data in the local database.

To deploy a workflow process to the Siebel mobile web client

1 Navigate to the Administration-Business Process screen, Workflow Deployment, then the Active Workflow Processes view.

2 Define the Replication field using values from the following table.

For more information, see “Deploying a Workflow Process on a Regional Node” on page 214.

Restrictions for Routing with the Siebel Mobile Web ClientIf modifying the Replication field to choose whether to route a workflow process to your MWC, then keep in mind that changing the Replication field value from None to All adds the workflow process and related records to the MWC or regional node when it synchronizes with the server.

Testing Routing Behavior with Full Copy NodesIf you extract a regional node with the routing group set to FULL COPY, then a workflow process with Replication set to None is routed to the MWC.

Value Description

All The workflow process is routed to Siebel Mobile Web Clients and regional nodes.

Regional The workflow process is routed to the regional nodes only.

None (Default) The workflow process is not routed to the Siebel Mobile Web Client or the regional nodes.



214

To test routing behavior with full copy nodes

1 Modify two existing or define two new workflow processes, one with Replication set to All and the other with Replication set to None.

2 Extract a regional node with the routing group set to FULL COPY.

3 Examine the dx file in the outbox of the regional node to make sure that both workflow processes were routed.

Behavior When Using a Run-Time Event with a Mobile ClientThere is some variation in the way a run-time event performs in a mobile client when compared with other Siebel client types.

NOTE: It is recommended that the processing mode be Local synchronous or remote asynchronous. If remote asynchronous is used for a mobile client, then the workflow process is started after you synchronize with the server. For more information, see “Remote Synchronous Processing” on page 150.

Notification to Mobile Users Who Are Not SynchronizedYou can define a workflow process to send a notification email to mobile users who are not synchronized. For more information, see 476188.1 (Doc ID) or 476275.1 (Doc ID) on OracleMetaLink 3.

Deploying a Workflow Process on a Regional NodeYou can execute a workflow process on a regional node. The workflow can be called from a script or a run-time event.

To deploy a workflow process on a regional node■ Make sure the workflow process resides on the regional node. The settings and environment must

be replicated entirely on the node. The objects that the workflow references must be available on the regional node.

Deployment of a Workflow Process in a Multilingual EnvironmentA workflow process deployed from the object manager for a language is not available on the object manager for another language until after a restart is executed. If deploying a workflow process that is used in a multiple language deployment, then the object managers for each language must be restarted.

For example, assume you define a workflow process that is called in the write record event for a business component through scripting. You publish and activate this workflow, then restart the servers. You see that the workflow is called both for callcenter_enu and callcenter_esn. Then you revise and publish this workflow from Siebel Tools. From within callcenter_enu, you activate the workflow. You see that callcenter_enu uses the revised workflow, but callcenter_esn does not. If you activate this workflow in callcenter_esn, then an error results. You must restart the callcenter_esn object manager to get the new workflow process to function correctly.



Deploying a Workflow Process as a Web ServiceA workflow process can be deployed as a Web service.

To deploy a workflow process as a Web service

1 In Siebel Tools, in the Workflow Designer, examine definitions in the MVPW in order to determine if the Data Type field for a process property is set to Integration Object. If so, make sure a value is defined in the Integration Object field for each of those process properties.

If hierarchical data in a business service is used by the workflow process, then you must set Data Type for the process property to Integration Object, then define an integration object in the Integration Object field.

If no integration object is defined, then the following error occurs: The selected workflow process contains hierarchy type process properties without having the integration

object name defined.


2 Make sure the workflow process you must deploy is published and activated.

For more information, see “Publishing a Workflow Process” on page 216.

3 Locate the workflow process that you must modify.


4 Right-click the workflow process, then choose Deploy as Web Service.

The Expose Workflow Process as Web Service dialog displays.

5 In the top window of the dialog, define the operation name for the new Web service.

Typically, you define the underlying method name of the business service without spaces, such as CreateAccount. Use a method for a business service that is defined in the workflow process.

6 In the bottom window of the dialog, define the URL that identifies the address for the Web service. Replace [webserver] with a valid host name and [lang] with a valid language code, such as enu.

7 (Optional) To generate a Web Services Description Language (WSDL) file, click the Generate WSDL checkbox, then define a location to save the WSDL file.

8 Click Finish.

The Web service is generated.



216

9 To view the Web service you just generated:

a In the Siebel client, navigate to the Administration-Web Services screen, then the Inbound Web Services view.

b Query the Name column in the Inbound Web Services list for the workflow process name you clicked in Step 4.

To display Web services that are generated from workflow processes and business services, query the Namespace column for http://siebel.com/CustomUI.

For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration.

Publishing a Workflow ProcessThis task is a step in “Process of Deploying a Workflow Process” on page 211.

To publish a workflow process

1 Locate the workflow process you must publish.


2 In the WF/Task Editor toolbar, click Publish.


Next, activate a workflow process.

Activating a Workflow ProcessThis task is a step in “Process of Deploying a Workflow Process” on page 211.

The first procedure in this topic describes how to activate a single workflow process. The second procedure describes how to activate workflow processes in batch. For more information, see “Activate Button in the Siebel Client” on page 63.

Activating a Single Workflow ProcessYou can activate a single workflow process.

To activate a single workflow process

1 Log in to the Siebel client with administrator privileges, connected to the appropriate database.

2 Navigate to the Administration-Business Process screen, then the Workflow Deployment view.

3 In the Repository Workflow Processes list, query the Name field for the workflow you published in Step 2 on page 216.



4 Make sure the workflow process is chosen.

5 Click Activate.

6 In the Active Workflow Processes list, set the deployment parameters for the workflow process:

a If necessary, query the Name field for the workflow you just activated.

b Set the activation date in the Activation Date/Time field.

c Set the expiration date in the Expiration Date/Time field.

d Make sure Replication is set to None, unless you are deploying the workflow process to the Siebel Mobile Web Client.

If you are deploying the workflow process to the Siebel Mobile Web Client, then see “Deploying a Workflow Process to the Siebel Mobile Web Client” on page 213.

e Set the monitoring level in the Monitoring Level field.

For more information, see “Setting Monitoring Levels for a Workflow Process” on page 233.

7 If a run-time event is defined in the workflow process, then you must reload the run-time events:

a Navigate to Administration-Runtime Events.

b Click the applet menu, then choose Reload Runtime Events.

This step reloads the run-time events in the current object manager session. For an example, see “Deploying the Workflow Process” on page 286. For more information, see Siebel Personalization Administration Guide.

Now you can start the workflow process through the Process Simulator, a script, or a workflow policy. For more information, see “Starting a Workflow Process” on page 143.

Activating a Batch of Workflow ProcessesYou can activate a batch of workflow process.

To activate a batch of workflow processes

1 In the Siebel client, navigate to the Administration-Business Process screen, then the Workflow Deployment view.

2 In the Repository Workflow Processes list, query the Name field for the workflow processes you must activate.

3 Choose the workflow processes you must activate, then click Activate.

NOTE: It is recommended that you do not choose every workflow process in the list.


Administering a Workflow Process ■ Process of Migrating a Workflow Process

218

Process of Migrating a Workflow ProcessThis process is a step in “Roadmap for Developing a Workflow Process” on page 97.

To migrate a workflow process, perform the following tasks:

1 Developing a Migration Strategy on page 218

2 Migrating a Workflow Process on page 223

After you test and publish a workflow process in the development environment, you can migrate it to the production environment.

NOTE: Before you migrate data, be sure the data that is required for the workflow process is also present in the target environment. For example, if your workflow requires custom entries in the List of values (LOV) table, then make sure these entries are present and active.

Developing a Migration StrategyThis task is a step in “Process of Migrating a Workflow Process” on page 218.

After you deploy the workflow process, it is ready to be migrated. Migrating is the act of moving a workflow process from a development environment to a production environment. Migration also describes the act of moving a workflow process from a lower version repository to a higher version repository. One of three utilities can be used: ADM, REPIMEXP, and Import/Export.

To develop a migration strategy

1 Peruse the available migration options in order to determine which option is most appropriate for your implementation.

For more information, see “Comparison of Migration Options” on page 219.

2 Consider the requirement to redeploy your workflow process after it is migrated.

If you migrate workflow processes using ADM, then the workflows are activated automatically. If you use REPIMEXP or the Siebel Workflow Import/Export option, then you must redeploy the workflows manually. For more information, see “Redeployment of a Workflow Process After it Is Migrated” on page 223.

3 Choose one of the migration options.



Comparison of Migration OptionsTable 36 provides a comparison of options for migrating workflow processes.

Migration with Application Deployment ManagerApplication Deployment Manager (ADM) is a deployment framework that automates the process of migrating enterprise customization data from one Siebel application environment to another, including from a development environment to a production environment. This customization data can include views, responsibilities, assignment rules, workflow processes, workflow policies, and so forth.

Table 36. Comparison of Options for Migrating a Workflow Process

Migration Option When to Use

ADM Environments in which to use ADM include:

■ When you are migrating customization data for your entire enterprise, including workflow process data.

■ You must migrate more than 10 workflow processes at one time.

For more information, see “Migration with Application Deployment Manager” on page 219.

REPIMEXP Environments in which to use REPIMEXP include:

■ When you are rolling out your release and most or every repository object must be migrated. REPIMEXP is the manual process for repository migration. If it is not necessary to use ADM, or you cannot use ADM, then use REPIMEXP.

■ If you choose not to connect Siebel Tools to your production repository, then you must use REPIMEXP.

For more information, see “Migration with REPIMEXP” on page 220.

Workflow Admin Service Business Service

Environments in which to use the Workflow Admin Service business service include:

■ When you can perform bulk or batch migration of workflow processes. As an alternative to using the Workflow Admin Service business service, you can perform client-side batch activation and expiration by way of the File menu in the application.

For more information, see “Migration with the Workflow Admin Service Business Service” on page 220.

Import/Export Environments in which to use Import/Export include:

■ When you can migrate workflow processes in increments of approximately 10 or less

For more information, see “Migration with Import/Export” on page 220.



220

ADM is designed to provide a single deployment tool that covers various areas within the Siebel application. The objective is to reduce the potential manual setup and deployment work and to provide as much automation as possible in order to decrease the error rate.

A deployment package for workflow processes in ADM includes the SRF, the workflow processes, their subprocesses, and their run-time settings, such as activation and expiration times, monitoring levels, and so forth. For information, see Siebel Application Deployment Manager Guide.

Migration with REPIMEXPThe REPIMEXP utility allows you to export and import repository objects. Because this utility migrates repository objects, including your workflow processes, it is most useful when your organization is ready to roll out an entire release. The Repository Import/Export utility is found in the siebel/bin directory. Use REPIMEXP for bulk migration of repository objects, including workflow processes. In the command line interface, type repimexp/help to view your usage options.

When using REPIMEXP, you cannot pick and choose which workflow processes to migrate. To choose a single workflow or only certain workflows for migration, use the Import/Export migration option.

Migration with the Workflow Admin Service Business ServiceThe Workflow Admin Service business service allows you to import, export, deploy, and activate multiple workflow processes in bulk. Workflows are identified through a search specification. For more information see, “Import and Export when Using Certain Features of Siebel Tools” on page 222 and “Workflow Admin Service Business Service” on page 489.

Migration with Import/ExportYou can use Import/Export for incremental migration of workflow processes. You use Siebel Tools to export workflows from one environment and to import workflows to another environment. The Import/Export feature for Siebel Workflow is designed only to migrate an individual workflow or a small set of workflows. For example, Siebel Workflow Import/Export cannot migrate 150 workflows at one time. To migrate large numbers of workflows with Import/Export, break them into sets of 10 workflows or less. For more information, see “Importing and Exporting a Workflow Process” on page 224.

Migration with Siebel ToolsWhen using Siebel Tools, you import the workflow process into the repository of the target environment, then you click Publish to mark the workflow for migration. After this, the workflows are ready to be activated. This technique makes sure the versions of the workflows that exist in the repository tables and the run-time tables are the same.



Figure 19 illustrates an incremental migration using the Import/Export utility and Siebel Tools.

Steps you perform when you use Siebel Tools to import a workflow process include:

1 Export the workflow process to XML by using the Import/Export Utility.

2 Import the workflow process into the repository of the target environment.


Migration with Siebel Tools In Conjunction with the Siebel ClientYou can import a workflow process directly into the run-time tables. This technique bypasses the requirement for you to write the workflows into the repository tables of the target environment and activation from the Siebel client, although these steps are still performed in the background by the Workflow Engine. This technique causes the latest version of the workflow process in the run-time tables, used by the Workflow Engine, to be different from the version that resides in the repository tables.

NOTE: Importing directly to the run-time tables is an effective technique for testing a workflow process in a different environment. However, it is recommended that this technique not be used for general migration of workflows across environments.

Figure 19. Incremental Migration Using Import/Export From within Siebel Tools



222

Figure 20 illustrates an incremental migration using Import/Export to export from within Siebel Tools and import from within the Siebel client.

Steps you perform when you use the Siebel Client to migrate a workflow process include:

1 Export the workflow process to XML by using the Export Utility.

2 Import the workflow process into the repository of the target environment.

Import and Export when Using Certain Features of Siebel ToolsSiebel Tools features that are not applicable to Siebel Workflow objects include:

■ SIF export and import.

■ Object Compare.

■ Three way merge during upgrades. For more information, see Siebel Application Services Interface Reference.

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

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

Import and Export with a SubprocessIf you import a workflow process that contains a sub process step, then you must import the subprocess, and then the parent workflow process. Import the parent only after the subprocess is successfully imported. This rule also applies for importing workflow processes in batch.

Figure 20. Incremental Migration Using Import/Export from within Siebel Tools and Import from within the Siebel Client



It is not necessary to export the subprocess first when exporting a workflow process.

Name length must also be considered for a subprocess when importing a workflow process. A subprocess can contain a name that is to 100 characters in length. The name of a subprocess that exceeds this limit can generate an error during import.

Import and Export with Carriage ReturnsIf a workflow process calls the SendMessage method of the Outbound Communications Manager business service to send email, and if carriage returns exist in the message body, then the workflow process can be exported. However, if the workflow is imported back into the database, then the imported workflow does not contain the carriage returns. Instead, the carriage returns appear as square characters, and the message body is treated as a single paragraph.

To remedy this situation, you must edit the message body, replacing the square characters with carriage returns. A carriage return is entered by pressing the enter key.

Redeployment of a Workflow Process After it Is MigratedWhen planning a migration strategy, it is important to consider potential redeployment work that must be performed after the workflow process is migrated. After migrating your workflow to a production environment, it might be necessary for you to redeploy the workflow before you can run it.

Table 37 describes how redeployment requirements depend on the technique that is used to migrate the workflow process.

Migrating a Workflow ProcessThis task is a step in “Process of Migrating a Workflow Process” on page 218.

Use the tool that you identified in the migration strategy to perform the migration. This topic describes procedural information for using the Import/Export strategy or the business service strategy. For procedures for ADM, see Siebel Application Deployment Manager Guide. For procedures for REPIMEXP, see Going Live with Siebel Business Applications.

If you are migrating a large number of workflow processes, then you can define a small group of workflows to migrate as a first phase of implementation. After you successfully migrate the first group, you can add more workflows in a systematic manner.

For more information, see “Migrating Workflow Policies to the Production Environment” on page 443.

Table 37. Comparison of Migrating with ADM to REPIMEXP or Import/Export

Redeployment with ADMRedeployment with REPIMEXP or Import/Export

It is not necessary for you to manually redeploy workflow processes in the target environment.

You must manually redeploy workflow processes in the target environment.



224

Importing and Exporting a Workflow ProcessYou can use the Import/Export feature both as a migration tool and as a way to back up an individual workflow process. Use a meaningful naming convention when choosing a filename for an exported workflow process in order to make it easy to understand the purpose of the process. Some prerequisites must be met when you use the import or export strategy. For more information, see “Migration with Import/Export” on page 220.

Importing a Workflow ProcessYou can import a workflow process.

To import a workflow process

1 In Siebel Tools, navigate to the Workflow Processes OBLE.

2 Right-click, then choose Import Workflow Process.

The Open dialog box displays.

3 Choose a path and filename of the workflow process to import, then click Open.

4 Choose the project to which you must add the workflow process.

The workflow process is imported with a status of In Progress.

If a workflow process of the same name exists in the target environment, then the version number for the newly imported workflow is incremented by one.

Exporting a Workflow ProcessYou can export a workflow process.

To export a workflow process



To choose more than one workflow process, press and hold the CTRL key while choosing the workflows.

2 Right-click, then choose Export Workflow Process.

The Save As dialog box displays.

3 Enter the file path, filename, the .xml filename extension, then click Save.

The workflow process is exported. If you chose more than one workflow to export, then the workflows you chose are saved to one XML file.

If you export a workflow process that contains a sub process step, then you must also export the sub process. A sub process is not automatically exported.



Migrating with the Workflow Admin Service Business ServiceThis topic gives one example of migrating with the Workflow Admin Service business service. You might use this feature differently, depending on your business model. For more information, see “Workflow Admin Service Business Service” on page 489.

To migrate with the Workflow Admin Service business service

1 In the Siebel client, navigate to the Administration-Business Service screen, then the Simulator view.

2 In the Simulator list, click New, then define fields according to values described in the following table.

3 In the Input Arguments list, click New, then define fields according to values described in the following table.

Change the Process Name value that you enter for Property Value in order to meet the specific requirements of your implementation.

4 In the Simulator list, click Run.

Upon completion, the simulator displays the results of the simulation in the Output Arguments list. In this example, the Property Value field in the Output Arguments list displays the number of workflow processes whose name begins with Pricing Procedure and whose status is completed. You can modify the Property Value in order to meet your specific business requirements.

5 To examine simulation output:

a Navigate to the Administration-Business Process screen, then the Workflow Deployment view.

Field Value

Service Name Workflow Admin Service

Method Name Activate

Field Value

Test Case # 1

Property Name FlowSearchSpec

Property Value [Process Name] like '*Pricing Procedure*' and [Status] = 'Completed'



226

b Issue a compound query using values from the following table.

The query returns a list of workflow processes that are also represented in the Output Arguments list of the business service simulator. The total number of records returned in the query must match the number of records that are displayed in the Property Value field described in Step 4.

Field Value

Name *Pricing Procedure*

Deployment Status Active

Administering a Workflow Process ■ Process of Administering a Workflow Process


Process of Administering a Workflow ProcessThis process is a step in “Roadmap for Developing a Workflow Process” on page 97. You might use this process differently, depending on your business requirements.

To administer the instances of a workflow process, perform the following tasks:

1 Viewing Run-Time Instances of a Workflow Process on page 227

2 Using the Workflow Instance Admin View on page 228

3 Monitoring a Workflow Process on page 233

4 Stopping an Instance of a Workflow Process on page 229

5 Deactivating the Instance of a Workflow Process on page 230

6 Removing a Workflow Process From the Run-Time Environment on page 231

Over the lifetime of a workflow process, you can perform the general sequence of steps described in this topic.

Viewing Run-Time Instances of a Workflow ProcessThe Workflow Deployment view allows you to view, deploy, and activate a workflow process. This view displays the parent and child relationship that exists between the workflow process and the run-time records for the workflow process.

To view run-time instances of a workflow process

1 Log in to the Siebel client.


3 In the Repository Workflow Processes list, query the Name field for the workflow process you must administer.

4 Drill down on the Name field.

5 Examine configuration for the workflow process, using values from the following table.

List Name Description

Active Workflow Processes Lists workflow processes that are deployed.

Child Items Filters records to display only child items of the workflow process chosen in the parent list.



228

Where Information About the Instance of a Workflow Process Is StoredTables that include information about instances of a workflow process include:

■ S_WFA_INSTANCE

■ S_WFA_INST_PROP

■ S_WFA_INST_WAIT

Tables that include information about instance monitoring of a workflow process include:

■ S_WFA_INST_LOG

■ S_WFA_INSTP_LOG

■ S_WFA_STPRP_LOG

Viewing Pre 7.7 Workflow ProcessesThe Workflow Processes view allows you to view workflow processes that are defined earlier than Siebel CRM version 7.7. The Workflow Processes view and the child views for the workflow are read only views that are used specifically for viewing workflow processes defined earlier than version 7.7.

To view pre 7.7 workflow processes


2 Navigate to the Administration-Business Process screen, then the Workflow Processes view.

3 In the Workflow Processes list, query the Name field for the workflow process you must administer.

4 Examine configuration for the workflow, using values from the following table.

Using the Workflow Instance Admin ViewThe Workflow Instance Admin view displays workflow processes that have persistence set and that are in a run state, wait state, or error state. This view allows you to view, monitor and control a workflow process. For a chosen instance, you can change the value of the process properties before resuming the instance.

View Tab Description

Process Definition Displays the definition of a workflow process that is defined earlier than version 7.7.

Process Designer Displays the flow diagram of a workflow process that is defined earlier than version 7.7.

Process Properties Displays properties of a workflow process that is defined earlier than version 7.7.



If a workflow process contains a wait step, or if the Auto Persist flag for a workflow is checked, then persistence for a 7.0 workflow process is set.

To use the workflow instance admin view


2 Navigate to the Administration-Business Process screen, then the Workflow Instance Admin view.

3 In the All Workflow Process Instances list, query the Process Name field for the workflow process you must administer.

4 Administer the instances for the workflow process, using values from the following table.

For more information, see “Stopping an Instance of a Workflow Process” on page 229 and “Manually Recovering the Instance of a Workflow Process” on page 251.

Stopping an Instance of a Workflow ProcessIf persistence is defined for a workflow process, then you can stop an instance of the workflow. After the instance of a workflow is stopped, it is removed. An instance that contains a status of Running, Waiting, or Error can be stopped.

If you stop an instance that is running, then the execution of the instance is terminated, which is different from purging an instance. For more information, see “Purging a Workflow Process from the Log File” on page 231.

CAUTION: A stopped instance of a workflow process cannot be resumed.

To stop an instance of a workflow process

1 In the All Workflow Process Instances list of the Workflow Instance Admin view, query the Process Name field for the workflow process you must stop.

For more information, see “Using the Workflow Instance Admin View” on page 228.

2 In the Related Instances list, choose the instance you must stop.

3 In the applet menu, choose Stop Instance.

List Name Description

All Workflow Process Instances

Lists instances of a workflow process that are running, in an error state, or in a waiting state.

Related Instances Displays instances of the workflow process that are chosen in the All Workflow Process Instances list.

Process Properties Displays process properties of the instance of the workflow process that is chosen in the Related Instances list. You can change the value of these process properties before you resume an instance that is waiting or that is in an error state.



230

Stopping an Instance of a Workflow Process Through a ScriptBy using the _StopInstance method, you can use a script to stop an instance of a workflow process. An example usage of this technique occurs when an interactive workflow must be cancelled but which is suspended in a wait step. In this scenario, the Process Instance Id is already known.

To stop an instance of a workflow process through a script■ Call the _StopInstance method on the Workflow Process Manager business service, as in the

following example, which uses a Process Instance Id that is hard coded:

var bs_WF = TheApplication().GetService("Workflow Process Manager");

var ps_inputs = TheApplication().NewPropertySet();

var ps_outputs = TheApplication().NewPropertySet();

ps_inputs.SetProperty("ProcessInstanceId", "1-IIT");

bs_WF.InvokeMethod("_StopInstance" , ps_inputs, ps_outputs);

Deactivating the Instance of a Workflow ProcessYou can deactivate a single instance of a workflow process, or multiple instances in a batch.

To deactivate an instance of a workflow process

1 In the Active Workflow Processes list of the Workflow Deployment view, choose the workflow process you must deactivate.

For more information, see “Viewing Run-Time Instances of a Workflow Process” on page 227.

2 In the Active Workflow Processes list, choose the instance you must deactivate.

3 From the applet menu, choose Deactivate Process.

The status of the chosen instance is changed to Inactive.

Deactivating Instances of a Workflow Process in BatchYou can deactivate instances of a workflow process in batch.

To deactivate instances of a workflow process in batch

1 In the Active Workflow Processes list of the Workflow Deployment view, choose the instances you must deactivate.

Use Multi-click, holding down the CTRL key while clicking each record in the list.

TIP: Instead of using Multi-click, formulate a query to display only the workflow processes you must deactivate, then choose Select all from the applet menu.




2 From the applet menu, choose Deactivate Process.

The status of the instances that are chosen in Step 1 are changed to Inactive.

Removing a Workflow Process From the Run-Time EnvironmentTo remove a workflow process from the run-time environment, you can delete the workflow, then purge the instance of the workflow from the log.

Deleting a Workflow ProcessYou can delete a workflow process from within the Workflow Deployment view, which removes the definition of the workflow from the run-time environment. It also stops instances of the deleted workflow.

To delete a workflow process

1 In the Active Workflow Processes list of the Workflow Deployment view, choose the workflow process you must remove.


2 From the applet menu, choose Delete Process.

3 If necessary, purge the workflow process from the log.

For more information see “Purging a Workflow Process from the Log File” on page 231.

TIP: You can use Multi-select to choose multiple workflow processes. Because the Delete Process functionality deletes a workflow and stops the instances of that workflow, instances that are related to the chosen workflows are also stopped. Therefore, if you must perform a batch delete of multiple workflows, then perform the procedure beginning with Step 1 on page 231, using Multi-select to choose multiple workflows rather than just one workflow. To use Multi-select, keep the CTRL key depressed as you click each record in the list.

Purging a Workflow Process from the Log FileYou can use the purge feature in order to delete a workflow process that contains a status of Stopped or Completed. If you must delete a paused instance, then stop the instance first. If you delete a running instance from the log, then the execution of the instance is unaffected and the instance continues to run.



232

To purge a workflow process from the log file

1 In the Siebel client, navigate to the Administration-Business Process screen, Workflow Instance Monitor, then the Process Instances view.

2 In the Process Instances list, choose the workflow process you must purge.

3 Click Purge.

4 In the Workflow Instance Monitor Purge dialog box, choose a date.

5 Click Purge.

Administering a Workflow Process ■ Monitoring a Workflow Process


Monitoring a Workflow ProcessThis topic describes how to monitor and troubleshoot a workflow process in the production environment. It includes the following topics:

■ Overview of Monitoring and Troubleshooting Tools on page 233

■ Setting Monitoring Levels for a Workflow Process on page 233

■ Setting Monitoring Levels for Tracing and the Event Log on page 236

■ Defining Metrics for a Workflow Process on page 237

■ Capturing Data with Siebel Application Response Measurement on page 238

■ Recording Behavior with the Siebel Flight Data Recorder on page 239

Overview of Monitoring and Troubleshooting ToolsTools that can be used to monitor and troubleshoot a workflow process include:

■ Progress and status information. Use the Workflow Instance Monitor view and the Workflow Instance Admin view to monitor the progress and status of each workflow process. For more information, see “Setting Monitoring Levels for a Workflow Process” on page 233.

■ Operation details. Use event logging to trace operations that are performed by each step of a workflow process. For more information, see “Setting Monitoring Levels for Tracing and the Event Log” on page 236.

■ Performance measurement data. Use SARM (Siebel Application Response Measurement) to capture timing data for measuring performance of a workflow process. For more information, see “Capturing Data with Siebel Application Response Measurement” on page 238.

■ Failure analysis records. Use Siebel FDR (Flight Data Recorder) to automatically capture the events that might lead to a system failure. For more information, see “Recording Behavior with the Siebel Flight Data Recorder” on page 239

Setting Monitoring Levels for a Workflow ProcessThe Monitoring Level you set determines the frequency with which log writing occurs and, hence, the data that is available in the views for the instance of a workflow process. There are two views you can use to monitor a workflow. For more information, see “Stopping an Instance of a Workflow Process” on page 229 and “Removing a Workflow Process From the Run-Time Environment” on page 231.

Monitoring Instances of a Workflow ProcessThe Workflow Instance Monitor view allows you to monitor instances of a workflow process, as well as step instances and aggregate data.



234

To monitor instances of a workflow process


2 Navigate to the Administration-Business Process screen, then the Workflow Instance Monitor view.

3 In the Workflow Process list, query the Name field for the workflow process you must monitor.

4 Monitor run-time data of the workflow process, using values from the following table.

For more information, see “Purging a Workflow Process from the Log File” on page 231, and “Using Instance Monitoring to Diagnose a Workflow Process” on page 240.

Monitoring LevelWhen the Monitoring level is set for a workflow process that is deployed, the instance of the workflow remains in the Workflow Instance Monitor view after it finishes and is no longer visible in the Workflow Instance Admin view. Depending on the monitoring level that is set for the chosen workflow, there might be no records in the Step Instances and Aggregate Data views.

Setting the Monitoring Level ParameterWhen an instance of a workflow process is created, the monitoring level is read from the workflow and remains throughout the lifetime of the instance unless the instance is paused. In the case of a paused instance, when the instance is resumed, the monitor level is reread from the workflow.

List Name or View Tab Description

Workflow Process Displays definitions of workflow processes that have monitoring turned on. A workflow with a Monitoring Level that is not set to NONE is turned on. For more information, see “Monitoring Level” on page 234.

Process Instances Displays the related log instances for the chosen workflow process.

Step Instances Displays the steps and process properties for the chosen instance of a workflow process.

Aggregate Data Displays aggregate data as a chart view for the chosen workflow process.



Table 38 describes parameters for monitoring levels and their corresponding frequencies for log writing that you can set for a workflow process.

To set the monitoring level parameter


2 In the Active Workflow Processes list, set the Monitoring Level field.

Guidelines for Setting the Monitoring LevelThe monitoring level determines the frequency with which data is written to the disk. The frequency is optimized internally by the run-time environment for Siebel Workflow, based on the type of workflow process and the monitoring level you choose. Monitoring can incur a performance overhead. It is best to set the monitoring level to 0 (None) or 1 (Status) on a workflow process that is running in a production environment.

NOTE: It is recommended that a monitoring level of 2 (Progress) and higher only be used for debugging a workflow process.

If the monitoring level is Debug, then the log is written to the disk after every step.

Monitoring Level and Compatibility with the 7.0 Workflow ProcessSettings for monitoring levels with a 7.0 workflow process include:

■ If the persistence frequency is set to NONE, then the monitoring level is set to NONE.

■ If the persistence frequency is ON_PAUSE or EVERY_STEP, then persistence is explicitly turned on and the monitoring level is set:

■ If the persistence level is ALL_STEPS, then the monitoring level is set to PROGRESS.

■ If the persistence level is CURRENT_STATE, then the monitoring level is set to STATUS.

Table 38. Descriptions of Parameters for Monitoring Levels

Monitoring LevelRecord Process Instance

Record Step Instances

Record Process Properties

0 None No None None

1 Status Yes None None

2 Progress Yes All Steps None

3 Detail Yes All Steps All Steps

4 Debug Yes All Steps All Steps



236

With the Siebel CRM 8.1 release, persistence and monitoring are separate features that serve different purposes. Persistence affects quality of service and is controlled during development. Monitoring is an administrative tool and is controlled during deployment. Monitoring typically does not affect the functionality of a workflow process.

Setting Monitoring Levels for Tracing and the Event LogYou can use tracing levels to troubleshoot a workflow process. Setting a trace level above the default level affects performance. Reset the trace level to the default value after troubleshooting is finished.

Table 39 describes the events that a workflow process uses for logging.

Increasing Tracing Levels for Components of the Workflow Management ServerYou can generate a more detailed trace file to assist in troubleshooting Workflow Process Manager, Workflow Process Batch Manager, and Workflow Recovery Manager. You should increase tracing levels prior to executing the server process.

Table 39. Events for Logging of a Workflow Process

Event Level Description

Workflow Definition Loading (DfnLoad)

3 Traces object definitions for workflow processes and steps for workflows that are loaded into memory.

Workflow Engine Invoked (EngInv)

4 Traces methods that are called and arguments that are passed to the Workflow Engine.

Workflow Process Execution (PrcExec)

4 Traces creation and completion for instances of workflow processes. Traces the process property get or set.

Workflow Step Execution (StpExec)

4 Traces creation and completion of the step, evaluation of the decision condition for the branch , calling of the business service, and inserting or updating of the business component .

Workflow Performance (WfPerf)

4 Measures overall execution time for a workfow process.

Workflow Performance (WfPerf)

5 Measures execution time of the workflow process and of individual steps of a workflow.

Workflow Recovery (WfRecv)

3 Traces recovery status and progress for an instance of a workflow process. Applicable only to the Workflow Recovery Manager server component.

Workflow Recovery (WfRecv)

4 Traces recovery details for an instance of a workflow process. Applicable only to the Workflow Recovery Manager server component.



To increase tracing levels for components of the workflow management server

1 In the Siebel client, navigate to the Administration-Server Configuration screen, Servers, Components, then the Events view.

2 In the Components list, choose the component for which you must generate tracing.

These components include the Workflow Process Manager, the Workflow Process Batch Manager, or the Workflow Recovery Manager.

3 Click the Events tab in order to view the configurable event types for the chosen component.

The log level is set to a default value of 1.

4 Change the log level value to 3, 4, or 5.

For more information, see Table 39 on page 236.

5 (Optional) For more troubleshooting, you can repeat Step 4 to increase the tracing level for the Object Manager SQL log event.

More tracing information is generated as the Component Event Configuration Log Level value increases. For more information on the different Log Level values available for Component Event Configuration, see Siebel System Monitoring and Diagnostics Guide.

Defining Metrics for a Workflow ProcessA workflow process metric allows you to collect data that is associated with a property of the workflow. To collect metrics, you define the subset of metrics to be captured, then activate the metric collection after you deploy the application.

To define metrics for a workflow process

1 Make sure the WF Process Metrics object type is exposed in the Object Explorer.




3 In the Object Explorer, expand the Workflow Process tree, then click WF Process Metric.

4 Right-click in the WF Process Metrics OBLE, then choose New Record from the pop-up menu.

5 In the Metric Name property, choose the desired metric from the list of predefined metric names.

6 For the Property Name property, choose a process property from the list of those defined for the workflow process.

7 Make sure the Inactive property does not contain a checkmark.

The Inactive property provides a convenient means for you to turn off a metric and turn it on later.



238




10 Query the Name field of the Active Workflow Processes list for the workflow process you activated in Step 8.

11 Set the Analytics Level field of the Active Workflow Processes to Property or All.

This step allows metrics to be collected at run time.

Capturing Data with Siebel Application Response MeasurementThe Workflow Process Manager server component can use Siebel Application Response Measurement (SARM). SARM captures timing data that is useful for monitoring the performance of the Siebel application, and records this information to binary files.

Table 40 describes SARM levels that are used with a workflow process.

Table 40. SARM Levels That Are Used with a Workflow Process

SARM Level Description

1 The Workflow Process Manager business service records the time that is required in order to execute the method of a business service.

Examples of service methods in Workflow Process Manager are RunProcess and ResumeInstance.

2 The Workflow Process Manager business service records the time required to perform the following:

■ Execute the method of a business service

■ Execute a step in a workflow process

■ Write monitoring data to the disk

SARM level 2 can help you determine the logging overhead when you increase the monitoring level of your workflow process.



Table 41 describes SARM areas and subareas that are used with a workflow process.

For more information on configuring SARM and the SARM analyzer, see Siebel Performance Tuning Guide.

Recording Behavior with the Siebel Flight Data RecorderLog files of the Siebel Flight Data Recorder (FDR) , identified with the .fdr extension, are records of system and server component behavior at run time. If a system or server component fails, then the settings and events that lead up to the failure are logged. The FDR log file can then be used to troubleshoot and analyze the specific settings and events that occurred prior to the failure. FDR log files are stored in the Binary subdirectory of the Siebel Server root directory.

FDR instrumentation points are embedded in the Workflow Process Manager business service and the Workflow Recovery Manager business service in order to provide capture processing details in case of a system failure or server component failure.

For information, see “How to Get Help with an Error of a Workflow Process” on page 242, and Siebel System Monitoring and Diagnostics Guide.

Table 41. SARM Areas and Subareas That Are Used with a Workflow Process

Level Area Subarea Description

1 WORKFLOW CORDR_RESUME Resume a workflow process that is suspended.

1 WORKFLOW CORDR_EXECUTE Execute a workflow process.

1 WORKFLOW ENGNE_INVOKE Call a method of the Workflow Process Manager business service.

2 WORKFLOW STEPS_EXSTEP Execute a step of a workflow process.

2 WORKFLOW MONTR_WRTE Write monitoring data of a workflow process to disk.


Administering a Workflow Process ■ Diagnosing a Workflow Process That Has Failed

240

Diagnosing a Workflow Process That Has FailedThis topic includes following topics:

■ Diagnosing a Workflow Process That Has Failed in a Production Environment on page 240

■ Troubleshooting Execution Problems with a Workflow Process on page 243

■ About the Workflow Recovery Manager on page 246

Diagnosing a Workflow Process That Has Failed in a Production EnvironmentThis topic describes how to diagnose problems in the production environment. For more information about some of the tools described in this topic, see “Monitoring a Workflow Process” on page 233.

Using Tracing to Diagnose a Workflow Process You can use tracing to diagnose a workflow process that has failed.

To use tracing to diagnose a workflow process

1 Turn on tracing for the appropriate component that is running the workflow process.

Example components include the Workflow Process Manager, Workflow Process Batch Manager, or the application Object Manager.

2 View the event log files.

For details on how to turn on tracing, see “Setting Monitoring Levels for Tracing and the Event Log” on page 236.

Using Instance Monitoring to Diagnose a Workflow ProcessYou can use instance monitoring to diagnose a workflow process that has failed.

To use instance monitoring to diagnose a workflow process


2 In the Active Workflow Processes list, choose the workflow process you must monitor.



3 Set the monitoring level to 3-Detail or 4-Debug.

At this level, the state and process properties values for each step in a workflow process are recorded, regardless of which component runs the step.

NOTE: The 3-Detail and 4-Debug monitoring levels affect performance of the Workflow Engine. For this reason, use these levels for troubleshooting purposes only.

4 Navigate to the Administration-Business Process screen, Workflow Instance Monitor, then the Process Instances view.

5 View the monitoring information and fix problems, as necessary.

Using the Business Service Simulator to Diagnose a Workflow ProcessYou can use the business service simulator to diagnose a workflow process that has failed.

To use the business service simulator to diagnose a workflow process

1 Run the workflow process from the Business Service Simulator using the Workflow Process Manager business service.

This step executes the workflow process in the application object manager.

2 In the Siebel client, navigate to the Administration-Business Service screen, then the Simulator view.

3 In the Simulator list, define a new record, then set the fields using values from the following table.

4 In the Input Arguments list, define a new record, and perform the following:

a Set the Test Case # field to 1.

b Choose and open the Property Name field.

The Property Name field opens a multi-value applet.

5 In the multi-value applet, click New, then set the fields using values from the following table.

6 Click Save.

Field Value

Service Name Workflow Process Manager

Method Name RunProcess

Iterations 1

Field Value

Property Name ProcessName

Value (Enter the name of the workflow process.)



242

7 Repeat Step 5 and Step 6 for other parameters that are passed to the workflow process, especially RowId, if necessary.

8 In the multi-value applet, click OK.

9 In the Simulator list of the Simulator view, click Run.

TIP: To increase the data that is available to you for troubleshooting, set the monitoring level to 4-Debug, as described in Step 3 on page 241, launch the workflow process with the Business Service Simulator, then view execution information of the workflow process in the Workflow Instance Monitor views.

For more information, see “Business Service Simulator” on page 201, and “Removing a Workflow Process From the Run-Time Environment” on page 231.

Avoiding Excessive Records in the S_WF_PROP_VAL TableThe S_WF_PROP_VAL table stores values of process property for a workflow process. When a workflow process is executed, records are created in the S_WF_PROP_VAL table along with a new S_WF_STEP_INST record.

There is the potential for the S_WF_PROP_VAL table to become very large over time, because a workflow process typically contains five or more process properties. Therefore, five records can be added to the S_WF_PROP_VAL table for each instance of a workflow process. Having Persistence defined on a large number of workflow processes can cause an increase in the size of the S_WF_PROP_VAL table. To avoid this situation, disable persistence on your workflows unless it is absolutely necessary.

To avoid excessive records in the S_WF_PROP_VAL table■ Disable persistence by setting the Auto Persist property to NO on the workflow process.

For more information, see “About Events” on page 157.

How to Get Help with an Error of a Workflow ProcessTo get help with an error of a workflow process, create a service request on OracleMetaLink 3. Alternatively, you can phone Global Customer Support directly in order to create a service request or get a status update on your current SR. Support phone numbers are listed on OracleMetaLink 3.



You can use the following ways to communicate errors of a workflow process:

■ Send the log files.

Log files are generated by turning on tracing, as described in Step 1 on page 240.

■ Communicate the error code and error message.

Except for a service workflow process, if a workflow process encounters an error, then the state of the workflow is persistent with a status of In-Error. If a workflow encounters an error in a subprocess, then the state of the subprocess is also persistent. Both the error code and the error message are saved in a process property. You can examine the error code and error message in the Process Properties list of the Workflow Process Instance Admin view. If a record is chosen from the All Workflow Process Instances list, then the related instance list displays the parent and child workflows. You can communicate the error code and the error message for further assistance.

Troubleshooting Execution Problems with a Workflow ProcessThis topic describes guidelines for resolving execution problems of a workflow process.

Table 42 lists Symptoms and error messages you can review in order to resolve problems with the execution of a workflow process.

Table 42. Troubleshooting Execution Problems of a Workflow Process

Symptom Diagnostic Steps and Cause Solution

After activating a workflow process, it does not execute when the corresponding run-time event is called.

Not applicable Make sure Reload Runtime Events is executed. To determine if a workflow process is started, turn on workflow logging for EngInv, StpExec, and PrcExec. For more information, see “Increasing Tracing Levels for Components of the Workflow Management Server” on page 236.

After revising a workflow process and reactivating it, the revised workflow information is not read.

Not applicable For a workflow process that is running in the Workflow Process Manager server component, reset the parameter Workflow Version Checking Interval. By default the interval is 60 minutes.



244

When a workflow process is started by the DisplayApplet run-time event, the workflow is started the first time but not subsequently.

If the DisplayApplet run-time event is a UI event, and if the default Web UI framework design uses a cache, then the event only fires the first time a non cached view is accessed. The workflow process is started only when the event fires and works correctly.

To make the field still work in this situation, you can explicitly set EnableViewCache to FALSE in the .cfg file.

After a workflow process is started from a run-time event, the row ID of the record on which the event occurred is not retrieved.

The run-time event is passed to the row ID of the primary business component and not to the row ID of the business component on which the run-time event acts.

Retrieve the row ID of the active business component by using a search specification. For example: the Active_row-id process property is equal to [Id], defined as Type equals Expression and the business component equals the business component name.

The following error message displays: Cannot resume Process [x-xxxxx] for Object-id [x-xxxxx]. Please verify that the process exists and has a waiting status.

Deleting existing instances of the workflow process does not help.

This error typically occurs in the following scenario:

1 An instance of a workflow process is started and paused, waiting for a run-time event.

2 The run-time event fires. The instance is resumed and run to completion.

3 The run-time event fires for a second time. The Workflow Engine tries to resume the instance but fails because the instance is no longer in a Waiting state.

Ignore the error message and proceed. Step 1 through Step 3 must occur, in that order, and in the same user session in order for the error message to be reported. As a result, the error message disappears when the application is restarted.

The Purge feature only works on instances that have stopped and finished. To delete persistent or incomplete instances, you first must manually stop the instances.

Unable to access a different business object from a workflow process.

The architecture for Siebel Workflow restricts the use of one business object to a workflow process.

Use a sub process step to access a different business object.





The following error message displays: Unable to initiate the process definition [process name].

Not applicable Make sure the following situations are true:

■ The workflow process exists.

■ The status for the workflow process is set to Active.

■ The workflow process is not expired.

One of the following error messages displays:

■ OMS-00107: (: 0) error code = 4300107, system error = 27869, msg1 = Could not find 'Class' named 'Test Order Part A'

■ OMS-00107: (: 0) error code = 4300107, system error = 28078, msg1 = Unable to create the Business Service 'Test Order Part A'

Not applicable Make sure at least one SRF is copied to the Siebel Server \objects\[lang] directory.

The following error message displays:

■ The selected record has been modified by another user since it was retrieved.

A workflow process attempted to update a record that was updated by another user or task since the record was initially retrieved by the workflow.

Define an error exception connector to handle the update conflict. For more information, see “Defining an Error Exception Connector to Handle an Update Conflict” on page 166.





246

About the Workflow Recovery ManagerThis topic describes Workflow Recovery Manager. It includes the following topics:

■ Overview of the Workflow Recovery Manager on page 246

■ Administering the Workflow Recovery Manager on page 248

■ Recommended Techniques to Recover a Workflow Process on page 250

■ Recovering a Workflow Process on page 250

Overview of the Workflow Recovery ManagerFunctionality provided by Workflow Recovery Manager includes:

■ Recovers interrupted instances of a long-running workflow process upon failure of the Siebel Server. As the instance is recovered, the Workflow Engine attempts to continue forward execution. If forward progress is not possible, then the workflow is marked as IN_ERROR and manual intervention is required in order to resume the workflow.

■ A instance of a workflow process is resumed at the last checkpoint in order to maintain the integrity of the execution. The checkpoint is automatically determined by the Workflow Engine based on hints that are provided by the developer during development. The Workflow Engine automatically persists relevant execution data in order to resume execution upon failure of a workflow process.

■ Recovery of instances of a workflow process is load balanced. One server thread can determine the recovered instances. This server thread delegates the actual resumption of the recovered instance to other server threads in a load balanced manner.

■ Recovery of a workflow process can be started without interfering normal execution of the Workflow Engine. One server thread can start the recovery of workflow instances, while other threads in the Workflow Engine still handle new requests in order to execute workflows. Thus, the Workflow Engine is blocked by the recovery thread.



Architecture of the Workflow Recovery ManagerFigure 21 illustrates the architecture that is used for recovering a workflow process.

Components in the architecture of the Workflow Recovery Manager include:

1 Workflow Engine. A batch component, Workflow Process Manager, that is responsible for executing a long-running workflow process. As the workflow is executed, the Workflow Engine persists the execution state into the database at the appropriate time.

2 Workflow Recovery Manager. A batch component that is responsible for identifying a workflow process that is interrupted due to a server failure. If Workflow Recovery Manager discovers an interrupted instance of a workflow, then the recovery manager forwards the instance to the Workflow Engine in order to resume execution. The recovery manager itself does not execute the instance of the workflow.

3 Database. A database that is used to store the execution state of the workflow processes. The persistent record is used to restore execution state when the workflow resumes execution from a failure.

4 Server Message Queue. A queue through which the Workflow Engine and the recovery managers multi-cast messages.

Figure 21. Architecture of the Workflow Recovery Manager



248

5 Business Process Administration View. Allows you to manually request the Workflow Recovery Manager to recover a workflow process that is interrupted.

6 Server Administration Task Management. Allows you to define a recurrence server task for the Workflow Recovery Manager. The recurrence server task requests the server manager to periodically scan for workflow processes that are interrupted.

Administering the Workflow Recovery ManagerThe status of the Workflow Recovery Manager component is Online after it is started, functioning similar to other components. However, no server tasks are visible unless a recovered instance of a workflow process is recovered after a server failure.

If you run list tasks for comp WfRecvMgr and no executed server tasks are returned, then it indicates there are no failed instances, which is expected behavior.

Workflow Recovery Manager that is in an Active status indicates that the Workflow Recovery Manager component is up and running.

To administer the Workflow Recovery Manager

1 In the Server Manager command-line interface, issue the enable compgrp workflow command.

This step makes sure that the component group for Siebel Workflow is activated on the server. For more information about Server Manager usage, see Siebel System Administration Guide.

2 In the Siebel client, navigate to the Administration-Server Management screen, then the Components view.

3 Query for Workflow Recovery Manager.

4 If Workflow Recovery Manager is not Online, then click Start Up.

This step starts the Workflow Recovery manager. It is not necessary to set other parameters.

Testing the Workflow Recovery ManagerIn this topic, you prepare to test, then test the Workflow Recovery Manager.

To prepare to test the workflow recovery manager

1 Connect to the Server Manager from the Siebel Server.

You must see the smgr> prompt. For more information about Server Manager usage, see Siebel System Administration Guide.

2 Issue the following command and check whether the Component Group named Workflow is activated:

Smgr>list compgrp



3 If the Workflow component group is not activated, then perform the following steps:

a Enter the following command to activate it:

Smgr> enable compgrp workflow

b Stop, then restart the server.

4 In the Siebel client, navigate to the Administration-Workflow Process screen, then the Workflow Deployment view.

5 If the server is reset, then make sure there is a workflow process that is running that then fails.

In order for the Workflow Recovery Manager to attempt recovery, there must be an instance of an active, running workflow process that fails if it is interrupted. Peruse the Active Workflow Processes list to make sure such a workflow is present.

Next, test the Workflow Recovery Manager.

To test the workflow recovery manager

1 Open a Telnet session connected to the Siebel Server, issue the command siebps, then make a note of the Process Id of the Siebel Server.

If you are using Windows, then use Windows Task Manager instead of Telnet.

2 Open a second Telnet session, then connect to the Server Manager prompt.

3 From the smgr> prompt, issue the following command to start the execution of the workflow:

Start task for comp wfprocmgr with processname = 'AutoRec_NN'

A new server task for the wfprocmgr component with the server task id is started.

4 From the first telnet session you opened, check whether the Inloop.txt file is generated.

Numeric values are added to the file over time.

5 Issue the following command to reset the Siebel Server:

Reset_server -e <enterprise> -M <server name>

This step causes the workflow process that you are monitoring to fail.

6 Restart the Siebel Server, then enter the siebps command as you did in Step 1.

The Siebel Server process is started again.

7 Connect back to the smgr> prompt, then issue the following command in order to resume execution of the workflow process from the point of failure:

smgr>start task for comp wfrecvmgr

A new server task for the Workflow Recovery Manager component is started with a new server task id.



250

8 From the Telnet session, enter the following command to check the contents of the file:

tail -f inloop.txt

Numeric values are added to the file until 2999 is reached.

9 Issue the following command to check the last value entered in the file:

outfile.txt

The last and only value in this file must be 3000.

10 Issue the following command:

list tasks for comp WfRecvMgr

Observe that there are now one or more server tasks in the list. These are server tasks that Workflow Recovery Manager performs in order to recover workflow processes that were interrupted when you reset the server in Step 5.

Recommended Techniques to Recover a Workflow ProcessIt is recommended that you perform the following techniques to recover a workflow process:

■ Modify the Allow Retry Flag property on the Siebel operation step and business service step in order to reduce the number of checkpoints, and thereby minimize run-time overhead. If the Recovery Manager cannot determine from which step the instance of a workflow process must recover, then the instance is marked for manual recovery. Recovery is performed by the Recovery Manager based on state information for the instance that is saved by the Workflow Engine. The state information is saved at recovery checkpoints. To optimize performance, the recovery checkpoints are determined by the Workflow Engine based on the nature of the step and the Allow Retry flag property on the step.

■ Break down a complex business service into a number of simpler business services, thereby making it easier to individually recover each smaller business service.

■ Use multiple recovery managers. Having multiple recovery managers provides a way to safeguard against system problems that are transient or permanent. For example, a situation can exist in an environment where the subnet in which the recovery manager resides is frequently down. However, it is typical for only one recovery manager to be present as long as the recovery manager itself can be automatically restarted upon server failure.

Recovering a Workflow ProcessIf the Workflow Process Manager server component fails, then the workflow process automatically resumes the interrupted instances for the workflow when the server restarts. Recovery is performed by the Recovery Manager based on state information for the instance that is saved by the Workflow engine. You can recover an interrupted workflow either automatically or manually.

Automatically Recovering the Instance of a Workflow Process If the Workflow Process Manager server component fails due to an event that occurs outside of the Workflow Process Manager server component, such as a server failure, then Siebel Workflow automatically resumes the interrupted instances of a workflow process when the server restarts.



For an instance that cannot be automatically recovered, you can manually recover the workflow process. For example, if the server fails in the middle of a Siebel operation to update a record, then the workflow is unable to determine if the Siebel operation finished. It might be necessary for you to manually make sure the update was finished before resuming execution of the workflow. In another case, if the Siebel operation queries a set of records, then even after the server fails, the workflow can be resumed automatically by requerying.

Automatic recovery of a workflow process applies to a workflow that runs in the server component. A workflow that runs on a local database cannot be recovered.

Manually Recovering the Instance of a Workflow ProcessYou can correct and resume the instance of a workflow process that encountered errors. For example, if the Communications Server is not available, then a workflow process that sends a notice through email includes a status of In Error. You can activate the Communication Server component, then resume the workflow.

To manually recover the instance of a workflow process

1 In the Siebel client, navigate to the Administration-Business Process screen, then the Workflow Instance Admin view.

Instances that are marked for manual recovery are recoverable from the Workflow Instance Admin view. For more information, see “Using the Workflow Instance Admin View” on page 228.

2 In the Related Instances list, choose an option from the applet menu, using values described in the following table.

If the Resume Instance menu items are not available, then see “Affect of Call Depth on the Resume Instance Menu Items” on page 252.

Menu Item Description

Resume Instance-Next Step The instance skips the current step of the workflow process, and evaluates the decision conditions that emanate from the current step in order to determine the next step to execute.

Resume Instance-Current Step The instance resumes from the current step of the workflow process. The current step is retried. If the current step is a sub process step, then a new instance of the subprocess is started.



252

Affect of Call Depth on the Resume Instance Menu ItemsAn instance of a workflow process can resume only if the Call Depth setting for the workflow is the highest among the related instances of the workflow. If the instance is part of a set of related instances, and if one or more of those other instances includes a higher Call Depth level, then Resume Instance-Next Step and Resume Instance-Current Step are disabled. For example, assume there are multiple related instances with Call Depth settings of level 0,1,2,3, and 4. Assume you choose the record with level 3. In this case, these Resume controls are disabled because level 3 is not the highest Call Depth level that is set among the related instances.

Administering a Workflow Process ■ About Upgrading a Workflow Process


About Upgrading a Workflow ProcessThis topic describes upgrading Siebel Workflow from earlier versions.

Siebel Database Upgrade Guide is the primary source for upgrade information. For important upgrade information that pertains to workflow, such as Workflow Premerge, Repository Merge, Workflow Postmerge, and Logging, see Siebel Database Upgrade Guide.

Upgrades for the Runtime and Repository SchemaIf there are repository and run-time schema changes for the Siebel Workflow tables, or if new columns were added to the repository and run-time schema, then you must add the new columns to the Siebel database. Perform the instructions provided in Siebel Database Upgrade Guide.

An existing workflow process in the run-time deployment table is not changed during the upgrade. After the merge is finished, use the Workflow Deployment view in the Siebel client to reactivate finished workflows in order to load the new workflows into the run-time environment. For instructions on reactivating a workflow process, see Siebel Database Upgrade Guide.

Merge for Workflow ProcessesIf you upgraded to Siebel CRM version 7.7, then workflow processes were moved from the run-time tables into the repository tables. If you are upgrading to version 8.0 from version 7.7 or version 7.8, then a modified seed workflow or a custom workflow is merged into the version 8.0 repository during the repository merge process.

However, if you are upgrading to Siebel CRM version 8.0 directly from a version prior to version 7.7, then your custom workflows and modified seed workflows are copied over to the version 8.0 repository as is. You must manually merge your customizations with the new version 8.0 seed workflows.

In either case, make sure you review your workflow customizations after the repository merge process is completed. For more information, see “Examining Seed Workflow Processes” on page 111. For information about detailed merge algorithms, see Siebel Database Upgrade Guide.

Mode Requirements for an Upgraded Workflow Process If you modify a 7.0 workflow process that was upgraded to version 7.7 or later, then the mode for the workflow can remain the same.


Administering a Workflow Process ■ About Upgrading a Workflow Process

254


12 Examples of Defining a Workflow Process

This chapter describes examples on which you can model development efforts for your workflow process. It includes the following topics:

■ Example of Defining a Workflow Process That Creates an Activity for a Sales Representative on page 255

■ Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete on page 264

■ Example of Defining a Workflow Process That Attaches an Activity Plan to an Opportunity on page 281

■ Example of Defining a Workflow Process That Manages Research Activities for a Service Request on page 288

■ Example of Defining a Workflow Process That Manages Creation of a Service Request on page 292

■ Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the User on page 301

Example of Defining a Workflow Process That Creates an Activity for a Sales RepresentativeThis topic gives one example of using a workflow process to create an activity for a sales representative. You might use this feature differently, depending on your business model.

To develop this example, perform the following tasks:

1 Defining the Workflow Process on page 256

2 Testing the Workflow Process on page 262

3 Deploying and Verifying the Workflow Process on page 263

In this workflow process, if a user creates a new opportunity, then the revenue for the opportunity is evaluated. If the value of the opportunity is over $10,000, then an activity is generated that directs the sales representative to pursue the deal. The workflow is started by the WriteRecord run-time event.


Examples of Defining a Workflow Process ■ Example of Defining a Workflow Process That Creates an Activity for a Sales Representative

256

Defining the Workflow ProcessPerform the procedures in this topic to define the workflow process for this example. Make sure you perform the procedures in the order in which they are presented.

Defining the New Workflow ProcessYou begin by defining the new workflow process.

To define the new workflow process

1 In the Object Explorer in Siebel Tools, click Project.

2 In the Projects OBLE, define a new project named Workflow Examples.

3 Make sure the Locked property contains a checkmark.

For brevity, example workflow processes in this book use the Workflow Examples project. In a development environment, you can use a project that more closely meets your development requirements. For more information, see Using Siebel Tools.


For more information, see “About the Object Hierarchy of a Workflow Process” on page 39.

5 In the Workflow Processes OBLE, right-click, then choose New Record to define a new workflow process using values from the following table.

For more information, see “Properties of a Workflow Process” on page 445.


Adding Steps and Connectors to the Workflow ProcessThis topic describes how to add steps and connectors to the workflow process.

Property Value

Process Name Large Opportunity Creates Activity



Project Workflow Examples

Examples of Defining a Workflow Process ■ Example of Defining a Workflow ProcessThat Creates an Activity for a Sales Representative


To add steps and connectors to the workflow process

1 In the Workflow Processes OBLE, right-click the workflow you defined in “Defining the New Workflow Process” on page 256, then choose Edit Workflow Process.


.


3 Click the decision point, then use the Properties window to change the Name property to the value described in the following table.

The Properties window is context sensitive. If you click a step or connector in the Process Designer, then the properties for the step or connector are displayed in the Properties window. If the Properties window is not visible, then right-click a step, and choose View Properties Window.

4 Clicking each remaining step in succession, use the Properties window to change the Name property for each step according to values described in the following table.

Property Value

Name Is Opportunity Over 10k?

Step Type Name Property

Siebel Operation Insert Activity to Follow Up

End End



258

5 Clicking each connector in succession, use the Properties window to change the Name property for the connector according to values described in the following table.

TIP: The connector that emanates from the start step defaults to the name Connector 0. To suppress the text label for a connector, right-click the connector, choose the Edit menu, then the Hide Text menu item.


Next, define properties and arguments for workflow process steps.

Defining Properties and Arguments for Steps of the Workflow ProcessIn this topic, you define properties and arguments for workflow process steps.

To define properties and arguments for steps of the workflow process

1 Click the Insert Activity to Follow Up step, then use the Properties window to set properties using values from the following table.

2 Make sure the Insert Activity to Follow Up step is still chosen in the Process Designer.

3 Add an input argument in the MVPW using values from the following table.


You must first define the Field Name, then the Value.

4 Add a second process property using values from the following table.

Connector Name Property

Between the start step and the decision point Evaluate Oppty

Between the decision point and the Siebel operation Yes

Between the decision point and the end step No

Property Value

Business Component Action

Operation Insert

Field Name Type Value

Description Literal This is a large opportunity. Please call the customer ASAP.


Type Literal To Do



Defining the Run-Time Event That Starts the Workflow ProcessIn this topic, you define the run-time event that starts the workflow process.

To define the run-time event that starts the workflow process

1 Choose the No connector, then use the Properties window to make sure the Type property is set to Default.

2 Choose the Yes connector, then set the Type property to Condition.

3 In the Process Designer, click the Evaluate Oppty connector, then use the properties window to define values described in the following table.

When defining these properties, enter them in the top to bottom order that is displayed in the table. Because Event Object and Event are context sensitive, based on the value entered in Event Object Type, you must define Event Object Type first.

The business scenario dictates that if the revenue for an opportunity is greater than $10,000, then an activity is inserted in the Activities view that directs the sales representative to pursue the opportunity with the customer. You use a decision condition on the decision point to implement this logic.

Next, define the decision condition for the workflow process.

Defining a Decision Condition for the Decision Pointin this topic, you define a decision condition for the decision point.

To define a decision condition for the decision point

1 In the Process Designer, right-click the Yes connector, then choose Edit Conditions.

The Compose Condition Criteria dialog box displays. A decision condition can be defined for a connector that emanates out of a start step, decision point, wait step, or user interact step. A decision condition is defined on the connector that emanates from a step. It is not defined directly on a step.

Property Value


Event Object Opportunity

Event WriteRecord

Type Default



260

2 In the Compare To dropdown picklist, choose Business Component.

The Compare To picklist is used to indicate whether an object, expression, or process property is used in the comparison. In this example, the comparison is made against the run-time value of a field from the Opportunity business component, as defined in the Object picklist. The items in the Object picklist are context sensitive. They change based on the value chosen in the Compare To picklist.

3 In the Object dropdown picklist, choose Opportunity.

4 In the Operation dropdown picklist, choose Greater Than.

In this example, if the value defined in the Values window of the Compose Condition Criteria dialog box is greater than the run-time value of the Revenue field for the business component, then the Operation picklist defines the decision condition that applies. The Revenue field is defined in the Field window.

5 In the Field window, choose Revenue.

6 In the Values window, click New to add a new value.

7 In the Add Value dialog box, type 10000, then click OK.



8 In the Compose Condition Criteria dialog box, click Add.

The decision condition you defined in the lower portion of the Compose Condition Criteria dialog box is added to the Conditions list in the upper portion of the dialog. At this point, you can add another decision condition. For this example, you only add a single decision condition.

The decision condition you set in the Compose Condition Criteria dialog box must resemble the condition illustrated in the following figure:

At run time, if the Revenue field on an opportunity is greater than 10000, then the Yes branch is pursued. Otherwise, the No branch is pursued.

9 Click OK.


Modifications you can perform after defining a decision condition include:

■ To update a condition, click the condition in the Conditions window of the Compose Condition Criteria dialog box, modify the condition, then click Update.

■ To delete a condition, click the condition in the Conditions window of the Compose Condition Criteria dialog box, then click Delete.


Next, test the workflow process.



262

Testing the Workflow ProcessIn this topic, you test the workflow process you defined in “Defining the Workflow Process” on page 256.

You must prepare this example to test the workflow process by creating an opportunity that matches the test criteria. You create this opportunity, and note the row ID for the opportunity. This row ID is then used in the properties for the workflow process in order to run the test.

Preparing This Example For TestingThis topic describes how to prepare this example for testing.

To prepare this example for testing

1 Validate the workflow process.

For more information, see “Validate Tool” on page 197.

2 Log in to the Siebel client, then navigate to the Opportunities list.

3 Add an opportunity using values from the following table.

4 Right-click the record you created in Step 3, then choose About Record.

5 Note the value of the row Id in the Row # field.

6 In Siebel Tools, in the Process Designer, click the canvas, making sure no workflow process step or connector is chosen.

If you click an empty space in the canvas, then the Multi Value Property Window (MVPW) displays the process properties for the workflow process.

7 In the MVPW, find the Object Id process property, then set the Default String field for the property to the Row Id for the opportunity you identified in Step 5.

Next, simulate the workflow process, then examine simulation results.

Simulating the Workflow ProcessThis topic describes how to simulate the workflow process then examine simulation results.

To simulate the workflow process

1 Use the Process Simulator to step through the entire workflow process.


2 In the Siebel client, navigate to the Opportunities screen.

Name Revenue

Large Opportunity to Test Workflow $400,000



3 In the Opportunities list, drill down on the opportunity named Large Opportunity to Test Workflow.

4 Click the Activities view tab.

A new Activity must be present, and it must contain the description you defined in “Defining Properties and Arguments for Steps of the Workflow Process” on page 258. If so, the simulation for the workflow process finishes successfully.

5 Remove the modifications you made for testing:

a In Siebel Tools, close the Simulator.

b In the WF Process Props OBLE, choose the Object Id process property for your workflow process.

c In the Properties window, delete the row ID in the Default String property.

d In the WF Process Props OBLE, step off the record to save your changes.

Deploying and Verifying the Workflow ProcessIf you finish a successful simulation of your workflow process, then you are ready to deploy it, and to verify that the workflow implements the required functionality.

To deploy and verify the workflow process

1 Deploy the workflow process:

a In the Siebel client, navigate to the Administration-Business Process screen, then the Workflow Deployment view.

b In the Repository Workflow Processes list, query the Name field for Large Opportunity Creates Activity.

c Click Activate.

d In the Active Workflow Processes list, query the Name field for Large Opportunity Creates Activity.

The record displays a status of Active. For more information, see “Process of Deploying a Workflow Process” on page 211.


2 In the Siebel client, add a new opportunity that includes a Revenue that is greater than $10,000.

3 Step off the record, return to the record, drill down on the name of the record, then verify that an activity associated with the opportunity is automatically added, and that it includes the custom description you defined earlier in this example.

If you must modify the workflow process, then use the Revise feature on the WF/Task Editor toolbar in Siebel Tools. For more information, see “About the Process Property” on page 47.


Examples of Defining a Workflow Process ■ Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete

264

Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are ObsoleteThis topic gives one example of using a workflow process to traverse a record set in order to close obsolete service requests. You might use this feature differently, depending on your business model.


1 Defining the New Business Component on page 264



4 Preparing the Workflow Process for Production on page 279

This example identifies, then closes obsolete service requests. If a service request is more than one year old with a Status that is not Closed or Cancelled, then the service request is considered obsolete. The workflow process identifies obsolete service requests, then traverses the resulting record set, changing the Status for each obsolete service request to Cancelled, the Sub-Status to Resolved, the Close Date to the current date, and adds a message to the Description that indicates the SR was cancelled due to obsolescence.

For more information about the technique used in this example, see “How the Siebel Operation Step Is Used to Traverse a Record Set” on page 79.

Defining the New Business ComponentSome requirements for this workflow process include:

■ The workflow process must process a record from the primary business component of the business object on which the workflow process is based.

■ A looping workflow process that processes a batch of records can loop only through the records of a non primary business component. This non primary business component must be based on the same business object that is defined for the workflow process. In this example, that business object is Service Request.

■ The non primary business component must be established as a child of the business object for the primary business component.

The Service Request business component is the primary business component of the Service Request business object. To satisfy these requirements, you define a new, non primary business component named Service Request No Link. This new business component is a child of the primary Service Request business component.

The child business component contains the minimum number of fields required by this business case, and those fields point to the same table columns as their counterpart fields in the primary business component. Thus, if a field is modified in the child, then the same field is modified in the primary business component. Both the primary and the child business component modify the same business component record.

Examples of Defining a Workflow Process ■ Example of Defining a Workflow ProcessThat Traverses a Record Set to Close Service Requests That Are Obsolete


A relationship must be established between the child and the business object for the primary business component. To establish this relationship, the child is defined as a Business Object Component on the Business Object for the primary business component.

Defining the Child Business ComponentTo define the new business component, you begin by defining the child business component.

To define the child business component

1 In the Object Explorer, click Business Component.

2 In the Business Component OBLE, right-click, then choose New Record.

3 Define properties for the new business component using values from the following table.

4 Make sure Service Request No Link is chosen in the Business Components OBLE.

5 In the Object Explorer, expand the Business Component tree, then click Field.

6 In the Field OBLE, right-click, then choose New Record to add fields to the Service Request No Link business component. Add four new fields using values in the following table.

Fields in the child business component correspond to fields with the same name in the primary business component. Because a field on the child references the same table and column as the counterpart for the field on the primary business component, the field modifies the same record. Because Created is a system field, it is not explicitly defined as a field on the primary business component, and is therefore not defined on the child.

TIP: To reduce the number keystrokes you must perform, define the Column property first. When you define the Column property, then step out of the Column field in the OBLE, the Text Length and Type properties automatically populate.

Property Value

Name Service Request No Link

Project Workflow Examples

Class CSSBCBase

Table S_SRV_REQ

Name Column Text Length Type

Status SR_STAT_ID 30 DTYPE_TEXT

Sub-Status SR_SUB_STAT_ID 30 DTYPE_TEXT

Closed Date ACT_CLOSE_DT (leave empty) DTYPE_UTCDATETIME

Description DESC_TEXT 2,000 DTYPE_TEXT



266

Next, establish a relationship between the child and the Business Object for the primary business component.

Establishing a Relationship Between the Child and the Business Object for the PrimaryIn this topic, you establish a relationship between the child and the business object for the primary.

To establish a relationship between the child and the business object for the primary

1 If necessary, expose the Business Object Component object type, which is a child of the Business Object object type.


2 In the Object Explorer, click Project.

3 In the Project OBLE, query the Name property for Service.

4 Make sure the Locked property for the Service project contains a check mark.

5 In the Object Explorer, click Business Object.

6 In the Business Objects OBLE, query the Name property for the Service Request business object.

7 In the Object Explorer, expand the Business Object tree, then click Business Object Component.

8 In the Business Object Components OBLE, right-click, then choose New Record.

9 Set the Bus Comp property to Service Request No Link. Do not define a link.

10 From the Tools application-level menu, choose the Tools menu, then the Compile Projects menu item.

11 Choose Locked Projects, then compile to the repository that is used by your sample database.

This is typically [Siebel client root directory]\OBJECTS\[language]\siebel.srf.

Defining the Workflow ProcessWork that this workflow process performs include:

■ Accepts a record of the Service Request business component. This record is not processed.

■ Identifies obsolete service requests by querying the Service Request No Link business component for records whose Created date is more than one year old and whose Status is not Closed or Cancelled.

■ Traverses records in the query result set, modifying the Status, Sub-Status, Close Date and Description fields to reflect the obsolete status of the record.



To define the workflow process




The two business service steps allows you to use the Watch window to debug the workflow. These are removed near then end of the configuration instructions for this example.



Property Value

Process Name Close Obsolete SRs





268

4 Add seven new process properties using values from the following table.

The first four process properties in the table are SR Close Date, SR Created Date, SR Description and SR Status. These properties provide a basis for using the Watch window in this example. They are not required to use the traverse record set technique. The last three records in the table are noRecord, numAcceptedRecords, and vRowId. These properties are required to use the traverse record set technique. For more information, see “About the Process Property” on page 47.

TIP: To simplify defining a process property, define a process property, then fully define fields for it. Right-click this process property, then choose Copy Record. A copy of the process property is created with the same values as the original process property. For the copy, modify only those fields that require modification from the original.


Next, define the Query Primary workflow step.

To define the query primary workflow stepClick the Query Primary workflow step, then use the Properties window to define values described in the following table.

Next, define the Query Child workflow step.

To define the query child workflow step

1 Click the Query Child workflow step.

Name In/Out Business Object Data Type

SR Close Date In/Out Service Request String

SR Created Date In/Out Service Request String

SR Description In/Out Service Request String

SR Status In/Out Service Request String

noRecord None Service Request String

numAcceptedRecords None Service Request Number

vRowId None Service Request Number

Property Value

Business Component Service Request

Operation Query



2 Use the Properties window to define values described in the following table.

3 Make sure the Query Child workflow step is still chosen in the Process Designer.

4 Click the MVPW, then click the Search Spec Input Arguments tab. Add a new record using values from the following table.

Enter the argument for the Search Specification exactly as displayed in the table. The entire specification must be enclosed within double quotes. Each search string must be enclosed with single quotes. A space is required before and after operators, such as the equal sign (=) and the not equal to sign (<>).

5 Click the Output Arguments tab. Add a new record using values from the following table.

The Query operation uses NumAffRows as a container to hold the total number of rows that are returned from the query. In this example, the value in NumAffRows is stored in NumAcceptedRecords, a process property, which makes the value available later in the workflow on the Yes connector in order to trap for the case where no records are returned in the query.

Property Value

Business Component Service Request No Link

Operation Query

Field Value

Expression Business Component Service Request No Link

Filter Business Component Service Request No Link

Search Specification "([Created] < Timestamp()-365.0) AND ([Description] = 'Test SR') AND ([Status] <> 'Closed') AND ([Status] <> 'Cancelled')"

Field Value

Property Name NumAcceptedRecords

Type Output Argument

Output Argument: NumAffRows



270

6 Add a new output argument using values from the following table.

You initialize noRecord at this point in preparation for the Yes connector that resides downstream of the decision point. If one or more records are returned in the query, then the Yes decision condition uses the value in noRecord to check for the end of the record set that is processed by the Read Next Record step.

7 Add a new output argument using values from the following table.

VRowId provides a way to display the record number in the Watch window while the workflow processes each record in the record set. It is used for debugging purposes in this example. The traversing a record set technique does not mandate this variable.

Next, define a decision condition for the decision point.

To define a decision condition for the decision point

1 Click the Yes connector.

2 In the Properties window , set the Type property to Condition.

3 Right-click the Yes connector, then choose Edit Conditions.

Argument Value

Property Name noRecord

Type Literal

Value false

Argument Value

Property Name vRowId

Type Business Component

Business Component Name Service Request No Link

Business Component Field Id



4 Define the following decision condition, then click Add:

This decision condition traps for the instance where no records are returned from the query. If this condition is met, then the workflow process pursues the No connector.

5 Define the following decision condition, then click Add:

This decision condition determines when the workflow reaches the end of the record set in cases where at least one record is returned in the query. For more information, see “Defining a Decision Condition on a Branch Connector” on page 95.

6 Click OK.

7 Click the No connector. Make sure the Type property in the Properties window is set to Default.

Next, define the Watch Pre-update Values workflow step.

To define the watch pre-update values workflow step

1 Click the Watch Pre-update Values workflow step.


The Workflow Utilities business service provides a way to view variables in the Watch window. For more information, see “Workflow Utilities Business Service” on page 487.

Property Value

Compare To Process Property

Operation Greater Than

Object NumAcceptedRecords

Value 0

Property Value

Compare To Process Property

Operation All Must Match (Ignore Case)

Object noRecord

Value false

Property Value

Business Service Name Workflow Utilities

Business Service Method Echo



272

3 In the MVPW, click the Output Arguments tab. Add four new output arguments using values from the following table.

This workflow step provides data that the Workflow Utility business service uses in order to display field values for the record of the business component that is currently processed. These values are displayed in the Watch window. Values that are displayed reflect their state prior to updating.

Depending on your testing requirements, you can display more descriptive record data, such as data from the Abstract field. To display other record data, define another Field, similar as you did with fields described in Step 6 on page 265. In the workflow process, define a process property that references that field, then add an Output Argument on the Workflow Utility business service that references the new process property.

Next, define the Update Fields workflow step.

To define the update fields workflow step

1 Click the Update Fields workflow step.


3 In the MVPW, click the Field Input Arguments tab. Add three new input arguments using values from the following table.

Next, define the Watch Post-update Values workflow step.

Property Name TypeBusiness Component Name

Business Component Field

SR Close Date Business Component Service Request No Link Closed Date

SR Description Business Component Service Request No Link Description

SR Created Date Business Component Service Request No Link Created

SR Status Business Component Service Request No Link Status

Property Value


Operation Update


Closed Date Expression Timestamp()

Description Literal This SR's Status set to Cancelled due to this SR's obsolescence

Status Literal Cancelled



To define the watch post-update values workflow step

1 Click the Watch Post-update Values workflow step.


3 In the MVPW, click the Output Arguments tab. Add four new output arguments using values from the following table.

Next, define the Read Next Record workflow step.

To define the read next record workflow step

1 Click the Read Next Record workflow step.


3 In the MVPW, click the Output Arguments tab, then add a new output argument using values from the following table.

Property Value


Business Service Method Echo

Property Name TypeBusiness Component Name


SR Close Date Business Component Service Request No Link Closed Date

SR Description Business Component Service Request No Link Description

SR Created Date Business Component Service Request No Link Created

SR Status Business Component Service Request No Link Status

Property Value


Operation NextRecord

Field Value

Property Name noRecord


Output Argument NoMoreRecords



274

4 Add a second argument using values from the following table.

5 From the Tools application-level menu, choose the File menu, then the Save menu item.

Next, you use the Process Simulator and Watch window to test the workflow.

Testing the Workflow ProcessIn this example, you first modify several service requests by using the Siebel client in order to delineate a set of test records that the workflow process traverses. Then, you use the Process Simulator and Watch window to test the workflow process.

For more information, see “Using the Watch Window” on page 199.

CAUTION: Although you are simulating the workflow process, the Update Fields step in this workflow process modifies records in the query results. It is important to remain cognizant of the fact that the traversing a record set technique processes a set of real records. If a step in the workflow modifies records, then the values for most if not every record in the database that meet the search criteria is modified.

Preparing Test Records for the Service RequestsIn this topic, you prepare test records for the service requests.

To prepare test records for the service requests

1 Log in to the Siebel client, connected to the Sample database.

2 Navigate to the Service Requests screen, then the Service Request List view.

3 Locate three records that contain an Opened date that is more than one year from the date that the workflow process is tested. For example, if you test the workflow on February 15, 2009, then make sure the Opened date for each service request is prior to February 15, 2008.

Field Value

Property Name vRowId


Business Component Name Service Request No Link

Business Component Field Id



4 Modify the three records so that there are three service requests in the database that contain a Description of Test SR, and that one request is Open, one Closed, and one Cancelled. Use the values described in the following table.

These modifications provide a way to test the workflow process on a small, constricted set of records.

5 Create a new service request. Set Status to Open and enter Test SR in the Description.

6 Log out of the Siebel client.

Next, validate and simulate the workflow process.

Validating and Simulating the Workflow ProcessIn this topic, you validate and simulate the workflow process.

To validate and simulate the workflow process

1 Validate the workflow process.

For more information, see “Validating the Workflow Process” on page 202.

2 In Siebel Tools, right-click the canvas of the Process Designer, then choose Simulate.


3 Click Start Simulation. Wait for the Siebel client to launch, control to return to Siebel Tools, and for the simulator to automatically highlight the Query Primary workflow process step.

For caution information, see “Testing the Workflow Process” on page 274.

4 From the Tools application-level menu, choose the View menu, Debug Windows, then the Watch menu item.

5 Click the push pin to dock the window.

You must initiate the simulation, as described Step 3, prior to opening the Watch window.

Status Description

Open Test SR

Closed Test SR

Cancelled Test SR



276

6 Click the expand icon located next to PS:Property Set, then expand the Process Properties entry in the Property Set list.

Process properties that are defined for this workflow process are displayed along with the current value for each property. To check this list, stop the simulation, then compare the list of properties in the Watch window to the list of records in the MVPW.

No values are displayed in the Process Properties section of the Watch window until after the simulator calls the Workflow Utilities business service, which it does when the simulator executes the Watch Pre-update Values step.

7 Click Simulate Next, then expand the BusComp entry in the Watch window.

The simulator executes the Query Primary Step, then highlights the Query Child step. The Query Primary step performs an unrestricted query on the Service Request business component, returning every service request that exists in the database. The Watch window now displays a BusComp entry that contains a list of values for the current business component record.




The simulator executes the Query Child step, then highlights the More Records decision point.

The search specification on the Query Child workflow process step results in the creation of a record set that contains four service request records. In essence, Query Child populates the Service Request No Link business component with these metadata records.

In addition to several system variables, the Process Properties section of the Watch window now contains values for two process properties that reference important variables that are used with the traversing a record set technique, as described in the following table.

The BusComp section of the Watch window only displays record data from the query that was performed on the primary business component. This information does not change for the remainder of the simulation.


The simulator executes the logic that is associated with the More Records decision point, then highlights the Watch Pre-update Values step. The Yes connector performs two tests to determine if flow continues or halts. A value of 0 in NumAcceptedRows indicates no records matched the search specification on the Query Child workflow step. A value of true in noRecord indicates there are no more records to process in the record set. If either case is true, then the workflow process ends.

Because the value for NumAcceptedRecords is 1 and noRecord is false for the workflow in this example, the Yes connector is pursued.

Property Value Explanation

NumAcceptedRecords 1 NumAcceptedRecords is a process property that references NumAffRows, which is a variable that is used with the traversing a record set technique.

NumAffRows maintains a count of the number of rows that are returned from the query on the Query Child workflow step.

In this example, one record met the search specification defined on the Query Child step.

noRecord false noRecord is a process property that references NoMoreRecords, which is a variable that is used with the traversing a record set technique.

NoMoreRecords is a flag that indicates if records remain to be processed in the record set.

The NextRecord operation sets NoMoreRecords to true when there are no more records to traverse in the record set.

For every iteration through the record set, the NextRecord operation on the Read Next Record workflow step writes the value of NoMoreRecords to the noRecord process property.



278


The simulator executes the Watch Pre-update Values step, then highlights the Update Fields step.

Several values under the Process Properties entry in the Watch window populate when this step is executed. Four service request fields that are modified during the example were defined. Writing to the Watch window both before and after the Update Fields workflow step allows you to clearly determine if the fields of the business component are updated appropriately. The values are described in the following table.


The simulator executes the Update Fields workflow step, then highlights the Watch Post-update Values workflow step. Although the Update Fields workflow step updates three service request fields, changes to the values in those fields are not reflected until the workflow explicitly writes the updated information to the Watch window.


Property Value Explanation

SR Close Date (empty) Because the search specification on the Query Child workflow step excludes Closed records, the Close Date is empty.

SR Description Test SR Your test records include Test SR in the Description. This value is provided to make sure only those records in the test record set are evaluated.

SR Status Open The search specification on the Query Child workflow step excludes a Closed or Cancelled service request, but allows a service request that is Open, Pending, Field Visit, and Quoted. However, there is only one record in the resulting record set, with a value of Open.

noRecord false Although there is only one record in the record set, the NextRecord operation is not executed, so noRecord contains false.



The simulator executes the Watch Post-update Values workflow step, then highlights the Read Next Record workflow step. The Watch window displays the updated values for the record of the business component, as described in the following table.


The simulator executes the Read Next Record workflow step, then highlights the More Records decision point. In the Watch window, values for the process properties remain constant except for noRecord. Because there is only one record in the record set, the NextRecord operation sets noRecord to true.


The simulator executes the logic that is associated with the decision point, then highlights the end workflow step. Because this simulation modifies records in the record set, to run the simulation again you must first reset values that were changed in the record set. In this case, for the record that the workflow process modified, you must reset SR Description to SR Test, and reset Status to Open.

This example tests a small set of service request records. For a more thorough test, create more service request records that meet or do not meet the decision condition defined in the workflow process. Simulate the workflow again, using the Watch window to make sure the modifications accurately reflect the required outcomes for the workflow.

Preparing the Workflow Process for ProductionTo prepare the workflow process for a production environment, you can remove some of the configuration that is specific to supporting debugging activities.

CAUTION: The traversing a record set technique can potentially modify a large number of records in your database. To avoid unwanted modifications to numerous records, when using this technique make sure your workflow is fully tested and achieves the required results. In this example, removing the Description from the Search Specification broadens the search to consider and possibly modify every service request that is over one year old and is not Closed or Cancelled.

Property Value Description

SR Close Date 11/12/2007 14:21:04 Set by the Input Argument on the Update Fields process step.

SR Description The Status for this service request is set to Cancelled due to the obsolescence for the service request.

Set by the Input Argument on the Update Fields process step.

SR Status Cancelled Set by the Input Argument on the Update Fields process step.

noRecord false NextRecord operation is not executed, so noRecord still contains false.



280

To prepare the workflow process for production

1 Delete the Watch Pre-update Values and Watch Post-update Values workflow steps.

2 In the MVPW, you can delete SR Close Date, CR Created Date, SR Description, and SR Status.

3 Click the Query Child workflow step.

4 In the MVPW, click the Search Spec Input Arguments tab.

5 In the Search Specification, in the Description string, replace the search specification that was used for testing with the search specification that must be used for production, as described in the following table.

For caution information, see the caution at the beginning of this topic.

6 If required, restore your test records to their original data.

7 If you made modifications to the Service Request No Link business component, such as adding new fields, then compile your work again.

8 Identify, then implement a way to start the workflow process.

This example is based on maintenance administrative work that occurs on a regularly scheduled interval, such as daily, weekly or monthly. One way to start the workflow process is to configure a repeating component job for the Workflow Process Manager component. For more information on how to configure a component to run repeatedly at specific times over specific intervals, see “Usage of the Repeating Component Request” on page 173.

Search Specification Used for Testing Search Specification Used for Production

"([Created] < Timestamp()-365.0) AND ([Description] = 'Test SR') AND ([Status] <> 'Closed') AND ([Status] <> 'Cancelled')"

"([Created] < Timestamp()-365.0) AND ([Status] <> 'Closed') AND ([Status] <> 'Cancelled')"

Examples of Defining a Workflow Process ■ Example of Defining a Workflow ProcessThat Attaches an Activity Plan to an Opportunity


Example of Defining a Workflow Process That Attaches an Activity Plan to an OpportunityThis topic gives one example of using a workflow process to attach an activity plan to an opportunity. You might use this feature differently, depending on your business model.


1 Defining the New Workflow Process on page 281


3 Defining How the Workflow Process is Started on page 284

4 Deploying the Workflow Process on page 286

5 Verifying Functionality of the Workflow Process on page 287

In this example, you define a workflow process that creates an activity plan for an opportunity, then navigates the user to a view that displays the new plan. The workflow then waits for the user to enter more data and save changes before continuing. You use the Process Simulator and the Siebel client to test the workflow.

Defining the New Workflow ProcessTo begin, you define the new workflow process, define step properties, then validate the workflow.

To define the new workflow process



2 In the Workflow Processes OBLE, right-click the new workflow process, then choose Edit Workflow Process.

Property Value

Process Name Create Plan




Examples of Defining a Workflow Process ■ Example of Defining a Workflow Process That Attaches an Activity Plan to an Opportunity

282



Next, define properties of the workflow step.

To define properties of the workflow step

1 In the Process Designer, click the Add Activity Plan to Oppty step.

2 In the Properties window, define the business component and the operation by entering values described in the following table.

If you perform an Insert operation on a business component, then you must supply a value for fields that are required in the business component. In particular, to insert a new activity plan, you must provide the name of the template for the activity plan.

3 Make sure the Add Activity Plan to Oppty workflow step is still chosen in the Process Designer.

4 In the MVPW, add a new input argument using values from the following table.


5 In the Process Designer, choose the Display Activity Plan step.

Property Value

Business Component Activity Plan

Operation Insert


Template Literal A valid activity template name, such as Introductory Sales Call.



6 Use the Properties window to define which view is displayed for the Display Activity Plan user interact step. Use values described in the following table.

7 Click the connector located between the Display Activity Plan step and the end step, then define properties in the Properties window using values from the following table.

The run-time event signals the end of the Display Activity Plan user interact step, which is achieved by defining a conditional branch that emanates from the Display Activity Plan step. For this example, you must wait for the user to make and save a change to the Activity Plan before continuing the workflow process. WriteRecordUpdated is the run-time event that signals this change.

For the Event and Event Object picklists to populate correctly for this example, you must define the Event Object Type first.

Next, test the workflow process.

Testing the Workflow ProcessIn this topic, you validate, then simulate the workflow process you defined in “Defining the New Workflow Process” on page 281. Because this workflow is based on the Opportunity business object and the workflow attempts to add an activity plan to an existing opportunity, you must define the row Id for a specific opportunity in order to allow the Process Simulator to execute logic for the workflow.

Before you can test your workflow process, you create an opportunity that matches the test criteria. You create this opportunity, then note the row ID for the opportunity. This row ID is then used in the properties for the workflow process in order to run the test.

Preparing Example Data for the SimulationIn this topic, you prepare example data for the simulation.

To prepare example data for the simulation

1 Log in to the Siebel client as SADMIN connected to the Sample database.

Property Value

User Interact View Opportunity Activity Plan

Property Value


Event WriteRecordUpdated

Event Object Activity Plan

Type Condition



284

2 Navigate to the Opportunities list.

3 Choose an opportunity, right-click, then choose About Record.

4 Note the value of the row ID in the Row # field, then click OK to close the About Record dialog box.

5 In Siebel Tools, in the MVPW, find the Object Id process property, then set the Default String field for the property to the row Id of the opportunity you identified in Step 4.

If the MVPW is not visible, then, from the application-level menu, choose the View menu, Windows, then the Multi Value Property Window menu item.

Next, you validate, then simulate the workflow process.

Validating and Simulating the Workflow ProcessIn this topic, you validate, then simulate the workflow process.

To validate, then simulate the workflow process



After you reach the user interact step in the simulation, use the Siebel client to make a change to the Activity Plan, then save your changes. For example, change values in the Planned Start Date field or in the Description field.

You cannot reach the end step by clicking Next after the Opportunity Activity Plan view displays in the Siebel client. Because you defined a decision condition on the branch, you must satisfy the condition in order to allow the logic of the workflow to proceed to the end step.

2 Acknowledge the message that displays at the end of the workflow process.

When the last step is reached, the Siebel client displays a message reporting Simulation terminated! Please check the Watch window for details.

3 Enter Alt+Tab to return to Siebel Tools, then click Next to finish the end step.

4 In the Watch window, view the Simulator Status field.

If Simulation ended successfully displays, then the workflow process ended without error.

Next, you define how the workflow process is started.

Defining How the Workflow Process is StartedNow that you built and simulated a workflow process, you must decide where and how it is started from the user interface. For this example, you add a button to the Opportunity list to start the workflow. For more information, see “Starting a Workflow Process” on page 143.

To how the workflow process is started

1 In Siebel Tools, in the Object Explorer, click Applet.



2 In the Applets OBLE, query the Name property for Opportunity List Applet.

3 Right-click, then choose Edit Web Layout.

4 In the Controls/Columns window, set the Mode to 3: Edit List.

By default, Mode is set to 1: Base. You must set it to 3: Edit List. If the Controls/Columns window is not visible, then, from the application-level menu, choose the View menu, Windows, then the Controls Window menu item.

5 Drag a Button control from the palette to the layout, then set the properties for the control using values from the following table.

The value displayed in the table does not appear in the MethodInvoked picklist. You must manually enter the value for MethodInvoked.

Methods that use the naming format EventMethod[a string value] do not require an applet or script on a business component to allow the event. If you do not use this special naming convention, then you must write a WebApplet_PreCanInvokeMethod script to allow the event.

6 Preview the applet. Make sure the new Create Plan button displays as illustrated in the following figure:

7 Save the applet changes.

8 Compile your changes to the SRF in your Siebel client directory.

Next, define the workflow process that is started when the run-time event is detected.

To define the workflow process that is started when the run-time event is detected


Property Value

Caption-String Override Create Plans

HTML Type MiniButton

MethodInvoked EventMethodCreateActivityPlan



286

2 In the Workflow Processes OBLE, query the Process Name property for the Create Plan workflow process you defined in “Defining the New Workflow Process” on page 281.


4 Click the connector between the start step and the step named Add Activity Plan to Oppty, then use the Properties window to set properties for the connector using values from the following table.

This configuration supplies a start condition for the workflow process so that the workflow is started when EventMethodCreateActivityPlan occurs on the Opportunity List Applet.



Next, deploy the workflow process.

Deploying the Workflow ProcessBefore the new workflow process can be called in the Siebel client, you must deploy it.

To deploy the workflow process

1 Deploy the workflow process.


2 In the Active Workflow Processes list, set the Monitoring Level to 4-Debug.

3 Make sure you reload run-time events.

4 Make sure a run-time event was generated for this workflow process:

a Navigate to the Administration-Runtime Events screen, then the Events view.

b Query the Subevent for EventMethodCreateActivityPlan.

This technique starts the workflow process. One record must be returned.

Next, you verify the workflow process.

Property Value

Type Condition

Event Object Type Applet

Event Object Opportunity List Applet

Event PreInvokeMethod

Subevent EventMethodCreateActivityPlan

EventCancelFlag TRUE



Verifying Functionality of the Workflow ProcessIn this topic, you verify that the workflow process implements the required functionality.

To verify functionality of the workflow process

1 In the Siebel client, navigate to the Opportunities screen, then the All Opportunities view.

2 In the All Opportunities list, click Create Plan.

This step starts the workflow process for an opportunity. The workflow navigates you to the Opportunity Activity Plan view.

3 Edit the Description field for the plan, then save your changes.

4 Navigate to the Administration-Business Process screen, then the Workflow Instance Monitor view.

For more information, see “Monitoring Instances of a Workflow Process” on page 233.

5 In the Workflow Process list, query the Name field for the Create Plan workflow process.

The related instance data displays in the bottom list.

6 Choose the Step Instances tab to view step instance details.

If your workflow process runs without error, then you can turn off monitoring for the workflow.

To turn off monitoring for the workflow process


2 In the Active Workflow Processes list, query the name field for the workflow process named Create Plan.

3 Set the Monitoring Level field to 0-None.


Examples of Defining a Workflow Process ■ Example of Defining a Workflow Process That Manages Research Activities for a Service Request

288

Example of Defining a Workflow Process That Manages Research Activities for a Service RequestThis topic gives one example of using a workflow process to manage research activities for a service request. You might use this feature differently, depending on your business model.



2 Defining Logic for the Workflow Process on page 289

3 Testing and Deploying the Workflow Process on page 290

4 Verifying Functionality of the Workflow Process on page 290

In this example, a workflow process detects a service request being taken ownership of, then automatically creates an activity of type Research. The workflow then provides the SR owner with initial items that can be used in research. You define a simple workflow that is initiated by a run-time event. You become familiar with elements involved in setting up this workflow, and you see that the workflow process and the run-time event work.

Defining the Workflow ProcessThis topic describes how to define the workflow process.




Property Value

Process Name SR Assigned-Auto Create Activities


Group (Leave this field empty.)


Auto Persist No

Description Automatically generates a research activity when SR ownership change is detected by using RTE

Examples of Defining a Workflow Process ■ Example of Defining a Workflow ProcessThat Manages Research Activities for a Service Request




Next, define the workflow logic.

Defining Logic for the Workflow ProcessThis topic describes how to define the workflow logic.

To define logic for the workflow process

1 Click the SR Owner Field Updated connector.

2 In the Properties window, define properties for the connector using values from the following table.

3 Click the Create Research Activity step, then use the Properties window to define values described in the following table.

Next, define fields to populate when inserting a new business component record.

To define fields to populate when inserting a new business component record

1 Make sure the Create Research Activity step is chosen.

Property Value

Type Condition


Event SetFieldValue

Event Object Service Request

Subevent Owner

Property Value

Operation Insert

Business Component Action


Examples of Defining a Workflow Process ■ Example of Defining a Workflow Process That Manages Research Activities for a Service Request

290

2 Define two new input arguments using values from the following table.


If performing an insert into a business component, then make sure fields that are required in the business component are defined in this step. Alternatively, define a value in the Pre Default Value property for the fields of the business component. To access this property, expand the Business Component object type in the Object Explorer, then click the child Field object type.


Next, test and deploy the workflow process.

Testing and Deploying the Workflow ProcessIn this topic, you test and deploy the workflow process.

To test and deploy the workflow process



2 Navigate to the Workflow Processes OBLE.

3 Query the Process Name property for the SR Assigned-Auto Create Activities workflow process.



5 If you must debug the workflow process, then, in the Siebel client, in the Active Workflow Processes list, set the Monitoring Level to 4-Debug.

For more information, see “Diagnosing a Workflow Process That Has Failed” on page 240.

Next, verify workflow process functionality.

Verifying Functionality of the Workflow ProcessThis topic describes how to verify that the workflow process implements the required functionality.


1 In the Siebel client, navigate to the Service Requests screen, then the All Service Requests view.

2 Create a new service request, then step off the record.


Type Literal Research

Description Literal Research the following: Siebel Bookshelf

Examples of Defining a Workflow Process ■ Example of Defining a Workflow ProcessThat Manages Research Activities for a Service Request


3 In the Service Request list, click the hyperlink in the SR # field.

4 Examine the Activities tab.

If the workflow executes correctly, then values displayed in the Activities list include:

■ Type: Research

■ Description: Will research the following: Siebel Bookshelf


Examples of Defining a Workflow Process ■ Example of Defining a Workflow Process That Manages Creation of a Service Request

292

Example of Defining a Workflow Process That Manages Creation of a Service RequestThis topic gives one example of using a workflow process to manage service request creation. You might use this feature differently, depending on your business model.


1 Defining the Workflow Process on page 292.

2 Defining Connectors for the Workflow Process on page 293.

3 Defining Properties for the Siebel Operation Steps on page 296.

4 Testing, Deploying, and Verifying the Workflow Process on page 300.

In this example, work that the workflow process automatically performs include:

■ Detects when an end user creates a new service request

■ Assigns the new service request to the creator

■ Changes the SR Sub-Status to Assigned to reflect the ownership

■ Sets the commit time on the SR, depending on the priority

■ Creates an activity with a description of research steps that the SR owner can perform to resolve the SR

You define a simple workflow process that is initiated by a run-time event. You become familiar with elements involved in setting up this workflow process, and you observe how a workflow process works in conjunction with a run-time event to make several modifications to a service request.

Defining the Workflow ProcessIn this topic, you define the workflow process.

Examples of Defining a Workflow Process ■ Example of Defining a Workflow ProcessThat Manages Creation of a Service Request







Next, define the connectors for this workflow process.

Defining Connectors for the Workflow ProcessIn this topic, you define connectors for the workflow process.

Property Value

Process Name Manage New SR


Group (Leave this field empty.)


Auto Persist No

Description For new SRs, automatically modifies several SR fields. Considers SR priority during modifications.



294

To define the connectors for the workflow process

1 Click the Start Workflow connector, then use the Properties window to define properties using values from the following table.

This configuration starts the workflow process when a WriteRecordNew run-time event is detected on a service request.

2 Click each connector in succession that emanates from the decision point.

In the figure in Step 2 on page 293, these are labeled ASAP, High, Medium, and Low. As you click each connector, make sure the Type property in the Properties window is set to Condition.

3 Click the connector labeled Priority Not Set, then define properties using values from the following table.

4 Right-click the ASAP connector, then choose Edit Conditions.

5 In the Compose Condition Criteria dialog box, define the decision condition using values from the following table.

Decision conditions in this workflow process are defined for the ASAP, High, Medium and Low connectors. Each conditional statement corresponds to a Priority value. Depending on how each priority evaluates in the priority connector decision condition, the workflow adjusts the Commit Time in the subsequent Siebel operation step.


Property Value

Type Condition


Event WriteRecordNew


Property Value

Type Default

Property Value

Compare To Business Component


Object Service Request

Field Priority

Value 1-ASAP



6 Right-click the High connector, then choose Edit Conditions to access the Compose Condition Criteria dialog box.


8 Right-click the Medium connector, then choose Edit Conditions to access the Compose Condition Criteria dialog box.


10 Right-click the Low connector, then choose Edit Conditions to access the Compose Condition Criteria dialog box.

Property Value




Field Priority

Value 2-High

Property Value




Field Priority

Value 3-Medium



296


TIP: For clarity, in this example you are directed to define several connectors, placing them on the canvas consecutively. You can use an alternative technique when your workflow process contains multiple connectors, and where each of these connectors contain similar definitions. You can define a single branch connector, define the decision condition, then copy and paste this connector for use elsewhere in the workflow. You can then define the variance on each connector, in this case the Value. The Siebel operation steps in this workflow can also be defined using the same cut and paste technique.


13 Close the Process Designer.

Next, define properties for the Siebel operation steps.

Defining Properties for the Siebel Operation StepsIn this topic, you define properties for the Siebel operation steps.

To define properties for the Siebel operation steps


2 Click the Object Explorer tab, then scroll down to the Workflow Process entry in the Object Explorer Hierarchy window.

3 In the Object Explorer Hierarchy window of the Development Tools Options dialog box, expand the Workflow Process hierarchy, then expand the WF Step hierarchy.

4 Make sure there is a check mark next to the WF Step I/O Argument hierarchy, then click OK.

5 in the Workflow Processes OBLE, query the Process Name property for the Manage New SR workflow process.

6 In the Object Explorer, expand the Workflow Process tree, then click WF Step.

7 Right-click in the WF Steps OBLE, then choose Columns Displayed. Arrange columns to reflect the order displayed in the screen print in Step 8.

Property Value




Field Priority

Value 4-Low



8 Set the Business Component property and the Operation property for each of the Siebel operation steps in the workflow process. The resulting properties must resemble those displayed in the following figure:

Next, define input arguments for the Siebel operation steps that set the commit time.

Defining Input Arguments for the Siebel Operation Steps That Set the Commit TimeSome properties for a workflow process can be defined in the Process Designer or the Workflow Processes OBLE, depending on your personal preference. In this procedure, you use the Workflow Processes OBLE to define several properties for workflow steps. To define these properties by using the Process Designer, you use the Properties window.

To define input arguments for the Siebel operation steps that set the commit time

1 Locate the Manage New SR workflow process.


2 Right-click the Manage New SR workflow process, then choose Edit Workflow Process to open the Process Designer.

3 Click the Siebel operation step named Set Commit Time in 1 Hour.



298

4 In the MVPW, define three new input arguments using values from the following table.


These arguments provide instructions to the Siebel operation when the ASAP branch is satisfied. In this case, the Sub-Status field is set to Assigned, the Owner field is assigned to the value in Created By Name, and the Commit Time is set to one hour after the time that the SR was created.

Commit Time contains a Type property of DTYPE_UTCDATETIME, which is a datetime field. Created contains a time stamp of when the SR was created. When a number is entered in a datetime field, days are represented by integers and hours. Minutes and seconds are represented by fractions. For more information, see “Timestamp Usage” on page 188.

NOTE: The entire expression in the Value property for the Commit Time Field Input Argument must be enclosed in double quotes. A space must precede and follow the plus sign ( + ).

5 Click the Siebel operation step named Set Commit Time in 2 Hours.



Field Name Type Value Business Component Name


Sub-Status Literal Assigned (Leave this field empty.)

(Leave this field empty.)

Owner Business Component


Service Request Created By Name

Commit Time Expression [Created]+0.4166 (Leave this field empty.)









Commit Time Expression [Created]+0. (Leave this field empty.)







Next, define Input Arguments for the Siebel operation steps named Create Plan of Action.

To define input arguments for the create plan of action Siebel operation step

1 Click the Siebel operation step named Create Plan of Action.

This step creates an activity for the service request with a description that contains a set of actions the owner can follow.

2 In the MVPW, define two new input arguments using values from the following table.

3 Save your work, then close the Process Designer.

Next, you test, deploy, and verify the workflow process.








Commit Time Expression [Created]+24 (Leave this field empty.)









Commit Time Expression [Created]+48 (Leave this field empty.)



Type Literal Research

Comment Literal Plan of Action: 1. Make sure customer logged description. 2. Reproduce the behavior. 3. Request logs.



300

Testing, Deploying, and Verifying the Workflow ProcessIn this topic, you test and deploy the workflow process, then verify that the workflow implements the required functionality.






While performing the deploy procedure, make sure you reload run-time events.

Next, verify functionality of the workflow process.


1 In the Siebel client, navigate to the Service Requests screen, then the All Service Requests view.

2 Create a new service request.

3 Set a value for the Priority field, or leave it blank.

4 Save the record.

When you step off the record, notice that the Siebel client delays slightly and an hourglass displays, which indicates that the workflow process is executing.

5 Choose the service request you just saved, then examine the Owner, Substatus and Date Committed fields. Verify that they are populated correctly.

6 Click the Activities tab.

Notice that the new activity created by the workflow process displays.

7 Examine the Comments field to verify it is populated according to the input arguments you defined on the Siebel operation named Create Plan of Action.

8 Test out a few scenarios by creating service requests with different Priority values and observe how the workflow process decision point performs.

Examples of Defining a Workflow Process ■ Example of Defining a Workflow ProcessThat Manages Creation of a Service Request then Navigates the User


Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the UserThis topic gives one example of using a workflow process to manage the creation of a service request, then navigate the user to a view. You might use this feature differently, depending on your business model.


1 Modifying the Existing Workflow Process on page 301

2 Testing and Deploying the Workflow Process on page 303.

3 Verifying Functionality of the Workflow Process on page 303.

This example is similar to “Example of Defining a Workflow Process That Manages Creation of a Service Request” on page 292, with one addition. In this example, the workflow process automatically navigates the user to the Activities view of the Service Request screen, where the user can peruse newly created activities that are associated with the service request.

Modifying the Existing Workflow ProcessIn this topic, you copy and modify an existing workflow process.

To modify the existing workflow process

1 Log in to Siebel Tools as SADMIN connected to the sample database.


3 In the Workflow Processes OBLE, right-click the workflow process named Manage New SR, then choose Copy Record.

This example assumes you defined and tested the “Example of Defining a Workflow Process That Manages Creation of a Service Request” on page 292. In this example, you can use the Revise feature on the WF/Task Editor Toolbar instead of the copy feature. The Copy feature is used in this step in the event you must continue working on the Manage New SR workflow process at some point in the future without the additional modification defined in this procedure.

4 Set the properties for the new workflow process using values from the following table.

5 Right-click the workflow process named Manage New SR-Navigate User to SR Activity, then choose Edit Workflow Process to open the Process Designer.

Property Value

Process Name Manage New SR-Navigate User to SR Activity



Examples of Defining a Workflow Process ■ Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the User

302

6 Drag, then drop a User Interact step from the palette to the canvas, placing it between the Create Plan of Action step and the End step.

7 Add connectors between the Create Plan of Action step and the user interact step; and between the user interact step and the End step, as illustrated in the following figure:

8 Click the user interact step, then use the Properties window to set properties using values from the following table.

9 Confirm the value set for the User Interact View property:

a In the Siebel client, navigate to the Service Requests screen, then the All Service Requests view.

b Click the Activities view tab.

c From the application-level menu, choose the Help menu, then the About View menu item.

The required view name displays.

Property Value

Name Display SR Activities View

User Interact View Service Request Detail View

Examples of Defining a Workflow Process ■ Example of Defining a Workflow ProcessThat Manages Creation of a Service Request then Navigates the User


10 Click the connector that connects the user interact step with the end step, then use the Properties window to set properties using values from the following table.


Next, test and deploy the workflow process.

Testing and Deploying the Workflow ProcessThis topic describes how to test and deploy the workflow process.






Next, verify functionality of the workflow process.

Verifying Functionality of the Workflow ProcessThis topic describes how to verify that the workflow process implements the required functionality.



2 Deactivate previous workflow processes where the business object for the process is set to Service Request. This way, other workflow processes do not run or interfere with starting the workflow process that is used for this example:

a In the Active Workflow Processes list, query the Business Object field for Service Request.

b From the application-level menu, choose the Edit menu, then the Select All menu item.

c In the Active Workflow Processes list, click Menu, then choose Deactivate Process.

3 In the Repository Workflow Processes list, query the Name field for New SR-Take User to Activity.

4 Click Activate.

Property Value

Type Condition



Event WriteRecordUpdated


Examples of Defining a Workflow Process ■ Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the User

304

5 In the Active Workflow Processes list, query the Name field for New SR-Take User to Activity.

One row is returned for every version that is activated.

6 Make sure only the latest version is active.

7 Set the Monitoring Level to 4-Debug.

8 In the Repository Workflow Processes list, click Menu, then choose Reload Runtime Events.

9 Navigate to the Service Request list view.

10 Create a new service request, define a Priority level, then step off the record.

The application delays, displaying an hourglass. Then the Owner, Sub-Status, and Date Committed fields are populated, and a new activity is created that is associated with the new service request. Also, the application automatically navigates the user to the Activities view of the Service Request screen and displays the new activity.

11 Make sure that a process instance exists for New SR Created-Take User to Activity in the Workflow Process Log view.


13 Examples of Using a Business Service with a Workflow Process

This chapter describes examples of using a business service with a workflow process. It includes the following topics:

■ Examples of Using the Server Requests Business Service on page 305

■ Examples of Using the Outbound Communications Manager Business Service on page 309

■ Example of Externalizing Properties when Using a Business Service on page 316

Examples of Using the Server Requests Business ServiceThis topic describes examples of using the Server Requests business service. For more information, see “Server Requests Business Service” on page 482.

Example of Using the Server Requests Business Service to Start a Workflow Process from a ScriptThis topic gives one example of how to use the Server Requests business service to start a workflow process from a script and to pass field values to process properties. You might use this business service differently, depending on your business model. The following code can be used:

//Example: Passing Field Values to Process Properties and start workflow from script using the Server Request BS

//function Invoke_Process()

{

var svc = TheApplication().GetService("Workflow Process Manager(Server Request)");

var Input = TheApplication().NewPropertySet();

var Output = TheApplication().NewPropertySet();

var bo = TheApplication().ActiveBusObject();

var bc = bo.GetBusComp("Opportunity");

var rowId = bc.GetFieldValue("Id");

var accountId = bc.GetFieldValue("Account Id");

Input.SetProperty("ProcessName", "My Opportunity Process");


Examples of Using a Business Service with a Workflow Process ■ Examples of Using the Server Requests Business Service

306

Input.SetProperty("Object Id", rowId);

// Pass the value of the Account Id field to the Account Id process property

Input.SetProperty("Account Id", accountId);

svc.InvokeMethod("RunProcess", Input, Output);

}

Example of Using the Server Requests Business Service to Call EIMThis topic gives one example of how to use the Server Requests business service from within a workflow process to call EIM. You might use this business service differently, depending on your business model.

You can use a workflow process to start a server task. For example, you can start EIM to export base tables to IF tables or to load IF tables into base tables. The required component parameters that are specific for EIM must be passed in a child property set. You can use either a wrapper business service for EIM, such as the Synchronous Assignment Manager Requests business service, or you can use the Server Requests business service.

Because the Server Requests business service is designed to call a variety of server tasks, it does not contain definitions for parameters that are specific to a component. Instead, these parameters are passed down in a child property set which are not declared in the repository. To make Siebel Workflow pass values in a child property set, you use the dot notation of [type].[property]. In this example, because the Server Request Manager service does not care about the child type, but uses the first child, you pass every parameter in the same child, such as EIM.Config.

To use the Server Requests business service to call EIM

1 In Siebel Tools, in the Workflow Processes OBLE, define a new workflow process with the values described in the following table.


Property Value

Process Name EIM Export to IF (Tools)

Business Object Account


Examples of Using a Business Service with a Workflow Process ■ Examples of Usingthe Server Requests Business Service


2 Open the Process Designer for the workflow process you defined in Step 1, then define a workflow that resembles the workflow in the following figure:


3 Click the Export EIM workflow step, then use the Properties window to define values described in the following table.

4 Make sure the Export EIM workflow step is still chosen in the Process Designer.

5 In the MVPW, add a new input argument using values from the following table.


6 Add another input argument to the Export EIM workflow step using values from the following table.

Property Value

Business Service Name Synchronous Server Requests

Business Service Method SubmitRequest

Field Value

Input Argument Component


Value EIM

Field Value

Input Argument EIM.Config


Value accnt.ifb


Examples of Using a Business Service with a Workflow Process ■ Examples of Using the Server Requests Business Service

308

7 Make sure the Server section of the client .cfg file contains the configuration described in the following table.

8 To prepare the workflow process for testing, set up accnt.ifb in the Siebel_Server\Admin directory.



If the workflow executes successfully, then it finishes without errors. There is an EIM task log generated in the Server Tasks screen in the Siebel client each time you step through the Process Simulator.


After the workflow is Active, you can start it from a workflow policy, a script, or as a subprocess from another workflow process. For more information, see “Process of Deploying a Workflow Process” on page 211.

Variable Value

GatewayAddress Gateway_Machine_Name

EnterpriseServer Enterprise_Server_Name

RequestComponent SRMSynch

RequestServer Siebel_Server_Name

Examples of Using a Business Service with a Workflow Process ■ Examples of Usingthe Outbound Communications Manager Business Service


Examples of Using the Outbound Communications Manager Business ServiceThis topic includes the following topics:

■ Example of Defining a Substitution when Using the Outbound Communications Manager on page 309

■ Example of Using the Outbound Communications Manager to Send an Email to the Owner of a Product Defect on page 310

The Outbound Communications Manager business service can be used to send notifications through fax and email, such as notifications to contacts or employees. For more information on methods and arguments, see Siebel Communications Server Administration Guide.

Example of Defining a Substitution when Using the Outbound Communications ManagerThis topic gives one example of how to define a substitution variable when calling the Outbound Communications Manager business service from within a workflow process. You might use this business service differently, depending on your business model.

To define a substitution when using the Outbound Communications Manager





Property Value

Process Name Send SR Notification




Examples of Using a Business Service with a Workflow Process ■ Examples of Using the Outbound Communications Manager Business Service

310

3 Click the Send Notification business service step, then use the Properties window to define values described in the following table.

4 Make sure the Send Notification step is still chosen in the Process Designer.

5 Click the MVPW, then add a new input argument using values from the following table.


6 Add another input argument to the Send Notification step using values from the following table.




Example of Using the Outbound Communications Manager to Send an Email to the Owner of a Product DefectThis topic gives one example of using the Outbound Communications Manager to send an email to the owner of a product defect. You might use this feature differently, depending on your business model.

Property Value

Business Service Name Outbound Communications Manager

Business Service Method SendMessage

Input Argument Type Value

Business Component Name

MsgBody Expression "The Service Request Number" + [SR Number] + "was created with the abstract" + [SR Abstract]

Service Request


CommProfile Literal (Enter the appropriate profile. The profile must correspond with a profile that is displayed in the Profiles view of the Administration-Communications, All Configurations screen in the Siebel client. Type in the profile name exactly as it is displayed in the client.)




1 Defining the Custom Recipient Group on page 311

2 Defining the Product Defect and the Template for the Email Message on page 313

3 Defining a Workflow Process That Calls the Email Template on page 314

Defining the Custom Recipient GroupYou can use the Outbound Communications Manager to send an email to the owner of a product defect. This technique involves setting up a recipient group. To send an email to the owner of a Product Defect by using a workflow process, you begin by defining the custom recipient group for a product defect owner.

To define the custom recipient group for a product defect owner

1 In the Siebel client, navigate to the Administration-Data screen, then the List of Values view.

2 Define a new record using values from the following table.

3 Define a second record using values from the following table.

4 In Siebel Tools, from the application-level menu, choose the View menu, then the Options menu item.

5 Click the Object Explorer tab, expand the Applet tree, make sure the Applet Toggle object type contains a checkmark, then click OK.

6 Navigate to the Applets OBLE, then query the Name column for Comm Source List Applet.

7 From the application-level menu, choose the Edit menu, then the Copy Record menu item.

Property Value

Type COMM_RECIP_SRC

Display Value Product Defect

Language - Independent Code Product Defect

Parent LIC (Leave this field empty.)

Property Value

Type COMM_RECIP_SRC

Display Value Product Defect Owner

Language - Independent Code Comm Employee

Parent LIC Product Defect



312

8 Define properties using values from the following table.

9 In the Applets OBLE, query the Name column for Comm Source List Applet, right-click the record, then choose Lock Object.

10 In the Object Explorer, expand the Applet tree, click Applet Toggle, then add a new record in the Applet Toggles OBLE using values from the following table.

11 In the Object Explorer, click Link, then add a new record in the Links OBLE using values from the following table.

Make sure you define properties in the order in which they are listed in the table.

12 Navigate to the Business Objects OBLE, query the Name column for Comm Request, right-click the record, then choose Lock Object.

13 In the Object Explorer, expand the Business Object tree, click Business Object Component, then add a new record in the Business Object Components OBLE using values from the following table.

The work you performed thus far is required in order to define a custom recipient group for a product defect owner. For more information, see Siebel Communications Server Administration Guide.

Next, define the product defect and employee link.

Property Value

Name Comm Source Product Defect List Applet

Class CSSFrameListCommSrc

Property Value

Applet Comm Source Product Defect List Applet

Property Value

Name Comm Request/Product Defect

Parent Business Component Comm Request

Child Business Component Product Defect

Inter Table S_COMM_REQ_SRC

Inter Parent Column COMM_REQ_ID

Inter Child Column SRC_ROW_ID

Property Value

BusComp Product Defect

Link Comm Request/Product Defect



Defining the Product Defect and the Template for the Email MessageIn this topic, you define the product defect and template for the email message.

To define the product defect and comm employee link

1 In the Object Explorer, click Link, then add a new record in the Links OBLE using values from the following table.

2 Navigate to the Business Objects OBLE, query the Name column for Product Defect, right-click the record, then choose Lock Object.

3 In the Object Explorer, expand the Business Object tree, click Business Object Component, then add a new record in the Business Object Components OBLE using values from the following table.

4 Compile your changes.

Next, define a template that defines the email message that is sent.

To define a template that defines the email message

1 In the Siebel client, navigate to the Communications screen, then the My Templates view.

2 Add a new record using values from the following table.

3 Click the Advanced view tab, then set the Recipient Group property to Product Defect Owner.

Property Value

Name Product Defect/Comm Employee

Parent Business Component Product Defect

Child Business Component Comm Employee

Source Field Owned By Id

Destination Field Id

Property Value

BusComp Comm Employee

Link Product Defect/Comm Employee

Property Value

Name eMail Notification - Product Defect

Channel Type Email



314

4 Define other information in the Advanced form, as required.

For a detailed explanation of the available fields, see Siebel Communications Server Administration Guide.

Next, define a test workflow process that calls the template.

Defining a Workflow Process That Calls the Email TemplateTo finish the configuration, you define a workflow process that calls the email template.

To define a test workflow process that calls the template

1 In Siebel Tools, in the Workflow Processes OBLE, define a new workflow process with the following values:


2 Open the Process Designer for the workflow process you defined in Step 1, then define a workflow process that resembles the workflow in the following figure:


3 Click the Call Template step, then use the Properties window to define values described in the following table.

4 Make sure the Call Template step is still chosen in the Process Designer.

Property Value

Process Name Email Notification of Product Defect



Property Value

Business Service Name Outbound Communications Manager

Business Service Method CreateRequest





6 In the MVPW, define one more input argument using values from the following table.





PackageNameList Literal eMail Notification - Product Defect

RecipientGroup Literal Product Defect Owner

RequestName Literal Comm Request created by AP Send Updated CR Email


SourceIdList Process Property Object Id


Examples of Using a Business Service with a Workflow Process ■ Example of Externalizing Properties when Using a Business Service

316

Example of Externalizing Properties when Using a Business ServiceThis topic gives one example of how to externalize properties when using a business service. You might use this technique differently, depending on your business model.

This topic includes the following topics:

■ Overview of Externalizing Properties on page 316

■ Benefits of Using the Externalizing Properties Technique on page 317

■ Input Arguments of the EAI Business Service on page 317

■ Example of an XML Hierarchy on page 318

■ Example of an eScript on page 319

■ Maintaining the XML File on page 321

The purpose of this example is to provide a technique to externalize properties for Siebel Workflow so that a workflow process that uses a business service that interacts with an external system does not require a repository change when migrating a Siebel instance between development, test, and production environments.

Overview of Externalizing PropertiesA workflow process that uses a business service that requires interaction with an external system must be changed when the repository is migrated between development, test, and production environments. An example of this situation is EAI HTTP Transport business service, which requires the URL of the external system for the HTTPRequestURLTemplate input argument. The URL for the workflow that uses the EAI HTTP Transport business service points to the external URL for an integrated test system in the testing instance, and points to the URL for a production external system in the production instance.

Consider the following:

1 The technique that is used in this example stores, in a file, the input arguments of a business service that are used in a workflow process.

2 A script on the Service_PreInvokeMethod event of the business service step reads, from the file, the values of these substitutable input arguments of the business service that are used in the workflow process.

3 The script can set the Input Argument of the business service using values read from the file.

This technique results in the following:

■ The file that resides on an instance of the production server contains values for the external system that is used for production

■ The file that resides on an instance for the development and test server contains the values for the external system that is used for development and test

Therefore, values for input arguments are not hard coded for the service in the workflow process. Instead, the script on the Service_PreInvokeMethod Event method reads the file at run time.

Examples of Using a Business Service with a Workflow Process ■ Example ofExternalizing Properties when Using a Business Service


This technique relies on a file that has a particular name, and that is available for reading on each Siebel Server. Otherwise the business service fails and Siebel Workflow throws an error at that business service step, which is the required behavior.

For a business service where the script is added to the Service_PreInvokeMethod event, it is expected that an input argument named ExternalSystem is defined, and that the value for the argument matches the XML tag name of the child of the root element in the file.

This script sets the child elements of the parent that resides at the second level, that is, the child of the root element, of the file as input arguments.

Benefits of Using the Externalizing Properties TechniqueBenefits of using the externalizing properties technique for certain business services include:

■ Makes transparent the migration of repository workflow processes between development, test, and production Siebel instances. That is, workflows no longer require changes during migration between various Siebel instances.

■ Supports current business services as well as future requirements.

■ Supports usage scenarios of a business service that is used in various workflow processes.

■ Is easy to manage and reduces the total cost of ownership of operational aspects of running an instance of the Siebel server.

Input Arguments of the EAI Business ServiceThe EAI HTTP Transport and EAI SQL Adapter business services, when used in the workflow process as a business service step, contain input arguments that might require changes when migrating the repository between development, test, and production Siebel instances. Table 43 describes potential required changes.

Table 43. Input Arguments That Might Require Changes when Migrating Repository Data

Business ServiceBusiness Service Methods Business Service Method Input Arguments

EAI HTTP Transport Send

SendReceive

HTTPRequestURLTemplate

EAI SQL Adapter Query ExtDBODBCDataSource

ExtDBPassword

ExtDBTableOwner

ExtDBUserName



318

Assume that an instance of a Siebel server contains integration points with a third party HR and Finance system. To use the EAI HTTP Transport and EAI SQL Adapter business services, the input arguments listed in Table 43 must be supplied in the definition of the business service step for the workflow process where the business service is referenced.

Example of an XML HierarchyThe following is an arbitrary file for an XML Hierarchy that contains input arguments for the EAI HTTP Transport and EAI SQL Adapter business services, and their values. The parameters under Finance and HR are for illustration purposes only. The file is named ebizint.xml.

A number of parameters with appropriate values can be used. For a usage scenario of a business service, parameters that are not required do no harm. Also, this XML Hierarchy is arbitrary. The following hierarchy is for illustration purposes only:

<?xml version="1.0" encoding="UTF-8" ?>

<Systems>

<Finance>

<TargetWebAddress>http://finance</TargetWebAddress>

<ExtDBODBCDataSource>financesource</ExtDBODBCDataSource>

<ExtDBUserName>financeuser</ExtDBUserName>

<ExtDBPassword>financepassword</ExtDBPassword>

<ExtDBTableOwner>financeowner</ExtDBTableOwner>

</Finance>

<HR>

<TargetWebAddress>http://hr</TargetWebAddress>

<ExtDBODBCDataSource>hrsource</ExtDBODBCDataSource>

<ExtDBUserName>hruser</ExtDBUserName>

<ExtDBPassword>hrpassword</ExtDBPassword>

<ExtDBTableOwner>hrowner</ExtDBTableOwner>

</HR>

</Systems>



Example of an eScriptWith the structure of the example XML file displayed in “Example of an XML Hierarchy” on page 318, the following eScript code example can be added to the Service_PreInvokeMethod event of the EAI HTTP Transport and EAI SQL Adapter business services:


{

var ExtSystem, XMLReadSvc, XMLReadSvcInputs, XMLReadSvcOutputs;

var ExtSystemParent, Child

var errorStr;

try

{

XMLReadSvcInputs = TheApplication () .NewPropertySet ();

XMLReadSvcOutputs = TheApplication () .NewPropertySet ();

XMLReadSvcInputs.SetProperty("FileName”, “C:\\ebizint.xml”);

XMLReadSvcInputs.SetProperty("EscapeNames”, “false”);

XMLReadSvc = TheApplication () .GetService ("EAI XML Read from File”);

ExtSystem = inputs.GetProperty (“ExternalSystem”);

XMLReadSvc.InvokeMethod(“ReadXMLHier”, XMLReadSvcInputs, XMLReadSvcOutputs);

//ExtSystem = {“HR”, “Finance”, “HRSensitive”}

ExtSystemParent = XMLReadSvcOutputs.GetChild(0) .GetChild(0);

for (var i =0; i < ExtSystemParent.GetChildCount(); i++)

{

Child = ExtSystemParent.GetChild(i);

if (Child.GetType() == ExtSystem)

{

for (var j=0; j < Child.GetChildCount(); j++)

{

var ExtType = Child.GetChild(j) .GetType();

var ExtValue = Child.GetChild(j) .GetValue();



320

Inputs.SetProperty (ExtType, ExtValue);

}

}

}

}

catch (e)

{

errorStr = e.toString();

TheApplication () .Trace(errorStr);

TheApplication () .RaiseErrorText(errorStr);


}

finally

{

ExtSystem = null;

XMLReadSvc = null;

XMLReadSvcInputs = null;

XMLReadSvcOutputs = null;

ExtSystemParent = null;

Child = null;

errorStr = null;

}


}



Figure 22 displays an example usage of the EAI HTTP Transport business service, which includes the eScript code described in this topic that is defined in the Service_PreInvokeMethod event.

Maintaining the XML FileThere is no other ongoing maintenance required for ebizint.xml. If the values in the file change, then this file must be updated with the correct values on the Siebel Servers. An example change that requires an update to ebizint.xml is a change to the URL that points to the external system.

Figure 22. Example Usage of EAI HTTP Transport Business Service



322


14 Defining a Custom Workflow Policy

This chapter describes workflow policies. It includes the following topics:

■ About Workflow Policies on page 323

■ Process of Planning a Workflow Policy on page 332

■ Process of Defining a Workflow Policy on page 340

■ Examples of Defining Workflow Policy Configurations on page 349

■ Customizing Workflow Policy Objects on page 360

■ Conditions for a Workflow Policy on page 370

For more information, see Chapter 16, “Administering a Workflow Policy” and Appendix A, “Reference Materials for Siebel Workflow.”

About Workflow PoliciesThis topic includes the following topics:

■ Overview of Workflow Policy Objects on page 323

■ Structure of a Workflow Policy on page 327

■ Sequence of a Workflow Policy on page 330

■ Hierarchy of Workflow Policy Objects on page 331

You can use a workflow policy to start a workflow process. A policy consists of one or more workflow policy conditions. If the workflow policy conditions are met, then the workflow policy action is executed.

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.

Overview of Workflow Policy ObjectsWorkflow policy objects provide the context in which Workflow Policies operate. The workflow policy object, through the policy components for the workflow process, defines the set of tables and columns that are monitored by a policy and how each table in the workflow policy object relates to the other tables. This collection of columns and the relations between the tables of the workflow policy object represent the entity within Siebel Tools that you must monitor.


Defining a Custom Workflow Policy ■ About Workflow Policies

324

Siebel Tools provides visibility to many predefined workflow policy objects for common business requirements, such as opportunity, service request, and contact. You can modify some predefined workflow policy objects through administrative screens in the Siebel client. You can also use Tools to define a custom workflow policy object in order to meet your specific business requirement.

Relations Between Objects of a Workflow PolicyRelations between workflow policy objects, workflow policy columns, and workflow policy programs are illustrated in Figure 23.

Relations between workflow policy objects include:

1 Workflow Policy Object. A workflow policy object is a collection of workflow policy components. A workflow policy object is defined by the parent and child relationship for the workflow policy object to workflow policy components and workflow policy component columns.

Figure 23. Relations Between Workflow Policy Objects, Programs, and Columns



2 Workflow Policy Component. A workflow policy component is a logical mapping of a database table that defines the Siebel database tables that you can monitor. Workflow policy components define the relations between the primary workflow policy component and other policy components of a workflow policy object. Except for the primary workflow policy component, each workflow policy component defines a relation to another workflow policy component. This relation is defined by defining a source policy column and a target policy column. The source and target columns on a workflow policy component identify foreign key relations between the tables.

A primary workflow policy component is a workflow policy component to which other workflow policy components are directly or indirectly related. From these workflow policy components, the workflow policy columns that are available for monitoring in the workflow policy can be defined. Each workflow policy object contains only one primary workflow policy component. The other workflow policy components of a workflow policy object are directly or indirectly related to the primary workflow policy component.

3 Workflow Policy Component Column. A workflow policy component column defines the columns in the Siebel database table that you can monitor. You expose these columns for monitoring when you define workflow policy conditions for a workflow policy.

To define a workflow policy object and the components for a workflow process, familiarize yourself with the Siebel Data Model. For more information, see Siebel Data Model Reference. For information about tables and how tables are related, see Siebel Data Model Reference.

Viewing the Hierarchy Between Workflow Policy ObjectsEach workflow policy component can expose a number of workflow policy component columns. In the Object Explorer, a workflow policy component column is the child object of a workflow policy component, which is itself a child object of a workflow policy object. To view this hierarchy, see “Hierarchy of Workflow Policy Objects” on page 331.



326

Example of an Entity Relationship Diagram for a Workflow PolicyFigure 24 displays the entity relationship diagram of four workflow policy components for a service request. The diagram illustrates each of the components, their relations to one another, and the columns that are of interest. Service request is the primary workflow policy component, and the other three components are joined to it either directly or indirectly.

Table Monitoring with a Workflow PolicyA workflow policy can only monitor Siebel database tables. You cannot use a workflow policy to monitor a database table that is external to Siebel.

CAUTION: Do not monitor the S_DOCK_TXN_LOG table or table columns of Enterprise Integration Manager (EIM). An EIM table is prefixed with EIM_, or ends with _IF. Most tables can be monitored except S_DOCK_TXN_LOG and EIM tables.

Figure 24. Example of an Entity Relationship Diagram for a Workflow Policy



Structure of a Workflow PolicyA rule contains an IF/THEN structure that provides the basic underlying logic of a workflow policy. The structure of a rule is:

If the conditions are true, then an action occurs

The rule contains a workflow policy condition and a workflow policy action. If the conditions of the workflow policy are met, then an action is called. Figure 25 illustrates the parts of an example workflow policy.

Parts that make up a typical workflow policy include:

1 Workflow Policy. A workflow policy is composed of workflow policy conditions and workflow policy actions. A workflow policy, based on the structure of the workflow policies rule, represents rules that the database monitors.

2 Workflow Policy Condition. A workflow policy condition is called: a situation that causes something to happen.

3 Workflow Policy Action. A workflow policy action is an action that is called by fulfilling a workflow policy condition.

4 Workflow Policy Program. A workflow policy program is a predefined program that provides arguments for the workflow policy action.

5 Duration. A duration is the amount of time for which workflow policy conditions exist in order for the conditions of the policy to be met. For more information, see “Planning the Workflow Policy and Workflow Policy Conditions” on page 334.

NOTE: The functionality that is available with a workflow policy can be supported by using a workflow process. It is recommended that a workflow policy be used to start a workflow process. Use a workflow process to define an action.

Figure 25. Parts of an Example of a Workflow Policy



328

Workflow Policy ConditionA workflow policy condition is an object that expresses an object or the relation of an attribute to a value. For example, a workflow policy condition can target data, such as severity for a service request. The workflow policy condition compares severity data to a value, such as 1-Critical. The combination of the data element, service request severity, a comparison operation, such as the equal sign (=), and the value, such as 1-Critical, define the condition.

The fact that severity of a service request is 1-Critical can be an issue only if the workflow policy condition remains valid for some extended amount of time, such as two hours. In this example, if the condition remains valid, then a duration can be set for two hours on the workflow policy. The duration is part of the condition. The policy actions are not executed until the conditions are met for the defined duration.

A workflow policy action can also occur when a time duration is not set. For example, where email is automatically sent to a sales manager each time a sales representative quotes a discount rate that exceeds 25 percent on revenue that is less than $100,000.

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

SR Severity = 1-Critical AND SR Status = Open

A workflow policy only supports an AND linkage between workflow policy conditions. It does not support an OR linkage. If you must monitor the service request severity to be 1-Critical or 2-High and the status to be Open, then you can use the IN operand to evaluate the OR of the severity:

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

Alternatively, an OR linkage can be simulated by defining multiple workflow policies for each key workflow policy condition. The combination of workflow policies act similar to an OR linkage. For more information, see “Examples of Defining Workflow Policy Configurations” on page 349.

Workflow Policy ActionA workflow policy action is an event that occurs when the conditions of your workflow policy are met. The parts of a workflow policy action include:

■ An action, which is a type of request, such as Send an Urgent Page

■ The action parameters, which are the arguments, such as the name of the recipient of the page and the alphanumeric text that is transmitted with the page

You can define several actions for one workflow policy, such as sending a page to one person and an email to another person. You can reuse an action in multiple workflow policies. For more information, see “Customizing Workflow Policy Objects” on page 360.

NOTE: In most cases, you can use a workflow policy action to start a workflow process.

You can pass a constant from a workflow policy action into a workflow process. For more information, see “Passing a Constant from a Workflow Policy Action into a Workflow Process” on page 183.



Workflow Policy ProgramA workflow policy program is a predefined program that provides arguments for the workflow policy action. A workflow policy action is based on the underlying program in Siebel Tools and inherits the arguments for the program. A workflow policy program defines the particular action that executes when the conditions of a workflow policy are met. Most functionality included in a workflow policy program can be executed by using a workflow process.

You can use a workflow policy program in multiple actions and you can use actions in multiple workflow policies.

Types of workflow policy programs include:

■ Send Message. Sends an email to one or more recipients.

■ Send Page. Sends a page to one or more recipients.

■ Send Broadcast Message. Inserts a message broadcast for one or more recipients.

■ DB Operation. Inserts or updates the data records of a Siebel database table for chosen workflow policy components.

■ External Program. Allows you to run an executable.

■ Assignment Request. For internal use only.

■ Generic Request Server. Submits a server request to a designated server component.

For more information, see Properties of the Workflow Policy Program on page 475 and Properties of the Workflow Policy Program Argument on page 476.

Predefined Workflow Policy ProgramsWorkflow policies use workflow policy actions that are based on workflow policy programs that are predefined in Siebel Tools. Some examples include:

■ Send Broadcast Message

■ Database Operation

For more information, see “Types of Workflow Policy Programs That Are Predefined” on page 381.



330

Sequence of a Workflow PolicyA sequence of a typical workflow policy is illustrated in Figure 26.

A sequence of a typical workflow policy includes the following steps:

1 Detect End-User Activity or Server Process. An end-user activity or server process occurs.

2 Create Triggers. Workflow policies are enforced at the data layer through database triggers. If the conditions for a particular workflow policy are met, then the underlying database triggers capture the database event into Workflow Policy Manager.

3 Fire Triggers. The S_ESCL_REQ table is queued.

4 Read Records. The Workflow Monitor Agent, which is a component of the Workflow Policy Manager, reads records in the S_ESCL_REQ table, then processes requests by executing the actions that are defined.

5 Start. In some cases, an action can start the Workflow Process Manager.

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


■ Workflow Action Agent, see “Executing a Workflow Policy with the Workflow Action Agent” on page 415

■ Generate Triggers, Workflow Process Manager and Workflow Monitor Agent, see “Run-Time Architecture of a Workflow Process” on page 31

■ The S_ESCL_REQ table, see “Usage of the S_ESCL_REQ Table” on page 408

Figure 26. Sequence of a Typical Workflow Policy



Hierarchy of Workflow Policy ObjectsUsing Siebel Tools, you can modify an existing workflow policy and define a new workflow policy to meet your business requirements.

Figure 27 highlights the object types you can modify and the hierarchies that exist between them.


■ If necessary, you must expose workflow policy objects in the Object Explorer. For more information, see “Exposing Object Types That Are Used to Develop a Workflow Process” on page 116.

■ When you use Siebel Tools to modify or define a workflow policy object on your local system, the changes are not available on the server until after they are applied to the server.

For more information about hierarchies in the Object Explorer, and for background information about object types, object definitions, and properties, see “About the Object Hierarchy of a Workflow Process” on page 39.

Figure 27. Workflow Policy Object Type Hierarchy in the Object Explorer in Siebel Tools


Defining a Custom Workflow Policy ■ Process of Planning a Workflow Policy

332

Process of Planning a Workflow PolicyThis topic describes information about planning a workflow policy. To plan a workflow policy, perform the following tasks:

1 Planning a Workflow Policy Group on page 332

2 Planning a Workflow Policy on page 333

3 Planning Objects to Monitor with a Workflow Policy on page 334

4 Planning the Workflow Policy and Workflow Policy Conditions on page 334

5 Planning the Workflow Policy Action on page 335

6 Examining Workflow Policies and Workflow Policy Programs That Are Predefined on page 335

7 Planning a Test and Migration Strategy for a Workflow Policy on page 336

Examples in this topic ground the concepts presented. For more information, see “Examples of Planning a Workflow Policy” on page 336.

Before planning a workflow policy, you must determine the automation solution that most closely meets the automation requirements for your business . For more information, see “Identifying an Automation Solution” on page 101.

Planning a Workflow Policy GroupThis task is a step in “Process of Planning a Workflow Policy” on page 332.

Workflow policies are organized into groups. A workflow policy group is a collection of workflow policies that provide a means of identifying policies that contain similar system requirements, thus facilitating load balancing on the servers and scalability. A workflow policy group allows you to manage and optimize process performance for the Workflow Agent by grouping similar policies to run under one Workflow Agent process.

Before you define a workflow policy, you must define a workflow policy group. Each Workflow Policy Agent is assigned to one workflow policy group. If you run only one Workflow Policy Monitor Agent and one Workflow Policy Action Agent, then assign your policies to one policy group.

Reasons to use multiple Workflow Policy Agents include:

■ To shorten the lag time between when the policy event is called and when Workflow Policies notices the event

■ To spread the workload across multiple application servers

■ To adjust the polling interval so that polling for a noncritical policy does not prevent efficient processing of a critical policy

Policies with similar time intervals are generally grouped together. By defining groups of policies with similar time intervals, you can assign the workflow policy group to a Workflow Policy Agent that contains a polling rate that matches the requirements of the workflow policies, thereby more efficiently using your resources.



Defining workflow policy groups and using multiple Workflow Policy Agents are part of tuning your system in order to realize higher performance. This work can be performed while you monitor system performance.

NOTE: The maximum number of policies in a single policy group is MaxInt. The maximum number of policies in policy groups is determined by the maximum number of records in the S_ESCL_RULE table.

Planning a Workflow PolicyThis task is a step in “Process of Planning a Workflow Policy” on page 332.

Many of the workflow policy objects and programs you must define for your workflow policies come predefined. However, you can use Siebel Tools to augment programs, define more workflow policy objects, or make more workflow policy columns available for monitoring. The planning phase is an appropriate time to review business process activities for your company. You must determine the work that can be automated with a workflow policy, then prioritize the implementation sequence. For more information, see:

■ Process of Defining a Workflow Policy on page 340


Technique for Grouping PoliciesIt is recommended that you define and implement a small group of policies at a time. After you successfully implement the group, you can proceed to another small group of policies in a systematic manner. If the business environment necessitates changes to your plan, then a workflow policy can be assigned to a different group. For more information, see “Moving a Workflow Policy to a Different Group” on page 431.

Technique for Testing a PolicyAfter planning a new workflow policy, you can test the policy by issuing a query that is based on the policy. Then you can execute the query in your current production environment. The query response can help you determine the frequency of the workflow policy conditions. You might find that a policy generates excessive notification or insufficient visibility. For more information, see “Testing, Troubleshooting, and Migrating a Workflow Policy” on page 440.



334

Planning Objects to Monitor with a Workflow PolicyThis task is a step in “Process of Planning a Workflow Policy” on page 332.

You can develop a plan for what objects to monitor. For example, assume the service department must send an email to the contact for the service request when a service request is opened that contains a severity level of critical. Table 44 describes the information to monitor in this example.

Planning the Workflow Policy and Workflow Policy ConditionsThis task is a step in “Process of Planning a Workflow Policy” on page 332.

Develop a plan for the properties of the workflow policy and workflow policy conditions, identify the workflow policy object to be monitored in the Siebel database, and determine the period and duration for the monitoring interval.

Table 45 describes an example plan that details the type of information to model for the workflow policy.

Table 44. Example of Objects to Monitor

What to Monitor Purpose of the Policy

Service request status

Service request severity

Send an email to the contact of the service request when the service request is opened and the severity level for the service request is critical.

Table 45. Example of a Plan for the Workflow Policy

NameWorkflow Policy Object

Workflow Policy Group Duration

Email Confirmation of SR

Service Request

Medium Frequency

This value establishes the interval period for monitoring.

0 (zero)

Duration indicates the time that must elapse before an action is performed. Each workflow policy includes one duration. If you require an action to occur after one hour, two hours, and six hours, then you must define a different policy for each duration.



Table 46 describes an example plan for the workflow policy conditions that is identified after you determine the workflow object and other properties for your workflow policy.

The condition of a workflow policy includes an expression. The Condition Field is the table column that is monitored in the database. A value for the condition of a workflow policy is read directly from a picklist that is defined at the table column level. The value that is required by the operation for the condition that you define, such as IN and NOT IN, must be available in the column policy picklist. Otherwise, the workflow policy cannot call the workflow policy action.

Planning the Workflow Policy ActionThis task is a step in “Process of Planning a Workflow Policy” on page 332.

An action of a workflow policy is executed when the conditions of the workflow policy are met. Workflow Policies come with a set of predefined actions. You can use these actions or define your own actions in order to suit your business requirements.

Table 47 describes an example plan that details the type of information you must define for a workflow policy action.

Examining Workflow Policies and Workflow Policy Programs That Are PredefinedThis task is a step in “Process of Planning a Workflow Policy” on page 332.

Workflow Policies comes with a number of predefined workflow policies and policy programs. Before you define a new workflow policy, you can examine the predefined policies to determine if a policy already exists that meets your business requirements. This way, you can modify existing, predefined objects rather than defining new objects. For more information, see “Types of Workflow Policy Programs That Are Predefined” on page 381 and “Properties of Workflow Policies” on page 470.

Table 46. Example of a Plan for the Workflow Policy Conditions

Field in the Workflow Policy Condition Operation Value

Service Request Severity = 1-Critical

Service Request Status = Open

Table 47. Example of a Plan for the Workflow Policy Actions

Action NameWorkflow Policy Program

Workflow Policy Object Arguments

Send SR Email to Contact Send SR Email Service Request Send to Contact



336

Planning a Test and Migration Strategy for a Workflow PolicyThis task is a step in “Process of Planning a Workflow Policy” on page 332.

Before you implement a new workflow policy, you must make sure that it works properly in a test environment. The environment can consist of a sample Siebel database and test data. Testing a new workflow policy, workflow policy condition, and workflow policy action makes sure that the policy you release into the production environment properly executes and does not cause a conflict with an existing workflow policy.

Guidelines for Setting up Your Test and Migration StrategyGuidelines for setting up your test and migration strategy include:

■ Make sure your test environment and production environment contain identical versions of the software and that you are using realistic data in your database by using a partial or full copy of the production database.

■ Define a small group of workflow policies to implement as a first phase of implementation. After you successfully implement the first group, you can add more policies in a systematic manner.

■ To test a new workflow policy, in your production environment, manually issue a query that is based on the new policy, then check the response. This technique helps you determine if a workflow policy generates excessive notification or misses the rows you must monitor.

For more information, see “Migrating Workflow Policies to the Production Environment” on page 443.

Examples of Planning a Workflow PolicyThis topic describes examples you can examine in order to plan a workflow policy. It includes the following topics:

■ Example of Planning a Workflow Policy That Sends a Discount Notice on page 336

■ Example of Planning a Workflow Policy That Sends a Notice of An Open Service Request on page 338

Example of Planning a Workflow Policy That Sends a Discount NoticeThis topic gives one example of planning a workflow policy. You might use this feature differently, depending on your business model. In this example, the sales department manager must be automatically notified when a sales representative quotes a discount that is greater than 30%.



To plan a workflow policy that sends a discount notice

1 Determine what to monitor.

The following table describes information the workflow policy must monitor.

2 Plan the workflow policy action.

The following table describes values on which the workflow policy action is based.

3 Plan the workflow policy conditions.

The following table describes the type of information that is required for the workflow policy conditions.

What to Monitor Purpose of the Policy

A quote that contains a discount that is greater than 30% requires Sales Manager approval.

Notify Sales Manager to review and approve the quote.

Name

Workflow Policy Object

Workflow Policy Group Duration Quantity Description

Notify Sales Manager upon Sales Approval

Quote Low Frequency

0 5 Notify the manager when a quote with a discount that is greater than 30% is created.

Field (Column Monitored in the Database) Comparison Value

Quote Status = In Progress

Quote Item Discount Percent > 30



338

4 Plan the workflow policy actions that occur when the conditions of the policy are met.

You can also define the action arguments, such as the email subject and the message template, by using dynamic values. The following table describes the Send Email to Sales Manager action.

Example of Planning a Workflow Policy That Sends a Notice of An Open Service RequestThis topic gives one example of planning a workflow policy. You might use this feature differently, depending on your business model. In this example, the service department must automate a notification policy when the number of open service requests for a service representative reaches 20.

To plan a workflow policy that sends a notice of an open service request

1 Determine what to monitor.

The following table describes a plan for the definition of the general policy.

2 Plan the workflow policy action.

The following table describes a plan for the policy action.

Action Name

Workflow Policy Program

Workflow Policy Object Arguments and Substitutions

Send Email to Sales Manager

Send Quote Email

Quote Subject: Please approve quote discount for [Account]

Message Template: Please approve the quote discount for quote [Quote Number] and notify [Last User First Name] [Last User Last Name]

Repeating Message: The following quote also requires approval: [Quote Number]

What to Monitor? Purpose of the Policy

Monitor open service requests when they reach a quantity of 20.

Use Send Broadcast Message to alert the service representative about the situation.

NameWorkflow Policy Object

Workflow Policy Group Quantity

Over 20 Open Service Requests Service Request High Frequency 20



3 Plan the workflow policy conditions.

After you determine the workflow object and other properties for the workflow policy, define the workflow policy conditions. The following table describes a plan for the conditions.

4 Plan the workflow policy actions that occur when the conditions of the policy are met.

You can also define the action arguments. The following table describes a plan for the argument of the action.

Field (Column Monitored in the Database) Comparison Value

Service Request Status = Open

Action NameWorkflow Policy Program

Workflow Policy Object Arguments and Substitutions

Alert Representative of Open SR

Send SR Message Broadcast

Service Request

Abstract: You own over 20 service requests

Message Template: You own over 20 service requests. Please review the queue for your service requests.


Defining a Custom Workflow Policy ■ Process of Defining a Workflow Policy

340

Process of Defining a Workflow PolicyTo define a workflow policy, perform the following tasks:

1 Defining a Workflow Policy Group on page 340

2 Defining a Workflow Policy Action on page 341

3 Defining a Workflow Policy on page 346


■ About Workflow Policies on page 323

■ Examples of Defining Workflow Policy Configurations on page 349


■ “Types of Workflow Policy Programs That Are Predefined” on page 381

Defining a Workflow Policy GroupThis task is a step in “Process of Defining a Workflow Policy” on page 340.

To define a workflow policy, you begin by defining a workflow policy group. For more information, see Planning a Workflow Policy Group on page 332.

To define a workflow policy group

1 In the Siebel client, navigate to the Administration-Business Process screen, then the Policy Groups view.

2 From the drop-down menu in the Policy Groups list, choose New Record.

3 In the Name field, define the name of the workflow policy group.

A workflow policy can belong to only one policy group. The name can be no more than 30 characters in length.

4 (Optional) Enter comments in the Comments field.

Define comments that describe the purpose or use of the policy group.



5 In the Policies list, click New, then define fields using values from the following table.

6 Repeat Step 5 for each workflow policy you must include in the group.

If at some point in the future you must reassign the workflow policy to another group, then see “Moving a Workflow Policy to a Different Group” on page 431.

Defining a Workflow Policy ActionThis task is a step in “Process of Defining a Workflow Policy” on page 340.

You must define the workflow policy action before you define the workflow policy that uses the action.

Field Usage

Name Define the name of the workflow policy that is included in the workflow policy group.

Object Define the workflow policy object for which the workflow policy is defined.

For example, Service Request, Opportunity, or Quote.

Activation Define the date and time that the workflow policy is activated.

If this field is null, then the workflow policy is activated immediately.

NOTE: It is recommended that each workflow policy group contain policies that are monitored within a similar time interval.

Expiration Define the date and time that the workflow policy expires.

If this field is null, then the workflow policy is active indefinitely.

Comments Define comments that describe the purpose or use of the workflow policy.



342

To define a workflow policy action


2 In the Actions list, click New Record from the applet level menu, then define fields using values from the following table.

3 In the Arguments list, define each argument, as necessary.

The Arguments list changes based on the Program you choose in the Actions list in Step 2. For more information, see “Arguments List” on page 344.

Field Description Value

Name Define the name of the workflow policy action.

The name is displayed in the Actions Applet of the Workflow Policies view.

Enter a descriptive name that is consistent with your overall naming strategy and meaningful to the policy maker.

Program Define the workflow policy program that is associated with the action.

You choose this program from a picklist. For more information, see “Types of Workflow Policy Programs That Are Predefined” on page 381.

Workflow Object

Define the workflow policy object with which this action is associated. If you define a workflow policy object, then this action is displayed only on the Actions Applet of the Workflow Policies view for workflow policies that are associated with this workflow policy object.

Chosen from a picklist of workflow policy objects.

Comments Define comments that describe the purpose or use of this workflow policy action.

Enter comments text.



4 (Conditional) In the Recipients list, define a recipient using values from the following table.

You only use the Recipients list when you choose certain programs in the Actions list in Step 2. For more information, see “Recipients List” on page 345.

5 (Optional) Repeat Step 2 to add additional recipients, as necessary.

Field Description

Type Choices available from the picklist include:

■ Send to Employee. Allows you to pick an employee.

■ Send to Position. Allows you to pick a position, thereby sending to the primary employee of this position without having to know the name of the person. The employee must be ACTIVE.

■ Send to Contact. Allows you to pick a contact.

■ Send to Relative. For more information, see “Send to Relative Recipient Type” on page 345.

■ Send to Address. Allows you to manually enter an email address. Used to support a program that sends email.

Name Define the Name of the recipient based on the value you pick for the Type field.

The message is sent based on position. If choosing an employee as the recipient, and if multiple employees occupy the same position, then the message is sent to every employee, even though you only choose one employee as the recipient.



344

Restrictions with Defining a Workflow Policy ActionThis topic describes restrictions with defining a workflow policy action.

Calling a DLL or External FunctionYou cannot call a DLL or external function through a workflow policy action. Instead, use a workflow process to call a DLL or external function.

You cannot call a business service from a workflow policy action.

Insert Operation Usage with a Workflow Policy ActionAn insert operation with a workflow policy action cannot populate the Primary Owner. For example, you cannot modify a Workflow Policy Program, such as Create SR Activity, to populate Primary Activity Owner, OWNER_PER_ID, because the intersection table, S_ACT_EMP, must also be populated. Because the same Workflow Policy Program cannot update two tables within one database operation, Workflow Process must be used to populate OWNER_PER_ID. Earlier versions, such as Siebel CRM version 6, can support this technique because an Activity can be assigned to only one employee. However, in later versions, such as Siebel version 7.x, an Activity can be assigned to multiple employees.

Arguments ListThe Arguments list is context sensitive. A different applet is displayed based on the Program you choose in the Actions list. For example:

■ If you choose Send Message Broadcast in the Program field of the Actions list, then the Send Message Broadcast Arguments list displays.

■ If you choose Send Email in the Program field of the Actions list, then the Send Message Arguments form displays.

Items to consider when using the Arguments form include:

■ A program argument is case sensitive. You must use the correct case. Use the picklists in the Arguments form when possible instead of entering the arguments manually.

■ Before using email or paging, you must perform the setup procedures described in “Administering a Workflow Policy” on page 401.

■ If the workflow policy program is Send Email, Send Page, or Send Broadcast Message, then use the Recipient list to enter the recipients of the action.

For a description of each workflow policy program type, the available workflow policy program arguments, and valid values, see “Types of Workflow Policy Programs That Are Predefined” on page 381.



Applets Refresh AutomaticallyThe applets that are displayed in the Workflow Policies view change automatically, depending on the program type you choose for the workflow policy action. This behavior is different from most views that you use in the Siebel client. For example, when you navigate to the Administration-Business Process screen, then the Policies view, the following applets are displayed: Policies List, Conditions, Actions, Arguments. If you choose Send Page to Opportunity Sales Rep in the Action field of the Actions list, then the Arguments list is automatically replaced with the Send Page Arguments form.

Recipients ListYou only use the Recipients list when you choose Send Email, Send Page, or Send Message Broadcast in the Program field of the Actions list.

Send to Relative Recipient TypeThe Send to Relative recipient type sends an email or page to an individual or position that is associated with the current record, such as Primary Sales Rep or Primary Sales Rep Manager. The choices that are available are context sensitive. They are based on the Workflow Object you choose in the Actions list.

Send to Relative is also used when you must define a custom Send to [xxxx] recipient. Because you must use one of the Recipient Type choices in the picklist, you use Send to Relative to define a custom recipient type. The Recipient Type choices are Send to Employee, Position, Contact, or Relative.

Email Manager does not send email to the same recipient twice for the same action. If it detects that an email was sent to a specific email address, then another message is not sent. If the Send to Relative type returns more than one recipient, then each recipient is sent an email as long as each email address is unique.

Sending an Email to Multiple Relative RecipientsA workflow policy can be defined so that the same email message is sent to a number of different relative recipients.

To send an email to multiple relative recipients

1 Define an action for the policy program.

2 In the Recipients list, add a new record, set the Type field to Send to Relative, then pick the name of the first recipient in the Name field.

3 Repeat Step 2 for each additional recipient, updating the Name field for each recipient.

4 Associate the action with the workflow policy.



346

Defining a Workflow PolicyThis task is a step in “Process of Defining a Workflow Policy” on page 340.

After you define your workflow policy group and workflow policy action, you can use the Workflow Policies view to define the workflow policy. For more information, see “Examples of Defining a Workflow Policy” on page 357.

To define a workflow policy

1 In the Siebel client, navigate to the Administration-Business Process screen, then the Policies view.

2 In the list for the Policies List, choose New Record from the applet level menu, then define fields using values from the following table.

Field Description Explanation

Name Define the name of the workflow policy.

Not applicable

Workflow Object

Define the workflow policy object for which the policy was defined.

For example, Service Request, Activity, or Accounts.

This field is required.

Policy Group

Define the workflow policy group to which the policy belongs.

Each workflow policy must be assigned to a workflow policy group.

For more information, see “Moving a Workflow Policy to a Different Group” on page 431.

Activation Define the date and time that the policy is activated.

If this field is null, then the workflow policy is activated immediately.

Expiration Define the date and time that the policy expires.

If this field is null, then the workflow policy is active indefinitely.

Duration Define the duration fields in days, hours, or minutes that the workflow policy conditions must be true in order for the workflow policy to be executed.

If the workflow policy is run in batch, then this field is ignored.



3 In the Conditions list, choose New Record from the applet level menu, then define fields using values from the following table.

Qty Define the number of records that meet the workflow policy conditions before the workflow policy action executes.

If you do not define a quantity, then Siebel Workflow assumes a quantity of 1. Qty allows you to define a workflow policy condition that is based on the number of records that meet the condition. For example, you can define a policy that sends a broadcast message when 20 or more critical service requests are open.

Batch Mode Define, by checking Batch, that this workflow policy evaluates records that potentially meet the conditions of the workflow policy.

The Workflow Monitor Agent scans records by using the conditions of the policy in order to find the matches.

If this field is checked, then run Workflow Monitor Agent with the Batch Mode flag set to TRUE.

The default is unchecked.

Field Usage Example

Condition Field

Define the workflow policy component column in the workflow policy object on which the workflow policy condition is based. Values that appear in the Condition Field are context sensitive, depending on the value you choose for Workflow Object in Step 2.

NOTE: For a workflow policy to be called that contains a Condition Field <> [Value n], a value must be defined in this field other than the value that is defined in the workflow policy condition. If there is no value, then the workflow policy is not called. The Operator IS NULL is used in this case.

Choose Service Request Area from the picklist.

Field Description Explanation



348

4 In the Actions list, choose New Record from the applet level menu, then define fields using values from the following table.

5 (Optional). Repeat Step 4 to add additional actions, as necessary.

Restrictions with Defining a Workflow PolicyRestrictions with defining a workflow policy include:

■ A workflow policy cannot be based on the S_DOCK_TXN_LOG table. The unique index for this table is TXN_ID, rather than the ROW_ID that is used with other standard Siebel tables. Because Siebel Workflow uses ROW_ID to do the comparison and execute actions, it errors out if used against the S_DOCK_TXN_LOG table.

■ You cannot execute a business service from a workflow policy.

■ A workflow policy updates a database field directly through the Data Layer, and does not update through the Business Object Layer. Therefore, a workflow process that includes a business component event that is related to the updated field is not executed.

Operation Define the comparison to make between the value of the column for a workflow policy agent and the value you define. Choose the comparison from the picklist for the field.

For more information, see “Examples of Defining Workflow Policy Configurations” on page 349.

Choose equals (=) from the picklist.

Value Define the value to compare to the column of the instance of the workflow policy.

Value is a required field except when the Comparison field contains a value of Is Null, Is Not Null, Is Updated, Is Deleted, or Is Added.

For more information, see “Examples of Defining Workflow Policy Configurations” on page 349, and “Date Calculations in the Conditions List” on page 375.

Choose Printer from the picklist.

Field Usage

Action Pick the action that is executed with this workflow policy.

Sequence Define the sequence of the action relative to other actions.

Consolidate If more than one record meets the conditions of the workflow policy during the same action interval, then you can consolidate the action to one instance. To consolidate an action, make sure the consolidate field contains a checkmark.

The consolidate flag is not available with an action that sends a page.

Field Usage Example

Defining a Custom Workflow Policy ■ Examples of Defining Workflow PolicyConfigurations


Examples of Defining Workflow Policy ConfigurationsThis topic describes example configurations for workflow policy actions and workflow policies. It includes the following topics:

■ Examples of Defining a Workflow Policy Action on page 349

■ Examples of Defining a Workflow Policy on page 357

Examples of Defining a Workflow Policy ActionThis topic describes examples that use a workflow policy action in order to address a specific business requirement. It includes the following topics:

■ Example of Defining a Workflow Policy Action That Sends a Page on page 349

■ Example of Defining a Workflow Policy Action That Sends an Email with a Repeating Message on page 351

■ Example of Defining a Workflow Policy Action That Sends a Broadcast Message on page 352

■ Example of Defining a Workflow Policy Action That Executes a Database Operation on page 354

■ Example of Defining a Workflow Policy Action That Runs an External Program on page 354

You can use these examples as the basis for defining your own workflow policy actions.

Example of Defining a Workflow Policy Action That Sends a PageThis topic gives one example of using a workflow policy action to send a page. You might use this feature differently, depending on your business model. A page can be sent to the support manager when the priority for a service request is very high and the service request is not assigned to anyone. Use the procedure in this topic to define a workflow policy action that addresses this situation.

To define a workflow policy action that sends a page



Defining a Custom Workflow Policy ■ Examples of Defining Workflow Policy Configurations

350

2 In the Actions list, define a new record using values from the following table.

If a workflow policy object is defined in the workflow policy Program field, then the Workflow Object field automatically populates. You choose a workflow policy object from the picklist when it does not automatically populate.

3 In the Send Page Arguments form, define the argument using values from the following table.

You use the Numeric Message Template for numeric paging and the Alphanumeric Message Template for alphanumeric paging. The type of paging to use is indicated by the pager type in the employee table.

You can copy and paste fields that are available from the Available Substitutions window.

4 In the Recipients list, define a new record using values from the following table.

This action is now available to use in a workflow policy.


6 Query the Workflow Object field for Service Request.

This query returns a list of policies where the action you just defined can most appropriately be used.

7 In the Name column, choose a Workflow policy, such as Page SR Owner (Gold).

8 In the Actions list, define a new record, then locate Page Support Manager when SR request changes, which is the action you just defined.

9 Examine the Send Page Arguments form.

The Send Page Arguments form populates with values that you defined in this procedure.

Field Value

Name Page Support Manager when SR request changes.

Program Send SR Page

Workflow Object Service Request

Field Value

Alpha Message Template The [SR Status] of [SR Number] was changed.

Field Value

Type Send to Position

Name Support Manager



Example of Defining a Workflow Policy Action That Sends an Email with a Repeating MessageThis topic gives one example of using a workflow policy action to send an email with a repeating message. You might use this feature differently, depending on your business model. In this example, the vice president of sales must be notified only after a specific number of deals fail to close. Because this action is used with a workflow policy that uses the Batch feature, you enter relevant information in the Repeating Message field of the Send Message Arguments form. Using this technique makes sure that the recipient receives one email with a consolidated list of the pertinent information on each of the deals. Without a Repeating Message, the email is sent but might not contain meaningful information.

To define a workflow policy action that sends an email with a repeating message



3 In the Send Message Arguments form, define the argument using values from the following table.


This action is now available for use in a workflow policy.


Field Value

Name Excellent Quality Opportunity

Program Send Opportunity Email

Workflow Object Opportunity

Comment Send an email to the VP of Sales when deals are not closing.

Field Value

Subject Opportunities not Closing

Message Template Meet with [Last User First Name] [Last User Last Name] about [Opportunity] for [Account]

Repeating Message Meet with [Last User First Name] [Last User Last Name] about [Opportunity] for [Account]

Field Value


Name VP Sales



352

6 Query the Workflow Object field for Opportunity.

This step returns a list of policies where the action you just defined can most appropriately be used.

7 In the Name column, choose a Workflow policy, such as New Opportunity.

8 In the Actions list, define a new record, then locate Excellent Quality Opportunity, which is the action you just defined.

9 Examine the Send Page Arguments form.

The Send Page Arguments form populates with values you defined in this procedure.

10 In the list for the Policies List, make sure the Batch Mode field contains a check mark.

Example of Defining a Workflow Policy Action That Sends a Broadcast MessageThis topic gives one example of using a workflow policy action to send a broadcast message. You might use this feature differently, depending on your business model. In this example, a service department must automate a notification policy for open service requests when there are at least 20 open requests for one service representative.

To define a workflow policy action that sends a broadcast message



3 In the Send Message Broadcast Arguments form, define the argument using values from the following table.

Field Value

Name Alert Representative of Open SRs

Program Send SR Message Broadcast


Field Value

Abstract You own over 20 Service Requests.

Message Template You own over 20 service requests. Please review your service request queue.




This action is now available for use in a workflow policy. For instructions on how to add an action to a workflow policy, see “Example of Defining a Workflow Policy Action That Sends a Page” on page 349.

Field Value

Type Send to Relative

Name SR Owner



354

Example of Defining a Workflow Policy Action That Executes a Database OperationThis topic gives one example of using a workflow policy action to execute a database operation. You might use this feature differently, depending on your business model. Insert and update are the two kinds of database operations that are possible with workflow policies. Insert allows a record to be inserted into a table in the Siebel database. The update database operation allows one or more columns in an existing record to be changed.

In the following example, a database update occurs when you use workflow policies to update the value of the Priority field to Very High if the Severity is Critical.

To define a workflow policy action that executes a database operation



3 In the Arguments form, define the argument using values from the following table.


Example of Defining a Workflow Policy Action That Runs an External ProgramThis topic gives one example of using a workflow policy action to run an external program. You might use this feature differently, depending on your business model.

In Siebel Workflow, you use Run External Program to define an action that runs an external program. For example, your company can write a custom executable to calculate the quality of a new lead. You can then call this executable from a workflow process when the parameters to calculate the lead change.

You can use a program named leadcalc.exe in the C:\bin directory and an Action in order to call and execute Run External Program.

Field Value

Name Update SR Priority to Very High

Program Change SR Priority


Field Value

Name New Priority

Value 1-ASAP



To define a workflow policy action that runs an external program



If a workflow policy object is already defined for the chosen workflow policy program, then the Workflow Object field automatically populates. Otherwise, you pick a workflow policy object from the picklist for the Workflow Object field.

After you step off the record, you cannot modify the Workflow Object.

3 In the External Program Arguments form, define fields using values from the following table.

In this form, you define the executable and information you must pass to the external program.



Field Value

Name Run Lead Calculation Program

Program Run External Program

Workflow Object (Define the workflow object involved in this action, such as Account.)

Field Value

Executable Name leadcalc.exe

Command Line (Enter command line parameters. These are the parameters you must pass to the executable.)

Execute Type (Choose an execute type.)

Available Substitutions (Choose the appropriate dynamic fields.)

Field Value


Name Support manager



356

Defining an External Program to Run on UNIXThe predefined Run External Program workflow policy program is not supported on UNIX. However, you can use the procedure described in this topic instead.

To define an external program to run on UNIX

1 Define a business service that executes an external program:

a Navigate to the Business Service Administration screen, then the Business Service Methods view.

b Add a new business service.

For example, Run Program.

c Add a new Method.

For example, Run.

d Add a new Method Argument.

For example, Program.

e Select Proc: Service_PreInvokeMethod.

f Call Clib.system in the function body.

For example:

var program = Inputs.GetProperty (“Program”)if (program){Clib.system(program);}return (CancelOperation);

2 Define a workflow process that calls the business service defined in Step 1:

a Add a start step, a business service step, and an end step.

b Connect the steps.

c For the business service step, define Run Program and Run.

d For the input argument for Program, define the external program you must run.

For example, you can define letter.txt that exists in /bin/mail [email protected] </home/users/hkim/letter.txt.

3 Run your workflow process.



Examples of Defining a Workflow PolicyThis topic describes examples of defining a workflow policy. It includes the following topics:

■ Example of Defining a Workflow Policy That Sends Paging Notification of Service Requests That Are Not Assigned on page 357

■ Example of Defining a Workflow Policy That Sends an Email Notification of Open Opportunities on page 358

Example of Defining a Workflow Policy That Sends Paging Notification of Service Requests That Are Not AssignedThis topic gives one example of using a workflow policy to send a page. You might use this feature differently, depending on your business model. In this example, the support manager requires that a page be sent when the priority for a service request is Very High and no one is assigned to the service request. Assume the Send Page action is already defined. Next, you define the workflow policy to implement the workflow policy action.

To define a workflow policy that sends paging notification of service requests that are not assigned


2 In the list for the Policies List, choose New Record from the applet level menu. Define a new policy record using values from the following table.

3 In the Conditions list, add two new records using values from the following table.

This step defines the conditions under which the Page Support Manager policy applies.

4 Scroll down to the Actions list, then add an Action.

5 From the picklist in the Action field, choose the appropriate notification action.

For example, Page for Critical SR Gold Support.

Field Value

Name Page Support Manager


Policy Group High Frequency

Duration 2 hours

Condition Field Operation Value

Service Request Priority = High

Service Request Owner IS NULL (leave empty)



358

Example of Defining a Workflow Policy That Sends an Email Notification of Open OpportunitiesThis topic gives one example of using a workflow policy to send a notice through email. You might use this feature differently, depending on your business model. In this example, the vice president of sales must be notified when the number of deals that are not closed reaches a designated level. For this example, assume you already defined a workflow policy action that batches information on the deals and sends an email message that contains information on the number of deals you designated.

To define a workflow policy that sends an email notification of open opportunities


2 In the list for the Policies List, chose New Record from the applet level menu. Define a new policy record using values from the following table.

NOTE: It is not necessary for you to define the Quantity field in order to display a repeating message.

3 In the Conditions list, add two new records, using values from the following table.

This step defines the conditions under which the Very High Value Opportunity policy applies.

4 In the Actions list, add a new action record using values from the following table.

This step defines the action to execute when the conditions are met.

Field Value

Name Very High Value Opportunity

Workflow Object Opportunity

Policy Group Medium Frequency

Quantity 5

Batch checked

Condition Field Operation Value

Forecast Probability <= 50

Forecast Revenue > 400000

Action Consolidate

Excellent Quality Opportunity Email Checked



5 Scroll to the bottom of the screen and examine the Send Message Arguments form.

Values in the form automatically populated with information from the Action you defined in Step 4.

6 In the Actions applet, click the Excellent Quality Opportunity E-mail hyperlink in the Action applet.

7 Examine values in the Actions applet and Send Message Arguments.

These values can be modified to meet the specific requirements of your implementation.

Configuring the Workflow Policy Monitor to Align the Timing of Email CreationThis topic describes how to make sure your email lists the opportunities that meet the conditions of the workflow policy. If the Workflow Policy Action agent runs too fast, then an individual email is inserted each time the conditions of the workflow policy are met.

To configure the workflow policy monitor to align the timing of email creation

1 Restart the Workflow Policy Monitor agent.

2 Restart the Workflow Policy Action agent.

■ Set the Sleep parameter on the Workflow Policy Action to at least 5 minutes.

For more information about starting a server process, see “Administering a Workflow Policy” on page 401.


Defining a Custom Workflow Policy ■ Customizing Workflow Policy Objects

360

Customizing Workflow Policy ObjectsValues assigned to a predefined object that is associated with defining a workflow policy are modified in the Siebel client. You can use Siebel Tools to modify these predefined objects or to define new objects. After compiling your modifications, the modified definitions are available for use in the Siebel client.

This topic includes the following topics:

■ Display of Workflow Policy Objects on page 360

■ Defining a Customized Workflow Policy Object on page 361


■ Procedures for using the Siebel client in order to define a workflow policy that references these compiled objects, see “Process of Defining a Workflow Policy” on page 340

■ Predefined policies you can use instead of defining new objects, see “Types of Workflow Policy Programs That Are Predefined” on page 381

■ Reference information, see “Properties of Workflow Policies” on page 470

Display of Workflow Policy ObjectsThis topic describes how workflow policy objects are displayed in the Siebel client. For information about how workflow policy objects are displayed in Siebel Tools, see “Hierarchy of Workflow Policy Objects” on page 331.

Workflow Policy Objects in the Siebel ClientYou use Siebel Tools to modify a predefined or to define a custom workflow policy and workflow policy program. After deployment, a customization is visible in the Workflow Policy view and the Workflow Action view in the Siebel client.

Objects That Are Displayed in the Workflow Policy ViewTable 48 describes how a Workflow Policy Object is displayed in the Workflow Policy view in the Siebel client after the object is deployed from Siebel Tools.

Table 48. Workflow Policy Objects That Are Displayed in the Workflow Policy View

Workflow Object in Siebel Tools Location of Workflow Object in the Siebel Client

Workflow Policy Object Workflow Object picklist in the list for the Policies List.

Workflow Policy Component Column Condition Field picklist of the Conditions list.

Values displayed in the picklist for the Condition field are context sensitive, depending on the value in the Workflow Object field in the list for the Policies List.



Object definitions for the Workflow Policy Component do not appear in the Workflow Policy view. However, the Workflow Policy Component object acts as an aggregator for values that are displayed in the Condition Field. Because the Workflow Policy Component Column object is a child of the Workflow Policy Component, values for the object definitions of the Workflow Policy Component Column that are part of a Workflow Policy Component are displayed in the Condition Field. The deployed definitions are visible in the Siebel client in the Policies view of the Administration-Business Process screen.

Objects That Are Displayed in the Actions ViewTable 49 describes how a Workflow Policy Program is displayed in the Workflow Action view in the Siebel client after the program is deployed from Siebel Tools.

The deployed object definitions are visible in the Siebel client in the Actions view of the Administration-Business Process screen. Information that is specific to Workflow Policies is described in this document. For more information about general Siebel Tools usage, see Using Siebel Tools.

Defining a Customized Workflow Policy ObjectThis topic describes how to use Siebel Tools in order to define customized objects that are associated with a workflow policy. It includes the following topics:

■ Defining a Customized Workflow Policy Column on page 362

■ Defining a Customized Workflow Policy Object on page 363

■ Defining a Customized Workflow Policy Component on page 364

■ Defining a Customized Workflow Policy Component Column on page 364

■ Defining a Customized Workflow Policy Program on page 366

■ Defining a Workflow Policy Program Argument on page 368

For more information, see “Examples of Workflow Policy Programs That Are Predefined” on page 388.

Table 49. Workflow Policy Programs That Are Displayed in the Workflow Action View

Workflow Object in Siebel Tools Location of Workflow Object in the Siebel Client

Workflow Policy Program Program field picklist in the Actions list

Workflow Policy Program Argument Arguments field picklist in the Arguments list

Values displayed in the picklist for the Arguments field are context sensitive, depending on the value in the Program field in the list for the Policies List.



362

Defining a Customized Workflow Policy ColumnThis topic describes how to define a customized workflow policy column. Before you can add a workflow policy column to a workflow policy component, you must define the workflow policy column in the Object List Editor (OBLE) for the Workflow Policy Columns.

CAUTION: Deleting a workflow policy column requires removal of references to the columns in workflow policy objects. Even if a workflow policy column is not currently used in an active workflow policy, the Workflow Monitor Agent might reference the columns in the repository, thereby facilitating fast activation of new workflow policies in the future. However, in order to avoid potential link conflicts, care must be used to remove old references if design requirements change.

To define a customized Workflow Policy Column

1 Identify the business object, business component, and applet that use the new workflow policy column:

a In the Siebel client, navigate to the view that will use the new policy column.

For example, from the Accounts List, drill down on an account record, then choose the Activities view tab.

b From the application-level menu, choose the Help menu, then the About View menu item.

c Note the Business Object, Business Components, and Applets that this view uses.

d In Siebel Tools, in the Business Components OBLE, choose one of the business components identified in Step c, then note the value in the Table property.

e The Table property displays the table name for the Siebel database table that this business component references.

2 Define the new workflow policy column:

a Choose Workflow Policy Column in the Object Explorer.

b From the application-level menu, choose the Edit menu, then the New Record menu item.

c In the Workflow Policy Columns OBLE, use the values you found in previous steps of this procedure to define properties for the new object.

The table name and column name combination must be unique. If the table name and column name combination are already defined for another object, then you cannot save the object.

Defining the Condition of a Workflow Policy That Is Based on a Foreign KeyYou can define the condition of a workflow policy that is based on a foreign key that exists in the primary table of the workflow object. For example, SOPTY.CURR_STG_ID, where S_OPTY is the primary table of the Opportunity workflow object, and CURR_STG_ID is a foreign key from S_STG.NAME.



To define the condition of a workflow policy that is based on a foreign key

1 In the Workflow Policy Columns OBLE, define a new workflow policy column with S_STG.NAME in the Name property.

2 Make sure CURR_STG_ID is added under the Opportunity workflow component.

3 Define a new workflow component in the Opportunity workflow object that is based on the S_STG table, using values displayed in the following table.

4 Add the new workflow column, S_STG.NAME, that you defined in Step 1 to the new workflow component you defined in Step 3.

You can now define a condition for the workflow policy that is based on the new workflow column.

Defining a Customized Workflow Policy ObjectThis topic describes how to define a customized workflow policy object.

CAUTION: In the Workflow Policy Components OBLE, you must define only one record as the primary workflow policy component. The Primary property can be checked for only one record.

To define a customized workflow policy object

1 In Siebel Tools, navigate to the Workflow Policy Objects OBLE.

2 From the application-level menu, choose the Edit menu, then the New Record menu item.

3 Define properties for the new record.

4 In the Object Explorer, click Workflow Policy Components.

5 From the application-level menu, choose the Edit menu, then the New Record menu item.

6 Make sure the Primary property contains a check mark.

Note the caution provided at the beginning of this topic.

7 Add more workflow policy components, defining relations to the primary workflow policy component, as necessary.

8 In the Object Explorer, click Workflow Policy Component Col.

9 In the Workflow Policy Component Columns OBLE, add an object for each of the workflow policy components that you defined in Step 7.

Property Value

Name (your choice)

Source Table Name S_STG

Source Column Name ROW_ID

Target Component Name Opportunity

Target Column Name CURR_STG_ID



364

Defining a Customized Workflow Policy ComponentThis topic describes how to define a customized workflow policy component.

To define a customized workflow policy component

1 In Siebel Tools, choose the Workflow Policy Object in the Object Explorer.

2 In the Workflow Policy Objects OBLE, query the Name property for Account.

3 In the Object Explorer, expand Workflow Policy Object, then choose Workflow Policy Component.

4 In the Workflow Policy Components OBLE, define a new record with a value in the Name property.

5 Enter a value in the Source Table Name property.

6 Enter a value in the Source Column Name property.

The Source Column Name property establishes a relationship between the workflow policy component you are currently defining and the primary policy component.

7 Identify the set of columns for the workflow policy component you just defined that you must monitor:

a In Siebel Tools, navigate to the Workflow Policy Column OBLE.

b Identify the column in the predefined workflow policy columns with an activity assigned to it but that is not currently exposed in the OBLE for the Workflow Policy Component Column.

Defining a Customized Workflow Policy Component ColumnThis topic describes how to associate a column with a workflow policy component.

Your business can use specialized terminology that more clearly defines the environment within your company. Values that appear in the Condition Field picklist on the Conditions list of the Workflow Policies view in the Siebel client are populated from the Alias property. You can use the Alias property in the Workflow Component Columns OBLE to define a custom label. Then, you can use this label when you refer to the definition of the workflow component column.

To define a customized workflow policy component column

1 In Siebel Tools, navigate to the Workflow Policy Columns OBLE.

2 Query the Name property for the name of the column you must modify.

If the query returns no results, then define a new Workflow Policy Column that references the required data table and data table column.

3 Navigate to the Workflow Policy Objects OBLE, then query the Name property for the required Workflow Policy Object.

4 Navigate to the Workflow Policy Components OBLE, then query the Name property for the required Workflow Policy Component.

5 Navigate to the Workflow Policy Component Columns OBLE.



6 Define your customization:

■ If you are defining a new object, then, from the application-level menu, choose the Edit menu, then the New Record menu item. Add values to the Workflow Column Name and Alias properties, as necessary.

■ If you are modifying an existing object, then query the Workflow Column Name property for the required Workflow Policy Component Column, and then modify the Alias property.

When defining the Workflow Column Name property, use the picklist to choose a column from the current set of columns that are available for this Workflow Policy Component.

If the workflow policy component column that you must monitor is not in the list, then you must define a new object for it by using the Workflow Policy Columns OBLE.

7 In the Object Explorer, click Workflow Policy Object.

By default, the Workflow Policy Object with the name of the object you just modified is the active record in the Workflow Policy Objects OBLE.

8 From the application-level menu, choose the Tools menu, then the Compile Selected Objects menu item.

9 Click Compile.


11 In the list for the Policies List, click Query.

12 Query the Workflow Object field for the workflow object you just modified, then click Go.

Your custom alias displays in the Condition Field picklist in the Conditions list.

Example of Modifying a Workflow Policy Component Column to Display a Custom LabelThis topic gives one example of modifying a workflow policy component column. You might use this feature differently, depending on your business model. In this example, the sales department in your company must refer to the person who is handling the opportunity as the Opportunity Primary Sales Associate.

To modify a workflow policy component column to display a custom label

1 In Siebel Tools, in the Object Explorer, click Workflow Policy Object.

2 In the Workflow Policy Objects OBLE, query the Name property for Opportunity.

3 In the Object Explorer, expand the Workflow Policy Object tree, click Workflow Policy Component, then query the Name property of the Workflow Policy Components OBLE for Opportunity.

4 In the Object Explorer, expand the Workflow Policy Component tree, then click Workflow Policy Component Col.

5 In the Workflow Policy Component Columns OLBLE, query the Workflow Column Name property for Opportunity Primary Sales Rep Position, then change the Alias property to Opportunity Primary Sales Associate.



366

6 In the Object Explorer, click Workflow Policy Object.

By default, the Workflow Policy Object named Opportunity is the active record in the Workflow Policy Objects OBLE.

7 From the application-level menu, choose the Tools menu, then the Compile Selected Objects menu item.

8 Click Compile.


10 In the list for the Policies List, click Query, enter New Opportunity in the Name field, then click Go.

11 In the Conditions list, define a new record, setting the Condition Field to Opportunity Primary Sales Rep Position, and the Operation to IS ADDED.

Your custom alias displays in the Condition Field picklist.

Defining a Customized Workflow Policy ProgramThis topic describes how to define a customized workflow policy program. A workflow policy program is a generic event on which actions are based. You define a workflow policy program by defining the workflow policy event.

CAUTION: Do not rename or change the name of an existing workflow policy program, as this can result in the loss of actions that are created for the program.

If you define a workflow policy program that inserts a new record, then you must determine and provide the minimum field values that constitute a valid record for the inserted record, as defined in the repository for the table. Table 50 describes required values.

For more information, see Siebel Data Model Reference.

CAUTION: Thoroughly test SQL queries that you plan to use with custom policy programs. Be aware that if the SQL statement fails to find rows, then the workflow policies action is unable to process a token.

Table 50. Values Required when Defining a Customized Workflow Policy Program

Required Values Values Not Required

Values for the columns that are needed to constitute the inserted record are required.

If a default value is defined for a column, then that default value is used on the insert if the program specifies none.

For example, the S_EVT_ACT table contains two required columns: NAME and ROW_STATUS. Because ROW_STATUS defaults to Y, it is not necessary for you to set a value in the program.

A value for a system generated column is not required, such as CREATED, CREATED BY, LAST_UPD, LAST_UPD_BY, ROW_Id, MODIFICTION_NUM, and CONFLICT_Id.



To define a customized workflow policy program

1 In Siebel Tools, in the Object Explorer, click Workflow Policy Program.

2 In the Workflow Policy Programs OBLE, choose an existing workflow policy program that is similar to what you require for the customized workflow policy program.

3 Right-click, then choose Copy Record.

The Copy Record feature copies the entire program, including the program arguments.

4 In the new workflow policy program, modify the appropriate properties in order to meet the requirements of the customized program, such as Workflow Object.

5 Define the program arguments.

Enter the arguments carefully to make sure capitalization, punctuation, and spelling are correct:

■ Type the entries in the Name column exactly as indicated in Table 99 on page 478. Primary ID, Primary Table, Operation Type, SQL Statement, and SQL Statement Outputs must contain one space between each word and each word must be properly capitalized. For example, Primary Id must contain: one space between the two words, a capital P, and a lowercase d.

■ Avoid using the carriage return. For more information, see “Use of Carriage Return in the Argument of a Workflow Policy Program” on page 367.

■ If using an SQL statement in a program argument, then make sure the statement is specific to the particular RDBMS you are using.

■ Type the names of the column pairs exactly: one space between each word, identically capitalized, one space in front of the left parenthesis, and no spaces in the column.

■ The order of the rows is not important.

NOTE: Before you use a workflow policy program and related arguments for the workflow policy program, you must delete the definitions for workflow policy program arguments that are inactive or incomplete. These can cause Workflow Monitor Agent errors.

Use of Carriage Return in the Argument of a Workflow Policy ProgramIn a workflow policy program argument, the carriage return character that exists in SQL Statement and SQL Statement Outputs can cause unexpected behavior for a workflow policy program. In most cases, the substitution value is not substituted with the intended value but is instead substituted with the [Label] literally. Avoid using the carriage return character.

Copying an Existing Workflow Policy ProgramThe advantage of copying an existing workflow policy program is that if something goes wrong with your customized workflow policy program, then you can start over with the original, unmodified workflow policy program.

NOTE: It is recommended that if you define a new workflow policy program, then first copy an existing workflow policy program that is similar to what you require, and then modify the copy in order to suit your specific business requirements.



368

Also, if you modify a copy of an existing workflow policy program, then you can often reuse a significant portion of the preexisting configuration, which leads to fewer errors than if you define an entirely new workflow policy program.

Defining a Workflow Policy Program ArgumentThis topic gives one example of using a workflow policy program argument to send an email. You might use this feature differently, depending on your business model. The example in this topic adds a new workflow policy program argument. The current recipients of type relative are limited to the Primary Sales representative. You add a relative for Primary Contact, thereby allowing a policy maker to define an action that sends an email to the Primary Contact for an opportunity.

To define a workflow policy program argument

1 In Siebel Tools, navigate to the Workflow Policy Programs OBLE.

2 In the Object Explorer, click Workflow Policy Program Arg.

3 In the Workflow Policy Program Arguments OBLE, make sure an object named Send to Relative exists.

4 Define a new record, setting the Name property to Primary Contact.

A new workflow policy program argument cannot contain the same name as an SQL Statement Output. If an attempt is made to add a new program argument that does contain the same name as an SQL Statement Output, then the Monitor Agent server task suspends, and then displays the Examining request for policy message.

5 Click in the Default Value property.

6 In the compose box, define your SQL statement. For example:

select O.PR_CON_ID, 'Send to Contact'from &Table_Owner.S_OPTY Owhere O.ROW_ID=?

Because Siebel Workflow passes the ROW_ID of the violating row, be sure your SQL queries use the same ROW_ID. In this example, the WHERE clause is written to use the ROW_ID of the opportunity row that violates the policy.

Certain requirements must be considered when defining an SQL statement. For more information, see “Requirements of an SQL Statement That Is Written for a Workflow Policy Program Argument” on page 369.

TIP: An SQL statement is specific to the database vendor. Use an external SQL tool in order to build and test your statement. If the test works, then copy the statement into the field.

7 Set the PickList property to Workflow Relative Type Picklist.

This picklist identifies this argument as a relative.

The Visible field is checked for your new workflow policy program argument . The changed field is checked when you define a new program argument.



Requirements of an SQL Statement That Is Written for a Workflow Policy Program ArgumentAn SQL statement that is written for a workflow policy program argument must include:

■ The table name and column name you reference must be in upper case

■ The case sensitive table name must be prefixed with &Table_Owner

■ The SQL statement must be valid for the specific database vendor

Guidelines for Using an SQL Statement with a Workflow Policy Program ArgumentGuidelines when using a SQL statement with a workflow policy program argument include:

■ It is recommended that the SQL statement return only one record. To be sure, use a statement that uses the outer join rather than the inner join.

■ Only one workflow policy program argument that uses an SQL statement can be used for a workflow policy program. Do not use two or more workflow policy program arguments that use SQL statements for a given workflow policy program.

CAUTION: It is recommended that you thoroughly test your SQL statement in the context of the workflow policy program in which it is used prior to implementation.


Defining a Custom Workflow Policy ■ Conditions for a Workflow Policy

370

Conditions for a Workflow PolicyThis topic describes how conditional logic is defined for a workflow policy. It includes the following topics:

■ Standard Comparisons in the Conditions List on page 370

■ A Field That Is Not Known Is Interpreted as Null on page 371

■ Specialized Comparisons in the Conditions List on page 371

■ Date Calculations in the Conditions List on page 375

Conditional logic for a workflow policy is defined in the Conditions list of the Workflow Policies view in the Siebel client. Comparison values in the Operation field expose the Siebel Workflow policy component column for monitoring.

Standard Comparisons in the Conditions ListThe Comparison field supports greater than (<), less than (>), not equal to (<>), greater than or equal to (>=), less than or equal to (<=), equal (=), LIKE, IN, NOT IN, BETWEEN, IS NULL, and IS NOT NULL operators.

Table 51 describes comparisons and values for a typical database. The requirements of the syntax that is used with your specific database might vary.

Table 51. Comparison Operators and Values for a Typical Database

Comparison Value

less than sign (<) 5

greater than sign (>) 5

not equal to sign (<>) 5

greater than or equal to sign (>=) 5

less than or equal to sign (<=) 5

equal sign (= ) A

LIKE Abc%

IN (1, 2, 3)

NOT IN ('A', 'B', 'C')

BETWEEN 1 and 2

BETWEEN 'A' and 'B'



The following syntax rules apply:

■ If using LIKE, IN, NOT IN, or BETWEEN with character fields, then use single quotes around the value.

■ If using IN or NOT IN, then you must place the value within parentheses.

■ An AND is implied between multiple conditions that are defined that use these comparison values. AND means that all the conditions must be met before the action occurs.

■ LIKE and NOT LIKE allow you to use wildcards. For example, LIKE Smith%, or NOT LIKE Sm%th%.

The following requirements of the underlying database apply:

■ If you define values for the comparison operands LIKE, IN, NOT IN, and BETWEEN in the Value field of the Conditions list of the Workflow Policies view, then it must be in a form that the underlying database expects.

■ IN, NOT IN, and BETWEEN require you to enter the database specific format for the field examined. For example, IN ('a', 'b', 'c') or IN (1, 2, 3, 4) and BETWEEN 'A' and 'B' or BETWEEN 1 and 10.

■ On an MS SQL Server database, if you define a workflow policy condition on a LONG column, then the available comparisons are IS NULL, IS NOT NULL, LIKE, and NOT LIKE.

NOTE: It is up to the creator of the policy to make sure the syntax is correct. The Process Designer only passes the BETWEEN clause to the database. It does not confirm syntax, except for date and time. For date and time fields, the Process Designer converts the date and time columns to the format of month/day/year, hour:minute:second.

A Field That Is Not Known Is Interpreted as NullIf a field value is not known rather than having no value, then the field is interpreted as null. For example, assume a condition includes the following logic:

FIeldA IS UPDATED

FieldB <> "MyValue"

In this case, if FieldB is null, then the condition <> "MyValue" is false. Null is interpreted as the field value is not known. When evaluating whether null is not equal to Y, Siebel assumes the field could be set to anything, including Y. Therefore, because it cannot be concluded that the field is definitely not set to Y, false is returned and the Workflow Monitor Agent does not execute the action.

Specialized Comparisons in the Conditions ListThe Comparison field supports the specialized operators IS ADDED, IS UPDATED, and IS DELETED. The IS operators serve as a starting point for the examination of the workflow policy.



372

If defining a batch type of workflow policy, then the comparison operators IS ADDED, IS UPDATED, or IS DELETED must be used in conjunction with a regular workflow policy condition. These comparison operators are considered special conditions that are intended for Dynamic mode when calling rows to look up a regular condition.

The following comparisons work at the workflow policy component level but do not operate at the field level:

■ IS ADDED. If a new row is added for this workflow policy component, then call this workflow policy to be examined. If used in conjunction with a standard comparison, IS ADDED can be used when a record is updated.

■ IS DELETED. If a row is deleted from this workflow policy component, then call this workflow policy to be examined.

The following comparisons operate at the field level:

■ IS UPDATED. If the value for a field that is changed by adding a new record with the specific field, or by modifying the field in an existing record, then call this policy to be examined. To monitor if a field for a particular table is updated, use the workflow policy component column that represents the LAST_UPD column for that table.

To monitor if a field within the workflow policy component is modified, use the field that is named after the workflow policy component.



Table 52 describes specialized comparisons for a database platform that can be used in defining a workflow policy condition.

An OR is implied between specialized comparisons, where one or more of the workflow policy conditions must be met before the action occurs. For example, a service representative can receive an email when an activity is added to an open service request. Conditions in the policy that you then create include:

■ Service Request Status = 'Open'

■ Service Request Activity Component IS ADDED

If a workflow policy condition is IS ADDED or IS UPDATED, then the database triggers that are generated do not represent every condition defined in the policy. The database triggers that are not represented are ignored. This situation can be viewed by examining the trigger.sql file that is produced as a result of the comparison. This behavior is expected. If the condition is modified, then Generate Triggers must be run in order to implement the updated conditions.

Table 52. Specialized Comparisons

Comparison Value Explanation

IS ADDED Use IS ADDED with a workflow policy component column that is defined in the Condition field and when nothing is defined in the Condition value.

The workflow policy condition is met when an instance of the workflow policy component is added. For example, if the policy component column for the service request is defined in the Condition field, and if IS ADDED is defined in the comparison, then the condition is met when you create a new service request.

IS UPDATED Use IS UPDATED with a field that is defined in the Condition field, and when nothing is defined in the Condition value. The condition is met when the field changes.

For example, if the status of a service request is defined in the Condition field, and if IS UPDATED is defined in the comparison, then the workflow policy condition is met when the status for the service request changes. For more information, see “IS UPDATED in the Conditions List” on page 374.

IS DELETED Use IS DELETED when you define a child workflow policy component in the Condition field, and when nothing is defined in the Condition value.

A child workflow policy component is a workflow policy component that is associated with a parent workflow policy component in Siebel.

For example, a parent workflow policy component might be Service Request. A child workflow policy component might be Service Request Activity. If IS DELETED is used in conjunction with another workflow policy condition, then the other condition must be based on the parent workflow policy component. For more information, see “IS DELETED in the Conditions List” on page 374.



374

If using a workflow policy condition with a standard comparison, then the condition is encompassed in the database triggers that are generated. However, if using a specialized comparison, because Workflow Monitor Agent evaluates the condition at runtime, then database triggers on the tables do not include the standard comparison conditions.

IS UPDATED in the Conditions ListAlthough workflow policy conditions are joined when an IS UPDATED statement is present, the format of the trigger.sql statement that is generated for the condition does not contain AND within the SQL syntax.

If a condition that is defined in the workflow policy is violated when IS UPDATED is not present, then the Workflow Monitor Agent calls the policy. However, if an IS UPDATED comparison is included as criteria on a field, then other fields in the Policy conditions are not checked.

IS DELETED in the Conditions ListFor example, assume that if an activity is deleted from a service request that contains a Sub-Status of In Process, then you must notify a service request owner. Table 53 describes the configuration that you use in this case.

NOTE: If using IS DELETED, then the ROW_ID of the record that is deleted from the child workflow policy component is not tracked or logged in the S_ESCL_REQ table, nor can the Workflow Monitor Agent component determine exactly which row that was deleted caused the policy to be called. If you must define Siebel Workflow to capture the deleted row, then you must use a workflow process that is driven by a run-time event. The run-time event is the PreDeleteRecord event on the BusComp event object type.

Table 53. Example of Using IS DELETED

Policy First Condition Second Condition Action

Based on the Service Request Workflow policy object.

Condition is based on each of the following situations being true:

■ Field is Activity Component

■ Comparison is IS DELETED

■ Value is empty

Condition is based on each of the following situations being true:

■ Field is Service Request Sub-Status

■ Comparison is equal (=)

■ Value is In Process

Send an email to the SR owner.



Date Calculations in the Conditions ListWorkflow Monitor considers both date and time when evaluating a workflow policy condition that performs a date comparison. CURRENT can be used when a value is entered for a date comparison. The following format can be applied for using CURRENT:

CURRENT [+/-] d:h:m

where:

■ d represents the day

■ h represents the hour

■ m represents the minutes

For example, CURRENT + 01:02:03 is the value in CURRENT plus one day, two hours, and three minutes. You can use CURRENT in the comparison value for date fields. You can also use CURRENT when you define the activation and expiration dates for a broadcast message action.

For more information, see “Date Format with a Workflow Policy Program” on page 477.



376


15 Using a Predefined Workflow Policy

This chapter describes workflow policies and workflow policy programs that are predefined. It includes the following topics:

■ Configuring a Predefined Workflow Policy on page 377

■ Types of Workflow Policy Programs That Are Predefined on page 381

■ Examples of Workflow Policy Programs That Are Predefined on page 388

■ Workflow Policy Programs that Are Predefined for Siebel Marketing on page 393

Configuring a Predefined Workflow PolicyYou can use a predefined workflow policy to implement commonly used functionality. You can view these policies as groups in the Siebel client by navigating to the Administration-Business Process screen, then the Policy Groups view.

To view groups of predefined workflow policies for messaging


2 Choose Siebel Messaging in the Name column.

The messaging policies are displayed in the Policies list.

Configuring a Predefined Workflow Policy for MessagingYou can use a predefined messaging policy to display a message in a pop-up dialog box in the Siebel client. For example, the predefined Messaging Policy Send Screen Pop for Activity can be used to display a pop-up dialog that informs the end-user of a new activity.

To configure a predefined workflow policy for messaging


2 Choose Siebel Messaging in the Name column.

3 Locate the workflow policy you must use, such as Messaging Policy Send Screen Pop for Activity.

4 Set the Expiration field to NULL.


Using a Predefined Workflow Policy ■ Configuring a Predefined Workflow Policy

378

5 Run the Generate Triggers server component with EXEC = True and Remove = True.

For more information, see “Generating Database Triggers” on page 404.

6 Run Generate Triggers again, this time with Remove = False.

7 Navigate to the Messages screen, then the All Messages view.

8 Click New.

9 In the Last Name field, enter the name of the contact who receives the message.

10 In the Assigned To field, enter the name of the employee to which this user is assigned.

11 In the Message field, type the text message that displays in the pop-up dialog.

12 Set the Alert Type field to Screen Alert.

13 Click the Message Alert Setup tab, then make sure there is a corresponding entry for the message recipient and that Alert Type is set to Screen Alert.

If the message recipient is already defined, then perform the following steps:

a Click New.

b Set the Last Name field to the same name you set in Step 9.

c Set the Alert Type field to Screen Alert.

14 Start a Workflow Monitor Agent server task for the workflow policy group you activated in Step 5.

For more information, see “Executing a Workflow Policy with Workflow Monitor Agent” on page 417.

15 Verify the configuration:

a Define a test user when assigning the contact in Step 9.

b In a second client session, log in to the Siebel client as the test user.

c In the initial client session, insert a new activity for this user.

d In the second client session, verify the pop-up dialog that contains the message you entered in Step 11 displays.

Identifying the Source Table When Modifying an Existing Workflow PolicyWhen defining the types of workflow policies for your business, you might find that the predefined workflow policy objects do not contain the policy components you require. You can use the procedures in this topic as a general guideline to identify the source database table and column when modifying an existing workflow policy object.



Work you must perform before modifying a workflow policy object include:

■ Identify the names of the database table and column for the workflow policy object. If you are going to add or modify a component, then you must know the relationship between the component and the primary workflow policy component.

■ Make sure other records are not referencing this object that can be affected by your change. For example, before you inactivate a component column, make sure that no workflow policy conditions are referencing that component column.

The procedures in this topic are presented in the context of account objects.

To identify the database table

1 In the Siebel client, navigate to the appropriate workflow policy object view, which is the view that contains the business data you must monitor.

For example, if you must modify the workflow for an account activity, then navigate to the Accounts screen, Accounts List, then the Activities view.

2 From the application-level menu, choose the Help menu, then the About View menu item.

About View identifies the business object, business components, and applets that this view uses. In the example of the Account Activities view, the dialog box identifies Action as the business component that is used by the Activities list.

3 In Siebel Tools, navigate to the Business Components OBLE, then query the Name property for Action.

Note the value in the Table property. In this example, the table name is S_EVT_ACT. You use this table name when you define a workflow policy component.

Next, determine the relationship between the business component and the primary workflow policy component.

To determine the relationship between the business component and the primary workflow policy component

1 Navigate to the Business Objects OBLE, then query the Name property for Account.

2 Navigate to the Business Object Components OBLE, query the Bus Comp property for Action, then click the hyperlink in the Link Property.

The Source Field property is empty and the Destination Field property contains Account Id.

The value in the Link property identifies the link that defines the relationship between the Account and the Action business components. This Link defines the relationship between the parent Business Component and the child Business Component through the Source field and Destination field.

A Source Field property that is empty indicates that the join is using the ROW_ID column of the table that is defined in the Table property of the parent business component. The Destination Field property defines the field within the child business component that is a foreign key to the Business Component.



380

3 Click the hyperlink in the Child Business Component property.

Clicking this hyperlink navigates you to the Action business component in the Business Components OBLE.

4 In the Object Explorer, expand the Business Component tree, then click Field.

5 In the Fields OBLE, choose the Account Id field, then note the value in the Column property.

The Column property contains TARGET_OU_ID, which is the column in the table that the Account Id field references. You use this information when you define the workflow policy component.

Using a Predefined Workflow Policy ■ Types of Workflow Policy Programs That ArePredefined


Types of Workflow Policy Programs That Are PredefinedThis topic describes the types of predefined workflow policy program types that can be used in a workflow process. It includes the following topics:

■ Overview of Workflow Policy Programs That Are Predefined on page 381

■ Workflow Policy Program That Sends a Page on page 382

■ Workflow Policy Program That Sends an Email Message on page 383

■ Workflow Policy Program That Sends a Broadcast Message on page 384

■ Workflow Policy Programs That Execute a Database Operation on page 386

■ Workflow Policy Program That Runs an External Program on page 386

Workflow Policies comes with a number of predefined workflow policy programs that you can use to meet specific business requirements. This way, you can modify existing, predefined objects rather than define them from scratch.

Overview of Workflow Policy Programs That Are PredefinedA workflow policy program is a generic event on which actions are based. A workflow policy program defines the particular execution that occurs when the conditions of a workflow policy are met. To view object definitions for a predefined workflow policy program, navigate to the Workflow Policy Programs OBLE in Siebel Tools.

Table 54 describes workflow policy programs that are created from program types. It provides an inventory of predefined workflow policy programs, and describes common actions you can use by inserting your own message text.

Table 54. Types of Predefined Workflow Policy Program

Program Type Program Description

Send Page Send Page Sends a generic page message.

Send Opportunity Page Sends a page regarding an opportunity.

Send Quote Page Sends a page regarding a quote.

Send SR Page Sends a page regarding a service request.

Send Email Send Email Sends a generic email message.

Send Opportunity Email Sends an email regarding an opportunity.

Send Quote Email Sends an email regarding an opportunity quote.

Send SR Email Sends an email regarding a service request.


Using a Predefined Workflow Policy ■ Types of Workflow Policy Programs That Are Predefined

382

Workflow Policy Program That Sends a PageIf you choose the Send Page workflow policy program type in the Workflow Policies Actions list, then the Send Page Arguments form displays.

Send Broadcast Message

Send Message Broadcast Sends a generic broadcast message.

Send SR Message Broadcast

Sends a broadcast message regarding a service request.

Send Opportunity Message Broadcast

Sends a broadcast message regarding an opportunity.

Database Operation

Change SR Close Date to Today

Updates the close date of the service request to the date for today.

Change SR Owner Changes the owner of the service request.

Change SR Group Changes the group of the service request.

Change SR Owner to Manager

Changes the owner of the service request to the current manager for the owner.

Change SR Priority Changes the priority of the service request to a new value.

Change SR Severity Changes the severity of the service request to a new value.

Change SR Status Changes the status of the service request to a new value.

Change SR Sub-Status Changes the Sub-Status of the service request to a new value.

Create SR Activity Creates an activity for a service request.

Create Opportunity Activity Creates an activity for an opportunity.

Table 54. Types of Predefined Workflow Policy Program

Program Type Program Description



Table 55 describes arguments and values for the Send Page workflow policy program type.


■ Workflow policies automatically determine the correctly formatted message depending on the type of pager that is used by the person who is paged.

■ If neither of the message arguments contains a value, then Workflow Policies logs an error message and the action is not finished.

■ You can only send a page to an employee. The pager information for an employee is stored in the Employee Administration view. The Siebel database currently does not store pager information for contacts.

■ Values in a message that originate from the Available Substitutions field can be substituted.

Configurations That Define Numeric PagingNumeric paging is inherently unreliable because of a lack of a computer protocol for sending a numeric page. If you must send a numeric page, then you can use the Pager Pin field in the employee table in order to control the delay that occurs between dialing the paging phone number and sending the numeric message. Add commas to the Pager Pin field. Each comma is roughly equal to a half second delay. Avoid using the numeric paging feature in an application that is mission critical.

Workflow Policy Program That Sends an Email MessageIf you choose the Send Email workflow policy program in the Actions list, then the Send Message Arguments form displays along with the Recipients list. The Send Message Arguments form allows you to define an email template that is used to build the message which is sent to the recipient who is defined in the Recipients list.

Table 55. Arguments and Values for the Send Page Workflow Policy Program Type


Numeric Message Template

Numeric message when the pager is numeric.

Alpha Message Template

Text message when the pager is alphanumeric.

Current is a reserved word in Siebel Workflow. Do not use this word in a message.

Available Substitutions

Dynamic fields that you can use in the Alpha Message Template.

When the action executes, the substitution value is populated with the value from the record that meets the conditions for the workflow policy.



384

Table 56 describes arguments and values for the Send Email workflow policy program type.

How an Email Can Be Sent to an Email Address That is Held in a Custom FieldWorkflow Manager can be configured to send an email message to an email address that is defined in a custom field, including to an address that is stored in a column other than S_EMPLOYEE.EMAIL_ADDR. For more information, see 475546.1 (Doc ID) on OracleMetaLink 3.

Workflow Policy Program That Sends a Broadcast MessageIf the Send Message Broadcast workflow policy program is chosen in the Actions list, then the Send Message Broadcast Arguments form displays.

Table 56. Arguments for the Send Email Workflow Policy Program Type


Subject Subject line of the email message.

Message Template Text of the message.

The maximum length is 2000 characters, including variable substitutions.


Repeating Message The message that is repeated when the Consolidate flag is checked on the Workflow Policies view.


Available Substitutions A dynamic field that you can use in Subject, Message Template, and Repeating Message. If the action executes, then the substitution value is populated with the value from the record that meets the conditions of the workflow policy.



Table 57 describes arguments and values for the Send Broadcast Message workflow policy program type.

Activation of the Check New Broadcasted Message Workflow PolicyThe Check New Broadcasted Message policy monitors the S_BRDCST_MSG table and starts the Notify Broadcasted Message workflow process in order to broadcast a new message that is added to the table. If you use a workflow policy that contains a workflow policy program Type property that is set to Send Broadcast Message, and if you implement caching for the broadcast message on an object manager component, then you must activate the Check New Broadcasted Message workflow policy, which belongs to the Siebel Messaging policy group.


■ Activating a workflow policy, see “Overview of Generating Database Triggers” on page 403.

■ Configuring caching for a broadcast message, see Siebel Applications Administration Guide.

Consolidation of Messages That Are Sent Through the Send Broadcast Message Workflow Policy ProgramIt is not possible to consolidate multiple broadcast messages into a single message that is then displayed to an end user. A user receives every broadcast message that is sent by a workflow process, each as a separate message.

Table 57. Arguments for the Send Broadcast Message Workflow Policy Program Type


Activation Date and time for which the broadcast message is active.

The variable CURRENT can be used when defining the activation date. For more information, see “Date Calculations in the Conditions List” on page 375.

Expiration Date and time when the broadcast message expires.

The variable CURRENT can be used when defining the activation date. For more information, see “Date Calculations in the Conditions List” on page 375.

Abstract Short description of the broadcast message.

Message Template

Text of message to broadcast.

The maximum length is 2000 characters, including variable substitutions.


Severity Severity of message to broadcast.


Dynamic fields that you can use in the Abstract and Message Template.

If the action executes, then the substitution value is populated with the value from the record that meets the conditions of the workflow policy.



386

Workflow Policy Programs That Execute a Database OperationA number of database operation programs are predefined. You just define the parameters. If you choose a database operation program, such as Create Opportunity Activity in the Actions list, then the Arguments list displays.

Table 58 describes arguments and values for the Database Operation workflow policy program type.

Workflow Policy Program That Runs an External ProgramIf a Run External workflow policy program type is chosen in the Program field of the Actions list, then the External Programs Arguments list displays. For more information, see “Example of Defining a Workflow Policy Action That Runs an External Program” on page 354.

Table 58. Arguments for the Database Operation Workflow Policy Program Type


Name Name of column to be updated.

Required Indication that the argument is required.

Value Updated value of the column.

If a substitution is defined in the program, then you can use a substitution in the value. The syntax for adding a substitution to the value is square brackets around the variable. For example, [SR Num].



Table 59 describes arguments for the Run External workflow policy program type.

If no path is supplied for the Executable Name argument, then the executable is assumed to be in the current path of Workflow Policies running on the Siebel Server. For example, if your Siebel Server is installed on C:\siebsrvr, then the default path for the executable name is C:\siebsrvr\bin.

NOTE: The external program cannot be one that is interactive, requires a user interface, or accesses the Windows desktop.

Table 59. Arguments for the Run External Workflow Policy Program Type


Executable Name

Path and name of executable to run.

For example, the executable launches from the Siebel Server.

The executable can be a batch program.

Command Line

The command line to use.

Include the parameters that you must pass to the executable.

If passing multiple substitution parameters, then you must include a space between each parameter. For example:

"[FirstName]"^"[LastName]"

where:

■ ^ is a space

A substitution parameter that contains a space must be encased in quotes. The quotes are also passed as part of the parameter.

For more information, see Siebel Object Types Reference.

Execute Type Settings for Execute Type include:

■ Wait. Workflow Policies waits for the external program to finish, then examines the return code of the external program. If the return code is not 0, then an error occurs.

■ No Wait. Workflow Policies executes the external program in the background, then continues processing. The return code is not checked.

When using a Visual Basic program that generates files, set Execute Type to Wait in order to avoid possible corruption of files. If Execute Type is set to No Wait, then Visual Basic attempts to write files twice, thus corrupting the data.


Dynamic fields that can be used as command line parameters.

If the action executes, then the substitution value is populated with the value from the record that is in violation.


Using a Predefined Workflow Policy ■ Examples of Workflow Policy Programs That Are Predefined

388

Examples of Workflow Policy Programs That Are PredefinedThis topic includes examples of using predefined workflow policy programs. It includes the following topics:

■ Example of a Workflow Policy Program That Manages the SR Close Date on page 388

■ Example of a Workflow Policy Program That Assigns an SR Owner on page 389

■ Example of a Workflow Policy Program That Escalates an SR on page 390

■ Example of a Workflow Policy Program That Sends a Quote by Using a Page on page 392

■ Workflow Policy Programs that Are Predefined for Siebel Marketing on page 393.

The examples use predefined workflow policy programs that are included with Workflow Policies. These programs can be viewed in the Object Explorer in Siebel Tools by choosing the Workflow Policy Program object.

Example of a Workflow Policy Program That Manages the SR Close DateThis topic gives one example of using a predefined workflow policy program to automatically close SRs (service requests) that are marked as resolved but not closed. You might use this feature differently, depending on your business model.

Using this program, you can define a policy so that if a service request contains an activity of type Resolution, and if the service request is open for more than five days, then the service request close date is changed to the date for today. If the policy calls the workflow policy program, then the program enters the current system date into the Close Date field of the service request.

Table 60 describes arguments for the Change SR Close Date to Today workflow policy program.

Table 60. Arguments for the Change SR Close Date to Today Workflow Policy Program

Argument Name Description

Primary ID Contains the row ID of the service request that meets the conditions for the workflow policy.

Primary Table

Operation Type

Specifies the S_SRV_REQ table and the operation to execute the Update operation.

Using a Predefined Workflow Policy ■ Examples of Workflow Policy Programs That ArePredefined


Example of a Workflow Policy Program That Assigns an SR OwnerThis topic gives one example of using a predefined workflow policy program to automatically assign an SR that is not yet assigned. You might use this feature differently, depending on your business model.

If an open service request is not assigned for a certain length of time, then this workflow policy program can be used to assign, that is change the owner of, a service request to the person who is considered an expert in the area of the specific service request. This configuration allows the correct people to see the incoming service request and assign it appropriately.

This workflow policy program allows you to choose a new owner from a picklist and put it into the field of the service request that matches the condition for the workflow policy.

Sql Statement select sys_extract_utc(current_timestamp) from

&Table_Owner.S_DUAL

This statement calls the Siebel function now() to obtain the current date and uses the table &Table_Owner.S_DUAL to temporarily hold the value. The S_DUAL table is used to hold temporary values.

A math function can also be performed. For example, the SQL statement select {fn now()}+7 from &Table_Owner.S_DUAL returns the current date plus seven days.

Different RDBMS databases use different formats for the same function. For example, in MS SQL, the function GetDate() is used to return the current date.

NOTE: The column name length must be less than 30 characters. For example, the following statement violates this rule because it is more than 30 characters in length: TO_CHAR(CREATED,'dd month yyyy','NLS_DATE_LANGUAGE=FRENCH').

Sql Statement Outputs The value for the Today variable is obtained from the SQL statement.

New Close Date (Column) Specifies the column in the record to be updated (ACT_CLOSE_DT).

New Close Date Specifies the field to be updated to the value of Today.

Update Row ID The row ID of the record you must update. This argument is the same as the value of the Primary ID.

Table 60. Arguments for the Change SR Close Date to Today Workflow Policy Program




390

Table 61 describes arguments for the Change SR Owner workflow policy program.

Example of a Workflow Policy Program That Escalates an SRThis topic gives one example of using a predefined workflow policy program to assign an open SR (service request) to a manager. You might use this feature differently, depending on your business model.

If the service request is not closed within a specific duration of time, then assign the service request to the manager for the owner. This configuration allows a proper response time to service calls. Work performed by this workflow policy program includes:

■ Uses the Primary ID as input into a SQL statement

■ Uses a query SQL statement to retrieve the current value of the Manager field

■ Sets the New Owner field to default to the current value of the Manager field

■ Allows the user to optionally update the New Owner field through a picklist

Table 61. Arguments for the Change SR Owner Workflow Policy Program


Primary ID Contains the row ID of the service request that meets the condition for the workflow policy.

Primary Table

Operation Type

Specifies the S_SRV_REQ table and to execute the Update action.

New Owner (Column) Specifies to update the Owner_EMP_ID field in the record that is updated.

New Owner Indicates that a picklist is displayed for assigning a new owner.

The picklist is defined by the columns picklist that is set to Picklist SR Owner, the Source set to ID, and the Applet set to SR Owner Pick Applet.

Visible If checked, then indicates that the picklist is visible to the user.

Using a Predefined Workflow Policy ■ Examples of Workflow Policy Programs That ArePredefined


Table 62 describes arguments for the Change SR Owner to Manager workflow policy program.

Table 62. Arguments for the Change SR Owner to Manager Workflow Policy Program


Primary ID Contains the row ID of the service request that meets the condition for the workflow policy.

Primary Table

Operation Type

Specifies the S_SRV_REQ table and to execute the Update action.

New Owner (Column)

Specifies to update the Owner_EM_ID field in the record that is updated.

New Owner Indicates that a picklist is displayed for assigning a new owner.

Sql Statement Policy Monitor requires definitions that are contained in the workflow policy object, workflow policy components, and workflow policy columns. If working and coding a workflow policy program by using Siebel tables, then it is required that the base table be explicitly joined through SQL code.

The following example SQL statement joins four tables, thus providing access to data from these four tables:

SELECT MGRPOS.PR_EMP_ID FROM &TABLE_OWNER.S_POSTN POS, &TABLE_OWNER.S_EMPLOYEE EMP, &TABLE_OWNER.S_POSTN MGRPOS, &TABLE_OWNER.S_SRV_REQ SR WHERE SR.ROW_ID = ? AND SR.OWNER_EMP_ID = EMP.ROW_ID AND EMP.PR_POSTN_ID = POS.ROW_ID AND POS.PAR_POSTN_ID = MGRPOS.ROW_ID


■ Only one field is retrieved.

■ SR.ROW_ID = ? uses a question mark as a placeholder for inputting the value of the Primary ID. The Primary ID is substituted for the question mark.

Sql Statement Inputs

Set to the value of Primary ID.

Sql Statement Outputs

Set to the value of Manager.



392

Example of a Workflow Policy Program That Sends a Quote by Using a PageThis topic gives one example of using a predefined workflow policy program to automatically send a quote depending on the relationship between the value for the quote and the revenue value of the opportunity that the quote references. You might use this feature differently, depending on your business model.

If a created quote contains a value that is less than some percentage of the revenue for the opportunity, then it is considered heavily discounted, and a page is sent to a designated employee.

SQL Usage with This ExampleThis workflow policy program sends out a pager message. The SQL statement is configured for the different RDBMS syntax. The four SQL statements include one default and three that are specific to an RDBMS: Informix, Oracle, and SQL Anywhere. The default SQL Statement retrieves five values from four tables by using an outer join that is defined by *=:

select

q.QUOTE_NUM, q.REV_NUM, o.NAME, a.NAME, a.LOC

from

&Table_Owner.S_DOC_QUOTE q, &Table_Owner.S_ORG_EXT a, &Table_Owner.S_OPTY o

where

q.ROW_ID = ? and q.OPTY_ID *= o.ROW_ID and q.TARGET_OU_ID *= a.ROW_ID

The Oracle SQL Statement retrieves five values from four tables by using an outer join that is defined by (+):

select

q.QUOTE_NUM, q.REV_NUM, o.NAME, a.NAME, a.LOC

from

&Table_Owner.S_DOC_QUOTE q, &Table_Owner.S_ORG_EXT a, &Table_Owner.S_OPTY o

where

q.ROW_ID = ? and q.OPTY_ID = o.ROW_ID (+) and q.TARGET_OU_ID = a.ROW_ID (+)

The SQL Statement is required. However, if an SQL statement with <SQL style> is present, then this style takes precedence over the SQL Statement.

Output from the SQL statement defines five variables that hold the result of the query statement. These variables are Quote Number, Revision, Opportunity, Account, and Site. In an outer join, there might not be an associated table, in which case the variables are set to null.

Using a Predefined Workflow Policy ■ Workflow Policy Programs that Are Predefined forSiebel Marketing


Workflow Policy Programs that Are Predefined for Siebel MarketingThis topic describes how to use workflow policy programs in order to assist with the execution of a marketing campaign.

Overview of Workflow Policy Programs That Are Predefined for Siebel MarketingThe workflow policy programs in Siebel Marketing are designed to allow a marketer to define complex campaign policies in order to automate the different stages of the campaign. Actions are based on the type of workflow policy program that is used by Workflow Policies in order to define campaign policies. Workflow policy programs that generate actions in order to execute a campaign include:

■ Send Campaign Email. Sends an email to the contacts and prospects who are associated with a campaign.

■ Create Campaign Contact Activity. Generates an activity record for the contacts or prospects who are the target of the marketing campaign.

■ Assign to Campaign. Uses a contact or a prospect and assigns it to a chosen campaign.

Workflow Policy Program to Send Email for a Marketing CampaignThe Send Campaign Email workflow policy program provides a marketer the ability to send an email to the targets of the marketing campaign, such as contacts or prospects. Send Campaign Email uses Available Substitutions in the Send Message Arguments form, such as Prospect First Name, in order to allow for the personalization of campaign emails. You use the Recipients list in the Workflow Policy view in the Siebel client in order to choose the Recipient Type. The campaign contacts and prospects to whom the email is sent are visible in the Contacts/Prospects list in the Campaign Administration view.

Modifying Available SubstitutionsTo add a new substitution to the Available Substitutions list, you modify the SQL Statement Outputs property for the workflow policy program.

To modify available substitutions

1 In Siebel Tools, query the Name property of the Workflow Policy Programs OBLE for Send Campaign Email.

2 Right-click the Send Campaign Email workflow policy program, then choose Lock Object.

3 In the Workflow Policy Program Arguments OBLE, choose the SQL Statement Outputs property.

4 In the Default Value property, add the substitution.

The Default Value property contains a comma separated list of substitution variables. These variables hold the result of the query statement. The list that is defined in the Default Value property is displayed in the Available Substitution field in the Send Message Argument form.


Using a Predefined Workflow Policy ■ Workflow Policy Programs that Are Predefined for Siebel Marketing

394

Workflow Policy Program to Create Activities for a Marketing CampaignThe Create Campaign Contact Activity workflow policy program generates an activity record for the contacts or prospects who are the targets of the campaign. You use the Workflow Policy Program Arguments OBLE to define the data that populates the Contact Activity record.

Table 63 describes some values that can be assigned to arguments for the Create Campaign Contact Activity workflow policy program in order to generate email activity.

Workflow Policy Program to Assign a Contact to a Marketing CampaignThe Assign to Campaign workflow policy program adds the contact or prospect to the list of campaign contacts or prospects for the designated campaign.

Table 64 describes some of the values that can be assigned to arguments for the Assign to Campaign workflow policy program.

Example of Developing a Workflow Policy That Manages a Marketing CampaignThis topic gives one example of developing a workflow policy to manage a marketing campaign. You might use this feature differently, depending on your business model.

Table 63. Arguments for the Create Campaign Contact Activity Workflow Policy Program

Argument Value

Name Values for the Name argument include:

■ Description. Use text to describe activity.

■ Status. Choose the activity status, such as planned or active, from the picklist.

■ Type. Choose the Activity type from the picklist.

Required This value indicates whether the argument is required.

Value Text or picklist.

Table 64. Arguments for the Assign to Campaign Workflow Policy Program

Argument Value

New Campaign Picklist that allows you to choose a campaign to which you assign the contact or prospect.



To develop a workflow policy that manages a marketing campaign, perform the following tasks:

1 Defining Workflow Policy Actions for the Marketing Campaign on page 395.

2 Defining the Workflow Policy Group for the Marketing Campaign on page 397.

3 Defining Workflow Policies for the Marketing Campaign on page 397.

In this example, a marketer must run a two tier campaign with different work executed depending on how the campaign recipient responds. The marketer names the campaign CD-ROM Promotion. Ways that the marketer requires the campaign to work include:

■ An email is sent telling recipients they can receive a discount by ordering a new product over the phone. The marketer must keep track of the recipients and gives them two weeks to respond.

■ At the end of the two week period, recipients who did not respond to the offer are assigned to a new campaign.

Defining Workflow Policy Actions for the Marketing CampaignThis task is a step in “Example of Developing a Workflow Policy That Manages a Marketing Campaign” on page 394.

Workflow policy actions required for this example include:

■ Send Campaign Email. To send the offer email to the campaign recipients.

■ Create Campaign Contact Activity. To record the activity that is associated with the contact.

■ Assign to Campaign. To assign non respondents to a new campaign.

First, define a send campaign email action.

To define a send campaign email action



Field Value

Name Send First Campaign Contact

Program Send Campaign Email

Workflow Object Campaign Contact

Comment (Enter appropriate text, as necessary.)



396

3 In the Send Message Arguments form, define the argument using values from the following table.


This action is now available for use in a workflow policy.

Next, define a Create Campaign Contact Activity action.

To define a create campaign contact activity action

1 Navigate to the Administration-Business Process screen, then the Actions view.


3 In the Arguments list, define the Type argument using values from the following table.

The Type argument is required. You can also define additional optional arguments, such as Description or Status. For each additional argument you define, define a new record in the Arguments list, then define the field and value.

Next, define an Assign to Campaign Email action.

Field Value

Subject (Enter text and dynamic fields, as necessary.)

Message Template (Enter text and dynamic fields for sending email to Contacts.)

Field Value

Type (Choose a predefined Recipient.)

Name (Choose the appropriate recipient name.)

Field Value

Name First CD-ROM Campaign

Program Create Campaign Contact Activity



Field Value

Argument Type

Value (Define the type of contact activity for this action, such as In Store Visit, or Demonstration.)



To define an assign to campaign email action

1 Navigate to the Administration-Business Process screen, then the Actions view.


3 In the Arguments list, define the Type argument using values from the following table.

Defining the Workflow Policy Group for the Marketing CampaignThis task is a step in “Example of Developing a Workflow Policy That Manages a Marketing Campaign” on page 394.

Workflow policies must be assigned to a workflow policy group. Therefore, in this example, a workflow policy group is defined specifically for the marketing campaign.

To define the workflow policy group for the marketing campaign

1 Navigate to the Administration-Business Process screen, then the Policy Groups view.

2 In the Policy Groups list, add a new record using values from the following table.

Defining Workflow Policies for the Marketing CampaignThis task is a step in “Example of Developing a Workflow Policy That Manages a Marketing Campaign” on page 394.

After the workflow policy actions and the workflow policy group are defined, the workflow policies can be defined. In this topic, you define workflow policies for the marketing campaign and for assigning non respondents. When performing the procedures for defining the policies in this topic, pay careful attention to how the fields in the Conditions list are set.

Field Value

Name Assign to Campaign

Program Assign to Campaign



Field Value

Argument New Campaign

Value Not applicable

Field Value

Name CD-ROM Promotion

Comments group of policies for CD-ROM marketing campaign



398

Defining the Email for the Marketing Campaign PolicyThe policy that you define in this topic calls for the sending of the offer email and the activity record for the email.

To define the email for the marketing campaign policy


2 In the list for the Policies List, define a new record using values from the following table.

The Policy Group you define in this step is the group you created in “Defining the Workflow Policy Group for the Marketing Campaign” on page 397.

3 In the Conditions list, to define the name, define a new record using values from the following table.

4 In the Conditions list, to define the Start Date, define a new record using values from the following table.

Field Value

Name Email for CD-ROM campaign


Policy Group CD-ROM Promotion

Duration 0

Field Value

Condition Field Name

Operation =

Value 1st CD-ROM Promotion

Field Value

Condition Field Start Date

Operation =

Value (Enter the date on which the campaign starts sending messages to the target audience.)



5 In the Conditions list, to define the Campaign Status, define a new record using values from the following table.

The Launched value starts the campaign.

Next, define the Assign Non-Respondents policy.

Defining the Assign Non Respondents PolicyThe policy that you define in this topic starts the reassignment of non respondents to a new campaign.

To define the assign non respondents policy


2 In the list for the Policies List, define a new record using values from the following table.

3 In the Conditions list, to define the Name, define a new record using values from the following table.

Field Value

Condition Field Campaign Status

Operation =

Value Launched

Field Value

Name Non-Respondents of CD-ROM campaign


Policy Group CD-ROM Promotion

Duration 14

Field Value

Condition Field Name

Operation =

Value 1st CD-ROM Promotion



400

4 In the Conditions list, to define the Campaign Status, define a new record using values from the following table.

5 In the Conditions list, to define the Done Flag, define a new record using values from the following table.

Defining Logic That Calls the Assign Non Respondents PolicySetting Done Flag to N flags the activity record for this recipient as requiring additional attention. If the Policy duration is set to 14 days and Done Flag is equal to N, then the policy executes in 14 days. Members of the target audience who did not respond to the first campaign are assigned to a new campaign after 14 days.

Field Value

Condition Field Campaign Status

Operation =

Value Launched

Field Value

Condition Field Done Flag

Operation =

Value N


16 Administering a Workflow Policy

This chapter describes how to administer a workflow policy. It includes the following topics:

■ Administering a Workflow Policy on page 401

■ Testing, Troubleshooting, and Migrating a Workflow Policy on page 440

Administering a Workflow PolicyThis topic describes administration work that is relevant to workflow policies. It includes the following topics:

■ Confirming the Installation of Workflow Policies on page 401

■ Administering Database Triggers on the Workflow Policy Server on page 402

■ Administering Email Manager and Page Manager on page 409

■ Executing a Workflow Policy with the Workflow Action Agent on page 415

■ Executing a Workflow Policy with Workflow Monitor Agent on page 417

■ Defining a Workflow Policy to Run in Batch Mode on page 428

■ Moving a Workflow Policy to a Different Group on page 431

■ Expiring a Workflow Policy on page 432

■ Deleting a Workflow Policy That Is Obsolete on page 434

■ Tracing and Reporting a Workflow Policy on page 436

■ Guidelines for Converting a Workflow Policy to a Workflow Process on page 439

Confirming the Installation of Workflow PoliciesIn this topic, you make sure workflow policies are installed correctly. The Workflow Policies module is installed as part of the Siebel Server and client installation and is activated by using your license key. This topic only describes how to make sure Workflow Policies is correctly installed. For information about the installation process, see the installation guide for the operating system you are using.

To use Workflow Policies, make sure Siebel Server components, including Workflow Management, Siebel Tools, and the Siebel client, are installed.


Administering a Workflow Policy ■ Administering a Workflow Policy

402

Confirming the Repository Setting for An Installation of Workflow Policies In the Siebel client, the cfg file is used to configure the Workflow Policies module. You must make sure the DockRepositoryName parameter of this cfg file specifies the correct repository name.

Confirming Siebel Workflow is Set Up for Workflow PoliciesYou must make sure that your license key includes Siebel Workflow. You must also make sure the Siebel Server is installed properly because Siebel Workflow runs as a server component on the Siebel Server.

To confirm Siebel Workflow is set up for workflow policies

1 Log in to the Siebel client as the Siebel administrator.

2 Navigate to the Administration-Business Process screen.

Under the list of views, the Policies, Policy Groups, and so forth are visible. This visibility indicates that your license key is correct.

3 From a Siebel client that is configured to manage the server component groups, navigate to the Administration-Server Management screen, Servers, then the Component Groups view.

4 Make sure the Workflow Management component group is activated.

Administering Database Triggers on the Workflow Policy ServerThis topic describes how to administer database triggers on the workflow policy server. It includes the following topics:

■ Overview of Generating Database Triggers on page 403

■ Generating Database Triggers on page 404

■ Guidelines for Generating Database Triggers on page 407

■ Database Triggers and Remote Users on page 407

■ Database Triggers and Database Administration on page 407

■ Usage of the S_ESCL_REQ Table on page 408



Overview of Generating Database TriggersThe Generate Trigger (GenTrig) component on the Siebel Server allows you to generate database triggers. Workflow Policies uses database triggers to identify which records match workflow policy conditions. You can run the Generate Triggers component when you must perform one of the following:

■ Define or delete new policies, including assignment policies, except for workflow policies with the Batch Flag set to TRUE

■ Amend workflow policy conditions or policy criteria

■ Change activation or expiration dates of policies, including assignment policies

Example of Behavior of Generate Triggers for a Workflow Policy That Contains Multiple ConditionsIf two or more workflow policy conditions are used in a workflow policy, then Generate Triggers uses OR logic instead of AND logic.

Table 65 describes example workflow policy conditions to use in order to create a workflow policy that is based on the Account object.

Multiple database triggers that are generated for multiple workflow policy conditions of one workflow policy is expected behavior. This technique separates the functionality of Generate Triggers and Workflow Monitor Agent. Generate Triggers simply monitors changes that are made to database records and inserts records into tables that are specific to a workflow policy. Workflow Monitor Agent evaluates violations, determines if the conditions that are associated with the rule for the violation are met, and executes the actions that are associated with a policy.

You cannot use AND between database triggers that are generated for multiple workflow policy conditions of a workflow policy, because Generate Triggers can monitor only database changes, and database changes that violate different conditions might not be concurrent. Therefore, using an AND condition causes Generate Triggers to miss many violations.

For example, assume a workflow policy contains the following workflow policy conditions:

■ SR area is Network

■ Activity Priority is 1-ASAP

Two database triggers are generated. One database trigger monitors an SR that is created or updated, and checks if the area equals Network. The other database trigger monitors an activity that is created or updated, and checks whether the Priority equals 1-ASAP.

Table 65. Example of Workflow Policy Conditions

Property Condition 1 Condition 2

Condition Field Account Modification Num Account Last Update By

Operation > <>

Value 0 0-1



404

But if you use AND database triggers and an end user creates an SR without an activity, then the database trigger is not violated because the activity does not exist. If later, a user adds an activity to the SR, then there still is no database trigger violation because the SR record does not change. This violation is missed due to use of AND logic. However, if you use OR for the database triggers and Workflow Monitor Agent evaluates the workflow policy condition, even though there are multiple violations in the S_ESCL_REQ table, then the Workflow Monitor Agent only processes one request because the other requests do not evaluate to TRUE.

Generating Database TriggersThis topic describes how to generate database triggers with the Generate Triggers server component. You can run the Generate Triggers server component from the Siebel client or from the command line. Both the Siebel client and the command line use the same parameters. The database triggers are only there in order to generate indicators for the Workflow Engine to check conditions for the policies.

CAUTION: If you incorrectly define a workflow policy condition, then running Generate Triggers can result in an invalid database trigger. An invalid database trigger can prevent execution of normal user transactions. For this reason, thoroughly test your workflow policy in a test environment before you migrate it to a production environment.

To generate database triggers

1 Make sure you meet the prerequisites for running the Generate Triggers server component.

a Make sure the Siebel Server is installed.

b Make sure the Siebel client is configured to access the Siebel Server Administration screens.

For more information on installing Server Manager, see the installation guide for the operating system you are using.

2 In the Siebel client, navigate to the Administration-Server Management screen, then the Jobs view.

3 In the Jobs list, click New.

4 In the drop-down list for the Component/Job field, choose Generate Triggers.

This step creates a new line entry but does not start the server task.



5 In the Job Parameters list, click New to modify component specific parameters, using values from the following table.

For a description of generic and enterprise parameters, see Siebel System Administration Guide.

6 Enter the Privileged User name and password.

7 In the Job Detail form, from the applet-level menu, choose Start Job.

8 To view changes to the state, refresh the screen by clicking Run Query from the applet menu.

Upon completion, the Status field contains Success or Error. You can view the log details.

9 (Conditional) If EXEC equals FALSE, then you must manually run the SQL script file.

For more information, see “Manually Running the SQL Script File” on page 406.

Name Value Usage

Remove TRUE or FALSE (default)

Set to TRUE in order to generate DROP TRIGGER statements to clean up the database triggers. Remove does not generate CREATE TRIGGER statements.

Trigger File Name

Valid filename on the Siebel Server

Define the name and output location for the SQL script file. The default is TRIGGER.SQL. The file is generated, then placed in the root directory of the Siebel Server during installation.

EXEC TRUE or FALSE (default)

Set to TRUE in order to run the SQL script file automatically.

Set to FALSE in order to run the SQL script manually.

For more information, see “Usage of the EXEC Parameter” on page 406.

Mode ALL, WORK, or ASGN

The following settings are available for the Mode parameter:

■ ALL. Generates database triggers for workflow policies and Assignment Manager.

■ WORK. Only generates database triggers for workflow policies.

■ ASGN. Only generates database triggers for Assignment Manager.

Privileged User Name and Privileged User Password

Assigned Privileged User name and password

Define the user name and password in order to make sure the end user enters a Privileged User name and password. The Table Owner is considered a Privileged User, so you can enter the Table Owner name and password in the Privileged User name and password fields.



406

Usage of the EXEC ParameterThe EXEC parameter specifies whether the SQL script file runs automatically or manually. If TRUE, then the Generate Trigger server component automatically generates the SQL script and applies it to the server database. If FALSE, then you must manually run the SQL script file.

Environments in which you must set EXEC to FALSE include:

■ You run a Sybase server with a Siebel or MS_SQL server. Setting EXEC to false prevents an end user who is connected from receiving an error message when Siebel generates database triggers. Make sure nobody is logged in to the database before you generate database triggers.

■ When you define a large number of database triggers because there are too many workflow policies.

In both cases, you must manually run the SQL script file and not use the Generate Triggers server component. For more information, see “Manually Running the SQL Script File” on page 406.

Manually Running the SQL Script FileAfter Generate Triggers finishes, if the EXEC parameter is FALSE, then run the SQL script file.

To manually run the SQL script file

1 Use the SQL tool provided by your RDBMS vendor to connect to the database server as the Siebel table owner.

For example, ISQL for Microsoft or SQL*Plus for Oracle.

2 Run the SQL script file that is defined by the Trigger File Name parameter.

The default filename is TRIGGER.SQL. The default location of this file is the root of the directory in which the Siebel Server is installed. For example:

C:\siebsrvr\trigger.sql

If you are using an MS SQL server database, then execute the trigger.sql script as the database owner login for the Siebel database. The database owner login is also known as the dbo login.

3 Make sure no errors are reported.

For example, assume you finished defining workflow policies in the Siebel client and you must set the database triggers in the Siebel database for the new policies. Using the Generate Triggers component, you set the file output name, thus creating a TRIGGER.SQL file that contains the database triggers that must be modified or defined in the test database for these policies. You then run the following command in SQL*Plus to generate the database triggers in the Oracle database:

SQL>@<path>\mytrig.sql

The successful creation of each database trigger in the Oracle database is indicated on the screen. For information on the syntax that is required for other databases, see your database documentation.



Guidelines for Generating Database TriggersGuidelines for running the Generate Triggers server component, especially if you are deleting a workflow policy, include:

■ If deleting a workflow policy, then running Generate Triggers does not remove the database trigger. If you delete a policy, then you must run Generate Triggers with the remove parameter set to TRUE, thus removing every database trigger. You must then rerun Generate Triggers in order to reset the database triggers for existing policies.

■ You must stop and restart the workflow monitor agents when running Generate Triggers.

■ If you change a workflow policy condition or a workflow policy group, then you must rerun Generate Triggers. It is not necessary for you to rerun Generate Triggers when you change a workflow policy action. For more information, see “Moving a Workflow Policy to a Different Group” on page 431.

■ For SQL Server, set your default database correctly. To determine your default database, launch the SQL Server Enterprise Manager, then navigate to the SQL Server Machine name. Next, click Security, then click LOGIN. The default database is listed to the right.

■ If you drop or regenerate database task triggers, then you must start a new Workflow Monitor Agent server, thus refreshing the cache for the Workflow Monitor Agent in order to account for the new changes in the monitored policy.

■ If a table name exceeds 18 characters, then Generate Triggers fails with the error 18 character limit, table_name trigger fail. When running Generate Triggers, there is an 18 character limit for table names. This error is caused by a DB2 SQL limitation for database trigger names that are limited to 18 characters. The name of the database trigger is derived from the table name plus a suffix, such as U, I, D, U1,I1,D1, and so forth.

Database Triggers and Remote UsersWhen a remote user synchronizes, the changes are incorporated into the database. For example, account information in the S_ORG_EXT table is updated upon synchronization. If you run a workflow process that generates database triggers which compares changes in the database against a specific workflow policy condition, and if the changes are of interest to the condition during synchronization, then the database triggers fire and rows are written to the S_ESCL_REQ table.

Database Triggers and Database AdministrationIt is important to keep your database administrators informed of database triggers that are active for a workflow process, because a database Update or Insert event causes the database trigger to react, regardless of how the event is executed. For example, if there are inserts to the S_SRV_REQ table, and if the database administrator performs a table export and import of these records, then the database triggers treat every record in the database as if it is a newly inserted record, which can result in an inappropriate modification to old records that were simply imported again.

NOTE: With the 8.1 release, the Generate Triggers server task requires the Privileged User Name and Password instead of Table Owner ID and Password.



408

Usage of the S_ESCL_REQ TableIf a database trigger fires against a workflow policy condition, then a record is inserted in the S_ESCL_REQ table, which is the escalation request table. This table contains the rows in the database that can cause a workflow policy to execute. After the Workflow Monitor Agent processes a request, it removes the row from this table.

Frequently, because of the way database triggers are generated, the logic that is defined in the condition for a workflow policy is not included on the database trigger itself. Also, the conditions in the database trigger file might not be indicative of the workflow policies that are violated. When Workflow Monitor Agent is run, the records in the S_ESCL_REQ table causes Siebel Workflow to evaluate the conditions for the related policy. Therefore, the database triggers are only there to generate indicators for the Workflow Engine to check the conditions for the workflow policy.

For more information about how the S_ESCL_REQ table is used, see “Workflow Monitor Agent” on page 417.

Remedies to Address Problems That Involve the S_ESCL_REQ TableRemedies to avoid or fix problems in the S_ESCL_REQ table include:

■ Use your database tools to monitor the size and efficiency of the table.

■ If the table is very large, then this situation indicates that too many policies are monitored and a new process for workflow policies must be defined in order to share the load.

■ If rows are monitored and not removed after the time interval is met, then this situation can indicate that a policy was deactivated without removing the database triggers. The database triggers are continuing to send data that is not acted on by an instance of a workflow policy.

■ If defining a new business component, then do not set the Table property to the S_ESCL_REQ table. A business component cannot be based on the S_ESCL_REQ table.

■ Expire, rather than delete a workflow policy. For more information, see “Expiring a Workflow Policy” on page 432.

■ Remove rows that belong to obsolete workflow policies. For more information, see “Deleting a Workflow Policy That Is Obsolete” on page 434.



Administering Email Manager and Page ManagerThis topic describes how to administer email manager and page manager. It includes the following topics:

■ About Setting Up the Siebel Server for Email Manager on page 409

■ Setting Up the Communications Profile to Send Email Through a Workflow Process on page 409

■ Starting Email Manager on page 410

■ Running the Page Manager Server Component on page 411

■ Parameters of the Page Manager Server Component on page 413

■ Troubleshooting Email Manager and Page Manager on page 414

About Setting Up the Siebel Server for Email ManagerSome actions for a workflow policy allow you to send an email message to a specific individual. Items to consider include:

■ If sending email using a workflow policy through a mail system that is compliant with SMTP or POP3, then make sure that SMTP and POP3 are working properly on the network.

■ Make sure the Email Manager component of the Siebel server is running. This component is part of the Communications Management component group, which must be configured.

■ Make sure the profiles that are set up in the Communications Manager are configured correctly to log in to a mail system that is compliant with SMTP or POP3. Email Manager uses these profiles. The Communications Outbound Manager verifies the profile.

■ Make sure the Mail Profile parameter is set to the name of the communication profile you use for sending the email.

Date Format in an Email MessageA workflow policy program is executed by the Siebel server, which connects to Oracle through ODBC. As part of this process, the required data is retrieved from the database through this connection. The format of a date in an email message is the format returned from the ODBC driver, which might be different from that used by Oracle.

Setting Up the Communications Profile to Send Email Through a Workflow ProcessSending email through Siebel Workflow involves defining a communications profile.

NOTE: To define a new communications profile, CompGrp CommMgmt must be configured. Make sure it is configured before you perform the procedure described in this topic. For more information, see Siebel Communications Server Administration Guide.



410

To set up the communications profile to send email through a workflow process

1 In the Siebel client, navigate to the Administration-Communications screen, then the Communications Drivers and Profiles view.

2 In the Communications Drivers list, query the Name field for the Internet SMTP/POP3 Server communications driver.

3 Click the Profiles view tab.

4 Define a new profile named [Profile Name].

5 In the Profile Parameters Overrides list, define records for parameters using values from the following table.

For details on these parameters, see Siebel Communications Server Administration Guide.

After you define the communications profile, you must define the component definition of Email Manager. The Email Manager component executes email actions after the conditions of a workflow policy are met.

Starting Email ManagerYou can start Email Manager from the command line or from the Server Configuration view in the Siebel client.

To start Email Manager from the command line■ To start the Email Manager server task with the [Profile Name] profile, issue the following

command in the server manager command line:

start task for comp MailMgr with MailProfile=<Profile Name>

Parameter Usage

From Address Define the email address of the sender for outbound communications.

POP3 Account Name Define the account name for the POP3 mailbox from which to retrieve inbound communications.

POP3 Account Password

Define the password for the POP3 mailbox account.

POP3 Server Define the host name or IP address of the machine on which the Internet POP3 server is running, as appropriate for your network configuration.

SMTP Server Define the host name or IP address of the machine on which the Internet SMTP server is running, as appropriate for your network configuration.



To start Email Manager from the server configuration view

1 Navigate to the Administration-Server Configuration screen, Servers, then the Components view.

2 In the Components list, locate the Email Manager component.

3 In the Component Parameters list, set the Mail Profile field to Test.

4 Set the Default Tasks component parameter to 1.

This step automatically begins a server task for Email Manager when the component is restarted or when the Siebel Server services are restarted.

How Outbound Communications Manager Sends EmailThe Outbound Communications Manager sends email messages according to the following sequence:

1 If the workflow policy is violated, then Workflow Monitor Agent inserts a record into the S_APSRVR_REQ table for workflow actions that call the Send Email workflow policy programs.

2 Email Manager picks up records from the S_APSRVR_REQ table, setting the status for each record from QUEUED to ACTIVE, then to SUCCEEDED during the course of the execution.

3 Outbound Communications Manager is called to log onto the [Profile Name] profile.

4 Outbound Communications Manager uses the Send Message method of the Outbound Communications Manager business service in order to send emails to recipients.

Mail Profile ParameterThe Mail Profile parameter specifies the mail profile to use and is defined in the Control Panel. The parameter establishes the connection between the application and the email system. If you do not define a profile, then the default profile is used. The names must match exactly.

Running the Page Manager Server ComponentSome workflow policy actions allow you to send a page message to a specific individual. The Page Manager server component of the Siebel server must be running in order for you to send a page. You can page a specific individual who uses an alphanumeric or numeric pager. Prerequisites to send a page using a workflow policy include:

■ Access to a local or network modem is provided for the server that is running the Page Manager component.

■ The Page Manager component of the Siebel server is running. Several parameters, similar to the dial-up networking set up in Windows, must be set prior to running the Page Manager component.

■ The appropriate telephone numbers for paging are entered in the Employee view. These numbers are used by Siebel Workflow.

■ The regional configuration is changed in order to avoid inputting the country code prior to the telephone number. Inputting the country code prior to inputting the telephone number can cause an error.



412

■ The PAGE_TYPE list of values parameters is changed in order to force the page manager to accept an alphanumeric send, thus displaying the language and the value.

NOTE: Alphanumeric paging is more reliable than numeric paging because the pager message is transmitted by a computer that resides at the company that provides pager services. This situation is not true for numeric paging, where a pager message is sent by emulating key presses on a telephone. A failure in sending a numeric pager message is very difficult to detect.

The Page Manager component uses the Telocator Alphanumeric Protocol (TAP) industry standard protocol for alphanumeric paging. To determine the phone number in which to send your alphanumeric page, check with the company that provides pager services.

Several parameters affect how the Page Manager component interacts with the modem. The parameters that can be changed are listed in the Server Administration screen. The modem parameters are the defaults for Hayes compatible modems. Make sure the settings are compatible with your modem.

To run the Page Manager server component



3 In the drop-down list for the Component/Job field, choose the Page Manager server component.

4 In the Job Parameters list, click New.

5 Click Parameters in the Server Tasks list, then enter your parameters.

For a list of parameters, see Table 66 on page 413.



Parameters of the Page Manager Server ComponentThe most important parameters are Modem Port, Dial Prefix, Long Distance Prefix, and Local Area Code. Change the values for these parameters to match your system. Table 66 describes default values that are used if you do not define a parameter.

Table 66. Parameters of the Page Manager Server Component

Parameter Description Usage

Modem Port The Component Object Model (COM) port where the modem is attached.

Default is COM1.

Valid values are COM1, COM2, and so forth.

Dial Prefix A number or sequence of numbers that must be dialed in order to acquire an outside line.

Default is 9.

If no dial-out prefix is used, then insert a comma (",").

If dialing 9 for an outside line is not required, and if you are using srvrmgr.exe from the command line, then defining a comma for this parameter returns an error. However, if you define a hyphen, or another character that cannot be dialed, then an error is not returned.

The following is an example command:

SRVRMGR.EXE /g NT01022 /e SBLPRD_ENT502 /s SBLPRD_APP502 /u ***** /p ***** /c "START TASK FOR COMPONENT PageMgr WITH DialPrefix = '-'"

Long Distance Prefix

The long-distance prefix.

Default is 1.

This value is added in front of long-distance phone numbers. If your location does not require a long-distance prefix to be dialed, then set this parameter to equal an empty string.

Local Area Code

The area code of your location.

Default is [empty].

If the beginning digits of a phone number are equal to this code, then they are removed before the phone number is dialed, and the long-distance prefix is not added.

Delay1 The number of seconds to wait between dialing a phone number and simulating key presses for the first set of numbers.

Default is 12.

Applies only to numeric paging. It is ignored for alphanumeric paging.



414

Troubleshooting Email Manager and Page ManagerWhen troubleshooting Email Manager and Page Manager, note the following situations:

■ If Email Manager is unable to log on to the mail server that is compliant with SMTP or POP3, then Email Manager stops processing and logs an error message in the trace files.

■ If Email Manager is able to log on but encounters a problem sending a particular email, then it logs an error message and continues on to the next request.

■ If the modem is not available, then Page Manager stops processing. The requests continue to accumulate in the Requests table. After you fix the processing problems, you must restart the servers. The servers continue processing from the point where they were interrupted.

■ If Page Manager is able to interface with the modem but encounters a problem with a page send, then it logs an error and moves on to the next request.

Delay2 The number of seconds to wait between simulating key presses for the first and second set of numbers.

Default is 4.

Applies only to numeric paging. Situations in which it is ignored include:

■ Alphanumeric paging

■ When the numeric pager does not contain a Personal Identification Number (PIN)

Modem Reset String

The modem command that is used to reset the modem.

Default is ATZ.

To determine the correct command, see your modem documentation.

Modem Init String

The modem command that is used to initialize the modem.

Default is AT&FQ0V1.

To determine the correct command, see your modem documentation. For example, some modems require a numeric value after &F.

Modem Dial String

The modem command that is used to dial the modem.

Default is ATDT.

This parameter is rarely changed.

Modem Hangup String

The modem command that is used to hang up the modem.

Default is ATH.


Modem Restore String

The modem command that is used to restore the power-up settings of the modem.

Default is AT&F.


Table 66. Parameters of the Page Manager Server Component

Parameter Description Usage



■ If a workflow policy executes email and paging actions, then it inserts email requests and paging requests into the database. These requests are inserted as records in the S_APSRVR_REQ table, which are then processed by Email Manager and Page Manager.

New requests contain a status of QUEUED. After a request is picked up by Email Manager or Page Manager, but before it is processed, it contains a status of ACTIVE. After a request is processed, the status for the request is SUCCEEDED if the processing is successful, or FAILED if an error occurs.

■ To generate sending emails, Siebel Server uses the UNIX Mail command.

Making Sure the Server Platform Can Run the Command to a Valid RecipientThis topic describes how to make sure your server platform can run the command to a valid recipient, and to make sure email was successfully sent.

To make sure the server platform can run the command to a valid recipient

1 From the UNIX command prompt, type the following command:

>mail recipient email address

where:

■ recipient email address is a valid address

2 Type a message that ends with a period on the last line to indicate the end of the message.

3 Press enter.

4 If email that is written to the S_APSRVR_REQ table is not sent, even though the Email Manager trace file displays status SUCCEEDED, then make sure the following Outlook settings on the server are set:

■ Send messages immediately

■ Check for new messages every [x] minutes

Both of these options must be configured in Outlook in order for an email message to be sent successfully.

Executing a Workflow Policy with the Workflow Action AgentThe Workflow Action Agent process submits a request to Email Manager and Page Manager when an action is to be executed.

NOTE: You must define a component definition for each Workflow Action Agent server task.

Work performed by Workflow Action Agent includes:

■ Processes requests that are logged in the S_ESCL_ACTN_REQ table for a single group. The S_ESCL_ACTN_REQ table is the escalation action request table.



416

■ Calls actions that are linked with the workflow policy that is processed for Siebel Workflow.

■ Logs email and page actions in the S_APPSRVR_REQ table for execution by Email Manager and Page Manager.

■ Purges requests from the S_ESCL_ACTN_REQ table after processing.

If the Use Action Agent parameter is set to TRUE in the Monitor Agent process, then you must perform the work described in “Starting the Workflow Action Agent” on page 416.

Starting the Workflow Action AgentStart the Workflow Action Agent in the same way that you start the Workflow Monitor Agent. For more information, see “Defining a New Workflow Monitor Agent Server Component” on page 419.

Guidelines for starting the Workflow Action Agent include:

■ For each Workflow Monitor Agent, there is a Workflow Action Agent. For each Workflow Monitor Agent, start only one Workflow Action Agent.

■ If using email consolidation, and if the Use Action Agent parameter is set to TRUE on the Workflow Monitor Agent, then you must start Workflow Action Agent separately.

For more information on starting Workflow Action Agent, see Siebel System Administration Guide.

Shutting Down the Workflow Action AgentYou shut down the Workflow Action Agent in the same way that you shut down the Workflow Monitor Agent. For more information, see “Defining a New Workflow Monitor Agent Server Component” on page 419.

If restarting a workflow policy process, then a Workflow Action Agent process immediately begins tracking relevant activities that occurred since it was shut down.

Using Workflow Action Agent for Batch PoliciesYou can run Workflow Action Agent separately for batch policies.

To use workflow action agent for batch policies

1 Start Workflow Monitor Agent with the following parameters:

■ Group Name

■ Processes the batch policies is TRUE

■ Use Action Agent is TRUE



2 Start Workflow Action Agent with the Group Name parameter.

The Workflow Monitor Agent continues processing, and puts the qualified rows in the S_ESCL_ACTN_REQ table. The Workflow Action Agent executes actions for rows in the S_ESCL_ACTN_REQ table, and deletes the rows from the S_ESCL_ACTN_REQ table afterward.

If the executed action persists for a long time or is intensive, then the Workflow Action Agent might be of use. However, in general, Workflow Action Agent does not help with a batch policy.

Executing a Workflow Policy with Workflow Monitor AgentThis topic includes the following topics:

■ Workflow Monitor Agent on page 417

■ Replication with the Workflow Monitor Agent on page 419

■ Starting Workflow Monitor Agent on page 419

■ Stopping or Restarting a Component of the Workflow Monitor Agent on page 421

■ Keeping Definitions for Workflow Monitor Agent Current on page 422

■ Command Line Interface Parameters of the Workflow Monitor Agent on page 423

Workflow Monitor AgentWorkflow Monitor Agent checks when the conditions of a workflow policy is met, and executes actions after conditions are met. To execute your workflow policies, you must start Workflow Monitor Agent. You start and stop the Workflow Monitor Agent server task in the Administration-Server views.

Table 67 describes some of the database tables that are involved with workflow policies.

Table 67. Database Tables That Are Involved with Workflow Policies

Table Name Description

S_ESCL_REQ Escalation request. This table holds the potential matching requests that are caused by an application. For more information, see “Usage of the S_ESCL_REQ Table” on page 408.

S_ESCL_STATE Escalation state. This table holds the policy matches that are based on time.

S_ESCL_ACTN_REQ Escalation action request. (Optional) This table holds the requests to execute actions, which is only used when Use Action Agent is set to TRUE.

S_ESCL_LOG Escalation log. This table holds a history of rows in the base table with matched policies.



418

Work Performed by the Workflow Monitor AgentWorkflow Monitor Agent executes several server processes that monitor the Siebel database. Work performed by Workflow Monitor Agent includes:

■ Checks the S_ESCL_REQ table to determine when the conditions of a policy are met.

■ Monitors policies within a single group.

You can only run one process of the Workflow Monitor Agent against a specific group at one time. You can run multiple processes of the Workflow Monitor Agent at the same time, but they must be against different groups. If you run two processes of the Workflow Monitor Agent against the same group, then a deadlock can occur.

■ Generates requests for Workflow Action Agent in the S_ESCL_ACTN_REQ table. This situation occurs if you set Action Agent to True.

■ Purges requests from the S_ESCL_REQ table after processing. If a database trigger is activated because a workflow policy condition is met, then a record is inserted into the S_ESCL_REQ table, which is the escalation request table. Workflow Monitor Agent (WorkMon) evaluates the request against the rules that are established by the policies in the workflow policy group.

If you set Action Agent to True, and if Workflow Monitor Agent determines that the request in the S_ESCL_REQ table contains no duration defined in the policy, then the Workflow Monitor Agent takes direct action and logs an entry into the S_ESCL_LOG table or sends it to the S_ESCL_ACTN_REQ table.

If Workflow Monitor Agent determines that the request includes a time element that must be met, then the request is sent to the S_ESCL_STATE table along with the expiration time. The request remains in the S_ESCL_STATE table until the expiration time is met, or until the request is removed because the conditions of the policy are no longer met. Workflow Monitor Agent evaluates each of the requests that remains in the S_ESCL_STATE table for a time duration match or to determine if the condition still matches in the S_ESCL_STATE table. If you set Action Agent to True, then as each match occurs, Workflow Monitor Agent takes direct action and logs an entry into the S_ESCL_LOG table or sends it to the S_ESCL_ACTN_REQ table.

NOTE: If a workflow policy contains a defined duration, then the duration time is calculated from the time Workflow Monitor Agent detects that the row is in violation of the policy, not from the time the row was inserted into the S_ESCL_REQ table. For example, if you define a policy and set the duration as one week, but then Workflow Monitor Agent is not started until several days after Generate Triggers is run, then the policy action fires one week from when Workflow Monitor Agent is started, not one week from when the policy is created or Generate Triggers is run.

If the request for an action is made to the S_ESCL_ACTN_REQ table, then Workflow Action Agent executes the action and logs an entry into the S_ESCL_LOG table.



REQ_ID Column of the S_ESCL_REQ TableThe REQ_ID column of the S_ESCL_REQ table (S_ESCL_REQ.REQ_ID) can hold up to 9 digits, so the maximum value allowed is 999,999,999. Because the S_ESCL_REQ_S sequence does not contain an upper boundary, the sequence for S_ESCL_REQ.REQ_ID can potentially generate a number that is greater than the maximum of the allowed 9 digits, causing an overflow. To avoid this situation, it is recommended that you perform one of the following work items:

■ Use a database tool to increase the column size

■ Use a database tool to reset the S_ESCL_REQ_S sequence

As a separate issue, you might encounter a message similar to Status: Deleting requests ([a numeric identifier]).

This message does not indicate the number of rows that Workflow Monitor Agent is deleting. The numeric identifier indicates the REQ_ID from the S_ESCL_REQ table, which is generated by the database to uniquely number the rows in the database. For example, the ways in which REQ_ID is generated include:

■ From the Sequence object in an Oracle database

■ From the identity column in an MS SQL Server database

■ From the User Defined Function (UDF) in a DB2 database

There is no correlation between REQ_ID and the number of rows in the S_ESCL_REQ table.

Replication with the Workflow Monitor AgentWithin the entire enterprise architecture of a Siebel deployment, there can be only one Workflow Monitor Agent monitoring a particular workflow group. For example, a regional node can run a Workflow Monitor Agent that monitors a group named Group 1. Meanwhile, in the headquarters, there is another Workflow Monitor Agent running that monitors a group named Group 2. In this way, the organization can run workflow policies where required, while working with the restriction of one Workflow Monitor Agent for one group. You cannot run more than one instance of Workflow Monitor Agent and Workflow Action Agent for a particular workflow group. However, multiple Workflow Monitor Agent and Workflow Action Agent processes are allowed for different groups that run at the same time.

Starting Workflow Monitor AgentTo start the predefined Workflow Monitor Agent, you begin by defining a separate server component for each Workflow Monitor Agent server task. You then start Workflow Monitor Agent from the server manager command line interface.

Defining a New Workflow Monitor Agent Server ComponentIn releases prior to Siebel CRM version 7.0, you can start Workflow Monitor Agent from the Server Tasks view in the Server Manager user interface. This situation no longer applies. Beginning with Siebel version 7.0, you must start Workflow Monitor Agent from the Server Manager command line interface.



420

To define a new workflow monitor agent server component

1 In the Siebel client, navigate to the Administration-Server Configuration screen, Enterprises, then the Component Definitions view.

2 In the Component Definitions list, define a new record using values from the following table.

3 Save the record.

4 In the Component Parameters list, choose the Group Name parameter record, then enter the name of the workflow policy group for which this component handles requests.

5 (Optional) Make additional changes to the component parameters.

For more information, see “Command Line Interface Parameters of the Workflow Monitor Agent” on page 423.

6 In the Component Parameters list, choose the Default Tasks parameter record, then set the Value to 1.

This component automatically starts up and shuts down with the Siebel Server.

Do not set Default Tasks to a value greater than 1. Setting Default Tasks to a value greater than 1 can cause undesirable behavior, such as multiple server tasks starting for the same workflow group.

7 In the Component Definitions list, choose Enable Component Definition from the applet menu.

The definition state changes from Creating to Active.

8 Stop, then restart the Siebel Server so that the component definition goes into effect.

When you make a change to a component parameter, the component must be stopped and restarted in order for the changes to go into effect. Also, you must define a Workflow Monitor Agent component definition for each workflow policy group.

Next, start the workflow monitor agent.

Field Description

Name Name of the component.

Component Type [Workflow Monitor Agent]

Component Group Choose an existing component group.

Description Description of the component.

Alias Alias for the component. The alias cannot contain blank spaces.



Starting the Workflow Monitor AgentYou use the server manager CLI to start the Workflow Monitor Agent.

CAUTION: If a Workflow Process Manager server task fails, and if more server tasks are started that also fail, then Workflow Monitor Agent exits with error after only one violation. This situation can result in Workflow Monitor Agent starting more server tasks that are not required when the Workflow Process Manager server task fails. To avoid this situation, stop, then restart Workflow Process Manager.

For more information, see “Command Line Interface Parameters of the Workflow Monitor Agent” on page 423. For more information on using the Siebel Server Manager Command Line Interface, see Siebel System Administration Guide.

To start the workflow monitor agent

1 Start the server manager by entering the following command into the Server Manager CLI:

srvrmgr /g <gateway server address> /s <Siebel Server name> /e <enterprise server name> /u <server administrator username> /p <server administrator password>

2 Start a new Workflow Monitor Agent server task in background mode by entering the following command:

start task for component WorkMon with SleepTime=<time>,GroupName=<group name>

3 (Optional) Start a new Workflow Monitor Agent server task to run in batch to process a Batch policy by entering the following command:

start task for component WorkMon with GroupName=<group name>, BatchMode=Y

You must define a separate server component definition for each Workflow Monitor Agent server task.

Stopping or Restarting a Component of the Workflow Monitor AgentYou can stop or restart a Workflow Monitor Agent component.

To stop or restart a component of the workflow monitor agent

1 In the Siebel client, navigate to the Administration-Server Management screen, then the Components view.

2 Choose the component, then click Shutdown or Startup.

NOTE: If you make changes to the parameters of the component, then the component must be stopped and restarted for the changes to go into effect. Also, you must define a component definition of the Workflow Monitor Agent for each workflow policy group.



422

Keeping Definitions for Workflow Monitor Agent CurrentWorkflow Monitor Agent and Workflow Action Agent read workflow configurations from the server database. If you use Siebel Tools to modify a workflow policy object, column, or program in the local database, then you must check these objects into the server database. Otherwise, Workflow Monitor Agent and Workflow Action Agent possess no knowledge about these modifications. Also, situations in which you must restart Workflow Monitor Agent and Workflow Action Agent include:

■ After using Siebel Tools to modify an object, column, or program for a workflow policy

■ After using the workflow administration views in the Siebel client to modify a workflow action

If you do not restart Workflow Monitor Agent and Workflow Action Agent, then the modifications do not go into effect until policies are reloaded, as defined in the Reload Policy parameter. Because the Reload Policy parameter is set to 600 seconds by default, in most cases 10 minutes elapse before the modifications go into effect if you do not perform a restart.

It is not necessary to restart the Workflow Process Manager when modifying a workflow process. For more information, see “Modifying a Workflow Process” on page 118. For more information about checking in and checking out objects, see Using Siebel Tools.

To keep definitions for Workflow Monitor Agent current

1 Use the Project check in feature in Siebel Tools to check modifications made to a workflow policy object, column, or program into the server database.

2 When necessary, restart Workflow Monitor Agent and Workflow Action Agent.

For more information, see “Stopping or Restarting a Component of the Workflow Monitor Agent” on page 421.



Command Line Interface Parameters of the Workflow Monitor AgentTable 68 describes parameters that can be set by using the Workflow Monitor Agent command line interface.

Table 68. Command Line Interface Parameters of the Workflow Monitor Agent

Parameter Name

Display Name Usage

Default Value

ActionAgent Use Action Agent

Defines whether the Action Agent is automatically run with Monitor Agent.

If set to the default FALSE, then the Workflow Action Agent server component starts within Workflow Monitor Agent, and actions are then executed by Workflow Monitor Agent.

Several factors apply when configuring Use Action Agent. For more information, see “Setting the Use Action Agent Parameter” on page 428.

FALSE

ActionInterval Action Interval

Defines the action execution interval in seconds.

This argument determines when actions for a policy are executed again on the row of a base table. The purpose of this argument is to limit the number of times an action is executed if a row continues to go in and out of a matching state.

In other words, if the same record repeatedly violates the same policy before the action interval expires, then the record is removed from the S_ESCL_REQ table and the action is not performed again.

The default is 3600 seconds. If this parameter is used, then the value must be greater than 0 (zero) or unexpected behavior can result.

3600

BatchMode Processes the batch policies

Defines whether Monitor Agent runs in batch mode.

If BatchMode is set to TRUE, then only those policies with the Batch flag set to TRUE are evaluated. If FALSE, then only those policies with the Batch flag set to FALSE are evaluated.

If starting with BatchMode set to TRUE, then Workflow Monitor Agent is run one time. That is, it processes records in the table, then exits.

FALSE



424

CheckLogCacheSz Cache size of Policy violations

Defines the number of policy violations to store in the cache.

The Cache size of Policy violations parameter determines how many violated policies can be stored in the cache. Based on the presence of the ROW_ID and RULE_ID in the map or cache, the cache determines whether or not an action is already initiated.

The Workflow Monitor checks the S_ESCL_LOG table for policy violations for the same BT_ROW_ID and RULE_ID.

100

DeleteSize Request delete size

Defines the number of records to commit at a time.

The minimum is 1. If Workflow Monitor encounters a deadlock, then you can reduce the default from 500 to 125 with minimal performance degradation. To avoid a call stack error, do not set Request delete size to zero.

500

GenReqRetry Number of seconds to retry

Defines the number of seconds to retry sending a Generic Request message.

120

GroupName Group Name

Required. Defines the workflow policy group on which Monitor Agent works.

Not applicable


Parameter Name

Display Name Usage

Default Value



IgnoreError Ignore errors

Defines whether to ignore errors while processing requests.

By default, the Workflow Monitor Agent and Workflow Action Agent do not ignore errors that occur while processing the requests. If Ignore errors is set to TRUE, and if an error is encountered, then the agent logs the error, deletes the request, and then continues working. If Ignore errors is set to FALSE, then the agent exits on an error and sends an email message to the mail ID that is defined in the argument of the Mailing Address.

If Ignore errors is set to TRUE, then valid errors are ignored. If Ignore errors is set to FALSE, then the agent stops and exits with the error.

NOTE: It is recommended that you set Ignore errors to FALSE so that valid errors are not ignored.

FALSE

KeepLogDays Number of days to keep violation information

Defines the number of days of violation information that are retained in the log.

Log information that is older than the value in Number of days to keep violation information is automatically removed. This value can be set to 0 to prevent the purging of this log information.

For more information, see “KeepLogDays Parameter and Workflow Monitor Agent” on page 428.

30

LastUsrCacheSz Cache size of last user information

Defines the number of last user information items to cache.

If executing actions, then the information about the last user to modify the row of the base table is available as a token substitution in the program arguments. By caching this information in the server, the throughput performance of executing actions can potentially increase.

100

MailServer Mail Server Defines the name of the email server to send notification of abnormal termination.

Not applicable


Parameter Name

Display Name Usage

Default Value



426

MailTo Mailing Address

Defines the mail address to review notification of abnormal termination.

If a Workflow Agent process exits with an error, then a mail is sent to [mail ID]. An error can be caused by the failure of an action to execute, invalid object definitions, and so forth.

Not applicable

NumRetries Number of Retries

Defines the number of retries for recovery.

If database connectivity is lost, then Number of Retries works in conjunction with the Retry Interval and Retry Up Time parameters to reconnect MTS or Siebel Server components to the database.

10000

ReloadPolicy Reload Policy

Defines the policy reload interval in seconds.

The Reload Policy parameter defines the frequency that policies are reloaded into the engine, thus allowing a change to be made on the screens and with the Generate Triggers component. The engine acts on the changes within some time frame.

The default is 600 seconds.

600


Parameter Name

Display Name Usage

Default Value



Requests Requests Per Iteration

Defines the maximum number of requests that are read for each iteration.

The Requests Per Iteration parameter controls the maximum number of requests that Workflow Monitor Agent reads from the requests queue within one iteration. Between iterations, Workflow Monitor Agent performs the following:

■ Deletes processed requests from the requests queue and commits

■ Optionally reloads policies from the database

■ Checks for shutdown request

■ Optionally sleeps

The Requests Per Iteration parameter provides a mechanism to control the maximum amount of work that Workflow Monitor Agent performs before taking these steps between iterations.

5000

Sleep Time Sleep Time Defines the time in seconds that the Workflow Agent process sleeps after it polls for events and fulfills obligations to notify.

After the Workflow Agent process finishes, the Workflow Agent process stops polling according to the time period set by the sleep interval. This parameter affects both the performance of the Workflow Agent process and the responsiveness of the application server.

For more information, see “Sleep Time Parameter and Workflow Monitor Agent” on page 428.

60


Parameter Name

Display Name Usage

Default Value



428

Setting the Use Action Agent ParameterTable 69 describes situations in which to set the Use Action Agent parameter.

Sleep Time Parameter and Workflow Monitor AgentYou can increase the Sleep Time parameter in order to adjust the processing frequency, because the Workflow Monitor Agent server task waits for more requests when it sleeps. Because the default setting is 60 seconds, the server task sleeps every one minute. The Workflow Monitor Agent server task wakes up, processes requests , if there are any, then sleeps. Workflow Monitor Agent performs this work repeatedly.

KeepLogDays Parameter and Workflow Monitor AgentIf the Number of Days to Keep Violation Information parameter is set to 0, then Workflow Monitor Agent does not purge from the S_ESCL_LOG table. If you set this parameter to 0, then it is recommended to monitor the size of the S_ESCL_LOG table, because the size of this table affects performance. Use this parameter judiciously.

Because infrequent cleaning of the S_ESCL_LOG table can lead to slow performance, decide how often you must start Workflow Monitor Agent using KeepLogDays, then restart Workflow Monitor Agent with a setting of 0 for this parameter.

Defining a Workflow Policy to Run in Batch ModeThe ability to run a workflow policy in batch mode allows you to evaluate more data in the database, and not just the records that called the policy. This feature is useful when you define a new policy that must be applied to historical data, and for enforcing a policy that contains a date condition.

Table 69. Situations in Which to Set the Use Action Agent Parameter

When to Set Use Action Agent to False When to Set Use Action Agent to True

In most cases, it is recommended that you start Workflow Monitor Agent with Use Action Agent set to False, the default setting.

This way, Workflow Monitor Agent monitors the situation and executes actions. Some possible actions that are executed include workflow processes, workflow programs, and email programs.

If you start Workflow Action Agent to execute actions when Use Action Agent is True, and if the action is executing a workflow process, then you might encounter access violation errors and Workflow Action Agent can fail.

It is recommended that you start Workflow Monitor Agent with Use Action Agent set to True when executing an action that involves email consolidation.

If you use email consolidation and Use Action Agent is set to True, then you must start Workflow Action Agent separately.



To define a workflow policy to run in batch mode


2 Create a new Policy Group.

3 In the Name and Comments fields, enter a name and comment that indicates that this group is used for workflow policies that are run batch mode.


5 In the list for the Policies List, query the Name field for the workflow policy you must run in batch mode.

6 In the list for the Policies List, make sure the Batch Mode field contains a checkmark.

If you start workflow monitor in batch mode, then it checks for workflow policies with the Batch Mode check box marked. Each policy causes an SQL statement to be issued to identify the specific records that meet the workflow policy conditions. The records identified are then processed in turn and the appropriate actions are carried out.

7 In the Policy Group field, associate the workflow policy with the workflow group you created in Step 2.

8 (Optional). Consolidate email messages:

a Add a condition in the Conditions list and a corresponding action in the Actions list.

b In the Actions list, click the Consolidate field to consolidate email messages.

For more information, see “Consolidation of Email Messages” on page 429.

9 When you start the Workflow Monitor and Workflow Action server components, define the group name you created in Step 2, and set the parameter Processes the batch policies to TRUE.

For more information, see “Command Line Interface Parameters of the Workflow Monitor Agent” on page 423.

NOTE: If defining a batch workflow policy, then the comparison operators IS ADDED, IS UPDATED, or IS DELETED must be used in conjunction with regular workflow policy conditions. These comparison operators are considered special conditions that are intended for Dynamic mode when triggering rows to look up regular conditions.

Consolidation of Email MessagesYou can use the batch feature to consolidate email messages for a designated recipient by checking the Consolidate field in the Actions list in the Workflow Policies view. If you consolidate email messages, then the recipient receives one email with the information of multiple actions rather than multiple emails. For example, you can define a workflow policy that sends an email to the director of sales each time a quote is submitted that includes a discount over 30%. If 20 sales representatives submit quotes that include the 30% discount, and if the Batch Mode field is checked, then the director of sales receives one email listing the 20 quotes. If the Batch Mode field is not checked, then the director of sales receives 20 email messages.



430

Using Batch Mode to Make Sure a Workflow Policy Is Triggered CorrectlyThe following example demonstrates why a previously existing record that meets the workflow policy conditions does not trigger the workflow policy:

A workflow policy based on a business object is created to monitor a field when the following situations occur:

■ Workflow Condition, Account Status is Active.

■ Workflow Action, Action: Send Email to Employee.

■ Remove and generate database triggers, then start a workflow monitor server task for the workflow group named Test.


■ If a new account is added that meets these requirements, then the workflow policy is called.

■ If an existing account is updated in such a way that these requirements are met, then the workflow policy is called.

NOTE: If an account existed in the database before the workflow policy was defined, and if the account meets the workflow policy requirements, then the workflow policy does not start the workflow process.

If database triggers were generated for this workflow policy, then the Workflow Monitor Agent evaluates a record only if it is updated, or if a new record is created. Therefore, old records are not affected.

To evaluate an account record that is created prior to the creation of the workflow policy, make sure the Batch Mode flag is checked for the workflow policy, and that the Workflow Monitor Agent is run with Batch Mode set to TRUE.

Table 70. Example of Records That Meet a Policy But Do not Trigger the Policy

Field Value

Workflow Policy Name Account Active

Workflow Object Account

Group Test



Moving a Workflow Policy to a Different GroupTo respond to changes in the business environment or to you configuration, you might find it necessary to change the workflow group for a workflow policy. Before you can move a workflow policy from one group to another group, requests that are associated with that workflow policy must finished. If a group for a workflow policy is changed while an associated request is pending, then Workflow Monitor Agent fails with the error Rule Not Found. If this situation occurs, then restore the workflow policy to the original group for the policy, wait for the request to finish, then proceed with the change.

If an existing workflow policy is moved from one workflow group to another workflow group, then the database triggers must be updated. The database triggers contain the RULE_ID and GROUP_ID for the workflow policy. Therefore, if the database triggers were not generated again, then rows exist in the S_ESCL_REQ table that reference the original RULE_ID and GROUP_ID.

To move a workflow policy to a different group

1 Run a Generate Triggers server task to drop database triggers, thus making sure no more rows are inserted for workflow policies in the group you must change.

Use the following parameters:

EXEC=TRUE

Remove=TRUE

Because database triggers are being disabled, you must avoid firing additional database triggers through a workflow policy. Therefore, consider making these changes when either no users or only a minimal number of users are accessing the system. For more information, see “Generating Database Triggers” on page 404.

2 If a Workflow Monitor Agent server task is already running, then allow the server task to finish.

This step makes sure the server task processes the remaining rows in the S_ESCL_REQ table for the workflow policy group.

3 Query the S_ESCL_REQ table for the GROUP_ID to make sure no more rows are present for GROUP_ID.

4 If no server task for the monitor agent is running for the group, then start a server task for the group with the proper group name.

5 After the remaining rows in the S_ESCL_REQ table for the group are finished processing, stop the server task of the Workflow Monitor Agent for the group.

6 Reassign the workflow policy to the group by changing the field of the group name for the workflow policy to the new group name.

7 Generate database triggers again, using the following parameters:

EXEC=TRUE

Remove=FALSE



432

8 Restart the Workflow Monitor Agent for the old group.

9 Start a new Workflow Monitor Agent for the new group.

Expiring a Workflow PolicyWhen you expire a workflow policy, you can remove rows that belong to the expired or deleted policy in the S_ESCL_REQ table, which is preferable to deleting the workflow policy.

If you encounter a failed to load parent rows error message, then it can be due to the presence of rows in the S_ESCL_REQ, S_ESCL_STATE and S_ESCL_ACTN_REQ tables that reference an expired workflow policy. The procedure in this topic allows you to determine, by using SQL queries, if there are rows in these tables that reference a policy that no longer exists in the S_ESCL_RULE table. To avoid workflow manager exiting with an error, make sure there are no outstanding records in the S_ESCL_REQ, S_ESCL_ACTN_REQ or S_ESCL_STATE tables before expiring the policy.

CAUTION: Setting Ignore Errors to True is primarily used to clean up the Workflow Tables. It is strongly discouraged to permanently set Ignore Errors to True.

Removing Rows That Belong to a Workflow Policy That Is Expired or DeletedYou can expire a workflow policy by removing rows from the S_ESCL_REQ table.

To remove rows that belong to a workflow policy that is expired or deleted

1 Look for the following error message in the WorkMon_xxx.log trace file:

■ [DBG33] 2000-01-24 08:49:30 Message: Rule not found

■ [DBG33] 2000-01-24 08:49:30 Message: Failed to load parent rows

This error message indicates an error occurred when Workflow Monitor agent attempted to process records from the S_ESCL_REQ, S_ESCL_STATE or S_ESCL_ACTN_REQ tables, and the workflow policy that it is trying to review is expired or deleted. For more information about these tables, see “Workflow Monitor Agent” on page 417.

2 To determine if there are records that reference an expired policy, run the following query:

select row_id, name, expire_dt

from s_escl_rule

where expire_dt is not null and expire_dt <= getdate()

Sysdate is an Oracle date time function. The corresponding function for SQL Server is getdate().

3 Note the ROW_ID for the expired workflow policy that is identified in Step 2.

4 Run the following query to determine the number of records in the S_ESCL_REQ table that reference an expired workflow policy:

select * from s_escl_req where rule_id in (select row_id from s_escl_rule where expire_dt is not null and expire_dt <= getdate())



5 Repeat Step 4 for the S_ESCL_STATE and S_ESCL_ACTN_REQ tables.

6 If there are records in the S_ESCL_REQ, S_ESCL_STATE, or S_ESCL_ACTN_REQ tables that reference an expired policy, then, in the Siebel client, start the Workflow Monitor Agent with Ignore Errors set to TRUE.

Workflow Monitor Agent can bypass the error and clean the S_ESCL_REQ table.

Note the caution information provided at the beginning of this topic.

7 Stop the server task.

8 Restart the server task with Ignore Errors set to FALSE.

This step makes sure other types of errors are not overlooked.

9 If the errors continue, then delete rows by RULE_ID, expire old workflow policies, and delete database triggers.

For more information, see “Deleting Rows by RULE_ID, Expire Old Policies, and Delete Database Triggers” on page 433.

Deleting Rows by RULE_ID, Expire Old Policies, and Delete Database TriggersYou can expire a workflow policy by deleting rows by RULE_ID, expiring old policies, and dropping database triggers.

To delete rows by RULE_ID, expire old policies, and delete database triggers

1 Make a backup copy of the database or the effected tables.

2 Identify the RULE_IDs that belong to workflow policies that no longer must be enforced by Siebel Workflow.

3 Use SQL to manually delete the rows that reference expired or deleted workflow policies.

Delete these policies by RULE_ID. For example:

delete from [table name] where RULE_ID = 'rule_id'

The Siebel application does not support direct delete or update statements on the Siebel database. Also, the S_ESCL_REQ, S_ESCL_ACTN_REQ, and S_ESCL_STATE tables are the only tables that do not contain dependencies. Make sure you perform this procedure in accordance with Siebel Support guidelines.

Performing the backup in Step 1 makes sure a backup exists that you can use to restore the tables to their state before rows were deleted, if necessary.

4 For a workflow policy that must not be active, expire it by putting an older date and time in the Expiration Date/Time field for the policy.



434

5 To delete database triggers that reference expired workflow policies, run the Generate Triggers server task with the following parameters:

Drop Triggers:

EXEC = True

Remove = True

Generate Triggers:

EXEC = True

Remove = False

If some workflow policies are expired, and if those policies did not drop and regenerate database triggers, then the database triggers for those policies can still cause records to be inserted into the tables for Siebel Workflow. Dropping these database triggers prevents creating rows that are related to expired policies in the S_ESCL_REQ table.

6 If necessary, regenerate database triggers.

For more information, see “Generating Database Triggers” on page 404.

7 If the errors persist, then create a service request.

Include a description of the steps you performed to resolve the error, along with a copy of the Workflow Monitor trace files with the following trace flags set:

Error Flags = 2

SQL Trace Flags = 2

For more information, see “How to Get Help with an Error of a Workflow Process” on page 242.

Deleting a Workflow Policy That Is ObsoleteDatabase triggers are still in effect at the time you expire or delete a workflow policy and shut down Workflow Monitor. Database triggers that are related to an expired or deleted policy continue to work because they are attached to database tables until they are deleted from the database. Therefore, between the time you expire a policy and the time you finish dropping and redefining database triggers, rows might be triggered for the expired policy in the S_ESCL_REQ table.

You might encounter the ESC-00054 error while starting Workflow Monitor because Workflow Monitor Agent looks for workflow policies that are referenced in the S_ESCL_REQ table, and finds policies that are inactive or not present. The policies are stored in the S_ESCL_RULE table. Those rows must remain in the S_ESCL_REQ table and must not be processed at all.



If Use Action Agent is set to FALSE for Workflow Monitor, then Workflow Monitor Agent executes for Action Agent, bypasses the S_ESCL_ACTN_REQ table, and uses only the S_ESCL_REQ table. If rows in the S_ESCL_REQ table exist for a workflow policy that is expired or deleted, then you must delete them before starting Workflow Monitor. Reasons for performing this work include:

■ To avoid the ESC-00054 error when starting Workflow Monitor.

■ To avoid the unnecessary use of storage space. Normally, Workflow Monitor does not process the rows at all. The rows remain unused in the S_ESCL_REQ table.

You can delete the rows by RULE_ID, which is the unique identifier for a workflow policy. Back up the database prior to performing the delete.

Example of Issuing Queries to Locate Workflow Policies That Are Deleted or ExpiredThe queries described in this topic can help you determine whether rows in the S_ESCL_REQ table exist that are related to a deleted or expired workflow policy.

Issuing a Query That Locates Workflow Policies That Are DeletedYou can issue a query that locates deleted workflow policies.

To issue a query that locates deleted workflow policies■ Run the following query:

select RULE_ID, count(RULE_ID)

from S_ESCL_REQ a

where not exists

(select row_id

from S_ESCL_RULE b

where a.RULE_ID = b.ROW_ID)

group by RULE_ID

Issuing a Query That Locates Workflow Policies That Are ExpiredYou can issue a query that locates expired workflow policies.



436

To issue a query that locates expired workflow policies

1 Run the following query:

select a.RULE_ID, b.NAME, count (a.RULE_ID), b.EXPIRE_DT, b.SUB_TYPE_CD

from S_ESCL_REQ a, S_ESCL_RULE b

where a.RULE_ID = b.ROW_ID

and b.EXPIRE_DT < sysdate

group by a.RULE_ID, b.NAME, b.EXPIRE_DT, b.SUB_TYPE_CD

where:

■ sysdate is the Oracle current date and time function

2 Determine if the workflow policies expired unintentionally.

An example of a workflow policy that expired unintentionally is someone forgetting to extend the dates and nobody changed the database triggers since the policy expired.

3 (Conditional). If you determine a workflow policy expired unintentionally and you must process the rows, then perform the following work:

■ If the Workflow Monitor is running and it is not necessary for you to shut it down, then reverse the expiration of the workflow policy by entering a date and time that is greater than the current date and time in the Expiration Date field for policy.

After a period of 10 minutes, the workflow policy goes into effect. This situation occurs because the default for the Reload Policy parameter of Workflow Monitor is 600 seconds.

■ If you require the workflow policy to go into effect immediately, then shut down Workflow Monitor if it is running, reverse expiration of the policy, then start Workflow Monitor.

You can also perform this work with a workflow policy that contains a duration.

Tracing and Reporting a Workflow PolicyThis topic describes how you can trace a workflow policy and generate reports about policies.

Trace Files for Workflow Policies and Siebel Server TasksWhen you start a Workflow Policies server process, a trace file for a Siebel Server task is generated so that you can check for error messages and other information. The Siebel Server processes for which trace files are generated include:

■ Generate Triggers

■ Page Manager

■ Email Manager

■ Workflow Monitor Agent

■ Workflow Action Agent



Viewing Trace FilesYou can view information about the trace file in either the Siebel client or the Siebel Server.

To view trace files in the Siebel client■ In the Siebel client, navigate to the Administration-Server Management screen, Tasks, then the

Log view.

The Tasks list displays the status of the Siebel Server tasks as running or started.

To view trace files in the Siebel server■ View the log directory for the Siebel Server by performing one of the following:

■ Use Windows Explorer to navigate to your Siebel Server log directory. Under \log, choose the name for the server in order to examine a file that lists the trace files for each server process.

■ Double-click the Trace File icon to access the trace file. You can view the trace file for application server tasks.

For more information on using trace files, see Siebel System Administration Guide.

Log Levels for Tracing and Events for Workflow PoliciesTable 71 describes the events that workflow policies use for logging.

NOTE: Setting a trace level above the default parameter affects performance. Reset the trace level to the default parameter after you finish troubleshooting.

Charts and Reports for Workflow PoliciesCharts are available for analyzing how frequently the condition of a workflow policy is met and the total number of policy instances that occur within a defined amount of time. Reports also summarize workflow policy and workflow log information.

Table 71. Events That Workflow Policies Use for Logging

Event Level Description

SqlParseAndExecute 4 Traces SQL statements and execution times.

Object Assignment 3 Traces Workflow Monitor Agent while it is performing Dynamic Assignment. Used in conjunction with Rules Evaluation.

Rules Evaluation 4 Traces Workflow Monitor Agent while it is performing Dynamic Assignment. Used in conjunction with Object Assignment.

Task Configuration 4 Parameter configuration of the server task.



438

Displaying Information About Frequency and Trends of How a Workflow Policy is UsedPolicy Frequency Analysis provides information about the number of times a workflow policy executes. Policy Trend Analysis provides information about policy execution trends.

To display information about frequency and trends of how a workflow policy is used

1 In the Siebel client, navigate to the Administration-Business Process screen, then the Policy Frequency Analysis view.

2 Peruse the view, using values described in the following table.

Displaying a Report for a Workflow PolicyIn the Workflow Policies and Log views, you can bring up a Reports page that you can print.

To display a report for a workflow policy


2 From the menu bar, click the Reports icon, then choose Workflow Policy.

A separate Siebel Report Viewer window opens with a report that displays summary information for the workflow policy.

You can also bring up a similar report for the Log views.

List or View Description

Monitor Log Lists the workflow policies.

Workflow Policy Frequency Analysis

Displays a chart that illustrates the execution frequency of a chosen policy.

To toggle between the Workflow Policy Frequency Analysis view and the Workflow Policy Trend Analysis view, use the toggle feature on the chart view.

Workflow Policy Trend Analysis

Displays the total number of workflow policy conditions that are met over a defined amount of time.



Guidelines for Converting a Workflow Policy to a Workflow ProcessIn general, it is recommended you keep a workflow policy simple, placing most business logic into a workflow process. To use this approach, you can convert a workflow policy to a workflow process.

Table 72 describes guidelines you can use when converting a workflow policy to a workflow process.

Table 72. Guidelines for Converting a Workflow Policy to a Workflow Process

Configuration Used in a Workflow Policy Configuration Used in a Workflow Process

A specialized operator, such as IS UPDATED or IS ADDED.

A run-time event.

A standard operator, such as = or <>. A branch or decision step.

A workflow policy program that performs an operation at the database layer.

A Siebel operation step at the object layer that implements logic which manipulates data at the data layer.

Although a workflow process cannot call a workflow policy program, if there is a requirement to perform an operation at the database level, then it might be possible to use the Siebel operation step to accomplish the same required functionality.

Not applicable For sending email, because a workflow process uses the communication outbound manager service, it can use a recipient group and an exact email address.


Administering a Workflow Policy ■ Testing, Troubleshooting, and Migrating a Workflow Policy

440

Testing, Troubleshooting, and Migrating a Workflow PolicyThis topic describes testing, troubleshooting, and migrating a workflow policy. It includes the following topics:

■ Testing a Workflow Policy on page 440

■ Troubleshooting a Workflow Policy on page 442

■ Migrating Workflow Policies to the Production Environment on page 443

Testing a Workflow PolicyTesting a workflow policy before implementing it in your production environment increases the likelihood that the recipient of an action receives accurate and useful information, and that the overall results meet the business requirements for the workflow process. It is critical that you thoroughly test your workflow policy and eliminate problems before you implement the policy in your production environment.

CAUTION: Your test environment and production environment must contain identical versions of the software.

To test a workflow policy

1 Develop a testing and migration strategy for introducing changes into the production environment.

For more information, see “Planning a Test and Migration Strategy for a Workflow Policy” on page 336.

2 Make sure you installed the workflow policy components on the Siebel Server.

For more information, see Siebel System Administration Guide.

3 Make sure the server processes for email and pager that are required by your workflow policy are running.

4 Make sure the required Workflow Agent processes are running.

5 Make sure each workflow policy, workflow policy condition, and workflow policy action executes as expected:

■ Test your workflow policy by entering data that meets the conditions you defined for the policy.

■ Make sure the policies, conditions, and actions are correctly defined.

■ Make sure the policies, conditions, and actions accurately define the transactions.

The correct columns can be monitored.

Administering a Workflow Policy ■ Testing, Troubleshooting, and Migrating a WorkflowPolicy


6 Make sure the workflow policy actions perform as expected and occur when expected:

■ Make sure your database triggers are generated.

■ Make sure the action interval and sleep times are correctly defined.

■ Make sure the proper action executes. For example, you can check that the email arrives or that the pager notification activates. You can use the Workflow Policies Log view to monitor progress of the Workflow Agent. For more information, see “Using the Workflow Policy Log to Monitor Execution of a Workflow Policy” on page 441.

Using the Workflow Policy Log to Monitor Execution of a Workflow PolicyThe Workflow Policy Log view displays a log of the records that meet a workflow policy condition that is tracked by the Workflow Monitor Agent process.

To use the workflow policy log to monitor execution of a workflow policy

1 In the Siebel client, navigate to the Administration-Business Process screen, the Policy Frequency Analysis view.

2 Query the Policy field for the workflow policy you must monitor.

3 Peruse the log using values from the following table.

After you verify that the workflow policy executes as expected, you can migrate the policy to your production environment. For more information, see “Migrating Workflow Policies to the Production Environment” on page 443.

Field Description

Policy The name of the workflow policy.

Workflow Object The name of the workflow policy object.

Object Identifier The ID of the workflow policy object for which the workflow policy condition was met.

Object Values Identifying information for the row that met the workflow policy condition.

Event The date and time that the workflow policy condition was met.



442

Troubleshooting a Workflow PolicyBecause a workflow policy is based on database triggers, the policy can execute on a database record only after the record is committed. If a policy is based on multiple database tables, then the policy goes into effect only if the records on those tables are committed.

For example, opportunity revenue is stored in the S_OPTY_POSTN table, and lead quality is stored in the S_OPTY table. A workflow policy that applies both of the following workflow policy conditions goes into effect only when the records are committed on both tables:

■ Opportunity Revenue > 10M

■ Lead Quality is High

A search specification can be used to defined multiple business components for the same database table. If you define the component of a workflow policy to monitor a business component, then be sure to include fields that are used in the search specification as workflow policy columns. The workflow policy column can then be used in the conditions of the workflow policy in order to enforce appropriate behavior.

Troubleshooting a Workflow Policy Action That Does Not TriggerYou can troubleshooting a workflow policy action that does not trigger.

To troubleshoot a workflow policy action that does not trigger

1 Make sure your test record meets the workflow policy conditions.

2 Make sure the Siebel client configuration file is pointing to the correct enterprise server.

If the server is incorrect, then the ESC-00053 error, Error loading rule definitions, might occur.

3 Check the date and time that the workflow policy was activated.

4 Check the monitor task:

a Check to see if the monitor is awake and running against the correct group.

b Search the Task Information log for the ROW_ID of your test record:

❏ If ROW_ID does not exist, then run GENERATE TRIGGERS.

❏ Update your test record.

5 Check the Action Agent task:

a Check to see if the Action Agent is awake and running against the correct workflow policy group.

b Search the Task Information log for the ROW_ID of the test record.

6 Make sure the database triggers are generated.

Administering a Workflow Policy ■ Testing, Troubleshooting, and Migrating a WorkflowPolicy


Tracing a Workflow PolicyThe General Events event is used for logging with a workflow policy. To view informational messages, set the log level to 3. To view debugging information, set the log level to 4. For more information, see “Tracing and Reporting a Workflow Policy” on page 436.

Migrating Workflow Policies to the Production EnvironmentTo migrate fully tested workflow policies to your production environment, you must perform a procedure that is similar to the procedure that is used to implement policies in your test environment.

To migrate workflow policies to the production environment

1 Back up your production environment database.

2 Migrate your test repository environment into your production repository environment.

For more information, see the upgrade guide for the operating system you are using.

3 Reenter, into the production environment, the workflow policy action types, workflow policies, and workflow policy groups that you defined in the test environment.

When you reenter definitions in the production environment, make sure you enter them exactly as they are defined in the test environment. It is not necessary to reenter information that you defined by using Siebel Tools.



6 In the drop-down list for the Component/Job field, choose Generate Triggers.

This step creates a new line entry but does not start the server task.

7 In the Job Parameters list, click New to modify parameter settings.

For a description of the parameters that are specific to the Generate Triggers server component, see “Administering Database Triggers on the Workflow Policy Server” on page 402. For a description of generic and enterprise parameters, see Siebel System Administration Guide.

8 Choose Submit Query.

9 Use trace files, as necessary, to monitor execution.

For more information on trace files, see “Tracing and Reporting a Workflow Policy” on page 436. For more information on using trace flags, see Siebel System Administration Guide.

NOTE: To help prevent invalid database triggers from applying to your production environment, apply database triggers to your test environment before you apply them to your production environment.



444


A Reference Materials for Siebel Workflow

This appendix provides reference information for Siebel Workflow. It includes the following topics:

■ Properties of Siebel Workflow on page 445

■ Properties of Workflow Policies on page 470

■ Predefined Business Services on page 482

Properties of Siebel WorkflowThis topic describes reference information for various objects used with a workflow process. It includes the following topics:

■ Properties of a Workflow Process on page 445

■ Properties of the Step and Connector of a Workflow Process on page 450

■ Fields and Arguments of Process Properties on page 462

Properties of a Workflow ProcessTable 73 describes properties of the top level object definition for a workflow process.

Table 73. Properties of the Object Definition of a Workflow Process

Property Description Possible Value

Auto Persist Sets workflow persistence. (Optional) YES or NO.

Business Object

The name of the associated business object.

(Optional) This value is chosen from a picklist of business objects. Only business objects that contain a defined primary component appear in this picklist.

For more information on defining the primary business component for a business object, see “Defining a Primary Business Component for a Business Object” on page 83.

Error Process Name

The name of the workflow process to call as the error process.

(Optional) Choose from the picklist of predefined workflow processes.


Reference Materials for Siebel Workflow ■ Properties of Siebel Workflow

446

Group This property applies to workflow processes that are defined earlier than version 7.7.

(Optional)

NOTE: Do not use this property for a new workflow process that you define. Use the Project property instead.

Pass By Ref Hierarchy

Applicable for hierarchal data that is passed between a subprocess and the parent workflow process. If pass by reference is checked, then a change that is made in the child workflow process propagates back to the parent workflow process. If implemented, then this feature reduces the memory footprint that is required for a workflow process because data is passed by reference instead of by value.

(Optional) TRUE or FALSE.

Process Name

The name of the workflow process. (Required). A descriptive name that includes the following characteristics:

■ Consistent with your overall naming strategy

■ Meaningful to the designer of the process

■ Unique

Project The name of the project to which the workflow process belongs.

(Required).

Replication Level

How the workflow process synchronizes to a Mobile Web Client. The All value synchronizes to the regional nodes for the server as well as to mobile users. The Regional value synchronizes only to the regional nodes.

None, All, or Regional.





State Management Type

The state management type for the workflow process. Describes the type of business service requests that are made while the workflow process is executing.

NOTE: If every business service that is called by this workflow process is a stateless business service, then it is recommended that the state management type be set to Stateless. Otherwise, it is recommended that the state management type be set to Stateful.

The default setting is Stateful.

For more information, see “State Management Type and the Workflow Process” on page 449.

(Required). The following values are available:

■ Stateless. A method of a business service that is called by this workflow process does not include a dependency on a state that is specific to the service. If the stateful or cached services that are called by this workflow can be released when the workflow pauses or finishes, then choose Stateless.

■ Stateful. A method of a business service that is called by this workflow process depends on a state that is specific to a service. If the stateful or cached services that are called by this workflow must not be released during and after the execution of the workflow, then choose Stateful.

Status The current status of the workflow process.

(Required). The following values are available:

■ Not In Use

■ In Progress

■ Completed

Version The version number of the workflow process.

Read only. The default version is 0. The version number increments by one when you use Revise to modify an existing workflow process.





448

Some of these properties, but not every property, can be defined by using the Workflow Processes OBLE, or the Properties window in the Process Designer. The Properties window in the Process Designer displays properties based on context.

To display properties for the workflow process





4 From the Tools application-level menu, choose the View menu, Windows, then the Properties Window menu item.

Web Service Enabled

This property indicates that a business service or workflow process is exposable as a Web service and can be called independently.

NOTE: Setting this property to TRUE does not automatically implement the workflow Web service, nor does defining the workflow process for Web service cause the flag to be checked.

(Optional) TRUE or FALSE.

Workflow Mode

The type of the workflow process. (Required). The following values are available:

■ 7.0 Flow



■ Service Flow

For more information, see “About the Workflow Mode Property” on page 127.





State Management Type and the Workflow ProcessThe OM session state management framework requires a business service to contain a state management type that is defined. A business service must be defined as Stateless or Stateful, or as a business service that is managed by the server. The stateless Workflow Process Manager business service is the Workflow Engine.

The State Management Type property of a workflow process defines whether the workflow is designed to be stateless or stateful. The Workflow Engine can execute a stateful workflow process or a stateless workflow process:

■ If a workflow process is defined as Stateless, then the OM session state management framework can release a stateful or cached business service that is called by this workflow when the workflow instance is paused or finished.

■ If a workflow process is defined as Stateful, then the OM session state management framework does not release a stateful or cached business service that is called by the instance of this workflow, even after the instance is finished. Instead, the framework waits for the caller of the Workflow Engine to decide when the cached business service must be released. The caller of the Workflow Engine can release stateful or cached business services by calling methods from the Web Channel Dedicated Block Service.

How the State Management Type is DefinedBy default, the State Management Type for a workflow process is set to Stateful in order to preserve the behavior for releases earlier than Siebel CRM 8.1. However, if a workflow process is designed to be executed through Web Channel, then it might be necessary to change the State Management Type for the workflow to Stateless in order to take advantage of the session pooling feature in the OM session state management framework.

Table 74 describes how the Workflow Mode property of a workflow process determines the State Management Type for the workflow.

Table 74. How the State Manage Type Property Is Defined

Workflow ModeHow Typically Defined Description

Service Flow Stateless Because a service workflow cannot contain a user interact step or wait step, it is executed for the entire workflow before the object manager session state management framework can release the session back to the pool.

Interactive Flow Stateless Similar to a long-running workflow process, the instance of an interactive workflow can move between sessions through the Universal Inbox. However, because the State Management Type setting is only relevant when the workflow is executed through Web Channel, and because an interactive workflow executes in a user interactive session, the State Management Type does not effect the behavior of an interactive workflow.



450

For more information on the Web Channel OM session state management framework, see Siebel Web UI Dynamic Developer Kit Guide.

Properties of the Step and Connector of a Workflow ProcessThis topic describes properties of the various steps and connectors that used in Siebel Workflow.

Long Running Flow

Stateless The Workflow Engine is already designed to allow a long-running workflow to deploy between sessions when a long-running workflow is paused.

NOTE: It is recommended that you do not define a long-running workflow to call a stateful business service because the state of the service is lost when the instance of a long-running workflow moves from one user session to another user session.

7.0 Flow Stateful Do not change this setting unless you are sure none of the business services that the workflow process calls directly or indirectly is a stateful business service.

Table 74. How the State Manage Type Property Is Defined

Workflow ModeHow Typically Defined Description



Table 75 describes the properties of a step of workflow process.

Table 75. Properties of a Step of a Workflow Process

PropertyType of Step Description Possible Value

Name All The name of the step. A descriptive name that includes the following characteristics:



■ Unique

When you define a new step, the step is automatically assigned a name, based on the type of step, and a sequence number. You can change this name or leave it as is. For more information, see “Name of a Step in a Workflow Process or a Process Property” on page 67.

Type All The type of step. This value is automatically entered when you define the step in the Process Designer view. This value is a read only property.

Business Component

Siebel Operation

Required. The business component that performs the action you define.

Choose from a list of business components that are defined for the chosen business object.

Business Service Name

Business Service

The name of the business service to call.

The picklist displays business services that have their Hidden flag set to FALSE.

For more information, see “Making a Business Service Visible to a Workflow Process” on page 71.

Business Service Method

Business Service

The name of the method to call on the business service.

The picklist displays methods that are defined for the business service that is chosen.



452

Subprocess Name

Sub Process The name of the sub process step.

A descriptive name that includes the following characteristics:


■ Meaningful to the designer of the workflow process

Error Code Stop A number that is associated with a string in the database that comprises the error message.

Numeric value.

Error Message

Stop A string in the database that comprises the error message.

Text string.

User Interact View

User Interact The name of the view for the user interact step.

Choose from a picklist that contains predefined view names.

Operation Siebel Operation

The type of operation. The following values are available:

■ Delete

■ Insert

■ NextRecord

■ PrevRecord

■ Query

■ QueryBiDirectional

■ Update

■ Upsert





Maximum Iterations

Wait The maximum number of times that you can execute this step within an instance of a workflow process.

If the maximum number of iterations is reached, then an error from the Object Manager is generated and the workflow process returns an In Error status. If you require the workflow to run to completion, then you must use an exception mechanism in Siebel Workflow to catch and handle the error. Example mechanisms include an error process or an error exception connector. For more information, see “Using an Error Exception Connector to Handle Errors” on page 164.

Description All A text narrative that describes the purpose of the step.

Free form text.

Comments All A text narrative that describes the purpose of the step.

Free form text.





454

Table 76 describes properties of the start step.

Update Snapshot

All Indicates that if the workflow process reaches this step, then Siebel Workflow uses a snapshot of the state of the process, so that if there is a system failure, you can recover the state. This parameter is used for recovery.

Check mark.

Processing Mode

Wait The mode in which the workflow process is run when it is started by a run-time event. For more information, see “Processing Mode Property of a Wait Step” on page 88.

(Optional)

The following values are available:

■ Local Synchronous. Executes the workflow process in the application object manager. This value is the default.

■ Remote Synchronous. Submits a synchronous request to the Workflow Process Manager server component in order to execute the workflow process.

■ Remote Asynchronous. Submits an asynchronous request to the Workflow Process Manager server component in order to execute the workflow process.

Table 76. Properties of the Start Step

Start Properties Expected Value

Comments (Descriptive text.)

Description (Descriptive text.)

Inactive FALSE

Name Start





Table 77 describes properties of the business service step.

Table 78 describes properties of the decision point step.

Parent Name Workflow name:version

Processing Mode Local Synchronous (or can be empty)

Table 77. Properties of the Business Service Step

Business Service Property Expected Value

Allow Retry Flag FALSE

Business Service Name (Choose the business service name from the picklist.)

Business Service Method (Choose the business service method from the picklist.)



Inactive FALSE

Name Business service 0 (You can modify this value, as necessary.)


Table 78. Properties of the Decision Point

Decision Point Properties Expected Value



Inactive FALSE

Name Decision Point 0 (You can modify this value, as necessary.)


Table 76. Properties of the Start Step

Start Properties Expected Value



456

Table 79 describes properties of the sub process step.

Table 80 describes properties of the Siebel operation step.

Table 81 describes properties of the task step.

Table 79. Properties of the Sub Process Step

Sub Process Properties Expected Value



Inactive FALSE

Name Sub Process 0 (You can modify this value, as necessary.)

Sub Process Name (Choose the name of the subprocess from the picklist.)

For a subprocess to appear in this picklist of defined workflow processes, the status for the subprocess must be Complete.

Table 80. Properties of the Siebel Operation Step

Siebel Operation Properties Expected Value

Allow Retry Flag FALSE

Business Component (Choose the business component name from the picklist.)



Inactive FALSE

Name Siebel Operation 0 (You can modify this value, as necessary.)

Operation (Choose the operation from the list.)


Table 81. Properties of the Task Step

Task Properties Expected Value



Inactive FALSE



Table 82 describes properties of the user interact step.

Table 83 describes properties of the wait step.

Name Task 0 (You can modify this value, as necessary.)

Task Name (Choose the task name from the picklist.)

Table 82. Properties of the User Interact Step

User Interact Properties Expected Value



Inactive FALSE

Name User Interact 0 (You can modify this value, as necessary.)


User Interact View (Choose the view name from the picklist.)

Table 83. Properties of the Wait Step

Wait Properties Expected Value

Business Service Method Sleep




Inactive FALSE

Maximum Iterations Not applicable

Name Wait 0 (You can modify this value, as necessary.)


Table 81. Properties of the Task Step

Task Properties Expected Value



458

Table 84 describes properties of the stop step.

Table 85 describes properties of the end step.

Table 84. Properties of the Stop Step

Stop Properties Expected Value



Error Code (Choose the error code from the picklist.)

Error Message (After the Error code is chosen, the Error message is automatically populated.)

Name Stop 0 (You can modify this value, as necessary.)


Table 85. Properties of the End Step

Stop Properties Expected Value



Inactive FALSE

Name End 0 (You can modify this value, as necessary.)




Table 86 describes properties of the workflow connector.

Table 86. Properties of the Workflow Connector


Name The name of the connector. The name of the connector must be unique to the workflow process. If it is not unique, then you cannot commit the record.

Type The type of connector. The following values are available:

■ Default. If no other decision conditions are satisfied, then this connector is followed. Also, if Default is used, then conditions that are defined for the connector are ignored.

■ Condition. A decision condition is defined for the connector.

■ Connector. There is no decision condition involved.

■ Error Exception. Captures an error that is generated by the system, such as an error that notes that the Assignment Manager server component is not available. For more information, see “Using an Error Exception Connector to Handle Errors” on page 164.

■ User Defined Exception. Captures an error that is generated by an end user, such as an error that notes that an order is incomplete. For more information, see “Using an Error Exception Connector to Handle Errors” on page 164.

Event Object Type

Describes the type of object on which a run-time event occurs.

NOTE: If Event Object Type is defined, then Event Object must be chosen.

(Optional)

Possible values include:

■ Application

■ Applet

■ BusComp

Event Object The name of the object on which the event occurs.

(Required if Event Object Type is defined). This name is defined in Siebel Tools.

Event Object is context sensitive, depending on the value in Event Object Type. For example, if Event Object Type is set to BusComp, then Event Object specifies the business component, such as Account.



460

Event The specific event that happens to the object.

(Required if Event Object Type is defined.) The set of available events is context sensitive, depending on the value in Event Object Type.

Subevent The name of the method or field in a business component to be monitored.

(Optional)

Used when the object type is BusComp or Applet and the event is InvokeMethod or SetFieldValue.

For InvokeMethod, the name of the called method. For SetFieldValue, the name of the field being set.

Event Cancel Flag

Aborts the run-time event after the workflow process is finishes.

NOTE: If this flag is not checked, then the following error results when the workflow process is run: The specialized method [Method Name] is not supported on this business component.

(Optional)

This flag only applies to an event that can be canceled. This flag works similar to CancelOperation in scripting.

Expression User friendly text for the decision condition that is defined for the connector.

Read-only

Event Visibility

Controls whether the workflow process waits for a run-time event that is generated within the current session, or by another session.

If the workflow process is persistent, then the visibility can be set to Enterprise or Local.

NOTE: If the workflow process is not persistent, then it is recommended that visibility be set to Local.

In most cases, where a workflow process must wait for an event, the workflow must be persistent, and you set the value to Enterprise. However, setting Event Visibility to Enterprise can have a detrimental effect on performance because a run-time event searches for a matching instance. Therefore, if it is not necessary for your workflow to be persistent, then it is recommended that you set Event Visibility to Local.





Table 87 describes properties of the error exception connector.

User Event Name

An arbitrary string that denotes the name of a user event.

This value can be a string but it must be unique within the Siebel enterprise.

Make sure you define a unique name on the User Event Name field. Also, make sure the name is sufficiently long so that it remains unique across the Siebel enterprise. For example: Order Placed-Begin Processing Event for Service Request Automation-Version 2.

User Event Storage

The process property that serves as the destination for the payload on the incoming user event.

This value can be a process property. The process property must be marked as the correlator.

User Event Timeout (Days)

The amount of time, in days, before the event times out.

Numeric value.

If the user event is on a wait step, then use this parameter. Do not define a wait duration on the wait step.

Comments More statements relative to the connector.

Free form text.

Table 87. Properties of the Error Exception Connector

Error Exception Connector Properties Expected Value


Inactive FALSE

Name Error Exception 0 (You can modify this value, as necessary.)

Parent Name (From step name)

Type Error Exception

User Event Name (Leave this field empty.)

User Event Storage (Leave this field empty.)

User Event Timeout 0





462

Fields and Arguments of Process PropertiesThis topic describes reference information for process properties and their arguments. It includes the following topics:

■ Fields of a Process Property on page 462

■ Fields of an Input Argument of a Process Property on page 465

■ Fields of an Output Argument of a Process Property on page 466

■ Fields of a Recipient Argument of a Process Property on page 468

■ Fields of the Input Argument of a Search Specification of a Process Property on page 469

Fields of a Process PropertyThis topic describes fields that can be defined for a process property in the MVPW. For configuration information, see “About the Process Property” on page 47.

Table 88 describes fields that can be defined for a process property.

Table 88. Fields of a Process Property


Name The name of the process property. A descriptive name that includes the following characteristics:



■ Unique

For more information, see “Name of a Step in a Workflow Process or a Process Property” on page 67.

Display Name A user friendly version of the property name.

The Display Name can be the same as or different from the Name.



In/Out Describes whether or not the process property is passed in or out of the process, passed into the process and returned, or used only within the process.


■ In. The process property is passed into the workflow process. Binary types cannot be assigned this value.

■ Out. The process property is passed out of the workflow process. Binary types cannot be assigned this value.

■ In/Out. The process property is passed into the workflow process and returned. Binary types cannot be assigned this value.

■ None. The process property is used only within the workflow process.

Business Object

The name of the associated business object.

Read only. For more information, see “Defining a Primary Business Component for a Business Object” on page 83.

Business Component

The name of the business component that contains the virtual field.

This value is chosen from a picklist of business components that belong to the business object of the workflow process.

Virtual Field The name of the field of the business component that is mapped to the workflow process property.

This value is chosen from a dropdown picklist of fields that belong to the business component. Only calculated fields with no calculated values appear in this picklist. Values for virtual fields are provided by the application logic at runtime.

Workflow does not require that a field of a business component be specified as a virtual field. Also, an applet can reference a virtual field in the same way that a standard field of a business component is referenced. The decision to make the field of a business component a calculated field is not directed by workflow.

Default String Initial value if the process property is a string type.

Free form text. If you enter [Value], then the process property is initialized with the value in the Value property of the workflow input property set.

Default Date Initial value if the process property is a date type.

Calendar widget.





464

Data Type The type of data that can be stored in the process property.


■ Alias. Size limit for default value, not run-time value: 250 characters.

■ Binary. For variant or binary information, usually for XML data. Binary types must be assigned the None value in the In/Out property.

■ Date. For dates.

■ Hierarchy. Data type that is used by Siebel Enterprise Application Integration in order to store data from a property set. For more information, see Overview: Siebel Enterprise Application Integration.

■ Integration Object. For storing integration objects. Integration objects use the Hierarchy data type.

■ Number. For numeric data. Size limit for default value, not run-time value: 22 digits.

■ String. For alphanumeric data, usually for UTF-16 data. Size limit for default value, not run-time value: 250 characters.

■ Strongly Typed Integration Obj. A special data type for exposing a workflow process as a Siebel inbound Web service. Siebel business services use this property when generating WSDLs.

NOTE: For both the workflow process and business service engines, values in the Strongly Typed Integration Obj and the Integration Object properties are treated as the same data type.

Default Number

Initial value if the process property is a numeric type.

Numeric widget.

Integration Object

Data type that is used by Siebel EAI in order to store data from an integration object.

For example: Account-Get Oracle Customer (Oracle)





Fields of an Input Argument of a Process PropertyTable 89 describes fields that can be defined on an input argument for the business service step, sub process step, and wait step.

Correlator Flag

Makes the process property ready for use as a correlator: a piece of business data that identifies the recipient of the incoming message. For more information, see “Workflow User Event Service Business Service” on page 486.

Check mark.

Access Mode Controls whether a process property is read only or read-write.

Read-only or Read-write.

Table 89. Fields of an Input Argument of a Process Property


Preferred Sequence (For business service steps only.)

Not applicable Not applicable

Input Argument (For business service steps only.)

The name of the input argument.

(Required) The picklist displays input arguments that exist for the business service method that is chosen.

If a method argument is defined as a business service method argument, and if the Hidden flag is set to FALSE, and if the type is Input or Input/Output, then the method argument displays in this picklist.

Subprocess Input (For sub process steps only.)

The name of the input argument.

(Required)

Type The type of argument. (Required) Choices in the picklist include:

■ Literal



■ Expression





466

Fields of an Output Argument of a Process PropertyTable 90 describes fields that can be defined on an output argument for a business service step, sub process step, and Siebel operation step.

Value A string value. Used for the Literal and Expression type of input arguments. This value can be a picklist, depending on the argument that is chosen. A string value can contain a maximum of 32,767 characters.

Property Name


Used for the Process Property type of input argument.


The name of a business component that is within the business object of the business process.

Used for the Business Component type of input argument.


The name of a field in the business component.

Used for the Business Component Field type of input argument.

Changed Not applicable Check mark.

Table 90. Fields of an Output Argument of a Process Property


Property Name

The name of the process property in which to store the results.

(Required) If Property Name is clicked, then a picklist of process properties that are defined for the process displays. For more information, see “Passing a Process Property In and Out of a Step of a Workflow Process” on page 57.

Type The type or argument. (Required) The following choices are available in the picklist:

■ Literal

■ Output Argument


■ Expression

Value A string value. Use for Literal or Expression arguments. A string value can contain a maximum of 32,767 characters.

Table 89. Fields of an Input Argument of a Process Property




Output Argument (For business service steps only.)

The name of the output argument.

Used for the Output Argument type of output argument. This is a picklist of output arguments for the method that is chosen.

If an argument is defined as a business service method argument, and if the Hidden flag is set to FALSE, and if the type is Output or Input/Output, then the argument displays in this picklist.

Subprocess Output (For sub process steps only.)

The name of the output argument.

Used for the Output Argument type of output argument.


The name of the business component within the business object of the business process.

Used for the Business Component type of output argument.


The name of a field in the business component.

Used for the Business Component Field type of output argument.

NOTE: A field that is based on a multi-value group cannot be chosen as a value for an input or output argument. If you must use a field that is based on a multi-value group, then you must define a business component for the field, then link it to the appropriate business object. For more information, see Configuring Siebel Business Applications.

Table 90. Fields of an Output Argument of a Process Property




468

Fields of a Recipient Argument of a Process PropertyTable 91 describes fields that can be defined on a recipient argument. For configuration information, see “About the Sub Process Step” on page 73.

Table 91. Fields of a Recipient Argument of a Process Property

Field DescriptionDefine This Property If. . . Possible Value

Recipient Type Code

The type of recipient. Not applicable This value is fixed as User and cannot be changed.

Value Type Code

The source from which the recipient value is derived.

Not applicable The following values are available in the picklist for this property:

■ Name

■ Expression



Recipient Name

The name of the recipient. This property is a pick applet which displays the first name, last name, and login name of users in the database.

The Value Type Code is set to Name.

Choose one name from the list of users who are available in the database.


The name of the business component.

The Value Type Code is set to Business Component.

Choose one business component.


The name of the field that resides in the business component.

The Value Type Code is set to Business Component.

Choose one business component field.

Process Property Name


The Value Type Code is set to Process Property.

Choose one process property.

Expression If the recipient value is derived from an expression, then the expression is entered in this property.

The Value Type Code is set to Expression.

The expression from which the recipient value is derived.



Fields of the Input Argument of a Search Specification of a Process PropertyTable 92 describes fields that can be defined for an input argument on a search specification on the Search Spec Input Arguments tab of the MVPW.

Table 92. Fields of an Input Argument on a Search Specification of a Process Property

Field Description

Expression Business Component

If you enter Expression in the Type field, then enter the name of the business component that evaluates the expression. For example, in the Search Specification field, you can enter:

"[Due Date] < '" + [Order Date] + "'"

The Expression business component evaluates Order Date so that the following search specification is used:

[Due Date] < '07/04/2001 18:51:26'

Filter Business Component Enter the name of the business component that provides the group of records on which you perform your search.

Search Specification The value you enter depends on the value you choose for the Type argument:

■ If you enter Literal in the Type argument, then enter a literal value in the form of an expression. For example, = 100.

■ If you enter Expression in the Type argument, then enter an expression, such as [Status] LIKE ‘*Open*’. The expression is evaluated by the Expression business component you define.

Type Required. Choose the type of value on which to base your search: Literal or Expression.

Comments Enter a text description of the purpose of the search.

Changed Check mark indicates a changed search specification.


Reference Materials for Siebel Workflow ■ Properties of Workflow Policies

470

Properties of Workflow PoliciesThis topic describes reference information for various objects used with the workflow policies module. It includes the following topics:

■ Properties of the Workflow Policy Column on page 470

■ Properties of the Workflow Policy Object on page 471

■ Properties of the Workflow Policy Component on page 472

■ Properties of the Workflow Policy Component Column on page 474

■ Properties of the Workflow Policy Program on page 475

■ Properties of the Workflow Policy Program Argument on page 476

Properties of the Workflow Policy ColumnThe Workflow Policy Columns OBLE displays a list of the available workflow policy columns. You must activate extension columns in Siebel Tools in order to make them available for use in workflow database operations.

Table 93 describes properties that are displayed in the Workflow Policy Columns OBLE.

Table 93. Properties of the Workflow Policy Column

Property Usage Description

Name Define the name of the workflow policy column, which is the default name that is displayed in the Conditions list on the Workflow Policies view.

A name that includes the following characteristics:


■ Meaningful to the policy maker

■ Descriptive of how the column is used

Changed The identifier for whether the record was added or edited.

A check mark or a blank value.

Project Define the project to which the workflow policy column belongs. You must lock the project before you can modify the column.

A project from the picklist of projects that are currently checked out.

Table Name Define the name of the Siebel database table that contains the column.

A table name from the picklist of Siebel database tables.

Column Name

Define the name of the column in the Siebel table.

A database column on the database table defined in Table Name.



Properties of the Workflow Policy ObjectThe Workflow Policy Objects OBLE displays a list of the available workflow policy objects.

Table 94 describes properties that are displayed in the Workflow Policy Objects OBLE.

Picklist Define the picklist that is used when choosing a comparison value for the column in the Workflow Policies view.

A picklist that is defined in the repository. The column that is chosen contains a corresponding Business Component field. If the corresponding Business Component field includes a picklist, then the picklist is entered in the Picklist property. For more information, see Configuring Siebel Business Applications.

Source Field

Define the field in the business component of the picklist that is the source of the comparison value.

The name of a field from a business component from the picklist that is defined in the Picklist field.

Applet Define the applet that is used to display the picklist in the Workflow Policies view.

An applet that is chosen from the picklist. Only choose a Pick applet.

Inactive Define whether this column is active or inactive.

If the column is inactive, then the column is not compiled when you compile your SRF and it is not accessible by an object.

A check mark indicates that the workflow policy column is inactive and is not compiled or accessible.

Comments Add comments that describe the purpose or use of the column.

Enter comments text.

Table 94. Properties of the Workflow Policy Object


Name Define the name of the workflow policy object.




Changed The identifier for whether the record was added or edited.

A check mark indicates the record was added or edited.

Table 93. Properties of the Workflow Policy Column




472

Properties of the Workflow Policy ComponentThe Workflow Policy Components OBLE displays a list of workflow policy components for the parent workflow policy object that is currently chosen in the OBLE. The Workflow Policy Components OBLE displays both the primary policy component and the nonprimary policy components. It also displays how each of the policy components are related.

Table 95 describes properties that are displayed in the Workflow Policy Components OBLE.

Inactive If the object is active or inactive, then define this property.

A check mark indicates that this field is inactive and is not compiled or accessible.

If an object is inactive, then the object is not compiled when you compile your SRF and it is not accessible by another object or policy.

Comments Add comments that relate to the workflow policy object.

Descriptive text.

Project Define the project name. Defined in the project picklist.

Table 95. Properties of the Workflow Policy Component


Name Define the name of the workflow policy component.




Changed Indicates whether the record was added or edited.

A check mark indicates the record was added or edited.

Primary Define whether this workflow policy component is the primary for the workflow policy object that is chosen in the Workflow Policy Objects OBLE.

A check mark indicates that this is the primary workflow component.

Each workflow policy object must contain only one primary workflow policy component.

Source Table Name Define the table on which the workflow policy component is based.

A table name from the picklist.

Table 94. Properties of the Workflow Policy Object




How the Primary Component and Nonprimary Components Are Represented in the Workflow Policy Components OBLEThe Primary property provides a visual indication of which component is the primary component and which components are the nonprimary components.

Source Column Name

Define the column in the source table that relates to another workflow policy component.

A picklist of columns from the table that is defined in the Source Table Name field. (Not required for the primary workflow policy component.)

Target Component Name

Define the target workflow policy component to which this workflow policy component is related.

A table name from the picklist. (Not required for the primary workflow policy component.)

Target Column Name

Define the column in the target workflow policy component to which the source column in this workflow policy component is joined.

A picklist of columns from the workflow policy component that is defined in the Target Component Name field. (Not required for the primary workflow policy component.)

Inactive Indicates whether the workflow policy component is active or inactive.

A check mark indicates that this field is inactive and that it is not compiled or accessible.

If the component is inactive, then it is not compiled when you compile your SRF and it is not accessible by a policy.

Comments Add comments for the workflow policy component.

Descriptive text.

Table 95. Properties of the Workflow Policy Component




474

For example, in Figure 28 the primary property for the workflow policy component named Account is checked, which defines Account as the primary component. Other components that are listed in the Workflow Policy Components OBLE are nonprimary components of the workflow policy component named Account.

Properties of the Workflow Policy Component ColumnThe Workflow Policy Component Columns OBLE displays a list of the workflow policy component columns that can be monitored for the parent workflow policy component that is currently chosen in the OBLE.

Figure 28. Representation of the Primary and Nonprimary Components in the OBLE



Table 96 describes properties that are displayed in the Workflow Policy Component Columns OBLE.

Properties of the Workflow Policy ProgramTable 97 describes properties that are displayed in the Workflow Policy Programs OBLE.

Table 96. Properties of the Workflow Policy Component Column


Workflow Column Name

Define the name of the workflow policy column that is defined in the Policy Component Column view.

A picklist of columns that are defined in the Workflow Policy Column view for the table on which the workflow policy component is based.

Alias Define the name of the column as it is displayed in the Conditions Field picklist in the Workflow Policies view.




■ Descriptive of how the column is used

The default is the workflow policy column name.

Changed Indicates whether the record was added or edited.

A check mark indicates that the record was changed.

Table 97. Properties of the Workflow Policy Program

Property Required Usage

Name Yes Define the name of the action to perform. This name is exposed in the Actions view in the Siebel client.

Changed No Indicates recent modifications.

Project No Define the Name of the project as defined in the project picklist.



476

DB Operation TypeOften, if some data changes, then other data must be changed in accordance. This data dependency is frequently implemented at the Object Manager layer through business components and run-time events. Database operations by workflow policies provide an alternative that works at the database record level.

NOTE: It is recommended that DB Operation be used only when the data dependency that is involved is centered around database records rather than around business components. For example, if one database record must be updated when another database record is inserted, then use DB Operation, regardless of which business components the two database records belong to, or whether the two database records belong to a business component at all.

Properties of the Workflow Policy Program ArgumentA workflow policy program argument defines recipients, database actions, and available substitutions. Each workflow policy program typically contains several program arguments. The fields that display in this view depend on the type of workflow policy program you choose. A workflow policy program argument is a child of a workflow policy program.

CAUTION: Certain text is not allowed in the Default Value workflow policy program argument. Do not use trailing spaces, [newline], or escape characters. Using this text can cause problems, such as failure of Workflow Monitor Agent at run time.

Type Yes You can choose the following types from the picklist:

■ DB Operation. Insert or update a database table based on arguments. For more information, see “DB Operation Type” on page 476.

■ External Program. Execute an external program in Windows.

■ Send Message. Compose and send an automatic email message.

■ Send Page. Send a page to a pager.

■ Send Broadcast Message. Send a broadcast message to a group of users.

Workflow object

No Limits use of this program to policies that are associated with this workflow policy object.

Inactive No Checked if the workflow policy program is not active.

Comments No Add text to describe the workflow policy program.

Table 97. Properties of the Workflow Policy Program




Table 98 describes properties that are displayed in the Workflow Policy Program Arguments OBLE.

Date Format with a Workflow Policy ProgramYou must use the following formats when setting a Default Value for time and date fields:

■ Date Column format: 2001-03-16

■ Time Column format: 19:26:26

■ Date Time Column format: 2001-04-05 21:25:00

A workflow policy program is executed by the Siebel Server that connects to Oracle through ODBC. As part of this process, the required data is retrieved from the database through this connection. The format of a date in an email is the format that is returned by the ODBC driver, which might be different from that used by Oracle.

Table 98. Properties of the Workflow Policy Program Argument


Applet Optional Define the Picklist applet.

Default Value Optional Define the text value of a type that depends on the Name of the program argument, an SQL statement, the text of a message, the email address of a recipient, and so forth.

The maximum length is 2000 characters.

If setting this property, then be sure to note the caution information described in this topic.

Name Required Define the parameter from a predefined set of values.

For a description of values, see “Values for the Name Property of the Workflow Policy Program Argument” on page 478.

The value is entered manually. You do not choose from a picklist.

Picklist Optional Define the Picklist object.

Required Boolean Define whether or not data entry is required. Value is TRUE or FALSE.

Source Field Optional Define the Picklist Source field.

Visible Boolean Define whether the data that is supplied by this argument displays. Value is TRUE or FALSE.

Inactive Not applicable

Checked if the program is not active.



478

Values for the Name Property of the Workflow Policy Program ArgumentYou can add functionality to a workflow policy program by defining a new workflow policy program argument. A workflow policy program argument determines how the workflow policy program performs, including what substitutions are available for a workflow policy program and how the recipients are defined.

TIP: To familiarize yourself with how a workflow policy program argument is used, examine some of the predefined arguments. For example, in the Workflow Policy Programs OBLE, query the Name property for Run External Program. This object references some of the common workflow policy program arguments that are described in Table 99. Next, query the Name property for Send Email. This workflow policy program references several workflow policy program arguments that are specific to sending a message, as described in Table 100.

Table 99 describes values for workflow policy program arguments that are common to a workflow policy program.

Table 99. Arguments in the Name Property of the Workflow Policy Program Arguments OBLE

Argument Usage Allowable Default Value

Primary Id The row ID of the violating row on which the workflow policy program is acting.

Empty.

Primary Table Define the base table to which the action is applied.

The base table can be unrelated to the record of the primary ID. For example, the violating row is in a child table and you must insert or update a record in the parent table.

Tables can also be updated that are not related to the primary ID table. For example, generate a broadcast message when a certain monitored value in the opportunity is true.

Tables defined within the Siebel business object repository, as compared to the workflow business object. Workflow business objects are used for monitoring values but are not used to code action programs.

Update Row ID Define the row ID of a table other than the primary table of the workflow policy object.

You can associate a workflow policy action with a workflow policy that updates a table.

This value is used only when the Operation Type is set to update.

The row ID you must update.

Operation Type Define the operation to perform: update or insert.

Two possible values for DB Operation: Update or Insert.




■ The value is entered manually into the Name property of the Workflow Policy Program Arguments OBLE.

■ If you run a database operation with Insert as the Operation Type, then you can choose a Default Value, New Row ID, as described previously, which provides the value for the ROW_Id field for the inserted row.

Passing Multiple Variables to SQL Program ArgumentsMultiple variables can be passed into SQL program arguments.

To pass multiple variables to SQL program arguments

1 In the Workflow Policy Program Arguments OBLE, choose Sql Statement Inputs.

2 Enter the variable names into the Default Value property.

Use the following format: [variable1], [variable2], [variable n]

Field Name Define the Name of the column in the base table to which the operation is performed.

This is one of two field column pairs.

Allowable values: Text, Variable, Function.

New Row ID For insert operations, this argument is automatically populated with the row ID of the row about to be inserted.

Empty.

Field Name (Column)

Define the Field Name, which must be identical to the Field Name of the first column pair and (Column) appended to the name.

This is the second of two column pairs.

Actual field name in the base table.

The value can not contain leading spaces.

Sql Statement Used as a way to identify more data from the database that are used as substitutions when the action is performed.

Valid SQL query statement for the RDBMS that is used: Oracle, MS SQL, Informix, or Sybase.

Sql Statement Inputs

Define the Name of the column in the base table on which the operation is performed.

Not applicable

Sql Statement Outputs

Use as a placeholder for the values that are chosen in the SQL Statement argument.

Variable Name.

Table 99. Arguments in the Name Property of the Workflow Policy Program Arguments OBLE

Argument Usage Allowable Default Value



480

Arguments for a Workflow Policy Program that Sends a MessageTable 100 describes program arguments that are specific to some workflow policy programs that send a message.

Arguments for a Workflow Policy Program that Sends a PageTable 101 describes program arguments that are specific to some workflow policy programs that send a page.

Table 100. Properties of the Send Message Program Argument

Value in Name Property Usage Value

Email Message Define the body of the email message. Text with available substitutions.

Email Message Repeated

Define the text that is repeated when the Consolidate feature is used.

Text with available substitutions.

Email Subject Define the text in the subject line of the email message.

Text.

Send to Contact Define the contacts who are available in Siebel CRM.

Not applicable

Send to Position Define the list of the positions that are available in Siebel CRM.

Not applicable

Send to Employee Define the list of employees who are available in Siebel CRM.

Not applicable

Table 101. Properties of the Send Page Program Argument


Send to Contact Define the contacts who are available in Siebel CRM.

Picklist of contacts.

Send to Employee Define the list of employees wo are available in Siebel CRM.

Picklist of employees.

Send to Position Define the list of the positions that are available in Siebel CRM.

Picklist of positions.

Send to Relative Define to send to an individual or group of individuals who are related to the Siebel Workflow object.

Not applicable



Arguments for a Workflow Policy Program that Runs an External ProgramTable 102 describes program arguments that are specific to some workflow policy programs that run an external program.

Alpha Numeric Page Message

Define the body of the text message. Text with available substitutions.

Numeric Page Message Define the body of the numeric message.

Text with available substitutions.

Table 102. Properties of the Run External Program Argument


Command Line Define the parameters to pass to the executable.

Not applicable

Executable Name Define the full path to the executable to execute.

Not applicable

Executable Type Define the mode in which the Workflow Action Agent executes the external program.


■ Wait

■ No wait

Table 101. Properties of the Send Page Program Argument



Reference Materials for Siebel Workflow ■ Predefined Business Services

482

Predefined Business ServicesThis topic describes some of the predefined business services that can be used in a workflow process. It includes the following topics:

■ Server Requests Business Service on page 482.

■ Workflow User Event Service Business Service on page 486.

■ Workflow Utilities Business Service on page 487.

■ Workflow Admin Service Business Service on page 489.

■ Other Business Services That Are Used with a Workflow Process on page 491

For more information about predefined business services, see Business Processes and Rules: Siebel Enterprise Application Integration.

Server Requests Business ServiceThis topic describes the predefined Server Requests business services. It includes the following topics:

■ Synchronous and Asynchronous Modes on page 482

■ Parameters of the Server Request Broker on page 483

■ Methods for the Server Requests Business Service on page 483

For more information, see “Examples of Using the Server Requests Business Service” on page 305.

You can use the predefined Server Requests business service to send a generic request to the Server Request Broker. The following processing modes in which the Server Requests business service can send a request are included:

■ Asynchronous

■ Synchronous

■ Schedule

Synchronous and Asynchronous ModesWhen in synchronous mode, the Server Requests business service sends a request to the Server Request Broker, then waits for a response. Otherwise, it sends the request but does not wait for a response.

It is recommended that you use the Server Requests business service in most cases, rather than the Workflow Process Manager (Server Request) business service. It is more efficient to make an asynchronous call to a workflow process. If a synchronous call is made to a workflow, then the workflow runs in the Object Manager, causing the user to wait for the process to end.



Parameters of the Server Request BrokerIf calling the Server Requests business service to submit a component request, then you must define parameters for the Server Request Broker in the input property set and parameters that are specific to a component in the child property set. Items to consider include:

■ If calling the Server Requests business service in order to call a server component, then the names of the component parameters must be referenced by the Alias Name for the parameter. The Alias Name usually does not contain spaces.

■ Failure to use the correct format results in an error message. Table 103 describes correct and incorrect formats.

■ Parameters for components must be defined with the Alias Name in the child property set.

■ There is no validation of the Alias Name.

■ These arguments do not appear in the picklist in the Administration-Business Process views.

Passing Parameters to Server ComponentsIf you must pass parameters that are not listed as available arguments, then you can define a custom business service that contains the necessary parameters. Alternatively, you can define a component job that includes the parameters that are defined as part of the job definition. For more information on component jobs, see Siebel System Administration Guide.

Methods for the Server Requests Business ServiceMethods that are available for the Server Requests Business Service include:

■ Submit Request. Use this method to submit a request to the Server Request Broker.

■ Cancel Request. Use this method to cancel a server request that is currently waiting to run.

Table 103. Format of the Component Parameter for Calling the Server Requests Business Service

Correct Format Incorrect Format

ObjReq.SetProperty "BCName", "Account" ObjReq.SetProperty "Buscomp Name", "Account"



484

Arguments of the Submit Request MethodTable 104 describes arguments for the Submit Request method.

Table 104. Arguments of the Submit Request Method of the Server Requests Business Service


Component Required if Component Job is not entered.

Enter the name of the server component to run.

Component Job Required if Component is not entered.

Enter the name of the component job to run.

Delete After Optional. Number of iterations before deleting the request. Works with Delete After Units. The default value is 0 (zero).

Delete After Units Optional. The units to measure the iterations for the Delete After argument. The default value is NoReq for synchronous where the request is not saved to the database, and Eon for asynchronous where the request is never deleted.

Other possible values include:

■ ASAP

■ SECONDS

■ MINUTES

■ HOURS

■ DAYS

■ WEEKS

■ MONTHS

■ YEARS

Description Optional. A description of the server request.

Enterprise Server Not applicable

Hold Flag Optional. For an asynchronous request only. Flag to indicate whether or not to hold the request.

Maximum Execution Time For future use.

Method Optional. Only applicable for a service based server component. For example, Workflow Process Manager or Communications Manager. Define the business service method to call.



Mode of Server Request Required. Instructs the Server Request Broker how to handle the server request. While in Auto mode, the Server Request Broker sets the mode to Synchronous or Schedule, depending on whether the Siebel client is connected or mobile.


■ DirectDB: Asynchronous request, written directly to the S_SRM_REQUEST table

NOTE: It is recommended that you use this argument in order to call an asynchronous request. If DirectDB mode is used, then the data in the S_SRM_REQUEST table is not lost. If you use Async when the Workflow Process Manager reaches MaxTasks, then it cannot process every SRM request.

■ Async: Asynchronous

■ Sync: Synchronous

■ Schedule: Schedule

■ Auto: Automatic configuration

Number of Retries Maximum number of times the request is retried in case of error.

Request ID Needed Optional. Only applicable to asynchronous and schedule mode. If this argument is set to false, then these two server requests return more quickly.

Repeat Amount Amount of units of time to repeat.

Repeat Interval Optional. The interval for repeating a request.

Repeat From Optional. Possible values are Scheduled Start, Actual Start, and End.

Repeat Interval Units Optional. Unit of intervals for a repeating request.

Repeat Number Optional. The number of repetitions for a repeating request.

Retry On Error Used for resubmitting the request, if the request errors out.

Default setting is FALSE.

Repeat Unit Unit of time to repeat.

Request ID Used for request key based routing.

Server Name Optional. Enter the specific server from which this request is run.

Start Date Optional. Start date and time.

Storage Amount Optional. Enter the amount of time that the server request is stored in the database in the event that the server is down.

Storage Units Optional. Enter the units to measure the iterations for the Storage Amount argument. The units are the same as Delete After Units.

Table 104. Arguments of the Submit Request Method of the Server Requests Business Service




486

Arguments of the Cancel Request MethodTable 105 describes arguments for the Cancel Request method of the Server Requests Business Service.

Workflow User Event Service Business ServiceThe Workflow User Event Service business service is used for one way communication from the Siebel client to the server component for the Workflow Process Manager in order to send notification that a user event occurred. A User event can be generated in the Siebel enterprise where a Siebel business service is used by calling the Workflow User Event Service business service.

To start a long-running workflow to be run in Workflow Process Manager, you must send a notification.

For more information, see “About the User Event” on page 161.

Table 105. Arguments of the Cancel Request Method of the Server Requests Business Service


Request ID Required. The ID of the server request to be cancelled.

Repeat Number Optional. The number of repetitions of the repeating server requests that are to be cancelled.



This service contains one method, GenerateEvent. Table 106 describes arguments for the GenerateEvent method.

Workflow Utilities Business ServiceThe Workflow Utilities business service contains generic utilities that are used most typically in a test environment. For an example that uses the Workflow Utilities business service, see “Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete” on page 264.

Table 106. Arguments of the GenerateEvent Method of the Workflow User Event Service Business Service


UserEventName The name of a user event is an agreement between the creator, which is an external entity, and the recipient, which is the workflow process. It includes no special significance, except that the incoming event name and the workflow instance definition must define exactly the same user event name in order to successfully communicate with each other. A user event name must be unique.

It is recommended to name the event so that it reflects the business purpose it serves. For example, Event Transferring Send Order Confirmation from Vitira To Siebel V2.

CorrelationValue Used to match an incoming message with an instance of a workflow process by using business data, such as an order number. If a workflow communicates with an external entity, then the external entity might not be aware it is communicating with a workflow process. In such cases, it is difficult for the external entity to use a Siebel identifier, such as the instance Id for the workflow process, to identify the recipient. It is more convenient to use business data, such as an order number, to identify the recipient. The correlator serves this purpose. Correlation applies to a user event that reaches a long-running workflow, which can define a process property as a correlator.

NOTE: Only one process property can be used as a correlator.

<Value> (Payload)

If the user event is generated, then the user can define data as payload. This data is delivered to the instance of a workflow process that receives the event. If the workflow is defined to wait for a user event, then the definition can define a process property to receive this payload data. The payload is a single value. Only one payload can be passed.

NOTE: If your situation requires you to send complex or structured data, then it is recommended you use the XML converter to convert the data into an XML document, then pass the resulting XML string as the payload of the event. The receiving workflow process can then call the XML converter again to recover the original data structure.



488

Echo Method of the Workflow Utilities Business ServiceThe Echo method of the Workflow Utilities business service returns a mirror image of the input arguments. Echo copies the echo inputs to the echo outputs. For example, Echo can be used to build or format the body of a mail message before calling the SendMessage method of the Outbound Communications Manager.

Table 107 describes arguments for the Echo method of the Workflow Utilities business service.

The Echo method was known as the Return Property Values method in Siebel CRM version 6.x. In Siebel version 7.0.3, the display name Return Property Values was omitted from Siebel Tools.

Output Parameter Usage with the Echo MethodWhen using the Echo Method of the Workflow Utilities business service, you define the output parameters that are populated with values from the active record of the business component that is currently manipulated by the workflow process. For example, assume you must acquire the value in the Price List Id field from the active record in the Account business component. You can use the Echo method with no input argument defined and one output argument defined.

Table 108 describes an example output parameter that is defined on the Workflow Utilities business service.

In this example, as a result of running the workflow process, the Echo Variable process property is populated with the value in the Price List Id field of the active record for the Account business component.

Table 107. Arguments for the Echo Method of the Workflow Utilities Business Service


Input Arguments This method accepts input arguments.

Output Arguments An exact copy of the input arguments.

Table 108. Example of Output Argument That Are Used with the Echo Method to Acquire a Value

Property Value

Property Name Echo Variable


Business Component Name Account

Business Component Field Price List Id



Table 109 describes methods of the Workflow Utilities business service.

Workflow Admin Service Business ServiceThe Workflow Admin Service business service allows a workflow process to perform administrative work on multiple workflow processes that are defined by a search specification. Example administrative work includes deploy, activate, export and import. This topic includes the following topics:

■ Methods of the Workflow Admin Service Business Service on page 489

■ Calling the Workflow Admin Service Business Service on page 491

For usage instructions, see “Import and Export when Using Certain Features of Siebel Tools” on page 222.

Methods of the Workflow Admin Service Business ServiceEach method of the Workflow Admin Service business service is defined by a search specification. The following methods are included:

■ Export. Exports workflow processes into a defined directory. Each workflow is exported to a separate .XML file with a file name that is the concatenation of the name of the workflow and the version number.

■ Import. Imports the export files for a workflow process into a defined directory.

■ Deploy. Deploys workflow processes.

■ Activate. Activates workflow processes.

■ DeleteDeploy. Deletes workflow deployment records.

Table 109. Methods on the Workflow Utilities Business Service

Method Name Description

Sleep Sleeps for the number of seconds defined by [value].

PropSetToText Converts a hierarchical input property set into a single string.

TextToPropSet Converts a single string into a hierarchical output property set.

DynamicDispatch Calls a service.

Echo Sends inputs to outputs.



490

Table 110 describes arguments for the methods on the Workflow Admin Service business service.

Table 110. Arguments of the Workflow Admin Service Business Service

Method Name

Argument Type Argument Name Description

Export Input ExportDir The directory to which the export files are written. For example, D:\workflows.

FlowSearchSpec The search specification that is used to identify the workflow processes to be exported. For example, [Process Name] like 'User Reg*'

Repository The repository from which workflow processes are exported. The default value is Siebel Repository.

Output NumFlowExported The number of workflow processes that are exported by the service.

Import Input ImportDir The directory where the workflow export files are located.

FileSearchSpec The search specification that is used to identify the export files for workflow processes that are to be imported. For example, User*.xml

Repository The repository into which workflow processes are imported.

ProjectName The Tools project into which workflow processes are imported. The project must be locked in order for the import to succeed.

Output NumFlowImported The number of workflow processes that are imported by the service.

Deploy Input FlowSearchSpec The search specification that is used to identify the workflow processes that are to be deployed.

A default search specification, [Status] = "In Progress", is automatically added to FlowSearchSpec. It is not necessary to explicitly define the search specification.

Output NumFlowDeployed The number of workflow processes that are deployed by the service.



Calling the Workflow Admin Service Business ServiceIt is recommended to call the Workflow Admin Service business service through the Business Service Simulator when you must activate or deploy a large number of workflow processes in bulk. This way, you can supply the search specification for each set of workflows. It is not recommended to run the Workflow Admin Service business service from within a workflow because you must change the input search specification inside the workflow for each set of workflows that are involved, resulting in the requirement to revise the workflow each time it calls the Workflow Admin Service business service.

Other Business Services That Are Used with a Workflow ProcessThis topic describes other business services that are sometimes used with a workflow process.

Synchronous Assignment Manager Requests Business ServiceThe Synchronous Assignment Manager Requests business service is used to assign an object by using Assignment Manager rules. This service includes one method, named Assign. The Assign method sends a request to the assignment manager server component. For more information, see Siebel Assignment Manager Administration Guide.

Activate Input FlowSearchSpec The search specification that is used to identify the workflow processes to be activated.

A default search specification, [Status] = "COMPLETED", is automatically added to FlowSearchSpec. It is not necessary to explicitly define the search specification.

Output NumFlowActivated The number of workflow processes that are activated by the service.

DeleteDeploy Input FlowSearchSpec The search specification that is used to identify the workflow deployment records to be deleted.

Output NumFlowDeleted The number of workflow deployment records that are deleted by the service.

Table 110. Arguments of the Workflow Admin Service Business Service

Method Name

Argument Type Argument Name Description



492

Assign Arguments for the Synchronous Assignment Manager Requests Business ServiceTable 111 describes arguments for the Assign method of the Synchronous Assignment Manager Requests Business Service.

Errors Due to Locked RecordsThe Synchronous Assignment Manager Requests business service attempts to assign records that meet the appropriate criteria, even if they are locked. To prevent an error in your workflow process that is caused by a locked record, set up a condition in your workflow process or workflow policy that skips a record that does not meet the following condition: ASGN_USR_EXCLD_FLG = N.

Outbound Communications Manager Business ServiceFor more information, see “Examples of Using the Outbound Communications Manager Business Service” on page 309.

Report Business ServiceThe Report business service automates the work that is required to send, schedule, print, save, or email a report. It also automates administrative jobs, such as synchronizing a new user. For more information, see Siebel Reports Administration Guide.

FINS Data Transfer Utilities Business ServiceThe FINS Data Transfer Utilities business service allows you to transfer data from a source business component to a destination business component without using a script. For more information, see Siebel Finance Guide.

FINS Validator Business ServiceThe FINS Validator business service allows you to validate data based on a predefined rule. It is developed through Application Administration, not through a script. The Validator business service supports custom messages. For more information, including calling the FINS Validator Service from a workflow, see Siebel Finance Guide.

Table 111. Arguments for the Assign Method of the Synchronous Assignment Manager Requests Business Service


Assignment Object Name Required. The object that you must assign.

Object Row ID Required. The row ID for the object you must assign. To assign the work item for the workflow process, set this to the Object Id process property.

Reply An output argument of this method.



Dynamic UI Business ServiceThe Dynamic UI business service and associated administration views allow you to define and render a view that contains a single, read only applet in the Siebel Financial Services application. For more information, see Siebel Finance Guide.



494


B Glossary

This appendix describes terms used with a workflow process. It includes the following topics:

■ Siebel Workflow Glossary on page 495

Siebel Workflow GlossaryThis topic describes terms that are used with a workflow process. It includes the following topics:

■ Terms That Are Used with a Workflow Process on page 495

■ Terms That Are Used with a Workflow Policy on page 499

Terms That Are Used with a Workflow ProcessTable 112 describes common terms that are used with Oracle’s Siebel Workflow.

Table 112. Terms That Are Used with a Workflow Process

Term Definition Description

7.0 Flow A workflow process that provides backward compatibility for a workflow that is defined prior to version 7.7.

Set in the Workflow Mode property on the workflow process.

Arguments Data that is passed to or received from a workflow process or a step within a workflow process.

Not applicable

Branch A possible outcome of a step within a workflow process.

A branch is followed by a step in the workflow process. If the conditions for the branch are met, then the work item proceeds to the step that follows the branch.

Branch Connector

A connector that emanates from a Start step, decision point, Wait step, or User Interact step.

Conditional logic is implemented on the branch connector.

Business Object

A group of one or more business components.

A business object represents an entity in the Siebel application that you must monitor. A workflow process is based on only one business object. Business objects are defined in Siebel Tools.


Glossary ■ Siebel Workflow Glossary

496

Business Process

A process that is associated with operational objectives and business relationships.

A business process is a set of one or more linked procedures, which collectively realize a business objective. An example of a business process is managing a new service request.

Business Service

A type of step in a workflow process in which an automated call is made to a service, such as the Outbound Communications service that handles inbound and outbound messaging.

A workflow process can include one or more business service steps.

Connector A definition of the relationship between two workflow process steps.

Not applicable

Decision Condition

The principles that are used to evaluate the logical flow that must be taken on a branch in a workflow process.

Typically, a decision condition is defined on a connector that emanates from a decision point.

Decision Point

A type of step in a workflow process in which the work item branches off to different steps, depending on a set of conditions.

A Decision Point consists of possible branches for that point in the business process. Each branch consists of one or more conditions that must be met in order for a work item to follow that branch. A workflow process can include one or more Decision Points.

End Step A type of step in a workflow process that specifies when a process instance is finished.

Not applicable

Error Exception

A type of step in a workflow process that executes in response to a deviation from normal processing.

An error exception can be an error that is generated by the system or is generated by an end user.

Expression Business Component

The name of the business component to evaluate an expression that is used as part of a search spec input argument.

Not applicable

Filter Business Component

The name of the business component to provide the group of records on which a search is performed in response to a Siebel Operation step.

The Filter Business Component is part of the search spec input argument.

Input Argument

A mechanism for providing data and configuration information as input to a step in a workflow process.

Not applicable





Interactive Workflow Process

A workflow process that assists the end user in navigating across Siebel views.


Long-Running Workflow Process

A persistent workflow process that can last for hours, days, or months.


Output Argument

A mechanism for providing data and configuration information as output from the step of a workflow process.

Not applicable

Process Property

A storage field in a workflow process that is used to contain values for use in steps as input and output arguments or for performing evaluations.

Not applicable

Process Simulator

A graphical flowchart interface that is used to debug a workflow process.

Not applicable

Search Spec Input Argument

A type of input argument that allows you to restrict the records that are considered when a Siebel Operation step is executed.

Not applicable

Service workflow process

A workflow process that executes a set of operations upon the calling of an event.


Siebel Operation

A type of step in a workflow process that performs database operations on a business component record or field. Example operations include insert, query, or update.

Not applicable

Start Step A type of step in a workflow process that defines the conditions to initiate an instance of a workflow process. When the conditions are met, an instance of the process is initiated.

A workflow process includes only one start step.

Step Branch A workflow object that provides capabilities for branching logic within a workflow process.

Not applicable





498

Step Instance

The instance of a step in a workflow process that is initiated.

A start step is initiated when conditions defined for the start step are met. A Decision Point is initiated when conditions for a branch connector are met. Other steps are initiated when the previous step finishes.

Step Recipient

The intended recipient of a sub process step.

Not applicable

Stop Step A type of step in a workflow process that specifies the conditions that cause an instance a process to terminate prior to completion.

Not applicable

Sub Process A workflow process that is called from another workflow process.

A sub process includes a separate workflow process object definition. A Sub Process is a type of step. There can be one or more Sub Process steps in a workflow process.

Task A type of step in a workflow process step that calls a Task from within a business process.

A Task step is similar to a Sub Process step in that the task step represents a container for a further set of steps below the level of the steps in the workflow in which the task step is defined.

User Interact Step

A type of step in a workflow process that is used to control the flow of Siebel views within an application.

A workflow process that contains one or more User Interact steps that guide a user through a defined flow of Siebel views based on user action, or executes a defined set of actions.

Wait Step A type of step in a workflow process that specifies when the instance of the process pauses execution and the duration of the pause.

Not applicable

Watch Window

A Window in Siebel Tools that dynamically displays record values of a business component and process property values of a workflow process.

These values are associated with and are manipulated by the workflow process being simulated.

Work Item The representation of the work that is processed in the context of a step within the instance of a workflow process .

A work item is an instance of a business object.





Terms That Are Used with a Workflow PolicyTable 113 describes common terms for Workflow Policies.

Workflow Mode

A property of the workflow process that is used to characterize run-time behavior for a workflow as a Service Flow, Interactive Flow, Long Running Flow, or 7.0 Flow.

Not applicable

Workflow Process

The representation of a business process.

A workflow process comprises one or more steps that indicate when a business process starts and ends and includes information about individual work that is performed within the business process.

Workflow Process Instance

An instance of a workflow process that is initiated.

An instance of a workflow process is initiated when the input conditions for the workflow are met. An instance consists of one or more step instances and contains one or more work items.

Workflow Step

An activity within a workflow process. Steps are logically linked together in order to define a process.

Not applicable

Table 113. Terms That Are Used with Workflow Policies

Term Definition Additional Description

Business Object

A group of one or more business components.

A business object represents an entity in Siebel that you must monitor. A workflow policy object is based on only one business object. Business objects are defined in Siebel Tools.

Business Rule The definition of how an organization must carry out a process in operations for the organization.

Not applicable

Object Type An entity in Siebel Tools that is displayed as a node on the Object Explorer.

For example, workflow policy objects, workflow policy components, workflow policy columns, and policy programs are object types.





500

Policy Action An event that Siebel executes when policy conditions are true and properties of the workflow policy are satisfied.

A policy action is based on programs. A policy action is defined in the Action applet of the Workflow Policies view. After you define a policy action, it can be used in a workflow policy.

Workflow Policy

A systematic expression of a business rule.

A workflow policy contains one or more policy conditions and one or more policy actions. If the policy conditions for a workflow policy are true, then the policy action occurs. A workflow policy is contained by one workflow policy group and is related to one workflow policy object. A workflow policy contains more properties that govern behavior for the policy. Workflow policies are defined in the Workflow Policies view.

Workflow Policy Column

A column in a table in the Siebel database that you must monitor.

You use a workflow policy column when defining a workflow policy condition for a workflow policy. A workflow policy column must be associated with a workflow policy component in order for it to be used in a workflow policy. A workflow policy column that is associated with a workflow policy component is known as a workflow policy component column. Workflow policy columns are defined in Siebel Tools.

Workflow Policy Component

A component that defines the Siebel database tables that you must monitor. A workflow policy component also defines the relationship between tables.

A workflow policy component contains workflow policy columns. A workflow policy component is defined in Siebel Tools.

Workflow Policy Component Column

A workflow policy column that is associated with a workflow policy component.

A workflow policy component column defines the database column that can be used in a workflow policy condition of a workflow policy. A workflow policy component column is defined in Siebel Tools.

Workflow Policy Condition

An expression that is compared against data in the Siebel database.

The result of the comparison is true or false. A workflow policy condition is defined in the Workflow Policies view. A workflow policy condition is defined by defining a workflow policy column, defining a comparison operator, then entering or choosing a value, if appropriate.





Workflow Policy Group

A group of one or more workflow policies.

A workflow policy group allows you to group workflow policies that share common required behavior. Siebel Server processes monitor workflow policy groups. For example, workflow policies that must be monitored hourly are different in a workflow policy group from those that are monitored weekly. A workflow policy group is defined in the Policy Groups view.

Workflow Policy Object

A group of one or more workflow policy components.

A workflow policy object represents an entity in the Siebel application that you must monitor. A workflow policy is based on only one workflow policy object. A workflow policy object is defined in Siebel Tools.

Workflow Program

The definition of an event. Types of events include Send Email, Send Page, Database Operation, Send Broadcast Message, and Run External Program. Different properties are associated with a program based on the event type. Some of the properties that can be defined for a program include the fields that can be substituted into a message, the possible recipients of a message, and the database columns that you must update. A workflow program is defined in Oracle’s Siebel Tools.





502


Index

Aa workflow step

deleting 121action parameters, definition of 328ActionAgent parameter 423ActionInterval parameter 423actions

creating for workflow policy 342working with for workflow policies 341

Actions appletfield descriptions, Actions view 341

applet fieldsWF Process Props applet 52WF Step Recipients applet 468WF Steps applet 68

architecture of workflow components 22arguments

action parameters for policies 328Create Email Activity program 394creating SQL statements for workflow policy

program 369Database Operation program 386definition of 495name property values for workflow policy

programs 478Run External program 387Send Email program 384Send Message Broadcast program 385Send Page program 383Workflow Policy Program Arguments

properties 476workflow policy program, example of

creating 368Assign Non-Respondents policy,

creating 399Assign to Campaign Email action 395Assign to Campaign program 394Assignment Request, Workflow Policy

program 329asynchronous server request 482

BBatch feature usage example 351Batch field for workflow policies 429batch manager

usage with primary and non-primary business components 173

batch modeBatchMode parameter 423running a workflow process 172

branch connector, definition of 495branch, definition of 495branches

Decision step, defining 92User Interact next step branches,

defining 86business analyst, role of 114business object

defining primary business components for 83

definition of 495, 499business process

definition of 496gathering information on 99

business rule, definition of 499business service

definition of 496using in a workflow process 70

Business Service stepabout 70defining 70

business service, predefinedasynchronous server request 482Outbound Communications Manager 491synchronous server request 482Workflow Utilities, arguments 487

business service, workflow policy action, executing from, note 344

Ccalculated fields, updating 78campaigns

Create Email Activity program 394marketing campaigns, scenario with Workflow

policies 394CheckLogCacheSz parameter 424Comparison 145comparison operations

condition criteria 189comparison values

entering date calculations 375specialized 371standard 370using in the Conditions applet 370


Index ■ D

504

Compose Condition Criteria dialog boxfield descriptions 95

condition criteria, definition of 496Conditions applet

using comparison values 370using specialized comparisons 371using standard comparisons 370

connectordefining for Decision branch 92defining for User Interact next step

branches 86definition of 496diagramming a workflow process 122point in connector, removing or adding 123

Create Email Activityabout and arguments 394creating 396

Ddatabase

Siebel database, described 22specialized comparisons 373triggers, creating 403Workflow Policies database tables 417

Database Operation, Workflow Policy program about 329

date calculations, comparison values 375Decision step

about working with 72branches, defining 92

decision stepdefinition of 496

default SQL statements 392defining a workflow process

example of 256DeleteSize parameter 424deleting

a workflow process 121a workflow process step 121workflow process instance 231

deploying a workflow process 211example of 263on a regional node 214to a mobile client 213

Eemail

consolidating for recipient, about using batch mode 429

creating Workflow policy for 358example of consolidating for recipient 351

Email for CD-ROM Campaign policy, creating 398

Email Managersetting up on Siebel Server 410troubleshooting 414

End stepabout 90defining 91

end stepdefinition of 496

Error Codedefault process property 54

error exception, definition of 496error handling

about 164assigning an error-workflow process to a

subprocess 169defining an error-workflow process 168passing properties and property sets to an

error-workflow process 58using exceptions 164

Error Messagedefault process property 54

errorsassigning an error-workflow process to a

subprocess 169defining an error exception to handle

errors 164defining an error-workflow process 168handling 164passing properties and property sets to an

error-workflow process 58errors, correcting a process and

resuming 251events

configuring a long-running workflow to wait for user events 162

generating user events 161handling 157using run-time events 157using user events 161Workflow User Event business service 486

events handling 157suspended interactive workflow 139user logout event 139

events, tracing and logging 236Example 264example

defining a workflow process 256deploying a workflow process 263

examplestesting a workflow process 262

expression business component, definition of 496

External Program, Workflow Policy program about 329

Index ■ F


FFDR

See Siebel Flight Data Recorder filesfield descriptions

Compose Condition Criteria dialog box 95input arguments for Business Service steps,

Subprocess steps, and Wait steps 49output arguments for Business Service steps,

Subprocess steps, and Siebel Operation steps 50

WF Process Props applet 52WF Step Recipients applet 468WF Steps applet 68

field name modifications 364filter business component, definition of 496

GGenerate Trigger (GenTrig)

functions of 403tips for running 404

Generic Request Server, Workflow Policy program 329

GenReqRetry parameter 424global implementation of Workflow 175GroupName parameter 424groups

creating for workflow policy 340planning policy groups 332, 333, 340working with for workflow policies 340

guidelinesautomation solutions, comparing 102, 103batch mode, running in 172branching, defining 209Business Integration Manager, using 156conditions and actions, configuring 327, 428DB operations, using 476debugging, setting monitoring levels for 235declarative or scripting techniques, choosing

between 94email consolidation, using Monitor Agent

with 428errors, setting Ignore Errors to handle 425externalizing parameters, requirements

for 317long-running workflows, using a stateful

business service with 450migrating workflows, avoiding incremental

deployment when 221non-persistent workflows, setting visibility

for 460parameters, hard coding 120policies, monitoring 341Process Mode property, configuring the 88

recovery, techniques for 250run-time events, configuring 145, 157S_ESCL_REQ, using database tools with 419sending complex or structured data,

converting data to XML for 487SQL, using 369state management, specifying 447Stop step, using the 89subprocess, passing the Object Id to 74synchronous and asynchronous processing,

configuring 214, 482, 485triggers, generating 406Type property, configuring the 57User Event business service, configuring

the 161user events, configuring 162workflow policy program, defining 367workflow processes, activating 217

IIgnoreError parameter 425input argument, definition of 496input arguments

defining for Subprocess step 74field descriptions for Business Service steps,

Subprocess steps, and Wait steps 49installation

verifying workflow policies 401interactive workflow process

building 130forward and backward navigation 131Object Id 55suspending and resuming, about 137suspension, events handling 139suspension, in-memory cache 139suspension, user logout event 139synthetic event, creating 131synthetic event, creating Next and Back

synthetic events 133synthetic event, creating ResumeLastIntFlow

synthetic event 136synthetic event, creating SaveWorkflow

synthetic event 134

KKeepLogDays parameter 425

LLastUsrCacheSz parameter 425license key validation 402logging events, table of 236long-running workflow process

assigning subprocess to end user 140


Index ■ M

506

building 139Object Id 55

MMailServer parameter 425MailTo parameter 426marketing campaigns, scenario with

Workflow policies 394Message Broadcast

Arguments applet, about and arguments and values 384

migratingpolicies, suggested strategies for 336production environment, workflow policies

to 443workflow processes 218

multilingual environmentsconfiguring a workflow process 175defining expressions for a workflow

process 176multiple records, executing actions in a

workflow process for 172multi-value group

updating a field based on a 78MVG

updating a field based on a 78

Nname, modifying workflow policy component

column and policy field names 364naming conventions

for a workflow process 44, 120for process properties 44, 120

NumRetries parameter 426

OObject Explorer

workflow policy object, defining 363Object Id

default process property 54in long-running, interactive, and service

workflow processes 55Object Manager

running a workflow process 152object properties

described 40object type

definition in relation to Siebel Tools 40definition of 499program types, table of 475workflow policy objects, modifying 378

Outbound Communications Manageravailable methods, described 491

output argumentsdefinition of 497field descriptions for Business Service steps,

Subprocess steps, and Siebel Operation steps 50

PPage Manager

parameters for 413setting up 411troubleshooting 414

palette items in Process Designer 65parallel processing, Workflow processes,

supported by 94persistence

about and using 141enabling, setting 142

planningworkflow policies, determining what to

monitor 334workflow policies, planning policies and

conditions 334workflow policy groups 332, 333, 340

policiescreating actions for 342creating groups for 340monitoring 334planning policies and conditions 334

Policies appletdescribed, Workflow Policies Groups

view 340policy action

See programscreating 342definition of 500working with 341

policy conditiondefinition of 500role in workflow policies 328

Policy Frequency or Trend Analysis chart, viewing 438

policy groupscreating 340planning, about and reasons for using 332,

333, 340predefined programs

assigning manager as owner 390close date, changing 388owner, changing 389Run External Program 354, 386Send Email, using and arguments 383Send Quote Page 392table of 381

Index ■ R


workflow action, using a predefined program to create 329

workflow policy programs 388Process Designer

design functions 45diagramming a process 122palette items 65

Process Instance Iddefault process property 55

process properties 47comparing with property sets 48concatenating 59defining 124naming conventions 44, 120passing field values to example 153workflow processes, about passing to 48

process property, definition of 497Process Simulator

running 204testing a workflow process 197, 198testing a workflow process, caution 204workflow process, using to start 198

process simulatordefinition of 497

process stepsBusiness Service step, about 70Business Service step, defining 70Decision step, about working with 72deleting 121End step, about 90End step, defining 91Siebel Operation step, about 75Siebel Operation step, defining 76Siebel Operation step, defining search

specification, examples 77Siebel Operation step, defining search

specifications 77Start step, about 69Stop step, about 88Stop step, defining 89Subprocess step, about 73Subprocess step, defining 73Subprocess step, defining input

arguments 74testing with Process Simulator, about 198User Interact step, about 85User Interact step, defining 86Wait step, about 87Wait step, defining 87

production environment, migrating to 443program

property descriptions, workflow policies 475programs

workflow policy action types 329

propertiesRun External Program Argument 481Send Message Argument 480tasks 115Workflow Policy Program Argument

properties, table of 477workflow policy programs 475

property setscomparing with process properties 48passing to a workflow process 48

Rrecipient types, table of 343recovery

workflow process, about 250workflow process, automatic 250workflow process, manual 251

referenceworkflow step and connector properties 450,

462ReloadPolicy parameter 426repository setting, verifying 402Requests parameter 427Run External

Program Argument properties, table of 481workflow policy program, creating

action 354workflow policy program. about and example

and arguments 386Run Workflow Process, about using to define

a policy 143run-time events 157

SS_ESCL_ACTION table 417, 418S_ESCL_ACTN_REQ table 418S_ESCL_LOG table 417, 418S_ESCL_REQ table 417, 418S_ESCL_STATE table 417, 418SARM

See Siebel Application Response Managementscripts, starting workflow processes,

examples 152search specification

search spec input argument, definition of 497

seeded workflow processes 111Send Campaign Email, using 393Send Email

creating for Workflow policy 358Message Arguments applet 383using and arguments 383

Send Message


Index ■ T

508

Workflow Policy program 329Send Message Argument, properties, table

of 480Send Page

Send Page Program Type, about and arguments 382

Workflow Policy program about 329Send Quote Page, using and SQL statement

examples 392Send to Relative recipient type, about

sending email or page 345server requests, submit request

arguments 484service requests

assigning manager as owner 390close date, changing to today’s date 388owner, changing to today’s date 389

service workflow processObject Id 55

Siebel administratorscorrecting a process and resuming 251deleting a workflow process instance 231stopping workflow processes 229

Siebel Application Response Management 238

Siebel ARMSee Siebel Application Response

Management 238Siebel Client

description 22Siebel database, described 22Siebel eScript, examples of calling from a

workflow process 152Siebel FDR files

See Siebel Flight Data Recorder files 239Siebel Flight Data Recorder files 239Siebel Operation Object Id

default process property 55Siebel Operation step

about 75defining 76defining search specification, examples 77defining search specifications 77definition of 497updating fields based on multi-value

groups 78Siebel Server

description of 22Email Manager, setting up 410setting up for Page Manager 411task trace file, created for listed

processes 436Siebel Tools

customizing Workflow Policies 331

description 22Workflow Processes and 39

Siebel VB, examples of calling from a workflow process 152

Sleep Time parameter 427specialized comparisons, descriptions 373SQL

SQL script file 406statements, created for workflow policy

program arguments 369statements, types of 392

Start stepabout 69defining a start step 69definition of 497

starting a workflow processabout 143as a configured business service 147from a script 152

starting of a workflow processfrom a run-time event 144from a Workflow policy 143

step branch, definition of 497step instance, definition of 498step recipient, definition of 498Stop step

about 88defining 89definition of 498

Subprocess stepabout 73assigning to end user for a long-running

workflow process 140defining 73defining input arguments 74definition of 498

synchronous server request 482synthetic event

creating 131creating Next and Back events 133creating ResumeLastIntFlow event 136creating SaveWorkflow event 134

Ttask, definition of 498tasks

properties 115testing

a workflow process, example of 262workflow process, Process Simulator 198

testing workflow policies 440trace file

Siebel Server task trace file, created for listed

Index ■ U


processes 436tracing

and logging events 236workflow process, increasing tracing

levels 236workflow process, log levels 236

Traversing a record set techniquedefinition of 79example 264

triggerdatabase triggers, creating 403Generate Trigger (Gen Trig), functions 403Generate Trigger (Gen Trig), tips of

running 404invalid trigger, avoiding in production

environment 443troubleshooting

Email and Page Manager 414notes on 442

UUpsert Operation, definition of 82Usage 173user events

configuring a long-running workflow to wait 162

using 161Workflow User Event business service 486

User Interact stepabout 85branches, defining 86creating substitute view names 86defining 86

User Interact step, definition of 498user, workflow role described 114

VValidate Tool

using for a workflow process 197values

arguments for the name property of a workflow policy program 478

described 41Message Broadcast program type 385Recipients applet fields 343Run External program type 387Send Email program type 384Send Message Broadcast program type, table

of 385VerCheckTime parameter, setting 64view names

creating substitutes using process properties 86

WWait step

about 87defining 87definition of 498global time calculations 176

watch windowdefinition of 498example usage 59, 266, 275

WF Process Props appletfield descriptions 52

WF Step Recipients appletfield descriptions 468

WF Steps appletfield descriptions 68

wildcards, using in standard comparisons 371

work item, definition of 498Workflow

associated job roles 21, 114definition 16deployment architecture 30development architecture 26, 30general principles 15global implementation 175global implementation, configuring a workflow

process in a multilingual environment 175

global implementation, defining expressions for a workflow process 176

global implementation, Wait steps and global time calculations 176

interaction with other Siebel components 36processing modes, 7.0 Flow 129processing modes, about 127processing modes, Interactive Flow 128processing modes, Long Running Flow 129processing modes, Service Flow 128requirements 100run-time architecture 31Siebel Tools and 39simulation architecture 28starting mechanisms 105upgrading 253

Workflow Action Agentfunctions of 415to run processes of 416

Workflow Action Argumentsapplets, described 341

Workflow Actionscreating Assign to Campaign Email 395creating Create Email Activity 396creating Send Campaign Email 395


Index ■ W

510

creating Send Email Message Program type 383

creating Send Page Program type 382using Database Operation program type 386

Workflow Administrator, role of 114Workflow components

architecture 22relationship between component and

primary 379relationship between Workflow object

and 325Workflow Conditions applet

using specialized comparisons in 371Workflow End User, workflow role,

described 114workflow groups

defining a workflow policy group 397planning 332

Workflow Groups appletabout using 340

workflow job rolesbusiness analyst 114end user 114workflow configurator 114

Workflow ManagerSee Workflow Policies

workflow mode, definition of 499Workflow Monitor Agent

parameters 423starting 417, 419testing workflow policies 441

Workflow objectsrelationship between Workflow policy

components and 325workflow persistence

about 141enabling, setting 142

Workflow PoliciesAssign Non-Respondents policy,

creating 399conditions, table of specialized

comparisons 373created for Send Email 358creating 346creating a policy action 342creating a workflow policy group 340definition of 328Email for CD-ROM Campaign policy,

creating 398license key validation 402migration 336moving from one group to another, note 431overview 323planning policies and conditions 334

planning, determining what to monitor 334policy condition, about 328production environment, migrating to 443program types, list of 329repository setting, viewing 402required components 401requirements, compared with a run-time

event 145Siebel Operation step, using different object

layers, described 83structure, about rule structure

(diagram) 327testing 336, 440tracing 443using specialized comparisons 371using standard comparisons 370verifying installation of 401views, administered by and example 401workflow policy action, parts of

(diagram) 328workflow policy group, about 330

Workflow Policies Actions viewapplet, field descriptions 341Message Broadcast Arguments applet 384

Workflow Policies Groups viewPolicies applet, described 340Workflow Groups applet 340

Workflow Policies Report, about 438Workflow Policies view

working with 346workflow policy

definition of 500Workflow Policy Action

Agent 332creating 342definition 328, 329working with 341

Workflow Policy Columnsdefinition of 500properties, values of 470

Workflow Policy Component Columnadding 362adding to Workflow policy objects 364associating workflow policy component

column with 366definition of 500functions of 325

Workflow Policy Componentsassociating with Workflow policy column 366defining 364definition of 500described 324function of 472OBLE, function of 474

Index ■ W


Workflow Policy Condition, description of 328

Workflow Policy Duration, description of 327

Workflow Policy Groupscreating 340definition 332definition of 501description 332planning 332, 333, 340

Workflow Policy Log 441Workflow Policy Monitor Agent 332Workflow Policy Object

adding new 363adding workflow policy component columns

to 364defined using Object Explorer 363definition of 501modifying 378

Workflow Policy Program Argumentsabout 476creating or modifying 368properties, table of 477

Workflow Policy Programscreating or modifying 366described 329predefined, table of 381property descriptions 475

workflow processadministering 227business services, enabling 71defining a new workflow process 120defining parameters 117defining process properties 124defining step details 126defining steps 117definition of 499deleting 121deploying as a Web service 215deploying, about 211deploying, on a regional node 214deploying, to a mobile client 213migration from development to

production 218process properties 47process properties and property sets 48publishing and activating 211running in batch mode 172running in the application object

manager 152running in the Workflow Process Manager

server component 150running on Object Manager 152starting, about 143

starting, as a configured business service 147

starting, from a run-time event 144starting, from a script 152starting, from a script, examples 152starting, from a Workflow policy 143

workflow process instance, definition of 499

Workflow Process Managerabout running a workflow process in batch

mode 172server component, running a workflow

process 150workflow process parameters

about defining 117workflow process steps

about defining 117workflow process, designing

definitions, working with 117workflow process, general information and

planningconsiderations for planning 83described 22diagramming steps 122gathering information for 99modifying existing definitions 118naming conventions 44, 120overview 22overview of developing 27planning tips 83process steps, about diagramming 122, 124,

126requirements 109reviewing existing definitions 117Siebel Tools and 39types, 7.0 Flow 129types, about 127types, Interactive Flow 128types, Long Running Flow 129types, Service Flow 128

workflow process, monitoringabout 233correcting a process and resuming 251deleting a workflow process instance 231levels 233stopping 229tracing and logging events, table of 236

workflow process, testing and troubleshooting

purging workflow process instances from the log 231

recovery 250stopping an instance 229testing 197, 198


Index ■ W

512

testing caution 204testing workflows involving server

components 198testing, running the Process Simulator 204testing, Validate Tool 197troubleshooting Siebel Flight Data Recorder

files 239troubleshooting, increasing tracing

levels 236troubleshooting, Siebel Application Response

Management 238troubleshooting, tracing and event log

levels 236

Workflow ProgramsAssign to Campaign 394configuring predefined 388Create Email Activity 394definition of 501Send Campaign Email, using 393

workflow recovery manager, definition of 246

workflow step, definition of 499Workflow User Event business service

generating user events 161Workflow Utilities, arguments 487

BPFWorkflow

Documents

Transcript of BPFWorkflow