Bpf Workflow

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    1 Favorite

    Bpf Workflow - Presentation Transcript

    1. Siebel Business Process Framework: Workflow Guide Version 8.0 December 2006
    2. Copyright © 2005, 2006, Oracle. All rights reserved. The Programs (which include both the software and documentation) contain proprietary information; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited. The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. This document is not warranted to be error- free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose. PRODUCT MODULES AND OPTIONS. This guide contains descriptions of modules that are optional and for which you may not have purchased a license. Siebel’s Sample Database also includes data related to these optional modules. As a result, your software implementation may differ from descriptions in this guide. To find out more about the modules your organization has purchased, see your corporate purchasing agent or your Siebel sales representative. If the Programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the United States Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS. Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065. The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any damages caused by such use of the Programs. Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.
    3. Contents Chapter 1: What’s New in This Release Chapter 2: Overview of Siebel Workflow General Principles of Workflow 18 Understanding the Workflow Processes Module 19 Understanding the Workflow Policies Module 21 Workflow Roles 25 Chapter 3: Introduction to Workflow Processes Overview of the Workflow Architecture 27 Workflow Processes Development Lifecycle 28 Analyzing Process Requirements 28 Defining Workflows 31 Identifying and Building Exception Handling 37 Testing and Troubleshooting Workflows 39 Migrating Workflows to Production 40 Deploying Workflows in Production 42 Monitoring Workflow Execution 42 Design-Time Architecture of Workflow 43 Simulation Architecture of Workflow 45 Deployment Architecture of Workflow 46 Run-Time Architecture of Workflow 47 Workflow Interaction with Other Siebel Components 52 Chapter 4: Planning Workflow Processes Gathering Information for Workflow Process Planning 55 Understanding Workflow Process Requirements 56 Seeded Workflow Processes 57 Considering Business Objects and Business Services When Planning Workflow Processes 57 Defining a Primary Business Component for a Business Object 57 Enabling a Business Service for Workflow Processes 58 Siebel Business Process Framework: Workflow Guide Version 8.0 3
    4. Contents ■ Defining a Test and Migration Strategy for Workflow Processes 58 Verifying Workflow Policies Installation 59 Verifying the Repository Setting for Workflow Policies Installation 59 Verifying the Workflow Setup for Workflow Policies Installation 59 Upgrading Siebel Workflow 60 Chapter 5: For Developers: Basics of Building Workflow Processes Overview of Developing a Workflow Process 61 Siebel Tools and Workflow Processes 62 Using Process Designer in Siebel Tools 64 About the Design Functions of the Process Designer 64 About the Multi Value Property Window 65 Field Descriptions: Workflow Processes 66 Field Descriptions: Process Properties for Workflows 71 Process Designer Palette Items 73 About Defining Workflow Process Parameters and Steps 75 Reviewing Existing Workflow Processes 76 Defining a New Workflow Process 76 Naming Conventions for Workflow Processes, Steps, Branches, and Process Properties 77 Modifying Existing Process Definitions 78 Tutorial: Using Process Designer in Siebel Tools 79 Chapter 6: For Developers: Workflow Process Steps About the Workflow Processes OBLE in Siebel Tools 89 Diagramming a Workflow Process 90 Defining Step Details for a Workflow Process 91 Deleting a Workflow Step 92 Deleting a Workflow Process 92 Copying a Workflow Process 92 About Process Properties 93 Process Properties Versus Property Sets 95 Passing Property Sets by Reference 96 Defining Process Properties 96 Concatenating Process Properties 97 Passing Process Properties In and Out of Steps 98 Field Descriptions for Defining Workflow Process Steps 99 Field Descriptions: Workflow Steps 99 4 Siebel Business Process Framework: Workflow Guide Version 8.0
    5. Contents ■ Field Descriptions: Workflow Branches 102 Field Descriptions: Compose Condition Criteria Dialog Box 105 About Start Steps 107 Defining a Start Step 107 Defining Next Step Branches for Start Steps 108 About Conditions and Values 108 Building Expressions with Expression Builder 109 About Decision Points 112 Defining a Decision Point 113 Defining Decision Branches 113 About Conditions and Values for Decision Points 114 About Business Service Steps 114 Field Descriptions: Input Arguments for Business Service Steps, Subprocess Steps, and Wait Steps 115 Field Descriptions: Output Arguments for Business Service Steps, Subprocess Steps, and Siebel Operation Steps 116 Defining a Business Service Step 118 Defining Input Arguments for Business Service Steps 119 Defining Output Arguments for Business Service Steps 119 Enabling the Pass By Reference Feature for Business Services That Support It 119 About Subprocess Steps 120 Field Descriptions: Step Recipients 120 Field Descriptions: Subprocess Steps 121 Defining a Subprocess Step 122 Defining Input Arguments for Subprocess Steps 122 Defining Output Arguments for Subprocess Steps 123 Defining Recipients for Subprocess Steps 123 Enabling a Subprocess to Support Pass By Reference 123 About Siebel Operation Steps 124 Defining a Siebel Operation Step 125 Defining Fields for a Siebel Operation Step 126 Defining Siebel Operation Search Specifications 126 Defining Siebel Operation Step Output Arguments 127 Field Descriptions: Search Specifications 128 Updating a Field Based on a Multi-Value Group 129 Traversing a Record Set 129 About Wait Steps 130 Defining a Wait Step 130 About User Interact Steps 131 Defining a User Interact Step 132 Siebel Business Process Framework: Workflow Guide Version 8.0 5
    6. Contents ■ Defining User Interact Next Step Branches 133 About Conditions and Values for User Interact Next Step Branches 133 Creating Substitute View Names with Process Properties 134 About Task Steps 134 Defining a Task Step 134 About Stop Steps 137 Defining a Stop Step 138 Defining Stop Step Input Arguments 138 About End Steps 139 Defining an End Step 139 Chapter 7: For Developers: Understanding How Workflow Processes Are Designed About Workflow Modes 141 About 7.0 Workflow Processes 143 About Long-Running Workflow Processes 143 About Interactive Workflow Processes 144 About Service Workflow Processes 144 Building Long-Running Workflow Processes 145 Assigning Subprocesses to End Users to Create Collaborative Long-Running Workflows 145 Configuring Long-Running Workflows to Invoke Tasks 146 Building Interactive Workflow Processes 146 Creating Synthetic Event Buttons to Control User Navigation 147 About Suspension and Resumption of Interactive Workflow Processes 151 About Forward and Backward Navigation between Views 153 Using Workflow Persistence 154 About Workflow Persistence 154 Enabling Workflow Persistence 155 Handling Events 155 Using Run-Time Events 155 About the Workflow User Event Business Service 157 Generating User Events with the User Event Business Service 158 Configuring Long-Running Workflow Processes to Wait for User Events 159 Workflow and Global Implementations 159 Configuring Workflows in a Multilingual Environment 159 Defining Expressions for Workflows Running in a Multilingual Environment 160 Wait Steps and Global Time Calculations in Workflow 160 Handling Errors 161 6 Siebel Business Process Framework: Workflow Guide Version 8.0
    7. Contents ■ Using Error Processes to Handle Errors 161 Passing User-Defined Process Properties and Property Sets to Error Processes 162 Assigning Error Processes to Subprocesses 162 Using Exceptions to Handle Errors 163 Defining Exceptions 163 Recovering Workflow Processes 164 Automatic Recovery of Workflow Process Instances 164 Manual Recovery of Workflow Process Instances 165 Invoking Workflow Processes 165 About Invoking a Workflow Process 165 Invoking a Workflow Process from a Workflow Policy 166 Invoking a Workflow Process from a Script 167 Example: Invoking a Workflow from a Script in Object Manager 168 Example: Invoking a Workflow from a Script to Pass Field Values to Process Properties 168 Invoking a Workflow Process from a Run-Time Event 169 Invoking a Workflow Process through a Configured Business Service 170 Running a Workflow Process in the Workflow Process Manager 171 Running a Workflow Process in the Application Object Manager 172 Running a Workflow Process in Batch Mode 172 Chapter 8: For Developers: Testing Workflow Processes Using the Validate Tool to Correct Errors in Workflow Processes 175 Testing Workflow Processes with the Process Simulator 176 About the Process Simulator and Supported Modes for Simulation 177 Running the Process Simulator 178 Troubleshooting Workflow Process Simulation 180 Testing Workflows That Involve Server Components 180 Chapter 9: For Administrators: Administering Workflow Processes About Deploying Workflow Processes 181 Deploying Workflow Processes 182 Deploying Workflow Processes to Mobile Clients 184 Restricting Mobile Client Routing 184 Deploying Workflow Processes on Regional Nodes 184 Migrating Workflow Processes from Development to Production 185 Importing or Exporting a Process Definition 187 Administering Workflow Processes in the Run-Time Client 188 Siebel Business Process Framework: Workflow Guide Version 8.0 7
    8. Contents ■ Viewing Run-time Instances of a Workflow Process 190 Stopping a Workflow Process Instance 190 Stopping All Workflow Process Instances of a Specific Process Definition 190 Deactivating a Workflow Process Instance 191 Expiring a Workflow Process Instance 192 Purging a Workflow Process Instance from the Log 192 Activating Fields Used by Workflow Processes 193 Monitoring and Troubleshooting Workflow Processes in Production 193 About Workflow Process Monitoring 193 Setting Workflow Process Monitoring Levels 195 Setting Tracing and Event Log Levels 196 Capturing Data with Siebel Application Response Management (Siebel ARM) 197 Recording Behavior with Siebel Flight Data Recorder (FDR) Files 198 Troubleshooting Workflow Processes in a Production Environment 198 Chapter 10: Workflow Policies About Planning Workflow Policies 203 Planning Workflow Policy Groups 203 Planning Workflow Policies 204 Determining What to Monitor When Planning Policies 205 Planning Policies and Conditions 205 Planning Workflow Policy Actions 206 Scenario for Planning Workflow Policies: Notification for 30%+ Discounts 206 Scenario for Planning Workflow Policies: Notification for Large Number of Open Service Requests 208 Defining a Test and Migration Strategy for Workflow Policies 209 About Creating Workflow Policies 209 About the Workflow Policies Views 210 Defining Workflow Policy Actions 210 About the Actions Applet in the Workflow Policies Action View 211 About the Arguments Applet in the Workflow Policies Action View 211 Using the Send Page Program Type 212 Using the Send Message Program Type 213 Using the Message Broadcast Program Type 214 Using the Run External Programs Type 215 Using the Database Operation Program Type 215 About the Recipients Applet 217 Creating a Workflow Policy Action 218 Example of a Workflow Policy Action: Creating a Send Page Action 219 Example of a Workflow Policy Action: Creating a Send Email Action with a Repeating Message 220 8 Siebel Business Process Framework: Workflow Guide Version 8.0
    9. Contents ■ Example of a Workflow Policy Action: Creating a Send Message Broadcast Action 221 Example of a Workflow Policy Action: Creating a Database Operation Action 222 Example of a Workflow Policy Action: Creating a Run External Program Action 222 Creating Workflow Policy Groups 224 About the Workflow Groups Applet 225 About the Workflow Policies Applet 225 Creating Workflow Policies 225 About the Policies List Applet 228 About the Conditions Applet 229 About the Actions Applet 233 Example of a Workflow Policy: Creating a Send Page Workflow Policy 234 Example of a Workflow Policy: Creating a Send Email Workflow Policy 234 About Customizing Workflow Policies with Siebel Tools 235 Siebel Tools and Workflow Policies 236 Siebel Tools Definitions in the Workflow Policies Views 237 About Workflow Policy Objects 238 Creating a Workflow Policy Object 238 Workflow Policies and the Siebel Tools Views 239 About the Workflow Policy Column List View 240 Configuring a Workflow Condition Based on a Foreign Key 241 About the Workflow Policy Object List View 242 About the Workflow Policy Component List View 242 About the Workflow Policy Component Columns View 244 Defining a Workflow Policy Column 245 Defining a Workflow Policy Component 246 Defining a Workflow Policy Object 246 Modifying Policy Column Names 247 Adding Policy Columns to a Workflow Policy Object 247 Associating a Column with a Workflow Policy Component 248 About the Validate Tool in Siebel Tools 248 Modifying an Existing Workflow Policy Object 248 About Workflow Policy Programs 251 About the Program List View 252 About the Workflow Policy Program Argument List View 252 Creating a Workflow Policy Program 256 Example of Creating a Workflow Policy Program Argument: Send Opportunity Email 258 Creating SQL Statements for Workflow Policies Program Arguments 258 About Predefined Workflow Policy Programs 259 Example of Using a Predefined Workflow Policy Program: Change SR Close Date to Today 259 Example of Using a Predefined Workflow Policy Program: Change SR Owner 260 Siebel Business Process Framework: Workflow Guide Version 8.0 9
    10. Contents ■ Example of Using a Predefined Workflow Policy Program: Change SR Owner to Manager 261 Example of Using a Predefined Workflow Policy Program: Send Quote Page 262 Making Object Types Available in the Siebel Client 263 About Workflow Policies Server Administration 263 Creating Database Triggers 263 About Database Triggers and Database Administration 265 Running Generate Triggers 266 Running the SQL Script File 267 About Database Triggers and Remote Users 268 Setting Up the Siebel Server for Email Manager 268 Setting Up the Communications Profile to Send Email through Workflow 268 Starting Email Manager 269 Setting Up the Siebel Server for Page Manager 270 Troubleshooting the Email and Page Managers 272 Executing Workflow Policies with Workflow Monitor Agent 273 Using Workflow Monitor Agent 275 Using Workflow Action Agent 281 Starting Workflow Agent Processes Automatically with Siebel Server 283 Deleting Expired Workflow Policies 283 About Workflow Policies and Siebel Server Task Trace Files 285 Viewing Trace Files in Siebel Server Administration 285 Viewing Trace Files in the Siebel Server Log Directory 286 About Tracing and Event Log Levels 286 About Workflow Policies Analysis Charts and Reports 286 Using the Policy Frequency or Trend Analysis Chart 286 Using Workflow Policies Reports 287 About Workflow Policies and Siebel Marketing 287 Using Workflow Policy Programs for Campaign Execution 287 Using the Send Campaign Email Workflow Policy Program 288 Using the Create Email Activity Workflow Policy Program 288 Using the Assign to Campaign Workflow Policy Program 289 Scenario for Creating a Marketing Campaign with Workflow Policies 289 About Testing Workflow Policies 292 Testing New Policies and Monitoring the Results 293 Troubleshooting Workflow Policies 293 Workflow Policies and Tracing 294 Migrating Policies to the Production Environment 294 Predefined Programs 295 10 Siebel Business Process Framework: Workflow Guide Version 8.0
    11. Contents ■ Chapter 11: Reference Materials for Siebel Workflow Siebel Workflow Terminology 298 Examples of Creating Workflow Processes 301 Example: Attach an Activity Plan to an Opportunity and Test with the Process Simulator and the Run-time Client 301 Example: Creating a Workflow Process Triggered by a Run-time Event 313 Example: Creating a Service Flow Workflow 316 Example: Run-time Event Workflow with User Interact Step to Navigate the End User to a View 321 Example: Externalize Parameters to be Used by Siebel Workflow 324 Predefined Business Services 328 FINS Data Transfer Utilities Business Service 329 FINS Validator Business Service 329 FINS Dynamic UI Business Service 329 Outbound Communications Manager Business Service 329 Report Business Service 329 Synchronous Assignment Manager Requests Business Service 329 Server Requests Business Service 330 Workflow Utilities Business Service 333 Workflow Administration Service 333 Passing Parameters to and from Workflow and Data Manipulation within Workflows 336 Manipulating Data Within Workflows 336 Passing Parameters to and from Workflow with the Workflow Process Manager Business Service 339 Example Script: Invoking Workflow Programmatically and Constructing an Input Property Set 340 Example Script: Defining Property Sets for the Input Property Set 340 Example Script: Constructing Property Sets 340 Example Script: Assembling Properties and Child Property Sets into the Input Property Set 341 Example Script: Invoking the Workflow Process Manager Business Service and Passing It the Input Property Set 341 Passing Parameters from Workflow to Global Variables (Profile Attributes) 342 Using Expressions with Workflow Processes 342 Using the Timestamp Argument 343 Index Siebel Business Process Framework: Workflow Guide Version 8.0 11
    12. Contents ■ 12 Siebel Business Process Framework: Workflow Guide Version 8.0
    13. 1 What’s New in This Release What’s New in Siebel Business Process Framework: Workflow Guide, Version 8.0 In this release, the title of this guide has been changed to Siebel Business Process Framework: Workflow Guide from its previous title of Siebel Business Process Designer Administration Guide. Table 1 lists changes described in this version of the documentation to support release 8.0 of the software. Table 1. New Product Features in Siebel Business Process Framework: Workflow Guide, Version 8.0 Topic Description Multiple-Document Interface Oracle’s Siebel Tools is now a multiple-document interface (MDI) application. This means that when you use Siebel Workflow, you can have multiple object editors open at any given time See Using Siebel Tools. displaying not only workflow processes, but other objects as well. Debug toolbar This toolbar contains buttons that let you access Siebel VB and Siebel eScript debugging tools. The relevant button for See Using Siebel Tools. Siebel Workflow is the Watch button that lets your monitor the contents of program variables in the Variable window when simulating a workflow from Siebel Tools. WF/New Task Editor toolbar In this release, you can use the debug toolbar to publish, activate, revise, and expire workflows/tasks. See Using Siebel Tools. Automatic Revisions Workflow and task configuration options that ensure you are See Using Siebel Tools. working on the most current workflow/task version. Three-way merge for upgrades Siebel Tools now supports three-way merge during upgrades for Workflow objects. This merge makes sure that the See “Upgrading Siebel Workflow” on customer's extensions to these objects carry forward to the page 60. new version. Multi-value Properties Window In this release, the Multi-value Properties Window (MVPW) replaces the list applet in most cases within the Siebel Tools See “About the Multi Value Property side of the Business Process Designer. You use the MVPW to Window” on page 65. view, create, and delete process properties to store data for a workflow process. You can also create, delete, and assign input/output arguments for a process step. The MVPW is context-sensitive; it displays the appropriate set of properties based on the object selected. Siebel Business Process Framework: Workflow Guide Version 8.0 13
    14. What’s New in This Release ■ Table 1. New Product Features in Siebel Business Process Framework: Workflow Guide, Version 8.0 Topic Description State Management Type field In this release, a new feature for Siebel Order Management— setting required for all Web Channel session state management—requires that all workflow processes business services are marked with a setting describing the Object Manager client-session mode when making a request See “Field Descriptions: Workflow to the Siebel server. Processes” on page 66. Because the Workflow engine is a business service, this new For more information on the Web feature means the addition of a new property field, called Channel session state State Management Type, for all workflow processes. By management feature, see Siebel default, this property is set to Stateless. You can set this field Web UI Dynamic Developer Kit to indicate whether a workflow process is stateless or Guide. stateful. Strongly typed integration This is a new data type for defining process properties specifically object data type used by web services. Strongly typed objects allow you more functional scripts and better performance. See “Field Descriptions: Process Properties for Workflows” on page 71. Process Designer naming Siebel Workflow automatically assigns a name and sequence conventions for workflow steps number to each step and connector that you create within a and branches workflow process. The name given is based on the type of step or connector. The sequence number differentiates See “Naming Conventions for instances of the same type of step or connector. Workflow Processes, Steps, Branches, and Process Properties” When a new step of the same type is added to the workflow, on page 77. if there is a gap between the sequence numbers for the type (gaps can be created when steps are deleted), the first sequence number in the first gap interval for the step type will be the sequence assigned to the new step. Pass By Reference feature Subprocess methods tasked with modifying large amounts of data must copy large quantities of data. This can negatively See “Passing Property Sets by impact performance and scalability of these method Reference” on page 96. invocations. Pass By Reference is a feature that allows you to avoid passing large property sets, by passing just a pointer to the property sets. This feature employs a new user property, Business Service User Prop, which is represented by a new child object of the Business Service object. Enhancement to Subprocess Subprocesses now support passing property sets by step reference with a new Workflow Process attribute called Pass By Ref Hierarchy Argument. This attribute specifies whether See “Enabling a Subprocess to subprocesses within the workflow process are enabled for use Support Pass By Reference” on with the Pass By Reference feature. The default setting is page 123. FALSE. 14 Siebel Business Process Framework: Workflow Guide Version 8.0
    15. What’s New in This Release ■ Table 1. New Product Features in Siebel Business Process Framework: Workflow Guide, Version 8.0 Topic Description New operation types In this release, the following operations were added: Delete, NextRecord, PrevRecord, and QueryBiDirectional. See “Defining a Siebel Operation Step” on page 125. Task step The Task step has been introduced to accommodate the new Siebel Task UI feature in this release, which is integrated with See “About Task Steps” on Siebel Workflow. You use the Task step to launch tasks from page 134. within a workflow process. For information on the new task feature, see Siebel Business Process Framework: Task UI Guide. Improved Process Simulator The Watch window allows you to see object and variable Watch window values during simulation. In this release, if the variable is editable, you can update it in the Watch window to feed a See “About the Process Simulator value to the simulation. and Supported Modes for Simulation” on page 177. Application Deployment ADM is an automated deployment framework that provides a Manager (ADM) enhancements mechanism to migrate enterprise customization data (views, responsibilities, assignment rules, and so on) from one Siebel See “Migrating Workflow Processes application environment to another. from Development to Production” on page 185. In this release, workflow processes and workflow policies are data types newly available for migration through ADM. Using See “Migrating Policies to the ADM, you can perform bulk migration and activation of Production Environment” on workflows, and you can migrate policies in batch as well. page 294. Also see Siebel Application Deployment Manager Guide. Workflow Admin Service Business A new business service that allows you to perform batch Service import/export, deployment, and activation of multiple workflow processes by way of a search specification. See “Migrating Workflow Processes Alternatively, you can perform client-side batch activation from Development to Production” and expiration by way of the File menu in the application. on page 185. New child views in the In the enhanced Workflow Deployment view (Administration - Workflow Deployment view Business Process), administrators can now view the parent- child relationship between a workflow process definition and See “Administering Workflow its run-time records. Processes in the Run-Time Client” on page 188. Administrators can use the multi-select function in the list views to perform activation, deletion, and expiration of workflow processes in batch. Siebel Business Process Framework: Workflow Guide Version 8.0 15
    16. What’s New in This Release ■ 16 Siebel Business Process Framework: Workflow Guide Version 8.0
    17. 2 Overview of Siebel Workflow This chapter provides a conceptual overview of Siebel Workflow. Siebel Workflow is a customizable business application that allows you to define, manage, and enforce your business processes— creating process automation within the Siebel application. Siebel Workflow orchestrates the various Siebel process-automation technologies. Workflow processes graphically sequence a series of automation steps that support a process, and they specify inputs and outputs for individual steps and for the process as a whole. Using Siebel Workflow to manage business processes in your organization, you can address such challenges as: ■ Automating escalation of events and notification of appropriate parties ■ Routing and assigning work ■ Processing work ■ Enforcing authorization and transition rules This chapter is organized as follows: ■ “General Principles of Workflow” on page 18 ■ “Understanding the Workflow Processes Module” on page 19 ■ “Understanding the Workflow Policies Module” on page 21 ■ “Workflow Roles” on page 25 Siebel Workflow and Process Automation Siebel Workflow brings together Workflow Processes and all other repository configuration objects, including the Workflow Policies module, for creating a comprehensive workflow design. The process- automation technologies in Siebel include: ■ Workflow Processes. Allows you to define your company’s business processes using a familiar flowcharting interface. A workflow process consists of one or more process steps such as start steps, subprocesses, decision points, and tasks. Workflow Processes is the key technology behind building business processes in the Siebel application. ■ Workflow Policies. Allows you to define policies that can act as triggers to execute a process. A policy consists of conditions and actions. When policy conditions are met, the policy action executes the relevant process. Workflow Policies generates events based on database operations. Workflow Policies is effective for performing simple actions such as sending email, or creating an activity or assignment. Siebel Business Process Framework: Workflow Guide Version 8.0 17
    18. Overview of Siebel Workflow ■ General Principles of Workflow ■ Tasks. Allows you to create wizard-like user interfaces with multiple-step, interactive operations that can include branching and decision logic to guide end users through task execution. Siebel Task UI allows navigation both backward and forward within task execution, and allows task execution to be paused and resumed as needed. For more information about Siebel Task UI, see Siebel Business Process Framework: Task UI Guide. ■ Assignment Manager. Expresses rules to assign records to people. Enables assignment of records based on skills, workload, and availability. Supports ownership transitions within a process. For more information on Assignment Manager, see Siebel Assignment Manager Administration Guide. ■ SmartScript. Guides users through data-entry activities. SmartScript is effective for call scripting and includes basic support for transaction-level commits. For more information on SmartScript, see Siebel SmartScript Administration Guide. ■ Activity Template. Provides a pre-defined series of steps to be completed. Activity Template is effective for handling asynchronous/offline work. For more information on Activity Template, see Siebel Applications Administration Guide. ■ State Models. Restricts transition of record status based on a current value and the position of the user. State Models can also enforce directional progression of status, so that, for example, Opportunities move forward but not backward through a pipeline. For more information on State Models, see Siebel Applications Administration Guide. While each of the above technologies provide specific functionality to allow business-process automation in the Siebel application, it is Workflow Processes that orchestrates many of the services the technologies perform. A workflow process orchestrates services either by directly invoking each technology, or by interacting with the other technologies through the Siebel event model. General Principles of Workflow In theory, businesses are managed according to policies and procedures that allow efficiency, quality service, adherence to contractual agreements, and profitability. These policies enforce business processes such as: ■ Allowing that response time objectives are met for customer callbacks and open service requests ■ Specifying review policies for important processes like contracts, quotes, or product shipments ■ Monitoring service requests or opportunities over time In practice, the benefits of policies often are not realized because policies are not consistently enforced. This may be because of the large number of processes or because of the dynamic nature of the information being monitored. The management of important events is central to the enforcement of business workflow. Workflow is the timely management of an event to allow proper handling. For example, service departments have procedures for managing an open service request or making sure that response times are met. A workflow can increase the visibility of these processes within an organization and check that they are correctly handled. 18 Siebel Business Process Framework: Workflow Guide Version 8.0
    19. Overview of Siebel Workflow ■ General Principles of Workflow Service departments have sets of defined rules that match their policies and service agreements such as: ■ Standards for processing calls. For example, when a Severity 1 call is assigned, the new owner is automatically paged. ■ Contracted service agreements that must be adhered to. For example, customers may purchase a support agreement guaranteeing a callback in two hours and problem resolution in four hours. Sales departments also have rules to enforce desired business practices, such as: ■ Discount authority. If a sales representative quotes a discount exceeding the maximum discount allowed, it requires the approval of the district sales manager or VP of Sales. ■ Pipeline management. Each sales representative manages his or her pipeline to ensure sufficient levels of prospects at each stage of the sales cycle. If an area of the pipeline needs attention, the representative or manager should be alerted. ■ Forecasting accuracy. Opportunities that are forecasted but never closed or forecasts having wide discrepancies with the actual revenue need to be flagged. Understanding the Workflow Processes Module Workflow Processes is the module in Siebel Workflow that you use to create and administer workflow processes. Workflow Processes Configuration Overview Workflow Processes allows you to define your company’s business processes using the Process Designer in Siebel Tools. Hosting the Process Designer in Siebel Tools provides an integrated development environment to configure Workflow along with other Siebel objects. This integrated development environment allows a top-down development framework for building business logic, starting with the creation of a workflow process, then providing pluggable services and data objects that make the process executable. You define a process that consists of process steps such as Start steps, Decision Points, Subprocess steps, or Business Service steps to complete work. Work can be completed with either a predefined business service or a custom business service. Predefined actions include updates to the Siebel database, notifications (such as an email or page), integration messages to external systems, and calls to invoke server tasks. Custom actions can be defined by using Siebel VB or Siebel eScript. Workflow Processes Administration Overview Workflow Processes can vary from a simple process such as entering a product order to a complex process such as managing call center workflow. Complex processes can comprise multiple smaller processes. Workflow Processes are administered through the Administration - Business Process views in the Siebel Client. Instructions for accessing and using the Administration - Business Process views are in Chapter 9, “For Administrators: Administering Workflow Processes.” Siebel Business Process Framework: Workflow Guide Version 8.0 19
    20. Overview of Siebel Workflow ■ General Principles of Workflow Invoking Workflow Processes Workflow processes can be invoked from events in the Siebel application or from external systems. Within the Siebel application, a process can be invoked from a workflow policy, an event (such as an insert of a record or a button click), or a server component. From an external system, processes can be invoked using COM or CORBA. For information on invoking a workflow process, see “About Invoking a Workflow Process” on page 165. Sample Workflow Process Scenario To help you understand how the Workflow Processes module works, see the usage scenario “Scenario: New Service Request”. You can view sample workflow processes in detail by selecting the project Workflow - Samples in Siebel Tools. Scenario: New Service Request Prior to implementing Siebel Call Center, ABC Computing found itself unable to resolve many customer issues in a timely manner. To better track and manage service requests, ABC implements the Service Request module and automates the company’s service-request management process. The goal is to meet a service-level agreement (SLA) commitment by making sure that all newly- logged service requests (SRs) are resolved within a specific amount of time. ABC Computing wants the SRs to be assigned by the system to the best representative based on availability and matching skills. If the SR needs immediate attention, the company wants to notify the owner of the SR. This automation is achieved using Siebel Business Process Designer. When an SR is logged, a workflow process is triggered. The workflow process calls Siebel Assignment Manager to assign the SR to the best available service representative. Based on the severity of the SR, Workflow might then send email notification to the representative, using Siebel Communications Server. Automating this process helps ABC Computing achieve faster turnaround time to resolve SRs and meet the company’s SLA commitment. ABC Computing defines its business process for a new service request with the Process Designer. Figure 1 on page 21 illustrates a diagram of the process as drawn in the Process Designer. The diagram demonstrates the steps and decision points involved when a new service request comes into the organization. The steps and decision points are displayed in the diagram in such a way that the flow of the work is clear. NOTE: The steps explained below are not generic; they refer specifically to the workflow process illustrated in Figure 1 on page 21. Each step is interpreted as follows: ■ Start. This is the start step initiating the process instance. The work item is the new service request. ■ Assign Service Request. This is a subprocess action. The service request is assigned to the appropriate agent based on the assignment rules defined in the Assign Service Request subprocess. ■ Severity. This is a decision step. The service request severity determines the next step in the process instance of the three possible paths: Critical, High, or Medium. 20 Siebel Business Process Framework: Workflow Guide Version 8.0
    21. Overview of Siebel Workflow ■ General Principles of Workflow ■ Send Email. This is an automated business service action. If the service request priority is critical, an email is sent to the assigned agent. This action calls the Outbound Communications Manager business service. ■ Priority High. This is a Siebel Operation update action. This step updates the service request priority to High. ■ Substatus Assigned. This is a Siebel Operation update action. This step updates the sub status to Assigned. ■ Email Error Activity. This is a Siebel Operation insert action. This action is triggered if an error is returned in the Send Email action. ■ Priority Very High and Dispatch. This is a Siebel Operation update action. This step changes the service request priority to Very High and the substatus to Dispatch. ■ End. This step defines the completion of the process. Figure 1. New Service Request Workflow Process Understanding the Workflow Policies Module The Workflow Policies module allows you to define policies that can act as triggers to execute a workflow process. NOTE: The name Workflow Policies replaces the name Workflow Manager, which was used to refer to the Siebel Business Process automation tool in earlier releases. A policy consists of one or more policy conditions. When the policy conditions are met, the policy action is executed. NOTE: A number of the functions available with Workflow Policies can be supported using Workflow Processes. It is recommended that Workflow Policies be used to define conditions for invoking workflow processes. Use Workflow Processes for defining the actions. Siebel Business Process Framework: Workflow Guide Version 8.0 21
    22. Overview of Siebel Workflow ■ General Principles of Workflow Workflow Policies Structure The basic underlying construct of Workflow Policies is the rule. The structure of a rule is: if all conditions are true, then an action occurs. The rule contains a policy condition and a policy action. This means when the conditions of the workflow policy are met, an action is triggered. A workflow policy represents the rules the database monitors. A workflow policy, based on the Workflow Policies rule structure, is composed of conditions and actions. A workflow policy condition is a trigger—a circumstance or situation that causes something to happen. A workflow policy action is an action invoked by a policy condition being fulfilled. You can also have a duration, which is the period of time for which all policy conditions exist for the conditions of the policy to be met. Workflow Policy Conditions A policy condition expresses an object/attribute relationship to a value. For example, a policy condition may target data such as Service Request Severity. The policy condition compares that data to a value, such as 1-Critical. The combination of the data element (Service Request Severity), a comparison operation (=), and the value (1-Critical) make up the policy condition. The fact that a Service Request Severity is 1-Critical may be an issue only if the policy condition remains valid for some extended period of time, such as two hours. If this is the case, a duration can be set for two hours on the workflow policy. The duration becomes part of the policy condition. The policy actions are not executed until the policy conditions are met for the specified duration. Policy actions can also occur when time duration is not set. For example, email is automatically sent to a sales manager each time a sales representative quotes a discount rate exceeding 25 percent on revenue less than $100,000. Policies frequently have more than one condition. All the conditions of the policy must be met before an action can occur. A service request with a severity of 1-High and a duration of two hours may be important only if another comparison is also valid, such as the Service Request Status is Open. The policy condition becomes the combination of these two comparison operations: SR Severity = 1-Critical AND SR Status = Open Siebel Workflow Policies supports only AND linkages between policy conditions, not OR linkages. If you need to monitor the SR Severity to be 1-Critical or 2-High and the SR Status is Open, you can use the IN operand to evaluate the OR of the SR Severity Condition. SR Severity IN (’1-Critical’, ’2-High’) AND SR Status = Open Alternatively, OR linkages can be simulated by creating multiple policies for each key policy condition. The combination of workflow policies will act like an OR linkage. For more discussion on comparisons, see “Using Comparison Values in the Conditions Applet” on page 229. Workflow Policy Actions A workflow policy action contains two parts: the action and the action parameters. An action is a type of request, such as “Send an Urgent Page.” Action parameters are the arguments, such as the name of the recipient of the page and the alphanumeric text transmitted with the page. 22 Siebel Business Process Framework: Workflow Guide Version 8.0
    23. Overview of Siebel Workflow ■ General Principles of Workflow You can specify several actions for one workflow policy, such as sending a page to one person and an email to another. You can reuse actions in multiple workflow policies. See “About Customizing Workflow Policies with Siebel Tools” on page 235 for a discussion of actions and their parameters. NOTE: In most cases, use workflow policy actions to run a workflow process. Figure 2 illustrates the key parts of a workflow policy. Figure 2. Key Parts of a Workflow Policy Workflow Policy Action Program Types Workflow policy actions are based on underlying predefined programs in Siebel Tools and inherit all the arguments of the program. Workflow policy action programs can be one of the following types: ■ Send Message. A program of this type sends an email to one or more recipients. ■ Send Page. A program of this type sends a page to one or more recipients. ■ Send Message Broadcast. A program of this type inserts a message broadcast for one or more recipients. ■ DB Operation. A program of this type either inserts or updates the data records of a Siebel database table for selected workflow policy components. NOTE: Often, when some data changes, other data must be changed in accordance. This data dependency logic is typically implemented at the Object Manager layer through business component definitions and run-time events. DB operations by workflow policies provide an alternative that works at the database-record level. DB operations should be used only when the data dependency involved centers around database records rather than around business components. For example, use DB operations when one database record must always be updated if another database record is inserted, regardless of which business components the two database records belong to, or whether the two database records belong to any business components at all. Siebel Business Process Framework: Workflow Guide Version 8.0 23
    24. Overview of Siebel Workflow ■ General Principles of Workflow ■ External Program. A program of this type allows you to run an executable. ■ Assignment Request. For internal use only. ■ Generic Request Server. A program of this type submits a server request to a designated server component. NOTE: Most functionality included in workflow policy action programs can be executed using Workflow Processes. You can use programs in multiple action definitions and you can use action definitions in multiple workflow policies. “Predefined Programs” on page 295 contains a list of the predefined programs. Workflow Policy Groups Workflow policies are organized into groups. A workflow policy group is a collection of workflow policies to facilitate load balancing on the servers. Workflow policy groups allow you to manage and optimize Workflow Agent process performance by grouping similar policies to run under one Workflow Agent process. Architecture of Workflow Policies The key elements of the Workflow Policies module are workflow policy object creation in Siebel Tools, workflow policy creation in the run-time client, and policy execution by the Siebel Server Workflow Components. The Workflow Policies architecture is illustrated in Figure 3. Figure 3. Architecture of Workflow Policies 24 Siebel Business Process Framework: Workflow Guide Version 8.0
    25. Overview of Siebel Workflow ■ Workflow Roles Workflow Policies enforces policies at the data layer, through database triggers. When a particular policy’s conditions are met, underlying database triggers capture the database event into a Workflow Policy Manager queuing table (S_ESCL_REQ). A Workflow Policy Manager component (the Workflow Monitor Agent) polls this table and processes requests by taking the actions defined. In some cases, an action defined might be to invoke the Workflow Process Manager. Workflow Policy Manager provides scalability by using an additional component called Workflow Action Agent. Workflow Action Agent can be executed on a different application server within the Siebel Enterprise. Workflow Policies Administration Overview The Workflow Policies module is administered through Siebel Workflow in the run-time client. Instructions for accessing and using the Workflow Policies views are in “About Customizing Workflow Policies with Siebel Tools” on page 235. Workflow Roles The job roles associated with Siebel Workflow are the following: ■ The Business Analyst considers your organization’s business requirements and determines the processes to be automated using the Siebel application. ■ The Workflow Configurator uses Siebel Tools to develop workflow processes and to define objects, business services, and programs. Your organization can use the predefined objects, business services, or programs provided in the application; or, the Workflow Configurator can define customized objects, business services, and programs in Siebel Tools. NOTE: Business services can also be defined in the Siebel client. For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration. ■ The Workflow Administrator monitors workflow processes in the Siebel client using Siebel Workflow. The Workflow Administrator also activates workflow policies by generating database triggers in a script and creating them in the Siebel database. The Workflow Administrator then starts Siebel Server processes that execute workflow processes and policies. This person is typically a system administrator, database administrator, or someone from the Information Services department. ■ The End User uses the system and executes workflow processes and policies. This person is typically an employee of your organization, and can also be a customer. Siebel Business Process Framework: Workflow Guide Version 8.0 25
    26. Overview of Siebel Workflow ■ Workflow Roles 26 Siebel Business Process Framework: Workflow Guide Version 8.0
    27. 3 Introduction to Workflow Processes Siebel Workflow is an interactive software tool that lets you automate how your organization handles workflow processes. It uses as its basic model the same processes that organizations use in their sales, marketing, and service departments that determine business workflow. You can use Siebel Workflow to promote consistency and adherence to processes through the automatic enforcement of business policies and procedures. The Siebel Workflow product provides a graphical user interface featuring a familiar flowcharting methodology for designing workflow processes. This chapter is organized as follows: ■ “Overview of the Workflow Architecture” on page 27 ■ “Workflow Processes Development Lifecycle” on page 28 ■ “Design-Time Architecture of Workflow” on page 43 ■ “Simulation Architecture of Workflow” on page 45 ■ “Deployment Architecture of Workflow” on page 46 ■ “Run-Time Architecture of Workflow” on page 47 ■ “Workflow Interaction with Other Siebel Components” on page 52 Overview of the Workflow Architecture Siebel Workflow works with all Siebel Business Applications and involves the following architectural components: ■ Siebel Tools. Siebel Tools is an integrated environment for configuring all aspects of a Siebel application. The Workflow Process Designer resides in Siebel Tools. You use the Process Designer to build your workflow processes. ■ Siebel Client. Workflow Processes and Workflow Policies are administered through the Administration - Business Process views in the Siebel client (Mobile Web Client). ■ Siebel Server. Siebel Server manages the Siebel Workflow components that automate business policies. ■ Siebel Database. A relational database containing the set of data that Workflow Policies act against. For a complete description of the Siebel Server architecture, refer to Siebel System Administration Guide. Siebel Tools provides the design interface and the debugging interface of Siebel Workflow. After workflow processes are designed and debugged, they are written to repository tables for deployment from the administrative interface in the run-time client. Siebel Business Process Framework: Workflow Guide Version 8.0 27
    28. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle Workflow Processes Development Lifecycle Figure 4 depicts the development and deployment lifecycle for a workflow process. NOTE: While the lifecycle shown is a linear flow, the typical development cycle of a workflow process is iterative. Figure 4. Development and Deployment Lifecycle of Workflow Processes The development and deployment steps shown in Figure 4 are covered in greater detail in the following topics: ■ “Analyzing Process Requirements” on page 28 ■ “Defining Workflows” on page 31 ■ “Identifying and Building Exception Handling” on page 37 ■ “Testing and Troubleshooting Workflows” on page 39 ■ “Migrating Workflows to Production” on page 40 ■ “Monitoring Workflow Execution” on page 42 Analyzing Process Requirements The first part of a workflow’s development entails analysis of your business requirements and the rules and processes to be automated. 28 Siebel Business Process Framework: Workflow Guide Version 8.0
    29. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle An implementation project team typically spends a fair amount of time on requirements analysis. It is not unusual for this to be about 30% of the of the total implementation time. A Business Analyst defines the processes to be automated using the Siebel application. A developer (the Workflow Configurator) reviews these processes. When making design decisions on how to implement the processes, the Workflow Configurator looks for the following areas as candidates to be implemented using Siebel Workflow: ■ Repetitive, manual processing ■ Need for timely processing of an event ■ Escalations and notifications When making implementation decisions about automating processes, a Workflow configurator should consider the options summarized in Table 2. Table 2. Using Siebel Workflow for Automation Versus Using Other Siebel Mechanisms Framework Key Advantages Limitations Workflow Processes ■ Visual representation of The semantics for control are not as rich business logic is as with scripting. Specific limitations relatively simple to include: understand and ■ Limited control of flow for maintain. iteration through record sets ■ Remote synchronous ■ Limited direct access to object and asynchronous methods execution enable broad horizontal scalability and long-running transactions. Siebel Business Process Framework: Workflow Guide Version 8.0 29
    30. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle Table 2. Using Siebel Workflow for Automation Versus Using Other Siebel Mechanisms Framework Key Advantages Limitations Workflow Policies ■ Policies respond to ■ Changes to policies may require database events database downtime to implement. regardless of whether ■ Policies are more difficult to they are initiated by an configure that other alternatives. Object Manager component or by a non- ■ Policies allow a limited range of Object Manager executable actions. component. ■ Policies may get higher transaction throughput on a given set of hardware for simple transactions. Siebel Script ■ Script is familiar to most Widespread scripting degrades: developers. ■ Ease of maintenance ■ Script provides a ■ Ease of upgrade complete set of semantics. ■ Performance ■ Script is highly flexible. When Workflow Policies Offers a Better Automation Choice than Workflow Processes When deciding whether to implement a workflow policy versus a workflow process there are some additional things you may want to consider, such as: ■ whether the data and business logic involved are at the data layer or the business logic layer of the Siebel architecture ■ which features your automation will need to implement. Workflow Process Manager and run-time events capture business-layer logic. Workflow Policy Manager captures data-layer logic. Data coming into Siebel via the data layer—for example EIM or MQ channels—cannot be captured via the business layer. This typically presents a good candidate for a workflow policy. Some features not supported by workflow processes—such as email consolidation, duration, and quantity—are also candidates for workflow policies. Workflow processes, however, provide a better platform for development and deployment, complex comparison logic, and flow management (IF, THEN, ELSE, or CASE). Workflows can invoke business services. Workflows provide pause, stop, and error-handling capabilities. Workflow Policy Manager is the better alternative in scenarios such as a case when bulk data uploads happen using EIM, or during Data Quality cleaning in the data layer. 30 Siebel Business Process Framework: Workflow Guide Version 8.0
    31. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle For more information on Workflow Policies, see Chapter 10, “Workflow Policies”. For more detail on analyzing requirements for process automation, see Chapter 4, “Planning Workflow Processes.” Defining Workflows With Siebel Workflow, the run-time engine manages process flow, application flow, and integration flow. Basic constructs such as Start/Wait/End steps, Decision Points, Subprocesses, and Connectors are available to define your workflow processes. (For details on how to implement each of these constructs, see Chapter 6, “For Developers: Workflow Process Steps.”) The key elements of run-time execution are: ■ Events. Workflow processes can be invoked from events in the Siebel application or in external systems. Events can pass context from the caller—a user session, for example—to a workflow process using a row-id. ■ Rules. The flow control for a workflow process is determined by decision rules. Rules can be based on business component data or on local variables known as process properties. Rule expressions are defined using Siebel Query Language. ■ Actions. Workflow process actions can perform database record operations, they can invoke business services, and they can cause a pause in the workflow process. ■ Data. Data is created or updated as the workflow process executes. There are three main types of data a workflow process operates on: ■ Business component data ■ Process properties ■ Siebel Common Object data. Think of process properties as local variables that are active during the workflow process. The variables are used as inputs and outputs to the various steps in a process. With every workflow process, there is a set of predefined process properties that are automatically generated when you define the workflow. One example of these predefined process properties is the Process Instance Id. For more information on process properties, see “About Process Properties” on page 93. Siebel Business Process Framework: Workflow Guide Version 8.0 31
    32. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle Some of the basic constructs of Siebel Workflow are shown in Figure 5. Figure 5. Basic Constructs of Siebel Workflow Events Using events is one of three main ways to invoke a workflow process. The other two invocation mechanisms are Workflow Policies and Tools object events (script). For more information on workflow invocation mechanisms, see “Invocation Mechanisms” on page 49. 32 Siebel Business Process Framework: Workflow Guide Version 8.0
    33. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle Rules There are several ways to implement decision rules in a workflow process. Table 3 describes the main ways and discusses their usefulness and limitations. Table 3. Ways to Implement Rules in Workflow Processes for Enforcing Business Logic Type Description When Useful Limitations Workflow A step in a workflow that When you need a Conditional Decision Point arbitrates between one or simple articulation of expressions lack more alternative branches in whether one or more support for some key the flow. alternative actions in operators including: flow should be taken. Each branch out of a ■ AND decision step has one or ■ OR more conditions. If all evaluate to TRUE for the ■ Order of branch, the flow continues precedence down that branch. control (that is, parentheses) Scripted Script within a business When Workflow Undermines the Business Service service action step that decision point readability and evaluates a potentially semantics are not simplicity of the complex set of inputs and sufficiently expressive workflow by hiding returns a simplified output to encapsulate logic within a business that can be evaluated by a decision criteria. service. workflow decision point. Other Other rule frameworks that When it is deemed Limitations vary Specialized Rule may be used directly or appropriate to use a depending on the rule Frameworks indirectly by a workflow, specialized rule framework used. such as personalization framework, such as rules, assignment rules, EAI when you need to Dispatch Service, or the assign work to people Siebel rules engine that is based on their new in this release. workload. The Siebel rules engine allows you to maintain business process logic declaratively and in a location external to your Siebel applications. For information on implementing rules in Siebel Workflow, see Siebel Business Rules Administration Guide. Siebel Business Process Framework: Workflow Guide Version 8.0 33
    34. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle Decision Points Decision points exit with multiple branches. For each branch, a conditional statement is evaluated. A conditional statement compares any two of the following: ■ process properties ■ business component fields ■ literal values The terms of comparison include: ■ two values are equivalent ■ one value exists among a series of others (for example, child record values, One Must Match, or All Must Match ■ Greater Than (>) or Less Than (<) ■ Between or Not Between ■ Null or Not Null For an example of a Compose Condition Criteria dialog box showing decision criteria, see Figure 23 on page 105. For descriptions of the fields in the Compose Condition Criteria dialog box, see Table 11 on page 106. 34 Siebel Business Process Framework: Workflow Guide Version 8.0
    35. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle Actions There are several ways to effect actions in a workflow. With a workflow process action, data is taken as an input, then a transformation takes place, and data is produced as output. Table 4 shows the main ways to cause various transformations, and describes their usefulness and limitations. Table 4. Actions in Siebel Workflow Action Type Description When Useful Limitations Business Service A workflow step that invokes When you need Creating and destroying Step a method of a business to execute a business services can be service. potentially expensive. Overhead can be complex, but reduced through caching. The business service may be reusable set of a prebuilt Siebel service or a Incorporating too much logic logic. scripted business service. within a business service may limit its reusability and the transparency of the workflow. Database A workflow step that When you need While it is possible to update Operation performs inserts, updates, to execute multiple records based on a (Siebel and queries against Siebel simple record search specification, it is not Operation Step) business components. operations within possible to retrieve and the workflow. iterate through a set of records such that subsequent workflow actions can execute for each record. Wait Step A workflow step that puts When you need The releasing event must be the workflow into a holding to support time- triggered through the Object pattern until a releasing based Manager. event is fired or a timeout escalations or occurs. long-running flows that may last for days or weeks (for example, waiting for a customer response) Business Service Step Business Service steps execute predefined or custom methods. Typical predefined business services used include Assignment Manager requests, notification through the Communications Server, server requests, and integration requests (from Siebel EAI). Custom business services can be written in Siebel VB or eScript. When defining a Business Service step, you must specify the business service, the business service method, input arguments (pass in a process property, business component data, or a literal value) and output arguments. Some commonly used business services for workflow processes include: Siebel Business Process Framework: Workflow Guide Version 8.0 35
    36. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle ■ FINS Data Transfer Utilities ■ FINS Validator ■ FINS Dynamic UI ■ Outbound Communications Manager ■ Report Business Service ■ Synchronous Assignment Manager Requests ■ Server Requests ■ Business Rule Service ■ Audit Trail Engine ■ EAI business services (such as EAI Siebel Adapter, EAI XML Converter, and so on) For more information on these business services, see “Predefined Business Services” on page 328. Siebel Operation Step Siebel Operation steps allow you to perform database operations of Insert, Update, Query, Delete, NextRecord, PreviousRecord, and QueryBiDirectional. These steps are performed on business components. Once you have defined the Siebel Operation step, you can use the Search Specification child object to locate the records you want to work on. Examples of Siebel Operations steps include creating an Activity record when a new SR is opened, or updating a comment field if an SR has been open too long. Wait Step Wait steps allow you to suspend workflow process execution for a specified period of time or until a specific event occurs. Figure 6 shows the definition of a timeout based on time defined as literal values in input arguments. Figure 6. Example Wait Step Definition About Developing Workflow Processes in Siebel Tools You develop workflow processes in Siebel Tools, on a local database. Siebel Workflow is a repository object. A workflow belongs to a project. 36 Siebel Business Process Framework: Workflow Guide Version 8.0
    37. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle Though compiling a Siebel Repository File is a standard practice for other repository objects, Siebel Workflow has its own deployment mechanism. You do not compile a SRF after you have developed workflow processes. For more information on Workflow deployment, see “About Deploying Workflow Processes” on page 181. Siebel Workflow does not participate in the behaviors that follow, though these behaviors are standard for other repository objects. ■ Merge. Siebel Workflow does not participate in three-way merge. When workflow definitions are imported into the repository, they maintain versioning provided by Siebel Workflow. ■ Object Comparison. This is disabled in this release. ■ Archive. Workflows do not participate in .sif archive. Instead, workflows can be archived as XML files using the Workflow export utility. Typically, developers use a local database to develop workflows. When using a local database, you must check out workflow definitions from the master repository. When developing workflows on a local database, the local database must have all the referenced data objects. For those data objects that are not docked and hence not packaged as part of the database extract, developers must import them into the local database. The following objects are not docked and are referenced by Workflow: ■ Data maps. To import data maps to the local database, you use the dedicated client connected to the local database, and the client-side import utility. ■ Message tables. You can copy message tables over to the local database. Alternatively, you can define messages using the unbounded picklist. While this allows for the creation of messages, it does not check the validity of the message at definition time. If you choose, you can also develop or modify workflows using Siebel Tools connected to the development database, by locking the project in the master repository. This way, you do not need to make sure that all the lists of values are made available to the local database. Identifying and Building Exception Handling An exception represents a deviation from the normal processing flow: an error. An exception can be a system error or a user-defined error. You can use exception handling to notify the user of an error and terminate the workflow process instance. There are three ways of handling exceptions: ■ Using a Stop step ■ Using Exception branches ■ Using a universal exception handler Using a Stop Step Use a Stop step to show a particular error message while processing. Examples for use include real- time processing for credit card authorization or for order validation. This type of exception handler provides customizable error messages including expressions. For more information on Stop steps, see “About Stop Steps” on page 137. Siebel Business Process Framework: Workflow Guide Version 8.0 37
    38. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle Using Exception Branches You can programmatically handle errors and change the flow depending on when errors are encountered. You do this using Exception branches. This provides a granular approach to handling exceptions at each step. In the example shown in Figure 7, when the Get Organization ID step is unable to get data, the workflow is programmed to continue to the Lookup Sender by Org step and if this fails, to take the red Exception branch and send an email (the Send Lookup Error Email step). Figure 7. Example of a Workflow That Uses Exception Branches to Programmatically Handle Exceptions For more information on handling exceptions with Exception branches, see “Using Exceptions to Handle Errors” on page 163. Using a Universal Exception Handler You can define a universal exception handler at the workflow level by setting Error Process Name on the workflow to be used as the error process.This error process workflow is then invoked for any exception that happens on the workflow attached to it. Use a universal exception handler when you need a uniform exception handler across multiple steps in a workflow or across multiple workflows. This type of exception handling also helps to reduce clutter on the workflow diagram itself. For more information on using error processes as uniform exception handlers, see “Using Error Processes to Handle Errors” on page 161. 38 Siebel Business Process Framework: Workflow Guide Version 8.0
    39. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle Testing and Troubleshooting Workflows There are two ways of testing and troubleshooting a workflow: simulating the workflow, and using event logs. Simulating Workflows Two simulators allow you to simulate workflows: Process Simulator. Most workflows can be tested and debugged using the Process Simulator, which is hosted in Siebel Tools. To use the simulator, you need to have the Siebel mobile client installed. The mobile client can connect to any database (that is, either development or local) that has the test data required to debug a workflow. In this release, you can test interactive workflows and runtime-event-based workflows using the Process Simulator. Long-running workflows and those workflows that invoke server components cannot be debugged using the Process Simulator. During the debugging, the process variables are displayed by the dynamic watch window. Business Service Simulator. Workflow can be run as a business service from the Business Service Simulator in the Siebel client. The workflows must be published and activated before testing them with the Business Service simulator. To use the simulator, the following conditions must first be met: ■ Siebel Mobile Client installed ■ Workflows exported from Siebel Tools ■ Workflows imported by way of the client NOTE: Alternatively, you can publish and activate to the Mobile Web Client directly from Siebel Tools. Use the Business Service simulator when you need to debug script in conjunction with a workflow. Set breakpoints in the script and execute the workflow in the mobile client. When the workflow executes a service for which a breakpoint is set, control is returned to the Script Debugger in Siebel Tools. Using Event Logs For more detailed information on the execution of a workflow, set event logs so that you can view the log files. NOTE: This method is useful if you cannot perform real-time debugging or do not have the Process Simulator readily available. However, use of this method may result in large log files that must be analyzed. For information on using the Log File Analyzer, see Siebel System Monitoring and Diagnostics Guide. Events used for logging are as follows: ■ Workflow Engine Invoked (EngInv). Traces methods invoked and arguments passed to the Workflow engine. ■ Workflow Definition Loading (DfnLoad). Traces process and step definitions loaded into memory. Siebel Business Process Framework: Workflow Guide Version 8.0 39
    40. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle ■ Workflow Process Execution (PrcExec). Traces process instance creation and completion. Traces the process property get/set. ■ Workflow Step Execution (StpExec). Traces step creation and completion, branch condition evaluation, business service invocation, and business component insert/update. ■ Workflow Performance (WfPerf). Traces process and step execution time, as well as overall process execution time. ■ Workflow Recovery (WfRecv). Traces instance recovery status and progress, as well as instance recovery details. (Applicable only to the Workflow Recovery Manager server component). For information on how to set event log levels, see “Setting Tracing and Event Log Levels” on page 196. Migrating Workflows to Production Once you have tested your workflows, they are ready to be migrated. Workflow definitions can be migrated across environments—for example, from development to production—using one of three migration utilities: ■ Application Deployment Manager (ADM). ADM automates the process of migrating enterprise customization data (views, responsibilities, assignment rules, workflow processes, workflow policies, and so on) from one Siebel application environment to another, including from a development environment to a testing environment. ■ Repository Import/Export Utility (REPIMPEXP). This utility allows export/import of all repository objects. This utility is best used to migrate all repository objects including your workflows when your organization is ready to roll out the release (that is, migrate all repository objects). ■ Workflow Import/Export Utility (Import/Export). This utility allows incremental migration of workflow definitions. Using Siebel Tools, you export the workflow from one environment and import the workflow to another environment. Import of workflows can be done in one of the following ways: 40 Siebel Business Process Framework: Workflow Guide Version 8.0
    41. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle ■ Using Siebel Tools for importing workflows. Using Siebel Tools, you import the definitions into the repository of the target environment, then you mark the workflows for deployment by clicking the Publish button. After this, the definitions are ready to be activated. This approach makes sure that the versions of the workflow definitions that exist in the repository tables and the run-time tables are the same. Figure 8 shows an incremental deployment using the Import/Export utility and Siebel Tools. Figure 8. Incremental Deployment Using Import/Export ■ Using the Siebel client for importing workflows. You can import the workflow definitions directly into the run-time tables. From your point of view, this approach bypasses the steps of writing the definitions into the repository tables of the target environment and activation from the Siebel client (although these steps are still performed behind the scenes by the Workflow engine). This approach causes the latest version of the workflow definition in the run-time tables (used by the Workflow engine) to be different from the version that resides in the repository tables. NOTE: This approach is a good one for testing a workflow in a different environment, but as a best practice, it should not be used for general migration of workflows across environments. Figure 9 shows an incremental deployment using Import/Export to export from Siebel Tools and import from the Siebel client. Figure 9. Incremental Deployment Using Import/Export to Export from Siebel Tools and Import from the Siebel Client Siebel Business Process Framework: Workflow Guide Version 8.0 41
    42. Introduction to Workflow Processes ■ Workflow Processes Development Lifecycle For more information on migration utilities, see “Migrating Workflow Processes from Development to Production” on page 185. Deploying Workflows in Production After migrating your workflows to a production environment, you may need to deploy them (publish them) before you can run them. Whether or not you must deploy them depends on which migration tools you used. Deployment of workflows happens as follows: ■ ADM automatically deploys all migrated workflows. If you have used ADM to migrate your workflows to production, you do not manually deploy them. ■ If you have used REPIMPEXP or Import/Export to migrate your workflows to production, you must manually deploy the workflows. Manual Deployment of Workflows You can publish workflows—that is, deploy them—manually from within Siebel Tools, or from within the run-time client. To deploy workflows manually in Siebel Tools, you use the Publish button or the Publish/Activate button found in the WF/Task Editor toolbar. Using the Publish/Activate button, you can both deploy and activate a workflow process with one click. If you choose to publish a workflow but not activate it, you can still use the run-time client to activate the workflow with the Activate button in the Workflow Deployment view. NOTE: In this release, deployment of workflows takes place using buttons in Siebel Tools called “Publish” and “Publish/Activate.” In earlier releases, the terminology on this button action was called “Deploy.” In earlier releases, activation could only take place in the run-time client. In this release, you can activate a workflow in Siebel Tools, given you have set the VerCheckTime parameter in the Workflow section of the .cfg file to -1 ([Workflow] VerCheckTime = -1). When you click either the Publish button or the Publish/Activate button, the workflow process is validated before it is deployed (published). If there are any validation errors for the workflow, a dialog box appears, giving you the opportunity to correct any errors before deployment (publishing). This dialog box is modeless, meaning that you may keep it open to see the error messages while working on the workflow using the Process Designer to correct the problems reported. However, you can proceed with the deployment despite problems (validation errors) if you choose to do so. If there are no validation errors, you do not see this dialog box, nor do you see a message stating that the validation was successful. The validation is carried out without user visibility, unless errors are detected. Monitoring Workflow Execution You monitor and control workflow process execution in the Administration - Business Process views of the run-time client. You can monitor and troubleshoot Siebel Workflow in the production environment considering progress and status information, operation details, performance- measurement data, and failure-analysis records. 42 Siebel Business Process Framework: Workflow Guide Version 8.0
    43. Introduction to Workflow Processes ■ Design-Time Architecture of Workflow For more information, see “Monitoring and Troubleshooting Workflow Processes in Production” on page 193. Design-Time Architecture of Workflow Workflow components and definitions are defined as Siebel Tools objects and are stored in the Siebel Tools repository. Before you can run a workflow process as a server task or from the Siebel Web Client, you must first publish the workflow process from Siebel Tools, then activate the workflow process from the Siebel Web Client. NOTE: If you use the Publish/Activate button (rather than the Publish button) to publish the workflow process in Siebel Tools, there is no need to separately activate the workflow in the run-time application. The Workflow Process repository object is a top-level object in the Object Explorer of Siebel Tools. You use the Object List Editor (OBLE) to create Workflow processes. Workflow processes belong to a project. There is no SRF compile required for deployment of workflow processes. There is no merge required. There is independent versioning of workflow processes in Siebel Tools and in the run-time client. Configuration data is available at design time, but run-time data is not available at design time. You use process properties to create workflow definitions, or alternatively, you can enter data through unbounded picklists. The following Siebel Tools features are not applicable to Workflow objects: ■ SIF export and import ■ Object Compare ■ Three-way merge during upgrades Because Siebel Tools excludes Workflow objects from these features, it is important to use the Workflow import and export feature for backing up and restoring workflow definitions. For example, if you archive a project in Siebel Tools, the Workflow objects within that project are not archived. CAUTION: If you delete all the objects from a project expecting that they can be restored from the SIF, it is important to keep in mind that Workflow objects are an exception, and cannot be restored from the SIF. Use the Workflow import and export feature to back up and restore workflow definitions. Siebel Business Process Framework: Workflow Guide Version 8.0 43
    44. Introduction to Workflow Processes ■ Design-Time Architecture of Workflow Use the Process Designer in Siebel Tools to develop workflow processes. Workflow processes are stored in the Siebel system in the repository and runtime tables. When you edit the processes in Siebel Tools, they are stored in the repository tables. When you publish and activate the processes, they are also inserted into the runtime tables. Figure 10 shows the design-time architecture of Workflow. Figure 10. Design-time Architecture of Siebel Workflow Figure 10 shows the following points: ■ Workflow processes in development are stored in the Siebel repository as repository tables and runtime tables ■ There are two methods of exporting workflow processes from the Process Designer in Siebel Tools as files: ■ As a workflow process file (.xml) ■ As a Siebel archived file (.sif) NOTE: Although not shown in Figure 10, you can also use ADM to migrate workflow processes from one Siebel environment to another. For more information about ADM, see Siebel Application Deployment Manager Guide. 44 Siebel Business Process Framework: Workflow Guide Version 8.0
    45. Introduction to Workflow Processes ■ Simulation Architecture of Workflow Simulation Architecture of Workflow After designing your workflow processes, you test them using the Process Simulator. Testing your workflow processes before migrating them to your production environment verifies that resulting actions are accurate and useful and the results are exactly what you want. Figure 11 shows the simulation architecture of Workflow. Figure 11. Simulation Architecture of Siebel Workflow Siebel Business Process Framework: Workflow Guide Version 8.0 45
    46. Introduction to Workflow Processes ■ Deployment Architecture of Workflow Deployment Architecture of Workflow After designing your workflow processes and testing them, it is time for deployment. Figure 12 shows the relationship of Siebel Tools and the run-time client in the deploying of workflow processes. Figure 12. Deployment of Workflow Processes Figure 12 illustrates that workflow definitions are read from the repository, then when a workflow is activated, its definitions are written to run-time tables. 46 Siebel Business Process Framework: Workflow Guide Version 8.0
    47. Introduction to Workflow Processes ■ Run-Time Architecture of Workflow Run-Time Architecture of Workflow The Workflow run-time architecture is based on the Siebel Object Manager layer and the server infrastructure layer of the Siebel Business applications architecture. The run-time environment is available both as a business service and as a server component. The run-time architecture supports three invocation modes for invoking and resuming workflow processes: Local Synchronous, Remote Synchronous, and Remote Asynchronous. Figure 13 shows the run-time architecture of Workflow. Figure 13. Run-time Architecture of Workflow Workflow Process Types Siebel Workflow has four types of workflow processes that characterize run-time behavior. The processing type is set in the Workflow Processes list editor of Siebel Tools, using the Workflow Mode field. The workflow process types are as follows: ■ 7.0 Flow. A 7.0 workflow process provides backward compatibility for existing Siebel 7 (pre-7.7) workflows. For more information, see “About 7.0 Workflow Processes” on page 143. ■ Long Running Flow. A long-running workflow process is a persistent workflow that can last for hours, days, or months. For more information, see “About Long-Running Workflow Processes” on page 143. ■ Interactive Flow. An interactive workflow process navigates the user across Siebel views. For more information, see “About Interactive Workflow Processes” on page 144. ■ Service Flow. A service workflow process executes a set of operations upon event invocation. For more information, see “About Service Workflow Processes” on page 144. Siebel Business Process Framework: Workflow Guide Version 8.0 47
    48. Introduction to Workflow Processes ■ Run-Time Architecture of Workflow Workflow Process Manager Workflow processes can be executed in any application object manager as a business service. Workflow processes can also be executed in the Workflow Process Manager server component. Running Workflow as a Business Service Workflow execution in an application object manager is invoked as a business service. The Workflow business services are called Workflow Process Manager. The Workflow Process Manager business services are also referred to as the Workflow engine. As a business service, the Workflow engine takes input arguments and returns output arguments. The two Workflow business services are: ■ Workflow Process Manager ■ Workflow Process Manager (Server Request) When the Workflow Process Manager business service is called, the workflow process is run in the object manager of the application called. When the Workflow Process Manager (Server Request) business service is called, the workflow process is run in the server component called Workflow Process Manager. Running Workflow in the Workflow Process Manager Server Component Workflow processes can be executed in the background using the Workflow Process Manager server component. The Workflow Process Manager server component 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 workflow processes, including all application logic within the workflow process. Workflow Management Server Components The Workflow Management server component group includes the following server components (with alias names in parentheses): ■ Workflow Process Manager (WfProcMgr) ■ Workflow Process Batch Manager (WfProcBatchMgr) ■ Workflow Monitor Agent (WorkMon) ■ Workflow Action Agent (WorkActn) ■ Workflow Recovery Manager (WfRecvMgr) ■ Generate Triggers (GenTrig) Workflow Process Manager and Workflow Process Batch Manager The Workflow Process Manager server components (WfProcMgr and WfProcBatchMgr) act as the application object manager to run workflows. The Workflow Process Manager server components are specialized server components configured and tuned to run workflow processes. Like all server components, the Workflow Process Manager server components provide a multi-threaded environment. 48 Siebel Business Process Framework: Workflow Guide Version 8.0
    49. Introduction to Workflow Processes ■ Run-Time Architecture of Workflow The Workflow Process Manager uses the Siebel Object Manager framework and runs workflows as a business service. The Workflow Process Manager hosts the Business Object layer and the Data Object layer. It is a scalable architecture with the ability to run multiple object managers and multiple tasks for each object manager. NOTE: The name Workflow Process Manager refers to both the Workflow business service (referred to as the Workflow engine) and the workflow server components. The Workflow Process Batch Manager (WfProcBatchMgr) is intended to run as a batch component. You must use a search specification to locate the business component records to work on. The Workflow Process Manager is active and can receive and process requests when it is in “Online” status. The Workflow Process Manager is inactive in all other statuses, such as “Shutdown” and “Offline.” In such cases, requests to WfProcMgr (and WfProcBatchMgr) cannot be processed. If the requests have been saved to the database, for example, if the requests are submitted in “DirectDB” mode, the requests can be re-submitted later when WfProcMgr comes back online. Otherwise, the requests are lost. Workflow Monitor Agent The Workflow Monitor Agent executes Workflow policies. Workflow Monitor Agent monitors policies, and executes actions once the policy conditions are met. Workflow Action Agent The Workflow Action Agent processes requests logged in the action request table (S_ESCL_ACTN_REQ) for a policy group and invokes all actions linked with the Workflow policy being processed. Workflow Recovery Manager The Workflow Recovery Manager polls the Workflow engine to check workflow instances running on the server. The Workflow Recovery Manager recovers crashed instances and resumes instances that have been waiting beyond a due date. Generate Triggers Generate Triggers allows you to create database triggers. The Workflow Policies module of Siebel Business Process Designer uses these database triggers to identify which records may match policy conditions. The Generate Triggers server component needs to be rerun whenever new policies are created or deleted, and when existing policies are updated. You can run the Generate Triggers server component from either the Server Manager graphical user interface, or command line mode. Invocation Mechanisms Siebel Workflow can be invoked in three ways: Siebel Business Process Framework: Workflow Guide Version 8.0 49
    50. Introduction to Workflow Processes ■ Run-Time Architecture of Workflow ■ Workflow Policies. Workflow Policies trigger workflow processes after a database change. The basic construct of a policy is a rule. If all the conditions of a rule are true, then an action occurs. In some cases, the action is to invoke Workflow Process Manager server component to execute a workflow process. NOTE: Processing invoked by Workflow Policies is not real time. Typical uses of a workflow policy are for EIM batch processing, for Siebel EAI inserts and updates, for manual changes from the user interface, for Assignment Manager assignments, and for Siebel Remote synchronization. ■ Events. Events belong to three objects: Application, Applet, and Business Component. Events can be configured from the administrative interface. There are two types of events used by Siebel Workflow: ■ Run-time events (Personalization events). Run-time events are based in the Object Manager and they occur when a change is encountered by the user interface or the business component layer. Processing invoked by run-time events is real time. ■ User events. User events are unique Workflow-internal events that trigger or resume a long- running workflow process. User events are generated by the User Event business service. ■ Script. Scripts (Siebel Tools object events) can call Siebel Workflow programmatically as a business service. Using script, you can invoke Workflow from an external system. The Workflow Process Manager server component provides APIs for such programmatic invocation. Scripts are raised by the Object Manager. Scripts belong to four objects: Application, Applet, Business Component, and Business Service. The main uses and limitations of each of the possible workflow invocation mechanisms is summarized in Table 5. Table 5. Advantages and Limitations of Workflow Invocation Mechanisms Type Most Useful When Limitations Workflow Policies You need to detect and react to data ■ Making changes requires database changes made outside of the Object downtime Manager—for example, by Siebel ■ Relatively complex to configure Remote or by Siebel EIM. 50 Siebel Business Process Framework: Workflow Guide Version 8.0
    51. Introduction to Workflow Processes ■ Run-Time Architecture of Workflow Table 5. Advantages and Limitations of Workflow Invocation Mechanisms Type Most Useful When Limitations Events ■ You need to implement a basic ■ Cannot directly respond to an entry point for a workflow or a event by scripting against the simple custom action event object ■ You need to avoid distributing ■ Can be more difficult to pass the .SRFs—for example, because of event context to business logic the burden created for mobile ■ This invocation mechanism does users not trap data changes made by non-Object Manager components Script (Siebel ■ You need flexibility to write script ■ Changes must be distributed Tools Object directly in response to an event through a new .SRF. Events) ■ You need access to an applet event ■ This invocation mechanism does that is only exposed in Siebel Tools not trap data changes made by non-Object Manager components For more information on invoking Siebel Workflow, see “Invoking Workflow Processes” on page 165. Administration and Monitoring Administration and monitoring of your workflow processes happens in the Administration - Business Process views in the run-time client. You use the Administration - Business Process views to stop workflow processes, to delete process instances and to purge process instances from the database, to monitor workflow processes that are running, and to recover workflow processes that have been interrupted. For more information, see “Administering Workflow Processes in the Run-Time Client” on page 188. Recovery If the Workflow Process Manager server component fails, Siebel Workflow automatically resumes the interrupted workflow instances when the server restarts. Recovery is performed by the Recovery Manager based on the process instance’s state information that is saved by the Workflow engine. To manually recover process instances, you use the Workflow Instance Admin view. From the application-level menu in the run-time client, choose Administration - Business Process > Workflow Instance Admin. See “Workflow Instance Admin View” on page 194. For more information, see “Recovering Workflow Processes” on page 164. Siebel Business Process Framework: Workflow Guide Version 8.0 51
    52. Introduction to Workflow Processes ■ Workflow Interaction with Other Siebel Components Workflow Interaction with Other Siebel Components In automating your organization’s business processes, Siebel Workflow interacts with various components of the Siebel Business architecture. Siebel Server Components The Workflow engine interacts with other server components through the Server Request Broker. Working as a business service, the Workflow engine calls server components. To invoke server components that are exposed as specialized services, the Workflow engine calls them by their respective signature. For example, to send emails, the Workflow engine calls the Communications Server as the Outbound Communications Manager business service. To assign objects to users, it calls the Assignment Manager component as the Synchronous/Asynchronous Assignment Request business service. To invoke server components that are not exposed as specialized services, the Workflow engine uses the predefined business service called Server Request. The Server Request business service sends a generic request to the Server Request Broker. For more information on the Server Request business service, see “Predefined Business Services” on page 328. Server Request Broker The Server Request Broker (SRBroker) acts as a request broker for the Siebel application server. The Workflow engine sends requests to SRBroker, synchronously or asynchronously, and SRBroker brokers the request to the appropriate component. The messaging involves: ■ Sending asynchronous messages from an interactive-mode server component to the Workflow engine. ■ Communication (synchronous and asynchronous) between the Workflow engine and batch components. ■ Scheduling repeated tasks that are to be executed periodically in the Workflow engine. Another job performed by SRBroker is load balancing. When SRBroker receives a request, it routes it to the server component in the current server. For Siebel Workflow, if the component is not available in the current server, SRBroker then sends it to other servers where the Workflow Process Manager component is enabled on a round-robin basis. Siebel Workflow also uses SRBroker to resume waiting processes. SRBroker pools a database table on a regular basis to see all server tasks that needs to be resumed. For more information on SRBroker, see Siebel System Administration Guide. 52 Siebel Business Process Framework: Workflow Guide Version 8.0
    53. Introduction to Workflow Processes ■ Workflow Interaction with Other Siebel Components Personalization Engine The Personalization engine handles run-time events (application events, applet events, and business component events). It is through integration with the Personalization engine that Siebel Workflow processes run-time events. A workflow process triggered or resumed by run-time events registers itself with the Personalization engine at the time of the process’s activation. When a run-time event occurs in a user session, the Personalization engine calls Workflow in the local object manager. Inbox Inbox is a single screen in Siebel Business Applications that shows all approval/notification items and tasks assigned end users regardless of the screen where the item originated. Inbox shows enough detailed information about the item so that the end users can act on the item from the Inbox and not have to navigate to other screens for more information. See Siebel Applications Administration Guide for more information on Inbox. Tasks Siebel Task UI allows you to create wizard-like user interfaces with multiple-step, interactive operations that can include branching and decision logic to guide end users through task execution. Task UI allows navigation both backward and forward within task execution, and allows task execution to be paused and resumed as needed. You can integrate tasks in workflow processes by including Task steps. For more information about Siebel Task UI, see Siebel Business Process Framework: Task UI Guide. Siebel Business Process Framework: Workflow Guide Version 8.0 53
    54. Introduction to Workflow Processes ■ Workflow Interaction with Other Siebel Components 54 Siebel Business Process Framework: Workflow Guide Version 8.0
    55. 4 Planning Workflow Processes This chapter describes the steps involved in planning workflow processes. To plan your workflow processes, perform the following activities: ■ “Gathering Information for Workflow Process Planning” on page 55 ■ “Understanding Workflow Process Requirements” on page 56 ■ “Considering Business Objects and Business Services When Planning Workflow Processes” on page 57 ■ “Defining a Test and Migration Strategy for Workflow Processes” on page 58 ■ “Verifying Workflow Policies Installation” on page 59 For information about upgrading Siebel Workflow, see “Upgrading Siebel Workflow” on page 60 and Siebel Database Upgrade Guide. Gathering Information for Workflow Process Planning Start gathering information by looking at how your organization currently handles workflow issues, business processes, and overall workflow. These current processes are the basis of what you will create using Siebel Workflow. If you currently have an automated system, you need to gather information on the processes handled by that system. It is also important to understand the limitations or problems that the current system has that you want to address with Siebel Workflow Processes. There are two primary areas you may want to research for information on your current workflow processes: existing process information and areas for improvement or new process requirements. Researching Existing Process Information Existing process information can come from a variety of sources: ■ Current automated processes ■ Management guidelines ■ Written guidelines of process rules or approval paths ■ Internal procedures, written or unwritten An example of gathering information about an existing process would be to document each step that a new work item, such as a service request, takes from the moment it is initiated to the moment it is complete. Include information about decision points in the process, such as when a service request should be escalated or which approval path an order takes when it is high priority versus low priority. Siebel Business Process Framework: Workflow Guide Version 8.0 55
    56. Planning Workflow Processes ■ Understanding Workflow Process Requirements Researching New Processes and Areas for Improvement After you have gathered as much information as you can about existing processes, review the information you have to see if there are areas for improvement in the process or whether a new process might be useful. Think of the following possibilities: ■ New management guidelines or business requirements ■ Current problems that need to be solved ■ Areas that you would like to make more visible ■ Customer satisfaction issues ■ Workflow processes that you would like to automate Understanding Workflow Process Requirements A workflow process operates on business objects and business components. Usually, each workflow process is associated with a business object. A workflow process consists of various actions. There are many predefined actions that can be used when you define a process. Some examples of the predefined actions are: ■ Notifications. Sending an email, page, or fax. ■ Siebel Operations. Inserting or updating information in the Siebel database. ■ Integration Messages. Requesting to send or receive data from an external system. ■ Assignment. Requesting Assignment Manager to assign an object. ■ Navigation. Navigating a user to a specific view (by way of a User Interact Step or a Task UI call). ■ Server Request. Requesting the Siebel Server Request Broker to run a server process. Except for Siebel Operations, all of the above actions are invoked by calling a method on a business service. Siebel has predefined these business services so they can be used in workflow processes. You may determine a specialized action that you are interested in calling in your workflow, such as “calculate credit risk.” Specialized actions can be added by defining a custom business service. Workflow Processes can call both predefined and custom business services. For more information on defining custom business services, see Integration Platform Technologies: Siebel Enterprise Application Integration. 56 Siebel Business Process Framework: Workflow Guide Version 8.0
    57. Planning Workflow Processes ■ Considering Business Objects and Business Services When Planning Workflow Processes Seeded Workflow Processes Many applications include seeded workflow processes for product functionality. By default, these seeded workflow processes are in a Completed state with a version number of 0. If you want to customize these seeded workflow processes, you need to revise them in Siebel Tools. After revising a seeded workflow, its version changes from 0 to 1. You then modify this version to suit your business needs, publish it, and activate it. Activating a workflow process creates the appropriate run-time events defined within the process. For information on activating workflow processes, see “Administering Workflow Processes in the Run- Time Client” on page 188. Considering Business Objects and Business Services When Planning Workflow Processes When planning a workflow process, please be aware of the following issues: ■ If your workflow process is associated with a business object, the business object should have a primary component defined in Siebel Tools. For more information, see “Defining a Primary Business Component for a Business Object.” ■ If your business requirements require specialized functions, you may want to create a custom business service for the specific activity. Business services can be defined in Siebel Tools or in the Siebel client administration screens. See Integration Platform Technologies: Siebel Enterprise Application Integration for information about defining a business service with Siebel Tools. ■ If your workflow process involves a Siebel-defined business service or a custom business service, you must enable the business service in order to use it. See “Enabling a Business Service for Workflow Processes” on page 58. Defining a Primary Business Component for a Business Object For a business object to be used with a workflow process, it must have a defined primary business component. To designate a primary component for a business object 1 In Siebel Tools, navigate in the Object Explorer to the appropriate business object. 2 Select the business object. 3 In the Properties window, use the picklist in the Primary Business Component field to select the appropriate component name. Select a primary component by selecting the key component for the specific business object. Siebel Business Process Framework: Workflow Guide Version 8.0 57
    58. Planning Workflow Processes ■ Defining a Test and Migration Strategy for Workflow Processes 4 Compile the SRF. Once a primary business component has been defined, the business object appears in the Workflow Processes list editor. Enabling a Business Service for Workflow Processes Siebel provides a number of predefined business services. (See “Predefined Business Services” on page 328 for a list of these services.) You can also define your own custom business services using Siebel Tools or the Administration - Business Service view in the Siebel client. To be displayed in a Siebel Workflow picklist, the Hidden flag for the business service must be set to FALSE. Additionally, you must set the Hidden flag for the associated business service methods and method arguments. NOTE: By default, business services defined in the Siebel client are not hidden. When creating workflow definitions in Siebel Tools, the value of the Name property—for business services, business service methods, and business service method arguments—is the value that appears in the picklists. To enable business services for Workflow 1 In Siebel Tools, from the Object Explorer applet, select the business service object. This action displays a list of defined business services. 2 Select the business service you want to modify. 3 In the Properties window, change the Hidden field to FALSE. 4 In the Object Explorer, select the business service method under the business service. 5 Select the method you want to modify and change the Hidden field to FALSE in the properties applet. 6 Repeat Step 5 for each method, if applicable. 7 In the Object Explorer, select the method argument under the business service method. 8 Select the argument you want to modify and change the Hidden field to FALSE in the Properties applet. 9 Repeat Step 8 for each method argument, if applicable. Defining a Test and Migration Strategy for Workflow Processes Before implementing new workflow processes, you must verify them in a test environment. Testing new processes verifies that the process you release into the production environment properly executes and does not cause conflicts with your existing workflow processes. The following are some suggestions for setting up your test and migration policy: 58 Siebel Business Process Framework: Workflow Guide Version 8.0
    59. Planning Workflow Processes ■ Verifying Workflow Policies Installation ■ Make sure your test environment and production environment have identical versions of the software and that you are using realistic data in your database by using a partial or complete copy of the production database. ■ Create a small group of workflow processes to implement as a first phase of implementation. After you have successfully implemented the first group, you can add more processes in a systematic manner. For more information on migrating your test environment to your production environment, see “Migrating Policies to the Production Environment” on page 294. Verifying Workflow Policies Installation Workflow Policies is installed as part of the Siebel Server and client installation and is enabled by using your license key information. This section describes only how to verify the correct installation of Workflow Policies. For information about the installation process, see the installation guide for the operating system you are using. To run Workflow Policies, make sure the Siebel Server components (including Workflow Management), as well as both Siebel Tools and the Siebel client (Service, Call Center, or Sales), are installed. Verifying the Repository Setting for Workflow Policies Installation In the Siebel client, the .cfg file is used to configure Workflow Policies. Check that the DockRepositoryName entry specifies the correct repository name. Verifying the Workflow Setup for Workflow Policies Installation You need to verify that your license key includes Siebel Workflow. Because Siebel Workflow runs as server components on the Siebel Server, you also need to verify the proper installation of the Siebel Server. To do this, follow the procedure that follows to verify that you can access the Workflow Policies client screens and server screens. To verify the Workflow setup 1 Log in to the Siebel client as the Siebel administrator. 2 Select View > Site Map > Administration - Business Process. Under the list of views, you should be able to see Policies, Policy Groups, and so forth. This indicates that your license key is correct. Siebel Business Process Framework: Workflow Guide Version 8.0 59
    60. Planning Workflow Processes ■ Upgrading Siebel Workflow 3 From a client that is configured to manage the server component groups, select View > Site Map > Administration - Server Management > Servers > Component Groups. Check that the Workflow Management component group is enabled. Upgrading Siebel Workflow This topics discusses upgrading Siebel Workflow to version 8.0 from prior versions. Runtime and Repository Schema Upgrade There have been repository and runtime schema changes for the workflow tables, and new columns have been added to the repository and runtime schema. To add the new columns to the Siebel database, follow the instructions provided in Siebel Database Upgrade Guide. Existing workflow definitions in the runtime deployment table are not changed during the upgrade. After the merge process is completed, use the Workflow Deployment view in the runtime client to reactivate all completed workflows to load the new workflow definitions into the runtime. For instructions on reactivating workflow processes, see Siebel Database Upgrade Guide. Workflow Definition Merge If you have upgraded to Siebel version 7.7, Siebel workflow definitions were moved from the runtime tables into the repository tables. If you are upgrading to version 8.0 from version 7.7 or 7.8, any modified seed workflows or custom workflows will be merged into the 8.0 repository during the repository merge process. For information about detailed merge algorithms, see Siebel Database Upgrade Guide. However, if you are upgrading to Siebel 8.0 directly from a version prior to version 7.7, your custom workflows and modified seed workflows will be 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 instance, make sure you review your workflow customizations after the repository merge process. 60 Siebel Business Process Framework: Workflow Guide Version 8.0
    61. 5 For Developers: Basics of Building Workflow Processes This chapter describes the steps involved in building workflow processes. This chapter is divided as follows: ■ “Overview of Developing a Workflow Process” on page 61 ■ “Siebel Tools and Workflow Processes” on page 62 ■ “Using Process Designer in Siebel Tools” on page 64 ■ “Tutorial: Using Process Designer in Siebel Tools” on page 79 Overview of Developing a Workflow Process You use Siebel Tools to create workflows. In a typical development cycle for creating workflows, your steps take the following sequence: 1 Review existing process definitions. See “Reviewing Existing Workflow Processes” on page 76. 2 Use the Siebel Tools client to develop new workflow processes. See “Using Process Designer in Siebel Tools” on page 64. 3 Save the workflow processes to your local database. 4 Test the workflow processes using the Siebel Web Client. See Chapter 8, “For Developers: Testing Workflow Processes.” 5 Debug the workflow processes using your local master or test database. NOTE: Long-running workflow processes cannot be debugged using the Process Simulator. For testing of long-running workflow processes, see “Testing Workflows That Involve Server Components” on page 180. Workflow definitions are checked out from the repository into the local database, where they are modified and debugged locally before being checked in to the master repository. NOTE: 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. 6 Run the workflow processes from the Siebel Web Client, using your local master or test database. 7 Using the Siebel Tools client: ■ Check the workflow processes into and out of your master database. ■ Export the workflow processes into an XML file for backup. ■ Import the workflow processes from the XML file to restore them (if necessary). See “Importing or Exporting a Process Definition” on page 187. Siebel Business Process Framework: Workflow Guide Version 8.0 61
    62. For Developers: Basics of Building Workflow Processes ■ Siebel Tools and Workflow Processes 8 Deploy the workflow process definitions from your master database to your staging or production database. See “Deploying Workflow Processes” on page 182. This development-cycle sequence is illustrated in Figure 14 on page 62. Figure 14. Typical sequence for developing workflows Siebel Tools and Workflow Processes Siebel Tools is an integrated environment for configuring Siebel applications. You use Siebel Tools to modify standard Siebel objects and create new objects to meet your organization’s business requirements. Just as you use Siebel Tools to extend the data model, modify business logic, and define the user interface, you also use Siebel Tools to configure the workflows that the Siebel application uses to automate your organization’s business processes. Siebel Tools consists of an Object Explorer window and one or more Object List Editor windows, as shown in Figure 15 on page 63. The Object List Editor window lists object definitions for each object type and allows you to edit object type properties. The Object Explorer provides navigation between each group of object definitions of a particular object type. Object type is an entity that is displayed as a node on the Object Explorer. An object type is the template from which object definitions are created and have a predefined set of properties. Workflow Process is one object type. An object definition implements one piece of the software such as Service Request or Contact. This object definition consists of properties, which are characteristics of that piece of the software. 62 Siebel Business Process Framework: Workflow Guide Version 8.0
    63. For Developers: Basics of Building Workflow Processes ■ Siebel Tools and Workflow Processes Properties correspond to the columns in Object List Editor windows. The information entered under the columns is values. You can edit the properties of the currently selected object definition in an Object List Editor window by changing the values in the columns. You may change the property values in an object definition but not the set of properties to which values are assigned. Object Explorer Object List Editor Figure 15. Object Explorer and Object List Editor Windows This guide assumes that you understand the basics of using Siebel Tools. The information you need to know includes the following topics: ■ Siebel Tools application windows (the Object Explorer and the Object List Editor) ■ Configuring object properties, applets, and applet controls ■ Using the Siebel Tools menu bar ■ Checking out and checking in projects ■ Working with projects For information on these and many other topics, see Using Siebel Tools. For further information, see Configuring Siebel Business Applications. Siebel Business Process Framework: Workflow Guide Version 8.0 63
    64. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools Using Process Designer in Siebel Tools You use the Process Designer in Siebel Tools to configure workflows to meet the specific needs of your business. In this release, the Process Designer resides in Siebel Tools and the Workflow Process object type is a new top-level object type in the Object Explorer within Siebel Tools. Siebel Workflow is a configuration object. The Workflow Process object type belongs to a specific project, but it does not get compiled and it is not part of the repository merge that happens during the upgrade process. Because the Process Designer is in Siebel Tools, data objects are available for use as you design your workflow processes. Changes to repository data are immediately available for use in a workflow process without the need for a compile of the SRF. You can use configuration data (business component fields and other repository information) while you are building your workflows. For example, if you have a List of Values (LOV) such as Account Status (with values of Gold, Silver, and Bronze) you can use a newly added LOV in the definition of your workflow process conditions as you are defining them. As another example, if you add a field to a business component, that new field is readily available for use in Process Designer. The type of data that is not available for use in designing workflow processes is the run-time data such as an account name or a ZIP code and other transactional data. To use run-time data as you are building workflow processes, make the data a process property variable. For more information, see “About Process Properties” on page 93. You can also hardcode the run-time data in your workflow process, if you need this flexibility, by using unbounded picklists. All business services are available for use at design time, both those business services defined in Siebel Tools and those defined in the run-time client. More information on the Process Designer’s design functions, applet fields, and palette items is included in the following sections: ■ “About the Design Functions of the Process Designer” on page 64 ■ “About the Multi Value Property Window” on page 65 ■ “Field Descriptions: Workflow Processes” on page 66 ■ “Field Descriptions: Process Properties for Workflows” on page 71 ■ “Process Designer Palette Items” on page 73 About the Design Functions of the Process Designer You use the Process Designer in Siebel Tools to build your workflow processes. While drawing your workflow processes in the Process Designer, you can: ■ Copy and paste. Copy and paste workflow palette items within a workflow as you are building it. When you copy a step, its associated branches are copied along with it. ■ 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. Create consistency by controlling alignment of shapes and by making shapes the same size as others in the workflow process. 64 Siebel Business Process Framework: Workflow Guide Version 8.0
    65. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools ■ Zoom. Zoom in and out on the Process Designer Palette to view the workflow process you are drawing at various magnifications. ■ Copy drawings. Copy workflow drawings into another application, such as a Microsoft Word document. In the design palette, right-click and choose Copy Drawing. ■ Print. Print a drawing of the workflow process. ■ Show branch labels and exceptions. You can choose to show or hide the names that label connectors within a workflow. The copy-paste function works as Windows applications do with the CTRL+C and CTRL+V key combinations. The rest of the design functions are employed by right-clicking the Process Designer Palette. For more information, see “Process Designer Palette Items” on page 73. About the Multi Value Property Window In this release, the Multi-value Properties Window (MVPW) replaces the list applet in most cases within the Siebel Tools side of the Business Process Designer. Rather than viewing a step’s properties by clicking the step and accessing a list applet below the canvas, you view the step’s properties in the Properties window, and its child items in the MVPW. Rather than right-clicking a step to see its input/output arguments, you view them in the MVPW. You can add and delete values from within the MVPW as well, in the same manner as was done in previous releases in the list applets. The MVPW is context-sensitive; it displays the appropriate set of properties based on the object selected. In some cases, depending on the context, the MVPW displays tabs to show a variety of object attributes. There are two cases in which the MVPW displays attributes and values: ■ When you click a step or connector in the Process Designer design canvas, its child objects are displayed in the MVPW. ■ When you click the canvas, with no step or connector selected, the child objects of the workflow process are displayed: its process properties and its metrics. Siebel Business Process Framework: Workflow Guide Version 8.0 65
    66. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools The Multi Value Property Window is shown in Figure 16. Figure 16. Multi Value Property Window Displaying Process Properties for a Workflow Process Field Descriptions: Workflow Processes Table 6 describes the fields in which you enter data to define workflow processes, in the Process Designer’s Properties window in Siebel Tools. 66 Siebel Business Process Framework: Workflow Guide Version 8.0
    67. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools The Properties window provides properties based on context. To display the properties of a particular workflow process (that is, not the properties of its steps or connectors), right-click in the design canvas (making sure that no step or connector is selected at the time) and select View Properties Window. Table 6. Workflow Processes Fields in the Properties Window Field Description Possible Value Auto Persist Sets workflow persistence. (Optional) YES or NO Business The name of the associated business (Optional) This value is selected from a Object object. picklist of business objects. Only business objects with a defined primary component appear in this picklist. See Chapter 4, “Planning Workflow Processes” for more information on defining the primary component for a business object. Error Process The name of the workflow process to (Optional) Choose from the picklist of Name call as the error process. predefined workflow processes. Group This field applies to pre-7.7 (Optional) workflows. NOTE: Do not use this field for new workflows you create. Use the Project field instead. Pass By Ref Applicable for hierarchal data (Optional) TRUE or FALSE Hierarchy passed between subworkflow processes and parent workflow processes. If “pass by reference” is checked, then changes made in the child workflow process propagate back to the parent workflow process. When enabled, this feature reduces memory footprint required for workflow processes as data is passed by reference instead of by value. Process The name of the process. (Required) A descriptive name that is: Name ■ Consistent with your overall naming strategy ■ Meaningful to the designer of the process ■ Unique Siebel Business Process Framework: Workflow Guide Version 8.0 67
    68. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools Table 6. Workflow Processes Fields in the Properties Window Field Description Possible Value Project The name of the project to which the (Required) workflow process belongs. Replication How workflows synchronize to None, All, or Regional Level Mobile Web Clients. The All value synchronizes to the server’s regional nodes as well as mobile users, whereas the Regional value synchronizes just to the server’s regional nodes. State The workflow process state (Required) Management management type. Describes the ■ Stateless. Business service method(s) Type type of business service requests invoked by this workflow process have made while the workflow process is no dependency on a service-specific being executed. If all services state. Choose this setting if the invoked by this workflow process stateful/cached services invoked by this are stateless business services, then workflow can be released when the the state management type should workflow pauses or completes. be set to Stateless. Otherwise, it should be set to Stateful. ■ Stateful. Business service method(s) invoked by this workflow process The default setting is Stateful. depend on a service-specific state. For more information, see “State Choose this setting if the stateful/ Management Type and Workflow cached services invoked by this Processes” on page 69. workflow should not be released during and after the execution of the workflow. Status The current status of the process. (Required) ■ Not In Use ■ In Progress ■ Completed Version The version number of the process Read-only. The default version is 0. The definition. version number increments by one when you use the Revise button to modify an existing process definition. 68 Siebel Business Process Framework: Workflow Guide Version 8.0
    69. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools Table 6. Workflow Processes Fields in the Properties Window Field Description Possible Value Web Service This field indicates that a business (Optional) TRUE or FALSE Enabled service or workflow is exposable as a web service and can be called independently. NOTE: Setting this field to TRUE does not automatically enable the workflow web service, nor does enabling the workflow process for web service cause the flag to be checked. Workflow The workflow process type. (Required) Mode The workflow process types are the following: ■ 7.0 Flow. A 7.0 workflow process provides backward compatibility for existing Siebel 7 (pre-7.7) workflows. ■ Long Running Flow. A long-running workflow process is a persistent workflow that can last for hours, days, or months. ■ Interactive Flow. An interactive workflow process navigates the user across Siebel views. ■ Service Flow. A service workflow process executes a set of operations. State Management Type and Workflow Processes The OM-session state management framework requires all business services to have a defined state management type. A business service must be defined either as Stateless or Stateful, or as a Server- managed business service. The Workflow engine is a business service—the Workflow Process Manager business service—and it is defined as Stateless. The State Management Type field (in the Workflow Process Properties window) of a workflow process defines whether a workflow process is designed to be stateless or stateful. The Workflow engine can execute both stateful or stateless workflow processes, as follows: ■ When a workflow process is defined as Stateless, the OM-session state management framework can release all stateful or cached business services invoked by this workflow process when the workflow instance is paused or completed. Siebel Business Process Framework: Workflow Guide Version 8.0 69
    70. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools ■ When a workflow process is defined as Stateful, the OM-session state management framework does not release any stateful or cached business services invoked by this workflow instance even after the instance is completed. Instead, the framework waits for the caller of the Workflow engine to decide when the cached services should be released. The caller of the Workflow engine can release all stateful or cached business services by calling methods from Web Channel Dedicated Block Service. Defining the Workflow Process State Management Type By default, the workflow process State Management Type is set to Stateful to preserve the pre-8.0 behavior. However, if a workflow process is designed to be executed through Web Channel, it may be necessary to change its State Management Type to Stateless in order to take advantage of the session-pooling feature in the OM-session state management framework. A workflow’s processing mode (Workflow Mode) determines its State Management Type as follows: ■ 7.0 Flow. All existing Siebel 7.0 workflows are defined as Stateful to preserve the existing behavior. Do not change this setting unless you are sure that none of the business services the workflow invokes directly or indirectly is a stateful business service. ■ Long Running Flow. In general, long-running workflows are defined as Stateless. This is because the Workflow engine is already designed to allow long-running workflows to migrate between sessions when long-running workflows are being paused. Developers should therefore not configure a long-running workflow to invoke any stateful business services, since the service state will be lost when a long-running workflow instance migrates from one user session to another. ■ Service Flow. In general, service workflows are defined as Stateless. This is because a service workflow can have neither User Interact steps nor Wait steps. This means a service workflow is always executed in its entirety before the OM-session state management framework is given a chance to release the session back to the pool. ■ Interactive Flow. In general, interactive workflows are defined as Stateless. Like a long- running workflow, an interactive workflow instance may migrate between sessions through the Universal Inbox. However, since the State Management Type setting is only relevant when the workflow process is executed through Web Channel, and since interactive workflows always execute in a user-interactive session, the State Management Type setting does not have any effect on the behavior of an interactive workflow. For more information on the Web Channel OM-session state management framework, see Siebel Web UI Dynamic Developer Kit Guide. 70 Siebel Business Process Framework: Workflow Guide Version 8.0
    71. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools Field Descriptions: Process Properties for Workflows Table 7 describes the fields in which you enter data to define process properties for workflows. To view and change these properties, use the Multi Value Property Window. View the MVPW by clicking in the design canvas of a workflow process, with no steps or connectors selected. You can also view the MVPW by selecting View > Windows > Multi Value Property Window. NOTE: For descriptions of the fields that apply to workflow steps, see “Field Descriptions: Workflow Steps” on page 99. Table 7. Process Property Fields for Workflow Processes Field Description Possible Value Name The name of the process property. A descriptive name that is: ■ Consistent with your overall naming strategy ■ Meaningful to the designer of the process ■ Unique Display Name A user-friendly version of the The Display Name can be the same as or property name. different from the Name. In/Out Describes whether or not the ■ In. The process property is passed into process property is passed in or out the process. (Binary types cannot be of the process, passed into the assigned this value.) process and returned, or used only ■ Out. The process property is passed out within the process. of the process. (Binary types cannot be assigned this value.) ■ In/Out. The process property is passed into the process and returned. (Binary types cannot be assigned this value.) ■ None. The process property is used only within the process. Business The name of the associated business Read only. See Chapter 4, “Planning Object object. Workflow Processes” for more information on defining the primary component for a business object. Business The name of the business This value is selected from a picklist of Component component containing the virtual business components belonging to the field. workflow process business object. Virtual Field The name of the business This value is selected from a picklist of component field mapped to the fields belonging to the business component. workflow process property. Only calculated fields with no calculated values appear in this picklist. Siebel Business Process Framework: Workflow Guide Version 8.0 71
    72. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools Table 7. Process Property Fields for Workflow Processes Field Description Possible Value Default Initial value if the process property Free-form text. If you enter <Value>, the String is a string type. process property is initialized with the value in the Value field of the workflow input property set. Default Date Initial value if the process property Calendar widget. is a date type. Data Type The type of data that can be stored ■ Alias. Size limit for default value (not in the process property. 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 field. ■ Date. For dates. ■ Hierarchy. Data type used by Siebel Enterprise Application Integration to store data from a property set. For more information, see Overview: Siebel Enterprise Application Integration. ■ Integration Object. For storing integration objects. Integration objects have 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 creating 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 Initial value if the process property Numeric widget. Number is a numeric type. 72 Siebel Business Process Framework: Workflow Guide Version 8.0
    73. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools Table 7. Process Property Fields for Workflow Processes Field Description Possible Value Integration Data type used by Siebel EAI to Example: “Account - Get Oracle Customer Object store data from an integration (Oracle)” object. Correlator Makes the process property ready Check mark. Flag for use as a correlator (a piece of business data that identifies the recipient of the incoming message). See “About the Workflow User Event Business Service” on page 157. Access Mode Controls whether a process property Read-only or Read-write. is read-only or read-write. Process Designer Palette Items Figure 17 shows the Process Designer Palette. Figure 17. Drag and drop steps and connectors from the palette to the work space in the Process Designer. Siebel Business Process Framework: Workflow Guide Version 8.0 73
    74. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools Table 8 describes the items available on the Process Designer Palette. Each item represents a type of step or connector. Table 8. Process Designer Palette Items Item Description Possible Value Start Represents the input conditions that Every process must begin with a Start must be met to execute an instance of a step. There can be only one Start step business process. For more information, in a process. see “About Start Steps” on page 107. Business Represents an activity within a business A process can have one or more Service process. Business service steps call Business Service steps. business services that allow you to execute predefined or custom actions in a workflow process. For more information, see “About Business Service Steps” on page 114. Decision Point Represents a step in the process A process can have one or more definition where the work item branches Decision Point steps. off to different steps depending on a set of conditions. A Decision Point evaluates the defined conditions to determine the next step of the process instance. For more information, see “About Decision Points” on page 112. Subprocess Represents a workflow process A process can have one or more embedded into another workflow Subprocess steps. process. A subprocess has its own process definition. For more information, see “About Subprocess Steps” on page 120. Siebel Represents a type of action. Siebel Business object logic applies to all Operation Operation steps perform Siebel Siebel operations. A process can have operations, such as Insert, Update, or one or more Siebel Operation steps. Query, on business components. For more information, see “About Siebel Operation Steps” on page 124. Task Represents a task called from within a A process can have one or more Task business process. Task steps invoke steps. tasks for end users to complete in the UI. For more information, see “About Task Steps” on page 134. 74 Siebel Business Process Framework: Workflow Guide Version 8.0
    75. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools Table 8. Process Designer Palette Items Item Description Possible Value User Interact Represents end-user view navigation. A process can have one or more User User Interact steps control the flow of Interact steps. Siebel views within an application. A workflow process containing User Interact steps guides end users through a specified flow of Siebel views based on the users’ actions, or executes a specified set of actions. For more information, see “About User Interact Steps” on page 131. Wait Represents a pause in workflow process A process can have one or more Wait execution. Wait steps suspend execution steps. for a specific period of time or until a specific event occurs. For more information, see “About Wait Steps” on page 130. Stop Represents an end to a workflow process A process can have one or more Stop and the presentation of an error to the steps. user. Stop steps terminate the workflow process instance. For more information, see “About Stop Steps” on page 137. End Indicates when process execution is A process can have one or more end complete. An End step allows you to steps. save output arguments as process properties. For more information, see “About End Steps” on page 139. Connector Represents the direction of flow between A process can have one or more steps in a business process. connectors. Error Represents a deviation from normal A process can have one or more Exception processing. An exception can be a Exception branches. system error or a user-defined error. About Defining Workflow Process Parameters and Steps The first part of designing a workflow process is working with workflow process definitions to set the general process parameters and lay out the flow of the process steps. This involves: ■ “Reviewing Existing Workflow Processes” on page 76 ■ “Defining a New Workflow Process” on page 76 ■ “Naming Conventions for Workflow Processes, Steps, Branches, and Process Properties” on page 77 ■ “Modifying Existing Process Definitions” on page 78 Siebel Business Process Framework: Workflow Guide Version 8.0 75
    76. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools As a best practice in developing workflows, give your workflow definitions parameters that are externalized and not hard-coded. Having parameters hard-coded in Workflow means that you need to change the definitions when the workflows are migrated between environments and executed. For example, if a workflow is sending emails to a list of customers and the parameter is hard-coded with the customer list, the workflow will not work correctly in the production environment. You need to make sure that such input arguments are read dynamically. For an example of how to externalize parameters used by workflows, see “Example: Externalize Parameters to be Used by Siebel Workflow” on page 324. Reviewing Existing Workflow Processes Review your existing workflow processes to see if the process you need is already available or if a similar process exists that you can copy and modify to meet your requirements. The Workflow Processes Object List Editor (OBLE) provides a list of all the current process definitions. You can access the Workflow Processes OBLE in Siebel Tools. To review existing workflow process definitions 1 In Siebel Tools, in the Object Explorer Types tab, choose the Workflow Process object type. The right pane shows the Workflow Processes OBLE, which lists all the workflow processes. 2 If you find a process you want to copy as the basis for a new process definition, select the record, then right-click and choose Copy Record. See “Copying a Workflow Process” on page 92 for more details on copying an existing process definition. Defining a New Workflow Process Once you have reviewed your existing workflow process definitions, you are ready to create new workflow processes for the processes you have identified as missing. To design a workflow process 1 From within Siebel Tools, check out (for local use) or lock (for server use) the project which contains the Workflow objects. NOTE: You must check out the Workflow objects only if you are using a local data source. You check out the Workflow objects just like any other repository objects. If you are logged on directly to the server data source, check-out is not needed. 2 In the Object Explorer Types tab, choose the Workflow Process type. The right pane shows an Object List Editor (OBLE) window with a list applet containing all the workflow processes. 76 Siebel Business Process Framework: Workflow Guide Version 8.0
    77. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools 3 In the Workflow Processes OBLE, right-click and select New Record to create a new workflow process record. 4 In the Process Name field, give the workflow a name that is short but meaningful. 5 Your new workflow process must belong to a project. Scroll to the Project field and from the picklist, choose the project to which you want the workflow to belong. 6 In the Description field, enter a description. Use this field to describe the purpose of the process and any special requirements or notes. 7 In the Business Object field, choose the business object that the workflow process involves. 8 In the Workflow Mode field, choose the type of workflow process: long-running, interactive, or service. 9 Enter other relevant details. 10 Right-click the record and choose Edit Workflow Process. 11 Drag and drop shapes (palette items) from the palette to the design canvas to build the workflow diagram. For information on workflow steps, see Chapter 6, “For Developers: Workflow Process Steps.” For more information on diagramming a workflow using the Palette Designer, see “Diagramming a Workflow Process” on page 90. Naming Conventions for Workflow Processes, Steps, Branches, and Process Properties When naming workflow processes, the combination of workflow process name and version must be unique. That is, you can have two workflow processes of the same name as long as their version numbers are different. Names given to workflow process steps and process properties must be unique as well, within a workflow process. When you create a new process step, its name field is automatically populated with a name/number combination that you can change. If you change the name, the new name (including the number) must be unique from the names of the other steps in the process. The name given automatically to a step or a connector is based on its type, for example “Business Service” for a business service step, or “Siebel Operation” for a Siebel operation step. The number given automatically in the name for a step or a connector is an integer (that is, 0, 1, 2, 3, and so on). This number differentiates instances of the same type of step or connector (for example, Business Service 0, Business Service 1). This number, called sequence, is stored as part of the name. When a new step of the same type is added to the workflow, if there is no gap between the sequence numbers for the type (gaps can be created when steps are deleted), the next number in the sequence is used. Otherwise, the first sequence number in the first gap interval for the step type will be the sequence assigned to the new step. For example, if 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) and Business Service 1 and Business Service 2 are then deleted, the next business service step assumes the sequence number 1. It is automatically named "Business Service 1." This sequencing approach is the same for branches (connectors). Siebel Business Process Framework: Workflow Guide Version 8.0 77
    78. For Developers: Basics of Building Workflow Processes ■ Using Process Designer in Siebel Tools Modifying Existing Process Definitions You can modify active workflow process definitions without restarting the Workflow Process Manager. A workflow process definition is refreshed in the process memory as soon as it is activated. When a new definition is deployed, the cache is refreshed, so any new instance picks up the new deployed definition. NOTE: For mobile clients and development clients, the server parameter called Workflow Version Checking Interval (VerCheckTime) controls how often the server component checks for new active versions of each process definition. When a new process definition is activated, all incoming process instances after the Workflow Version Checking Interval will use the new definition. Process instances initiated before this activation will continue using the previous process definition. Regarding the refresh of the process definition cache, it is important to note the following: When a process definition is activated (or reactivated) in a thread, ■ the caches of all threads in the same process are refreshed and all such threads get the updated definition immediately; ■ the caches of threads in other processes are not refreshed until a time period elapses, which is defined by the server parameter VerCheckTime. For example, consider the following scenarios: ■ Activation in thin clients. When workflows are activated from a thin client, such as the Call Center application, all user sessions in the same Call Center application server process get the updated workflow definition immediately. User sessions in other server processes, however, must wait for the VerCheckTime interval defined in the server process configuration before they receive the updated definition. ■ Activation in mobile or development clients. Each mobile or development client is a process of its own. The particular mobile/development client receives the updated workflow definition immediately. All other mobile/development clients must wait for the VerCheckTime interval defined in their configuration files before they can receive the updated definition. ■ Publish/Activate in Siebel Tools. The Siebel Tools application is a process of its own. All thin clients and mobile/development clients must wait for the VerCheckTime interval before they can receive the updated definition. NOTE: Refreshing the process definition cache is necessary but not sufficient for running the updated workflow definition correctly. If the workflow definition contains run-time events, the run- time event cache must also be refreshed. For thin clients, this requires you to reload run-time events from the Administration - Runtime Events views (right-click from the context menu, and select Reload Runtime Events). For mobile clients, this requires you to log out and log back in to the mobile client (which guarantees a refresh of the process definition cache as well). To modify an existing workflow process definition 1 In Siebel Tools, in the Workflow Processes OBLE, select the record for the workflow process you want to modify. 78 Siebel Business Process Framework: Workflow Guide Version 8.0
    79. For Developers: Basics of Building Workflow Processes ■ Tutorial: Using Process Designer in Siebel Tools 2 In the WF/Task Editor toolbar, click the Revise button, as shown in Figure 18. Figure 18. Revise Button in WF/Task Editor Toolbar A new version of the workflow process is created for editing. 3 With this new process record selected, right-click and choose Edit Workflow Process. 4 Make changes to this new version, as necessary. 5 When you have finished modifying the workflow process, validate it by right-clicking in the Palette Designer. For more information, see “Using the Validate Tool to Correct Errors in Workflow Processes” on page 175. 6 Deploy the workflow process to make it active. For more information, see “Deploying Workflow Processes” on page 182. Revising a Workflow Versus Copying a Workflow There is an important difference between revising a workflow, and copying a workflow. Revising a workflow—that is, modifying an existing workflow process definition—occurs through use of the Revise button in the WF/Task Editor toolbar. When you revise a workflow, the new workflow record created is the same as the original, with the same name, except that its version is different (incremented by one), and it is editable (its Status is “In Progress”). If your intent is to create a different workflow, with a different name and a different purpose, then you can copy an existing workflow to do so. In contrast to revising a workflow, when you copy a workflow (right-click > Copy Record from the context menu), you create a new workflow process that is identical to the original one, except that a unique name (such as “04-K88GQ”) has been generated for it; after doing this, you should update the name of the process with a different and meaningful one. The version of a new, copied workflow process is 0. When you revise a workflow process, however, the version is the next integer that follows the version number of the original workflow being revised. Tutorial: Using Process Designer in Siebel Tools This tutorial takes you through the steps involved in designing, simulating, and deploying a workflow process using Siebel Business Process Designer. This tutorial is organized as follows: ■ “Designing Your Workflow Process” on page 80 ■ “Testing Your Workflow Process” on page 85 ■ “Deploying Your Workflow Process” on page 87 Siebel Business Process Framework: Workflow Guide Version 8.0 79
    80. For Developers: Basics of Building Workflow Processes ■ Tutorial: Using Process Designer in Siebel Tools Designing Your Workflow Process In this tutorial, you complete the following sequence of activities to design your workflow process: 1 Create a new workflow process record. See “To create a new workflow process” on page 80. 2 Draw the workflow process in the Palette Designer. See “To design the workflow process” on page 81. 3 Define properties for the steps of the workflow process. See “To set properties for the workflow process” on page 82. 4 Create a trigger for the workflow process. See “To define the run-time event that triggers the workflow process” on page 83. 5 Define condition criteria for a Decision branch of the workflow process. See “To define condition criteria for the workflow’s Decision Point” on page 83. 6 Validate the workflow process. See “To validate the workflow process” on page 84. NOTE: The login information (SADMIN/SADMIN) as well as the other settings listed in this tutorial are provided as examples. You should modify these example settings as appropriate for your own setup. You create a workflow process and set its properties using the Process Designer in Siebel Tools. To create a new workflow process 1 Log in to Siebel Tools as SADMIN/SADMIN connecting to the Sample database. 2 In the Object Explorer Types tab, choose the Project object type. 3 In the Projects OBLE, right-click and select New Record to create a new project. a Name the project “80 Workflow.” b Lock the project. 4 In the Object Explorer Types tab, choose the Workflow Process object type. NOTE: If the Workflow Process object type does not appear in the Object Explorer by default, you can add it. Choose View > Options, and on the Object Explorer tab, select the Workflow Process type. 5 In the Workflow Processes OBLE, right-click and select New Record to create a new workflow process record. 80 Siebel Business Process Framework: Workflow Guide Version 8.0
    81. For Developers: Basics of Building Workflow Processes ■ Tutorial: Using Process Designer in Siebel Tools 6 Fill in the record’s fields to give the workflow process the following properties: Property Value Process Name 80 Workflow Large Opportunity Creates Activity Workflow Mode Service Flow Project 80 Workflow Business Object Opportunity This workflow is to be invoked by a run-time event. Once a user creates a new Opportunity record, the revenue of the opportunity will be evaluated. If the value of the opportunity is over $10,000, an Activity record will be created to have the sales representative follow up on the deal. To design the workflow process 1 Right-click on the new workflow process record you created in Step 5 on page 80 and select Edit Workflow Process. 2 From the palette, drag and drop step icons to the design canvas to match the following graphic. Add one Start step, one Decision Point, one Siebel Operation step, and one End step. Siebel Business Process Framework: Workflow Guide Version 8.0 81
    82. For Developers: Basics of Building Workflow Processes ■ Tutorial: Using Process Designer in Siebel Tools 3 Drag and drop Connector branches to connect all the steps, as depicted in the following graphic. Make sure that all of the connectors are correctly attached. A connector is correctly attached when red dots and squares appear at each of its ends (when the connector is selected). If you see a white square at one end, that end is not correctly attached. To set properties for the workflow process 1 Select the Start step. The corresponding Start step’s attributes are displayed in the Properties window and in the Multi Value Property Window. NOTE: If the Properties window is not visible, from the application menu select View > Windows > Properties Window. When you select a step icon or connector in the design canvas, its corresponding attributes and child items are shown in the Properties window and in the MVPW so that you can define its properties. 2 For the Start step, in the Properties window, set the Name property to “Start.” 3 Select the Decision Point. 4 For the Decision Point, set the Name property to “Is opportunity over 10K?” 5 Select the Siebel Operation step. 6 For the Siebel Operation step, set the following properties: Property Value Name Insert Activity to Follow Up Business Component Action Operation Insert 82 Siebel Business Process Framework: Workflow Guide Version 8.0
    83. For Developers: Basics of Building Workflow Processes ■ Tutorial: Using Process Designer in Siebel Tools 7 With the Siebel Operation step selected in the design canvas, view the context-sensitive child items for the step, including tabs for input arguments and output arguments. 8 In the Field Input Arguments tab, right-click and choose New Record to add two new records with the following properties: Field Name Type Value Description Literal Please call the customer ASAP since this is a large opportunity. Type Literal To Do. 9 Select the End step, and set its Name property to “End.” To define the run-time event that triggers the workflow process 1 In the design canvas, select the Connector branch that connects the Start step to the Decision Point. The Properties window and the MVPW toggle to attributes for the branch. 2 Set the branch properties as follows: Property Value Name Evaluate Oppty Type Condition Event Object Type BusComp Event Object Opportunity Event WriteRecord The business scenario for this tutorial dictates that when an opportunity’s revenue is greater than $10,000, an activity is inserted for the sales representative to follow up with the customer. To determine whether this activity is inserted or not, you set condition criteria on the workflow’s Decision Point. To define condition criteria for the workflow’s Decision Point 1 In the design canvas, double-click the Connector branch that connects the Decision Point to the Siebel Operation step. The Compose Condition Criteria dialog box appears. 2 In the Compare To dropdown picklist, select Business Component. 3 In the Operation dropdown picklist, select Greater Than. 4 In the Object dropdown picklist, select Opportunity. Siebel Business Process Framework: Workflow Guide Version 8.0 83
    84. For Developers: Basics of Building Workflow Processes ■ Tutorial: Using Process Designer in Siebel Tools 5 In the Field dropdown picklist, select Revenue. 6 In the Values box, click the New button to add a new value. 7 In the Add Value dialog box, type “10000” and click OK. 8 In the Compose Condition Criteria dialog box, click the Add button. The conditions you have set in the Compose Condition Criteria dialog box appear as shown in Figure 19. Figure 19. Condition Criteria for “Insert Activity to Follow Up” Siebel Operation Step 9 Click OK. To validate the workflow process 1 In the Process Designer, right-click and select Validate. The Validate dialog box appears. 2 Click Start. “Starting validation...” appears in the bottom-left corner of the Validate dialog box. 84 Siebel Business Process Framework: Workflow Guide Version 8.0
    85. For Developers: Basics of Building Workflow Processes ■ Tutorial: Using Process Designer in Siebel Tools 3 If the validation is successful, there are no errors to report and in the bottom-left corner of the dialog box, a message reads, “Total tests failed: 0.” NOTE: See “Using the Validate Tool to Correct Errors in Workflow Processes” on page 175 for a list of possible errors. 4 Click Cancel to exit the Validate dialog box. Testing Your Workflow Process In this section of the tutorial, you simulate the workflow process you created in “Designing Your Workflow Process” on page 80. In this tutorial, you complete the following sequence of activities to test your workflow process: 1 Before you can test your workflow process, you must create an opportunity that matches your test criteria. You create this opportunity, and make note of its row ID. This row ID is then used in the workflow process properties to run the test. See “To prepare for testing the workflow process” on page 85. 2 You start the simulation process with the Simulate command, and then you set the Debug properties for the run-time client. See “To begin your test of the workflow process” on page 86. 3 You run the Process Simulator in Siebel Tools by using the buttons of the Simulate toolbar. See “To run the Process Simulator” on page 86. To prepare for testing the workflow process 1 Launch Siebel Call Center logging in as SADMIN/SADMIN to the Sample database. 2 From the application-level menu, choose Navigate > Site Map > Opportunities. 3 Add an opportunity with the following properties: Name 80 Workflow Large Test Opportunity Revenue $400,000 4 From the applet-level menu, choose About Record to find the row ID for the opportunity in the Row # field. Make a note of this row ID. 5 In Siebel Tools, in the Palette Designer, right-click and choose View Properties Window if the Properties window is not already showing. 6 In the Properties window, select the Object Id field. 7 In the Default String field, insert the row ID value you noted in Step 4. Siebel Business Process Framework: Workflow Guide Version 8.0 85
    86. For Developers: Basics of Building Workflow Processes ■ Tutorial: Using Process Designer in Siebel Tools To begin your test of the workflow process 1 In the Process Designer, right-click and select Simulate. A read-only version of the workflow process diagram now shows where the canvas appeared previously. Because the simulator in Siebel Tools begins by launching an instance of the run-time client, you must first set the appropriate Debug properties. 2 Set the Debug properties for your run-time client, as follows: a In Siebel Tools, navigate to View > Options > Debug. b Set the following properties for your run-time client: Executable C:sea80clientbinw32udsiebel.exe CFG file C:sea80clientbinenuuagent.cfg Browser C:Program FilesInternet Exploreriexplore.exe Working directory C:sea80clientbin Arguments /h User name SADMIN Password SADMIN Data source Sample c Click OK. To run the Process Simulator 1 In the Process Designer, make sure the Simulator toolbar is visible. If not, from the application menu select View > Toolbars > Simulate. 2 From the OBLE, select a workflow, then right-click and choose Simulate Workflow Process to enable the Simulate button, then click Simulate. Alternatively, if you are working in the graphical workflow editor, you can right-click and choose Simulate. 3 With the read-only version of the workflow process diagram visible, click the Start Simulation button on the Simulate toolbar. The simulation process begins, and a debug instance of your run-time client is launched. This can take several seconds. 4 In Siebel Tools, view the read-only version of the workflow process diagram. The Start step icon is selected. 5 (Optional) In order to see additional information as you simulate your workflow process, in the Palette Designer, right-click and select Watch window. NOTE: You can use the Watch window to see object and variable values during simulation. If the variable is editable, you can update it in the Watch Window to feed a value to the simulation. You can hide the Watch window at any time by right-clicking and selecting Hide Watch Window. 86 Siebel Business Process Framework: Workflow Guide Version 8.0
    87. For Developers: Basics of Building Workflow Processes ■ Tutorial: Using Process Designer in Siebel Tools 6 Click the Simulate Next button to continue simulating the workflow process. In the read-only version of the workflow process, the Siebel Operation step icon is selected. 7 Click the Simulate Next button again to continue simulating the workflow process. 8 Click the Complete Simulation button to end the simulation. 9 From the application-level menu in the run-time client, choose Navigate > Site Map > Opportunities > Activities to see your test opportunity. If an Activity record has been generated, the simulation of your workflow process was completed successfully. Deploying Your Workflow Process When you have finished a successful simulation of your workflow process, you are ready to deploy it. To deploy the workflow process 1 In Siebel Tools, in the WF Process Props list applet, scroll to the Object Id process property for your workflow process. 2 In the Default String field for the Object Id process property, delete the row ID. 3 In the open windows in the Tools MDI (multiple-document interface), click Workflow Process list. 4 Select your workflow process record and in the WF/Task Editor toolbar, click the Publish button. The Status of the workflow process changes to Completed. 5 From the application-level menu in the run-time client, choose Navigate > Site Map > Administration - Business Process > Workflow Deployment. 6 In the parent applet, select your workflow process and click the Activate button. In the child applet, your workflow process record shows a status of Active. You may need to refresh the list of records to see this newly updated status. To refresh the list, perform a null query in the child applet. Siebel Business Process Framework: Workflow Guide Version 8.0 87
    88. For Developers: Basics of Building Workflow Processes ■ Tutorial: Using Process Designer in Siebel Tools 88 Siebel Business Process Framework: Workflow Guide Version 8.0
    89. 6 For Developers: Workflow Process Steps This chapter describes the various steps you use to build workflow processes and how to work with them. When you add a step to build a workflow process, you also define the branches, conditions, and values associated with the step. This chapter is organized as follows: ■ “About the Workflow Processes OBLE in Siebel Tools” on page 89 ■ “About Process Properties” on page 93 ■ “Field Descriptions for Defining Workflow Process Steps” on page 99 ■ “About Start Steps” on page 107 ■ “About Decision Points” on page 112 ■ “About Business Service Steps” on page 114 ■ “About Subprocess Steps” on page 120 ■ “About Siebel Operation Steps” on page 124 ■ “About Wait Steps” on page 130 ■ “About User Interact Steps” on page 131 ■ “About Task Steps” on page 134 ■ “About Stop Steps” on page 137 ■ “About End Steps” on page 139 About the Workflow Processes OBLE in Siebel Tools You use the Workflow Processes list editor in Siebel Tools to do the following: ■ Create and edit a workflow process. See “Diagramming a Workflow Process” on page 90. ■ Define step details for a workflow process. See “Defining Step Details for a Workflow Process” on page 91. ■ Copy a workflow process. See “Copying a Workflow Process” on page 92. ■ Delete a workflow step. See “Deleting a Workflow Step” on page 92. ■ Delete a workflow process. See “Deleting a Workflow Process” on page 92. ■ Revise an existing workflow process. See “Modifying Existing Process Definitions” on page 78. ■ Import and export a workflow process. See “Importing or Exporting a Process Definition” on page 187. Siebel Business Process Framework: Workflow Guide Version 8.0 89
    90. For Developers: Workflow Process Steps ■ About the Workflow Processes OBLE in Siebel Tools Diagramming a Workflow Process Diagramming the process steps is an important part of creating a functional process. The flowchart interface of the Process Designer allows you to build a visual representation of the entire process flow, including decision points and decision branches. From this design, you then access and fill in step details by clicking a step icon. You can choose to define the details for each step as you create them in the Designer applet, or you can finish the entire flowchart of the process and then enter the details for each step. You define workflow step details by clicking on a step icon or connector arrows in the flowchart workspace. Based on your planning results, use the following procedure to diagram the steps of the process. To diagram the steps of a workflow process 1 From Step 11 on page 77, add a Start step to the design canvas. All processes must have one and only one Start step. Details on defining a Start step are in “Defining a Start Step” on page 107. 2 Add one or more middle steps to the design canvas. Processes can have one or more of any of the action step types, such as Business Service, Decision, Subprocess, Task, Stop, Wait, Exceptions, and Siebel Operation. There can be multiples of each type of step. For details on each type of step, see: ■ “Defining a Decision Point” on page 113 ■ “Defining a Business Service Step” on page 118 ■ “Defining a Subprocess Step” on page 122 ■ “Defining a Siebel Operation Step” on page 125 ■ “Defining a Wait Step” on page 130 ■ “Defining a User Interact Step” on page 132 ■ “Defining a Task Step” on page 134 ■ “Defining a Stop Step” on page 138 3 Add an End step to the diagram area. All processes must have at least one End step. Details on defining an End step are in “Defining an End Step” on page 139. 90 Siebel Business Process Framework: Workflow Guide Version 8.0
    91. For Developers: Workflow Process Steps ■ About the Workflow Processes OBLE in Siebel Tools 4 Illustrate the flow and paths of the process by dragging and dropping connector arrows between the steps. Position one end of the arrow on one of the steps and drag the handles to connect the other end to the next step in the flow. NOTE: An end point on a connector is white if it is not successfully connected to a step. Be sure that both ends of all connectors are red, indicating that each connector is successfully connecting two steps. Connecting an arrow to a Decision Point creates a decision branch for that specific Decision. For information about defining decision branches, see “Defining Decision Branches” on page 113. To add or remove a point in a connector, use the following steps: a Select the connector or exception. b Right-click and select one of the following: ❏ Edit > Add Point ❏ Edit > Remove Point Defining Step Details for a Workflow Process A workflow step’s details include input and output arguments, branch parameters, and conditions. You define each step’s details using the WF Steps applet in the Object List Editor (OBLE), one at a time by selecting each step in the workflow. To define step details 1 Single-click on each step palette item to select the step, and enter the step’s details in the Properties window. (If the Properties window is not showing, right-click and select View Properties Window.) 2 Enter input arguments, output arguments, branch parameters, and condition criteria using the Multi Value Property Window. ■ To enter input and output arguments (for Business Service steps, Subprocess steps, and Wait steps), use the tabs in the MVPW. ■ To enter branch parameters (for Start steps, Decision Points, and User Interact steps), click the branch and use the Properties window and the MVPW. ■ To enter conditions (for branches), double-click the branch (or right-click the branch and choose Edit Conditions). The Compose Condition Criteria dialog box appears. NOTE: The values you find listed in the Compose Condition Criteria dialog box are constrained by the business object for your workflow process, which is specified at the process level. For more information, see “Using Process Designer in Siebel Tools” on page 64 and “Field Descriptions: Workflow Processes” on page 66. ❏ Enter your condition criteria and click Add to add the condition. Siebel Business Process Framework: Workflow Guide Version 8.0 91
    92. For Developers: Workflow Process Steps ■ About the Workflow Processes OBLE in Siebel Tools ❏ To update a condition, select the record in the Conditions control, make modifications as necessary in the other controls, and click Update. ❏ To delete a condition, select the record from the Conditions control and then click Delete. ❏ Click OK. Deleting a Workflow Step You can delete a process step in the Palette Designer. When you delete a step, its associated branches are deleted along with it. To delete a step 1 From the flowchart diagram, choose the icon for the step you would like to delete. 2 Right-click the icon, then select Edit > Delete. Deleting a Workflow Process You can delete a workflow process in the Object List Editor in Siebel Tools. To delete a workflow process 1 In the Object Explorer Types tab within Siebel Tools, choose Workflow Process. 2 In the OBLE, select the process you want to delete. 3 Right-click and select Delete Record. Copying a Workflow Process If, in your existing workflow process definitions, you find a process you want to copy as the basis for a new process definition, you can copy it. The new workflow process you create in this way is identical to the original, with an automatically generated unique name (such as “04-K88GQ”), and a version number of 0. You copy a workflow process in the Object List Editor in Siebel Tools. To copy a process 1 In the Object Explorer Types tab within Siebel Tools, choose Workflow Process. 2 In the OBLE, select the process you want to copy. 3 Right-click and select Copy Record. 4 In the Process Name field, enter a new name for the process. 92 Siebel Business Process Framework: Workflow Guide Version 8.0
    93. For Developers: Workflow Process Steps ■ About Process Properties 5 Modify the other definition fields as necessary for the new process. NOTE: If you want to revise an existing process definition rather than create a new, copied process, see “Modifying Existing Process Definitions” on page 78. About Process Properties Process properties are fields for storing values that you can use in steps, either as input and output arguments, or for performing evaluations. Process properties store values that the workflow process retrieves from the database or derives before or during processing. You can base decision branches on the values in a process property and pass process properties as step arguments. When a workflow process completes, the final results of the process properties are available as output arguments. You can also use process property values in expressions. Some default process properties are automatically defined for each process. They are: ■ Object Id. The Siebel row ID of the record against which the process is invoked. For more information, see “Object Id and Non-7.0 Workflow Processes” on page 94. ■ Error Code. An error symbol of the process instance if a step returns an error. This process property is automatically populated when an error occurs. ■ Error Message. An error message text of the process instance if a step returns an error. This process property is automatically populated when an error occurs. ■ Siebel Operation Object Id. The Siebel row ID of the record that is updated, created, or queried on during a Siebel Operation step. This process property is automatically populated when a Siebel Operation step is executed. ■ Process Instance Id. A unique number assigned to the currently running instance of the process. This process property is automatically populated when a process is executed and persistence is enabled. As an example for using process properties, you can define three new process properties for a workflow. These properties are of type String as shown in Figure 20. The process properties have values of "Welcome", "to", and "Siebel". Figure 20. Example of Process Properties You Can Create Siebel Business Process Framework: Workflow Guide Version 8.0 93
    94. For Developers: Workflow Process Steps ■ About Process Properties In the above example, you can create a fourth process property called "ProcessProperty4" that concatenates these first three values and displays the combination in an applet field. ProcessProperty4 is of type String and gets a value as an output argument on a step. The output argument is of type Expression as shown in Figure 21. Figure 21. Process Property Used as an Output Argument The following sections provide further information on process properties: ■ “Object Id and Non-7.0 Workflow Processes” on page 94 ■ “Process Properties Versus Property Sets” on page 95 ■ “Passing Property Sets by Reference” on page 96 ■ “Defining Process Properties” on page 96 ■ “Concatenating Process Properties” on page 97 ■ “Passing Process Properties In and Out of Steps” on page 98 Object Id and Non-7.0 Workflow Processes The Object Id process property is the Siebel Row Id of the primary business component record against which a process is invoked. Runtime Event Behavior When a workflow is invoked by a runtime event, the active business component instance that triggered the runtime event is automatically passed to workflow. Run-time events are received on the row specified by the Object Id parameter. Workflow receives and processes this event only when the business object that the active business component instance belongs to is the same as the business object in the workflow definition. If workflow can receive this event, the Object Id process property is automatically set to the active row of the primary business record in the business object. If the business component that actually triggered the runtime event is not the primary business component, the active row of the business component is not reflected in the Object Id process property, and needs to be retrieved through some extra processing. 94 Siebel Business Process Framework: Workflow Guide Version 8.0
    95. For Developers: Workflow Process Steps ■ About Process Properties Non-7.0 Flow Behavior In non-7.0 Flows, that is, in long-running, interactive, and service workflow processes: ■ The Object Id must match the Row ID of the primary business component’s active row. The Workflow engine will not allow the active row of the primary business component (BC) to be different from the Object Id process property. If the Object Id process property is different from the active row, the primary BC is re-executed to make the active row the same as the Object Id. NOTE: If you want to change the active row in a step of a workflow, you may do so (using an appropriate Business Service step or Siebel Operation step), but you must promptly update the Object Id process property to the new active Row ID, in the output arguments of the step that changes the active row. Once a step completes and output arguments have been evaluated, Workflow checks to make sure the Object Id matches the active row. So changes to the active row must be reflected in the Object Id property within the affected step. ■ It is possible to change the active row by assigning a new Row Id to the Object Id parameter. When Workflow detects that an assignment is made to the Object Id process property, Workflow re-executes the BC and makes the new Row ID the active row. ■ You can set the Object Id to an empty string and Workflow will no longer enforce the must-match rule. However, the parts of Workflow that require an Object Id (such as run-time events and Siebel Operation steps) cannot be used until the Object Id is set to a new Row ID. Process Properties Versus Property Sets Siebel business services use a structure known as the property set to represent input and output data for a method call. Property sets are hierarchical structures containing name/value pairs, known as properties, at each level in the hierarchy. For a detailed description of property sets, see Integration Platform Technologies: Siebel Enterprise Application Integration. Siebel Business Process Designer provides capabilities to store property sets as process properties. You can use process properties to pass property sets to and from business service steps. Such process properties have a data type of hierarchy, integration object, or strongly typed integration object and can be used as input and output arguments for any business service method arguments that have a data type of hierarchy, integration object, or strongly typed integration object. When you want to call a workflow as a business service, you can map the data contained in the input and output property sets to and from process properties. This is useful when you want to run a workflow within a script. When a workflow process is started, any process properties of type string, number, or date with an In/Out type of In or In/Out will be initialized to the input property with the same name, if one exists. Any hierarchy process properties with an In/Out type of In or In/Out will be initialized with any child input property sets that have a matching name (type). Any process properties with their Default String set to "<Value>" will be initialized with the value in the Value field of the input property set. Siebel Business Process Framework: Workflow Guide Version 8.0 95
    96. For Developers: Workflow Process Steps ■ About Process Properties When a workflow process completes, all process properties of type string, number, or date with an In/Out type of In or In/Out will be stored as properties in the output property set. Any hierarchy process properties with an In/Out type of In or In/Out will be stored as child property sets. If a process property with the name <Value> is defined, its value will be stored in the Value field of the output property set. For more information, see “Passing Parameters to and from Workflow with the Workflow Process Manager Business Service” on page 339. Passing Property Sets by Reference Subprocess methods tasked with modifying large amounts of data must copy large quantities of data as input and output arguments. This can negatively impact the performance and scalability of these method invocations. If you can avoid any unnecessary copying of data, you can achieve improvements in performance and scalability. Pass By Reference is a feature that allows you to avoid passing large property sets, by passing just a pointer to the property sets. You can enable support of Pass By Reference for workflow processes in subprocess steps; see “Enabling a Subprocess to Support Pass By Reference” on page 123. Defining Process Properties Process properties are the variable data you enter as you define workflow processes in the Process Designer within Siebel Tools. You use the WF Process Props applet in the Object List Editor (OBLE). You can define process properties step-by-step as you diagram a workflow process, or you can draw the workflow process diagram and then later define properties for the steps that make up the workflow process. To define process properties 1 Depending on your situation, do one of the following: ■ If in the process of creating a new workflow process, begin from Step 10 on page 77. ■ If defining process properties for an existing workflow process, navigate to the Palette Designer for the workflow process. From within an existing workflow process, having the process selected in the OBLE’s Workflow Processes list applet, right-click and choose Edit Workflow Process. 2 From the application menu, choose View > Windows > Multi Value Property Window. 3 In the Process Properties tab of the MVPW, right-click and choose New Record. 4 Enter a name for the process property. NOTE: See “Naming Conventions for Workflow Processes, Steps, Branches, and Process Properties” on page 77 for reserved symbols, such as the period (“.”) character, that cannot be used in a process property name. 96 Siebel Business Process Framework: Workflow Guide Version 8.0
    97. For Developers: Workflow Process Steps ■ About Process Properties 5 Select a data type code from the picklist. The default data type is String. NOTE: The String data type code is appropriate for strings, text data, and non-XML data (even though XML data can be stored here). String data in Siebel workflow processes is assumed to be UTF-16 String encoded. Literal or Expression data types are always UTF-16 String. The choices are: ■ String. If the property holds a character value. ■ Number. If the property holds a numeric value. ■ Date. If the property holds a date value. ■ Hierarchy. If the property holds hierarchical data (a property set). ■ Binary. If the property holds a binary value. Binary data is encoded in the original character set it was entered in. This data type code is appropriate for self-describing data, such as XML. ■ Integration Object. If the property holds an integration object. The Siebel .srf should have the integration object definition for this object. ■ Strongly Typed Integration Obj. If the property holds a strongly typed integration object. Alias. If the property holds an XPath notation for pointing to a child in a hierarchical process property. NOTE: Once a data type has been selected, it cannot be modified. 6 Enter a default string value, date value, or number value, if applicable. This is the value of the process property at the start of process execution. 7 Repeat Step 3 through Step 6 to define additional properties as necessary. Concatenating Process Properties You can use process property values in your expressions by concatenating workflow process properties with other process properties or with text. For example, you want to concatenate these process properties so that they appear as “Welcome to SupportWeb.” ■ ProcessProperty1= "Welcome" ■ ProcessProperty2= "to" ■ ProcessProperty3= "SupportWeb" You must create a ProcessProperty4 = “Welcome to SupportWeb.” To concatenate process properties ■ Define a Wait step with these values: ■ Output Argument = ProcessProperty4 ■ Type = Expression Siebel Business Process Framework: Workflow Guide Version 8.0 97
    98. For Developers: Workflow Process Steps ■ About Process Properties ■ Value = [&ProcessProperty1]+' '+[&ProcessProperty2]+' '+[&ProcessProperty3] The ampersand (“&”) indicates that this is a process property. The process property you indicate can also be the name of a business component field. ProcessProperty1-3 can be of many different types, such as string and date. Value, on the other hand, should be set to String type. Passing Process Properties In and Out of Steps In non-7.0 Flows—that is, in long-running, interactive, and service workflow processes—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 Workflow for the duration of the call to match the name of the argument as specified by the input argument’s configuration. For example: MyTree is a process property with data type Hierarchy. MyBusSvc is a business service that has a hierarchical input SomeTree. If the input argument is configured as shown in Figure 22, then the call into MyBusSvc will receive a child in its input process property with Process Property Type field set to “SomeTree” (instead of “MyTree”). The rest of the data in the child process property will be the same as the contents of the process property MyTree. Figure 22. Mutt Value Property Window of the input arguments tab for a business service Similarly, Workflow will expect an output argument of a step in a workflow that passes out a hierarchy to send it out as a child of the output property set. Workflow will locate the child by examining the Type field of the child. The string in the Type field should match the Output Argument name as specified in the output argument applet of the step. Once Workflow finds such a child, the data is copied into the indicated destination process property. However, the Type field on the incoming hierarchy will be discarded and instead the name of the process property will overwrite the Type field. To summarize, when passing hierarchies into and out of steps, the Type field of the top level of the data is used as the name of the argument. So the Type field of the top level of a hierarchical argument should not contain data. 98 Siebel Business Process Framework: Workflow Guide Version 8.0
    99. For Developers: Workflow Process Steps ■ Field Descriptions for Defining Workflow Process Steps Field Descriptions for Defining Workflow Process Steps Information on field descriptions is organized as follows: ■ “Field Descriptions: Workflow Steps” on page 99 ■ “Field Descriptions: Workflow Branches” on page 102 ■ “Field Descriptions: Compose Condition Criteria Dialog Box” on page 105 ■ “Field Descriptions: Input Arguments for Business Service Steps, Subprocess Steps, and Wait Steps” on page 115 ■ “Field Descriptions: Output Arguments for Business Service Steps, Subprocess Steps, and Siebel Operation Steps” on page 116 ■ “Field Descriptions: Step Recipients” on page 120 ■ “Field Descriptions: Subprocess Steps” on page 121 ■ “Field Descriptions: Search Specifications” on page 128 Field Descriptions: Workflow Steps Table 9 describes the fields in which you enter data to define workflow process steps. Table 9. Workflow Step Fields Type of Field Step Description Possible Value Name All The name of the step. A descriptive name that is: ■ Consistent with your overall naming strategy ■ Meaningful to the designer of the process ■ Unique NOTE: When you create a new step, the step is automatically assigned a name (based on its step type) and a sequence number. You can change this name or leave it as is. Type All The type of step. This value is automatically entered when you create the step in the Process Designer view. This is a read-only field. Siebel Business Process Framework: Workflow Guide Version 8.0 99
    100. For Developers: Workflow Process Steps ■ Field Descriptions for Defining Workflow Process Steps Table 9. Workflow Step Fields Type of Field Step Description Possible Value Business Siebel Required. The business Choose from a list of business Component operation component that will perform components that have been defined step the action you specify. for the selected business object. Business Business The name of the service to The picklist displays business Service Name service step invoke. services existing in Siebel Tools with the Hidden flag set to FALSE. See “Enabling a Business Service for Workflow Processes” on page 58 for more information. Business Business The name of the method to The picklist displays methods Service service step invoke on the service. defined for the selected business Method service. Subprocess Subprocess The name of the subprocess A descriptive name that is: Name step step. ■ Consistent with your overall naming strategy ■ Meaningful to the designer of the process Error Code Stop step A number associated with a Numeric value. string in the database that comprises the error message. Error Stop step A string in the database that Text string. Message comprises the error message. User Interact User interact The name of the view for the Choose from a picklist containing View step user interact step. predefined view names. Operation Siebel The type of operation. Insert, Query, Update, NextRecord, operation PrevRecord, QueryBiDirectional, or step Delete. 100 Siebel Business Process Framework: Workflow Guide Version 8.0
    101. For Developers: Workflow Process Steps ■ Field Descriptions for Defining Workflow Process Steps Table 9. Workflow Step Fields Type of Field Step Description Possible Value Maximum Wait step The maximum number of When the maximum number of Iterations times you can execute this iterations is reached, an Object step within a process Manager error will be generated and instance. the workflow process will return an In Error status. If you want the process to run to completion, you need to use a Workflow exception mechanism (such as an error process or exception branch) to catch and handle the error. For more information, see “Using Exceptions to Handle Errors” on page 163. Service Hours Wait step The name of the schedule This value is selected from a picklist used in calculating the wait of service calendars. end time. Description All A text narrative describing Free-form text. the purpose of the step. Update All This parameter is used for Check mark. Snapshot recovery. Update Snapshot indicates that when the process reaches this step, Workflow takes a snapshot of the process state, so that if there is a crash, you can get the state back. Processing Wait step The mode in which the (Optional) Mode process will be run when Local Synchronous. Executes the triggered by run-time process in the application object events. manager. This is the default. Remote Synchronous. Submits a synchronous request to the Workflow Process Manager server component to execute the process. Remote Asynchronous. Submits an asynchronous request to the Workflow Process Manager server component to execute the process. Siebel Business Process Framework: Workflow Guide Version 8.0 10 1
    102. For Developers: Workflow Process Steps ■ Field Descriptions for Defining Workflow Process Steps Field Descriptions: Workflow Branches NOTE: A branch can wait for multiple run-time events or a single user event. A branch cannot wait for a mixture of run-time events and user events. Specify only one event for a branch. Only long- running workflows can wait for user events. Never use run-time events in long-running workflows. Table 10 describes the fields that can be defined for step branches (connectors). Table 10. Workflow Branch Fields Field Description Possible Value Name The name of the branch. The name of the branch must be unique to the workflow process or you will not be able to commit the record. Type The type of branch. The value can be one of the following choices: Default. This value indicates that if nothing else is satisfied, this branch will be followed. Additionally, if this value is used, any conditions defined for the branch are ignored. Condition. This value indicates that a condition is defined for the branch. Connector. Use this value when there is no condition branching involved. Error Exception. Use this value to define exception handling. This connector type captures system errors, such as an error noting that the Assignment Manager server component is not available. For more information, see “Using Exceptions to Handle Errors” on page 163. User Defined Exception. Use this value to define exception handling. This connector type captures user-defined errors, such as an error noting that an order being submitted is incomplete. For more information, see “Using Exceptions to Handle Errors” on page 163. 102 Siebel Business Process Framework: Workflow Guide Version 8.0
    103. For Developers: Workflow Process Steps ■ Field Descriptions for Defining Workflow Process Steps Table 10. Workflow Branch Fields Field Description Possible Value Event Object This field is used when defining (Optional) Type a run-time event. The type of Application. object to which the event occurs: an application, an Applet. applet, or a business component. BusComp. NOTE: Event Object must be selected if Event Object Type exists. Event Object The name of the object (the Required if Event Object Type is specified. This application, applet, or business is the name as defined in Tools. The set of component) to which the event objects is different for different object types. occurs. Event The specific event that happens Required if Event Object Type is specified. The to the object. set of available events is different for different object types. Sub Event An options parameter for the (Optional) event, used when the object For InvokeMethod, the name of the method type is BusComp or Applet and being invoked. For SetFieldValue, the name of the event is InvokeMethod or the field being set. SetFieldValue. The subevent is the name of the method or business component field to be monitored. Event Cancel Aborts the run-time event after (Optional) Flag executing the process. This flag only applies to events that are NOTE: If this flag is not cancelable. This flag functions like checked, the error “The CancelOperation in scripting. specialized method <Method Name> is not supported on this business component” will result when running the workflow process. Expression User-friendly text for the Read-only condition defined for the branch Siebel Business Process Framework: Workflow Guide Version 8.0 10 3
    104. For Developers: Workflow Process Steps ■ Field Descriptions for Defining Workflow Process Steps Table 10. Workflow Branch Fields Field Description Possible Value Event Controls whether the workflow If the workflow process is persistent, the Visibility process waits for run-time visibility can be set to Enterprise or Local. events generated locally (that If the workflow process is not persistent, is, within the current session) or visibility should be set to Local. by any session. NOTE: In most places where a workflow needs to wait for an event, the workflow must be persistent, you set the value to Enterprise. However, setting Event Visibility to Enterprise may have a negative performance impact, because any run-time event will search for any matching instance. Therefore, it is recommended that if your workflows do not need to be persistent, you should set the Event Visibility to Local. User Event An arbitrary string that denotes This can be any string and must be unique Name the name of a user event. within the Siebel enterprise. NOTE: Make sure to give the User Event Name field a name that is unique and that is long enough to remain unique across the Siebel enterprise. Example: “Order Placed - Begin Processing Event for Service Request Automation - Version 2” User Event The process property that This value can be any process property except Storage serves as the destination for the the process property marked as the correlator. payload on the incoming user event. User Event The amount of time, in days, Numeric value Timeout before the event times out. NOTE: If the user event is on a wait step, use (Days) this parameter. Do not specify a wait duration on the wait step. Comments Additional statements relative to Free-form text. the branch. 104 Siebel Business Process Framework: Workflow Guide Version 8.0
    105. For Developers: Workflow Process Steps ■ Field Descriptions for Defining Workflow Process Steps Field Descriptions: Compose Condition Criteria Dialog Box You set condition criteria for branches, Decision Points, and User Interact steps using the Compose Condition Criteria dialog box. Figure 23 shows an example of the Compose Condition Criteria dialog box. This example shows the criteria for a decision branch in a workflow to be followed if the Severity field from a Service Request matches the value "1-Critical". Figure 23. Compose Condition Criteria Dialog Box Siebel Business Process Framework: Workflow Guide Version 8.0 10 5
    106. For Developers: Workflow Process Steps ■ Field Descriptions for Defining Workflow Process Steps Table 11 describes the fields that you use to define criteria for condition connectors, in the Compose Condition Criteria dialog box. NOTE: The values you find listed in the Compose Condition Criteria dialog box are constrained by the business object for your workflow process, which is specified at the process level. For more information, see “Using Process Designer in Siebel Tools” on page 64 and “Field Descriptions: Workflow Processes” on page 66. Table 11. Compose Condition Criteria Fields Field Description Possible Value Compare To Indicates where the This is a required field, with the following choices: comparison value is ■ Business Component coming from. ■ Process Property ■ Expression ■ Applet Operation Identifies the This Must Match. The current value must match exactly, comparison including case. operation. 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. 106 Siebel Business Process Framework: Workflow Guide Version 8.0
    107. For Developers: Workflow Process Steps ■ About Start Steps Table 11. Compose Condition Criteria Fields Field Description Possible Value Object The name of the This value is selected from a picklist of business objects. associated business object. Field This is a required The name of the field within the named applet. field when Applet is the Compare To value. Values The Values field is dynamic based on the Compare To field. The Values field is for storing data to be used in the condition evaluation. About Start Steps Start steps identify the input conditions that must be met for a process to execute. For example, to handle open service requests, you could define a start condition of “Status = Open.” The main parts of defining Start steps for a workflow process are: ■ “Defining a Start Step” on page 107 ■ See “Field Descriptions: Workflow Steps” on page 99 for descriptions of all step field values. ■ Define the start step branches, conditions, and values. ■ See “Field Descriptions: Workflow Branches” on page 102. ■ See “Field Descriptions: Compose Condition Criteria Dialog Box” on page 105. ■ See “About Conditions and Values” on page 108. For more information on workflow process field descriptions, see “Field Descriptions: Workflow Processes” on page 66 and “Field Descriptions: Process Properties for Workflows” on page 71. Defining a Start Step You define a Start step in the Process Designer in Siebel Tools. To define a Start step 1 In the Workflow Processes OBLE in Siebel Tools, select the workflow process for which you would like to define a Start step, or create a new workflow process. 2 Right-click and choose Edit Workflow Process. 3 Drag and drop a Start icon from the palette to the workspace. Siebel Business Process Framework: Workflow Guide Version 8.0 10 7
    108. For Developers: Workflow Process Steps ■ About Conditions and Values 4 In the Properties window, enter or modify the step name, and then enter a description of the purpose of the Start step. NOTE: If the Properties window is not showing, select the step icon, then right-click and select View Properties Window. 5 See “Defining Next Step Branches for Start Steps” on page 108 for instructions on setting up branches for the Start step. Defining Next Step Branches for Start Steps Start steps can have multiple Next Step branches. Use the following procedure to define each branch. NOTE: In this release, Workflow processes do not support parallel processing. Make sure that you define your conditions so that only one branch is valid. If an object matches the conditions in multiple branches, the exact run-time behavior of the Workflow engine is not guaranteed. To define a Next Step branch 1 In the Process Designer, drag and drop the appropriate step icon for the next step in the process. NOTE: If you have already designed the entire workflow process, including connector arrows, click the connector arrow attached to the Start step, then proceed to Step 4. 2 Drag and drop a connector arrow to the canvas, connecting the Start step with the new next step. 3 Click the connector arrow to access the attributes for the branch in the Properties window. NOTE: If the Properties window is not showing, select the connector icon, then right-click and select View Properties Window. 4 Enter or modify the branch name. NOTE: The name of the branch must be unique to the workflow process or you will not be able to commit the record. 5 Choose a branch type. Type values are described in Table 10 on page 102. CAUTION: Always define a Default branch step in case some work items do not meet any of the conditions you define. 6 Enter any comments. About Conditions and Values Conditions and values affect the flow of your process execution. For example, you can define a condition based on the value of a priority field. If the priority is “high,” the process follows a branch that sends an email to a vice president. If the priority is “medium,” the email is sent to an engineer. Information on conditions and values is organized as follows: ■ “Building Expressions with Expression Builder” on page 109 108 Siebel Business Process Framework: Workflow Guide Version 8.0
    109. For Developers: Workflow Process Steps ■ About Conditions and Values ■ “About Conditions and Values for Decision Points” on page 114 ■ “About Conditions and Values for User Interact Next Step Branches” on page 133 Building Expressions with Expression Builder This section describes “Compare To” options, operations, and patterns for building expressions. Compare To Options Compare To options, as well as their required and optional fields, are the following: ■ Applet. Compare the run-time value of an applet column to a literal(s). Required fields: ■ Operation. Comparison operation. All operations allowed. ■ Object. The name of the applet. ■ Field. The column in the applet. ■ Values. One or more literals for comparison. ■ Business Component. Compare the run-time value of a buscomp field to a literal(s). Required fields: ■ Operation. Comparison operation. All operations allowed. ■ Object. The name of the business component. ■ Field. The field in the business component. ■ Values. One or more literals for comparison. ■ Expression. Evaluate expressions and determine whether they return true. Required fields: ■ Operation. Specifies how effects of multiple expressions stack. Only applicable when multiple values are specified in the Values field. Operations allowed: All Must Match, None Can Match, One Must Match, This Must Match, as well as the four Ignore Case variations of these operations. See “Operations” on page 110 for further detail. ■ Values. One or more expressions. Optional field: ■ Object. The name of a business component, if business component fields are referenced in the expressions. Fields of at most one business component can be referenced in the expressions. ■ Process Property. Compare the run-time value of a process property to a literal(s). Required fields: ■ Operation. Comparison operation. All operations allowed. ■ Object. The name of the process property. ■ Values. One or more literals for comparison. Siebel Business Process Framework: Workflow Guide Version 8.0 10 9
    110. For Developers: Workflow Process Steps ■ About Conditions and Values Operations This section describes the comparison operations available. All available operations can be grouped into two categories, as follows: ■ simple comparison operations ■ iterative comparison operations Simple Comparison Operations Simple comparison operations involve comparisons that can be expressed in simple expressions without the need for iterative operations. These operations include the following: ■ Between. The comparison succeeds if the run-time value of interest is between two pre-defined literal values. This comparison requires exactly two values in the Values field, which is enforced by the Process Designer. ■ Not Between. The comparison succeeds if the run-time value of interest is not between two pre- defined literal values. This comparison requires exactly two values in the Values field, which is enforced by the Process Designer. ■ Greater Than. The comparison succeeds if the run-time value of interest is greater than a pre- defined literal value. Logically, only one value is needed in the Values field. ■ Less Than. The comparison succeeds if the run-time value of interest is less than a pre-defined literal value. Logically, only one value is needed in the Values field. ■ Is Null. The comparison succeeds if the run-time value of interest is null/empty. No value is required in the Values field. ■ Is Not Null. The comparison succeeds if the run-time value of interest is not null/empty. No value is required in the Values field. Iterative Comparison Operations Iterative comparison operations involve comparisons that involve multiple iterations on the literal values or expressions in the Values field, or iterations on child business component records, to derive a Boolean result. These operations include All Must Match, This Must Match, None Can Match, One Must Match, and their Ignore Case variations. The iterative operation can be defined in two ways, resulting in different iterative behavior: ■ when multiple values are specified in Values field ■ when multiple child business component records 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 that the workflow is working on. A child business component is involved in the comparison if the Compare To option is “Business Component” or “Expression,” and the Object field is specified as the name of a child business component. Multiple records may exist in the current workset for the child business component if multiple records were returned when the child business component was last executed. 110 Siebel Business Process Framework: Workflow Guide Version 8.0
    111. For Developers: Workflow Process Steps ■ About Conditions and Values ■ All Must Match Multiple-value behavior. If the values involved are literal values (that is, if the Compare To option is anything but “Expression”), this comparison succeeds if at least one value matches. If the values involved are expressions (that is, if the Compare To option is “Expression”), this comparison succeeds if all expressions are evaluated to true. Multiple-child-buscomp-record behavior. All child business component records are used for comparison and the overall comparison succeeds only if the comparison succeeds for every one of the records. The following example illustrates how this works, for the Workflow business object Account, with the decision-branch configuration specified in the table below: Compare To Operation Object Field Values Business Component All Must Match Contact First Name John, Sam In this configuration, all the Contact business component records in the current workset— which is usually all the child Contact records for the particular Account record that the workflow is working on—must have a first name of either John or Sam in order for the comparison to succeed and for the decision branch to pass. ■ This Must Match Multiple-value behavior. If the values involved are literal values, the comparison succeeds when at least one value matches. If the values involved are expressions, the comparison succeeds if at least one expression is evaluated to true. Multiple-child-buscomp-record behavior. Only the current child business component record is used for comparison and the overall comparison succeeds if the comparison succeeds for the current record. ■ None Can Match Multiple-value behavior. If the values involved are literal values, the comparison succeeds when none of the values matches. If the values involved are expressions, the comparison succeeds when none of the expressions is evaluated to true. Multiple-child-buscomp-record behavior. All child business component records are used for the comparison and the overall comparison succeeds only if the comparison fails for every one of the records. ■ One Must Match Multiple-value behavior. If the values involved are literal values, the comparison succeeds when at least one value matches. If the values involved are expressions, the comparison succeeds when at least one expression is evaluated to true. This is the same as This Must Match. Multiple-child-buscomp-record behavior. All child business component records are used for comparison and the overall comparison succeeds if the comparison succeeds for at least one of the records. Siebel Business Process Framework: Workflow Guide Version 8.0 11 1
    112. For Developers: Workflow Process Steps ■ About Decision Points ■ All Must Match (Ignore Case) Same as its corresponding counterparts except that string comparisons are case-insensitive. ■ This Must Match (Ignore Case) Same as its corresponding counterparts except that string comparisons are case-insensitive. ■ None Can Match (Ignore Case) Same as its corresponding counterparts except that string comparisons are case-insensitive. ■ One Must Match (Ignore Case) Same as its corresponding counterparts except that string comparisons are case-insensitive. Building Expressions This section describes two common patterns in building expressions: ■ making references to process properties ■ making references to business component fields. Referencing Process Properties The syntax is [&PropName], where PropName is the name of the process property. Example: [&Object Id] like '99-28B1T' Referencing Business Component Fields The syntax is [FieldName], where FieldName is the name of the field. As mentioned above, the business component itself is specified in the Object field of the Expression Builder. Example, for the business component Contact: [First Name] like 'John' Example: Using Expressions for Comparison of Values The example that follows shows how expressions can be used to compare the value of a process property—Object Id—to that of a business component field: Contact.Account Id. Compare To Operation Object Values Expression This Must Match Contact [Account Id] like [&Object Id] About Decision Points Decision Points are a type of step that evaluate one or more defined conditions to determine the next step of a process instance. 112 Siebel Business Process Framework: Workflow Guide Version 8.0
    113. For Developers: Workflow Process Steps ■ About Decision Points The main parts of creating Decision Points for a workflow process are: ■ “Defining a Decision Point” on page 113. ■ “Defining Decision Branches” on page 113. ■ Defining the conditions and values. See “About Conditions and Values for Decision Points” on page 114. Defining a Decision Point You define a Decision Point in the Process Designer in Siebel Tools. To define a Decision Point 1 In the Workflow Processes OBLE in Siebel Tools, select the workflow process for which you would like to define a Decision Point. 2 Right-click and choose Edit Workflow Process. 3 Drag and drop a Decision Point icon from the palette to the canvas. 4 In the Properties window, enter or modify the step name, and then enter a description of the purpose of the Decision point. NOTE: If the Properties window is not showing, select the Decision Point icon, then right-click and select View Properties Window. Continue to “Defining Decision Branches” on page 113 to create the branches for the Decision Point. Defining Decision Branches If you connected the Decision Points to the next steps in the process with connector arrows, as described in “Diagramming a Workflow Process” on page 90, branches are automatically created. If this is the case, modify the branch fields as necessary and then go to “About Conditions and Values for Decision Points” on page 114 for the procedure on defining conditions and values for each branch. To define a Decision branch 1 Drag and drop a connector arrow to the canvas, connecting the Decision Point with the new next step. 2 Click the connector arrow to access its branch properties in the Properties window. NOTE: If the Properties window is not showing, select the connector icon, then right-click and select View Properties Window. 3 Enter or modify the branch name. NOTE: The name of the branch must be unique to the workflow process or you will not be able to commit the record. Siebel Business Process Framework: Workflow Guide Version 8.0 11 3
    114. For Developers: Workflow Process Steps ■ About Business Service Steps 4 Choose a branch type. Type values are described in Table 10 on page 102. CAUTION: Always define a Default branch step in case some work items do not meet any of the conditions you define. 5 Enter any comments. 6 Verify in the Process Designer that the Decision Point branch is connected with a connector arrow to the appropriate next step. The handles of the connector arrow will be red if they are correctly attached to the steps. NOTE: Decision Points can have multiple Decision Point branches. Repeat Step 1 on page 113 through Step 6 for additional branches. For more information, see “About Conditions and Values for Decision Points” on page 114. About Conditions and Values for Decision Points Conditions and values affect the flow of your process execution. Different actions may occur depending on which path is followed. For example, you can define a condition based on the value of a priority field, so that if the priority is equal to “high,” the process execution follows a branch leading to an action that sends an email to a vice president. However, if the priority is equal to “medium,” the email is sent to an engineer. NOTE: A Decision Point evaluates a record’s business component value at the time the workflow process is executed. If the workflow process is triggered by a workflow policy and multiple violations of a policy condition occur within the Workflow Monitor Agent’s action interval, then at the time the workflow process is executed, the Decision Point determines which branch to take based on the current value of the business component field. If the Decision branch criterion is moved from the workflow process level to the workflow policy level, then the policy generates unique events within the defined action interval. In this way, the workflow process is triggered for all violations. For more information, see “Building Expressions with Expression Builder” on page 109. About Business Service Steps Business services allow you to execute predefined or custom actions in a workflow process. Some examples of predefined business services include: ■ Notifications. Notifications can be sent to employees or contacts 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 tasks. You can run a server component task using the Asynchronous or Synchronous Server Requests business service. For a list of some of the most commonly-used predefined business services, see “Predefined Business Services” on page 328. 114 Siebel Business Process Framework: Workflow Guide Version 8.0
    115. For Developers: Workflow Process Steps ■ About Business Service Steps You can use Siebel VB or Siebel eScript to define your own custom business services that you can invoke from a workflow process. CAUTION: Business services invoked from workflow processes cannot include browser scripts; they only work with server scripts. A business service with browser scripts will fail if it is executed from a workflow process on the Siebel Server. You can define business services by navigating to Site Map > Administration - Business Service, or by selecting the business service object in Siebel Tools. The methods and arguments you define in your business service appear in the picklists in the Arguments list applets for the business service. The main parts of creating Business Service steps for a workflow process are: ■ “Defining a Business Service Step” on page 118 ■ “Defining Input Arguments for Business Service Steps” on page 119 ■ “Defining Output Arguments for Business Service Steps” on page 119 You can also enable Business Service steps to support Pass By Reference. For information on the Pass By Reference feature, see “Passing Property Sets by Reference” on page 96. Field Descriptions: Input Arguments for Business Service Steps, Subprocess Steps, and Wait Steps Input arguments allow you to define values that you want to pass to a service method. Many methods require input arguments. Table 12 describes the fields that can be defined for Business Service steps, Subprocess steps, and Wait steps. Table 12. Input Arguments Fields Field Description Possible Value Input For business service steps This field is required. The picklist displays input Argument only: the name of the input arguments existing for the selected business argument. service method. A method argument appears in this picklist if it has been defined as a business service method argument, the Hidden flag is set to FALSE, and the type is input or input/output. Subprocess For subprocess steps only: This field is required. Input the name of the input argument. Siebel Business Process Framework: Workflow Guide Version 8.0 11 5
    116. For Developers: Workflow Process Steps ■ About Business Service Steps Table 12. Input Arguments Fields Field Description Possible Value Type The type of argument. This is a required field. The picklist contains the following choices: ■ Literal ■ Process Property ■ Business Component ■ Expression Value A string value. For Literal and Expression type input arguments. This could be a picklist, depending on the argument selected. String values can only be a maximum of 32,767 characters. Property The name of the business For Process Property–type input arguments. Name process property. Business The name of a business For Business Component–type input arguments. Component component within the Name business object of the business process. Business The name of a field within For Business Component Field–type input Component the business component. arguments. Field Changed Checkmark. Field Descriptions: Output Arguments for Business Service Steps, Subprocess Steps, and Siebel Operation Steps Output arguments are the result of a business service method. Output arguments should be stored in process properties. 116 Siebel Business Process Framework: Workflow Guide Version 8.0
    117. For Developers: Workflow Process Steps ■ About Business Service Steps Table 13 describes the fields that can be defined for Business Service steps, Subprocess steps, and Siebel Operation steps. NOTE: Calculated fields are unavailable as values for input or output arguments. If you want to use a calculated value, use an expression. Table 13. Output Arguments Fields Field Description Possible Value Property The name of the Process This is a required field. Name Property to store the results. This is a picklist of properties that have been defined for the process. For more information about defining process properties, see “Defining Process Properties” on page 96. Type The type or argument. This is a required field. The picklist contains the following choices: ■ Literal ■ Output Argument ■ Business Component ■ Expression Value A string value. For Literal or Expression arguments. Note that string values can only be a maximum of 32,767 characters. Output For business service steps For Output Arguments type. Argument only: the name of the output This is a picklist of output arguments for the argument. selected method. An argument appears in this picklist if it has been defined as a business service method argument, the Hidden flag is set to FALSE, and the type is Output or Input/Output. Subprocess For subprocess steps only: For Output Arguments type. Output the name of the output argument. Siebel Business Process Framework: Workflow Guide Version 8.0 11 7
    118. For Developers: Workflow Process Steps ■ About Business Service Steps Table 13. Output Arguments Fields Field Description Possible Value Business The name of the business For Business Component type. Component component within the Name business object of the business process. Business The name of a field within For Business Component Field type. Component the business component. NOTE: Business component fields based on multi- Field value groups cannot be selected as values for input or output arguments. If you want to use a field based on a multi-value group, you need to define a business component for the field and link it to the appropriate business object. See Configuring Siebel Business Applications for more information. Defining a Business Service Step You define a Business Service step in the Process Designer in Siebel Tools. To define a Business Service step 1 In the Workflow Processes OBLE in Siebel Tools, select the workflow process for which you would like to define a Business Service step. 2 Right-click and choose Edit Workflow Process. 3 Drag and drop a Business Service step icon from the palette to the canvas. 4 In the Properties window, enter or modify the step name, and then enter a description of the purpose of the Business Service step. NOTE: If the Properties window is not showing, select the step icon, then right-click and select View Properties Window. 5 In the Business Service Name field, select the name of the service to be invoked from the picklist. The picklist contains the business services defined in Siebel Tools or the Siebel client. See Integration Platform Technologies: Siebel Enterprise Application Integration for information on creating customer-defined services. 6 In the Business Service Method field, select the method for invoking the service. The choices available for this field depend on the service you select in Step 5. 7 If you need to define input arguments, continue to “Defining Input Arguments for Business Service Steps.” 8 If you need to define output arguments, continue to “Defining Output Arguments for Business Service Steps” on page 119. 118 Siebel Business Process Framework: Workflow Guide Version 8.0
    119. For Developers: Workflow Process Steps ■ About Business Service Steps Defining Input Arguments for Business Service Steps You define input arguments in the Process Designer in Siebel Tools. To define input arguments for a Business Service step 1 With the appropriate Business Service step selected in the Process Designer canvas, view the step’s child items in the MVPW. 2 In the Input Arguments tab of the MVPW, right-click and choose New Record. 3 Complete the fields. For field descriptions, see “Field Descriptions: Input Arguments for Business Service Steps, Subprocess Steps, and Wait Steps” on page 115. Defining Output Arguments for Business Service Steps Output arguments allow you to store a resulting value in a process property. To define output arguments for a Business Service step 1 With the appropriate Business Service step selected in the Process Designer canvas, view the step’s child items in the MVPW. 2 In the Output Arguments tab, right-click and choose New Record. 3 Complete the fields. For field descriptions, see “Field Descriptions: Output Arguments for Business Service Steps, Subprocess Steps, and Siebel Operation Steps” on page 116. NOTE: Business services, methods, and arguments all have Display Name and Hidden properties in Siebel Tools. For a business service, method, or argument to be displayed on any picklist, the Hidden flag for the object must be set to FALSE. For more information, see “Considering Business Objects and Business Services When Planning Workflow Processes” on page 57. Enabling the Pass By Reference Feature for Business Services That Support It The new _SupportsPassByRef_ user property is available for use on only a set list of Siebel business services. You cannot add this user property to custom business services. If, in a workflow process, you configure a Business Service step that is not marked for Pass By Reference, the Workflow engine returns an error. In order for the Workflow engine to honor Pass By Reference, the business service must have the Business Service User Prop setting to TRUE and the Business Service step in the workflow must be marked for Pass By Reference. CAUTION: Use of the Pass By Reference feature is not supported for any custom business services. For more information on using the Pass By Reference feature, see “Enabling a Subprocess to Support Pass By Reference” on page 123. Siebel Business Process Framework: Workflow Guide Version 8.0 11 9
    120. For Developers: Workflow Process Steps ■ About Subprocess Steps About Subprocess Steps A Subprocess step allows you to invoke a separate process within a process. A process definition can have one or more Subprocess steps. The main parts of creating a Subprocess step for a workflow process are: ■ “Defining a Subprocess Step” on page 122 ■ “Defining Input Arguments for Subprocess Steps” on page 122 ■ “Defining Output Arguments for Subprocess Steps” on page 123 ■ “Defining Recipients for Subprocess Steps” on page 123 You can also enable Subprocess steps to support Pass By Reference. For information on the Pass By Reference feature, see “Passing Property Sets by Reference” on page 96. To use Pass By Reference with subprocesses, see “Enabling a Subprocess to Support Pass By Reference” on page 123. Field Descriptions: Step Recipients Table 14 describes the fields that can be defined for step recipients. Table 14. Step Recipients Fields Field Description Possible Value Recipient The type of recipient. This value is fixed as “User” and cannot be Type Code changed. Value Type The source from which the recipient This field is a picklist with the following Code value comes. values: ■ Name ■ Business Component ■ Process Property ■ Expression Recipient The name of the recipient. This field Choose one name from the list of all users Name is a pick applet which displays the available in the database. first name, last name, and login name of all users in the database. NOTE: Complete this field if the Value Type Code is set to Name. Business The name of the business Choose one business component. Component component. Name NOTE: Complete this field if the Value Type Code is set to Business Component. 120 Siebel Business Process Framework: Workflow Guide Version 8.0
    121. For Developers: Workflow Process Steps ■ About Subprocess Steps Table 14. Step Recipients Fields Field Description Possible Value Business The name of the business Choose one business component field. Component component field. Field NOTE: Complete this field if the Value Type Code is set to Business Component. Process The name of the process property. Choose one process property. Property NOTE: Complete this field if the Name Value Type Code is set to Process Property. Expression If the recipient value is derived from The expression from which the recipient an expression, the expression is value is derived. entered in this field. NOTE: Complete this field if the Value Type Code is set to Expression. Field Descriptions: Subprocess Steps Table 15 describes the fields in which you enter data to define Subprocess steps. Table 15. Subprocess Step Fields Field Description Possible Value Step The name of the subprocess step. A descriptive name that is: ■ Consistent with your overall naming strategy ■ Meaningful to the process designer Type The type of step. This value is automatically entered when you create the step on the Process Designer view. Read-only. Description A text narrative describing the Free-form text. purpose of the subprocess. Subprocess The name of the process to run. This value is selected from a picklist of defined workflow processes. NOTE: In order for the subprocess to appear in this picklist of defined workflow processes, the subprocess must have a status of Complete. Siebel Business Process Framework: Workflow Guide Version 8.0 12 1
    122. For Developers: Workflow Process Steps ■ About Subprocess Steps Table 15. Subprocess Step Fields Field Description Possible Value Created By The name of the person who creates This value is automatically entered based the step. on the log in name of the user. Created The date that the step is created. This value is automatically entered. Defining a Subprocess Step Before you define a Subprocess step, you must define the workflow process you will call with the step. To define a Subprocess step 1 In the Workflow Processes OBLE, verify that the workflow process that is to be called as a subprocess is defined, or create it. 2 Select the workflow process to which you want to add a Subprocess step. 3 Right-click and select Edit Workflow Process. 4 Drag and drop a Subprocess icon from the palette to the canvas. 5 In the Properties window, enter or modify the step name, and then enter a description of the purpose of the Subprocess step. NOTE: If the Properties window is not showing, select the step icon, then right-click and select View Properties Window. 6 In the Subprocess Name field, select the process that the Subprocess step will call. 7 If you need to define input arguments for this subprocess, continue to “Defining Input Arguments for Subprocess Steps” on page 122. If you need to define output arguments for this subprocess, continue to “Defining Output Arguments for Subprocess Steps” on page 123. NOTE: Once a Subprocess step has been created within a workflow, to directly edit the corresponding subprocess, you can double-click the Subprocess step icon to reach the design canvas for that subprocess. You can also right-click the Subprocess step icon and select Edit Sub Process from the context menu. Defining Input Arguments for Subprocess Steps Input arguments allow you to populate process properties in the subprocess. For example, if you want to pass the Object Id from the main process to the subprocess, you would do this through input arguments. If the subprocess is based on a different business object, you must pass the relevant row ID of the target object as the subprocess Object Id Process Property. 122 Siebel Business Process Framework: Workflow Guide Version 8.0
    123. For Developers: Workflow Process Steps ■ About Subprocess Steps For field descriptions, see “Field Descriptions: Input Arguments for Business Service Steps, Subprocess Steps, and Wait Steps” on page 115.To define input arguments for a Subprocess step 1 With the appropriate Subprocess step selected in the Process Designer canvas, view the step’s child items in the MVPW. 2 In the Input Arguments tab, right-click and choose New Record. 3 Complete the fields. For field descriptions, see “Field Descriptions: Input Arguments for Business Service Steps, Subprocess Steps, and Wait Steps” on page 115. NOTE: The Object Id passed to a subprocess should be null, not the parent’s Object Id, when the subprocess will create a child object. Defining Output Arguments for Subprocess Steps Output arguments allow you to store a resulting value in a process property. To define output arguments for a Subprocess step 1 With the appropriate Subprocess step selected in the Process Designer canvas, view the step’s child items in the MVPW. 2 In the Output Arguments tab, right-click and choose New Record. 3 Complete the fields. For field descriptions, see “Field Descriptions: Output Arguments for Business Service Steps, Subprocess Steps, and Siebel Operation Steps” on page 116. Defining Recipients for Subprocess Steps 1 With the appropriate Subprocess step selected in the Process Designer canvas, view the step’s child items in the MVPW. 2 In the Recipients tab, right-click and choose New Record. 3 Complete the fields. For field descriptions, see “Field Descriptions: Step Recipients” on page 120. Enabling a Subprocess to Support Pass By Reference You may find that in some instances, subprocess methods that you use must modify large amounts of data. This requires them to copy large quantities of data, which negatively impacts performance and scalability of these method invocations. In such cases, it makes sense to use the Pass By Reference feature so that a pointer to the data is passed, but not the data itself. Siebel Business Process Framework: Workflow Guide Version 8.0 12 3
    124. For Developers: Workflow Process Steps ■ About Siebel Operation Steps For example, you have added a Subprocess step to a workflow process. You want to pass a large property set to this Sub Process step. This example workflow is shown in Figure 24. In this example, you want to pass the property set that the workflow creates in the “Create Siebel Message” step to the “11i Process Order” step. Figure 24. Example Workflow for Which Pass By Reference with a Subprocess Would Be Useful When you configure a subprocess to support Pass By Reference, you are free from the need to map the output argument in the subprocess step for the hierarchical properties that you are passing in. The subprocess overwrites the passed input hierarchical argument. Optionally, you can have the subprocess modify the passed input hierarchical argument. To enable a subprocess to support Pass By Reference 1 In the Workflow Processes list, select the workflow process that is your subprocess. 2 In the Properties window, set the Workflow Process attribute Pass By Ref Hierarchy Argument to TRUE. In the Worfklow Process List list, the Pass by Ref Hierarchy property is now checked for the child workflow. About Siebel Operation Steps Siebel Operation steps include operations such as Insert, Update, or Query. These steps are performed on business components. After you define a Siebel Operation step, you can use the Multi Value Property Window to define any field values for the step. For the Update step, you can use the Search Spec Input Arguments tab on the MVPW to define which records you want to update. Information about Siebel Operation steps is organized as follows: ■ “Defining a Siebel Operation Step” on page 125. ■ “Defining Fields for a Siebel Operation Step” on page 126 ■ “Defining Siebel Operation Search Specifications” on page 126 ■ “Defining Siebel Operation Step Output Arguments” on page 127 ■ “Field Descriptions: Search Specifications” on page 128 ■ “Updating a Field Based on a Multi-Value Group” on page 129 124 Siebel Business Process Framework: Workflow Guide Version 8.0
    125. For Developers: Workflow Process Steps ■ About Siebel Operation Steps Defining a Siebel Operation Step NOTE: After executing an Insert step, the Siebel Operation Object Id process property automatically stores the row ID of the record that was created. You can define Siebel Operation steps for any business component associated with the business object selected for the process. If you want to update a business component not associated with the business object, you can either invoke a subprocess or associate the business component to the business object using Siebel Tools. All fields are available for update and insert except fields based on multi-value groups and calculated fields. If you want to update a field based on a multi-value group, you can define a business component for the field and link the business component to the object using Siebel Tools. An example is an update to an Account Team. Account Team is based on a multi-value group, so it cannot be updated by selecting the Account business component. However, you can create a business component called “Account Team” and then associate it with the Account business object using Siebel Tools. You could then select Account Team as the business component to update with the Siebel Operation step. To define a Siebel Operation step 1 Select the appropriate workflow process in the Workflow Processes OBLE. 2 Right-click and choose Edit Workflow Process. 3 Drag and drop the Siebel Operation Step icon from the palette to the canvas. 4 In the Properties window, enter a name for the step, and a description of the purpose of the step. NOTE: If the Properties window is not showing, select the step icon, then right-click and select View Properties Window. 5 In the Operation field, select the type of operation. The available choices are: ■ Insert ■ Update ■ Delete ■ Query ■ NextRecord ■ PrevRecord ■ QueryBiDirectional NOTE: Verify that updates or inserts of fields that have dependencies are valid fields. For example, if you have a service request process and your process is updating the area and sub- area fields, you will need to make sure that the values selected for the subarea field are valid for that associated area. 6 In the Business Component field, select the name of the business component. 7 If you need to define fields for this Siebel operation, continue to “Defining Fields for a Siebel Operation Step” on page 126. Siebel Business Process Framework: Workflow Guide Version 8.0 12 5
    126. For Developers: Workflow Process Steps ■ About Siebel Operation Steps 8 If you need to define search specifications for this Siebel operation, continue to “Defining Siebel Operation Search Specifications” on page 126. 9 If you need to define output arguments for this Siebel operation, continue to “Defining Siebel Operation Step Output Arguments” on page 127. Defining Fields for a Siebel Operation Step NOTE: If the Siebel Operation step will perform an Insert operation, make sure that all required fields have been added to the Siebel Operation step. System fields and predefaulted fields are automatically populated. To define fields for a Siebel Operation step 1 With the appropriate Siebel Operation step selected in the Process Designer, view the step’s child properties in the MVPW. 2 In the Field Input Arguments tab, right-click and choose New Record. 3 In the Field Name field, select the name of the field to be updated. 4 In the Type field, choose an input argument type. The choices available are: ■ Literal ■ Process Property ■ Business Component ■ Expression 5 If the field type selected is Literal, enter a value. 6 If the field type selected is Process Property, select a property name. 7 If the field type selected is Business Component, select the applicable business component name and business component field. 8 If the field type selected is Expression, enter the expression in the value field. 9 In the Comments field, enter any appropriate comments. Defining Siebel Operation Search Specifications You can define search specifications to identify the specific data on which to perform the operation. Search specifications are used when the business component has multiple records and you want to perform the operation on only some of the records. For example, if you have a process for the Account object and you want to update only those Opportunities with a lead quality of Poor, you would define search specifications to access only those Opportunities. 126 Siebel Business Process Framework: Workflow Guide Version 8.0
    127. For Developers: Workflow Process Steps ■ About Siebel Operation Steps To define Siebel operation search specifications 1 With the appropriate Siebel Operation step selected in the Process Designer, view the step’s child properties in the MVPW. 2 In the Search Spec Input Arguments tab, right-click and choose New Record. 3 In the Type field, select a search specification type. The choices available are: ■ Literal ■ Expression. A literal search specification type is a static string where the runtime value is the same as the one defined in the Process Designer whereas an expression search specification type is a Siebel expression (often based on other runtime variables) where the runtime value can only be determined at runtime by evaluating the expression. 4 In the Search Specification field, enter search specifications. CAUTION: Define your Siebel operation search specification as efficiently as possible, so that only the smallest necessary set of rows will match. Search specifications that select a large set of rows could cause severe performance degradation. 5 If the search specification type is Expression, select the applicable business component name. NOTE: A search specification of type Literal is executed as written. For example, [Status] LIKE ‘*Open*’. A search specification of type Expression allows you to construct a search specification dynamically. For example, “[Contact ID] = ‘ ” + [&New ID] + “ ‘ ” will be evaluated to [Contact ID] = ‘1 - ABC’ if the New ID process property is 1 - ABC at run time. Both sides of an expression can reference business component fields. The Filter Business Component defines the business component referenced on the left hand side, and the Expression Business Component defines the business component referenced on the right hand side. For example, in the following configuration: Filter Business Component = Account Expression Business Component = Contact Expression = "[Id] = [Account Id]" The expression evaluates as follows: “[Account.Id] = [Contact.Account Id]” Defining Siebel Operation Step Output Arguments Output arguments allow you to store a resulting value in a process property. This value can then be passed to other processes. To define output arguments for a Siebel Operation step 1 With the appropriate Siebel Operation step selected in the Process Designer, view the step’s child properties in the MVPW. 2 In the Output Arguments tab, right-click and choose New Record. Siebel Business Process Framework: Workflow Guide Version 8.0 12 7
    128. For Developers: Workflow Process Steps ■ About Siebel Operation Steps 3 In the Property Name field, select the property name from the picklist. 4 In the Type field, choose an output argument type. The choices available are: ■ Literal ■ Output Argument ■ Expression ■ Business Component 5 If the output argument type you chose is ■ Literal, then enter a value. ■ Output Argument, then enter the argument. ■ Business Component, then select the applicable business component name and business component field. 6 In the Comments field, enter any appropriate comments. Field Descriptions: Search Specifications Table 16 describes the fields that can be defined for Siebel operation search specifications. Table 16. Search Specification Fields Field Description Expression Business If you entered Expression in the Type field, enter the name of the Component business component that will evaluate 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 search specification becomes: [Due Date] < '07/04/2001 18:51:26' Filter Business Component Enter the name of the business component that will provide the group of records on which you will perform your search. Search Specification If you entered Literal in the Type field, enter a literal value in the form of an expression. For example, “= 100”. If you entered Expression in the Type field, enter an expression such as [Status] LIKE ‘*Open*’. The expression will be evaluated by the Expression business component you specify. Type Required. Choose the type of value on which to base your search: Literal or Expression. 128 Siebel Business Process Framework: Workflow Guide Version 8.0
    129. For Developers: Workflow Process Steps ■ About Siebel Operation Steps Table 16. Search Specification Fields Field Description Comments Enter a text description of the purpose of the search. Changed Checkmark indicates a changed search specification. Updating a Field Based on a Multi-Value Group Calculated fields cannot be updated using Siebel Operation steps because typically they require values from other business component fields. Use expressions to perform calculations. The Object Id for the process is automatically passed to Siebel Operation steps. Because this automatic passing occurs, you do not need to enter a search specification value unless you are updating child records. For example, if you have a process based on the service request object and you want to update the service request, you do not need to enter a search specification. However, if you want to update activities for the service request, you may want to enter a search specification to query the specific activity that you want to update. Otherwise, the update step updates all activities for the service request. The Object Id cannot be null if you are executing a Siebel operation, unless you are inserting into the primary Object Id. If the process has no Object Id, the Siebel Operation step returns an error. When performing a query operation for child records, the Siebel Operation Object Id process property field will return the row ID if one record matches, a “*” if multiple records match, and Null/no value if no records match. NOTE: The only ability provided is to return a row ID of a matching row. The Insert/Update operation updates the Siebel Operation Object Id process property field of the record’s row ID. NOTE: The Workflow Policy programs and Siebel Operation steps use different object layers to update data. For example, you may have a Workflow Policy that calls a Workflow Policy Program to update a Service Request Record. This method goes through the Data Layer in which State Model does not apply. Conversely, if you have a Workflow Policy that calls a Workflow Process Action and in the Workflow Process, you have defined a Siebel Operation step to update a Service Request Record, this method goes through the Object Layer in which the State Model does apply. Traversing a Record Set This document describes the Next Record and Previous Record features of Siebel Operation step and the design and run-time enhancements needed to implement this. Using the Next Record and Previous Record features of the Siebel Operation step, you can navigate through the records of a child business component of the business object associated with the workflow. Siebel Business Process Framework: Workflow Guide Version 8.0 12 9
    130. For Developers: Workflow Process Steps ■ About Wait Steps In this release, new operations—Next Record, Previous Record, and QueryBiDirectional—have been added to the Siebel Operation step in the Process Designer in addition to the original actions (Update, Query, and Insert). The Siebel Operation - Next Record operation changes the active row of the target business component to the next record in the current workset. The Siebel Operation - Previous Record operation changes the active row to the previous record. You must perform a query on a target business component before using subsequent Next/Previous Record operations. If the workflow is traversing active records or if your workflow uses the PreviousRecord operation, query bidirectionally. Otherwise, use the standard Siebel query operation. NOTE: These new actions cannot be used to navigate through the primary business component records. You can use the Next Record and Previous Record operations to loop through all the records of a child business component. An output argument called “NoMoreRecords” has been added to the Siebel Operation business service, and is set to TRUE when there are no more records to navigate—either in the forward direction for Next Record or in the backward direction for Previous Record. This output argument can be assigned to a process property, and in conjunction with a Decision Point, can be used to exit the loop after navigating through all the records. To support this output argument, the Process Designer now shows an Output Argument column in the output arguments tab for the Siebel Operation step. In addition, an output argument called NumAffRows (Number of Affected Rows) exists for Query and Update operations. In the case of Query, this output argument gives the number of rows returned as a result of the query. In the case of Update, this output argument indicates the number of rows updated. About Wait Steps Wait steps allow you to suspend process execution for a specific period of time or until a specific event occurs. Workflow administrators can specify to pause a process instance in units of seconds, minutes, hours, or days. In addition, administrators can specify a service calendar to account for business hours and days when waiting a specified duration. If a workflow process includes a Wait step, by default it is persisted. For information on how to create a Wait step for a workflow process are, see “Defining a Wait Step” on page 130. Defining a Wait Step You can define a Wait step to pause a process instance. To define a Wait step 1 Select the appropriate workflow process in the Workflow Processes OBLE. 2 Right-click and choose Edit Workflow Process. 3 Drag and drop the Wait step icon from the palette to the canvas. 130 Siebel Business Process Framework: Workflow Guide Version 8.0
    131. For Developers: Workflow Process Steps ■ About User Interact Steps 4 In the Properties window, enter a name for the step, and a description of the purpose of the step. NOTE: If the Properties window is not showing, select the step icon, then right-click and select View Properties Window. 5 With the Wait step icon selected in the canvas, view the step’s child properties in the MVPW. 6 In the Input Arguments tab, enter input arguments. See “To define input arguments for a Wait step” on page 131. NOTE: For durations greater than 60 seconds, specify minutes or a greater unit of measure so that business component data is refreshed. Workflow is resumed from Workflow Process Manager when units of minutes or higher are specified. Wait steps with durations measured in anything other than seconds are automatically persisted. To define input arguments for a Wait step 1 In the Input Arguments tab of the MVPW, right-click and choose New Record. 2 In the Property Name field, select the property name from the picklist. 3 In the Type field, select an input argument type from the picklist. The choices available are: ■ Literal ■ Input Argument ■ Expression ■ Business Component 4 If the input argument type you chose is ■ Literal, then enter a value. ■ Input Argument, then enter the argument. ■ Business Component, then select the applicable business component name and business component field. 5 In the Comments field, enter any appropriate comments. About User Interact Steps The User Interact step allows application designers to design and configure the flow of Siebel views within an application. Siebel Workflow guides end users through a specified flow of Siebel views based on the end users’ actions, or executes a specified set of actions. This flow can be modified as business rules change. The User Interact step has the following behaviors: ■ The User Interact step brings up the required view. The User Interact step runs in the user session. It sends a request to the Siebel Web Engine to build the view. NOTE: 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. You also cannot combine a UserInteract step with the invocation of a task. Siebel Business Process Framework: Workflow Guide Version 8.0 13 1
    132. For Developers: Workflow Process Steps ■ About User Interact Steps ■ The User Interact step waits for a run-time event to resume processing. It waits in the memory of the user session. In cases where there is no run-time event defined, the workflow process will continue to the end. ■ If, after a User Interact step, the end user manually navigates out of the view, the workflow process remains in the memory of the user session. The process is deleted when the user session is terminated or when another workflow process is instantiated in the same user session. NOTE: Workflows running in the Workflow Process Manager server component should not contain User Interact steps. That is, if the workflow is running in background mode or in batch mode, it cannot include User Interact steps. If the Workflow Process Manager encounters a User Interact step, an error will result. The User Interact step has been enhanced to take process properties as input arguments. In this way, you can dynamically set view names as you design your interactive workflow processes. The view name property is set in the View field (an unbounded picklist) of the User Interact step. For more information on User Interact steps, see the following sections: ■ “Defining a User Interact Step” on page 132 ■ “Defining User Interact Next Step Branches” on page 133 Defining a User Interact Step You define a User Interact step in the Process Designer in Siebel Tools. To define a User Interact step 1 Select the appropriate workflow process in the Workflow Processes OBLE. 2 Right-click and choose Edit Workflow Process. 3 Drag and drop the User Interact step icon from the palette to the canvas. 4 With the User Interact step selected, view the step’s properties in the Properties window. NOTE: If the Properties window is not showing, select the step icon, then right-click and select View Properties Window. 5 In the Properties window, enter a name for the step, and a description of the purpose of the step. 6 From the picklist in the User Interact View field, select the view name to which you would like to navigate the user. Only views associated with the business object will be available in the picklist. 7 In the Description field, enter a description of the purpose of the User Interact step. NOTE: The User Interact step is only supported if the process is invoked through a script or run-time event and the process is run locally in the application object manager. 132 Siebel Business Process Framework: Workflow Guide Version 8.0
    133. For Developers: Workflow Process Steps ■ About User Interact Steps Defining User Interact Next Step Branches User Interact steps can have multiple Next Step branches. Use the following procedure to define each branch. NOTE: In this release, Workflow processes do not support parallel processing. Make sure that you define your conditions so that only one branch is valid. If an object matches the conditions in multiple branches, it will try to take all branches one at a time in a random order until the first End step is reached. To define a Next Step branch 1 From the Process Designer palette, drag and drop the appropriate step icon for the next step in the process to the canvas. NOTE: If you have already designed the entire workflow process, including connector arrows, click the connector arrow attached to the User Interact step, then proceed to step 4. 2 Drag and drop a connector arrow to the canvas, connecting the User Interact step with the new next step. 3 With the connector selected in the canvas, view the Properties window for the branch. NOTE: If the Properties window is not showing, select the branch icon, then right-click and select View Properties Window. 4 In the Name field, enter or modify the branch name. NOTE: The name of the branch must be unique to the workflow process or you will not be able to commit the record. 5 In the Type field, select a branch type. Type values are described in Table 10 on page 102. CAUTION: Always define a Default branch step in case some work items do not meet any of the conditions you define. 6 In the Comments field, enter comments, if applicable. About Conditions and Values for User Interact Next Step Branches Conditions and values affect the flow of your process execution. Different actions may occur depending on which path is followed. For example, you can define a condition based on the value of a priority field, so that if the priority is equal to High, the process execution follows a branch leading to an action that sends an email to a vice president. However, if the priority is equal to Medium, the email is sent to an engineer. For more information, see “Building Expressions with Expression Builder” on page 109. Siebel Business Process Framework: Workflow Guide Version 8.0 13 3
    134. For Developers: Workflow Process Steps ■ About Task Steps Creating Substitute View Names with Process Properties You can associate view names with process properties so that they can be set dynamically at run time. You do this by assigning a view name to the run-time value of a process property. To associate a view name with a process property to set view names dynamically at run time ■ In the Interact Navigate View field 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 Task Steps A Task step is similar to a Subprocess step in that it represents a container for a further set of steps below the level of the steps of its own workflow. Task steps launch tasks from within a workflow process. NOTE: A workflow process that launches a task must be a long-running workflow; its Mode must be set to Long Running Flow. Once a workflow calls a task, the task is visible in the end user’s Inbox. Until the end user completes the task, the workflow is in a waiting state. Once the task is complete, the workflow moves to its next step, continuing its execution. The main parts of creating a Task step for a workflow process are: ■ Defining the Task step’s input arguments, including associating the Task step with a task flow. NOTE: In order to create the definition for a Task step in a workflow process, you must already have created the relevant task flow in the Task Editor. For information on creating tasks, see Siebel Business Process Framework: Task UI Guide. ■ Defining the Task step’s output arguments. ■ Assigning a recipient for the task. Once you have created a Task step in the Process Designer and you have associated the Task step with a task flow, you can open the Task Editor by double-clicking the task step on the Process Designer canvas. Defining a Task Step You define a Task step in the Process Designer in Siebel Tools. To define a Task step 1 In Siebel Tools, in the Object Explorer, click the Workflow Process object. 134 Siebel Business Process Framework: Workflow Guide Version 8.0
    135. For Developers: Workflow Process Steps ■ About Task Steps 2 In the OBLE, select the workflow process to which the new Task step will be added. NOTE: If the status of the workflow process is Completed or Not In Use, click the Revise button in the WF/Task Editor toolbar. 3 Right-click on the workflow process, and from the context menu, choose Edit Workflow Process to open it in the Process Designer. The Palette and Property windows are launched along with the Process Designer, and the workflow is opened in an editable mode. NOTE: If the Palette does not show, you can launch it by selecting View > Windows > Palette in the Tools menu. If the Properties window does not show, you can launch it by selecting View > Windows > Properties Window from the Tools menu. 4 From the Palette, drag and drop the Task step icon to the canvas at the appropriate spot within the workflow. 5 Using connectors, join the newly added Task step to other steps in the workflow process. 6 Select the Task step on the canvas. 7 In the Properties window, which shows the properties of the Task step selected, change the name of the Task step to a name of your choice. The default name assigned is “Task” + <integer>. 8 In the Task Name field, use the picklist to select a task flow to associate with the Task step added to the workflow. 9 (Optional) Using the Properties window, enter comments and a description for the Task step. 10 In the Properties window, make sure the Inactive property is set to FALSE. To define Task Step input arguments 1 In the Multi Value Property Window, select the Input Arguments tab. 2 Add input arguments to the Task step. a In the Input Arguments tab, right-click and select New Record. b From the dropdown picklist of the Task Input field, pick the name of a property to use as an input argument. c Complete the fields for the new property record. Sequence Type Value Property Name Siebel Business Process Framework: Workflow Guide Version 8.0 13 5
    136. For Developers: Workflow Process Steps ■ About Task Steps Business Component Name Business Component Field 3 Add additional input arguments as necessary, repeating Step 2. For more information, see details on the Task Step IO Arguments child object in Siebel Business Process Framework: Task UI Guide. To define Task Step output arguments 1 In the Multi Value Property Window, select the Output Arguments tab. 2 Add output arguments to the Task step. a In the Output Arguments tab, right-click and select New Record. b From the dropdown picklist of the Property Name field, pick the name of a property to use as an output argument. c Complete the fields for the new property record. Sequence Type Value Task Output Business Component Name Business Component Field 3 Add additional output arguments as necessary, repeating Step 2. For more information, see details on the Task Step IO Arguments child object in Siebel Business Process Framework: Task UI Guide. To assign a recipient to the Task step 1 In the Multi Value Property Window, select the Recipients tab. 2 Add recipients to the Task step. a In the Recipients tab, right-click and select New Record. 136 Siebel Business Process Framework: Workflow Guide Version 8.0
    137. For Developers: Workflow Process Steps ■ About Stop Steps b Complete the fields for the new recipient record. Name Recipient Type Code Value Type Code Recipient Name Business Component Name Business Component Field Process Property Name Expression Business Object Module 3 Add additional recipients as necessary, repeating Step 2. About Stop Steps Stop steps are used to raise an error to the user and terminate the workflow process instance. The main parts of creating a Stop step for a workflow process are: ■ Define a Stop step. See “Defining a Stop Step” on page 138. ■ Define input arguments for the Stop step. See “Defining Stop Step Input Arguments” on page 138. Table 17 describes how the Stop step is handled, depending on how it is called and in which object manager it is running. Table 17. How Workflow Process Manager Handles Stop Steps Stop Step Conditions Results Workflow policy calls a Workflow Process Manager: process that contains a ■ Exits Stop step. ■ Writes an error message to the log file. Siebel Business Process Framework: Workflow Guide Version 8.0 13 7
    138. For Developers: Workflow Process Steps ■ About Stop Steps Table 17. How Workflow Process Manager Handles Stop Steps Stop Step Conditions Results A script or run-time event ■ Process is running in the Workflow Process Manager: calls a process that Workflow Process Manager ■ Writes an error message to the contains a Stop step. object manager. log file. ■ Process is running in the Workflow Process Manager: application object manager. ■ Flags an error message to the user. Defining a Stop Step It is recommended that the Stop step be used only in workflow processes invoked from a script. To define a Stop step 1 Select the appropriate workflow process in the Workflow Processes OBLE. 2 Right-click and choose Edit Workflow Process. 3 Drag and drop the Stop step icon from the palette to the workspace. 4 In Properties window, enter a name for the step, and a description of the purpose of the step. NOTE: If the Properties window is not showing, select the step icon, then right-click and select View Properties Window. 5 In the Error Code field, select an error code. NOTE: To define a custom error message, select an error code starting with WF_ERR_CUSTOM. The error message displayed will be %1. To define the text of the custom error message, enter an input parameter with the name %1, and then enter the text of the message in the value field for input arguments. 6 In the Error Message field, enter an error message. 7 If you need to define input arguments for this step, continue to “Defining Stop Step Input Arguments” on page 138. Defining Stop Step Input Arguments NOTE: No picklist is available for Input Argument Name. The input arguments for a Stop step are the substitution variables in the error message. Substitution variables are identified by a “%”. To define the substitution value, enter the substitution variable in the input argument name, such as “%1”. 138 Siebel Business Process Framework: Workflow Guide Version 8.0
    139. For Developers: Workflow Process Steps ■ About End Steps To define input arguments for a Stop step 1 In the canvas, select the Stop step and view its child properties in the MVPW. 2 In the Input Arguments tab, right-click and choose New Record. 3 Enter a name for the input argument. This should be the substitution variable appearing in the error message. 4 Choose an input argument type. The choices available are: ■ Literal ■ Process Property ■ Expression ■ Business Component 5 If the input argument type selected is Literal, enter a value. 6 If the input argument type is Process Property, select a property name and a property data type. 7 If the input argument type is Business Component, select the applicable business component name and business component field. 8 If the input argument type is Expression, enter the expression in the value field. 9 In the Comments field, enter any appropriate comments. About End Steps An End step specifies when a process instance is finished. It also provides one last chance to store output arguments to a process property. Each workflow process definition must have at least one End step. For more information, see “Defining an End Step” on page 139. NOTE: An important difference between the Stop step and the End step is that the Stop step sets the workflow state to In Error while the End step sets the workflow state to Completed. This is important to keep in mind when calling a workflow process using Workflow Monitor Agent. If the WorkMon parameter Ignore Errors is set to False, a workflow process that encounters a Stop step will cause the WorkMon to exit with error. If the workflow process encounters an End step, WorkMon will not exit with error. Defining an End Step You define an End step in the Process Designer in Siebel Tools. To define an End step 1 Select the appropriate workflow process in the Workflow Processes OBLE. 2 Right-click and choose Edit Workflow Process. Siebel Business Process Framework: Workflow Guide Version 8.0 13 9
    140. For Developers: Workflow Process Steps ■ About End Steps 3 Drag and drop the End step icon from the palette to the canvas. 4 With the End step icon selected, view the step’s properties in the Properties window. NOTE: If the Properties window is not showing, select the step icon, then right-click and select View Properties Window. 5 In the Properties window, enter a name for the step, and a description of the purpose of the step. 6 See “To define output arguments for an End step” on page 140 to enter output arguments. Output arguments allow you to store a resulting value in a process property. This value can then be passed to other processes. To define output arguments for an End step 1 Select the End step and view its child properties in the MVPW. 2 In the Output Arguments tab, right-click and choose New Record. 3 Select the property name from the picklist. 4 Choose an output argument type. The choices available are: ■ Literal ■ Expression ■ Business Component ■ Output Argument 5 If the output argument type selected: ■ Literal, then enter a value. ■ Expression, then enter the expression in the Value field. ■ Business Component, then select the applicable business component name and business component field. ■ Output Argument, then enter the argument. 6 In the Comments field, enter any appropriate comments. 140 Siebel Business Process Framework: Workflow Guide Version 8.0
    141. 7 For Developers: Understanding How Workflow Processes Are Designed This chapter describes the ways in which workflow processes operate. This chapter is divided as follows: ■ “About Workflow Modes” on page 141 ■ “Building Long-Running Workflow Processes” on page 145 ■ “Building Interactive Workflow Processes” on page 146 ■ “Using Workflow Persistence” on page 154 ■ “Handling Events” on page 155 ■ “Workflow and Global Implementations” on page 159 ■ “Handling Errors” on page 161 ■ “Recovering Workflow Processes” on page 164 ■ “Invoking Workflow Processes” on page 165 About Workflow Modes Siebel Business Process Designer has four processing-mode types that characterize run-time behavior. A workflow process’s mode is set using the Workflow Mode field in Siebel Tools, in the Workflow Processes list editor (and in its Properties window). The workflow modes are as follows: ■ 7.0 Flow. The 7.0 workflow process provides backward compatibility for existing Siebel 7 (pre- 7.7) workflows. If you have existing workflows and you upgrade to Siebel 7.7, these existing workflows become 7.0 workflows by default. Upgrading pre-7.7 workflows to Siebel 8 follows the same rule, because pre-7.7 workflows must first be upgraded to 7.7 workflows before the upgrade to Siebel 8. For more information on the 7.0 Flow mode, see “About 7.0 Workflow Processes” on page 143. ■ Long Running Flow. The long-running workflow process is a persistent workflow that can last for hours, days, or months. For more information, see “About Long-Running Workflow Processes” on page 143. ■ Interactive Flow. The interactive workflow process navigates the user across Siebel views and runs in the user session. For more information, see “About Interactive Workflow Processes” on page 144. Siebel Business Process Framework: Workflow Guide Version 8.0 14 1
    142. For Developers: Understanding How Workflow Processes Are Designed ■ About Workflow Modes ■ Service Flow. The service workflow process executes a set of operations. A service workflow completes a unit of work from start to finish. For more information, see “About Service Workflow Processes” on page 144. NOTE: Existing pre-7.7 workflow processes are set to a workflow mode of 7.0 Flow by default. All new workflows (that is, all workflows not existing in a release prior to 7.7) should be categorized as long-running, interactive, or service flows. Newly created workflows are automatically set to the Service Flow type. Workflow Mode for Workflows that Involve Both a Wait Step and a User Interact Step Any workflow process that includes User Interact steps is an interactive workflow and should have its mode set to Interactive Flow. Such a flow can contain Wait steps, as long as they are there to wait for an event, or do not wait at all (for example, dummy Wait steps used for assigning process property values). A workflow process with a Wait step is a long-running workflow (Long Running Flow) only when the Wait step waits for a period of time, after which the workflow must be resumed from the Workflow Process Manager. In other cases, for example, if the Wait step waits for a run-time event in the same user session, the flow is not a long-running workflow. This type of workflow could contain User Interact steps, which would make it an interactive workflow. Workflow Mode for Workflows that Involve Subprocess Steps A main process can call multiple subprocesses, but the modes of the main process and its subprocesses must be consistent. Table 18 shows the allowed pairings of main process and subprocess mode types. While subprocesses of Service main processes must be service workflows, and subprocesses of 7.0 main processes must be 7.0 workflows, the subprocesses of interactive and long-running workflows can have modes which differ from those of their parent processes. Table 18. Modes Allowed for Pairings of Main Process with Subprocess Main Process Workflow Mode Subprocess Workflow Mode Service Flow Service Flow 7.0 Flow 7.0 Flow Interactive Flow Service Flow Interactive Flow Long Running Flow Service Flow Interactive Flow Long Running Flow 142 Siebel Business Process Framework: Workflow Guide Version 8.0
    143. For Developers: Understanding How Workflow Processes Are Designed ■ About Workflow Modes About 7.0 Workflow Processes The 7.0 Flow workflow process mode provides backward compatibility for existing Siebel 7 (pre-7.7) workflows. If you have existing pre-7.7 workflows and you upgrade to Siebel 7.7, these existing workflows become 7.0 workflows by default. You should categorize all new workflows as service, interactive, or long-running. NOTE: If no Workflow Mode is specified for a workflow process, the mode is assumed to be 7.0 Flow. It is strongly recommended that you not use the 7.0 Flow mode for new workflow processes you create. As you create new workflow processes, make sure to specify a Workflow Mode (other than 7.0 Flow) so that 7.0 Flow is not assumed as the default mode. In Siebel version 8.0, when you create a new workflow process, the Workflow Mode defaults to Service Flow. About Long-Running Workflow Processes A long-running workflow process is a persistent workflow that can last for hours, days, or months. One example of a long-running workflow is Send Order to SAP. In this example, the workflow sends an order to an external system and waits for a response. You can use the Long Running Flow mode to create a single workflow to handle an entire business process transaction (for example, the Quote to Cash business process), and to coordinate between multiple subprocesses. You can build long-running workflow processes that are collaborative, by assigning subprocesses to end users. You do this by employing the Workflow User Event business service, which generates user events that can span from one user or session to another user or session. For more information, see “About the Workflow User Event Business Service” on page 157. NOTE: You cannot build User Interact steps into long-running workflows, but you can build interactive workflows into long-running workflows as subprocesses. Additionally, you cannot simulate long-running workflows using the Process Simulator in Siebel Tools. For more information, see: ■ “Building Long-Running Workflow Processes” on page 145 ■ “Assigning Subprocesses to End Users to Create Collaborative Long-Running Workflows” on page 145 Siebel Business Process Framework: Workflow Guide Version 8.0 14 3
    144. For Developers: Understanding How Workflow Processes Are Designed ■ About Workflow Modes About Interactive Workflow Processes An interactive workflow is used for controlling user navigation between screens and across views. An interactive workflow is comprised primarily of a set of User Interact steps, and usually includes a run-time event. NOTE: An interactive workflow can run only in the context of a user session; it cannot run in the Workflow Process Manager server component, or in other server components that do not have a UI context, such as Business Integration Manager. To be run in the context of a user session means the workflow must run within an Application Object Manager that has UI context—such as Siebel Call Center, Siebel Service, Siebel eSales, or Siebel eService. These applications can support view navigation, view display, and so on. This is necessary for interactive workflows because they perform view display through the User Interact step and they require interaction with the user for clicking buttons and hyperlinks. Interactive workflow processes can be controlled through the use of a synthetic event attached to explicit user interface buttons. A synthetic event is a specialized run-time event that is dedicated to controlling workflow navigation. 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 moving the user back or forward, and by suspending or resuming a workflow process. For more information, see: ■ “Building Interactive Workflow Processes” on page 146 ■ “Creating Synthetic Event Buttons to Control User Navigation” on page 147 ■ “About Suspension and Resumption of Interactive Workflow Processes” on page 151 ❏ “In-memory Cache of Suspended Interactive Workflows” on page 153 ❏ “Events Handling of Suspended Interactive Workflows” on page 153 ❏ “Detection and Handling of the User Logout Event for Suspended Interactive Workflows” on page 153 ■ “About Forward and Backward Navigation between Views” on page 153 About Service Workflow Processes A service workflow process is a transient workflow. That is, it runs to completion in a short period of time, all at once without stopping or pausing for any other event or activity. A service workflow is the lowest common denominator of the workflow process mode types, in that it has no special behavior associated with it and it can be part of any type of workflow process other than a v7.0 flow as a subprocess. This mode of workflow process simply executes a set of operations upon invocation of an event. NOTE: A service workflow process cannot wait—not for run-time events, and not by pausing for time. A service workflow process cannot have User Interact steps or Wait steps. The Process Designer does not allow you to build User Interact steps or Wait steps into a service workflow process; you cannot drag and drop these step types onto the design canvas if the workflow’s mode is Service Flow. 144 Siebel Business Process Framework: Workflow Guide Version 8.0
    145. For Developers: Understanding How Workflow Processes Are Designed ■ Building Long-Running Workflow Processes One example of a service workflow is a workflow for sending an email. Building Long-Running Workflow Processes A long-running workflow process is a persistent workflow that can last for hours, days, or months. An example of a long-running workflow process is an approval process that sends an order to an external system such as SAP, and then waits for a response. For more information, see “About Long- Running Workflow Processes” on page 143. NOTE: When building long-running workflow processes, use user events and not run-time events to trigger processes and resume instances. For more information on the use of long-running workflow processes, see: ■ “Assigning Subprocesses to End Users to Create Collaborative Long-Running Workflows” on page 145 ■ “Configuring Long-Running Workflows to Invoke Tasks” on page 146 Assigning Subprocesses to End Users to Create Collaborative Long-Running Workflows Using the Subprocess step, you can configure workflows that assign interactive subprocess workflows to end users to create collaborative workflow processes. An example of a collaborative workflow is one that includes a requirement for approvals; the route the workflow takes as it moves through its activities is a route across multiple users. Use the Recipients fields on a Subprocess step to create collaborative workflows. Assignment occurs based on the login name, not on the Position or User ID. This login name may be a literal value, it may be held in a process property or a buscomp field, or it may be the result of an expression. NOTE: The Process Designer cannot validate the data supplied to make sure that it represents a valid login name at design time. To assign subprocesses to end users 1 Create a Subprocess step. 2 With the step selected in the Process Designer canvas, view the step’s child items in the MVPW. 3 In the Recipients tab, set the Recipient Name field to the login name of the assignee (the end user who will be assigned the subprocess). Siebel Business Process Framework: Workflow Guide Version 8.0 14 5
    146. For Developers: Understanding How Workflow Processes Are Designed ■ Building Interactive Workflow Processes Configuring Long-Running Workflows to Invoke Tasks You can use a long-running workflow to assign a task to a user, then create an inbox item for the task and push it to the user's Inbox. The user can then click on the inbox item to create a new instance of the task and run it. For example, in an Expense Report Approval long-running workflow, after the employee submits an expense report, a new task called Review Expense Report is to be created and assigned to the employee's manager. Because this case is a one-to-one assignment, the assignment can be made simply by looking up the manager's ID from the user's business component. After the manager's ID has been retrieved, a new item is created in the manager's Inbox that refers to the Review Expense Report task. Example: Use a long-running workflow to assign a task to a user and execute it 1 In the long-running workflow, at the point where a task needs to be called, determine the ID of the user to whom the new task instance is to be assigned. This logic is dependent on your business requirements, and it can be implemented either as a Siebel operation (in cases for which the ID is already present in a business component), or as a business service call. When the assignment logic implies application of assignment rules, a business service interface to Siebel Assignment Manager can be used. The input to the service is variable, depending on the context that is needed for the assignment. The output, however, is always simply the ID of the user to whom the task is to be assigned. 2 Define a task step that creates a new item in the Inbox of the user that the task has been assigned to (specified as the input argument Owner Id). Adding Task Steps to Workflows When you add a Task step to a workflow process, the workflow will create a new UI task and assign it to a user. To add a Task step within an existing workflow process, the workflow should be opened with the Process Designer in edit mode. That is, the status of the workflow should be In Progress. If not, the workflow process should be revised so that an editable In Progress copy is created. For details on how to configure Task steps, see “Defining a Task Step” on page 134. Building Interactive Workflow Processes When you are building interactive workflow processes, do the following: ■ Set the mode of interactive workflows to Interactive Flow. ■ Set the Auto Persist flag for interactive flows that need to be persisted. ■ Configure business components and applets by adding buttons to applets to make use of the synthetic events that control user navigation of workflow processes. See “Creating Synthetic Event Buttons to Control User Navigation” on page 147. This topic is organized as follows: 146 Siebel Business Process Framework: Workflow Guide Version 8.0
    147. For Developers: Understanding How Workflow Processes Are Designed ■ Building Interactive Workflow Processes ■ “Creating Synthetic Event Buttons to Control User Navigation” on page 147 ■ “About Suspension and Resumption of Interactive Workflow Processes” on page 151 ■ “In-memory Cache of Suspended Interactive Workflows” on page 153 ■ “Events Handling of Suspended Interactive Workflows” on page 153 ■ “Detection and Handling of the User Logout Event for Suspended Interactive Workflows” on page 153 ■ “About Forward and Backward Navigation between Views” on page 153 Creating Synthetic Event Buttons to Control User Navigation A synthetic event is a specialized run-time event that is dedicated to controlling workflow navigation. To control the way a user navigates through the Siebel application, you can create buttons on applets within views and then associate synthetic events with the buttons. For example, in the Account Note view of the Siebel application you are configuring, there is an Account Entry Applet on which you want to include buttons for Back, Next, and SaveWorkflow synthetic events so that the user can move forward or backward from the Account Note view, or suspend an interactive workflow process, and then return later to resume the workflow. After you have created the buttons, you associate methods within the interactive workflow process— for example, with Back and Next synthetic events, you associate methods to outgoing branches on the User Interact step. You set the synthetic event method name in the MethodInvoked field of the button controls. The name of the synthetic event method depends on the synthetic event, taking one of the following formats: ■ FrameEventMethodWFNext and EventMethodWFNext. This event moves the user forward in the interactive workflow. NOTE: 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 process is waiting. ■ FrameEventMethodWFBack and EventMethodWFBack. This event moves the user backward in the interactive workflow. ■ SaveWorkflow. This event suspends (saves) the interactive workflow and makes it appear in the user’s Inbox. ■ ResumeLastIntFlow. This event resumes the last executed interactive workflow. NOTE: ResumeLastIntFlow is different from the other events in that it is not tied to any specific workflow process and can be invoked from anywhere in the Siebel application. That is, the button corresponding to this event can be put in any applet, including the task bar where the Site Map icon is located (the recommended place for this button). This topic is organized as follows: Siebel Business Process Framework: Workflow Guide Version 8.0 14 7
    148. For Developers: Understanding How Workflow Processes Are Designed ■ Building Interactive Workflow Processes ■ “To create synthetic event buttons for Next and Back events” on page 148 ■ “To create synthetic event buttons for the SaveWorkflow event” on page 148 ■ “To create synthetic event buttons for the ResumeLastIntFlow event” on page 150 To create synthetic event buttons for Next and Back events 1 In Siebel Tools, select a view to which a User Interact step navigates the user. 2 Configure a Next button or a Back button on an applet where the event is to be triggered. For more information, see Using Siebel Tools. 3 Specify the MethodInvoked property of the button control as the name of the associated event, for example, FrameEventMethodWFBack for backward navigation. 4 In the Process Designer, associate the applet type run-time event, for example, FrameEventMethodWFBack, to the outgoing branches of the User Interact step in the workflow process that will receive the event. Assign the event the following properties: ■ Event Type = Applet ■ Event Obj = AppletName ■ Event = InvokeMethod ■ Sub Event = [method name, for example, FrameEventMethodWFBack] NOTE: You do not have to manually create buttons for each applet. You can copy any button you have created to other applets by using the Applet Comparison capability in Siebel Tools. Also, if you add the applet button controls to the HTML Model Controls applet, when you create new applets with the New Applet Wizard or the conversion process, you can then select all the Workflow-related method buttons. To create synthetic event buttons for the SaveWorkflow event 1 In Siebel Tools, select a view to which a User Interact step navigates the user. 2 Configure a Save button on an applet where the event is to be triggered. For more information, see Using Siebel Tools. 3 Specify the MethodInvoked property of the button control as the name of the associated event, SaveWorkflow. 4 Use the script that follows to invoke the Workflow event handler to handle the button-click event, and passes the Workflow event handler the event’s contextual information, that is, the name of the view where the event occurs. NOTE: The event does not need to be defined in the workflow process definition. function WebApplet_InvokeMethod (MethodName) { return (ContinueOperation); } 148 Siebel Business Process Framework: Workflow Guide Version 8.0
    149. For Developers: Understanding How Workflow Processes Are Designed ■ Building Interactive Workflow Processes function WebApplet_PreCanInvokeMethod (MethodName, &CanInvoke) { // Recognize SaveWorkflow event, which is // used to save Interactive flow if (MethodName == "SaveWorkflow") { CanInvoke = "TRUE"; return (CancelOperation); } return (ContinueOperation); } 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); Siebel Business Process Framework: Workflow Guide Version 8.0 14 9
    150. For Developers: Understanding How Workflow Processes Are Designed ■ Building Interactive Workflow Processes var bc = BusComp (); var bcId = bc.GetFieldValue ("Id"); Inputs.SetProperty("RowId", bcId); var workflowSvc= TheApplication().GetService("Workflow Process Manager"); workflowSvc.InvokeMethod("_HandleSpecialEvent", Inputs, Outputs); return (CancelOperation); } return (ContinueOperation); } To create synthetic event buttons for the ResumeLastIntFlow event 1 In Siebel Tools, select a view to which a User Interact step navigates the user. 2 Configure a Resume button on an applet where the event is to be triggered. For more information, see Using Siebel Tools. 3 Specify the MethodInvoked property of the button control as the name of the associated event, ResumeLastIntFlow. 4 Use the script that follows to invoke the Workflow event handler to handle the button-click event, and passes the Workflow event handler the event’s contextual information, that is, the name of the view where the event occurs. NOTE: The event does not need to be defined in the workflow process definition. function WebApplet_InvokeMethod (MethodName) { return (ContinueOperation); } function WebApplet_PreCanInvokeMethod (MethodName, &CanInvoke) { 150 Siebel Business Process Framework: Workflow Guide Version 8.0
    151. For Developers: Understanding How Workflow Processes Are Designed ■ Building Interactive Workflow Processes if (MethodName == "ResumeLastIntFlow") { CanInvoke = "TRUE"; return (CancelOperation); } return (ContinueOperation); } 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); return (CancelOperation); } return (ContinueOperation); About Suspension and Resumption of Interactive Workflow Processes Interactive workflow processes that have been suspended can be resumed from within the user’s Inbox. The user can navigate out of an interactive process, then navigate back to the process and pick up where the user left off. Siebel Business Process Framework: Workflow Guide Version 8.0 15 1
    152. For Developers: Understanding How Workflow Processes Are Designed ■ Building Interactive Workflow Processes Suspension and resumption of interactive workflow processes can be used in a situation such as the following: a transaction involving the user (an insurance agent) cannot be completed because of missing information, such as a spouse’s social security number required for the entry of an insurance policy quote. In this example, when the insurance agent has been able to obtain the social security number after suspending the interactive workflow process, she can resume the process from within her Inbox and enter the number to complete the entry of the quote. Once the process is complete, the Workflow engine removes the interactive workflow process from her Inbox. Suspended interactive workflows are placed in the workflow owner’s Inbox for tracking and explicit resumption. A suspended interactive workflow is placed in the Inbox under the following two conditions: ■ When the workflow is explicitly suspended through use of the Suspend button (this is called explicit suspension). ■ When a suspended workflow must be removed from the in-memory cache (such as when the user logs out), and if the suspended workflow has its Auto Persist flag checked. (The time period during which a user leaves the view the workflow took the user to, and during which the workflow instance is placed in the in-memory cache, is called implicit suspension.) An interactive workflow is suspended under the following two conditions: ■ When the workflow is explicitly suspended through use of the Suspend button (known as explicit suspension). The suspended workflow is persisted to the database and placed in the Inbox immediately. ■ When a user leaves a view (known as implicit suspension). The suspended workflow is put in the in-memory cache. The suspended workflow is persisted to the database and placed in the Inbox when it must be removed from the in-memory cache (such as when the cache is full or when the user logs out), and if it has its Auto Persist flag checked. A suspended interactive workflow in the Inbox is removed from the Inbox: ■ When the workflow has run to its end and terminates. Suspending a Workflow Versus Persisting a Workflow There is a difference between suspending a workflow and persisting a workflow. When a workflow is suspended, it can be persisted, but only when its Auto Persist flag is set to TRUE. For example, with implicit suspension, if a user leaves a view the workflow took the user to, the workflow instance is saved in the in-memory cache. In this case, no Inbox item is generated yet. When the user logs out, Inbox items are generated for any workflows in the cache that have the Auto Persist flag set to TRUE. So the Inbox items are visible only when the user logs out and then logs back in. 152 Siebel Business Process Framework: Workflow Guide Version 8.0
    153. For Developers: Understanding How Workflow Processes Are Designed ■ Building Interactive Workflow Processes In-memory Cache of Suspended Interactive Workflows Users often navigate out of structured interactive workflows because the workflows have been set up in this manner to address the specific needs of your business. When this happens, the interactive workflows remain in memory so that they can be resumed later in the same user session. As it is uncommon for users to have a large number of unfinished tasks at hand, there can be a maximum of eight suspended interactive workflow instances in the memory cache. This eight-instance limit applies to an individual user session. The limit is eight instances total of all interactive workflows initiated from within the user session, not eight instances per 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. When the eight-instance limit is reached, new interactive workflows are not prevented from running. Instead, if the user initiates another interactive workflow after eight instances are already cached in memory, and this ninth instance must be saved to the cache, then the oldest instance is either pushed into the database (if its Auto Persist flag is set) or dropped, as the memory cache has reached its limit. Events Handling of Suspended Interactive Workflows Workflow handles events in the following sequence: 1 Checking of the in-memory cache to see if any workflow instances there can receive these events, using the matching criteria specified by the events. 2 Checking of the database to see if any persisted workflows can receive these events. 3 Resumption of all instances found in Step 1 and Step 2. Detection and Handling of the User Logout Event for Suspended Interactive Workflows Upon receiving the user logout event, the Workflow engine goes through suspended interactive workflows in the in-memory cache. Workflows with the Auto Persist flag checked are saved as Inbox items. Other workflows are deleted. About Forward and Backward Navigation between Views You can use synthetic events to define an interactive workflow process so that when the user clicks the Next and Back buttons, the user is taken to the next and previous views in the sequence without losing the context of the process instance. NOTE: Use synthetic events to allow the user to navigate backward through views. Run-time events allow forward navigation, but not backward navigation. Workflows can navigate back and forth if the following conditions are met: ■ The workflow being resumed is either an interactive workflow process or a 7.0 workflow process. Siebel Business Process Framework: Workflow Guide Version 8.0 15 3
    154. For Developers: Understanding How Workflow Processes Are Designed ■ Using Workflow Persistence ■ The triggering event is a workflow navigation event, 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. NOTE: Free-flow (backward-forward) navigation is possible with interactive workflow processes and 7.0 workflow processes. Free-flow navigation is not possible with service workflows and long-running workflows. When considering whether to allow backward navigation in your workflow process, be aware of the following: 1. The backward navigation feature does not undo the effect of the workflow process; it only modifies the current step counter to point to a previous step. 2. The workflow configuration must make sure that the segment of the workflow that can be repeated by the backward navigation feature is idempotent. For more information, see “Creating Synthetic Event Buttons to Control User Navigation” on page 147. Using Workflow Persistence Workflow persistence is a feature used to store the state of a workflow process instance and its steps, as well as its process properties. The workflow process state and process properties are saved in the S_WFA_INSTANCE and S_WFA_INST_PROP tables. By using workflow persistence to store the state of a workflow process, you can build end-to-end workflows which include Wait steps, subprocesses, and other interruptions, and which maintain the active state of a process over short or long periods of time, with activity occurring in various parts of your enterprise. When persistence is set to TRUE, a user can continue with a workflow process that has been suspended. The suspended workflow appears in the user’s Inbox. For more information, see “About Workflow Persistence” on page 154. About Workflow Persistence Workflow persistence is an attribute of a workflow process that supports long-lived transactions within a single workflow process. Workflow persistence allows process resumption after a pause or a server crash. Workflow persistence saves and restores data when the process is resumed. For example, with persistence set on an interactive workflow, an end user of the workflow can set aside his work and take a break. If the workflow persistence parameter times out, the workflow will be in the user’s Inbox ready for resumption when the user returns. The workflow persistence setting applies to long-running workflow processes, interactive workflow processes, and 7.0 workflow processes. You cannot use workflow persistence with service workflow processes. The persistence property is a YES/NO setting. For long-running workflows, persistence is automatically set by the server at execution time. For interactive workflows, you set the persistence property using the Auto Persist flag in the Workflow Processes list editor of Siebel Tools. Persistence behaves as follows: ■ Long-running workflows are automatically persisted 154 Siebel Business Process Framework: Workflow Guide Version 8.0
    155. For Developers: Understanding How Workflow Processes Are Designed ■ Handling Events ■ Interactive workflows are persisted on suspension, if the Auto Persist flag is set ■ You control workflow persistence by setting the Auto Persist flag. When a session times out or a user logs out of a Web session, workflow processes with the Auto Persist flag set to YES are persisted and can be resumed from the Universal Inbox. ■ 7.0 workflows with persistence set are marked as Auto-Persist and are persisted NOTE: In the previous release, workflow persistence was used for monitoring workflow processes, and it was controlled by adjusting two settings that could apply to individual steps of a workflow: frequency and level. In this release, process monitoring is separate from workflow persistence, and persistence does not need to be set for long-running processes, because for long-running processes it is set by default. For 7.0 workflow processes that had persistence set, the Auto Persist flag is automatically set to TRUE (YES) during upgrade and import. For more information on workflow persistence, see “Enabling Workflow Persistence” on page 155. Enabling Workflow Persistence For long-running workflow processes, persistence occurs by default. For interactive workflow processes, you set the Auto Persist flag in the Process Designer within Siebel Tools. To set workflow persistence for interactive workflow processes 1 In Siebel Tools, from the Object Explorer applet, select the Workflow Process object. 2 In the Workflow Processes OBLE, select the process you want to work with. 3 In the Auto Persist field, choose YES using the drop-down picklist. NOTE: Persisted workflow processes are automatically purged once they complete running. Handling Events Information on events handling is organized as follows: ■ “Using Run-Time Events” on page 155 ■ “Using User Events” on page 156 Using Run-Time Events Run-time events allow the Siebel application to respond in real time to user actions. Run-time events can be specified in the branches for Start, Wait, or User Interact steps to start or resume a workflow process. The fields of the WF Step Branch properties that are used to define a run-time event are described in “Field Descriptions: Workflow Branches” on page 102 and are the following: ■ Event Object Type ■ Event Object Siebel Business Process Framework: Workflow Guide Version 8.0 15 5
    156. For Developers: Understanding How Workflow Processes Are Designed ■ Handling Events ■ Event ■ Sub Event ■ Event Cancel Flag Run-time events can be used for workflows that run within a user session. For workflows that span across multiple users—long-running workflows—use user events instead. For more information, see “Using User Events” on page 156. NOTE: Run-time events should not be used to trigger long-running workflows because a run-time event is specifically attached to a single user and a single session. A run-time event is only for that single user, as it stems from Personalization functionality. Instead use an interactive workflow or a service workflow to handle the run-time event, then after processing it and validating it, generate a user event to notify a long-running workflow. For further information on run-time events, see Siebel Personalization Administration Guide. Run-time Events and User Interact Steps The following events are not supported with the User Interact step: ■ The DisplayRecord event. ■ The DisplayApplet event. ■ The SetFieldValue event for a field that has the Immediate Post Changes property set to TRUE. ■ The Login event. Use the WebSessionStart event instead. Choosing Between Using Run-Time Events and Using Workflow Policies In cases when it is necessary to detect database events, use workflow policies, not run-time events, for defining integrations that occur on data change or write. For example, when using the UI, use run-time events to trigger a workflow process. When using the Siebel EAI Adapter, which performs numerous WriteRecord events, use workflow policies. Using User Events While run-time events act on workflow processes from within the application object manager, user events are events internal to Siebel Workflow. User events initiate and resume long-running workflow processes in the Workflow Process Manager server component (WFProcMgr). NOTE: User events can be used only in long-running workflow processes. While run-time events can be used in workflows that run within a single user session, user events are for use in long-running workflows that span multiple users. A user event can be used to trigger a workflow process (when it is attached to a Start step), or to resume a waiting workflow instance (when it is attached to any step that can receive input arguments). A user event can also bring data into a workflow instance, in the form of the user event’s payload, which can contain user data. User events require use of the Workflow User Event business service to communicate with the Workflow Process Manager. 156 Siebel Business Process Framework: Workflow Guide Version 8.0
    157. For Developers: Understanding How Workflow Processes Are Designed ■ Handling Events More information on user events is provided in the following topics: ■ “About the Workflow User Event Business Service” on page 157 ■ “Generating User Events with the User Event Business Service” on page 158 ■ “Configuring Long-Running Workflow Processes to Wait for User Events” on page 159 About the Workflow User Event Business Service User events can be generated anywhere in the Siebel enterprise (wherever a Siebel business service is used) by calling the Workflow User Event business service. The Workflow User Event business service is used for one-way communication from the run-time client to the Workflow Process Manager server component. In order to trigger a long-running flow to be run in WFProcMgr, you need to send a notification. The Workflow User Event business service sends this notification in the form of a user event. Arguments The following arguments define a Workflow User Event business service: ■ User Event Name. The name of a user event is an agreement between the creator (an external entity) and the recipient (the workflow definition). It has no special significance, except that the incoming event name and the workflow instance definition must specify exactly the same user event name in order to successfully communicate with each other. User event names must be unique. It is best to logically name user events after the business purpose they serve (for example, "Event Transferring Send Order Confirmation from Vitira To Siebel - V2"). ■ Correlation. Used to match an incoming message with a workflow instance using business data such as an order number. Correlation is the process of matching an incoming message with a workflow instance using business data such as an order ID. In this release, correlation applies to user events reaching long-running workflows. It is often the case that Siebel Workflow communicates with an external entity and the external entity is unaware that it is in contact with a Siebel workflow. In such cases, it is difficult for the external entity to use a Siebel identifier (like the workflow process instance Id) to identify the recipient. It is more convenient to use a piece of business data (such as an order number) to identify the recipient. The correlator serves this purpose. A long-running workflow can specify a process property as a correlator. NOTE: Only one process property can be used as a correlator. ■ Payload. When the user event is created, the user can specify any data as payload. This data is delivered to the workflow instance that receives the event. When the workflow is defined to wait for a user event, the definition can specify a process property to receive this payload data. The payload is a single value—only one payload can be passed. NOTE: If your situation calls for sending complex or structured data, you should convert the data into an XML document (using the XML converter) and then pass the resulting XML string as the payload of the event. The receiving workflow can then call the XML converter again to recover the original data structure. Siebel Business Process Framework: Workflow Guide Version 8.0 15 7
    158. For Developers: Understanding How Workflow Processes Are Designed ■ Handling Events Generating User Events with the User Event Business Service User events are Workflow-internal events used to resume long-running workflow processes from the Workflow Process Manager. To create a user event, you invoke the Workflow User Event business service, specifying the payload and the correlator. NOTE: Long-running workflow processes should use only user events, not run-time events. The Workflow User Event business service is a standard Siebel business service that can be used everywhere a Siebel business service can be used. You invoke the Workflow User Event business service by configuring a business service step that calls it. A common case is when a foreground workflow (that is, a 7.0 workflow, an interactive workflow, or a service workflow) can initiate a user event (by using a business service step configured to call the Workflow User Events business service) to communicate to a background workflow (that is, a long- running workflow). User events can be created by all supported Siebel mechanisms to invoke a business service (such as scripting, COM interfaces, and Java interfaces). This is the recommended way to externally communicate with a Siebel workflow. NOTE: While any type of workflow process (or business service) can generate user events, only long- running workflow processes should be configured to receive user events. NOTE: The following procedure outlines one of several ways of invoking the User Event business service to generate user events. The User Event business service is a standard Siebel business service and can be invoked by all supported mechanisms, such as scripting, COM interfaces, and Java interfaces. To invoke the User Event business service for generating a user event 1 Add a Business Service step to a workflow process. 2 Set the step properties as follows: ■ Business Service Name = Workflow User Event Service ■ Business Service Method = GenerateEvent 3 Create a new input argument for the step. 4 In the Input Argument field, choose Payload from the picklist and fill in the fields as appropriate. 5 Repeat Step 3 to create an input argument by choosing Correlator Value from the picklist. 6 Repeat Step 3 to create an input argument by choosing User Event Name from the picklist. 158 Siebel Business Process Framework: Workflow Guide Version 8.0
    159. For Developers: Understanding How Workflow Processes Are Designed ■ Workflow and Global Implementations Configuring Long-Running Workflow Processes to Wait for User Events When using user events in your workflow processes, keep in mind that only long-running workflows can wait for user events. All other types of workflows cannot wait for user events, though they can generate user events. Long-running workflows should be configured with user events only, not run- time events. To configure a long-running workflow definition to wait for a user event 1 Select the workflow process that you are setting to wait for the user event. 2 In the MVPW, set one of the workflow’s process properties as the correlator by setting its Correlator Flag to TRUE. 3 On the branch of the step that handles the event (a Start step or a Wait step), enter parameters to complete the following fields: ■ User Event = [the name of the workflow you selected for the Value field in Step 6 on page 158] ■ User Event Timeout = [the timeout period for the user event] User Event Timeout works in a similar way as the timeout setting for run-time events. Workflows are resumed after the timeout period if no user event is received during the timeout period. ■ User Event Storage = [the name of the process property that will hold the payload passed in from the user event] NOTE: User events are not queued. If no recipient is waiting to accept the user event with the specified correlator, the event is discarded. Workflow and Global Implementations Information on global implementation of Workflow is provided as follows: ■ “Configuring Workflows in a Multilingual Environment” on page 159 ■ “Defining Expressions for Workflows Running in a Multilingual Environment” on page 160 ■ “Wait Steps and Global Time Calculations in Workflow” on page 160 Configuring Workflows in a Multilingual Environment In order to create workflows in a language other than the base language, you need to make sure that your database is enabled for multilingual lists of values (that is, you make sure it is MLOV- enabled) for the non-base language type. For example, if you are modifying workflows using language=FRA and the base language=ENU, then you need to make sure that List of Values entries exist for the FRA language type. Siebel Business Process Framework: Workflow Guide Version 8.0 15 9
    160. For Developers: Understanding How Workflow Processes Are Designed ■ Workflow and Global Implementations To verify that List of Values entries exist for the appropriate language type 1 From the application-level menu of the run-time client, choose Navigate > Site Map > Administration - Data > List of Values. 2 Run the following query: Type = "WF_*". 3 Enable the database for multilingual lists of values by running the MLOV upgrade utility. For information on running the MLOV upgrade utility, see Configuring Siebel Business Applications. 4 In the List of Values applet, make sure the Active flag is set. NOTE: Workflow definitions cannot reference literal values in dynamic picklists in global implementations. Literal values are language dependent. Workflows referencing literal values become language dependent as well and cannot be run in a global implementation. For more information on global deployments, see Siebel Global Deployment Guide. Defining Expressions for Workflows Running in a Multilingual Environment Workflows use the Display value to fetch records from tables. In a multilingual deployment, the data in the tables is stored in language-independent code (LIC). To run workflows in a multilingual environment, use the LookupValue function to fetch the LIC based on the Display value. Example 1: You have a Decision Point that compares Account Status to "Active". The Account Status field is bounded by the Account Status picklist. You can set the Compare To field to "Expression", and set the Expression field to: [Account Status] = LookupValue ("ACCOUNT_STATUS", "Active") Example 2: You have a Business Service step that calls the Outbound Communications Manager to send emails to "Expense Approver". The Recipient Group argument is bounded by the Comm Recipient Group picklist. You can set the Type field to "Expression", and set the Value field to: LookupValue ("COMM_RECIP_SRC", "Comm Employee") For more information on globalization, see Siebel Global Deployment Guide. For more information on configuring Siebel Workflow to use MLOV-enabled fields, see Configuring Siebel Business Applications. Wait Steps and Global Time Calculations in Workflow An absolute wait is a wait period governed solely by the duration specified. For example, an absolute wait set for 30 minutes waits 30 minutes from the time the wait is initiated by a Wait step. A service calendar wait, on the other hand, is not absolute. For example, a service calendar wait could be set to begin at 6 P.M., but if the service hours for the organization are 9 A.M. to 6 P.M., the wait will not initiate until 9 the next morning. So it will run from 9 to 9:30 instead of 6 to 6:30. 160 Siebel Business Process Framework: Workflow Guide Version 8.0
    161. For Developers: Understanding How Workflow Processes Are Designed ■ Handling Errors When creating workflows with Wait steps, keep in mind that in this release, absolute waits are not affected by any time-zone settings, including server and user time-zone preferences. The database server should always use UTC. For more information, see Siebel Global Deployment Guide. For a wait that is not absolute—that is, the workflow involves service calendar integration—the Wait step requires a time zone for delay computations. In this case, the current user’s time zone is used. NOTE: When a workflow process is executing as a server task, you must shut down and restart the Workflow Process Manager after making any changes to the Time Zone user preference for the SADMIN user. The changes will only take effect after restarting the Workflow Process Manager. This is important if you are implementing UTC, as you may need to set the Time Zone user preference. Handling Errors Information on error processing is organized as follows: ■ “Using Error Processes to Handle Errors” on page 161 ■ “Passing User-Defined Process Properties and Property Sets to Error Processes” on page 162 ■ “Assigning Error Processes to Subprocesses” on page 162 ■ “Using Exceptions to Handle Errors” on page 163 ■ “Defining Exceptions” on page 163 Using Error Processes to Handle Errors You can use an error process for handling errors. An error process is a standard workflow process. It becomes an error process when you associate it to another (main) process using the Error Process Name field in the Workflow Processes list to choose the error process from the picklist. When an error occurs, the exception branch calls this error process. Like the Subprocess step, the error process must have been predefined in order to be selected. When the selection button associated with the Error Process Name field is clicked, a pick applet of all available processes will be shown. Once an error process is selected, this process will be called when the current process reaches an error state. Processing of the current process will stop and end, and will instead start the error process. If a workflow process that has an error process defined for it encounters an error, it stops processing and passes all system-defined process properties to the error process. When a workflow process reaches an error state, one of the following events happens depending on whether or not an error process is defined for the workflow process: ■ If no error process is defined for the workflow process, the process remains in the state called In Error. The original error code is returned to the caller of the process. ■ If an error process is defined for the workflow process, one of the following events happens: Siebel Business Process Framework: Workflow Guide Version 8.0 16 1
    162. For Developers: Understanding How Workflow Processes Are Designed ■ Handling Errors ■ The error process handles the error successfully. The error handling is considered successful if the error process arrives at an End step. In this case, the error process will be in the Completed state. No error code will be returned to the caller of the workflow process. The workflow process terminates immediately with a Completed state. ■ The error process tries to handle the error, but fails with a different error. The error handling is considered failed if the error process arrives at a Stop step. In this case, the error process will be in the In Error state. A new error code, which you have selected in the Stop step, is returned to the caller of the workflow process. The workflow process remains in the In Error state. ■ The error process cannot handle the error. If no Start conditions are satisfied, the error process ends immediately. In this case, the error process will be in the In Error state. The original error code will be returned to the caller of the workflow process. The workflow process remains in the In Error state. The following sections provide more information about error processes: ■ “Passing User-Defined Process Properties and Property Sets to Error Processes” on page 162 ■ “Assigning Error Processes to Subprocesses” on page 162 Passing User-Defined Process Properties and Property Sets to Error Processes If you want more than just the system-defined process properties to be passed to the error process, note the following: ■ If you want the original process instance to pass any user-defined process properties to the error process, you have to explicitly recreate those user-defined process properties in your error process, giving them the same name and data type. ■ If you want to pass a property set from the original process to the error process, you have to create a common user-defined hierarchy process property in the original workflow process and in the error process, and use this common hierarchy property to pass the property set. ■ If you want the error process to get the name of the original workflow process, you have to create a common user-defined process property in the original workflow process and in the error process, and then pass the original process name through this common user-defined process property. Assigning Error Processes to Subprocesses If a subprocess encounters an error and there is an error process defined for the subprocess, the error process completes with one of the following outcomes: 162 Siebel Business Process Framework: Workflow Guide Version 8.0
    163. For Developers: Understanding How Workflow Processes Are Designed ■ Handling Errors ■ The error process handles the error successfully. The error handling is considered successful if the error process arrives at an End step. In this case, the error process is in the Completed state. The subprocess also terminates with a Completed state, and the control returns to the main process instance. The main process instance continues to execute from the next step. ■ The error process tries to handle the error, but fails with a different error. The error handling is considered failed if the error process arrives at a Stop step. In this case, the error process will be in the In Error state. The new error code, which you have selected in the Stop step, is returned to the subprocess. Both the subprocess and the main process will terminate with the In Error state. Using Exceptions to Handle Errors Exceptions are a type of branch designed for handling system and user-defined errors. An example of a system generated error would be a failure when sending an email notification. A user-defined error would be trying to submit an order that was incomplete. As a branch, an exception is a type of connector between two steps. Exceptions are illustrated in the Palette Designer as red connectors. When you click on an exception connector in the Palette Designer, the Properties window shows its WF Step Branch properties. NOTE: Be aware that exceptions on a step are evaluated after the step has completed. If you want to evaluate an exception before executing a step, you must attach the exception to the previous step in the process. The main parts of creating exceptions for a workflow process are: ■ Define an exception ■ Define the exception conditions ■ Add the exception actions For more information, see “Defining Exceptions” on page 163. Defining Exceptions Exceptions are defined in the Process Designer as part of branch properties. To define an exception 1 In Siebel Tools, make the appropriate process active by selecting it in the Workflow Processes OBLE. 2 Right-click and select Edit Workflow Process. 3 In the Process Designer, drag and drop an Error Exception connector from the palette to the canvas, connecting it to an existing step icon. Be sure that the end of the connector is attached to the step. Siebel Business Process Framework: Workflow Guide Version 8.0 16 3
    164. For Developers: Understanding How Workflow Processes Are Designed ■ Recovering Workflow Processes 4 With the exception arrow selected in the canvas, enter a name for the exception in the Properties window. NOTE: If the Properties window is not showing, select the exception icon, then right-click and select View Properties Window. 5 In the Type field, select Error Exception or User Defined Exception. 6 In the canvas, double-click the exception icon to access the Compose Condition Criteria dialog box. 7 Define the conditions that apply to the exception. Recovering Workflow Processes You can recover interrupted workflow processes both automatically and manually. Automatic Recovery of Workflow Process Instances If the Workflow Process Manager server component fails because of an exogenous event (such as a server crash), Siebel Workflow automatically resumes the interrupted workflow instances when the server restarts. For a workflow process instance that cannot be automatically recoverable, you can manually recover the process. For example, if the server crashes in the middle of a Siebel operation to update a record, then the workflow can’t know whether the Siebel Operation has completed. You may have to manually verify that the update was completed before resuming the workflow execution. In another case, if the Siebel operation is to query a set of records, then even after the server crashes, the workflow can be resumed automatically by requerying. NOTE: Automatic recovery of workflow processes applies to workflow processes that run in the server component. Workflow processes running on a local database are not recovered. Recovery is performed by the Recovery Manager based on the process instance’s state information that is saved by the Workflow engine. The state information is saved at recovery checkpoints. For performance optimization, the recovery checkpoints are determined by the Workflow engine based on the nature of the step and Allow Retry flag step parameter. The application developer can minimize run-time overhead by using the Allow Retry flag to reduce the number of checkpoints. This parameter is set at the step level. NOTE: Set the Auto Retry flag for Siebel Operation steps and business service steps. Based on this information, the Workflow engine determines the recovery checkpoints. If the Recovery Manager cannot determine from which step the workflow instance should recover, then those instances are marked for manual recovery. 164 Siebel Business Process Framework: Workflow Guide Version 8.0
    165. For Developers: Understanding How Workflow Processes Are Designed ■ Invoking Workflow Processes Manual Recovery of Workflow Process Instances You can correct and resume a workflow process instance that has encountered errors. For example, if the Communications Server is not available, a workflow process sending an email notification will have a status of In Error. You can enable the Communication Server component, then resume the workflow process. Instances marked for manual recovery are recoverable from the Workflow Instance Admin view. From the application-level menu in the run-time client, choose Navigate > Site Map > Administration - Business Process > Workflow Instance Admin > Related Instances and select an option from the applet menu. There are two options for manual recovery: ■ Resume Instance - Next Step. The process instance skips the current step, and evaluates all the branching conditions coming from the current step to determine the next step to execute. ■ Resume Instance - Current Step. The process instance resumes from the current step. The current step is retried. If the current step is a subprocess step, a new subprocess instance is started. NOTE: A workflow process instance is resumable only if, among its related process instances, its Call Depth setting is the highest. That is, Resume Instance - Next Step and Resume Instance - Current Step are disabled if the instance is part of a set of related instances and one or more other instances are set at a higher level (so the instance is called from another instance). For example, if there are multiple related instances with Call Depth settings of level 0,1,2,3, and 4 and you select the record with level 3, then these Resume controls will be disabled because level 3 is not the highest Call Depth level set among the related instances. Invoking Workflow Processes This section describes the different ways to invoke and run a workflow process. The information provided in this section is organized as follows: ■ “About Invoking a Workflow Process” on page 165 ■ “Invoking a Workflow Process from a Workflow Policy” on page 166 ■ “Invoking a Workflow Process from a Script” on page 167 ■ “Invoking a Workflow Process from a Run-Time Event” on page 169 ■ “Invoking a Workflow Process through a Configured Business Service” on page 170 ■ “Running a Workflow Process in the Workflow Process Manager” on page 171 ■ “Running a Workflow Process in the Application Object Manager” on page 172 ■ “Running a Workflow Process in Batch Mode” on page 172 About Invoking a Workflow Process A workflow process can be invoked in the following ways: Siebel Business Process Framework: Workflow Guide Version 8.0 16 5
    166. For Developers: Understanding How Workflow Processes Are Designed ■ Invoking Workflow Processes ■ From the Process Simulator view. See “Testing Workflow Processes with the Process Simulator” on page 176. ■ From a workflow policy. See “Invoking a Workflow Process from a Workflow Policy” on page 166. ■ From a script. See “Invoking a Workflow Process from a Script” on page 167. ■ From a run-time event. See “Invoking a Workflow Process from a Run-Time Event” on page 169. ■ From a user event. See “Using User Events” on page 156. ■ From a synthetic event. See “Creating Synthetic Event Buttons to Control User Navigation” on page 147. ■ As a configured business service. See “Invoking a Workflow Process through a Configured Business Service” on page 170. You can use these methods to test workflow processes in your test environment before migrating them to the production environment. When testing, being able to invoke from a workflow policy is important because it tests invoking a workflow process on the server. You can also use these methods to invoke processes in your production environment. In Chapter 8, “For Developers: Testing Workflow Processes,” invoking a process from the Process Simulator view is described. Overview: Siebel Enterprise Application Integration and Siebel Email Response Administration Guide discuss invoking a process from a server component. The other invocation methods are explained in this chapter. NOTE: Starting with Siebel 7.0, you should not be using Business Integration Manager and Business Integration Batch Manager, so if you were using either one in your business processes you need to replace them with Workflow Process Manager or Workflow Process Batch Manager, respectively. Invoking a Workflow Process from a Workflow Policy To invoke a workflow process from a workflow policy, you define a policy action that uses the workflow policy program Run Workflow Process. Alternatively, you can create a custom workflow policy program by copying the Run Workflow Process program and 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. NOTE: For complete information about defining workflow policies, see “About Creating Workflow Policies” on page 209. To invoke a process from a workflow policy 1 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Actions. 2 In the Actions applet, click New to define a new action. ■ In the Program field, use the picklist to select the Run Workflow Process program. 3 In the Arguments applet, in the Argument field, select ProcessName. 166 Siebel Business Process Framework: Workflow Guide Version 8.0
    167. For Developers: Understanding How Workflow Processes Are Designed ■ Invoking Workflow Processes ■ In the Value field, enter the name of the workflow process you want to invoke as the argument value. 4 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Policy Groups. 5 In the Policy Groups applet, click New to define a new group and name it. 6 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Policies. 7 In the Policies List applet, click New to define a new policy. a In the Conditions applet, click New to define a condition for the policy that must be met to invoke the workflow process. b In the Actions applet, click New to define a new action and enter the name of the action you defined in Step 1. 8 Run Generate Triggers. See “Creating Database Triggers” on page 263 for more information about running the trigger generator. 9 If you are using the Run Workflow Process program, verify that the Workflow Process Manager server component is online. 10 Run Workflow Monitor Agent. See “Using Workflow Action Agent” on page 281 for more information about monitoring workflow policies. 11 Violate the policy. The action should invoke the workflow process. Invoking a Workflow Process from a Script Workflow processes can be invoked programmatically from a script using Siebel VB or Siebel eScript. By using scripts, workflow processes can be invoked from anywhere in the Siebel application or from external programs. NOTE: Invoking a workflow process from a script is done in synchronous mode. When invoking a process from a script, you can specify that the process run either on the server or in the object manager. To run a process on the server, call the service Workflow Process Manager (Server Request). To run a process in the application object manager, call the service Workflow Process Manager. See the following sample scripts for examples of how to invoke a workflow process from a script: ■ “Example: Invoking a Workflow from a Script in Object Manager” on page 168 ■ “Example: Invoking a Workflow from a Script to Pass Field Values to Process Properties” on page 168 Siebel Business Process Framework: Workflow Guide Version 8.0 16 7
    168. For Developers: Understanding How Workflow Processes Are Designed ■ Invoking Workflow Processes Example: Invoking a Workflow from a Script in Object Manager The following is a sample script that invokes a workflow process called My Account Process. In this example, the process is invoked in the object manager. / Example: Invoking a Workflow Process via scripting function 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: Invoking a Workflow from a Script to Pass Field Values to Process Properties The following is a similar example script that invokes a workflow process called My Opportunity Process. In this example, the process is invoked in the object manager and additional field values are passed to process properties defined in the workflow process. //Example: Passing Field Values to Process Properties function 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 property Input.SetProperty("Account Id", accountId); svc.InvokeMethod("RunProcess", Input, Output); 168 Siebel Business Process Framework: Workflow Guide Version 8.0
    169. For Developers: Understanding How Workflow Processes Are Designed ■ Invoking Workflow Processes Invoking a Workflow Process from a Run-Time Event Workflow Processes integrates with the Run-time Events engine to provide a simplified event mechanism for automating business processes. This mechanism: ■ Allows real-time monitoring of events ■ Minimizes the need for scripting and workflow policy invocation The following types of events are possible: ■ Application ■ Business Component ■ Applet NOTE: For more information about run-time events, see Siebel Personalization Administration Guide. In order to use a run-time event to invoke a workflow process, you use Siebel Tools to configure buttons on applets. To create a button that invokes a workflow process 1 From Siebel Tools, configure a button on an applet and specify the MethodInvoked property. For more information, see Using Siebel Tools. 2 To enable the button, override the PreCanInvokeMethod property. Next, edit the server script and compile your changes to the Siebel repository file. 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 3 Define a workflow process. To invoke this workflow process from a button click, specify a run- time event in one of the following ways: ■ To start this workflow process, specify the run-time event on the Start step on a Condition branch. Siebel Business Process Framework: Workflow Guide Version 8.0 16 9
    170. For Developers: Understanding How Workflow Processes Are Designed ■ Invoking Workflow Processes ■ To resume this workflow process (if it has been paused) from a button click, specify the run- time event in a User Interact step or a Wait step on a Condition branch. The fields values are described in Table 19. Table 19. Run-time Event Field Values Field Value Event Object Type BusComp Event PreInvokeMethod Event Object Name of the business component on which the applet that contains the button is based. Sub Event Name of the method set in step one. The Sub Event name must be unique. Event Cancel Flag True. If this flag is not checked, the error “The specialized method <Method Name> is not supported on this business component” will result when running the workflow process. NOTE: If users click the button when there are no workflow process instances waiting, either the event will be discarded or the users will receive a “Cannot resume process....” error message. You can prevent this from happening by requiring users to run a workflow process in order to access this view. For example, you can set up a workflow that includes the User Interact step. You can handle the error by defining an Error Exception branch or error process. 4 After you create the workflow process, activate the process and reload personalization. To reload personalization: a From the application-level menu, choose Navigate > Site Map > Administration - Runtime Events > Events. b From the applet menu, select Reload Runtime Events. You must reload personalization after activating a workflow process that registers any run-time events in order for the process to take effect. Invoking a Workflow Process through a Configured Business Service You can invoke a workflow by defining a configured business service. With a configured business service like Workflow Process Manager (Server Request), you do not need to specify Server Request Broker (SRBroker) parameters. NOTE: To use Workflow Process Manager (Server Request), SRProc and SRBroker must be running. For more information, see Siebel System Administration Guide. When you invoke the Server Requests directly, you must specify SRBroker parameters. 170 Siebel Business Process Framework: Workflow Guide Version 8.0
    171. For Developers: Understanding How Workflow Processes Are Designed ■ Invoking Workflow Processes To define a configured business service 1 In Siebel Tools, navigate to Siebel Objects > Business Service. Add a new record with values: ■ 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) 2 Click Business Service User Prop. Add the following records: ■ Name: Component ■ Value: (internal [or short] name of the server component, for example, 'WfProcMgr') ■ Name: Mode ■ Value: (mode of the server request, for example, 'Async') 3 (Optional) Enter additional user properties pertaining to SRBroker (see “Predefined Business Services” on page 328). 4 Select Business Service Method. Add the following records: ■ Name: (this is the name that you can reference in scripting) ■ Display Name: (this is the name that you see in workflow views) 5 Click Business Service Method Arg. Add records specific to the component being invoked, for example, ‘ProcessName’ for WfProcMgr. Note that the name is the internal (or short) name of the server component parameter. NOTE: SRBroker and SRProc are required to run any business service that invokes server components. For more information on invoking business services, see Siebel Object Interfaces Reference. Running a Workflow Process in the Workflow Process Manager A workflow process can be run within the Workflow Process Manager server component. The methods of invoking a workflow process that support running a process on the server include: ■ From a workflow policy that executes on the server ■ From a script specifying the Server Request parameter ■ From a run-time event with Processing Mode set to Remote Synchronous or Remote Asynchronous NOTE: Invoking a workflow process from a script is done in synchronous mode. If a user invokes a process to be run on the server within the Workflow Process Manager server component, the process executes only if the user is connected to the server. If the user is not connected to the server, the request is queued and executes when the user synchronizes or the server becomes available. Siebel Business Process Framework: Workflow Guide Version 8.0 17 1
    172. For Developers: Understanding How Workflow Processes Are Designed ■ Invoking Workflow Processes If you compiled a custom .srf file using Siebel Tools, this file needs to be added to the Objects directory on the Siebel Application Server. In addition, you must update the siebel.cfg file referenced in the Server parameters to reflect the custom .srf file (note that the siebel.cfg file is the default configuration file for Workflow Process Manager server components). NOTE: Business services calling UI functions, including navigation functionality such as the User Interact step, are not supported when processes run on the server. Running a Workflow Process in the Application Object Manager Running a workflow process in the application object manager can be useful for enforcing business processes with mobile users or for defining business processes that involve end-user navigation. The methods that support invoking a workflow process in the application object manager include: ■ From the Process Simulator ■ From a script specified to run locally in the application object manager ■ From a run-time event with Processing Mode specified as local synchronous Running a Workflow Process in Batch Mode Workflow processes can be run in batch mode by running the Workflow Process Batch Manager server component (WfProcBatchMgr). Executing a process in batch allows you to execute the actions in a workflow process for multiple records. When you are running a process in batch, you may want to specify a search specification to limit the number of records that are evaluated. NOTE: Only 7.0 workflow processes and service workflow processes should be run in batch mode. Workflow Process Batch Manager takes the parameter Search Specification, then executes the search specification on the primary business component of the process business object. For each fetched record, the Workflow Process Batch Manager invokes the workflow process and sets the Object Id process property as the current active row. Table 20. Workflow Process Batch Manager Parameters Display Name Description Workflow Process Name Required. Name of the workflow process definition to execute. Search Specification Search specification that identifies the work items to process. NOTE: The Search Specification parameter is a generic parameter that is shared by all Workflow Management server components. This parameter is only used by one component, however: WfProcBatchMgr. Any Search Specification parameter specified for a component other than WfProcBatchMgr is not used. 172 Siebel Business Process Framework: Workflow Guide Version 8.0
    173. For Developers: Understanding How Workflow Processes Are Designed ■ Invoking Workflow Processes Scheduling a Batch Workflow You can set up a batch workflow to run a workflow process at specified intervals, for example, 7 A.M. every Monday. You do this by setting up a component request. To set up a component request to schedule a batch workflow 1 From the application-level menu in the run-time client, choose Navigate > Site Map > Administration - Server Configuration > Enterprises > Component Definitions. 2 In the Component Request form, click New. 3 In the Component/Job field, click the selection button. The Component/Jobs dialog box appears. 4 Select Workflow Process Batch Manager. 5 In the Component Request Parameters form applet, click New. 6 In the Name field, click the selection button, then select Workflow Process Name from the dialog box. 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 Select Search Specification. In the Value field, provide a search specification.For more information on running a workflow process in batch, see Siebel System Administration Guide. Siebel Business Process Framework: Workflow Guide Version 8.0 17 3
    174. For Developers: Understanding How Workflow Processes Are Designed ■ Invoking Workflow Processes 174 Siebel Business Process Framework: Workflow Guide Version 8.0
    175. 8 For Developers: Testing Workflow Processes This chapter explains how to test your workflow processes before deployment. You use the Process Simulator in Siebel Tools to test workflow processes, and you can also test them in real time using the run-time environment. The way you test your workflow processes depends on the type of process you are testing. Before you can successfully simulate a process, you must validate it to make sure the configuration is correct. So this chapter begins with an explanation of the Validate tool. This chapter is organized as follows: ■ “Using the Validate Tool to Correct Errors in Workflow Processes” on page 175 ■ “Testing Workflow Processes with the Process Simulator” on page 176 ■ “About the Process Simulator and Supported Modes for Simulation” on page 177 ■ “Running the Process Simulator” on page 178 ■ “Testing Workflows That Involve Server Components” on page 180 For more information, such as planning high-level planning strategies for testing the Siebel application, see Testing Siebel Business Applications. Using the Validate Tool to Correct Errors in Workflow Processes The Validate tool in Siebel Workflow is an error-correction mechanism that you use before simulation and deployment. You can validate a workflow process by using the context-sensitive right-click menu in the palette or in the Workflow Processes OBLE in Siebel Tools. Validation enforces the semantic consistency of a workflow process that otherwise cannot be easily enforced by structural constraints. For example, using validation, you can make sure that an error process does not itself contain an error process. When you validate a workflow process, you are given warnings about errors the workflow may contain. You can then correct the errors before running the Process Simulator. The Validate tool can detect the following errors: ■ Connectors not attached correctly. Make sure all the workflow process diagram’s branches are connected correctly. ■ Outgoing branches not specified for Decision points. Make sure to specify outgoing branches for each Decision point in the workflow process. ■ Business services and business service methods not specified for Business Service steps. Make sure that each Business Service step in the workflow process is not missing a business service or a business service method. Siebel Business Process Framework: Workflow Guide Version 8.0 17 5
    176. For Developers: Testing Workflow Processes ■ Testing Workflow Processes with the Process Simulator ■ Business components missing from Siebel Operation steps. Make sure to specify the business component upon which each Siebel Operation step acts. ■ Subprocess names not specified for Subprocess steps. Make sure that each Subprocess step specifies the appropriate subprocess that the workflow calls. To validate a workflow process 1 In Siebel Tools, in the Workflow Processes OBLE, select the process you want to validate. 2 Right-click and select Validate. The Validate dialog box appears. 3 Click Start. “Starting validation...” appears in the bottom left corner of the Validate dialog box. 4 If the validation is successful, there are no errors to report and in the bottom left corner of the dialog box, a message reads, “Total tests failed: 0.” 5 If the validation is not successful, you will get a list of the errors and the rules they violate. Take one of the following actions: a Click on the error to see the message in the Details dialog box. b You can also save the errors to a log file by clicking the Save As button at the bottom of the validation panel. NOTE: Not all errors are fatal; some errors are only warnings. Testing Workflow Processes with the Process Simulator Testing your workflow processes before migrating them to your production environment verifies that resulting actions are accurate and useful and the results are exactly what you want. You need to develop a test and migration procedure for introducing changes into the production environment. Some of the considerations for this procedure are discussed in “Defining a Test and Migration Strategy for Workflow Processes” on page 58. CAUTION: Your test environment and production environment must have identical versions of the software. Of the various ways to invoke a workflow process, invocation from the Process Simulator is an easy way to debug a workflow process. You can debug process steps as you define them in Siebel Tools, where the Process Designer and the Process Simulator both reside. NOTE: When the workflow process is run from the Process Simulator, it runs in the application object manager. Actual invocation of the process may be run in the application object manager or in the Workflow Process Manager server session, depending on specific parameters. Because some workflow processes that can run in the Workflow Process Manager server session may not be able to run in the application object manager, not all workflow processes can be simulated. For more information, see “About the Process Simulator and Supported Modes for Simulation” on page 177. 176 Siebel Business Process Framework: Workflow Guide Version 8.0
    177. For Developers: Testing Workflow Processes ■ Testing Workflow Processes with the Process Simulator The other methods involve invoking a workflow process outside of Siebel Workflow. For information on these methods of invoking a workflow process, see “About Invoking a Workflow Process” on page 165. For information about invoking a workflow process from a server component, see Overview: Siebel Enterprise Application Integration and Siebel Email Response Administration Guide. About the Process Simulator and Supported Modes for Simulation The Process Simulator allows you to step through a workflow process while viewing the results of each step. A workflow process does not have to be active to run it in the Process Simulator. The simulator ignores activation date, expiration date, and status. NOTE: Before you run the Process Simulator or deploy your workflow processes, you use the Validate feature. The Validate feature has rules to make sure the workflow process works correctly. For more information, see “Using the Validate Tool to Correct Errors in Workflow Processes” on page 175. You can use the Process Simulator to test workflows that run in the Siebel client. This includes service workflows, 7.0 workflows, and interactive workflows. You cannot use the Process Simulator to test long-running workflows or workflows that involve a server component, such as Workflow Process Manager, Server Request Broker, Assignment Manager, and Communications Server. To test workflows that involve a server component, the workflow must be deployed to the run-time environment and tested using the application server. When you start the Process Simulator, the Siebel Web Client is launched with a connection to the database specified in your debug options. (For information on setting debug options, see “Running the Process Simulator” on page 178.) A Watch window shows the Workflow variables (process properties) and application data (business objects and business components). This topic is organized as follows: ■ “Process Simulator Commands” on page 177 ■ “Process Simulator Watch Window” on page 178 For more information on testing workflow processes, see: ■ “Running the Process Simulator” on page 178 ■ “Testing Workflows That Involve Server Components” on page 180 Process Simulator Commands You control the Process Simulator using the Simulate toolbar. Siebel Business Process Framework: Workflow Guide Version 8.0 17 7
    178. For Developers: Testing Workflow Processes ■ Testing Workflow Processes with the Process Simulator To enable the Simulate toolbar 1 From the application menu in Siebel Tools, choose View > Toolbars > Simulate. When active, the Simulate toolbar appears as shown below. 2 Once you can view the Simulate toolbar, you may continue to Step 1 on page 179 to run the Process Simulator. Table 21 describes the buttons in the Simulate toolbar. Table 21. Process Simulator Commands Button Description Start Simulation Activates the Start step in the process. Resumes the process if it is paused. Simulate Next Activates the step immediately after the step that just executed. Complete Simulation Pauses the simulation. Stop Simulation Stops the process. Process Simulator Watch Window You can use the Watch window in the Process Simulator to view process properties. To view the Watch window, right-click in the Process Simulator and select Watch Window. Running the Process Simulator Before you run the Process Simulator for the first time, you must set your debug options. Then in the Process Designer, you right-click and select Simulate Workflow Process to start the Process Simulator. CAUTION: When testing a workflow process using the Process Simulator, it is important to note that the workflow runs just as if it were called normally. For instance, if the process includes a Siebel operation such as update or add, the records in the database will be updated when you run the Process Simulator. NOTE: The Workflow Process Simulator will simulate a wait period if a Wait step is specified in seconds. However, if the unit of time is specified in minutes or greater, the Simulator will simply move on to the next step. 178 Siebel Business Process Framework: Workflow Guide Version 8.0
    179. For Developers: Testing Workflow Processes ■ Testing Workflow Processes with the Process Simulator To use the Process Simulator to test a workflow process 1 In Siebel Tools, navigate to View > Options > Debug and set your debug options. Complete the fields in the Debug tab according to the guidelines listed below, where $ represents settings specific to your setup. Enter the complete path for the Siebel executable (Siebel.exe) and the configuration file (uagent.cfg). Executable $SiebelClientBINsiebel.exe CFG file $SiebelClientBINenuuagent.cfg Working directory $SiebelClientBIN User name $username Password $password Data source $datasource 2 In the Workflow Processes OBLE, right-click on the workflow you want to simulate and select Simulate Workflow Process. This brings you to the Process Simulator view. The workflow’s Start step is highlighted to mark the starting point of the simulation. 3 In the Simulate toolbar, click the Start Simulation button to begin the simulation. A new instance of the Web client launches according to the debug settings you entered in Step 1 on page 179. You use this Web client as the run-time environment for the simulation. There are no actions you need to take in this Web client unless the workflow being simulated is an interactive flow. Details on simulating interactive flows can be found in Step a of Step 4. After the Web client is initialized, the Start step executes and the workflow is paused at the second step. Then, control passes back to Siebel Tools. At this point, if the first step executes as expected, the second step of the workflow is highlighted in the Process Simulator view. Note the following, as you use the Process Simulator: ■ To use the Watch window, right-click on the canvas and select Watch Window. ■ You can use the Process Designer at any time to make changes to the step details, and then return to the Process Simulator to test the process. 4 In the Simulate toolbar, click the Simulate Next button to execute the highlighted step. After the step execution completes, if the step is not a User Interact step, the highlight is moved to the next step in the workflow and the Simulator is ready for the next step’s execution. (Continue to Step 5.) If the step is a User Interact step in an interactive flow, the corresponding view defined in the step is displayed in the Web client. a Switch to the Web client and make fire the run-time event expected by the User Interact step in order to resume the workflow execution. Control is passed back to Siebel Tools, and the highlight moves to the next step in the workflow. Siebel Business Process Framework: Workflow Guide Version 8.0 17 9
    180. For Developers: Testing Workflow Processes ■ Testing Workflows That Involve Server Components 5 Continue stepping through the workflow process and verifying the results of each step in the Watch window until the process completes. NOTE: After the last step has executed, the simulation automatically ends. You can use the Stop Simulation button, however, to stop the simulation before the last step executes, and then close the workflow process window to exist the simulation. Troubleshooting Workflow Process Simulation This topic provides guidelines for resolving workflow process simulation problems. To resolve the problem, look for it in the list of Symptoms/Error messages in Table 22. Table 22. Resolving Workflow Process Simulation Problems Symptom/Error Message Diagnostic Steps/Cause Solution When trying to simulate a If a Start step has outgoing Either remove the event for workflow, upon starting the branches that have run-time simulation, or add a default workflow, it does not run. events, the simulator waits branch. on the event and it will never get to next step. After completing the user The branches out of the user Make sure all the branches out of interact step, the simulator interact step may be missing user interact step have the fails to move further. associated run-time events. respective run-time events associated with the actions performed on the user interact step. Testing Workflows That Involve Server Components You cannot use the Process Simulator to test workflows that involve server components, such as long-running workflow processes. If a workflow process involving a server component is run in the Process Simulator, incorrect behavior will result. To test a workflow process that involves a server component, you test the workflow in the run-time environment. For example, if you want to test a workflow process that invokes Siebel Assignment Manager, you deploy the workflow to the run-time environment. You export the workflow from Siebel Tools and import it into the Web Client. Then you test the workflow in real time with the working server components. 180 Siebel Business Process Framework: Workflow Guide Version 8.0
    181. 9 For Administrators: Administering Workflow Processes This chapter is organized as follows: ■ “About Deploying Workflow Processes” on page 181 ■ “Migrating Workflow Processes from Development to Production” on page 185 ■ “Administering Workflow Processes in the Run-Time Client” on page 188 ■ “Monitoring and Troubleshooting Workflow Processes in Production” on page 193 About Deploying Workflow Processes Workflow design and workflow deployment occur separately. Workfow deployment is the process of moving an environment and making it active. After you have designed a workflow process in the Process Designer within Siebel Tools, you deploy the workflow process by publishing the workflow process (also in Siebel Tools), and then activating the workflow process in the run-time client application. NOTE: If use the Publish/Activate button (rather than the Publish button) to publish the workflow process while in local mode, there is no need to separately activate the workflow in the run-time application. The following bulleted items describe the above actions in more detail: ■ Publish. Moves the workflow process definition from the repository tables into the runtime client tables. ■ Activate. Selects the active version of the workflow process in the runtime tables. Only one version of a workflow process can be active at a time for a Siebel Enterprise. NOTE: Activating occurs from within the Siebel client (where multi-select is supported) and provides a form of version control for when you have multiple developers publishing multiple versions of the same workflow process. ■ Publish/Active. Publishes and activates a workflow process with a single button click from within Siebel Tools while in local mode. To use this feature, you must also set the [Workflow] VerCheckTime parameter to -1 for the client on which you are testing. For more information about the setting this parameter, see “Deploying Workflows in Production” on page 42. Siebel Business Process Framework: Workflow Guide Version 8.0 18 1
    182. For Administrators: Administering Workflow Processes ■ About Deploying Workflow Processes Figure 12 on page 46 shows the deployment architecture of Siebel Workflow. Siebel Tools is connected to the server data source. The run-time client application is also connected to the server data source. The steps you take are summarized as follows: 1 Publish the workflow process in the Process Designer in Siebel Tools. This step makes the workflow process visible in the run-time client application. The following diagram shows the Publish button in the WF/Task Editor toolbar. 2 Log in to the run-time client. From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Deployment. This takes you to the Workflow Deployment view, where you can activate the workflow process. You can find further information about deploying workflow processes as follows: ■ See “Deploying Workflow Processes” on page 182 for general information about deploying workflow processes. ■ See “Deploying Workflow Processes to Mobile Clients” on page 184 for information specific to deploying workflow processes to mobile clients. Deploying Workflow Processes There are two steps involved in deploying a workflow process because the workflow process definitions are stored as repository objects, while deployed workflow processes are stored in run- time tables along with their deployment parameters. You deploy workflow processes from the Siebel Tools repository to the Siebel Workflow run-time client. NOTE: If the workflow process you are deploying contains subprocess steps or references new repository objects such as business components, business services, and views, you must first make sure these subprocesses or repository objects are available to the workflow you are deploying. In the case of subprocess steps, deploy the subprocesss before deploying the parent workflow, so the subprocesses are accessible to the parent workflow process. In the case of new repository objects, first compile the new repository objects so they are accessible to the workflow process you are deploying. The workflow process definition is read from the repository and Siebel Workflow writes the definition to the run-time environment as XML. You deploy the workflow process with its deployment parameters (Replication, Activation Date, Expiration Date, and Monitoring Level). See “Setting Workflow Process Monitoring Levels” on page 195 for detailed information on deployment parameters. 182 Siebel Business Process Framework: Workflow Guide Version 8.0
    183. For Administrators: Administering Workflow Processes ■ About Deploying Workflow Processes To deploy a workflow process 1 In Siebel Tools, enable the Workflow/Task Editor toolbar by selecting View > Toolbars > WF/Task Editor Toolbar. 2 Select the workflow process in the Object List Editor. 3 In the WF/Task Editor toolbar, click the Publish button. The workflow’s status changes from In Progress to Completed and is available as follows: ■ If you are connected to the server data source, the completed workflow process is available at run time to be activated. ■ If you are connected to the local data source, check in the workflow process. After you check in the workflow, it is available at run time to be activated. 4 In the run-time client, from the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Deployment and query for the workflow you just deployed. 5 With the workflow process selected, click the Activate button. This checks the syntax for validity, registers run-time events if used, and changes the status of the process to Active. It also changes the status of the previous active version to Outdated. a If your workflow process has run-time events, you will also need to reload the run-time events. From the application-level menu, choose Navigate > Site Map > Administration - Runtime Events, then click the applet menu and select Reload Runtime Events. This will reload the run- time events in the current object manager session. For more information, see Siebel Personalization Administration Guide. 6 Set the deployment parameters for the workflow process: a Set the activation date in the Activation Date/Time field. b Set the expiration date in the Expiration Date/Time field. c Set the replication to None, unless you are deploying the workflow process to mobile clients. If you are deploying the workflow to mobile clients, see “Deploying Workflow Processes to Mobile Clients” on page 184. d Set the monitoring level in the Monitoring Level field. For more information, see “Setting Workflow Process Monitoring Levels” on page 195. Now you can invoke the workflow process from any of the invocation modes: the Process Simulator, a script, or Workflow Policies. To activate workflow processes in batch 1 In the run-time client, from the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Deployment and query for the workflows you want to deploy. 2 Select the workflows you want to activate, and then click the Activate button. NOTE: It is recommended that you do not select all workflows. Siebel Business Process Framework: Workflow Guide Version 8.0 18 3
    184. For Administrators: Administering Workflow Processes ■ About Deploying Workflow Processes Deploying Workflow Processes to Mobile Clients The Replication field in the Workflow Deployment view allows you to choose whether to route a workflow process definition to your mobile clients. Routing only the workflow process definitions your mobile clients need lets you reduce the amount of data in the local database. To set the Replication parameter, navigate to Administration - Business Process > Workflow Deployment > Active Workflow Processes. Table 23 lists the possible values for the Replication field. Table 23. Parameter Settings for the Replication Field in the Workflow Deployment View Field Description Replication Choose from these possible values: ■ All. The workflow process definition is routed to all mobile clients and regional nodes. ■ Regional. The workflow process definition is routed to the regional nodes only. ■ None. (Default) The workflow process definition is not routed to the mobile client or the regional nodes. More information about using workflow processes with mobile clients is provided in the following sections: ■ “Restricting Mobile Client Routing” on page 184 ■ “Deploying Workflow Processes on Regional Nodes” on page 184 Restricting Mobile Client Routing When modifying the Replication field in order to choose whether to route a workflow process definition to your mobile clients, keep in mind that changing the Replication field value from None to All adds the workflow process definition and all related records to the mobile client or regional node when it synchronizes with the server. Deploying Workflow Processes on Regional Nodes You can execute workflow processes on regional nodes. The workflow process can be called from script or run-time events. When executing a workflow process on a regional node, the workflow process must reside on the regional node. The settings and environment should be replicated entirely on the nodes. All the objects the workflow is referencing must be available on the regional node. 184 Siebel Business Process Framework: Workflow Guide Version 8.0
    185. For Administrators: Administering Workflow Processes ■ Migrating Workflow Processes from Development to Production Migrating Workflow Processes from Development to Production Once you have tested your workflow processes in your development environment, you can move them to the production environment. NOTE: Before migrating data, make sure that all data required for the workflow process is also present in the target environment. For example, if your workflow process requires custom entries in the list of values (LOV) table, make sure that these are present and active. Siebel applications provide four utilities for migrating workflow processes from development to production: ■ REPIMPEXP. The Repository Import/Export utility is found in the siebel/bin directory. Use REPIMPEXP for bulk migration of repository objects, including workflow definitions. In the command-line interface, type repimpexp/help to view your usage options. NOTE: Using REPIMPEXP, you cannot pick and choose which workflows to migrate. To select a single workflow or only certain workflows for migration, use the Import/Export migration option. ■ Import/Export functionality in Siebel Workflow. Use Import/Export for incremental migration of workflow definitions. You use Siebel Tools to export workflows from one environment, and to import workflows to another environment. NOTE: The Workflow import/export feature is designed only to migrate individual workflow processes or small sets of workflow processes. For example, Workflow import/export will not migrate 150 workflow processes at one time. To migrate large numbers of processes, break them into smaller sets of 10 workflow processes or less. ■ Application Deployment Manager (ADM). Application Deployment Manager (ADM) is a feature that automates the process of migrating enterprise customization data (views, responsibilities, assignment rules, workflow processes, workflow policies, and so on) from one Siebel application environment to another, including from a development environment to a testing environment. 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 provide as much automation as possible to decrease the error rate. A workflow process deployment package in ADM includes the SRF, the workflow processes, their subprocesses, and their run-time settings (such as activation/expiration times, monitoring levels, and so on). For information on how to migrate workflow definitions using ADM, see Siebel Application Deployment Manager Guide. ■ Workflow Admin Service Business Service. This is a new business service that allows you to perform batch import/export, deployment, and activation of multiple workflow processes initiated by way of a search specification. The methods for this business service are: Activate, Delete Deploy, Deploy, Export, and Import. ■ Activate. Activates workflow processes initiated by a search specification. Input Arguments: Siebel Business Process Framework: Workflow Guide Version 8.0 18 5
    186. For Administrators: Administering Workflow Processes ■ Migrating Workflow Processes from Development to Production ❏ FlowSearchSpec. The search specification used to select the workflow processes to be activated. Output Arguments: ❏ NumFlowActivated. The number of workflow processes that have been activated by the service. ■ DeleteDeploy. Deletes workflow deployment records initiated by a search specification. Input Arguments: ❏ FlowSearchSpec. The search specification used to select the workflow deployment records to be deleted. Output Arguments: ❏ NumFlowDeleted. The number of workflow deployment records that have been deleted by the service. ■ Deploy. Deploys workflow processes initiated by a search specification. Input Arguments: ❏ FlowSearchSpec. The search specification used to select the workflow processes to be deployed. Output Arguments: ❏ NumFlowDeployed. The number of workflow processes that have been deployed by the service. ■ Export. Exports workflow processes initiated by a search specification into a specified directory. Each workflow process is exported to a separate .xml file with that file name being the concatenation of the process name and version number. Input Argument: ❏ ExportDir. The directory to which the export files are written, such as d:workflows. Output Arguments: ❏ NumFlowExported. The number of workflow processes that have been exported by the service. ■ Import. Imports workflow export files initiated by a search specification from a specified directory. Input Arguments: ❏ FileSearchSpec. The search specification used to select the workflow export files to be imported, such as User*.xml. ❏ ImportDir. The directory where the workflow export files are located. ❏ ProjectName. The Siebel Tools project into which workflow processes will be imported. The project needs to be locked for workflow import to succeed. ❏ Repository. The repository into which workflow processes will be imported. Output Arguments: 186 Siebel Business Process Framework: Workflow Guide Version 8.0
    187. For Administrators: Administering Workflow Processes ■ Migrating Workflow Processes from Development to Production ❏ NumFlowImported. The number of workflow processes that have been imported by the service. When you migrate workflow processes using ADM, the workflows are activated automatically. If you use REPIMPEXP or the Siebel Workflow import/export option, you must activate the workflows manually. NOTE: If you choose not to connect Siebel Tools to your production repository, you must use REPIMPEXP for migration of all your workflow process definitions. For more information, see “Importing or Exporting a Process Definition” on page 187. Choosing Between Migration Options Table 24 explains when to use each of the migration options. Table 24. Options for Migrating Workflow Processes Migration Option Recommended Use Use ADM when: You are migrating customization data for your entire enterprise, including workflow process data. You need to migrate large numbers of processes (more than 10) at one time. Use the import/export You need to migrate workflow definitions in increments of utility when: approximately 10 or less. Use REPIMPEXP when: You are rolling out your release and all repository objects must be migrated. REPIMPEXP is the manual process for repository migration. You should use this repository-migration option if for any reason you do not want to use ADM, or cannot use ADM. Use Workflow Admin You can perform bulk or batch migration of workflow processes. Service Business Service: Alternatively, you can also perform this migration from the client. Importing or Exporting a Process Definition It is a good idea to back up your process definitions regularly using the Export function. Use a meaningful naming convention when selecting a filename for an exported process to make it easy to understand the purpose of the process. To export a process definition 1 In Siebel Tools, in the OBLE, select the workflow process or processes you want to export. To select more than one process, press and hold the CTRL key while selecting the processes. 2 Right-click and choose Export Workflow Process. The Save As dialog box appears. Siebel Business Process Framework: Workflow Guide Version 8.0 18 7
    188. For Administrators: Administering Workflow Processes ■ Administering Workflow Processes in the Run-Time Client 3 Enter the file path, filename, and the .xml filename extension, and then click Save. The process or processes are exported. If you selected more than one process to export, all the processes are saved to one XML file. NOTE: When exporting a process containing subprocesses, you must also export the subprocesses. Subprocesses are not exported automatically. To import a process definition 1 In Siebel Tools, in the OBLE, select the workflow process or processes you want to import. To select more than one process, press and hold the CTRL key while selecting the processes. 2 Right-click and choose Import Workflow Process. The Open dialog box appears. 3 Select a path and filename of the process to import, and then click Open. The process is imported with a status of In Progress. NOTE: If a process definition of the same name exists in the target environment, the newly imported process definition’s version number will be incremented by one. Administering Workflow Processes in the Run-Time Client You use the Administration - Business Process views in the run-time client to administer workflow processes created in Siebel Tools. The Administration - Business Process views include the following: ■ Workflow Deployment view. For deploying and activating workflow processes. From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Deployment. This view shows the parent/child relationship between a workflow process and its run-time records. For detailed information on a selected workflow process, drill down on the process name in the top applet to navigate to a form applet. ■ Active Workflow Processes view. This is a child view of the Workflow Deployment view (Repository Workflow Processes list applet), appearing as a tab. This view lists all workflow process definitions that have been deployed in the system. ■ Child Items. This is a child view of the Workflow Deployment view (Repository Workflow Processes list applet), appearing as a tab. Select a workflow process record in the parent list applet, and the child applet will filter to display only process definitions of the same process name. ■ Workflow Instance Admin view. For viewing and controlling workflow processes that are in a running state, a waiting state (persisted workflows), and an error state. For a selected instance, you can change the value of the process properties before resuming the instance. From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Instance Admin. 188 Siebel Business Process Framework: Workflow Guide Version 8.0
    189. For Administrators: Administering Workflow Processes ■ Administering Workflow Processes in the Run-Time Client ■ Workflow Instance Monitor view. For monitoring all workflow process instances in all states, as well as step instances and aggregate data. An instance that is completed moves from the Workflow Instance Admin view to appear in the Workflow Instance Monitor view (when the Monitoring flag is set). From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Instance Monitor. ■ Workflow Processes view. For reviewing pre-7.7 workflow process definitions. From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Processes. NOTE: The Workflow Processes view and its child views listed below are read-only views used only for reviewing pre-7.7 workflow processes. You view any new workflows that you create in the Workflow Processes OBLE in Siebel Tools. ■ Process Definition view. For reviewing the definitions of pre-7.7 workflow processes. From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Processes > Process Definition. ■ Process Designer view. For reviewing the process flow diagrams of pre-7.7 workflow processes. From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Processes > Process Designer. ■ Process Properties view. For reviewing the properties of pre-7.7 workflow processes. From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Processes > Process Properties. Workflow process instances are stored in the following tables: S_WFA_INSTANCE S_WFA_INST_PROP S_WFA_INST_WAIT Workflow instance monitoring information is stored in the following tables: S_WFA_INST_LOG S_WFA_INSTP_LOG S_WFA_STPRP_LOG Information on administering workflow process instances is organized as follows: ■ “Viewing Run-time Instances of a Workflow Process” on page 190 ■ “Stopping a Workflow Process Instance” on page 190 ■ “Stopping All Workflow Process Instances of a Specific Process Definition” on page 190 ■ “Deactivating a Workflow Process Instance” on page 191 ■ “Expiring a Workflow Process Instance” on page 192 ■ “Purging a Workflow Process Instance from the Log” on page 192 Siebel Business Process Framework: Workflow Guide Version 8.0 18 9
    190. For Administrators: Administering Workflow Processes ■ Administering Workflow Processes in the Run-Time Client Viewing Run-time Instances of a Workflow Process You can view a workflow’s run-time instances in the Workflow Instance Admin view. To view run-time instances for a workflow process 1 Navigate to Site Map > Administration - Business Process > Workflow Instance Admin. 2 In the All Workflow Process Instances applet, select the workflow. 3 In the Related Instances child applet, you can view the workflow’s run-time instances and their parameters. Stopping a Workflow Process Instance From within the Workflow Instance Admin view, Workflow administrators can stop a process instance if persistence is defined. After a workflow process instance is stopped, it is removed from the system. Process instances with a status of Running, Waiting, or Error can be stopped. NOTE: If you stop a running workflow process instance, the execution of the process instance is terminated. This is different from purging a workflow process instance from the monitoring log. See “Purging a Workflow Process Instance from the Log” on page 192. To stop a process instance 1 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Instance Admin. 2 In the All Workflow Process Instances applet, select the workflow. 3 In the Related Instances applet, select the process instance to stop. 4 In the applet menu, choose Stop Instance. CAUTION: Stopped processes cannot be resumed. Stopping All Workflow Process Instances of a Specific Process Definition You can stop all workflow process instances of a specific process definition in the Workflow Deployment view. If you know the specific instance you want to stop, stop the workflow process from the Workflow Instance Admin view. See “Stopping a Workflow Process Instance” on page 190. 190 Siebel Business Process Framework: Workflow Guide Version 8.0
    191. For Administrators: Administering Workflow Processes ■ Administering Workflow Processes in the Run-Time Client If you want to stop all process instances of a specific version of a workflow process definition, then you can delete the process definition from within the Workflow Deployment view. NOTE: Deleting a process definition from the Workflow Deployment view will not only remove a process definition from the run time. It will also stop all process instances of the deleted process definition. To stop all process instances of a workflow process definition NOTE: Using Multi-select, you can select multiple process definitions for deletion. Because the Delete Process functionality deletes a process definition and stops all the process instances of that definition, all process instances related to the selected definitions will also be stopped as a result of the deletion. So, if you want to perform a batch delete of multiple workflow processes, follow the steps below, using Multi-select to choose multiple workflow processes rather than just one. 1 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Deployment > Active Workflow Processes. 2 Select the process instance. 3 From the applet menu, select Delete Process. Deactivating a Workflow Process Instance In the Active Workflow Processes tab of the Workflow Deployment view, you can deactivate a single instance of a workflow process, or multiple process instances in one batch. To deactivate a workflow process instance 1 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Deployment > Active Workflow Processes. 2 Select the process instance you want to deactivate. 3 From the applet menu, choose Deactivate Process. The status of the selected process instance for the workflow process is changed to Inactive. To deactivate workflow process instances in batch 1 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Deployment > Active Workflow Processes. 2 Select the process instances you want to deactivate. Hold down the CTRL key while selecting process instances, or if you have performed a query to access the workflow processes you want to deactivate, choose Select all from the applet menu. 3 From the applet menu, choose Deactivate Process. The status of all selected process instances for the workflow process is changed to Inactive. Siebel Business Process Framework: Workflow Guide Version 8.0 19 1
    192. For Administrators: Administering Workflow Processes ■ Administering Workflow Processes in the Run-Time Client Expiring a Workflow Process Instance This administrative procedure is performed in Siebel Tools, not in the run-time client. To expire a workflow process instance 1 In Siebel Tools, enable the Workflow/Task Editor toolbar by choosing View > Toolbars > WF/Task Editor Toolbar. 2 In the Object Explorer, select the Workflow Process object. 3 In the Object List Editor, select the workflow process that you want to expire. 4 Lock the project in which the selected workflow process was created. a From the application menu, choose Tools > Lock Project 5 In the WF/Task Editor toolbar, click the Expire button. The Expire button is the button at the far right of the WF/Task Editor toolbar, as shown below. Purging a Workflow Process Instance from the Log Using the purge function, an administrator can delete all process instances with a status of Stopped or Completed before the user-specified date. If you want to delete a paused instance, stop the instance first. NOTE: If you delete a running workflow process instance from the log, the execution of the process instance is unaffected and the workflow process will continue to run. To purge all process instances from the log 1 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Instance Monitor > Process Instances. 2 In the Workflow Process list, select the workflow. 3 Click Purge. 4 In the Workflow Instance Monitor Purge dialog box, select a date. 5 Click Purge. 192 Siebel Business Process Framework: Workflow Guide Version 8.0
    193. For Administrators: Administering Workflow Processes ■ Activating Fields Used by Workflow Processes Activating Fields Used by Workflow Processes Fields that are not activated by the Object Manager must be activated in order for Workflow to be able to reference and use them. When fields are exposed on the user interface, they are activated by the Object Manager, so workflow processes (running on the Object Manager) that reference these fields are able to run properly. But when fields are not exposed on the user interface, they are not activated by the Object Manager. In this case, a workflow process running on the Object Manager cannot use these fields, and an error is generated. To activate the fields necessary for a workflow process to run, do one of the following: ■ Expose the fields on the user interface. ■ At the business component level, explicitly activate the fields by setting the fields’ property Force Active = TRUE. Monitoring and Troubleshooting Workflow Processes in Production You monitor and control workflow process execution in the Administration - Business Process views of the run-time client. You can use the tools described below to monitor and troubleshoot Workflow in the production environment. ■ Progress and status information. Use the Workflow Instance Monitor view and the Workflow Instance Admin view to monitor the progress and status of each process instance. For details, see “About Workflow Process Monitoring” on page 193 and “Setting Workflow Process Monitoring Levels” on page 195. ■ Operation details. Use the event logging facility to trace operations performed by each processing step of a Workflow application. For details, see “Setting Tracing and Event Log Levels” on page 196. ■ Performance-measurement data. Use Siebel ARM to capture timing data for measuring performance of Workflow applications. For details, see “Capturing Data with Siebel Application Response Management (Siebel ARM)” on page 197. ■ Failure-analysis records. In case of a system failure, Siebel FDR (Flight Data Recorder) automatically captures the events that may have led to a system failure. For details, see “Recording Behavior with Siebel Flight Data Recorder (FDR) Files” on page 198. You can troubleshoot production workflows with one or a combination of the tools mentioned above. For troubleshooting techniques, see “Troubleshooting Workflow Processes in a Production Environment” on page 198. About Workflow Process Monitoring There are two views you can use to monitor workflow processes: Siebel Business Process Framework: Workflow Guide Version 8.0 19 3
    194. For Administrators: Administering Workflow Processes ■ Monitoring and Troubleshooting Workflow Processes in Production ■ Workflow Instance Monitor view ■ Workflow Instance Admin view Workflow Instance Monitor View Use this view to see the history of all workflow process instances in all states, as well as step instances and aggregate data. When the Monitoring flag is set for a deployed workflow process definition, the workflow process instance remains in the Workflow Instance Monitor view after it has completed and is no longer visible in the Workflow Instance Admin view. The Workflow Instance Monitor view provides a log of workflow instances. From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Instance Monitor. The top applet in this view lists workflow definitions. NOTE: The top applet shows the workflow definitions for all workflow processes that have monitoring turned on, that is, the Monitoring Level is not NONE. The other applets in this view are the following: ■ Process Instances. This applet shows the related log instances for the selected workflow process. ■ Step Instances. This applet shows the steps and process properties for the selected process instance. ■ Aggregate Data. This applet shows aggregate data as a chart view for the selected workflow process. NOTE: Depending on the monitoring level set for the selected workflow process, you may see no records in the Step Instances and Aggregate Data applets. Workflow Instance Admin View Use this view for monitoring running workflow processes. This view shows all processes that are in running, waiting, and error states and that have persistence set. Persistence is set if the workflow process has a Wait step or the workflow’s Auto Persist flag is checked (for 7.0 workflows). From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Instance Admin. The top applet in this view lists all workflow process instances that are running, in an error state, or in a waiting state. The other applets in this view are the following: ■ Related Instances. This applet shows the associated processes for the selected parent workflow process—subprocesses and error processes. ■ Process Properties. This applet shows the process properties for the process instance selected in the Related Instances applet. You can change the value of these process properties before resuming an instance that is waiting or in an error state. 194 Siebel Business Process Framework: Workflow Guide Version 8.0
    195. For Administrators: Administering Workflow Processes ■ Monitoring and Troubleshooting Workflow Processes in Production Setting Workflow Process Monitoring Levels You set deployment parameters to determine the way you monitor your workflow processes. These deployment parameters are Monitoring Level and Log-writing Frequency. Monitoring Level Parameters Table 25 shows the monitoring level parameters (and their corresponding log-writing frequencies) that you can set for a workflow process. When the workflow instance is created, the monitoring level is read from the workflow process definition and stays throughout the lifetime of the instance unless the instance is paused. In the case of an instance being paused, when the instance is resumed, the monitor level is reread from the definition. Table 25. Monitoring Level Parameters Record Process Record Step Record Process Monitoring Level Instance Instances Properties 0 None N None None 1 Status Y None None 2 Progress Y All Steps None 3 Detail Y All Steps All Steps 4 Debug Y All Steps All Steps To set the Monitoring Level parameter 1 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Deployment. 2 In the Active Workflow Processes applet, complete the Monitoring Level field. Use Table 25 as a reference on the various levels you can choose and what each level records. Log-writing Frequency Parameters Log-writing frequency determines the frequency at which monitoring data is written to the disk. The frequency is optimized internally by the Workflow run-time environment, based on the workflow type and the monitoring level you select. At the Debug monitoring level, the log is written to the disk after every step. NOTE: Enabling monitoring at any level incurs performance overhead to your workflow processes. It is best to set the monitoring level to 0 (None) or 1 (Status) on workflow processes running in production. Monitoring levels of 2(Progress) and higher should only be used for the debugging of workflow processes. Siebel Business Process Framework: Workflow Guide Version 8.0 19 5
    196. For Administrators: Administering Workflow Processes ■ Monitoring and Troubleshooting Workflow Processes in Production Monitoring Levels and 7.0 Compatibility 7.0 workflows with persistence frequency and persistence level set are mapped to a monitoring level based on the following logic: ■ 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, persistence is explicitly turned on and the monitoring level is set as follows: ■ 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. NOTE: In this release, persistence and monitoring are separate features that serve different functions. Persistence is a quality of service and is controlled at definition time. Monitoring is an administrative tool and is controlled at deployment time. Monitoring has no impact on the way a workflow process functions. Setting Tracing and Event Log Levels You can use tracing levels to troubleshoot workflow processes. Table 26 lists the events that Siebel Workflow uses for logging. Table 26. Workflow Process Logging Events Event Level Description Workflow Definition 3 Traces process and step definitions loaded into memory. Loading Workflow Engine 4 Trace methods invoked and arguments passed to the Workflow Invoked engine. Workflow Process 4 Trace workflow process execution. Execution Workflow Step 4 Trace workflow step execution. Execution Workflow Performance 4 Measure overall process execution time. Workflow Performance 5 Measure process and step execution time. Workflow Recovery 3 Trace instance recovery status and progress (applicable only to the Workflow Recovery Manager server component). Workflow Recovery 4 Trace instance recovery details (applicable only to the Workflow Recovery Manager server component). NOTE: Setting trace levels above the default parameters will affect performance. Trace levels should be reset to default parameters after troubleshooting has been completed. 196 Siebel Business Process Framework: Workflow Guide Version 8.0
    197. For Administrators: Administering Workflow Processes ■ Monitoring and Troubleshooting Workflow Processes in Production Increasing Tracing Levels for Workflow Management Server Components You can generate a more detailed trace file to assist in troubleshooting Workflow Process Manager, Workflow Process Batch Manager, and Workflow Recovery Manager. NOTE: Complete these steps prior to executing the server process. To increase tracing levels 1 From the application-level menu, choose Navigate > Site Map > Administration - Server Configuration > Servers > Components > Events. 2 In the Components applet, choose the component for which you want to generate tracing: the Workflow Process Manager, the Workflow Process Batch Manager, or the Workflow Recovery Manager. 3 Click the Events tab to view all the configurable event types for the selected component. The log level is set to a default value of 1. 4 Change the log level value to 3, 4, or 5. Use Table 26 on page 196 to make your choice. 5 (Optional) For additional troubleshooting, you may want to repeat Step 4 to increase the tracing level for the Object Manager SQL log event. NOTE: 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. Capturing Data with Siebel Application Response Management (Siebel ARM) The Workflow Process Manager server component is enabled for Siebel Application Response Measurement (Siebel ARM). Siebel ARM captures timing data useful for monitoring the performance of the Siebel application, and records this information to binary files. Siebel ARM settings affect the Workflow Process Manager as follows: When the Siebel ARM level is set to 1, the Workflow Process Manager business service records: ■ The time it takes to execute a service method Examples of service methods in Workflow Process Manager are RunProcess and ResumeInstance. When the Siebel ARM level is set to 2, the Workflow Process Manager business service records: ■ The time it takes to execute a service method ■ The time it takes to execute a workflow step ■ The time it takes to write monitoring data to the disk Siebel ARM level 2 can help you determine the logging overhead when you increase the monitoring level of your workflow process. Siebel Business Process Framework: Workflow Guide Version 8.0 19 7
    198. For Administrators: Administering Workflow Processes ■ Monitoring and Troubleshooting Workflow Processes in Production Table 27 shows the Siebel ARM areas and subareas defined for Siebel Workflow, and their Siebel ARM levels. Table 27. Siebel ARM Areas and Levels Area Sub-area Level Description WORKFLOW CORDR_RESUME 1 Resume a suspended process. WORKFLOW CORDR_EXECUTE 1 Execute a process. WORKFLOW ENGNE_INVOKE 1 Invoke a Workflow Process Manager service method. WORKFLOW STEPS_EXSTEP 2 Execute a step. WORKFLOW MONTR_WRTE 2 Write process monitoring data to disk. For more information on enabling Siebel ARM and the Siebel ARM analyzer, see Siebel Performance Tuning Guide. Recording Behavior with Siebel Flight Data Recorder (FDR) Files Siebel flight data recorder log files (extension .fdr) are records of system and server component behavior at run time. In the event of a system or server component failure, the settings and events leading up to the failure are captured and logged. The Siebel flight data recorder log file can then be forwarded to Siebel Technical Support and used to troubleshoot and analyze the specific settings and events that occurred prior to the failure. The Siebel flight data recorder log files are stored in the Binary subdirectory of the Siebel Server root directory. FDR instrumentation points have been embedded in the Workflow Process Manager business service and the Workflow Recovery Manager business service to provide capture-processing details in case of a system failure or server component failure. For more information on Siebel flight data recorder files, see Siebel System Monitoring and Diagnostics Guide. Troubleshooting Workflow Processes in a Production Environment You can troubleshoot Workflows in the production environment in the following ways: ■ Tracing ■ Instance monitoring ■ Using the Business Service Simulator 198 Siebel Business Process Framework: Workflow Guide Version 8.0
    199. For Administrators: Administering Workflow Processes ■ Monitoring and Troubleshooting Workflow Processes in Production To troubleshoot a workflow process using tracing 1 Turn on tracing for the appropriate component running the workflow: 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 Tracing and Event Log Levels” on page 196. To troubleshoot a workflow process using instance monitoring 1 Navigate to Site Map > Administration - Business Process > Workflow Deployment. 2 In the Active Workflow Processes applet, select the workflow process. 3 Set the monitoring level to 3-Detail or 4-Debug. At this level, each execution of a process (from whichever component it is run) will record state and process properties values for each step. 4 View the monitoring information in the Workflow Instance Monitor views. a Navigate to Site Map > Administration - Business Process > Workflow Instance Monitor > Process Instances (or Step Instances). NOTE: The monitoring levels of 3-Detail and 4-Debug affect performance of the Workflow engine. For this reason, these settings should be used for troubleshooting purpose only. To troubleshoot a workflow process using the Business Service Simulator 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. a Navigate to Site Map > Administration - Business Service > Simulator. b In the Simulator applet, create a new record and set the following fields: Service Name: Workflow Process Manager Method Name: RunProcess Iterations: 1 c In the Input Arguments applet, create a new record, and do the following: ❏ Set the Test Case # field to 1. ❏ Select and open the Property Name field. The Property Name field opens a multi-value applet. d In the multi-value applet, click New and set the following fields: ❏ Property Name: ProcessName ❏ Value: <Enter the name of the workflow process> e Click Save. Siebel Business Process Framework: Workflow Guide Version 8.0 19 9
    200. For Administrators: Administering Workflow Processes ■ Monitoring and Troubleshooting Workflow Processes in Production f Repeat Step d and Step e for any parameter that should be passed to the process, especially RowId if necessary. g In the multi-value applet, click OK. h In the Simulator applet of the Simulator view, click Run. NOTE: You may want to set the monitoring level to 4-Debug (as described in “To troubleshoot a workflow process using instance monitoring” on page 199, then launch the workflow this way, and then view the process execution information in the Workflow Instance Monitor views. Communicating Workflow Errors to Siebel Technical Services You can communicate workflow errors to Siebel support professionals in the following ways: ■ Send the log files (as generated by turning on tracing, described in “To troubleshoot a workflow process using tracing” on page 199. ■ Communicate the error code and error message. With the exception of service flows, when a workflow process encounters an error, the process state is persisted with a status of “In-Error.” If a workflow process encounters an error in one of its subprocesses, the subprocess state is also persisted. Both the error code and the error message are saved in the process properties. Administrators can examine the error codes and error messages in the Process Properties applet of the Workflow Process Instance Admin view. When a record is selected from the All Workflow Process Instances list, the related instance applet lists its parent and child processes. You can communicate the error code and the error message to Technical Services for further assistance. Resolving Workflow Process Execution Problems This topic provides guidelines for resolving workflow process execution problems. 200 Siebel Business Process Framework: Workflow Guide Version 8.0
    201. For Administrators: Administering Workflow Processes ■ Monitoring and Troubleshooting Workflow Processes in Production To resolve the problem, look for it in the list of Symptoms/Error messages in Table 28. Table 28. Resolving Workflow Process Execution Problems Symptom/Error Message Diagnostic Steps/Cause Solution After activating a workflow, it Verify that <Reload Runtime is not executing when the Events> has performed. In order corresponding run-time event to tell if a workflow process has is triggered. been triggered, turn on workflow logging (EngInv, StpExec, PrcExec). See “Increasing Tracing Levels for Workflow Management Server Components” on page 197. After revising a workflow and For workflows running in the reactivating it, the revised Workflow Process Manager server workflow information has not component, reset the parameter been read. <Workflow Version Checking Interval>. By default the interval is 60 minutes. When a workflow is triggered Since the DisplayApplet event To make the field still work in this by the run-time event is a UI event, and the default scenario, you can explicitly set DisplayApplet, the workflow Web UI framework design is EnableViewCache to FALSE in the is triggered the first time but to use cache, the event only .cfg file. not subsequently. fired when the first time non- cached view is accessed. The workflow was triggered only when the event fired and worked correctly. After triggering a workflow The run-time event passes Retrieve the row ID of the active from a run-time event, the the row ID of the object BC business component using search row ID of the record on which (that is, the primary business specifications (for example: the event occurred is not component) and not the row Active_row-id (process property) retrieved. ID of the business component = [Id] defined as Type = on which the run-time event Expression and BC = BC name). is acting. Siebel Business Process Framework: Workflow Guide Version 8.0 20 1
    202. For Administrators: Administering Workflow Processes ■ Monitoring and Troubleshooting Workflow Processes in Production Table 28. Resolving Workflow Process Execution Problems Symptom/Error Message Diagnostic Steps/Cause Solution “<Cannot resume Process This error typically occurs in Deleting existing instances does <x-xxxxx> for Object-id <x- the following scenario: not help. You should ignore the xxxxx>. Please verify that error message and proceed. the process exists and has a 1 A workflow instance is Step 1 through Step 3 need to started and paused, waiting status.” occur, in that order, in the same waiting for a run-time user session for the error event. message to be reported. As a 2 The run-time event fires. result, the error message The workflow instance is disappears when the application is resumed and run to re-started. completion. The Purge feature only works on 3 The run-time event fires stopped and completed instances. for a second time. The In order to delete persisted or Workflow engine tries to incomplete instances, you first resume the workflow need to manually stop the instance and fails, since instances. the workflow instance is no longer in a Waiting state. Unable to access a different The Workflow architecture Use a subprocess step to access a business object from a restricts the use of one different business object. workflow process. business object to a workflow. The Workflow Process Verify the following: Manager returns the error ■ the workflow process exists “Unable to initiate the process definition <process ■ the process status is set to name>.” Active ■ the process has not expired. OMS-00107: (: 0) error code Make sure at least one .SRF is = 4300107, system error = copied to the Siebel 27869, msg1 = Could not find Serverobjects<lang> directory. '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' 202 Siebel Business Process Framework: Workflow Guide Version 8.0
    203. 10 Workflow Policies This chapter provides information about how to use workflow policies. The information is organized as follows: ■ “About Planning Workflow Policies” on page 203 ■ “About Creating Workflow Policies” on page 209 ■ “About Customizing Workflow Policies with Siebel Tools” on page 235 ■ “About Workflow Policies Server Administration” on page 263 ■ “About Workflow Policies and Siebel Marketing” on page 287 ■ “About Testing Workflow Policies” on page 292 ■ “Migrating Policies to the Production Environment” on page 294 ■ “Predefined Programs” on page 295 About Planning Workflow Policies Information on planning activities for workflow policies is provided in the following topics: ■ “Planning Workflow Policy Groups” on page 203 ■ “Planning Workflow Policies” on page 204 ■ “Determining What to Monitor When Planning Policies” on page 205 ■ “Planning Policies and Conditions” on page 205 ■ “Planning Workflow Policy Actions” on page 206 ■ “Scenario for Planning Workflow Policies: Notification for 30%+ Discounts” on page 206 ■ “Scenario for Planning Workflow Policies: Notification for Large Number of Open Service Requests” on page 208 ■ “Defining a Test and Migration Strategy for Workflow Policies” on page 209 Planning Workflow Policy Groups Before you create your Workflow policies, you need to create workflow policy groups. Each Workflow Policy Agent is assigned one workflow policy group. If you are going to run only one Workflow Policy Monitor Agent and one Workflow Policy Action Agent, assign all your policies to one policy group. The reasons to use multiple Workflow Policy Agents are: Siebel Business Process Framework: Workflow Guide Version 8.0 20 3
    204. Workflow Policies ■ About Planning Workflow Policies ■ To shorten the time between when the policy event is triggered and when Workflow Policies notices the event ■ To spread the workload across multiple application servers ■ To adjust the polling interval so that polling for noncritical policies does not prevent efficient processing of critical policies Policies with similar time intervals are generally grouped together. By creating groups of policies with similar time intervals, you can assign the workflow policy group a Workflow Policy Agent with a polling rate that matches the needs of the workflow policies—creating a more efficient use of your resources. Creating workflow policy groups and using multiple Workflow Policy Agents are part of tuning your system to create the highest performance and can be done as you monitor your system’s performance. NOTE: The maximum number of policies in a single policy group is MaxInt. The maximum number of policies in all policy groups is determined by the maximum number of records in table S_ESCL_RULE. Planning Workflow Policies Once you have gathered policy information, you can begin to plan the workflow policies. Many of the workflow policy objects and programs you need to create your workflow policies have been predefined by Siebel. However, you can use Siebel Tools to augment programs, create additional workflow policy objects, or make additional workflow policy columns available for monitoring. See “About Customizing Workflow Policies with Siebel Tools” on page 235 for more information on how to perform these tasks. The planning phase is a good time to review your company’s business process activities. You want to determine which work can be automated with Workflow Policies and then prioritize the implementation sequence. It is always a good idea to create 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. See “About Creating Workflow Policies” on page 209 for more information on creating workflow policies. NOTE: After planning a new workflow policy, test the policy definition by creating a query based on the policy. Then you can execute the query on your current production environment. The query response can help you determine the frequency of the workflow conditions. You may find that a policy creates excessive notification or insufficient visibility. See “About Testing Workflow Policies” on page 292 for more information. 204 Siebel Business Process Framework: Workflow Guide Version 8.0
    205. Workflow Policies ■ About Planning Workflow Policies Determining What to Monitor When Planning Policies The first step in planning is to identify the purpose of the policy and the specific database information that needs to be monitored. For example, if the service department wants to send an email to the service request contact whenever a service request is opened with a severity level of critical, the information to record would be that which is listed in Table 29. Table 29. Determining What to Monitor What to Monitor Purpose of the Policy Service request status Send an email to the service request contact when the service request is opened and its severity level is critical. Service request severity Planning Policies and Conditions The second step in planning is to define the policy properties and conditions, identify the workflow policy object to be monitored in the Siebel database, and determine the monitoring interval period and duration. Table 30 illustrates the type of information you need to model the general policy definition in terms of Workflow Policies. It shows the workflow policy name as Email Confirmation of SR, the workflow policy object is Service Request, monitoring interval period (Workflow Group) is Medium Frequency, and the duration is set to 0. Table 30. Planning Policies Name Workflow Object Workflow Group Duration Email Confirmation of SR Service Request Medium Frequency 0 NOTE: Duration indicates the time element that must be met before an action is performed. Each workflow policy has one duration, so if you need to cause an action to occur after one hour, two hours, and six hours, you must create a different policy for each duration. After you determine your policy’s workflow object and other properties, you need to define the workflow conditions, as shown in Table 31. Conditions are in the form of an expression. Table 31. Workflow Policy Conditions Field (Column Monitored in the Database) Comparison Value Service Request Severity = 1-Critical Service Request Status = Open Siebel Business Process Framework: Workflow Guide Version 8.0 20 5
    206. Workflow Policies ■ About Planning Workflow Policies Workflow policy condition values are read directly from any picklist specified at the table column level. The values called for by the condition operation you specify, such as IN/NOT IN, must be available in the column policy picklist, or else the policy cannot trigger the action. Planning Workflow Policy Actions The third step in planning is to define the policy actions. A policy action is executed when the conditions of the policy have been met. Table 32 illustrates the type of information you need to define a workflow policy action. Table 32. Workflow Policy Actions Action Name Program Workflow Object Arguments Send SR Email to Contact Send SR Email Service Request Send to Contact NOTE: Workflow Policies comes with a set of predefined actions and programs. You can use these or define your own actions or programs to suit your business needs. Scenario for Planning Workflow Policies: Notification for 30%+ Discounts In this scenario, the sales department manager wants to be automatically notified whenever sales representatives quote discounts over 30%. Table 33 lists a workflow policy that monitors quotes with a discount exceeding 30%, for which the purpose is to notify the sales manager to review and approve the quote. Table 33. Determining What to Monitor What to Monitor Purpose of the Policy Quotes with a discount exceeding 30% Notify Sales Manager to review and approve the need Sales Manager approval quote. 206 Siebel Business Process Framework: Workflow Guide Version 8.0
    207. Workflow Policies ■ About Planning Workflow Policies Table 34 shows the workflow policy name as Notify Sales Manager on Sales Approval. The workflow policy object is Quote, the workflow policy group is Low Frequency, the duration is set to 0, and the quantity is set to 5. This means that the workflow policy action occurs as soon as five new quotes meet the criteria of the workflow policy conditions. Table 34. Planning Policies Workflow Workflow Name Object Group Duration Quantity Comments Notify Sales Manager Quote Low 0 5 Notify the manager on Sales Approval Frequency when a quote with a discount over 30% is created. Table 35 illustrates the type of information you need for the policy conditions. Table 35. Workflow Policy Conditions Field (Column Monitored in the Database) Comparison Value Quote Status = In Progress Quote Item Discount Percent > 30 Next, define 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, using dynamic values. Table 36 lists definitions for the Send Email to Sales Manager action. Table 36. Actions and Action Arguments Workflow Action Name Program Object Arguments and Substitutions Send Email to Sales Send Quote Quote Subject: Please approve quote discount Manager Email 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 quotes also need approval [Quote Number] Siebel Business Process Framework: Workflow Guide Version 8.0 20 7
    208. Workflow Policies ■ About Planning Workflow Policies Scenario for Planning Workflow Policies: Notification for Large Number of Open Service Requests In this scenario, the service department wants to automate its notification policy when the number of open requests for an agent reach a critical mass of 20. The tables below show the information needed to define this type of workflow policy. Table 37 represents the general policy definition. Table 37. Determining What to Monitor What to Monitor? Purpose of the Policy Monitor open service requests when Send a Message Broadcast to the service representative they reach a quantity of 20 to alert the representative about the situation. Next, model the general policy definition in terms of Workflow Policies. Table 38. Workflow Policies Name Workflow Object Workflow Group Quantity Over 20 Open Service Service Request High Frequency 20 Requests Table 38 shows the policy name is Over 20 Open Service Requests, workflow policy object is Service Request, workflow policy group is High Frequency, and the quantity is 20. After you determine the policy’s workflow object and other properties, define the workflow conditions for your workflow policy. Table 39 shows the workflow condition definitions. Table 39. Workflow Conditions Field (Column Monitored in the Database) Comparison Value Service Request Status = Open 208 Siebel Business Process Framework: Workflow Guide Version 8.0
    209. Workflow Policies ■ About Creating Workflow Policies Define the workflow policy actions that occur when the conditions of the policy are met. You can also define the action arguments. Table 40 on page 209 shows the action argument definitions. Table 40. Actions and Action Arguments Workflow Action Name Program Object Arguments and Substitutions Alert Agent of Open SR Send SR Service Abstract: You have over 20 service Message Request requests Broadcast Message Template: You have over 20 service requests. Please review your service request queue. Defining a Test and Migration Strategy for Workflow Policies Before implementing new workflow policies, you must verify them in a test environment consisting of a sample Siebel database and workflow policies test data. Testing new policies, conditions, and actions checks that the policy you release into the production environment properly executes and does not cause conflicts with your existing workflow policies. The following are some suggestions for setting up your test and migration policy: ■ Make sure your test environment and production environment have identical versions of the software and that you are using realistic data in your database by using a partial or complete copy of the production database. ■ Create a small group of workflow policies to implement as a first phase of implementation. After you have successfully implemented the first group, you can add more policies in a systematic manner. ■ To verify a new workflow policy, go to your production environment, manually create a query based on the new policy, and check the response. This helps you determine if a policy creates excessive notification or misses the rows you want to monitor. For more information on migrating your test environment to your production environment, see “Migrating Policies to the Production Environment” on page 294. About Creating Workflow Policies Information about creating Workflow policies is provided as follows: ■ “About the Workflow Policies Views” on page 210 ■ “Defining Workflow Policy Actions” on page 210 ■ “Using the Send Page Program Type” on page 212 ■ “Using the Send Message Program Type” on page 213 Siebel Business Process Framework: Workflow Guide Version 8.0 20 9
    210. Workflow Policies ■ About Creating Workflow Policies ■ “Using the Message Broadcast Program Type” on page 214 ■ “Using the Run External Programs Type” on page 215 ■ “Using the Database Operation Program Type” on page 215 ■ “Creating a Workflow Policy Action” on page 218 ■ “Creating Workflow Policy Groups” on page 224 ■ “Creating Workflow Policies” on page 225 About the Workflow Policies Views The views you use to create and define workflow policies are a part of the Siebel Workflow run-time client. To display the Workflow Policies view, you navigate to Workflow Policies in the Administration - Business Process screens of Site Map. Several views are used when you create Workflow policies. These views include: ■ Workflow Policies Action view. Use to create the actions you want to use with your workflow policies. See “Defining Workflow Policy Actions” on page 210. ■ Workflow Policies Groups view. Use to create the workflow policy groups to use with workflow policies. See “Creating Workflow Policy Groups” on page 224. ■ Workflow Policies Policies view. Use to create workflow policies. See “Creating Workflow Policies” on page 225. ■ Workflow Policies Explorer view. Use to review the currently defined workflow policy objects. ■ Workflow Policies Log view. Use to review the workflow policy monitor log, to check policy trends, and to check policy frequency. Defining Workflow Policy Actions Workflow policy actions are events that you want to occur when the conditions of your workflow policy are met. You must create the appropriate workflow policy actions before you create the policy that will use the actions. In the run-time client, you use the Workflow Policies Action view to define policy actions. This view and its associated fields are described below. For the procedure on creating a workflow policies action, go to “Creating a Workflow Policy Action” on page 218. The Workflow Policies Action view consists of three applets. These applets are: ■ Actions applet. This is where you create a name for your action and choose the appropriate program. See “About the Actions Applet in the Workflow Policies Action View” on page 211. ■ Arguments applet. This is where you define the arguments for the action. The format of the Arguments applet changes depending on the program type of the action. See “About the Arguments Applet in the Workflow Policies Action View” on page 211. 210 Siebel Business Process Framework: Workflow Guide Version 8.0
    211. Workflow Policies ■ About Creating Workflow Policies ■ Recipients applet. This is the contact name, employee name, position, or relative of the workflow policy object that can receive an email, page, or message broadcast. See “About the Recipients Applet” on page 217. NOTE: You cannot invoke DLLs or external functions using workflow policy actions. Use workflow processes for this. About the Actions Applet in the Workflow Policies Action View Table 41 describes the fields of the Workflow Policies Actions applet. Table 41. Actions Applet Fields Field Description Possible Value Name The name of the workflow policy action. A descriptive name that is: ■ Consistent with your overall naming strategy ■ Meaningful to the policy maker Program The workflow policies program This program is chosen from a picklist. associated with the action. See “Predefined Programs” on page 295 Workflow Workflow policy object that this action is Chosen from a picklist of workflow Object associated with. This action is now policy objects. available only to policies that are based on this workflow policy object. Comments Comments describing the purpose or use Any text. of this action. About the Arguments Applet in the Workflow Policies Action View The format of the Workflow Policies Arguments applet varies, depending on the program type you select for the workflow policy action. NOTE: Program arguments are case sensitive. You must enter the correct case. Use the argument picklists when possible instead of entering the arguments yourself. This section describes each workflow policy program type, the available workflow policy program arguments and valid values, and some usage scenarios. The available workflow policy program types are: ■ Send Page. See “Using the Send Page Program Type” on page 212. ■ Send Message. See “Using the Send Message Program Type” on page 213. Siebel Business Process Framework: Workflow Guide Version 8.0 21 1
    212. Workflow Policies ■ About Creating Workflow Policies ■ Message Broadcast. See “Using the Message Broadcast Program Type” on page 214. ■ Run External. See “Using the Run External Programs Type” on page 215. ■ Database Operation. See “Using the Database Operation Program Type” on page 215. NOTE: Before using the email or paging functions, you need to perform the setup procedures described in “About Workflow Policies Server Administration” on page 263 Using the Send Page Program Type The Send Page Arguments applet displays if you select the Send Page workflow policy program type in the Workflow Policies Actions applet. Send Page Arguments and Values Table 42 shows the arguments and valid values for the Send Page workflow policy program type. NOTE: Numeric paging is inherently unreliable because of a lack of a computer protocol for sending numeric pages. If you must send a numeric page, you can use the Pager Pin field in the employee table to control the delay 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 mission critical applications. Table 42. Send Page Program Type Argument Valid Values When Used by Action Numeric Message Numeric message when pager is numeric. Template Alpha Message Text message when pager is alphanumeric. Template “Current” is a reserved word in Siebel Workflow. Do not use this word in messages. Available Dynamic fields that you can use in the Alpha Message Template. Substitutions When the action executes, the substitution value is populated with the value from the record that meets all the workflow policy conditions. Request Key A string indicating which Page Manager should execute the action. You use this when multiple Page Managers are running. When you specify a request key string, it should match the Request Key parameter of the Page Manager that you want to execute the action. Leave this argument blank when you are running one Page Manager or when the Page Manager that executes the action is not important. When setting the Send Page arguments, note the following: ■ Siebel Workflow Policies automatically determines the correctly formatted message depending on what type of pager the person being paged has. 212 Siebel Business Process Framework: Workflow Guide Version 8.0
    213. Workflow Policies ■ About Creating Workflow Policies ■ If neither of the message arguments has a value, Workflow Policies logs an error message and the action is not completed. ■ You can send only pages to employees. The pager information for an employee is stored in the Employee Administration view. The Siebel database currently does not store pager information for contacts. ■ Messages support substitution of values that come from the Available Substitutions field. Using the Send Message Program Type When you select the Send Email workflow policy program in the Actions applet, the Send Message Arguments applet displays along with the Recipients applet. The Send Message Arguments applet allows you to create an email template used to build the message sent to the recipient specified in the Recipients applet. Send Email Arguments and Values Table 43 shows the arguments and valid values for the Send Email workflow policy program type. Table 43. Send Email Workflow Policy Program Type Argument Valid Values When Used by Action Subject Subject line of email message. Message Template Text of message. Maximum length is 2000 characters, including variable substitutions. “Current” is a reserved word in Siebel Workflow. Do not use this word in a message. Repeating Message Message that is repeated when the Consolidate flag is checked on the Workflow Policies Policies view. “Current” is a reserved word in Siebel Workflow. Do not use this word in messages. Available Substitutions Dynamic fields that you can use in Subject, Message Template, and Repeating Message. When the action executes, the substitution value is populated with the value from the record that meets all the policy conditions. Request Key A string indicating which Email Manager should execute the action. You use this when multiple Email Managers are running. When you specify a request key string, it should match the Request Key parameter of the Email Manager that you want to execute the action. Leave this argument blank when you are running one Email Manager or when the Email Manager that executes the action is not important. Siebel Business Process Framework: Workflow Guide Version 8.0 21 3
    214. Workflow Policies ■ About Creating Workflow Policies Using the Message Broadcast Program Type The Message Broadcast Arguments applet appears if the Send Message Broadcast workflow policy program is selected in the Actions applet. Send Message Broadcast Arguments and Values Table 44 shows the arguments and valid values for the Message Broadcast workflow policy program type. Table 44. Message Broadcast Workflow Policy Program Type Argument Valid Values When Used by Action Activation Date and time for which the message broadcast is active. The variable CURRENT can be used when specifying the activation date. See “Entering Date Calculations” on page 233 for more information. Expiration Date and time when the message broadcast expires. The variable CURRENT can be used when specifying the activation date. See “Entering Date Calculations” on page 233 for more information. Abstract Short description of the message broadcast. Message Text of message to broadcast. Template Maximum length is 2000 characters, including variable substitutions. “Current” is a reserved word in Siebel Workflow. Do not use this word in a message. Severity Severity of message to broadcast. Available Dynamic fields that you can use in the Abstract and Message Template. When Substitutions the action executes, the substitution value is populated with the value from the record that meets all of the policy conditions. Activating the Check New Broadcasted Message Workflow Policy If you use any workflow policy that contains a workflow policy program type = Send Message Broadcast and you enable message broadcast caching on an object manager component, then you must activate the Check New Broadcasted Message workflow policy, which belongs to the Siebel Messaging policy group. The Check New Broadcasted Message policy monitors the S_BRDCST_MSG table and invokes the Notify Broadcasted Message workflow process to broadcast any new message added to the table. For information on configuring message broadcast caching, see Siebel Applications Administration Guide. For information on activating a workflow policy, see “Creating Database Triggers” on page 263. 214 Siebel Business Process Framework: Workflow Guide Version 8.0
    215. Workflow Policies ■ About Creating Workflow Policies Using the Run External Programs Type The External Programs Arguments applet appears if a Run External workflow policy program type is selected in the Actions applet. An example of a Run External Program is described in “Example of a Workflow Policy Action: Creating a Run External Program Action” on page 222. Run External Arguments and Values Table 45 shows the arguments and valid values for the Run External workflow policy program. Table 45. Run External Workflow Policy Program Type Argument Valid Values When Used by Action Executable Name Path and name of executable to run. For example, the executable will launch from the Siebel Server. The executable can be a batch program. Command Line The command line to use. The parameters that you want to pass to the executable. Execute Type ■ Wait. Workflow Policies waits for the external program to complete and examines the return code of the external program. If the return code is not 0, an error condition occurs. ■ No Wait. Workflow Policies executes the external program in the background and then continues processing. The return code is not checked. Note that for Visual Basic programs which create files, set Execute Type to Wait to avoid possible corruption of files. When set to No Wait, Visual Basic attempts to write files twice, thus corrupting the data. Available Dynamic fields that can be used as command line parameters. When the Substitutions action executes, the substitution value is populated with the value from the record in violation. If no path is supplied for the Executable Name argument, the executable is assumed to be in the current path of Workflow Policies running on the Siebel Server. For example, your Siebel Server may be installed on C:siebsrvr. The default path for the executable name would be C:siebsrvrbin. NOTE: The external program cannot be one that is interactive, requires a user interface, or accesses the Windows desktop. Using the Database Operation Program Type Siebel Business Process Designer has a number of database operation programs already predefined. All you need to define are the parameters. Siebel Business Process Framework: Workflow Guide Version 8.0 21 5
    216. Workflow Policies ■ About Creating Workflow Policies The Arguments applet appears if you select a database operation program such as Create Opportunity Activity in the Actions applet. Database Operation Arguments and Values Table 46 shows the arguments and valid values for the Database Operation workflow policy program. Table 46. Database Operation Workflow Policy Program Type Argument Valid Values When Used by Action Name Name of column to be updated. Required Indicates the argument is required. Value Updated value of the column. You can use substitutions in the value if they were defined in the program. The syntax for adding substitutions to the value is square brackets around the variable, for example, [SR Num]. 216 Siebel Business Process Framework: Workflow Guide Version 8.0
    217. Workflow Policies ■ About Creating Workflow Policies About the Recipients Applet Table 47 describes the fields in the Recipients applet. Table 47. Recipients Applet Fields Field Description Possible Value Recipient The possible values are dependent on ■ Send to Employee. Picklist of Type the workflow policy program selected employees. for the action. Recipients apply to ■ Send to Position. Picklist of workflow policy programs that are of positions. the Send Email, Send Page, and Send Message Broadcast type. ■ Send to Contact. Picklist of contacts. ■ Send to Relative. Send to an individual or group of individuals (such as a service request owner or opportunity team member) related to the Workflow object (such as an Opportunity or Service Request). ■ Send to Address. Represents a direct email address for programs that send email. Recipient Name of the recipient based on the Contact name, employee name, position, Name recipient type. or relative of workflow policy object to send an email, page, or message broadcast. NOTE: Messages are sent based on position. When choosing an employee as the recipient, note that if multiple employees occupy the same position, the message is sent to all of them, even though you are only choosing one employee as the recipient. The Send to Relative recipient type sends an email or page to an individual or position associated with the current record. For example, you can send an email to the primary sales representative of an opportunity (when all the conditions of the policy are met). Send to Relative is also used when you wish to configure a custom Send to <xxxx> recipient. Because you must use one of the Recipient Type choices in the picklist (Send to Employee, Position, Contact, or Relative), you use Send to Relative to define a custom recipient type. NOTE: Email Manager does not send email to the same recipient twice for the same action. If it detects that an email has already been sent to a specific email address, another one is not sent. If the Send to Relative type returns more than one recipient, each recipient is sent an email as long as each email address is unique. Siebel Business Process Framework: Workflow Guide Version 8.0 21 7
    218. Workflow Policies ■ About Creating Workflow Policies The Send to Position recipient type allows you to send to the primary employee of this position without having to know the name of the person (the employee must be ACTIVE). The Send to Contact recipient type allows you to pick any available contact in the Siebel system. NOTE: The only time the Action Recipients applet is available is when a Send Email, Send Page, or Send Message Broadcast program is selected in the Actions applet. Creating a Workflow Policy Action The procedure for creating a workflow policy action is described below. Examples of creating workflow policy actions for specific workflow policy programs follow the procedure. To create a workflow policy action 1 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Actions. 2 In the Actions applet, click New Record from the applet-level menu and enter the name of the workflow policy action. This name is the one that appears in the Actions Applet of the Workflow Policies Policies view. 3 Pick a workflow policy program type from the picklist in the Program field. 4 Select a workflow policy object, if applicable, from the picklist in the Workflow Object field. If you specify a workflow policy object, this action appears only on the Actions Applet of the Workflow Policies Policies view for policies associated with this workflow policy object. 5 Enter a description of the purpose of the action in the Comments field. 6 In the Arguments applet, pick one or more of the arguments and enter the appropriate value. The available arguments change according to the workflow policy program type you select in Step 2. NOTE: See “About the Arguments Applet in the Workflow Policies Action View” on page 211 for a description of the Argument applet for the specific workflow policy program types. 7 If the workflow policy program is either Send Email, Send Page, or Send Message Broadcast, enter the recipients of the action in the Recipient applet. NOTE: You cannot execute a business service from a Workflow Policy Action. Examples of Workflow Policy Actions The following are several examples of workflow policy actions for specific situations. You can use these examples as the basis for creating your own workflow policy actions. ■ “Example of a Workflow Policy Action: Creating a Send Page Action” on page 219 ■ “Example of a Workflow Policy Action: Creating a Send Email Action with a Repeating Message” on page 220 ■ “Example of a Workflow Policy Action: Creating a Send Message Broadcast Action” on page 221 ■ “Example of a Workflow Policy Action: Creating a Database Operation Action” on page 222 218 Siebel Business Process Framework: Workflow Guide Version 8.0
    219. Workflow Policies ■ About Creating Workflow Policies ■ “Example of a Workflow Policy Action: Creating a Run External Program Action” on page 222 Example of a Workflow Policy Action: Creating a Send Page Action You may want a page sent to the support manager whenever a service request priority becomes very high and the service request is not assigned to anyone. Use the following procedure to define a workflow policy action for this situation. To send a page whenever a service request is set to the highest value 1 In the Workflow Policies Actions view, fill in the Actions applet fields as follows: a Create a new record in the Actions applet and enter the name of the action: Page Support Manager when SR request changes b Select a predefined workflow policy program from the Program field picklist: Send SR Page c Select a predefined workflow policy object from the Workflow Object field picklist. Service Request NOTE: The workflow object field fills in automatically only when a workflow policy object is specified in the workflow policy program being selected. You pick a workflow policy object from the picklist when it does not automatically fill in. 2 Fill in the Send Page Arguments applet. a Select dynamic fields from Available Substitutions. b Enter text and dynamic fields in the Alpha Message Template: The [SR Status] of [SR Number] has changed. 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. 3 Fill in the Recipients applet. a Select a predefined recipient type from the Recipient Type field picklist: Send to Position b Select Recipient Name from the Recipient Name picklist: Support Manager This action is now available to use in a workflow policy. Siebel Business Process Framework: Workflow Guide Version 8.0 21 9
    220. Workflow Policies ■ About Creating Workflow Policies Example of a Workflow Policy Action: Creating a Send Email Action with a Repeating Message In this example, the vice president of sales wants to be notified only after a specific number of deals fail to close. Because this action will be used with a workflow policy that uses the Batch feature, you will need to enter relevant information in the Repeating Message field of the Send Message Arguments applet. This is because the recipient receives one email with a consolidated list of the pertinent information on each of the deals. Without a Repeating Message, the email would be sent but may not contain meaningful information. Use the following procedure to define a workflow policy action for this situation. To send an email with a repeating message 1 In the Workflow Policies Actions view, fill in the Actions applet fields as follows: a Create a new record in the Actions applet view and enter the name of the action: Excellent Quality Opportunity b Select a predefined workflow policy program from the Program field picklist: Send Opportunity Email c Select a predefined workflow policy object from the Workflow Object field picklist: Opportunity d Enter text in the Comments field: Send an email to the VP of Sales when deals aren’t closing 2 Fill in the Send Message Arguments applet. a Select dynamic fields from Available Substitutions where appropriate. b Enter text and/or dynamic fields in Subject: Opportunities not Closing c Enter text and/or dynamic fields in Message Template: Meet with [Last User First Name] [Last User Last Name] about [Opportunity] for [Account] d Enter text and/or dynamic fields in Repeating Message: Meet with [Last User First Name] [Last User Last Name] about [Opportunity] for [Account] 3 Fill in the Recipients applet. a Select a predefined Recipient Type from the Recipient Type field picklist: Send To Position b Select the Recipient Name from the Recipient Name picklist: 220 Siebel Business Process Framework: Workflow Guide Version 8.0
    221. Workflow Policies ■ About Creating Workflow Policies VP Sales When you create the workflow policy for this action, check the Batch field in the Policies applet of the Workflow Policies Policies view. Example of a Workflow Policy Action: Creating a Send Message Broadcast Action In this example, a service department wants to automate its notification policy for open service requests when open requests for one agent reach at least 20. To create a Message Broadcast Action for open service requests 1 In the Workflow Policies Actions view, fill in the Actions applet fields. a Create a new record in the Actions applet and enter the name of the action: Alert Agent of Open SRs b Select a predefined workflow policy program from the Program field picklist: Send SR Message Broadcast c Select a predefined workflow policy object from the Workflow Object field picklist: Service Request 2 Complete the Send Message Broadcast Arguments form using message arguments and typing in static text. a Enter text in Abstract: You have over 20 Service Requests. b Enter text in Message Template: You have over 20 service requests. Please review your service request queue. 3 Fill in the Recipients applet. a Select a predefined Recipient Type from the Recipient Type field picklist: Send to Relative b Select the Recipient Name from the Recipient Name picklist: SR Owner Siebel Business Process Framework: Workflow Guide Version 8.0 22 1
    222. Workflow Policies ■ About Creating Workflow Policies Example of a Workflow Policy Action: Creating a Database Operation Action Two kinds of database operations are possible in Workflow Policies—insert and update. 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 create a Database Operation to update Service Request Priority 1 In the Workflow Policies Actions view, fill in the Actions applet fields. a Create a new record in the Actions applet and enter the name of the action: Update SR Priority to Very High b Select a predefined workflow policies program from the Program field picklist: Change SR Priority 2 Fill in the Arguments applet. a Select from Name picklist: New Priority b Select from Value picklist: 1-Critical Example of a Workflow Policy Action: Creating a Run External Program Action In Siebel Workflow you use the action type Run External Program for defining an action that runs an external program. For example, your company could write a custom executable for calculating the quality of a new lead coming into the system. You could then call this executable from Siebel Workflow whenever the parameters for calculating the lead change. In the first of the following examples, a program named “leadcalc.exe” is in the C:bin directory and the action is being defined to call and execute this program. The second example provides the procedure for running external programs on UNIX. To run an external lead calculation program 1 In the Workflow Policies Actions view, fill in the Actions applet fields as follows. a Create a new record in the Actions applet and enter the name of the action: Run Lead Calculation Program b Select a predefined workflow policy program from the Program field picklist: 222 Siebel Business Process Framework: Workflow Guide Version 8.0
    223. Workflow Policies ■ About Creating Workflow Policies Run External Program c Select a predefined workflow policy object from the Workflow Object field picklist. NOTE: The workflow object field fills in automatically only when a workflow policy object is specified in the workflow policy program being selected. You pick a workflow policy object from the picklist when it does not automatically fill in. 2 Fill in the Run External Program Arguments applet. a Enter the name of the executable: leadcalc.exe b Enter any command line parameters. These are the parameters you want to pass to the executable. c Select an execute type. d Select dynamic fields from Available Substitutions. 3 Fill in the Recipients applet. a Select a predefined recipient type from the Recipient Type field picklist: Send to Position b Select Recipient Name from the Recipient Name picklist: Support Manager This action is now available to use in a workflow policy. To run an external program on a UNIX platform The Run External Program workflow policy program is not supported on UNIX. However, you can use the following procedure as a workaround. 1 Define a business service that executes an external program. a From the application-level menu, choose View > Site Map > Business Service Administration > Business Service Methods. 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); Siebel Business Process Framework: Workflow Guide Version 8.0 22 3
    224. Workflow Policies ■ About Creating Workflow Policies 2 Create a workflow process calling the business service created in step 1. a Add and connect a Start step, a Business Service step, and an End step. b For the Business Service step, specify Run Program and Run. c For the input argument for Program, specify the external program you want to run. For example, /bin/mail hkim@pcs.com </home/users/hkim/letter.txt. 3 Run your workflow process. Creating Workflow Policy Groups Workflow policy groups provide a means of identifying policies having similar system requirements. By grouping policies you can optimize your system, balance system loads, and provide scalability. All workflow policies must be assigned to a workflow policy group. You create groups for workflow policies in the Workflow Policies Groups view. The Workflow Policies Groups view has two applets: ■ Workflow Groups applet. Allows you to create new policy groups and to view and select previously existing policy groups. Specifying a workflow policy group determines the monitoring cycle for a workflow policy. Each policy group should contain policies that need to be monitored within similar time intervals. See “About the Workflow Groups Applet” on page 225. ■ Policies applet. Lists the workflow policies assigned to the selected group. See “About the Workflow Policies Applet” on page 225. To create a policy group 1 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Policy Groups. 2 From the applet drop-down menu in the Policy Groups applet, select New Record and enter the name for the group. 3 (Optional) Enter comments in the Comments field. 224 Siebel Business Process Framework: Workflow Guide Version 8.0
    225. Workflow Policies ■ About Creating Workflow Policies About the Workflow Groups Applet Table 48 describes the fields in the Workflow Groups applet. Table 48. Workflow Groups Applet Fields Field Description Name The name of the workflow policy group. All workflow policies belong to one and only one policy group. This name can be no more than 30 characters long. Comments Any comments describing the purpose or use of the policy group. About the Workflow Policies Applet Table 49 describes the fields in the Policies applet of the Workflow Policies Groups view. Table 49. Policies Applet Fields Field Description Name The name of the policy included in the workflow policy group. Workflow object The workflow policy object for which the policy was created, for example, Service Request, Opportunity, or Quote. Activation Date/Time The date and time that the policy was or will be activated. If this field is null, the policy is activated immediately. Expiration Date/Time The date and time that the policy expires. If this field is null, the policy is active indefinitely. Comments Any comments describing the purpose or use of the policy. Creating Workflow Policies After creating your workflow policy actions and workflow policy groups, you are ready to go to the Workflow Policies view to complete your workflow policy creation. You create a new workflow policy after you create the policy action and the policy group. The Workflow Policies view is made up of four applets: ■ Policies List applet. Where you enter and view information about the workflow policy. The entry applet toggles with a list applet so that you can quickly move between working on an individual policy and viewing information about several policies or groups of policies. See “About the Policies List Applet” on page 228. Siebel Business Process Framework: Workflow Guide Version 8.0 22 5
    226. Workflow Policies ■ About Creating Workflow Policies ■ Conditions applet. Where you define or change the conditions for the workflow policy. You can define as many conditions as necessary. All the conditions for the policy must be met to trigger the workflow policy action. If you want the policy to be triggered when one or another condition is true, you must create a separate workflow policy for each condition. See “About the Conditions Applet” on page 229. ■ Actions applet. Where you enter the name of the previously defined workflow policy action you want to take place when the conditions of the workflow policy are met. See “About the Actions Applet” on page 233. ■ Arguments applet. Where you can review the workflow policy action arguments. To create a Workflow policy 1 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Policies. 2 In the Policies List applet, select New Record from the applet-level menu, create a policy name and fill in the other applet fields. 3 Fill in the fields in the Conditions applet. 4 Fill in the name of the action you created in the Workflow Policies Actions view and, if necessary, check the Consolidate field. NOTE: Workflow policies can not be based on the table S_DOCK_TXN_LOG. The unique index for this table is TXN_ID, rather than ROW_ID for other standard Siebel tables. Because Workflow uses ROW_ID to do the comparison and execute actions, it will error out if used against S_DOCK_TXN_LOG. NOTE: You cannot execute a Business Service from a Workflow Policy. Examples of Workflow Policies The following are examples of workflow policies for specific situations. You can use these examples as the basis for creating your own workflow policy actions. ■ “Example of a Workflow Policy: Creating a Send Page Workflow Policy” on page 234 ■ “Example of a Workflow Policy: Creating a Send Email Workflow Policy” on page 234 NOTE: Workflow policies update the database fields directly through the Data Layer, and do not go through the Business Object Layer; therefore, any Workflow Processes that include Business Component events related to the updated fields are not executed. Using Batch Mode with Workflow Policies You can create Workflow policies as batch policies by checking the Batch check box in the Policies applet. When you start Workflow Monitor in batch mode, it checks for policies with the Batch check box marked. Each policy causes an SQL statement to be issued to identify the specific records that meet the policy conditions. The records identified are then processed in turn and the appropriate actions are carried out. 226 Siebel Business Process Framework: Workflow Guide Version 8.0
    227. Workflow Policies ■ About Creating Workflow Policies You can use the batch function to consolidate email messages for a designated recipient by checking the Batch field in the Actions applet in the Workflow Policies Policies view. If you consolidate email messages, the recipient would receive one email with the information of multiple actions rather than multiple emails. For example, you can create a workflow policy that sends an email to the director of sales each time a quote is submitted with a discount over 30%. If 20 sales representatives submit quotes with the 30% discount and the Batch field is checked, the director of sales receives one email listing the 20 quotes. If the Batch field is not checked, the director of sales will receive 20 email messages. NOTE: When creating a batch type workflow policy, the comparison operators IS ADDED, IS UPDATED, or IS DELETED must be used in conjunction with regular conditions. These comparison operators are considered special conditions intended for Dynamic mode when triggering rows to look up regular conditions. Siebel Business Process Framework: Workflow Guide Version 8.0 22 7
    228. Workflow Policies ■ About Creating Workflow Policies About the Policies List Applet Table 50 defines the Policies List applet fields. Table 50. Policies Applet Fields Field Description Policy Name The name of the workflow policy. Workflow The workflow policy object for which the policy was created, for example, Service Object Request, Activity, or Accounts. This field is required. Group The workflow policy group to which the policy belongs. Each policy must be assigned to a workflow policy group. See the note following this table for information about changing workflow policy groups. Comments Any comments about the purpose or use of the policy. Activation The date and time that the policy was or will be activated. If this field is null, the Date/Time policy is activated immediately. Expiration The date and time that the policy expires. If this field is null, the policy is active Date/Time indefinitely. Duration The duration fields specify how long in days, hours, or minutes all conditions must be true for the workflow policy to be executed. This field is ignored if the policy is run in batch mode. Created By The login name of the person who created the workflow policy. The information in this field is automatically filled. Read-Only. Created On The date and time the workflow policy was created. The information in this field is supplied for you. Read-Only. Quantity The number of records that meet the policy conditions before the policy action executes. If you do not specify a quantity, Siebel Workflow assumes a quantity of 1. Quantity allows policy administrators to create conditions that are based on a number of records that meet the policy conditions. For example, an administrator may create a workflow policy that sends a message broadcast when 20 or more critical service requests are open. Batch When Batch is checked, this indicates that this policy should evaluate all records that potentially meet the conditions of the policy. The Workflow Monitor Agent scans all records using the conditions of the policy to find the matches. When this field is checked, run Workflow Monitor Agent with the Batch Mode flag set to TRUE. The default is unchecked. NOTE: Before you can move a Workflow Policy from one group to another group, all requests 228 Siebel Business Process Framework: Workflow Guide Version 8.0
    229. Workflow Policies ■ About Creating Workflow Policies associated with that Workflow Policy must complete. If a Workflow Policy’s group is changed while associated requests are pending, the Workflow Monitor Agent will fail with the error Rule Not Found. If this occurs, restore the Workflow Policy to its original group, wait for the requests to complete, and then proceed with the change. About the Conditions Applet Table 51 defines the Conditions applet fields in the Workflow Policies Policies view. Table 51. Workflow Policy Conditions Applet Fields Field Description Field The workflow policy component column in the workflow policy object on which the workflow policy condition is based, for example, service request priority or service request open date. Select the workflow policy column instance from the picklist for the field. This field is required. Comparison The comparison to make between a workflow policy agent’s column value and the value you specify, for example, equals (=) or greater than (>). Select the comparison from the picklist for the field. This field is required. For more information, refer to “Using Comparison Values in the Conditions Applet.” Value The value to compare to the workflow policy column value instance, for example, not started or very high. This field is required except when the Comparison field has a value of Is Null, Is Not Null, Is Updated, Is Deleted, or Is Added. For more information, refer to “Using Comparison Values in the Conditions Applet” and “Entering Date Calculations” on page 233. Using Comparison Values in the Conditions Applet You use comparison values in the Operation field. The field exposes the Workflow policy component column for monitoring. Standard Comparisons The Comparison field supports <, >, <>, >=, <=, =, LIKE, IN, NOT IN, BETWEEN, IS NULL, and IS NOT NULL operators. An ‘AND’ is implied between multiple conditions defined using these comparison values. ‘AND’ means that all conditions must be met before the action occurs. Siebel Business Process Framework: Workflow Guide Version 8.0 22 9
    230. Workflow Policies ■ About Creating Workflow Policies When you specify values for the comparison operands LIKE, IN, NOT IN, and BETWEEN in the Value field of the Conditions applet of the Workflow Policies Policies view, 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 being examined, for example, IN (‘a’, ‘b’, ‘c’) or IN (1, 2, 3, 4) and BETWEEN ‘A’ and ‘M’ or BETWEEN 1 and 10. NOTE: It is up to the policy creator to make sure the syntax is correct. Siebel Business Process Designer only passes the BETWEEN clause to the database. It does not verify syntax, except for date and time. For date and time fields, Siebel Business Process Designer converts the date and time columns to the format of month/day/year, hour:minute:second. LIKE and NOT LIKE allow you to use wildcards, for example, LIKE Smith% or NOT LIKE Sm%th%. Table 52 shows comparison values for a typical database (your specific database syntax requirements may vary). Note that when using LIKE, IN, NOT IN, or BETWEEN with character fields, you use single quotes around the value. In addition, when using IN or NOT IN, you must place the value within parentheses. Table 52. Comparisons for a Typical Database Comparison Value < 5 > 5 <> 5 >= 5 <= 5 = A LIKE Abc% IN (1, 2, 3) NOT IN (‘A’, ‘B’, ‘C’) BETWEEN 1 and 2 BETWEEN ‘A’ and ‘B’ NOTE: On an MS SQL Server database, when you create a workflow policy condition on a LONG column, the available comparisons are IS NULL, IS NOT NULL, LIKE, and NOT LIKE. Specialized Comparisons The Comparison field also supports the specialized operators IS ADDED, IS UPDATED, and IS DELETED. The following comparisons work at the workflow policy component level. They do not operate at the field level. 230 Siebel Business Process Framework: Workflow Guide Version 8.0
    231. Workflow Policies ■ About Creating Workflow Policies ■ IS ADDED. If a new row is added for this workflow policy component, then trigger this workflow policy to be examined. NOTE: If used in conjunction with standard comparisons, IS ADDED can be triggered when a record is updated. ■ IS DELETED. If a row is deleted from this workflow policy component, then trigger this workflow policy to be examined. The following comparison operates at the field level. To monitor if a field within the workflow policy component was modified, use the field that is named after the workflow policy component. ■ IS UPDATED. If the field’s value has changed, either by adding a new record with the specific field or by modifying the field in an existing record, then trigger this policy to be examined. To monitor if any field for a particular table was updated, use the workflow policy component column that represents the LAST_UPD column for that table. The IS operators serve as a starting point for the examination of the workflow policy. NOTE: When creating a batch type workflow policy, the comparison operators IS ADDED, IS UPDATED, or IS DELETED must be used in conjunction with regular conditions. These comparison operators are considered special conditions intended for Dynamic mode when triggering rows to look up regular conditions. Siebel Business Process Framework: Workflow Guide Version 8.0 23 1
    232. Workflow Policies ■ About Creating Workflow Policies Table 53 describes the specialized comparisons for all database platforms that can be used in creating workflow conditions. Table 53. Specialized Comparisons Comparison Value IS ADDED Use IS ADDED with a workflow policy component column specified in the Condition field and nothing specified in the Condition value. The condition is met when an instance of the workflow policy component is added. For example, if the Service Request policy component column is selected in the Condition field and IS ADDED is selected in the comparison, the condition will be met when you create a new service request. IS UPDATED Use IS UPDATED with any field specified in the Condition field and nothing specified in the Condition value. The condition is met when the field changes. For example, if service request status is specified in the Condition field and IS UPDATED is selected in the comparison, the condition is met when the Service Request status changes. IS DELETED Use IS DELETED when you specify a child workflow policy component in the Condition field, and nothing is specified in the Condition value. A child workflow policy component is a workflow policy component that is associated with a major entity in Siebel (a parent workflow policy component). 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 other conditions, the other conditions must be based on the parent workflow policy component. For example, you may want to notify a service request owner if an activity is deleted from a service request that has a sub-status of In Process. The policy would be based on the Service Request Workflow policy object. The first condition would be field = Activity Component, comparison = IS DELETED, value = blank. The second condition would be field = Service Request sub-status, Comparison = ‘=’, value = In Process. The action is to send an email to the SR owner. NOTE: ‘OR’ is implied between conditions defined using these specialized comparison values, where ‘OR’ means that one or more of the conditions must be met before the action occurs. An ‘AND’ is implied between conditions using standard comparisons and conditions using specialized comparisons. For example, you may want a service representative to receive an email when an open service request has an activity added to it. You would then create a policy that has conditions Service Request Status = ‘Open’, Service Request Activity Component IS ADDED. 232 Siebel Business Process Framework: Workflow Guide Version 8.0
    233. Workflow Policies ■ About Creating Workflow Policies Entering Date Calculations Workflow Monitor considers both date and time when evaluating Workflow Policy conditions that perform a date comparison. CURRENT can be used when entering a value for a date comparison. The format for using CURRENT is CURRENT +/- d:h:m where “d” is day, “h” is hours, and “m” is minutes. You can use CURRENT in the comparison value for date fields. You can also use CURRENT when you specify the activation and expiration dates for a message broadcast action. About the Actions Applet Table 54 defines the Actions applet fields on the Workflow Policies Policies view. Table 54. Actions Applet Fields Field Description Action The name of the action. Sequence The sequence of the action relative to other actions. This field is required. Contact Last The last name of a contact when the recipient of the action is a contact in the Name database. Contact First The first name of a contact when the recipient of the action is a contact in the Name database. Employee The login name of an employee when the recipient of the action is an employee. Login Position The position of an employee when the recipient of the action is a position. Relative The relative type when the recipient of the action is determined by the workflow object, for example, service request owner. Consolidate Consolidates the action to one instance if more than one record meets all the Flag conditions of the workflow policy during the same action interval. Default is FALSE. The consolidate flag is unavailable with actions that send pages. Many of the choices in the fields in the Workflow Policies Policies view are predefined in other Siebel Business Process Designer views, either in Siebel Client or in Siebel Tools. You can modify the predefined choices or create new choices for these fields. These choices show up as a picklist in the Workflow Policies Policies view applets. Siebel Business Process Framework: Workflow Guide Version 8.0 23 3
    234. Workflow Policies ■ About Creating Workflow Policies Example of a Workflow Policy: Creating a Send Page Workflow Policy In this situation, the support manager wants a page sent whenever a service request priority becomes Very High and no one has been assigned to the service request. The Send Page action has already been created; now you must create the workflow policy to implement the workflow policy action. To create a Send Page Workflow policy 1 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Policies. 2 In the Policies List applet, select New Record from the applet-level menu. 3 Fill in the Policies applet as follows: a Name: Page support manager b Workflow Object: Service Request c Policy Group: High Frequency d Duration: 2 hours 4 Fill in the Conditions applet: a Service Request Priority = Very High b Service Request Owner IS NULL 5 Fill in the Actions applet with the name of the appropriate Send Page action. Example of a Workflow Policy: Creating a Send Email Workflow Policy In this situation, the vice president of sales wants to be notified when the number of deals that are not closed reaches a designated level. In this case, you have already created an workflow policy action that batches information on the deals and sends an email message containing information on the number of deals you designated. To create a Send Email Workflow policy 1 From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Policies. 2 In the Policies List applet, select New Record from the applet-level menu. 3 Fill in the Policies applet as follows: a Name: Very High Value Opportunity b Workflow Object: Opportunity 234 Siebel Business Process Framework: Workflow Guide Version 8.0
    235. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools c Policy Group: Medium Frequency d Quantity: 5 e Comments: Reminder to talk to the sales rep on opportunities nearing closure > $400,000, but low probability f Batch: checked NOTE: You do not need to fill in the Quantity field to have a repeating message. 4 Fill in the Conditions applet with the following: Field Comparison Value Forecast Probability <= 50 Forecast Revenue > 400000 5 Fill in the Actions applet. a Enter the Action name with the appropriate workflow policy action: Excellent Quality Opportunity b Check the Consolidate field. The Send Message Arguments fills in automatically with the information from the defined workflow policy action. NOTE: To make sure that the email action works properly, you can restart the Workflow Policy Monitor and Workflow Policy Action agents and set the Workflow Policy Action parameter Sleep to at least 5 minutes. This makes sure that your email lists all the opportunities meeting the conditions of the workflow policy. If the Workflow Policy Action agent runs too fast, then there will be an individual email each time the conditions of the workflow policy are met. Starting the server processes is discussed in “About Workflow Policies Server Administration” on page 263 About Customizing Workflow Policies with Siebel Tools This section describes how to customize workflow policies with Siebel Tools. “Siebel Tools and Workflow Policies” on page 236 “Siebel Tools Definitions in the Workflow Policies Views” on page 237 Siebel Business Process Framework: Workflow Guide Version 8.0 23 5
    236. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Siebel Tools and Workflow Policies Using Siebel Tools, you can define new workflow policy objects and modify existing workflow policy objects to meet your business needs. A brief discussion of basic Siebel Tools concepts is provided here as they relate to Workflow Policies. For a complete discussion of Siebel Tools, see Using Siebel Tools and Configuring Siebel Business Applications. NOTE: When you use Siebel Tools to modify or create workflow policy objects on your local system, the changes are not available on the server until they are applied to the server. Siebel Tools consists of an Object Explorer window and one or more Object List Editor windows. Figure 15 on page 63 shows the Object Explorer and Object List Editor window. The Object List Editor window lists object definitions for each object type and allows you to edit object type properties. The Object Explorer provides navigation between each group of object definitions of a particular object type. Object type is an entity that is displayed as a node on the Object Explorer. An object type is the template from which object definitions are created and have a predefined set of properties. Workflow policy programs, workflow policy columns, and workflow policy objects are all object types. An object definition implements one piece of the software such as Service Request or Contact. This object definition consists of properties. Properties are characteristics of the software that the object definition implements. For example, the properties of workflow policy column (object type) Service Request Severity (object definition) include Name (Service Request Severity), Table Name, Picklist, and so on. NOTE: Workflow policy objects are not included in the Object Explorer by default. Click View > Options > Object Explorer to add the workflow policy objects to the Object Explorer view. Properties correspond to the columns in Object List Editor windows. The information entered under the columns is values. You can also use the Properties window to edit the properties of the currently selected object definition in an Object List Editor window by changing the values in the columns. You may change the property values in an object definition but not the set of properties to which values are assigned. 236 Siebel Business Process Framework: Workflow Guide Version 8.0
    237. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Object type definitions have a specific set of properties, as discussed above. They also have hierarchical relationships with other definitions called parent-child. The arrangement of folder icons in the Object Explorer is hierarchical (in the Types view). An object type (folder) beneath and slightly to the right of another is the child object type of the one it is below. The one above the child object type is the child’s parent object type. Figure 25 shows parent-child relationships in the Object Explorer. A parent object type can have multiple child object types. Parent-child relationship between Program and Program Argument Parent-child relationship between Workflow Object, Workflow Component, and Workflow Component Column Figure 25. Parent-Child Object Type Relationships in the Object Explorer Siebel Workflow Policies accesses the following object types to create workflow policies, workflow actions, and workflow conditions: ■ Workflow policy program ■ Workflow policy program arguments ■ Workflow policy column ■ Workflow policy object ■ Workflow policy component ■ Workflow component column Workflow policy programs and program arguments must be created and defined in Siebel Tools for use by workflow policies in the Workflow Policies Action view. Workflow policy objects, workflow policy components, workflow policy component columns, and workflow policy columns must be created and defined in Siebel Tools for use by workflow polices in the Workflow Policies Policies view. Siebel Tools Definitions in the Workflow Policies Views The Workflow objects that were defined in Siebel Tools are displayed in Workflow Policies in the Workflow Object picklist in the Workflow Policies view. The workflow policy component columns defined in Siebel Tools are available to Workflow Policies views. The workflow policy component columns in Siebel Tools are exposed in Workflow Policies in the Condition Field picklist in the Workflow Policies view. Siebel Business Process Framework: Workflow Guide Version 8.0 23 7
    238. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools The policy programs defined in Siebel Tools are available in Workflow Policies views. The policy programs in Siebel Tools are exposed in Workflow Policies in the Program Field picklist in the Workflow Policy Actions view. You use Siebel Tools to configure or create custom workflow policy objects and custom policy programs. The use of Siebel Tools is described in Using Siebel Tools. Only information specific to Workflow Policies is described in this document. About Workflow Policy Objects Although Siebel Tools includes many of the workflow policy components you need for workflow policy creation, you can reconfigure entities in Siebel Tools to meet the full range of your business needs. Workflow policy objects provide the context in which Workflow Policies operate. The workflow policy object, through its workflow policy components, defines the set of tables and columns that can be monitored by a policy and how each table in the workflow policy object relates to the other tables. This collection of columns and the relationships between the tables of the workflow policy object represent the entity within Siebel Tools that you would like to monitor. Workflow policy objects comprise: ■ Workflow policy components. Defines the Siebel database tables that you can monitor. Workflow policy components define the relationships between the primary workflow policy component and all other policy components of a workflow policy object. ■ Workflow policy component columns. 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. Siebel Tools includes many of the workflow policy objects for common business needs such as Opportunity, Service Request, and Contact. You may find that you need to reconfigure existing workflow policy objects or create custom workflow policy objects to meet your specific business needs. CAUTION: Do not try to monitor Enterprise Integration Manager (EIM) table columns. To recognize EIM tables, look for table names that begin with EIM_ or end with _IF. Creating a Workflow Policy Object Creating a workflow policy object consists of four main steps: ■ Defining the workflow policy columns. See “Defining a Workflow Policy Column” on page 245. ■ Defining the workflow policy components. See “Defining a Workflow Policy Component” on page 246. ■ Defining the workflow policy object. See “Defining a Workflow Policy Object” on page 246. ■ Associating the workflow policy column with the workflow policy component. See “Associating a Column with a Workflow Policy Component” on page 248. 238 Siebel Business Process Framework: Workflow Guide Version 8.0
    239. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools About the Relationship Between Workflow Policy Components Figure 26 shows the entity relationship diagram for four Service Request Workflow Policy components. The diagram shows each of the components, their relationship to one another, and which columns are of interest. Service Request is the primary workflow policy component, and the other three components are joined directly or indirectly to it. Figure 26. Relationships of Workflow Policy Objects and Workflow Policy Component Relationship Between Workflow Policy Object and Workflow Policy Component If the Service Request has the primary field checked, then it is the primary component. All the other components in the list are the nonprimary components of the Service Request workflow policy object. Workflow Policies and the Siebel Tools Views This section discusses the following Siebel Tools views: ■ Workflow Policy Column List view. 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. See “About the Workflow Policy Column List View” on page 240. ■ Workflow Policy Object List view. Displays a list of the available workflow policy objects. See “About the Workflow Policy Object List View” on page 242. Siebel Business Process Framework: Workflow Guide Version 8.0 23 9
    240. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools ■ Workflow Policy Component List view. Displays a list of all workflow policy components for the selected workflow policy object. This view shows both the primary policy component and any nonprimary policy components and how each of the policy components is related. See “About the Workflow Policy Component List View” on page 242. ■ Workflow Policy Component Columns List view. Displays a list of all the policy columns that can be monitored from the selected workflow policy component. See “About the Workflow Policy Component Columns View” on page 244. About the Workflow Policy Column List View Table 55 describes the fields in the Workflow Policy Columns List view. Table 55. Workflow Policy Columns Applet Fields Field Description Comments Name The name of the workflow policy A descriptive name that is column. This is the default name that ■ Consistent with your overall naming appears in the Conditions applet on strategy. the Workflow Policies Policies view. ■ Meaningful to the policy maker. ■ Descriptive of how the column is used. Changed The identifier for whether the record A check mark or a blank value. was added or edited. Project The project the workflow policy A project from the picklist of projects you column belongs to. The project must currently have checked out. be locked by you before you can modify the column. Table The name of the Siebel database A table name from the picklist of all Siebel Name table that contains the column. database tables. Column The name of the column in the Siebel A database column on the database table Name table. specified in Table Name. Picklist This is the picklist that is used when A picklist defined in the repository. The selecting a comparison value for the column selected would have a column in the Workflow Policies corresponding Business Component field. If Policies view. the corresponding Business Component field has a picklist defined, the picklist should be entered here. For more information on picklists, see Configuring Siebel Business Applications. Source The field in the business component A Business Component field name from the Field of the picklist that is the source of the picklist specified in the Picklist field. comparison value. 240 Siebel Business Process Framework: Workflow Guide Version 8.0
    241. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Table 55. Workflow Policy Columns Applet Fields Field Description Comments Applet Pick applet used to display the picklist An applet chosen from the picklist. Only Pick in the Workflow Policies view. applets should be selected. Inactive Determines if this column is active or A check mark indicates this is inactive and inactive. If column is inactive, the is not compiled or accessible. column is not compiled when you compile your .srf and is not accessible by any object. Comments Comments describing the purpose or Any text. use of column. Configuring a Workflow Condition Based on a Foreign Key You can configure a workflow condition 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 configure a workflow condition based on a foreign key existing on the primary table 1 Create a new Workflow policy column, S_STG.NAME. 2 Make sure CURR_STG_ID is added under the Opportunity workflow component. 3 Create a new workflow component in the Opportunity workflow object based on S_STG table: ■ Name = your choice ■ Source Table Name = S_STG ■ Source Column Name = ROW_ID ■ Target Component Name = Opportunity ■ Target Column Name = CURR_STG_ID 4 Add the new workflow column S_STG.NAME (from Step 1) to the new workflow component. You can now create a workflow condition that is based on the new workflow column. Siebel Business Process Framework: Workflow Guide Version 8.0 24 1
    242. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools About the Workflow Policy Object List View Table 56 describes the properties for a workflow policy object. Table 56. Workflow Policy Object Properties Fields Field Description Comments Name The name of the workflow policy A descriptive name that is: object. ■ Consistent with your overall naming strategy. ■ Meaningful to the policy maker. Changed The identifier for whether the A check mark indicates the record has been record has been added or edited. added or edited. Inactive Indicates if the object is active or A check mark indicates this field is inactive inactive. and will not be compiled or accessible. If object is inactive, the object is not compiled when you compile your .srf and is not accessible by any other object or policy. Comments Comments relating to the Descriptive text. workflow policy object. Project The project name. Defined in the project picklist. About the Workflow Policy Component List View A workflow policy component is a logical mapping of a database table. Figure 27 on page 243 shows the Workflow Policy Component list view. Except for the primary workflow policy component, each workflow policy component defines a relationship to another workflow policy component. This relationship is defined by specifying a source policy column and a target policy column. The source and target columns on a workflow policy component identify foreign key relationships between the tables. A primary workflow policy component is a workflow policy component that all other workflow policy components are directly or indirectly related to. From these workflow policy components, the workflow policy columns that are available for monitoring in the workflow policy can be defined. 242 Siebel Business Process Framework: Workflow Guide Version 8.0
    243. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools To define a workflow policy object and its components, you should be familiar with the Siebel Data Model and Siebel Data Model Reference. Siebel Data Model Reference describes the tables and how the tables are related. Figure 27. Workflow Policy Component List View Table 57 describes all of the properties of a workflow policy component. Table 57. Workflow Policy Component Properties Fields Field Description Comments Name Name of the workflow policy A descriptive name that is: component. ■ Consistent with your overall naming strategy. ■ Meaningful to the policy maker. Changed Indicates whether the record has A check mark indicates the record been added or edited. has been added or edited. Primary Indicates whether this workflow A check mark indicates this is the policy component is primary for the primary workflow component. workflow policy object selected in the Note: Each workflow policy object workflow Object applet. must have only one primary workflow policy component. Siebel Business Process Framework: Workflow Guide Version 8.0 24 3
    244. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Table 57. Workflow Policy Component Properties Fields Field Description Comments Source Table Name The table that the workflow policy A table name from the picklist. component is based on. Source Column The column in the source table that A picklist of columns from the table Name relates to another workflow policy specified in the Source Table Name component. field. (Not required for the primary workflow policy component.) Target Component The target workflow policy component A table name from the picklist. (Not Name that this workflow policy component required for the primary workflow is related to. policy component.) Target Column The column in the target workflow A picklist of columns from the Name policy component that the source workflow policy component column in this workflow policy specified in the Target Component component is joined to. Name field. (Not required for the primary workflow policy component.) Inactive Indicates if the component is active or A check mark indicates this field is inactive. inactive and is not compiled or accessible. If the component is inactive, it is not compiled when you compile your .srf and is not accessible by any policy. Comments Any comments for the workflow policy Descriptive text. component. About the Workflow Policy Component Columns View This view displays a list of columns that can be monitored from the selected workflow policy component. To navigate to workflow policy component columns, choose Workflow Policy Object > Workflow Policy Component > Workflow Policy component column. The Workflow Policy Component Column view lists all the columns available for monitoring. 244 Siebel Business Process Framework: Workflow Guide Version 8.0
    245. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Table 58 describes the workflow policy component columns values. Table 58. Workflow Policy Component Columns Properties Fields Field Description Comment Workflow Column The name of the column defined A picklist of all columns that were defined Name in the workflow Policy Component in the Workflow Policy Column view for the Column view. table that the workflow policy component is based on. Alias The name of the column as it The default is the workflow policy column appears in the Conditions Field name. picklist in the Workflow Policies ■ A descriptive name that is: Policies view. ■ Consistent with your overall naming strategy. ■ Meaningful to the policy maker. ■ Descriptive of how the column is used. Changed Indicates whether the record was A check mark indicates that the record added or edited. has changed. Defining a 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 Workflow Policy Column List view. The procedure has two basic parts. First, you need to identify the business object, business component, and applet that will use the new workflow policy column. Second, you create the new workflow policy column. To add a new policy column 1 Start Siebel with /x. 2 In Siebel Client, navigate to the view that will use the new policy column, for example, the Account > Activities view. 3 Pull down Help > About View. A dialog box appears identifying the business object, business components, and applets the view uses. Make note of this information. 4 In Siebel Tools, select the Business Component identified in step 3 from the Object Explorer and scroll to the Table field. This Table field identifies the Siebel database table that this business component represents. Make note of this information. 5 In Siebel Tools, select Workflow Policy Column from the Object Explorer. Siebel Business Process Framework: Workflow Guide Version 8.0 24 5
    246. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools 6 Navigate to Edit >New Record. 7 Fill in the rest of the fields in the Workflow Policy Columns view with the values you found in previous steps. NOTE: The table name/column name combination must be unique. You are not allowed to add a record if your table name/column name combination has already been defined in another record. Defining a Workflow Policy Component To define a workflow policy component 1 In Siebel Tools, select Workflow Policy Object, then select Account. Then, expand the Object Explorer field Workflow Policy Object to Workflow Policy Component. 2 Create a new record and enter a name for the new policy component. 3 Enter the source table name for the policy component. 4 Set the source policy column name. This determines the relationship between this policy component and the primary policy component. 5 Determine the relationship between this policy component and the primary policy component. Next, you need to identify the set of columns from this workflow policy component that you would like to monitor. To do this in Siebel Tools, navigate to Workflow Policy Object > Workflow Policy Component > Workflow Policy Component Column and Workflow Policy Column view. Here you need to identify the column in the predefined workflow policy columns that has an activity assigned to it but is not currently exposed in the Workflow Policy Component Column view. Defining a Workflow Policy Object A workflow policy object is defined by its parent-child relationship to workflow policy components and workflow policy component columns. A workflow policy object is a collection of workflow policy components. Each workflow policy object has one and only one primary workflow policy component. All the other workflow policy components of a workflow policy object are related to the primary workflow policy component, either directly or indirectly. A workflow policy component defines a database table that includes those columns you would like to monitor. Workflow policy component relationships are based on their corresponding table relationships. A workflow policy component column is the specific column that is available for monitoring. Each of these workflow policy components can expose any number of workflow policy component columns. In the Siebel Tools Object Explorer, a workflow policy component column is a child object of a workflow policy component, which is a child object of a workflow policy object. Follow these steps when you need to create a new workflow policy object. 246 Siebel Business Process Framework: Workflow Guide Version 8.0
    247. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools To define a new workflow policy object 1 Open Siebel Tools and go to the Workflow Policy Object view. 2 Select the Workflow Policy Object applet. 3 Navigate to Edit >New Record and a row for a new record appears. Add the information for the new record in the appropriate fields. 4 Select the Workflow Policy Components applet. Add your primary workflow policy component and designate it as primary in the Primary field. CAUTION: You can have one, and only one, primary workflow policy component. 5 Add more workflow policy components and correctly define relationships to your primary workflow policy component. 6 Select the Workflow Component Columns applet. Add your workflow policy component columns for each of your workflow policy components. Modifying Policy Column Names Each business uses specialized terminology that clearly defines conditions within that organization. You can easily change the names of columns using the Alias column in the Workflow Component Column applet. NOTE: The fields that appear in the Conditions applet in the Workflow Policies view are called workflow policy component columns in Siebel Tools. The Column Instances available in the picklist in the Workflow Policies view are names from the Alias field in the Workflow Component Column applet. To change a policy column name 1 Open Siebel Tools and go to the Workflow Policy Component Column view. 2 Select the Alias field in the Workflow Component Column applet for the condition you want to change. 3 Type in the new name. Adding Policy Columns to a Workflow Policy Object If you are creating a new workflow policy object or if you want to add new columns to an existing workflow policy object, you must first verify that the column is available in the Workflow Policy Columns applet in the Workflow Policy Column view. If the column is not listed, you need to add the column in the Workflow Policy Column view before you perform the following steps. To add a column to a workflow policy object 1 Open Siebel Tools and select the Types tab in Object Explorer. Siebel Business Process Framework: Workflow Guide Version 8.0 24 7
    248. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools 2 From Object Explorer, select the workflow policy object for the new column and then the workflow policy component under that object. 3 In the Workflow Policy Component Column applet, navigate to Edit > Add Record and add the information for the new record in the appropriate fields. You should see a list of workflow policy columns that were defined for the database table that the workflow policy component is based on. Associating a Column with a Workflow Policy Component This topic describes how to associate a column with a workflow policy component. To associate a column with a workflow policy component 1 In Siebel Tools, from Object Explorer navigate to Workflow Policy Object and select Account. Then navigate to Workflow Policy Component > Workflow Policy Component Column, with Activities selected in Workflow Policy Component. 2 Create a new record in the Workflow Policy Component Column applet. 3 In the Workflow Policy Column Name field, click on the picklist to see the current set of columns available from this workflow policy component’s database table. 4 Select each workflow policy column you would like to monitor. 5 Change Display Name to match your business needs as appropriate. Note that if the workflow policy component column that you would like to monitor is not in the list, you must first define it under the Workflow Policy Column Explorer view. About the Validate Tool in Siebel Tools Siebel Tools provides a Validate Tool that allows you to check for high-level errors in new workflow policy objects or columns. To bring up the menu with Validate, right-click your mouse. Selecting Validate brings up the Validate screen. Clicking the Start button runs the validation process and returns information either as a caution or as error messages that appear in the Details box. Modifying an Existing Workflow Policy Object When defining the types of workflow policies you need to operate your business, you may find that the predefined workflow policy objects do not contain the policy components you need. Use the procedural steps in this section as a general guideline for modifying a workflow policy object. Before modifying a workflow policy object: 248 Siebel Business Process Framework: Workflow Guide Version 8.0
    249. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools ■ Find out the name of its database table and column names. If you are going to add or modify a component, you need to know the relationship between the component and the primary workflow policy component. ■ Make sure you do not have other records referencing this object that may be affected by your change. For example, before inactivating a component column, verify that no policy conditions are referencing the component column. To determine a database table 1 Start Siebel by entering the following from the command line: C:Siebelbinsiebel.exe /x 2 In Siebel Client, navigate to the appropriate workflow policy object view. This is the view that contains the business data you want to monitor. For example, if you need to modify the workflow for an account activity, you would navigate to the Account > Activities view. 3 Choose Help > About View. About View identifies the Business object, Business components, and applets this view uses. In the case of the Account Activities view, the dialog box identifies Action as the business component used by the Activities applet. 4 In Siebel Tools, select Business Component in the Object Explorer and find the appropriate component name. 5 Select the component (for example, Action) and find the table name. In the illustration above, the table name is S_EVT_ACT. You use this table name when you create a workflow policy component. Siebel Business Process Framework: Workflow Guide Version 8.0 24 9
    250. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools To determine the relationship between a component and the primary workflow policy component 1 In Siebel Client, navigate to the appropriate workflow policy object view. 2 Choose Help > About View. 3 Find the business component for the appropriate applet and the business object this view uses. 4 In Siebel Tools, select Business Object in the Object Explorer and search for the business component object name you noted in Step 3 on page 250. 5 In Object Explorer, expand Business Object to Business Object Component and select the appropriate Business Object Component. The attribute in the Link field identifies the link defining the relationship between the account and action business components. 6 In Object Explorer, select Link and find the applet/object link. The illustration below shows the Account/Action Link selected. This Link defines the relationship between the parent Business Component and the child Business Component through the Source field and Destination field. A blank Source field indicates that the join is using the ROW_ID column of the parent business component. The Destination field is the field within the child business component that is a foreign key to the Business Component. 7 In Object Explorer, select Business Component, then select the appropriate component name. 250 Siebel Business Process Framework: Workflow Guide Version 8.0
    251. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools 8 Expand the Business Component to Field. Select the appropriate field and find the Column attribute. In the illustration below, Account ID is the field and TARGET_OU_ID is the Column attribute. The column indicates which column within the table this field represents. You use this information when you define the workflow policy component. About Workflow Policy Programs Workflow policies use workflow policy actions based on the workflow policy programs that are predefined in Siebel Tools. (See “Predefined Programs” on page 295 for a complete list.) To meet your business needs, you can also reconfigure workflow policy programs to create new types of workflow policy actions. A workflow policy program is a generic event that actions are based on. A workflow policy program defines the particular action that takes place when the conditions of a workflow policy are met. There are five types of programs in the Siebel application: ■ Send Message. For more information, see “Send Message Program Arguments” on page 255. ■ Send Page. For more information, see “Send Page Program Arguments” on page 255. ■ External Program. For more information, see “Run External Program Arguments” on page 256. ■ Send Message Broadcast. ■ Database Operation. Siebel Business Process Framework: Workflow Guide Version 8.0 25 1
    252. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools About the Program List View Table 59 describes the Program properties fields. Table 59. Program Properties Property Required Description Name Yes 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 Name of the project as defined in the project picklist. Type Yes Select one of the following types from the picklist: ■ DB Operation. Insert or update a database table based on arguments. ■ 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 Message Broadcast. Send a message broadcast to a group of users. Workflow No Limits use of this program to policies associated with this workflow object policy object. Inactive No Checked if program is not active. Comments No Text to describe the program. About the Workflow Policy Program Argument List View Workflow policy program arguments define recipients, database actions, and available substitutions. Each workflow policy program typically has several program arguments. The argument fields that display in this view depend on the type of workflow policy program you select. A workflow policy program argument is a child process of a workflow policy program. 252 Siebel Business Process Framework: Workflow Guide Version 8.0
    253. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Table 60 shows the Workflow Policy Program Argument properties values. Table 60. Workflow Policy Program Argument Common Properties Property Required Description Applet Optional Picklist applet. Default Value Optional 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 on. Maximum length is 2000 characters. Name Required Identifies the parameter from a predefined list. Picklist Optional Picklist object. Required Boolean Value is TRUE or FALSE. Indicates whether or not data entry is required. Source Field Optional Picklist Source field. Visible Boolean Value is TRUE or FALSE. Indicates whether the data supplied by this argument is displayed. Inactive Checked if program is not active. When setting a Default Value for time/date fields, use the following formats: ■ Date Column format: 2001-03-16 ■ Time Column format: 19:26:26 ■ Date Time Column format: 2001-04-05 21:25:00 Siebel Business Process Framework: Workflow Guide Version 8.0 25 3
    254. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Common Workflow Policy Program Argument Values You can add functionality to workflow policy programs by creating a new workflow policy program argument record. Workflow policy program arguments determine how the workflow policy program behaves, including what substitutions are available for a workflow policy program and how the recipients are defined. Valid values for workflow policy program arguments common to all workflow policy programs are shown in Table 61. Table 61. Valid Database Operations Workflow Policy Program Argument Values Name Description Allowable Default Value Primary ID The row ID of the violating row that the Should be empty. Workflow policy program is acting on. Primary Table The base table to which the action is Any of the tables defined within applied. The base table can be unrelated to the Siebel business object the record of the primary ID. Examples repository (as compared to the include: The violating row is in a child table workflow business object). and you now want to insert or update a Workflow business objects are record in the parent table. Tables can also used for monitoring conditions but be updated that are not related to the are not used in the coding of action primary ID table. For example, create a programs. Message Broadcast record when a certain monitored condition in the Opportunity record is true. Update Row ID The row ID of a table other than the primary The row ID you want to update. table of the workflow policy object. You can associate a workflow policy action with a workflow policy that updates any table. This value is used only when the Operation Type is set to update. Operation Type What operation to perform—update or Two possible values for DB insert. Operation: Update or Insert. Field Name Name of the column in the base table to Allowable values: Text, Variable, which the operation is performed. Function. This is one of two field column pairs. New Row ID For insert operations, this argument is Should be empty. automatically populated with the row ID of the row about to be inserted. Field Name Name must be identical to the Field Name of Actual field name in the base table. (Column) the first column pair and (Column) The value can not contain any appended to the name. leading spaces. This is the second of two Column Pairs. 254 Siebel Business Process Framework: Workflow Guide Version 8.0
    255. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Table 61. Valid Database Operations Workflow Policy Program Argument Values Name Description Allowable Default Value Sql Statement Selects additional data from the database to Valid SQL query statement for the be used as substitutions when the action is RDBMS used (that is, Oracle, MS performed. SQL, Informix, or Sybase). Sql Statement Name of the column in the base table on Inputs which the operation will be performed. Sql Statement A placeholder for the values selected in the Variable Name. Outputs SQL Statement argument. When you run a database operation with Insert as the Operation Type, you can select a Default Value—New Row ID—as described previously, which provides the value for the ROW_Id field for the row being inserted. Send Message Program Arguments Table 62 describes program arguments specific to the Send Message program. Table 62. Send Message Program Argument Properties Name Description Value Email Message Body of the email message. Any text with available substitutions. Email Message Text that is repeated when the Consolidate Any text with available Repeated feature is used. substitutions. Email Subject Text in subject line of the email message. Any text. Send to Contact All contacts available in Siebel. Send to Position List of the positions available in Siebel. Send to Employee List of all employees available in Siebel. Send Page Program Arguments Table 63 describes the Program Arguments particular to the Send Page program. Table 63. Send Page Program Argument Properties Name Description Value Send to Contact All contacts available in Siebel. Picklist of contacts. Send to Employee List of all employees available in Siebel. Picklist of employees. Send to Position List of the positions available in Siebel. Picklist of positions. Siebel Business Process Framework: Workflow Guide Version 8.0 25 5
    256. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Table 63. Send Page Program Argument Properties Name Description Value Send to Relative Send to an individual or group of individuals related to the Workflow object. Alpha Numeric Page Body of the text message. Any text with available Message substitutions. Numeric Page Message Body of the numeric message. Any text with available substitutions. Run External Program Arguments Table 64 describes the Program Arguments particular to the Run External Program program. Table 64. Run External Program Argument Properties Name Description Value Command Line What parameters to pass to the executable. Executable Name Full path to the executable to execute. Executable Type The mode in which the Workflow Action Agent will execute Wait. the external program. No wait. Creating a Workflow Policy Program A workflow policy program is a generic event that actions are based on. You define a program by defining the workflow policy event. CAUTION: Do not rename or change the name of an existing workflow policy program. If you do so, you will lose all the actions created for the program. When creating a workflow policy program that inserts new records, you must determine and provide the minimum field values that constitute a valid record as defined in the repository for the table: ■ Provide values for all required columns. If a default value is defined for a column, that default value is used on the insert if the program specifies none. For example, S_EVT_ACT has two required columns: NAME and ROW_STATUS. ROW_STATUS defaults to Y so you do not have to set a value in the program (although you can). ■ You do not need to provide a value for system-generated columns such as CREATED, CREATED BY, LAST_UPD, LAST_UPD_BY, ROW_Id, MODIFICTION_NUM, CONFLICT_Id. For more information, see Siebel Data Model Reference. 256 Siebel Business Process Framework: Workflow Guide Version 8.0
    257. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Siebel Systems recommends that when you want to define a new workflow policy program that you copy an existing program that is similar to what you need and then modify the copy to suit your specific business needs. The advantage to using this method is that if something goes wrong with your customized program, you can always start over with the original existing program. Additionally, modifying a copy of an existing program is less error–prone that creating an entirely new program. CAUTION: Thoroughly test any SQL queries that you plan to use with customized policy programs. Be aware that if the SQL statement fails to find rows, the workflow policies action is unable to process any tokens. To create a workflow policy program 1 In Siebel Tools, choose Program. 2 Select an existing program that is similar to what you need for the new workflow policy program. 3 Right-click and choose Copy Record. This copies the entire program including the program arguments. 4 Modify the appropriate fields, such as Workflow Object, to meet the needs of the new program. 5 Define the program arguments. Enter the arguments carefully to make sure capitalization, punctuation, spelling, and so on are correct: ■ Type the entries in the Name column exactly as indicated in Table 61 on page 254. Primary ID, Primary Table, Operation Type, SQL Statement, and SQL Statement Outputs must have one space between each word and each word must be properly capitalized. For example, Primary ID must have one space between the two words, capital P, and lowercase d. NOTE: In program arguments, 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. ■ When using SQL statements in program arguments, make sure that the statements are 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 using a program and its related program arguments in a workflow policy, you must delete any inactive or incomplete program argument definitions. These could cause Workflow Monitor Agent errors. Siebel Business Process Framework: Workflow Guide Version 8.0 25 7
    258. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Example of Creating a Workflow Policy Program Argument: Send Opportunity Email The following is an example of adding a new a workflow policy program argument, in this case, Send Opportunity Email. The current recipients of type relative are limited to the Primary Sales representative. You want to add a relative for Primary Contact. This allows policy makers to create an action that sends an email to the Primary Contact for an opportunity. To add an alternative Send to Relative to the Send Opportunity Email program 1 In Siebel Tools, choose Workflow Policy Program > Send Opportunity Email > Workflow Policy Program applet. NOTE: To create a new workflow policy program argument for Send Opportunity Email, check the existing program arguments and make sure that the Send to Relative program argument exists. 2 Create a new record, Primary Contact. NOTE: When creating new program arguments, they cannot have the same name as a SQL Statement Output or the Workflow Monitor Agent server task will hang with the message “Examining request for policy...” when inserting a record. 3 Bring down the box under Default Value and create your SQL statement. For example: select O.PR_CON_ID, 'Send to Contact' from &Table_Owner.S_OPTY O where O.ROW_ID=? Workflow passes the ROW_ID of the violating row, so make sure to write all your SQL queries to 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. NOTE: SQL statements are database vendor–specific. Use an external SQL tool to build and test your statements. When the test works, copy the statement into the field. 4 Select Workflow Relative Type Picklist in the PickList field. This picklist describes this argument as a relative. The Visible field is checked. The changed field becomes checked when you create a new program argument. Creating SQL Statements for Workflow Policies Program Arguments Before you begin to create the Recipient Type, Send to Relative, you must create a SQL statement in the Workflow Policy Program applet in Siebel Tools. SQL statements written for Workflow Policies Program Arguments must have the following characteristics: 258 Siebel Business Process Framework: Workflow Guide Version 8.0
    259. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools ■ The table name and column name you reference must be uppercase. ■ The case-sensitive table name should be prefixed with: &Table_Owner. ■ The SQL statement must be valid for the specific database vendor being used. NOTE: Workflow program SQL statements should return only one record. To ensure this, initiate statements that use outer joins rather than inner joins. About Predefined Workflow Policy Programs You can use the following examples as explanation for how to interpret the program arguments. Review these examples to understand the format of a program. The examples use the predefined workflow policy programs included with Workflow Policies (see “Predefined Programs” on page 295). These programs can be viewed in the Siebel Tools Object Explorer by clicking Program and then Program Argument. ■ “Example of Using a Predefined Workflow Policy Program: Change SR Close Date to Today” on page 259 ■ “Example of Using a Predefined Workflow Policy Program: Change SR Owner” on page 260 ■ “Example of Using a Predefined Workflow Policy Program: Change SR Owner to Manager” on page 261 ■ “Example of Using a Predefined Workflow Policy Program: Send Quote Page” on page 262 Example of Using a Predefined Workflow Policy Program: Change SR Close Date to Today Using this program, you can define a policy such that if a Service Request has an activity of type Resolution, and the SR is open for more than five days, the SR close date is changed to today’s date. When the policy triggers the workflow policy program, the program enters the current system date into the Close Date field of the Service Request record. Table 65 shows the arguments for the Change SR Close Date to Today program. Table 65. Change SR Close Date to Today Program Arguments Argument Name Comment Primary ID Contains the row ID of the Service Request record meeting the policy condition. Primary Table Specifies the table (S_SRV_REQ) and what action is to take place (Update). Operation Type Siebel Business Process Framework: Workflow Guide Version 8.0 25 9
    260. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Table 65. Change SR Close Date to Today Program Arguments Argument Name Comment 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 hold the value temporarily. The S_DUAL table is used to hold temporary values. Math functions can also be performed. For example, SQL Statement = select {fn now()}+7 from &Table_Owner.S_DUAL returns the current date plus seven days. Different RDBMS have 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: TO_CHAR(CREATED,'dd month yyyy','NLS_DATE_LANGUAGE=FRENCH'). Sql Statement Outputs The “Today” variable obtains its value 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 want to update. (The same as the value of the Primary ID.) Example of Using a Predefined Workflow Policy Program: Change SR Owner If an open service request is not assigned for a certain length of time, this workflow policy program could be used to assign (change owner) a service request to the expert in the area of the specific service request. This would allow the right people to see the incoming service request and assign it appropriately. 260 Siebel Business Process Framework: Workflow Guide Version 8.0
    261. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools This workflow policy program allows you to select a new owner from a picklist and put it into the field of the Service Request record matching the policy condition. Table 66 shows the arguments for the Change SR Owner program. Table 66. Change SR Owner Program Arguments Argument Name Comment Primary ID Contains the row ID of the Service Request record meeting the policy condition. Primary Table Specifies the table (S_SRV_REQ) and what action is to take place (Update). Operation Type New Owner (Column) Specifies the field in the record to be updated (Owner_EMP_ID). New Owner Indicates that a picklist is to be displayed for assigning a new owner. The picklist is defined by columns picklist = Picklist SR Owner, Source = ID, and Applet = SR Owner Pick Applet. Visible When checked, indicates the picklist is visible to the user. Example of Using a Predefined Workflow Policy Program: Change SR Owner to Manager If the service request is not closed within a specific duration of time, assign the service request to the owner’s manager. This would allow a proper response time to service calls. This workflow policy program does the following: ■ Uses the Primary ID as input into a SQL statement ■ Uses a query SQL statement to retrieve the current value of the field Manager ■ Sets the New Owner field to default to the current value of Manager ■ Allows the end user to update the New Owner field optionally through a picklist Table 67 shows the arguments for the Change SR Owner to Manager program. Table 67. Change SR Owner to Manager Program Arguments Argument Name Comment Primary ID Contains the row ID of the Service Request record meeting the policy condition. Primary Table Specifies the table (S_SRV_REQ) and what action is to take place (Update). Operation Type Siebel Business Process Framework: Workflow Guide Version 8.0 26 1
    262. Workflow Policies ■ About Customizing Workflow Policies with Siebel Tools Table 67. Change SR Owner to Manager Program Arguments Argument Name Comment New Owner Specifies the field in the record to be updated (Owner_EM_ID). (Column) New Owner Indicates that a picklist is to be displayed for assigning a new owner. Sql Statement 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 SR.ROW_ID = ? uses a question mark as a placeholder for inputting the value of the Primary ID. The system knows to substitute the Primary ID for the question mark. This SQL statement joins four tables, giving access to data from all of them. In this example, only one field is retrieved. Policy Monitor requires the definitions contained in the workflow policy object, workflow policy components, and workflow policy columns. In working and coding workflow policy action programs using the Siebel tables, explicit joining of the base table through SQL code is required. Sql Statement Set to the value of Primary ID. Inputs Sql Statement Set to the value of Manager. Outputs Example of Using a Predefined Workflow Policy Program: Send Quote Page If a created quote has a value less than some percentage of the opportunity’s revenue (very highly discounted), send a page to a designated employee. This workflow policy program sends out a pager message. The SQL statement is configured for the different RDBMS syntax. There are four SQL statements, one default and three specific to an RDBMS (Informix, Oracle, and SQL Anywhere). 262 Siebel Business Process Framework: Workflow Guide Version 8.0
    263. Workflow Policies ■ About Workflow Policies Server Administration The default SQL Statement query retrieves five values from four tables using an outer join specified 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 (Oracle) query retrieves five values from four tables using an outer join specified by the (+): 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 (<SQL style>) is present, this takes precedent over SQL Statement. The SQL statement outputs define five variables (Quote Number, Revision, Opportunity, Account, Site) to hold the result of the query statement. In an outer join, there may not be an associated table, in which case the variable will be set to null. Making Object Types Available in the Siebel Client The workflow policy objects, columns, and programs that are created in Siebel Tools are available to the policy maker to create policies and actions in the Siebel client. For these Siebel Tools objects to be accessible in the Siebel client, the Siebel Repository must be updated in the Siebel database. Workflow policy objects, columns, and programs are read from the Repository, not from the compiled Siebel repository file (.srf). The client must also have the correct repository name specified in the configuration file (.cfg) in the parameter “DockRepositoryName.” About Workflow Policies Server Administration This section describes the server administration tasks relevant to Workflow Policies. Creating Database Triggers The Generate Trigger (GenTrig) component on the Siebel Server allows you to create database triggers. Workflow Policies uses database triggers to identify which records match policy conditions. Run Generate Triggers when you: Siebel Business Process Framework: Workflow Guide Version 8.0 26 3
    264. Workflow Policies ■ About Workflow Policies Server Administration ■ Create or delete new policies (including Assignment Policies), with the exception of Workflow Policies that have Batch Flag set to TRUE. ■ Amend policy conditions or policy criteria. ■ Change activation or expiration dates of policies, including Assignment Policies. To run Generate Triggers, you must have installed Siebel Server, and the client you are using must be enabled to access the Siebel Server Administration screens. See the installation guide for the operating system you are using for more information on installing Server Manager. CAUTION: If you have incorrectly defined a policy condition, running Generate Triggers may result in invalid triggers. An invalid trigger can prevent execution of normal user transactions. For this reason, thoroughly test your policies in your test environment before you deploy them in your production system. Generating triggers is a one- or two-step process, depending on how the EXEC parameter is set; the default setting is FALSE. ■ If the EXEC parameter is set to TRUE, the Generate Trigger component automatically creates the SQL script and applies it to the server database. ■ If the EXEC parameter is set to FALSE, generating triggers is a two-step process: ■ Use the Generate Triggers component from a Siebel Server to create the SQL script file, which is placed in the root directory of the Siebel Server installation. ■ Use your database vendor’s SQL tool to execute the SQL script file against the server database. You can run the Generate Triggers component from either the Server Manager graphical user interface (GUI) or command line mode. Both the GUI and the command line use the same parameters. So the triggers are only there to create indicators for the Workflow engine to check the policies’ conditions. Example of GenTrig Behavior for a Workflow Policy with Multiple Conditions When two or more conditions are used in a workflow policy, Generate Triggers shows the OR logic instead of the AND logic, as in the following example. Create a workflow policy based on the Account object, with the following conditions: Condition 1 Condition Field Account Modification Num Operation > Value 0 264 Siebel Business Process Framework: Workflow Guide Version 8.0
    265. Workflow Policies ■ About Workflow Policies Server Administration Condition 2 Condition Field Account Last Update By Operation <> Value 0-1 Multiple triggers created for multiple conditions of one policy is expected behavior. This is the case in order to separate the functionality of GenTrig and WorkMon. GenTrig simply monitors database record changes and inserts records in Workflow Policy-specific tables. WorkMon evaluates records (violations), checks to see if all the conditions associated with the rule of the violation are met, and executes the actions associated with a policy. You cannot use AND between triggers generated for multiple conditions of a policy, because GenTrig can monitor only database changes, and database changes that violate different conditions are not always concurrent. So using an AND condition would cause GenTrig to miss many violations. For example, a policy has two conditions: SR area=Network Activity Priority=1-ASAP Two triggers will be generated. One trigger monitors an SR being created or updated, and checks if the area equals Network. The other trigger monitors an activity being created or updated, and checks whether the Priority equals 1-ASAP. But if you used AND triggers, and a user creates an SR without an activity, the trigger is not violated since the activity does not exist. If later, a user adds an activity to the SR, there still is no trigger violation because the SR record does not change. This would be a missed violation due to use of AND logic. If, however, you use OR for the triggers and have WorkMon evaluate the condition, even though there will be multiple violations in S_ESCL_REQ, WorkMon will only process one request because the other requests are not evaluated to TRUE. About Database Triggers and Database Administration It is important to keep your database administrators informed of any active Workflow database triggers, as any database Update or Insert event will cause the database trigger to react, regardless of how the event is executed. For example, if you have Workflow triggers on Inserts to the S_SRV_REQ table, and the database administrator does a Table export and import of these records, the triggers will treat every record in the database as if it were a newly inserted record, which may result in inappropriate actions being taken on old records that were simply re-imported. NOTE: In this release, the Generate Triggers task now requires the Privileged User Name and Password instead of Table Owner ID and Password. Siebel Business Process Framework: Workflow Guide Version 8.0 26 5
    266. Workflow Policies ■ About Workflow Policies Server Administration Running Generate Triggers When running Generate Triggers, remember the following tips, especially if you are deleting a policy: ■ Deleting a policy and then running Generate Triggers does not remove the database trigger. When you delete a policy, you must run Generate Triggers with the remove parameter set to TRUE. This removes all triggers. You must then rerun Generate Triggers to reset the triggers for existing policies. ■ You must stop and restart the Workflow Monitor Agents when running Generate Triggers. ■ Generate Triggers must be rerun whenever you change policy conditions or policy groups. Generate Triggers does not need to be rerun when changing policy actions. ■ For SQL Server, have your default database set correctly. To determine your default database, launch the SQL Server Enterprise Manager and navigate to the SQL Server Machine name. Then, click Security and then click LOGIN. The default database will be listed to the right. ■ You must start a new WorkMon task anytime you drop or regenerate triggers. This refreshes the WorkMon cache to account for the new changes in the policy being monitored. To generate triggers using the GUI 1 In the Siebel client, from the application-level menu, choose Navigate > Site Map > Administration - Server Management > Jobs. 2 In the Jobs list, click New. 3 From the Component/Job drop-down list, select Generate Triggers. This creates a new line entry but does not start the task. 4 In the Job Parameters list, click New to modify parameter settings. The component-specific parameters for Generate Triggers are in Table 68. See Siebel System Administration Guide for a description of the generic and enterprise parameters. 5 Enter your Privileged User name and password. 6 In the Job Detail form applet, from the applet-level menu, select Start Job. 7 To view changes to the state, refresh the screen by clicking Run Query from the applet menu. 8 Upon completion, the Status field contains either Success or Error. It is recommended that you view the log details. Table 68. Component-Specific Parameters for Generate Triggers Name Value Description Remove TRUE or FALSE Set to TRUE to generate “DROP TRIGGER” statements to (default) clean up the triggers. Remove does not generate “CREATE TRIGGER” statements. Trigger File Valid filename on the Name and output location for the SQL script file. The default Name Siebel Server is TRIGGER.SQL. The file is created in the root directory of the Siebel Server during installation. 266 Siebel Business Process Framework: Workflow Guide Version 8.0
    267. Workflow Policies ■ About Workflow Policies Server Administration Table 68. Component-Specific Parameters for Generate Triggers Name Value Description EXEC TRUE or FALSE Determines if the SQL script file runs automatically or (default) manually. If TRUE, the SQL script file runs automatically. Also, if you are creating a large number of triggers because there are too many workflow policies, the triggers should be applied by the user and not by the Generate Triggers server process. The Exec parameter should be set to FALSE in this case. Mode ALL or WORK or Set to ALL to create both Workflow Policy triggers and ASGN Assignment Manager triggers. Set to WORK to create only Workflow Policy triggers. Set to ASGN to create only Assignment Manager triggers. Privileged Assigned Privileged All users must enter a Privileged User name and password. User Name/ User name and The Table Owner is considered a Privileged User, so you may Privileged password enter the Table Owner name and password in the Privileged User User name and password fields. Password Running the SQL Script File Once Generate Triggers has completed, run the SQL script file if the EXEC parameter is FALSE. To run the SQL script file 1 Connect to the database server as the Siebel tableowner using your RDBMS vendor’s SQL tool (for example, ISQL for Microsoft or SQL*Plus for Oracle). 2 Run the SQL script file specified by the Trigger File Name parameter. The default filename is TRIGGER.SQL. The default location of this file is the root of the directory that the Siebel Server was installed in. For example, this might be: C:siebsrvrtrigger.sql 3 Verify that no errors are reported. For example, the policy administrator, Bill Stevens, has finished creating policies in the test Siebel Client and wants the database triggers set in the Siebel database for the new policies. Using the Generate Triggers component, he sets the file output name. This creates a file, TRIGGER.SQL, for the database administrator containing all the triggers that need to be modified or created in the test database for these policies. The database administrator then runs the following command in SQL*Plus to create the triggers in the Oracle database: Siebel Business Process Framework: Workflow Guide Version 8.0 26 7
    268. Workflow Policies ■ About Workflow Policies Server Administration 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 required for other databases, refer to your database documentation. NOTE: On an MS SQL server database, execute the script trigger.sql as the database owner (dbo) login for the Siebel database. About Database Triggers and Remote Users When a remote user synchronizes, the changes get incorporated into the database (for example, account information in the S_ORG_EXT table is updated on synchronization). If you run a workflow which creates database triggers that compare changes in the database against specific conditions, then the triggers will fire and rows get written to S_ESCL_REQ if the changes are of interest to the workflow conditions during synchronization. Setting Up the Siebel Server for Email Manager Some workflow policy actions allow you to send email messages to specific individuals. It is important to note the following: ■ To send email using Workflow Policies and using a SMTP/POP3-compliant mail system, both must be working properly on your network. ■ The Email Manager component of the Siebel Server must be running. This is part of the Communications Management component group, which must be enabled. ■ Email Manager uses profiles set up in Communications Manager. The Communications Outbound Manager does verification of the profile. You then must verify that this profile is configured correctly to log into the SMTP/POP3-compliant mail system. ■ You must also set the Mail Profile parameter to the name of the communication profile you want to use for sending the email. More information on using Email Manager is provided in the following sections: ■ “Setting Up the Communications Profile to Send Email through Workflow” on page 268 ■ “Starting Email Manager” on page 269 Setting Up the Communications Profile to Send Email through Workflow Sending email through Workflow involves creating an SMTP/POP3 communications profile. NOTE: In order to create a new communications profile, CompGrp “CommMgmt” must be enabled. Verify that it is enabled before beginning the following procedure. For more information, see Siebel Communications Server Administration Guide. 268 Siebel Business Process Framework: Workflow Guide Version 8.0
    269. Workflow Policies ■ About Workflow Policies Server Administration To create a communications profile 1 From the application-level menu, choose Navigate > Site Map > Administration - Communications > Communications Drivers and Profiles. 2 In the Communications Drivers list applet, select the “Internet SMTP/POP3 Server” communications driver. 3 Click the Profiles tab. 4 Create a new profile called <Profile Name>. 5 Click the Driver Parameters tab, and complete the fields for the parameters described in Table 69 in the Profile Parameters Overrides applet: Table 69. Driver Parameters for Creating a Communications Profile Parameter Entry From Address <the sender’s email address for outbound communications> POP3 Account Name <the account name for the POP3 mailbox from which to retrieve inbound communications> POP3 Account Password <the password for the POP3 mailbox account> POP3 Server <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 <the host name or IP address of the machine on which the Internet SMTP server is running, as appropriate for your network configuration> NOTE: For details on the parameters listed in Table 69, see Siebel Communications Server Administration Guide. After creating your communications profile, you need to create the component definition of Email Manager. The Email Manager component executes email actions once the conditions of a Workflow policy are met. Starting Email Manager You can start Email Manager from the command line, or from the Email Manager Component view. To start Email Manager from the command line ■ To start the Email Manager task with the <Profile Name> profile, in the server manager command line, use the following command to start a task for Email Manager: start task for comp MailMgr with MailProfile=<Profile Name> Siebel Business Process Framework: Workflow Guide Version 8.0 26 9
    270. Workflow Policies ■ About Workflow Policies Server Administration To start Email Manager from the Server Administration view 1 From the application-level menu, choose Navigate > Site Map > Administration - Server Configuration > Servers > Components. 2 In the Components list, find the Email Manager component. 3 In the Component Parameters list, set Mail Profile = Test. 4 If you want to automatically start up a task for Email Manager whenever the component is restarted or the Siebel server services are restarted, set the component parameter Default Tasks = 1. When the workflow policy is violated, Workflow Monitor Agent will insert a record into the S_APSRVR_REQ table for workflow actions that invoke any of the Send Email workflow policy programs. Email Manager will then pick up records from the S_APSRVR_REQ table, setting their status from QUEUED to ACTIVE and then to SUCCEEDED during the course of the execution. Subsequently, Outbound Communications Manager will be invoked to log onto the <Profile Name> profile and send the emails out to the recipients using the Outbound Communications Manager business service, Send Message method. Mail Profile Parameter The Mail Profile parameter specifies the mail profile to use and is defined in Control Panel. The parameter establishes the connection between the application and the email system. If you do not specify a profile here, the default profile is used. The names must match exactly. Setting Up the Siebel Server for Page Manager Some Workflow policy actions allow you to send page messages to specific individuals. The Page Manager component of the Siebel Server must be running for you to send a page. Some actions can page specific individuals with alphanumeric or numeric pagers. To send a page using Workflow Policies, make sure these prerequisites are met: ■ The server running the Page Manager component has access to a local or network modem. ■ The Page Manager component of the Siebel Server is running. Several parameters, similar to dial-up networking set up in Windows, must be set prior to running the Page Manager component. ■ Enter the appropriate telephone numbers for paging in the Employee view. These are the numbers used by Workflow. ■ Change the regional configuration to avoid inputting the country code prior to the telephone number. This could cause errors. ■ Change the list of values (PAGE_TYPE) parameters to make the page manager accept an alphanumeric send. This means the language and the value shown. NOTE: Alphanumeric paging is more reliable than numeric paging because the pager messages are transmitted by the computer at the pager companies. This is not true for numeric paging, where pager messages are sent by emulating key presses on a phone. Failures in sending numeric pager messages are very hard to detect. 270 Siebel Business Process Framework: Workflow Guide Version 8.0
    271. Workflow Policies ■ About Workflow Policies Server Administration The Page Manager component uses the industry standard protocol Telocator Alphanumeric Protocol (TAP) for alphanumeric paging. Check with your pager company for the phone number to send your alphanumeric paging. Several parameters affect how the Page Manager component interacts with the modem. You can change these parameters in the Server Administration screen. The available parameters are listed. The modem parameters are the defaults for Hayes-compatible modems. Verify that the settings are compatible with your modem. To run the Page Manager component 1 From the application-level menu, choose Navigate > Site Map > Administration - Server Management > Jobs. 2 In the Jobs list, click New. 3 From the Component/Job drop-down list, select the Page Manager component. 4 In the Job Parameters list, click New. 5 Click on Parameters in the Server Tasks applet and enter your parameters. See Table 70 for a list of parameters. The 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. If you do not specify a parameter, the default values described in Table 70 are used. Table 70. Parameters for the Page Manager Component Parameter Value Modem Port The component object model (COM) port where the modem is attached. Valid values are COM1, COM2, and so on. Default = COM1 Dial Prefix A number or sequence of numbers that needs to be dialed to get an outside line. If no dial-out prefix is use, insert a “,” (comma). Default = 9 Note that when dialing 9 for an outside line is not required and you are using srvrmgr.exe from the command line, specifying a comma for this parameter returns an error. But, if you set it to a hyphen (or any other non-dialable character) it will work correctly. Example command: SRVRMGR.EXE /g NT01022 /e SBLPRD_ENT502 /s SBLPRD_APP502 /u ***** /p ***** /c "START TASK FOR COMPONENT PageMgr WITH DialPrefix = '-'" Long Distance The long-distance prefix. This value is added in front of all long-distance phone Prefix numbers. Set this parameter to equal an empty string if your location does not require a long-distance prefix to be dialed. Default = 1 Siebel Business Process Framework: Workflow Guide Version 8.0 27 1
    272. Workflow Policies ■ About Workflow Policies Server Administration Table 70. Parameters for the Page Manager Component Parameter Value Local Area Code The area code of your location. If the beginning digits of a phone number are equal to this code, they are removed before the phone number is dialed, and the long-distance prefix will not be added. Default = <empty> Delay1 The number of seconds to wait between dialing a phone number and simulating key presses for the first set of numbers. This applies only to numeric paging. It is ignored for alphanumeric paging. Default = 12 Delay2 The number of seconds to wait between simulating key presses for the first and second set of numbers. This applies only to numeric paging. It is ignored for alphanumeric paging. This is also ignored if the numeric pager does not have a personal identification number (PIN). Default = 4 Modem Reset A modem command used to reset the modem. String Default = ATZ Refer to your modem documentation for the correct command. Modem Init A modem command used to initialize the modem. String Default = AT&FQ0V1 Refer to your modem documentation for the correct command. For example, some modems require a numeric value after &F. Modem Dial A modem command used to dial the modem. You should rarely need to change String this parameter. Default = ATDT Modem Hangup A modem command used to hang up the modem. You should rarely need to String change this parameter. Default = ATH Modem Restore A modem command used to restore the power-up settings of the modem. You String should rarely need to change this parameter. Default = AT&F Request Key When you have more than one Page Manager, the request key serves as the ID for each Page Manager. You can then specify this key for the Workflow action in the Workflow Action Argument view. The request key can be any string. Troubleshooting the Email and Page Managers Email Manager stops processing when it is unable to log on to the mail server (SMTP/POP3-compliant server) and logs an error message in the trace files. 272 Siebel Business Process Framework: Workflow Guide Version 8.0
    273. Workflow Policies ■ About Workflow Policies Server Administration Page Manager stops processing if the modem is not available. The requests continue to accumulate in the Requests table. After you fix your processing problems, you must restart the servers. The servers will continue processing from where they left off. If Email Manager is able to log on but has a problem sending a particular email, it logs an error message and continues on to the next request. If Page Manager is able to interface with the modem but has a problem with a given page send, it will log an error and move on to the next request. When Workflow Policies executes email and paging actions, it actually 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 have a status of “QUEUED.” After a request is picked up by Email Manager or Page Manager, but before it is processed, it has a status of “ACTIVE.” After a request is processed, its status becomes SUCCEEDED if the processing is successful, or FAILED if an error occurs. To generate the sending emails, Siebel Server uses the UNIX “Mail” command. To verify that your server platform can run the command to a valid recipient and verify the email was successfully sent, do the following: 1 From the UNIX command prompt type: >mail recipient email address where recipient email address is a valid address. 2 Then, type a message ending with a period on the last line to indicate the end of the message. Then, press enter. If email written to S_APSRVR_REQ is not sent, though the Email Manager trace file shows status SUCCEEDED, check that 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 enabled in Outlook for email messages to be sent successfully. Executing Workflow Policies with Workflow Monitor Agent To execute your Workflow policies, you need to start Workflow Monitor Agent. Workflow Monitor Agent checks when the conditions of policies are met, and executes actions once those conditions are met. You start and stop the Workflow Monitor Agent task in the Administration - Server views. Siebel Business Process Framework: Workflow Guide Version 8.0 27 3
    274. Workflow Policies ■ About Workflow Policies Server Administration Table 71 describes Workflow policies database tables. Table 71. Workflow Policies Database Tables Table Description S_ESCL_REQ This table holds the potential matching requests caused by applications. S_ESCL_STATE This table holds the time-based policy matches. S_ESCL_ACTN_REQ (Optional) This table holds the requests to execute actions. This is only used if you use Action Agent=TRUE. S_ESCL_LOG This table holds a history of base table rows that have matched policies. What Workflow Monitor Agent Does Workflow Monitor Agent performs several server processes that monitor the Siebel database. Workflow Monitor Agent: ■ Checks the Escalation Requests table to see when the conditions of a policy are met ■ Monitors all policies within a single group NOTE: You can only run one Workflow Monitor Agent process against a specific group at one time. You can run multiple Workflow Monitor Agent processes at the same time, but they must be against different groups; if you run two Workflow Monitor Agent processes against the same group, deadlocks will occur. ■ If you use Action Agent = True, this generates requests for Workflow Action Agent in the Action Request table (S_ESCL_ACTN_REQ) ■ Purges requests from the S_ESCL_REQ table after processing. When a database trigger is activated because a workflow policy condition is met, a record is inserted into the Escalation Request table, S_ESCL_REQ. Workflow Monitor Agent (Workmon) evaluates the request against the rules set up by the policies in the workflow policy group If you use Action Agent = True, and if Workmon determines that the request in the S_ESCL_REQ table has no duration defined in the policy, Workmon either takes direct action and logs an entry into the S_ESCL_LOG table or sends it to the S_ESCL_ACTN_REQ table. 274 Siebel Business Process Framework: Workflow Guide Version 8.0
    275. Workflow Policies ■ About Workflow Policies Server Administration If Workmon determines that the request has a time element that must be met, the request is sent to the S_ESCL_STATE table along with the expiration time. The request stays in the S_ESCL_STATE table until the expiration time is met, or the request is removed because the conditions of the policy are no longer met. Workmon 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 use Action Agent = True, then as each match occurs WorkMon either 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 has a specified duration, the duration time is calculated from the time WorkMon detects that the row is in violation of the policy, not from the time the row was inserted into S_ESCL_REQ. For example, if you create a policy and set the duration as one week, but then WorkMon is not started until several days after Generate Triggers is run, the policy action will fire one week from when WorkMon is started, not one week from when the policy is created or Generate Triggers is run. When the request for an action is made to the S_ESCL_ACTN_REQ table, Workflow Action Agent executes the action and logs an entry into the S_ESCL_LOG table. More information about Workflow Monitor Agent is provided in the following sections: ■ “Using Workflow Monitor Agent” on page 275 ■ “Using Workflow Action Agent” on page 281 ■ “Starting Workflow Agent Processes Automatically with Siebel Server” on page 283 Using Workflow Monitor Agent Before you start Workflow Monitor Agent, you must create a separate server component definition for each Workflow Monitor Agent task. You can start Workflow Monitor Agent from the Server Manager command-line interface. Replication and Workflow Monitor Agent Within 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 be running a Workflow Monitor Agent that monitors a group called Group 1. Meanwhile, in the headquarters, there is another WorkMon running, which monitors a group called Group 2. In this way, the organization is able to run Workflow Policies where needed, while working with the restriction of one WorkMon for one group. NOTE: You cannot run more than one instance of Workflow Monitor Agent and Workflow Action Agent for a particular workflow group. However, you are allowed to have multiple Workflow Monitor Agent and Workflow Action Agent processes for different groups running at the same time. Starting Workflow Monitor Agent The following activities are involved in starting Workflow Monitor Agent: ■ “To create a Workflow Monitor Agent component definition” on page 276 Siebel Business Process Framework: Workflow Guide Version 8.0 27 5
    276. Workflow Policies ■ About Workflow Policies Server Administration ■ “To set parameters and activate a Workflow Monitor Agent component definition” on page 276 ■ “To start Workflow Monitor Agent using the Server Manager command-line interface” on page 276 Table 73 on page 278 shows Workflow Monitor Agent parameters. To create a Workflow Monitor Agent component definition 1 In the Siebel client, from the application-level menu, choose Navigate > Site Map > Administration - Server Configuration > Enterprises > Component Definitions. 2 In the Component Definitions list, click New. 3 Complete the fields described in Table 72: Table 72. Component Definitions Fields Field Description Name Name of the component Component Type WorkMon Component Group Select an existing component group Description Description of the component Alias Alias for the component. The alias can not contain blank spaces. 4 From the applet-level menu, choose Save Record. The component definition is saved. To view the definition, you must perform a query. To set parameters and activate a Workflow Monitor Agent component definition 1 In the Component Definitions list, perform a query for the component definition. 2 (Optional) You may make additional changes to the component parameters. For a description of Workflow Monitor Agent parameters, see Table 73 on page 278. 3 From the Component Definitions list applet-level menu, choose Enable Component Definition. The definition state changes from “Creating” to “Active.” 4 Restart the Siebel server. Your changes take effect. To start Workflow Monitor Agent using the Server Manager command-line interface 1 Start the server manager by entering: srvrmgr /g <Siebel Gateway Name Server address> /s <Siebel server name> /e <enterprise server name> /u <server administrator username> /p <server administrator password> 276 Siebel Business Process Framework: Workflow Guide Version 8.0
    277. Workflow Policies ■ About Workflow Policies Server Administration 2 Start a new Workflow Monitor Agent task in background mode by entering: start task for component WorkMon with SleepTime=<time>,GroupName=<group name> NOTE: You will need to create a separate server component definition for each Workflow Monitor Agent task. To run the Workflow Monitor Agent task 1 From the application-level menu, choose Navigate > Site Map > Administration - Server Management > Jobs. 2 In the Jobs list, click New. 3 From the Component/Job drop-down list, select the name of the server component defined for this Workflow Monitor Agent task. 4 In the Job Parameters list, click New. Specify the parameters for the Workflow Monitor Agent. See Table 73 on page 278 for a list of parameters. 5 In the Job Detail form applet, from the applet-level menu, select Start Job to begin Workflow Action Agent task. NOTE: Run only one instance of Workflow Monitor and Workflow Action Agent for a given workflow group. For example, you can start only one instance for the “Sales” group at a specific time. However, you are allowed to have multiple Workflow Monitor and Workflow Action Agent processes for different groups running at the same time. Siebel Business Process Framework: Workflow Guide Version 8.0 27 7
    278. Workflow Policies ■ About Workflow Policies Server Administration Table 73 shows Workflow Monitor Agent parameters. Table 73. WorkMon Command-Line Interface Parameters Parameter Default Name Display Name Description Value ActionAgent Use Action Agent Determines if Action Agent is automatically FALSE run with Monitor Agent. If set to FALSE (the default setting), the Workflow Action Agent server component starts within Workflow Monitor Agent, and actions are then executed by Workflow Monitor Agent. You must start Workflow Action Agent separately when using email consolidation and when the parameter Use Action Agent is set to TRUE. ActionInterval Action Interval Action execution interval in seconds. This 3600 argument determines when actions for a given policy are executed again on a given base table row. The purpose of this argument is to limit the number of times actions are executed if a row keeps going in and out of a matching condition. In other words, if the same record repeatedly violates the same policy before the action interval expires, the record will be removed from the S_ESCL_REQ table and the action will not be performed again. Note: The default is 3600 seconds. If this parameter is used, the value must be greater than 0 (zero) or unexpected behavior may result. BatchMode Processes the Determines if Monitor Agent is running in FALSE batch policies batch mode. When the value is set to TRUE, only the policies that have the Batch flag set to TRUE will be evaluated. When FALSE, only the policies that have the Batch flag set to FALSE will be evaluated. Note that when starting with Batch Mode set to TRUE, Workflow Monitor Agent will run once; that is, it will go through all records in the table and then exit out. 278 Siebel Business Process Framework: Workflow Guide Version 8.0
    279. Workflow Policies ■ About Workflow Policies Server Administration Table 73. WorkMon Command-Line Interface Parameters Parameter Default Name Display Name Description Value CheckLogCach Cache size of Number of policy violations to store in cache. 100 eSz Policy violations DeleteSize Request delete This indicates the number of records to 500 size commit at a time. The minimum is 1. If Workflow Monitor encounters deadlocks, you may reduce the default to 125 with minimal performance degradation. Note: to avoid call stack errors, do not set the Request Delete Size value to zero. GenReqRetry Number of Number of seconds to retry sending a 120 seconds to retry Generic Request message. GroupName Group Name Required. Workflow policy group that Monitor Agent works on. IgnoreError Ignore errors Ignore errors while processing requests. By FALSE default, the Workflow Monitor and Action agents will not ignore errors that occur while processing the requests. If Ignore Errors is set to TRUE and an error is encountered, the agent processes will log the error condition, delete the request, and continue working. By setting this argument to FALSE, the agent processes will exit on an error and send an email message to the mail ID specified by the Mailing Address argument. When running Workflow with Ignore Errors=TRUE, note that valid errors will be ignored. Whereas, if Ignore Errors is set to FALSE, the agent stops and exits with the error. It is recommended that you set Ignore Errors to FALSE so that valid errors are not ignored. KeepLogDays Number of days Number of days worth of violation 30 to keep violation information that should be retained. information Sets the number of days log information is stored. Log information older than the number of days set is automatically removed from the system. This value can be set to 0 to prevent the purging of this log information. Siebel Business Process Framework: Workflow Guide Version 8.0 27 9
    280. Workflow Policies ■ About Workflow Policies Server Administration Table 73. WorkMon Command-Line Interface Parameters Parameter Default Name Display Name Description Value LastUsrCacheS Cache size of Number of last user information items to 100 z last user cache. When executing actions, the information information about the last user to modify the base table row 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. MailServer Mail Server Name of email server to send notification of abnormal termination. MailTo Mailing Address Mail address to review notification of abnormal termination. Mail to <mail ID> if a Workflow Agent process exits with an error condition. An error can be caused by the failure of an action to execute, invalid object definitions, and so on. NumRetries Number of Number of retries for recovery. This 10000 Retries parameter works with the Retry Interval and Retry Up Time parameters to reconnect MTS or Siebel Server mode components to the database if database connectivity has been lost. ReloadPolicy Reload Policy Policy reload interval in seconds. This 600 argument defines the frequency that policies are reloaded into the engine. This allows changes 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. 280 Siebel Business Process Framework: Workflow Guide Version 8.0
    281. Workflow Policies ■ About Workflow Policies Server Administration Table 73. WorkMon Command-Line Interface Parameters Parameter Default Name Display Name Description Value Requests Requests per Maximum number of requests read per 5000 iteration iteration. This controls the maximum number of requests WorkMon reads from the requests queue within one iteration. Between iterations WorkMon deletes processed requests from the requests queue and commits, optionally reloads policies from the database, checks for shutdown request, and optionally sleeps. In other words, you can think of the Requests Per Iteration parameter as a way to control the maximum amount of work WorkMon performs before taking these between-iteration steps. Sleep Time Sleep Time The time in seconds that the Workflow Agent 60 process “sleeps” after it has polled for events and fulfilled all obligations to notify. Once it has completed its obligations, the Workflow Agent process stops polling for 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. NOTE: You can separate the processes for load balancing or run one process for ease of testing. Using Workflow Action Agent The Workflow Action Agent process submits a request to Email Manager and Page Manager when actions are to be taken. NOTE: You will need to create a component definition for each Workflow Action Agent task. Workflow Action Agent: ■ Processes requests logged in the action request table (S_ESCL_ACTN_REQ) for a single group. ■ Invokes all actions linked with the Workflow policy being processed. ■ Logs email and page actions in the S_APPSRVR_REQ table for execution by Email Manager and Page Manager. ■ Purges requests from S_ESCL_ACTN_REQ after processing. Siebel Business Process Framework: Workflow Guide Version 8.0 28 1
    282. Workflow Policies ■ About Workflow Policies Server Administration If the Use Action Agent parameter is set to TRUE in the Monitor Agent process, you need to perform the following steps to start the Action Agent process. To run the Workflow Action Agent process ■ You start the Workflow Action Agent in the same way that you start the Workflow Monitor Agent. See “Starting Workflow Monitor Agent” on page 275. NOTE: You should start one Workflow Action Agent for only one Workflow Monitor Agent. ■ When using email consolidation, and when the parameter Use Action Agent is set to TRUE on the Workflow Monitor Agent, you must start Workflow Action Agent separately. For more information on arguments for starting a Workflow Agent process, refer to Siebel System Administration Guide. To shut down the Workflow Agent process ■ You shut down the Workflow Action Agent in the same way that you shut down the Workflow Monitor Agent. When restarting a workflow policy process, a Workflow Agent process immediately begins tracking all relevant activities that have occurred since it was shut down. Using Workflow Action Agent for Batch Workflows Workflow Action Agent is not only related to dynamic policies; you can start Workflow Action Agent separately for batch policies. To run Workflow Action Agent for batch workflows 1 Start Workflow Monitor Agent with the following parameters: ■ Group Name ■ Processes the batch policies = TRUE ■ Use Action Agent = TRUE 2 Start Workflow Action Agent with the following parameter: ■ Group Name 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 S_ESCL_ACTN_REQ and deletes the rows from S_ESCL_ACTN_REQ afterward. The Workflow Action Agent may be of use, if the action being executed is long-running or intensive. In general, however, Workflow Action Agent will not help with batch workflows. 282 Siebel Business Process Framework: Workflow Guide Version 8.0
    283. Workflow Policies ■ About Workflow Policies Server Administration Starting Workflow Agent Processes Automatically with Siebel Server You can specify that the Workflow Agent Process for a Workflow Group automatically starts when the Siebel Server is started. To start a Workflow Monitor Agent Process automatically 1 Expose the Default Tasks component parameter by navigating to Show Advanced Objects and setting the value to TRUE. 2 In the Siebel client, from the application-level menu, choose Navigate > Site Map > Administration - Server Configuration > Enterprises > Component Definitions. 3 In the Component Definitions list, select the Workflow Monitor Agent in Server Components and set the parameters in Component Parameters to the following values: ■ Group Name. Enter the name of Workflow Group you want to start under Current Value. It will be copied to Value on Restart. ■ Default Tasks. Enter 1 under Value on Restart for starting one Workflow Agent. ■ Use Action Agent. Default is False, which means Workflow Action Agent is run automatically in Workflow Monitor Agent. See Table 73 on page 278 for a detailed description of these parameters. NOTE: If you want to Workflow Action Agent to run as a separate process for the above Workflow Monitor Agent, follow the above steps plus the following revised Step 3: Enter True under Current Value for Use Action Agent. To start multiple Workflow Monitor Agent Processes for multiple Workflow Groups 1 See Siebel System Administration Guide for instructions on creating a defined component. Create a defined component as a Server mode component with WorkMon Component Type, and then assign the component to Siebel Server. 2 Create a defined component for each additional Workflow Group. 3 Follow the steps listed above to configure each component to start automatically. Deleting Expired Workflow Policies Triggers are still in effect at the time you expire or delete policies and shut down Workflow Monitor, and triggers related to expired or deleted policies continue to function since they are attached to database tables until they are deleted from the database. So, between the time you expire policies and the time you finish dropping and recreating triggers, there can be rows triggered for the expired policies in S_ESCL_REQ. Siebel Business Process Framework: Workflow Guide Version 8.0 28 3
    284. Workflow Policies ■ About Workflow Policies Server Administration You may get the error ESC-00054 while starting Workflow Monitor because WorkMon looks for the policies referenced in S_ESCL_REQ and finds policies that are inactive or not present. The policies are stored in the S_ESCL_RULE table. Those rows should remain in S_ESCL_REQ and should not be processed at all. Given ‘Use Action Agent’ = FALSE for Workflow Monitor, WorkMon also acts for Action Agent, bypasses the S_ESCL_ACTN_REQ table, and uses only the S_ESCL_REQ table. If you have rows in the S_ESCL_REQ table for policies that are expired or deleted, then you must delete them before starting Workflow Monitor for the two reasons mentioned above, that is: ■ to avoid the error ESC-00054 when starting Workflow Monitor. ■ normally, Workflow Monitor doesn’t process the rows at all; they just sit in the S_ESCL_REQ table taking up the space. You can delete the rows by RULE_ID, which is the unique identifier for a Workflow Policy. Back up the database prior to doing the delete. Example Queries The following are queries that can help you determine whether you have rows in S_ESCL_REQ that are related to deleted or expired policies. Deleted Policies 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 Expired Policies Where sysdate is the Oracle current date-time function: 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 284 Siebel Business Process Framework: Workflow Guide Version 8.0
    285. Workflow Policies ■ About Workflow Policies Server Administration If you determine that the policies have expired unintentionally—for example, because someone forgot to extend the dates—and you want to process the rows (and it is understood that nobody has changed the triggers since the policies expired), then you can do the following, which also applies to policies with a duration: ■ If the Workflow Monitor is running and you do not want to shut it down, unexpire the policies by putting a date-time greater than the current date-time in the Expiration Date field for policies. ■ After a period of 10 minutes, the policy will take effect. This is because the Reload Policy parameter of Workflow Monitor is set to 600 seconds as the default. ■ If you want the policy to take effect immediately, then you can shut down Workflow Monitor (if running), unexpire the policies, and start Workflow Monitor. About Workflow Policies and Siebel Server Task Trace Files Whenever you start a Workflow Policies server process, a Siebel Server task trace file is created so that you can check for error messages and other information about the process. Trace files are created for the following Siebel Server processes: ■ Generate Triggers ■ Page Manager ■ Email Manager ■ Workflow Monitor Agent ■ Workflow Action Agent You can view trace file information in one of two places: ■ The Siebel Server Tasks > Tasks Info Log in Administration - Server Management. See “Viewing Trace Files in Siebel Server Administration” on page 285. ■ The log directory of your Siebel Server. See “Viewing Trace Files in the Siebel Server Log Directory” on page 286. Viewing Trace Files in Siebel Server Administration You can view trace files from the Administration - Server Management view. To view trace files ■ In the Siebel client, from the application-level menu, choose Navigate > Site Map > Administration - Server Management > Tasks > Log. The Tasks applet lists the status of all the Siebel Server tasks either running or started. Siebel Business Process Framework: Workflow Guide Version 8.0 28 5
    286. Workflow Policies ■ About Workflow Policies Server Administration Viewing Trace Files in the Siebel Server Log Directory You can also use Windows Explorer to navigate to your Siebel Server log directory. Under log, select the server’s name to see a file that lists all the trace files for each server process. You can double-click the Trace File icon to access the trace file. You can view the trace file for any application server task. See Siebel System Administration Guide for more information on using trace files. About Tracing and Event Log Levels Workflow Policies uses the events described in Table 74 for logging. Table 74. Workflow Policies Logging Events Event Level Description SqlParseAndExecute 4 Traces all SQL statements and execution times. Object Assignment 3 Traces Workflow Monitor Agent while it is doing Dynamic Assignment. Use in conjunction with Rules Evaluation. Rules Evaluation 4 Traces Workflow Monitor Agent while it is doing Dynamic Assignment. Use in conjunction with Object Assignment. Task Configuration 4 Parameter configuration of the server task. NOTE: Setting trace levels above default parameters will affect performance. Reset trace levels to default parameters after troubleshooting has been completed. About Workflow Policies Analysis Charts and Reports Siebel Workflow Policies provides several charts for analyzing how frequently a workflow policy condition is met and the total number of policy instances occurring in a specified period of time. Workflow Policies also provides reports that summarize Workflow Policy and Workflow Log information. More information about analysis charts and reports is provided in the following sections: ■ “Using the Policy Frequency or Trend Analysis Chart” on page 286 ■ “Using Workflow Policies Reports” on page 287 Using the Policy Frequency or Trend Analysis Chart Policy Frequency Analysis provides you with information about the number of times a Workflow policy executes. Policy Trend Analysis provides you with information about policy execution trends. 286 Siebel Business Process Framework: Workflow Guide Version 8.0
    287. Workflow Policies ■ About Workflow Policies and Siebel Marketing To view the Policy Frequency or Trend Analysis chart ■ From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Policy Frequency Analysis. This view has two applets: ■ Monitor Log. This lists the workflow policies. ■ Workflow Policy Frequency/Trend Analysis. The Workflow Policy Frequency Analysis applet displays a chart illustrating the execution frequency of a selected policy. The Workflow Policy Trend Analysis applet shows the total number of workflow policy conditions met over a specified period of time. To toggle between the two analysis applets, use the toggle list on the chart applet. Using Workflow Policies Reports In the Workflow Policies Policies and Log views, you can bring up a Reports page that you can print out. To bring up the report, select Reports from View. The Reports page that appears provides summary information of the Workflow Policy. If you need to review all the business rules for your organization, you can print out the Reports page for each of your workflow policies. About Workflow Policies and Siebel Marketing This section describes workflow policy programs for campaign execution. Using Workflow Policy Programs for Campaign Execution The Workflow Policy programs in Siebel Marketing were designed to allow a marketer to create complex campaign policies to automate the different stages of the campaign. Actions are based on the type of workflow policy program used and are used by Workflow Policies to create campaign policies. Three workflow policy programs are designed for creating actions to execute campaigns: ■ Send Campaign Email. Sends email to all contacts and prospects associated with a campaign. See “Using the Send Campaign Email Workflow Policy Program” on page 288. ■ Create Email Activity. Creates an activity record on all the contacts or prospects that were sent an email. See “Using the Create Email Activity Workflow Policy Program” on page 288. ■ Assign to Campaign. Takes a contact or a prospect and assigns it to a chosen campaign. See “Using the Assign to Campaign Workflow Policy Program” on page 289. Siebel Business Process Framework: Workflow Guide Version 8.0 28 7
    288. Workflow Policies ■ About Workflow Policies and Siebel Marketing Using the Send Campaign Email Workflow Policy Program The Send Campaign Email program provides marketers with the ability to send emails to campaign contacts and prospects. Send Campaign Email has new Available Substitutions in the Send Message Arguments applet, such as [Prospect First Name], to allow for personalization of campaign emails. To add a new substitution, you need to edit the SQL Statement corresponding to your Database Platform in Siebel Tools, Program | Programs Argument. Modify the Default Value for SQL Statement Outputs. These variables are for holding the result of the query statement. These variables also correspond to the Available Substitution in the Send Message Argument applet. The Recipients applet is where you select the Recipient Type. The campaign contacts and prospects to whom the email will be sent are seen in the Contacts/Prospects applet in the Campaign Administration view. Using the Create Email Activity Workflow Policy Program This workflow policy program in a campaign creates an activity record on all the contacts or prospects that were sent an email. In the Arguments applet, you specify the data that fills in the columns on the record you are creating on the Contact Activity table. Table 75 describes valid values for the Arguments applet. Table 75. Create Email Activity Program Arguments Argument Value Name Description: Text of activity. Status: Choose activity status such as planned or active from the picklist. Type: Choose Activity type from the picklist. Required This value indicates whether the argument is required. Value Text or picklist. 288 Siebel Business Process Framework: Workflow Guide Version 8.0
    289. Workflow Policies ■ About Workflow Policies and Siebel Marketing Using the Assign to Campaign Workflow Policy Program This workflow policy program adds the selected contact or prospect to the list of campaign contacts or prospects for the designated campaign. Table 76 describes the value for the New Campaign argument. Table 76. Assign to Campaign Program Argument Argument Value New Campaign Picklist that allows you to choose a campaign to which you will assign the contact or prospect. Scenario for Creating a Marketing Campaign with Workflow Policies In this scenario, a marketer wants to run a two-tier campaign with different actions taken depending on how the campaign recipient responds. The marketer is calling the campaign the “CD-ROM Promotion.” This is how the marketer wants the campaign to work: ■ An email is sent telling recipients they can receive a discount by ordering a new product over the phone. The marketer wants to keep track of the recipients and to give them two weeks to respond. ■ At the end of the two-week period, any recipients who did not respond to the offer are assigned to a new campaign. To set up this campaign, the marketer must perform the following activities: ■ Define the actions to be used by the policies. See “Defining the Workflow Policy Actions” on page 289. ■ Create a workflow policy group for the campaign. See “Creating the Workflow Policy Group” on page 291. ■ Create the policies for the two tiers of the campaign. See “Creating the Policies” on page 291. Defining the Workflow Policy Actions Three Workflow policy actions are required for this scenario: ■ Send Campaign Email. To send the offer email to the campaign recipients. ■ Create Email Activity. To record the email activity in a table. ■ Assign to Campaign. To assign nonrespondents to a new campaign. The steps for creating the three actions are described below. To create a Send Campaign Email action 1 Create a new record in the Workflow Policies Actions view. Siebel Business Process Framework: Workflow Guide Version 8.0 28 9
    290. Workflow Policies ■ About Workflow Policies and Siebel Marketing a Enter the name of the action: Send First Campaign Contact b Select a predefined program from the Program field: Send Campaign Email c Select the following predefined Workflow Policy Object from the Workflow Object field picklist: Campaign Contact d Enter any appropriate text in the Comments field if needed. 2 Fill in the Send Message Arguments applet. Select dynamic fields from Available Substitutions where appropriate. a Enter text and dynamic fields in Subject. b Enter text and dynamic fields in Message Template for sending email to Contacts. 3 Fill in the Recipients applet. a Select a predefined Recipient Type from the Recipient Type field picklist. b Select the Recipient Name from the Recipient Name picklist. To create a Create Email Activity action 1 Create a new record in the Workflow Policies Actions view Actions applet. a Enter the name of the action: First CD-ROM Campaign b Select a predefined Workflow policy program from the Program field: Create Email Activity c Select a predefined workflow policy object from the Workflow Object field picklist: Campaign Contact d Enter text in the Comments field if needed. 2 Fill in the Arguments applet with the activity table field name and the appropriate text. To create an Assign to Campaign Email action 1 Create a new record in the Workflow Policies Actions view Actions applet. a Enter the name of the action: Assign to Campaign b Select a predefined workflow policy program from the Program field: Assign to Campaign 290 Siebel Business Process Framework: Workflow Guide Version 8.0
    291. Workflow Policies ■ About Workflow Policies and Siebel Marketing c Select a predefined workflow policy object from the Workflow Object field picklist: Campaign Contact d Enter text in the Comments field if needed. 2 Fill in the Arguments applet to indicate the name of the new campaign. Creating the Workflow Policy Group All policies must be assigned to a workflow policy group, so in this scenario a group is created just for campaigns. To define a Workflow Policy Group 1 Create a new record in the Workflow Policies Groups view. 2 Enter the name of the workflow policy group for this policy: Campaign Group This is the name entered into the Group field in the Workflow Policies Policies view. Creating the Policies Once the workflow policy actions and the workflow policy group are ready, the policies can be created. Two policies are required in this scenario: ■ Email for CD-ROM campaign—to trigger the sending of the offer email and the email activity record. ■ Assign Non-Respondents—to trigger the reassignment of nonrespondents to a new campaign. In the procedures below for creating the policies, it is important to note how the fields in the Conditions applet are set. To create the Email for CD-ROM Campaign policy 1 Fill out the Policies Applet in the Workflow Policies Policies view. a Enter the policy name: Email for CD-ROM campaign b Choose a workflow policy object from the picklist: Campaign Contact c Choose a workflow policy group from the picklist: Campaign Group d Enter a zero in the Duration field. 2 Fill out the Conditions Applet in the Workflow Policies Policies view. Siebel Business Process Framework: Workflow Guide Version 8.0 29 1
    292. Workflow Policies ■ About Testing Workflow Policies a Enter a campaign name: 1st CD-ROM Promotion b Enter a start date. c Enter a campaign status of Active. This is the trigger that sets off the campaign. To create the Assign Non-Respondents policy 1 Fill out the Policies Applet in the Workflow Policies Policies view. a Enter the policy name: Non-Respondents of CD-ROM campaign b Choose a workflow policy object from the picklist: Campaign Contact c Choose a workflow policy group from the picklist: Campaign Group d Enter 14 days in the Duration field. 2 Fill out the Conditions Applet in the Workflow Policies Policies view. a Enter a campaign name: 1st CD-ROM Promotion b Enter a campaign status of Active. This is the trigger that sets off the campaign. c Enter N in the Done field. If the Policy duration is set to 14 days and Done is equal to N in the Conditions applet (meaning that no flag exists in the activity record for this recipient), then the policy executes in 14 days. That is, everyone who did not respond to the first campaign is assigned to a new campaign after 14 days. About Testing Workflow Policies This section describes testing and troubleshooting procedures. Testing your workflow policies before implementing them into your production environment allows action recipients to receive accurate and useful information and the results are exactly what you want. You need to develop a testing and migration procedure for introducing changes into the production environment. Some of the considerations for creating a test and migration environment are discussed in “Defining a Test and Migration Strategy for Workflow Policies” on page 209. Before you can test your new workflow policies, you must install the Siebel Server workflow policy components on the Siebel Server. See Siebel System Administration Guide for more information. CAUTION: Your test environment and production environment must have identical versions of the software. 292 Siebel Business Process Framework: Workflow Guide Version 8.0
    293. Workflow Policies ■ About Testing Workflow Policies Testing New Policies and Monitoring the Results You need to test your new workflow policies by entering data that meets all the workflow policy conditions you defined in the policy. Test each of the newly defined workflow policies, workflow policy conditions, and workflow policy actions to verify that: ■ The policies, conditions, and actions are correctly defined ■ The policies, conditions, and actions accurately define the transactions (the correct columns) you want to monitor ■ The actions are what you want and occur when you want them ■ The action interval and sleep times are correctly defined Correctly testing your workflow policies and eliminating any problems are critical before implementing the policies in your production environment. Make sure your database triggers are created, the email and pager server processes are running, and your Workflow Agent processes are running before you test and monitor the new policies. You verify your action by checking to see if the proper action occurs. That is, you can check that the email arrives or the pager goes off. You can monitor Workflow Agent progress using the Workflow Policies Log view. The Workflow Policy Log view displays a log of all the records that meet a policy condition tracked by the Workflow Monitor Agent process. You access the Workflow Policy Log view from the Siebel client. The view contains the following fields: ■ Policy. The name of the policy. ■ Workflow Object. The name of the workflow policy object. ■ Object Identifier. The ID of the workflow policy object for which the policy condition was met. ■ Object Values. Identifying information for the row that met the policy condition. ■ Event Date/Time. The date and time the policy condition was met. Once you have verified that the workflow policies work as expected, you can migrate the workflow policies to your production environment. Troubleshooting Workflow Policies Because workflow policies are based on database triggers, a workflow policy can take effect on a database record only after the record is committed. If you have a policy that is based on multiple database tables, the policy takes effect only if the records on all 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 policy with conditions Opportunity Revenue > 10M and Lead Quality = high takes effect only when the records are committed on both tables. Siebel Business Process Framework: Workflow Guide Version 8.0 29 3
    294. Workflow Policies ■ Migrating Policies to the Production Environment Also keep in mind that multiple business components can be created for the same database table using search specifications. If you are creating a workflow policy component to monitor a business component, be sure to include all the fields that are being used in search specifications as workflow policy columns. The workflow policy column can then be used in the policy conditions to allow appropriate behavior to be enforced. If your workflow policy action does not occur, check the following: ■ Verify that your test record meets ALL your workflow policy conditions. ■ Verify that the client configuration file is pointing to the correct enterprise server (one error that can occur if the server is incorrect is ESC-00053, “Error loading rule definitions”). ■ Check the workflow policy activation date/time. ■ Check the monitor task: ■ Is the monitor awake and running against the correct group? ■ Search the Task Information log for the Row_Id of your test record. ❏ If Row_Id does not exist, run GENERATE TRIGGERS. ❏ Update your test record. ■ Check the Action Agent task: ■ Is Action Agent awake and running against the correct workflow policy group? ■ Search the Task Information log for the Row_Id of the test record. ■ Make sure your triggers are generated. Workflow Policies and Tracing Workflow Policies uses the General Events event for logging. To view informational messages, set the log level to 3. To view debugging information, set the log level to 4. Migrating Policies to the Production Environment To migrate fully tested policies to your production environment, you need to follow a process similar to the one used for implementing the policies in your test environment. To migrate to your production environment 1 Back up your production environment database. 2 Migrate your test repository environment into your production repository environment. The process is described in the upgrade guide for the operating system you are using. 294 Siebel Business Process Framework: Workflow Guide Version 8.0
    295. Workflow Policies ■ Predefined Programs 3 Re-enter your workflow policy action types, workflow policies, and workflow policy groups exactly as they are in the test environment into the production environment. NOTE: Information that you have entered using Siebel Tools does not need to be re-entered. 4 In the Siebel client, from the application-level menu, choose Navigate > Site Map > Administration - Server Management > Jobs. 5 In the Jobs list, click New. 6 From the Component/Job drop-down list, select Generate Triggers. This creates a new line entry but does not start the task. 7 In the Job Parameters list, click New to modify parameter settings. For a description of the component-specific parameters for Generate Triggers, see “About Workflow Policies Server Administration” on page 263. See Siebel System Administration Guide for a description of the generic and enterprise parameters. 8 Select Submit Query. See “About Workflow Policies Server Administration” on page 263 for more information on trace files. For more information on using trace flags, see Siebel System Administration Guide. NOTE: To help prevent invalid triggers from being applied to your production environment, apply your database triggers to your test environment before you apply them to your production environment. Predefined Programs The following is a list of all predefined programs. These programs have been created from the five program types: ■ Send Page ■ Send Email ■ Run External Program ■ Send Message Broadcast ■ Database Operation Table 77 contains common actions that you can use by inserting your own message text. Table 77. Predefined Programs Program Description Send Page Send Page Send a generic page message. Send Opportunity Page Send a page regarding an opportunity. Send Quote Page Send a page regarding a quote. Siebel Business Process Framework: Workflow Guide Version 8.0 29 5
    296. Workflow Policies ■ Predefined Programs Table 77. Predefined Programs Program Description Send SR Page Send a page regarding a service request. Send Email Send Email Send a generic email message. Send Opportunity Email Send an email regarding an opportunity. Send Quote Email Send an email regarding an opportunity quote. Send SR Email Send an email regarding a service request. Message Broadcast Send Message Broadcast Send a generic message broadcast. Send SR Message Broadcast Send a message broadcast regarding a service request. Send Opportunity Message Send a message broadcast regarding an opportunity. Broadcast Run External Program Run External Program Run an external program. Database Operation Change SR Close Date to Today Update the service request’s close date to today’s date. Change SR Owner Change the service request’s owner. Change SR Group Change the service request’s group. Change SR Owner to Manager Change the service request’s owner to the current owner’s manager. Change SR Priority Change the service request’s priority to a new value. Change SR Severity Change the service request’s severity to a new value. Change SR Status Change the service request’s status to a new value. Change SR Sub-status Change the service request’s sub-status to a new value. Create SR Activity Create a service request activity. Create Opportunity Activity Create an opportunity activity. 296 Siebel Business Process Framework: Workflow Guide Version 8.0
    297. 11 Reference Materials for Siebel Workflow This chapter provides reference information organized as follows: ■ “Siebel Workflow Terminology” on page 298 ■ “Examples of Creating Workflow Processes” on page 301 ■ “Predefined Business Services” on page 328 ■ “Passing Parameters to and from Workflow and Data Manipulation within Workflows” on page 336 ■ “Using Expressions with Workflow Processes” on page 342 Siebel Business Process Framework: Workflow Guide Version 8.0 29 7
    298. Reference Materials for Siebel Workflow ■ Siebel Workflow Terminology Siebel Workflow Terminology Table 78 and Table 79 describe the common terms for Workflow Processes and Workflow Policies. Table 78. Workflow Processes Terms Term Definition Arguments Data passed to or received from a process or step. Branch A possible outcome of a workflow process step. A branch can have one or more conditions. A branch is followed by a step in the workflow process definition. If all of the conditions for the branch are met, the work item proceeds to the step following the branch. Business object A group of one or more business components. A business object represents an entity in the Siebel application that you would like to monitor. A workflow process is based on one and only one business object. Business objects are defined in Siebel Tools. 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 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 definition can have one or more business service steps. Connector A definition of the relationship between two workflow process steps. Decision Point A type of step in a workflow process definition in which the work item branches off to different steps depending on a set of conditions. A Decision Point consists of all possible branches for that point in the business process. Each branch consists of one or more conditions that must be met for a work item to follow that branch. A workflow process definition can have one or more Decision Points. End A type of workflow process step that specifies when a process instance is finished. Exception A type of workflow process step that specifies when a process instance should follow an alternative branch instead of the normal branch path. Process property A storage field that contains values for use in steps as input and output arguments or for performing evaluations. Process A graphical flowchart interface used for debugging workflow processes. Simulator Siebel Operation A type of workflow process step that handles database operations such as insert, query, or update of a business component record or field. 298 Siebel Business Process Framework: Workflow Guide Version 8.0
    299. Reference Materials for Siebel Workflow ■ Siebel Workflow Terminology Table 78. Workflow Processes Terms Term Definition Start A type of step that defines the conditions for initiating an instance of a workflow process. When the conditions have been met, the process instance is initiated. A workflow process definition has one and only one start step. Step An activity within a workflow process. Steps are logically linked together to create a process definition. Step instance The instance of a process definition step that has been initiated. A start step is initiated when all conditions defined for the start step have been met. A Decision Point is initiated when all conditions for a decision branch have been met. All other steps are initiated when the previous step has completed. Stop A type of workflow process step that specifies the conditions that cause a process instance to terminate prior to completion. Subprocess A workflow process embedded into another workflow process as part of the workflow process definition. A subprocess has its own workflow process definition. A subprocess is a type of step. There can be one or more subprocess steps in a workflow process. Wait A type of workflow process step that specifies when a process instance should pause in execution and the duration of the pause. 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 activities within the business process. Workflow process An instance of a workflow process that has been initiated. A process instance instance is initiated when the input conditions for a process definition have been met. A process instance consists of one or more step instances and contains one or more work items. Work item The representation of the work being processed in the context of a step within a process instance. A work item is an instance of a business object. Table 79. Workflow Policies Terms Term Definition Business object A group of one or more business components. A business object represents an entity in Siebel that you would like to monitor. A workflow policy object is based on one and only one business object. Business objects are defined in Siebel Tools. Business rule The definition of how an organization wants to carry out a process in its operations. Object type An entity in Siebel Tools displayed as a node on the Object Explorer. For example, workflow policy objects, workflow policy components, workflow policy columns, and policy programs are all object types. Siebel Business Process Framework: Workflow Guide Version 8.0 29 9
    300. Reference Materials for Siebel Workflow ■ Siebel Workflow Terminology Table 79. Workflow Policies Terms Term Definition Policy action An event that Siebel executes when all policy conditions are true and all the workflow policy properties are satisfied. Policy actions are based on programs. Policy actions are defined in the Workflow Policies Actions view. Once you define a policy action, it can be used in a workflow policy. Policy condition A policy condition is an expression that is compared against the data in the Siebel database. The result of the comparison is either true or false. Workflow policy conditions are defined in the Workflow Policies Policies view. A policy condition is defined by selecting a workflow policy column, selecting a comparison operator, and entering or selecting a value, if appropriate. Program The definition of an event. Types of events are Send Email, Send Page, Database Operation, Send Message Broadcast, 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 would like to update. Programs are defined in Siebel Tools. 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 all the policy conditions for a workflow policy are true, then the policy action occurs. (That is, when all policy conditions are met.) A workflow policy is contained by one workflow policy group and is related to one workflow policy object. A workflow policy contains additional properties that govern its behavior. Workflow policies are defined in the Workflow Policies Policies view. Workflow policy A column that defines the column on the Siebel database table that you would column like to monitor. You use workflow policy columns when defining workflow policy conditions for a workflow policy. A workflow policy column must be associated with a workflow policy component for it to be used in a workflow policy. A workflow policy column that is associated with a workflow policy component is called a workflow policy component column. Workflow policy columns are defined in Siebel Tools. Workflow policy Components that define the Siebel database tables you would like to monitor. component Workflow policy components also define the relationships between tables. Workflow policy components contain workflow policy columns. Workflow policy components are defined in Siebel Tools. Workflow policy A workflow policy column that is associated with a workflow policy component. component Workflow policy component columns define the database columns that can be column used in workflow policy conditions for a workflow policy. Workflow policy component columns are defined in Oracle’s Siebel Tools. 300 Siebel Business Process Framework: Workflow Guide Version 8.0
    301. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes Table 79. Workflow Policies Terms Term Definition Workflow policy A group of one or more workflow policies. Workflow policy groups allow you to group group workflow policies sharing common desired behavior. Siebel Server processes monitor workflow policy groups. For example, workflow policies that need to be monitored hourly would be in a different workflow policy group than those that need to be monitored weekly. Workflow policy groups are defined in the Workflow Policies Groups view. Workflow policy A group of one or more workflow policy components. A workflow policy object object represents an entity in the Siebel application that you would like to monitor. A workflow policy is based on one and only one workflow policy object. Workflow policy objects are defined in Siebel Tools. Examples of Creating Workflow Processes This section provides the following examples on which you can model your development of workflow processes: ■ “Example: Attach an Activity Plan to an Opportunity and Test with the Process Simulator and the Run-time Client” on page 301 ■ “Example: Creating a Workflow Process Triggered by a Run-time Event” on page 313 ■ “Example: Creating a Service Flow Workflow” on page 316 ■ “Example: Run-time Event Workflow with User Interact Step to Navigate the End User to a View” on page 321 ■ “Example: Externalize Parameters to be Used by Siebel Workflow” on page 324 Example: Attach an Activity Plan to an Opportunity and Test with the Process Simulator and the Run-time Client This example takes the following steps: 1 Create a new workflow process. a Configure the steps within the workflow process. ❏ Configure a Siebel Operation step to perform an Insert operation. ❏ Configure a User Interact step to display a view. b Validate the workflow process. 2 Test the workflow process using the Process Simulator. 3 Call the workflow process from the UI using a run-time event. Siebel Business Process Framework: Workflow Guide Version 8.0 30 1
    302. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes 4 Publish and activate the workflow process. 5 Test the workflow process using the run-time client. Part 1: Create a New Workflow Process Your new workflow is going to create an activity plan on an opportunity record and then navigate the end user to a view to display the new plan. To create a new workflow for this example 1 In the Object Explorer in Siebel Tools, select the Project object. 2 In the Projects OBLE, find and lock the project called “Oppty (SSE)”. 3 In the Object Explorer, select the Workflow Process object. 4 In the Workflow Processes OBLE, right-click and create a new record with the following properties: ■ Name = Create Plan ■ Business Object = Opportunity ■ Workflow Mode = Interactive Flow ■ Project = Oppty (SSE) Figure 28. Create a New Workflow Process 5 Right-click and select Edit Workflow Process. 302 Siebel Business Process Framework: Workflow Guide Version 8.0
    303. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes 6 In the Process Designer, drag and drop step and connector icons from the palette to the canvas, as follows and as shown in Figure 29: a Add a Start step. b Add a Siebel Operation step. c Add a User Interact step. d Add an End step. e Place connectors between the steps as shown in Figure 29. Figure 29. Add Four Steps and Connectors 7 Give each step a meaningful name. You can change step names in the Properties window. The Properties window changes depending on context (for the appropriate step icon selected). NOTE: If the Properties window is not showing, select a step icon, then right-click and select View Properties Window. Select each step and change its name as follows: Step Name Start Start Siebel Operation Add Activity Plan to Oppty User Interact Display Activity Plan End End Siebel Business Process Framework: Workflow Guide Version 8.0 30 3
    304. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes To configure the steps for this example workflow 1 In the Process Designer canvas, select the Siebel Operation step (Add Activity Plan to Oppty). 2 Tell the workflow which operation you want it to perform (such as Query, Insert, or Update) and which business component to use for the operation. a Using the Properties Windows, set the following attributes for the step: Property Value Business Component Activity Plan Operation Insert When you perform an Insert operation on a business component, you must supply a value for any required field in the business component. In particular, to insert a new activity plan, you must provide the name of the activity plan template. 3 With the Siebel Operation step still selected, in the Multi Value Property Window, click the Field Input Arguments tab. 4 Right-click and select New Record to add a new input argument, and supply the following required values. Field Type Value Name Template Literal Any valid activity template name, such as Introductory Sales Call. 5 In the Process Designer canvas, select the User Interact step (Display Activity Plan). 6 Using the Properties Window, set the following attributes: Property Value User Interact View Opportunity Activity Plan 7 Tell the workflow which event will denote the end of the User Interact step. For example, you might want to wait for the user to enter additional data before continuing in the workflow. For this example, you want to wait for the user to make and save a change to the Activity Plan record. a The User Interact step requires a conditional branch. Select the connector between the User Interact step and the End step. Use the Properties window to set the following branch attributes: Property Value Type Condition Event Object Type BusComp 304 Siebel Business Process Framework: Workflow Guide Version 8.0
    305. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes Property Value Event Object Activity Plan Event WriteRecordUpdated Now that you have finished configuring the workflow, you are going to validate it to make sure each step performs as intended. To validate this example workflow 1 In the Process Designer, right-click and select Validate. 2 In the Validation dialog box, click Start. 3 If any error is reported, follow the instructions to fix it and then repeat Step 2 until no errors are reported. Once you have validated the workflow, you are ready to test it using the Process Simulator. Part 2: Test the Workflow Process Using the Process Simulator First you must verify that your Debug options are correctly set for process simulation. To prepare to test the workflow using the Process Simulator 1 Verify the Debug options for launching the simulation client. You need to do this because the Process Designer launches an instance of the mobile client executable to perform the simulation. a In Siebel Tools, select View > Options. b In the Debug tab, review the settings and modify them as needed for your environment. Siebel Business Process Framework: Workflow Guide Version 8.0 30 5
    306. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes c Click OK. The Debug tab is shown below. 2 Confirm that the Debug options are correct by launching a test client. To do this, type the F5 key on your keyboard. Because this example workflow is based on the Opportunity business object and the workflow attempts to add an activity plan to an existing opportunity, you must specify an opportunity row Id for the simulation. To specify an opportunity row Id for the simulation 1 In the Siebel client, navigate to Site Map > All Opportunities. 2 In the Opportunities list view, obtain the row_Id of one record. 3 Return to Siebel Tools and select the Create Plan workflow process in the Workflow Proceses list. View the workflow’s properties in the Multi Value Property window. NOTE: If the Multi Value Property window is not showing, with the workflow process selected, choose View > Windows > Multi Value Property Window. 4 In the Properties window, set the Default String value of the Object Id process property to the Opportunity row Id found in Step 2. 306 Siebel Business Process Framework: Workflow Guide Version 8.0
    307. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes 5 Close any running Mobile client sessions now. You will not be able to use the Process Simulator if there are running sessions. a Confirm there are no Siebel client icons in the Task Bar before continuing. You are now ready to simulate the workflow process. To launch the Process Simulator 1 In Siebel Tools, in the Process Designer, right-click in the design canvas and select Simulate Workflow Process. NOTE: If the Simulation toolbar is not visible, choose View > Toolbars > Simulate. 2 Click the Start Simulation button in the simulation toolbar. The Mobile client executable is launched. 3 Wait for the Simulation In Progress dialog box to appear, as shown in Figure 30. Figure 30. Wait for the Simulation in Progress dialog box to appear before returning to Siebel Tools 4 To return to the Siebel Tools session, type Alt-Tab on your keyboard. NOTE: At this point, you may want to 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 your display area. Siebel Business Process Framework: Workflow Guide Version 8.0 30 7
    308. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes 5 Step through the workflow using the Watch Window to monitor status (click the Simulate Next button to move between the steps). NOTE: If the Watch Window is blank, right-click in the Simulation applet and select Watch Window. This refreshes the display. 6 Once the Opportunity Activity Plan view is displayed in the Mobile client, note that you cannot reach the End step by clicking the Next button. Since you specified a condition on the branch, you must satisfy the condition before reaching the End step. a Using the Mobile client session, make and save a change to the Activity Plan business component. For example, change the Planned Start Date or the Description. b Type Alt-Tab to return to Siebel Tools and click Next to complete the End step. When the last step is reached, the Mobile client displays a message reporting "Simulation terminated! Please check the watch window for details." c Acknowledge the message and Alt-Tab to return to Siebel Tools. 7 In the Watch Window, view the Simulator Status field. If “Simulation ended successfully” is displayed, the workflow process ran without error. Part 3: Call the Workflow from the UI using a Run-time Event Now that you have built and simulated a workflow process, you must decide where and how it will be invoked from the user interface. For this example, you will add a button to the Opportunity List applet to invoke the workflow. To add a new button to the Opportunity list applet and configure it to invoke a new event 1 Return to your Siebel Tools session. If you have hidden the Object Explorer, type CTRL+E to re-expose it. You may also want to hide the Watch Window. 2 In the Object Explorer, select the Applet object. 3 In the Applets OBLE, select the Opportunity List Applet applet. 308 Siebel Business Process Framework: Workflow Guide Version 8.0
    309. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes 4 Right-click and select Edit Web Layout. 5 Drag a button control to the layout and set its properties as follows: Property Value Caption Create Plans HTML Type MiniButton MethodInvoked EventMethodCreateActivityPlan Name Plan Button NOTE: Methods that use the naming format EventMethodxxx do not require any applet or business component script to enable the event. If you did not use this special naming convention (for example, MethodInvoked = CreateActivityPlan) you must write a WebApplet_PreCanInvokeMethod script to enable the event. 6 In the Controls/Columns window, set the Mode. NOTE: If the Controls/Columns window is not visible, select View > Windows > Controls Window. By default the Mode is “1: Base.” a Set the Mode to “3: Edit List.” Siebel Business Process Framework: Workflow Guide Version 8.0 30 9
    310. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes 7 Preview the applet. The new Create Plan button should appear as shown in Figure 31. Figure 31. New Button (Create Plan) Added to the UI to Invoke a Synthetic Event 8 Save the applet changes. 9 Compile a new SRF in your client directory. Now you are ready to modify the workflow process so that it launches whenever the method EventMethodCreateActivityPlan is invoked. To configure the workflow process to run when the event is detected 1 In the Object Explorer, select the Workflow Process object. 2 In the Workflow Processes OBLE, query for the Create Plan process created in “Part 1: Create a New Workflow Process” on page 302. 3 Right-click the process and select Edit Workflow Process. 4 Supply a start condition for the workflow, so that the workflow will be called whenever the method EventMethodCreateActivityPlan occurs on the Opportunity List Applet. a Select the connector between the Start step and the step called "Add Activity Plan to Oppty". 310 Siebel Business Process Framework: Workflow Guide Version 8.0
    311. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes b Use the Properties window to set the properties on the branch as follows: Property Value Type Condition Event Object Type Applet Event Object Opportunity List Applet Event PreInvokeMethod Subevent EventMethodCreateActivityPlan EventCancelFlag TRUE 5 Validate the workflow process. If there are no errors, you are ready to deploy the workflow. Part 4: Deploy and Activate the Workflow Process Before the new workflow process can be called in the run-time client, you must publish and activate it. To publish the workflow process from Siebel Tools 1 Return to your Siebel Tools session. 2 In the Object Explorer, select the Workflow Process object. 3 In the Workflow Processes OBLE, if "Create Plan" is the not the active row, query for it, and select it. 4 Click the Publish button at the top of the screen. The status of the Create Plan workflow automatically changes from “In Progress” to “Completed.” as shown in Figure 32. Figure 32. Workflow Deployed in Siebel Tools 5 Type F5 to launch the run-time administration client. 6 Connect using SADMIN or an equivalent administrative account. Siebel Business Process Framework: Workflow Guide Version 8.0 31 1
    312. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes 7 Navigate to Site Map > Administration - Business Process > Workflow Deployment. The Workflow Deployment view is displayed. 8 In the Repository Workflow Processes applet, query for the Create Plan workflow process. One record is returned. 9 Click the Activate button. 10 In the Active Workflow Processes applet, query for the Create Plan workflow process. One record is returned for every version that was activated for the process. 11 In the Active Workflow Processes applet, set the Monitoring Level to 4-Debug. 12 Verify that a run-time event was created for this workflow process. a Navigate to Site Map > Administration - Runtime Events > Events. b From the applet menu, select Reload Runtime Events. c Query for the method you are using to invoke the workflow (Subevent = EventMethodCreateActivityPlan). One record is returned. Now you are ready to call the workflow process using the button you created on the Opportunity List Applet. Part 5: Test the Workflow Process Using the Run-time Client You begin testing the workflow process in the Opportunities view of the run-time client, using the Create Plan button you created in “Part 3: Call the Workflow from the UI using a Run-time Event” on page 308. You make an activity plan and save a change to it. Then you review the workflow process log. To test the workflow process in the run-time client 1 Open the Opportunity List View to access the Create Plan button. a In the run-time client, navigate to Site Map > Opportunities > All Opportunities. 2 In the All Opportunities list (which is the Opportunities List View that you modified in “To add a new button to the Opportunity list applet and configure it to invoke a new event” on page 308), click the Create Plan button. This invokes the workflow process for an opportunity. The workflow process invoked navigates you to the Opportunity Activity Plan view. 3 Verify that a new plan was created. 4 Edit the plan Description field and save the change. 5 Navigate to Site Map > Administration - Business Process > Workflow Instance Monitor. 312 Siebel Business Process Framework: Workflow Guide Version 8.0
    313. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes 6 Query for the workflow process called “Create Plan.” The related instance data is displayed in the bottom applet. 7 Select the Step Instances tab to review the details. If your workflow process runs without error, you can turn off monitoring. To turn off monitoring for the workflow process 1 Navigate to Administration - Business Process > Workflow Deployment. 2 Query for the workflow process called “Create Plan.” 3 In the Active Workflow Processes applet, set the Monitoring Level field to 0-None. Example: Creating a Workflow Process Triggered by a Run-time Event In this example you create 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 see that the workflow process and run-time event works. The business scenario for this workflow is that a workflow 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. To set up this example workflow process 1 Launch Siebel Tools connected to a sample database. 2 Create a test project. 3 Create a new workflow process with the following properties: Name SR Assigned - Auto Create Activities Business Object Service Request Group <leave this field blank> Auto Persist No Workflow Mode Service Flow Project <your test project> Description <provide a description> 4 In the Workflow Processes OBLE, right-click on the new process record and select Edit Workflow Process. 5 In the Process Designer, drag and drop the following icons from the palette to the canvas: ■ Start step ■ Siebel Operation step Siebel Business Process Framework: Workflow Guide Version 8.0 31 3
    314. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes ■ End step 6 Drag and drop connector icons from the palette to the canvas, and use them connect one step to another. NOTE: Make sure that when the connector is highlighted, the end points of the connectors show in red, which means the connector is fully connected to the steps. 7 Select each step and change its name as follows: Step Name Start Start Siebel Operation Create Research Activity End End To create a condition branch 1 Create a condition on the branch coming from the Start step, with attributes as follows: Branch Name SR Owner Field Updated Type Condition Event Object Type BusComp Event SetFieldValue Event Object Service Request Subevent Owner 2 In the Compose Condition Criteria dialog box, create a condition to check that the SR [Owner] field is set to a value (the SR has to be assigned and cannot be left blank). Create a new record and specify the following: Compare To Business Component Operation Is Not Null Business Component Service Request Business Component Field Owner a Leave the Values applet blank because we are checking that the [Owner] field is not null. So there is no need to check against any particular value. b Click Add, and then click OK to close the Compose Condition Criteria dialog box. To define the Siebel Operation step 1 In the Process Designer, select the Siebel Operation step icon and view its attributes in the Properties window. 2 Specify the following attributes: Name Create Research Activity 314 Siebel Business Process Framework: Workflow Guide Version 8.0
    315. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes Operation Insert Business Component Action To specify the fields to populate when inserting a new record into the Action business component 1 In the MVPW, select the Field Input Arguments tab. 2 For this test case, create Field Name records with arguments as follows: Field Name Type Value Type Literal Research Description Literal Research the following: Siebel Bookshelf, SupportWeb NOTE: When performing inserts into a business component, make sure that any required fields for the business components are specified in this step or have pre-default settings from the Business Component > Field configuration in Siebel Tools. To deploy the workflow process in Siebel Tools 1 Use the open windows in the Tools MDI (multiple-document interface) to navigate back to the Workflow Processes OBLE. 2 Query for the workflow process you created in Step 3 (SR Assigned - Auto Create Activities). 3 Deploy the workflow process. To activate the workflow process 1 Launch the client. 2 Navigate to Site Map > Administration - Business Process > Workflow Deployment. 3 Query for the workflow (SR Assigned - Auto Create Activities). 4 In the Repository Workflow Processes applet, click the Activate button. To set monitoring for the workflow process 1 In the Active Workflow Processes applet, query for the workflow (SR Assigned - Auto Create Activities). One record is returned for every version that was activated. 2 Set the Monitoring Level to 4-Debug. To test the workflow process being invoked by the run-time event 1 Navigate to Site Map > Service Requests > All Service Requests. Siebel Business Process Framework: Workflow Guide Version 8.0 31 5
    316. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes 2 Create a new service request record and step off the record. 3 Re-select the service request record and click on the Activities tab. This displays an activity with the following attributes: ■ Type: Research ■ Description: Will research the following: Siebel Bookshelf, SupportWeb Once this activity is created, you have confirmed that the workflow process was invoked, that it was triggered by the run-time event, and that it executed correctly. Example: Creating a Service Flow Workflow The goal of this example is to introduce you to the processing mode field called Workflow Mode and its effect on workflow process execution. The end user creates a new service request, and then Siebel Workflow detects this and performs the following: ■ 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 set of steps, which the SR owner can follow when researching the SR To create this example Service Flow workflow 1 Launch Siebel Tools, connecting to a sample database. 2 Create a test project. 3 Create a new workflow process with the following properties: Name New SR Created Business Object Service Request Group <leave this blank> Auto Persist No Workflow Mode Service Flow Project <the test project you created in Step 2> Description <provide a description> 4 Right-click in the new workflow process record and select Edit Workflow Process to access the Process Designer. 5 Drag and drop the following icons from the palette to the canvas, in the order listed: ■ Start step ■ Decision Point 316 Siebel Business Process Framework: Workflow Guide Version 8.0
    317. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes ■ Siebel Operation steps (5 total) ■ End step Arrange the step icons on the canvas as shown in Figure 33. Figure 33. Service Mode Workflow 6 Drag and drop Connector icons onto the palette and use them to connect the steps to one another as shown in Figure 33. NOTE: To give a connectors an elbows (a corner), right-click the connector and select Add Point. Then click the newly added point and drag it to the desired location in the canvas. Make sure that when each connector is selected, its end points are red. The red color indicates that the connector is fully connected to the steps it joins. 7 Double-click each step icon and branch icon to rename each one as is shown in Figure 33. To define the branches for this example workflow process 1 Select the Connector icon called “New SR Created by User” and view its properties in the Properties window. 2 Specify the following branch properties, which cause the workflow process to run when a new SR is created: Name Check SR Priority Type Condition Event Object Name BusComp Siebel Business Process Framework: Workflow Guide Version 8.0 31 7
    318. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes Event WriteRecordNew Event Object Service Request 3 Specify branch properties for each of the connectors coming out of the Decision Point called “Check SR Priority.” (This Decision Point checks the value of the SR’s Priority field.) a For each connector, set the type to Condition in the Properties window. b For each connector, right-click and select Edit Conditions to access the Compose Condition Criteria dialog box. Define conditions as follows: ❏ For four of the five connectors, set Field definitions that correspond to a Priority value. The workflows base the Commit Time on the value in the Priority field. (For the third connector, do not set a priority. The default value is that the priority is not set.) ❏ For the first of the five connectors, set Priority to 1-ASAP. ❏ For the second of the five connectors, set Priority to 2-High. ❏ For the third of the five connectors, do not set Priority. ❏ For the fourth of the five connectors, set Priority to 3-Medium. ❏ For the last of the five connectors, set Priority to 4-Low. 4 Once all conditions and values are set, return to the Process Designer canvas. To define the Siebel Operation steps for this example workflow process 1 In the canvas, select the Siebel Operation step named “Set Commit Time In 1 Hour” that comes from the “Prio 1” branch. In this step, you will update the Service Request by setting the Commit Time according to the priority level, set the owner to the Service Request creator and also set Sub-status = "Assigned". 318 Siebel Business Process Framework: Workflow Guide Version 8.0
    319. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes a Set the fields and values as shown below. To set the Fields, right click on the Operation step and pick "Show Fields". 2 Select the Siebel Operation step named “Set Commit Time In 2 Hours” that comes from the “Prio 2” branch. In this step, you will update the Service Request by setting the Commit Time according to the priority level, set the owner to the Service Request creator and Sub-status = "Assigned". a Set the fields and values as follows. To set the Fields, right click on the Operation step and pick "Show Fields". ❏ Field Name = Sub-Status ❏ Type = Literal ❏ Value = Assigned 3 Select the Siebel Operation step named “Set Commit Time In 24 Hours” that comes from the “Prio 3” branch. In this step, you will update the Service Request by setting the Commit Time according to the priority level, set the owner to the Service Request creator and Sub-status = "Assigned". a Set the fields and values as follows. To set the Fields, right click on the Operation step and pick "Show Fields". ❏ Field Name = Sub-Status ❏ Type = Literal ❏ Value = Assigned Siebel Business Process Framework: Workflow Guide Version 8.0 31 9
    320. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes 4 Select the Siebel Operation step named “Set Commit Time In 48 Hours” that comes from the “Prio 4” branch. In this step, you will update the Service Request by setting the Commit Time according to the priority level, set the owner to the Service Request creator and Sub-status = "Assigned". a Set the fields and values as follows. To set the Fields, right click on the Operation step and pick "Show Fields". ❏ Field Name = Sub-Status ❏ Type = Literal ❏ Value = Assigned 5 Select the Siebel Operation step named “Create Plan of Action Activity.” This step will create an activity for the service request with a set of actions that the owner can follow. 6 Set the fields and values as shown below. In the Comment field, enter the following text (or any text of your preference): Plan of Action: 1. Verify whether any attachments have been provided for the issue logged. 2. Ensure understanding of behavior logged by customer. If anything is unclear, check with customer and get clarification. 3. Check whether there is anything that can be tested for the behavior. 4. Request logs where appropriate and applicable. 5. If any references are found in the Bookshelf, provide them to customer for review 320 Siebel Business Process Framework: Workflow Guide Version 8.0
    321. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes To verify that the workflow process works in real time, invoked by the run-time event 1 Publish the workflow process from within Siebel Tools. 2 Activate the workflow process by clicking the Activate button in the Siebel client. 3 Reload run-time events. Since the workflow process has a run-time event that initiates it, the personalization data and cache must be updated through reloading of run-time events. a Navigate to Administration - Run-time Events. b From the applet menu, select Reload Run-time Events. 4 Test the workflow process being invoked by the run-time event: a Navigate to Site Map > Service Requests > All Service Requests and create a new service request record. b Set a value for the Priority field, or leave it blank. c Save the record. When you step off the record, you will notice the client application freezes or delays slightly (with an hourglass). d Re-select the service request record and check the Owner, Substatus and Date Committed fields. Verify they have been populated correctly. 5 Check the Service Request > Activities view for the new activity. a Select the Activities tab. The new activity record is displayed. b View the Comments field. 6 Test out a few scenarios by creating service request records with different Priority values and see how the workflow process Decision Point behaves. Example: Run-time Event Workflow with User Interact Step to Navigate the End User to a View The goal of this example is to create a simple workflow process that is initiated by a run-time event and that takes the end user to a view. This is an Interactive Flow. A new service request is created by an end user. Siebel Workflow detects this and performs the following: ■ 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 set of steps which the owner can follow when researching for the SR. Siebel Business Process Framework: Workflow Guide Version 8.0 32 1
    322. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes ■ Navigates the end user to the Service Request > Activities view to display the newly created activity. For this example, you will re-use the workflow process from “Example: Creating a Service Flow Workflow” on page 316 and modify it slightly. To set up this example workflow process 1 Launch Siebel Tools, connecting to a sample or server database. 2 In the Object Explorer, select the Workflow Process object. 3 In the Workflow Processes OBLE, select the workflow process called “New SR Created.” 4 Revise this workflow process to create a new version of status In Progress. 5 Rename the newly created workflow process “New SR Created - Take User to SR Activity View.” 6 Change the Workflow Mode to Interactive Flow. 7 Deactivate all previous workflow processes based on Business Object = Service Request, so that they do not run or interfere with invocation of the workflow process for this example. 8 Right-click the workflow process called “New SR Created - Take User to SR Activity View” and select Edit Workflow Process to access the Process Designer. 9 In the Process Designer, do the following: a Drag and drop the User Interact step icon from the palette to the canvas, between the steps “Create Plan of Action Activity” and “End Workflow.” b Add connectors from “Create Plan of Action Activity” to the User Interact step, and then from the User Interact step to the “End Workflow” step, as shown in Figure 34. Figure 34. Example Workflow Process: “New SR Created - Take User to SR Activity View” 322 Siebel Business Process Framework: Workflow Guide Version 8.0
    323. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes 10 Select the User Interact step and view its properties in the Properties window. Make the following modifications to the step’s properties: a Change the name of the step to “Display SR Activities View.” b In the View field, select Service Request Detail View from the picklist. NOTE: If you are not sure which is the correct view corresponding to the UI, you can check it by navigating to Service Requests > All Service Requests > Activities tab. Then, from the application menu, select Help > About View. This will show the view's configuration and the repository view name. 11 Create an event coming from the User Interact step. a Set the following branch attributes: ❏ Name = To End ❏ Type = Condition ❏ Event Object Type = BusComp ❏ Event Object = Service Request ❏ Event = WriteRecordUpdated 12 From within Siebel Tools, publish the workflow. To test the workflow process in the run-time client 1 In the Siebel client, navigate to Site Map > Administration - Business Process > Workflow Deployment. 2 Query for the “New SR - Take User to Activity” workflow process. 3 Click the activate button. 4 In the Active Workflow Processes applet, query for the same process. One row is returned for every version that was activated. 5 Make sure only the latest version is active. 6 Set the Monitoring Level to 4-Debug. 7 Reload personalization: a In the upper applet menu choose "Reload Runtime Events". 8 Test the “New SR Created - Take User to Activity” workflow process as follows: a Navigate to the Service Request list view. b Create a new service request, specify a Priority level, and step off the record. The application delays, with an hourglass. Then the Owner, Sub-Status, and Date Committed fields are populated, and a new activity is created. Also, the application automatically navigates the user to the Service Request > Activities view to display the new activity record. Siebel Business Process Framework: Workflow Guide Version 8.0 32 3
    324. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes c Verify in the Workflow Process Log view that a process instance exists for “New SR Created - Take User to Activity.” Example: Externalize Parameters to be Used by Siebel Workflow The goal of this example is to provide a framework to externalize Workflow parameters such that workflow processes using business services that interact with external systems do not require repository changes when migrating between Siebel instances in development, test, and production. Concepts shown in this example can be extended for other business services provided by Siebel and can help avoid changes to workflows when migrating the repository between development, test, and production Siebel instances. Overview Workflow processes using business services that require interaction with external systems—for example, “EAI HTTP Transport” which requires the URL of the external system for the input argument “HTTPRequestURLTemplate”—need to be changed when the repository is migrated between development, test, and production. The URL for the workflow using the “EAI HTTP Transport” business service would point to an integrated test system's external URL in the testing instance and point to a production external system URL in the production instance. The basic idea for the design of the framework is to store in a file all the input arguments of a business service that are in use in a given workflow process. In the Service_PreInvokeMethod event of the Business Service step, add script to read values of these substitutable input arguments of a business service in use in a workflow process from a file, and set the Input Argument of the business service with values read from a file. This way, the file residing on the production Siebel instance server will contain values for production external systems, and the file residing on the dev/test Siebel instance server will contain values for dev/test external systems. In other words, input argument values are not hard coded for such a service in the workflow design, but read at run time from a file in the Service_PreInvokeMethod Event method script. This framework relies on a file, with a particular name, on each Siebel server being available for reading. Otherwise the business service will fail and <ProductName> will throw an error at that Business Service step (this is the desired behavior). For any business service where the script is added to the Service_PreInvokeMethod event, it is expected that an input argument called “ExternalSystem” is defined, and the argument’s value matches the XML tag name of the child of the root element in the file. This script code will set all the child elements of the second-level parent (child of the root element) of the file as input arguments. The following are the key requirements of this framework for externalizing Workflow parameters for certain business services: ■ The framework should make transparent the migration of repository workflows between development, test, and production Siebel instances. That is, workflows should no longer require any changes during migration between various Siebel instances. 324 Siebel Business Process Framework: Workflow Guide Version 8.0
    325. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes ■ The framework should support current business services as well as future requirements. ■ The framework should support all usage scenarios of a given business service used in various workflows. ■ The framework should be easy to manage and have a net effect of reducing the total cost of ownership of operational aspects of running the Siebel instance. Design The following two services, when used in the workflow as a step, have input arguments that may require changes when migrating the repository between development, test, and production Siebel instances. ■ EAI HTTP Transport ■ SendandReceive Method Input Argument(s) ❏ HTTPRequestURLTemplate ■ EAI SQL Adapter ■ Query Method Input Argument ❏ ExtDBODBCDataSource ❏ ExtDBPassword ❏ ExtDBTableOwner ❏ ExtDBUserName Assume that a given Siebel instance has integration points with third-party HR, Finance, and UAN systems. In order to use the two services above, the input arguments mentioned above for the respective business services must be supplied in the workflow step definition where these services are used. The following is an arbitrary XML Hierarchy file called “ebizint.xml,” containing input arguments for the above two services and their values. The parameters under “Finance,” “HR,” and “UAN” are for illustration purposes only. Siebel Business Process Framework: Workflow Guide Version 8.0 32 5
    326. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes You can have any number of needed parameters with appropriate values. For a given usage scenario of a business service, any parameters that are not needed will do no harm. Also, this XML Hierarchy is completely arbitrary. The one shown Figure 35 is for illustration purposes only. Figure 35. Example XML Hierarchy 326 Siebel Business Process Framework: Workflow Guide Version 8.0
    327. Reference Materials for Siebel Workflow ■ Examples of Creating Workflow Processes Given the above structure of the file, the eScript code example shown in Figure 36 on page 327 can be added to the Service_PreInvokeMethod event of the two services mentioned. Figure 36. Example eScript Code Siebel Business Process Framework: Workflow Guide Version 8.0 32 7
    328. Reference Materials for Siebel Workflow ■ Predefined Business Services Note the location of the “ebizint.xml” file. In a Windows environment, this file should be present on C: on all Siebel servers where the above services could be invoked. The file must be made read- only for the user ID under which the Siebel Service runs. Write access should be denied to all users. There is no other ongoing maintenance required for this file. Whenever the values in the file change— for example, the external system URL—this file needs to be updated with the correct values on all Siebel Servers. Figure 37 shows an example usage of the EAI HTTP Transport business service, which has the above eScript code in the Service_PreInvokeMethod event. Figure 37. Example Usage of EAI HTTP Transport Business Service Predefined Business Services This section describes the predefined business services that are commonly used in workflow processes. ■ FINS Data Transfer Utilities. See “FINS Data Transfer Utilities Business Service” on page 329. ■ FINS Validator. See “FINS Validator Business Service” on page 329. ■ FINS Dynamic UI Service. See “FINS Dynamic UI Business Service” on page 329. ■ Outbound Communications Manager. See “Outbound Communications Manager Business Service” on page 329. ■ Report Business Service. See “Report Business Service” on page 329. ■ Synchronous Assignment Manager Requests. See “Synchronous Assignment Manager Requests Business Service” on page 329. ■ Server Requests. See “Server Requests Business Service” on page 330. ■ Workflow Utilities. See “Workflow Utilities Business Service” on page 333. ■ Workflow Administration Service. See “Workflow Administration Service” on page 333. For more predefined business services, see Business Processes and Rules: Siebel Enterprise Application Integration. 328 Siebel Business Process Framework: Workflow Guide Version 8.0
    329. Reference Materials for Siebel Workflow ■ Predefined Business Services FINS Data Transfer Utilities Business Service The FINS Data Transfer Utilities business service allows you to transfer data from a source BC to a destination BC without using script. FINS Validator Business Service The FINS Validator business service allows you to validate data based on predefined rules. It is developed through Application Administration, not through script. The FINS Validator business service supports custom messages. This service has one method available: Validate. FINS Dynamic UI Business Service The FINS Dynamic UI business service allows the creating and rendering of read-only views with a single read-only applet based on user input. This business service is administered through administration views, not through script. Outbound Communications Manager Business Service The Outbound Communications Manager business service is for sending notifications (through fax and email), such as notifications to contacts or employees. For information on methods and arguments, see Siebel Communications Server Administration Guide. Report Business Service The Report business service automates sending, scheduling, printing, saving, and emailing reports. It also automates administrative jobs such as synching new users. Synchronous Assignment Manager Requests Business Service The Synchronous Assignment Manager Requests business service is for assigning an object using Assignment Manager rules. For more information on Assignment Manager rules, see Siebel Assignment Manager Administration Guide. This service has one method available, Assign. This method sends a request to the assignment manager server component. Siebel Business Process Framework: Workflow Guide Version 8.0 32 9
    330. Reference Materials for Siebel Workflow ■ Predefined Business Services Assign Arguments Table 80 describes the Assign method arguments. Table 80. Assign Method Arguments Argument Description Assignment Object Name Required. This is the object that you want to assign. Object Row ID Required. This is the row ID for the object you want to assign. To assign the work item for the workflow process, set this to the Object Id process property. Reply TIP: The Synchronous Assignment Manager Requests business service attempts to assign all records that meet the appropriate criteria, even if they are locked. To prevent errors in your process due to locked records, set up a condition in your workflow process or workflow policy to skip records that do not meet the condition ASGN_USR_EXCLD_FLG = N. Server Requests Business Service The Server Requests business service is for sending generic requests to the server request broker. The Server Requests business service can send requests in three different modes: asynchronous, synchronous or schedule mode. While in synchronous mode, it will send the request to the server request broker and wait for a response. Otherwise, it will just send the request but does not wait for a response. When invoking the Server Requests business service to submit a component request, you need to specify SRBroker parameters in the input property set and all component specific parameters in a child property set. The following are points to note: ■ Component parameters must be specified with their Alias Names in the child property set. ■ There is no validation of these Alias Names. ■ These arguments do not appear in the picklist in the Administration - Business Process views. NOTE: If you want to pass parameters to the server component that are not listed as available arguments, you can create a custom business service that contains the necessary parameters. Alternatively, you can create a component job that has the parameters defined as part of the job definition. For more information on component jobs, see Siebel System Administration Guide. This service has two methods available: ■ Submit Request. Use this method to submit a request to the server request broker. ■ Cancel Request. Use this method to cancel any server request that is currently awaiting to be run. 330 Siebel Business Process Framework: Workflow Guide Version 8.0
    331. Reference Materials for Siebel Workflow ■ Predefined Business Services Submit Request Arguments Table 81 describes the Submit Request method arguments. Table 81. Submit Request Method Arguments Argument Description 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 (request is not saved to the database) and “Eon” for asynchronous (request is never deleted). Other possible values are: ■ ASAP ■ SECONDS ■ MINUTES ■ HOURS ■ DAYS ■ WEEKS ■ MONTHS ■ YEARS Description Optional. A description of the server request. Enterprise Server Hold Flag Optional. For asynchronous requests only. Flag to indicate whether or not to hold the request. Maximum Execution Time For future use. Method Optional. Only applicable for service-based server components (for example, Workflow Process Manager, Communications Manager). Specify the business service method to invoke. Siebel Business Process Framework: Workflow Guide Version 8.0 33 1
    332. Reference Materials for Siebel Workflow ■ Predefined Business Services Table 81. Submit Request Method Arguments Argument Description Mode of Server Request Required. This tells the server request broker how to handle the server request. While in auto mode, the server request broker will set the mode to either synchronous or schedule, depending if the client is connected or mobile. ■ Sync: Synchronous ■ Async: Asynchronous ■ Schedule: Schedule ■ Auto: Automatic configuration Number of Retries Request ID Needed Optional. This is only applicable to asynchronous and schedule mode. If this is set to false, these two server requests will return even faster. Request Key For future use.* Repeat Amount Repeat Interval Optional. The interval for repeating requests. Repeat From Optional. Possible values are Scheduled Start, Actual Start, and End. Repeat Interval Units Optional. Unit of intervals for repeating requests. Repeat Number Optional. The number of repetitions for repeating requests. Retry On Error Repeat Unit Request ID Server Name Optional. Enter the specific server that this request is to be run from. Start Date Optional. Start date and time. Storage Amount Optional. Enter the amount of time that the server request will be 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. 332 Siebel Business Process Framework: Workflow Guide Version 8.0
    333. Reference Materials for Siebel Workflow ■ Predefined Business Services Cancel Request Method Arguments Table 82 describes the Cancel Request method arguments. Table 82. Cancel Request Method Arguments Argument Description Request ID Required. This is the ID of the server request to be cancelled. Repeat Number Optional. This is the number of repetitions of the repeating server requests that are to be cancelled. Workflow Utilities Business Service The Workflow Utilities business service contains generic utilities that can be used in process definitions. This business service has one available method, Return Property Values. This method returns a mirror image of the input arguments. The Return Property Values method is also referred to as the Echo method. Return Property Values Arguments Table 83 describes the Return Property Values method arguments. Table 83. Return Property Values Method Arguments Argument Description Input Arguments This method accepts any input arguments. Output Arguments An exact copy of the input arguments. Workflow Administration Service The Workflow Administration business service allows Workflow to perform administrative functions, such as Deploy/Activate/Export/Import, on multiple workflow processes specified by a searchspec. Export Method Exports workflow processes specified by a search specification into a specified directory. Each workflow process is exported to a separate .XML file with a file name being the concatenation of process name and version number. Input Arguments ExportDir. The directory to which the export files will be written to, e.g., d:workflows. Siebel Business Process Framework: Workflow Guide Version 8.0 33 3
    334. Reference Materials for Siebel Workflow ■ Predefined Business Services FlowSearchSpec. The search specification used to select the workflow processes to be exported, for example: [Process Name] like 'User Reg*' Repository. The repository from which workflow processes will be exported. The default value is “Siebel Repository.” Output Argument NumFlowExported. The number of workflow processes that have been exported by the service. Import Method Imports workflow export files specified by a search specification in a specified directory. Input Arguments ImportDir. The directory where the workflow export files are located. FileSearchSpec. The search specification used to select the workflow export files to be imported, for example: User*.xml Repository. The repository into which workflow processes will be imported. Project. The Tools project into which workflow processes will be imported. The project needs to be locked for the workflow import to succeed. Output Argument NumFlowImported. The number of workflow processes that have been imported by the service. Deploy Method Deploys workflow processes specified by a search specification. Input Argument FlowSearchSpec. The search specification used to select the workflow processes to be deployed. NOTE: A default search specification, [Status] = "In Progress", is automatically added to FlowSearchSpec and does not need to be explicitly specified. Output Argument NumFlowDeployed. The number of workflow processes that have been deployed by the service. Activate Method Activates workflow processes specified by a search specification. 334 Siebel Business Process Framework: Workflow Guide Version 8.0
    335. Reference Materials for Siebel Workflow ■ Predefined Business Services Input Argument FlowSearchSpec. The search specification used to select the workflow processes to be activated. NOTE: A default search specification, [Status] = "COMPLETED", is automatically added to FlowSearchSpec and does not need to be explicitly specified. Output Argument NumFlowActivated. The number of workflow processes that have been activated by the service. DeleteDeploy Method Deletes workflow deployment records specified by a search specification. Input Argument FlowSearchSpec. The search specification used to select the workflow deployment records to be deleted. Output Argument NumFlowDeleted. The number of workflow deployment records that have been deleted by the service. Siebel Business Process Framework: Workflow Guide Version 8.0 33 5
    336. Reference Materials for Siebel Workflow ■ Passing Parameters to and from Workflow and Data Manipulation within Workflows Passing Parameters to and from Workflow and Data Manipulation within Workflows This section explains how to manipulate data within workflow processes and how to pass parameters to and from Workflow. Manipulating Data Within Workflows You can manipulate data within workflow processes. This section explains how to access run-time event parameters from workflow processes. To access run-time event parameters from workflow processes 1 Set up a run-time event for each applet that is required to trigger a workflow process. Fill in the fields of the WF Step Branch properties. Example field values are shown in the following table. Field Value Branch Name Enter a name for the branch. Type Condition Next Step Enter a name for the next step. Event Object Type Applet Event InvokeMethod Event Object Choose the name of the event object that will trigger the workflow. Sub Event NewRecord Comments Optional Event Cancel Flag The default is blank. 2 Set up your process properties in Process Designer as usual. For information on using process properties, see “About Process Properties” on page 93. 336 Siebel Business Process Framework: Workflow Guide Version 8.0
    337. Reference Materials for Siebel Workflow ■ Passing Parameters to and from Workflow and Data Manipulation within Workflows 3 Drill down into the first step in your workflow process and add a new output argument for each process property you want to populate using run-time events. Add new output arguments by filling in the fields of the Output Arguments applet. Example field values are shown in the following table. Field Value Property Name Enter a name for the property. Type Expression Value GetProfileAttr(“RestrucOut”) Note: As you are filling in the Profile Attribute field, make note of the name you give to each of the Profile Attributes property values, for use in Step 8 on page 338. Output Argument Leave as default. Business Component Name Leave as default. Business Component Field Leave as default. Comments Optional 4 Activate the workflow process. For more information, see “Deploying Workflow Processes” on page 182. 5 Since the workflow process includes run-time events, you must load the run-time events. a From the application-level menu, choose Navigate > Site Map > Administration - Runtime Events > Events. b From the applet menu, select Reload Runtime Events. 6 From the Events view tab, find the run-time event that is associated with the workflow run-time event that you created. As an example, you can query for the InvokeMethod event on the Opportunity List Applet object. Siebel Business Process Framework: Workflow Guide Version 8.0 33 7
    338. Reference Materials for Siebel Workflow ■ Passing Parameters to and from Workflow and Data Manipulation within Workflows 7 Drill down on the Action Set Name. The Actions view is shown in the following figure. 8 Add a new Action for each process property that will be populated using run-time events. For example, you can create a new action to set the ACU Transaction ID and call it Set ACU Trans ID. a For each new action: ❏ Set the Action type to Attribute Set. ❏ Set the Profile Attribute to match the value you used in the GetProfileAttr call in the Process Designer in Step 3 on page 337, such as TransType. ❏ Set the Set Operator value to Set. ❏ Assign the Value field the appropriate value, such as the literal string FA-0001. You assign the value using the standard Siebel expression builder. ❏ Set the Sequence for the action to be less than the default sequence (for the Workflow_XXXXXXX Action). b Make sure the Sequence setting of the Workflow_XXXXXXX Action is the highest number so that this action happens after all the other actions. NOTE: Whenever you modify the workflow process, you must repeat this step because modifying a workflow process resets the workflow action’s sequence to 1. c From the applet menu, select Reload Runtime Events. 338 Siebel Business Process Framework: Workflow Guide Version 8.0
    339. Reference Materials for Siebel Workflow ■ Passing Parameters to and from Workflow and Data Manipulation within Workflows Passing Parameters to and from Workflow with the Workflow Process Manager Business Service The Workflow engine can be invoked programmatically, that is, by calling a business service. The Workflow Process Manager business service is a standard Siebel business service used for this purpose. When you run a workflow process by invoking the Workflow Process Manager business service, you can pass inputs to Workflow, and in some cases, obtain outputs from Workflow. Passing Inputs to Workflow The input property set is required to contain a 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 will be passed to the workflow process by the Workflow Process Manager business service. Simple data type process properties (such as String, Number, and DateTime) that are marked In or In/Out will be initialized if the input property set has a property (in the top-level property set) with a name matching the name of the workflow process property. The value of such a property in the input property set will initialize the value of the matching workflow process property. Hierarchical data type process properties that are marked In or In/Out will be initialized if the input property set has a child whose property set Type field contains a string matching the name of the hierarchical workflow process property. If such a match is found, the matching child (and everything below the child) in the input property set is copied into the process property. Passing Outputs from Workflow Not all workflow processes that are started programmatically return outputs. For example, an interactive workflow process may be programmatically started, but since it can pause, the output from the call to start the workflow process may reflect the state at an intermediate point. For this reason, only workflow processes that are guaranteed to run to completion in one call, that is, service flows, should be expected to provide output in the output arguments of the call into the Workflow Process Manager business service. Output arguments follow the same convention as input arguments. Simple workflow process properties (such as String, Number, and DateTime) that are marked Out or In/Out will appear as properties on the top-level property set. Hierarchical process properties will appear as children of the output property set. Hierarchical process properties can be located by examining the Type field of the child, which will match the workflow process property name. Example Scripts You can use scripts for invoking Workflow programmatically and for passing parameters. Example scripts are provided in the following sections: ■ “Example Script: Invoking Workflow Programmatically and Constructing an Input Property Set” on page 340 ■ “Example Script: Defining Property Sets for the Input Property Set” on page 340 ■ “Example Script: Constructing Property Sets” on page 340 Siebel Business Process Framework: Workflow Guide Version 8.0 33 9
    340. Reference Materials for Siebel Workflow ■ Passing Parameters to and from Workflow and Data Manipulation within Workflows ■ “Example Script: Assembling Properties and Child Property Sets into the Input Property Set” on page 341 ■ “Example Script: Invoking the Workflow Process Manager Business Service and Passing It the Input Property Set” on page 341 Example Script: Invoking Workflow Programmatically and Constructing an Input Property Set The following is a sample script which programmatically invokes the Workflow Process Manager business service and which constructs an input property set, psInputs, for the business service. This script defines strings that will be 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:sea752XMLMessagesAgentAuthorizationVBCReq-final.xml" var resFileName = "C:sea752XMLMessagesAgentAuthorizationVBCResponse-final.xml" Example Script: Defining Property Sets for the Input Property Set The following is a sample script that defines property sets, which will be 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 Script: Constructing Property Sets The following is a sample script that constructs property sets. //Build property set hierarchy sAgentID = app.LoginName(); 340 Siebel Business Process Framework: Workflow Guide Version 8.0
    341. Reference Materials for Siebel Workflow ■ Passing Parameters to and from Workflow and Data Manipulation within Workflows psRequest.SetType("XMLHierarchy"); psAgentNumTag.SetType("DataAgentNumber"); psAgentNumTag.SetValue(sAgentID); psRequest.AddChild(psAgentNumTag); Example Script: Assembling Properties and Child Property Sets into the Input Property Set The following is a sample 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); psInputs.SetProperty("CICSServiceName", CICSServiceName); psInputs.SetProperty("ProcessName", processName); psInputs.SetProperty("Request File Name", reqFileName); psInputs.SetProperty("Response File Name", resFileName); Example Script: Invoking the Workflow Process Manager Business Service and Passing It the Input Property Set The following is a sample script that invokes the Workflow Process Manager business service and passes it the input property set. var svc = TheApplication(). GetService(“Workflow Process Manager”); svc.InvokeMethod("RunProcess", psInputs, psOutputs);//Call the Workflow var sErr = psOutputs.GetProperty("sErr");//Check the Workflow status Siebel Business Process Framework: Workflow Guide Version 8.0 34 1
    342. Reference Materials for Siebel Workflow ■ Using Expressions with Workflow Processes Passing Parameters from Workflow to Global Variables (Profile Attributes) You can use a business service to access and pass parameters from Workflow to global variables. To access workflow parameters for a running workflow process 1 Define a business service with 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 “About Business Service Steps” on page 114. 4 Use the following script to take the business service argument values and assign them to Profile Attributes. function Service_PreInvokeMethod (MethodName, Inputs, Outputs) { 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 further processing. All the necessary information has been put into the profile attributes of the application. Users can use the standard procedures for accessing the profile attributes to extract this information. For more information, see Siebel Personalization Administration Guide. Using Expressions with Workflow Processes Expressions can be used in workflow processes. The timestamp argument is of particular note, as its arithmetic varies from the time information used in workflow policy programs. 342 Siebel Business Process Framework: Workflow Guide Version 8.0
    343. Reference Materials for Siebel Workflow ■ Using Expressions with Workflow Processes For more information, see “Using the Timestamp Argument” on page 343. Using the Timestamp Argument You can use the timestamp argument to get the current system time and to do time arithmetic based on the current time. The arithmetic involving time information for workflow processes is different from that for workflow policy programs. The second operand to 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 should appear as follows: Timestamp()+0.021 The operation is explained as follows: ■ 0.021 = 30/(24*60) ■ (24*60) represents a whole day in minutes ■ 30 represents the required minutes Siebel Business Process Framework: Workflow Guide Version 8.0 34 3
    344. Reference Materials for Siebel Workflow ■ Using Expressions with Workflow Processes 344 Siebel Business Process Framework: Workflow Guide Version 8.0
    345. Index A definition 298 action parameters, defined 22 next step branches, defining 108 ActionAgent parameter 278 User Interact next step branches, defining 133 ActionInterval parameter 278 business analyst, role of 25 actions business objects creating for workflow policies 218 defining primary business components for 57 working with for workflow policies 210 definition 298 Actions applet business policies field descriptions, Actions view 211 creating policy actions 218 field descriptions, Policies view 233 creating policy groups 224 applet fields creating workflow policies 226 Supprocess applet 121 gathering information on 55 WF Process Props applet 71 business processes WF Step Branches applet 102 automating 169 WF Step Recipients applet 120 business processes, definition 298 WF Steps applet 99 business rule, definition 299 architecture of workflow components 27 business service arguments definition 298 action parameters for policies 22 using in workflow processes 114 common values for policy programs 254 Business Service steps Create Email Activity program 288 about 114 creating argument values 256 defining 118 creating SQL statements for program 258 input arguments, defining 119 Database Operation program 216 output arguments, defining 119 definition 298 Business Service, Workflow Policy Action, Policy Program List Argument view 252 executing from, note 218 programs, example of creating 258 business services, predefined Run External program 215 asynchronous server requests 330 Send EMail program 213 Outbound Communications Manager 329 Send Message Broadcast program 214 synchronous server requests 330 Send Page program 212 Workflow Utilities, arguments 333 Assign Non-Respondents policy, creating 292 C Assign to Campaign Email action 290 calculated fields, updating 125 Assign to Campaign program 289 campaigns Assignment Request, Workflow Policy Create Email Activity program 288 program 24 marketing campaigns, scenario with Workflow asynchronous server requests 330 policies 289 comparison operations B condition criteria 106 Batch feature 220 comparison values Batch field for workflow policies 227 entering date calculations 233 batch mode specialized 230 running workflow processes 172 standard 229 BatchMode parameter 278 using in the Conditions applet 229 branches Compose Condition Criteria dialog box Decision step, defining 113 field descriptions 105 Siebel Business Process Framework: Workflow Guide Version 8.0 34 5
    346. Index ■ D conditions E defining in Start steps 133 email User Interact next step branches 133 consolidating for recipient 220 Conditions applet consolidating for recipient, about using batch field descriptions, Policies view 229 mode 227 using comparison values 229 creating Workflow policy for 234 using specialized comparisons 230 testing 235 using standard comparisons 229 Email for CD-ROM Campaign policy, creating Configurator workflow role, described 25 291 connector Email Manager defining for Decision branches 113 setting up on Siebel Server 269 defining for Start branches 108 troubleshooting 272 defining for User Interact next step branches End steps 133 about 139 definition 298 defining 139 diagramming a workflow process 91 definition 298 point in connector, removing or adding 91 output arguments, defining 140 copying End User, workflow role, described 25 workflow processes 92 Error Code workflow steps 92 default process property 93 Create Email Activity error handling about and arguments 288 about 161 creating 290 assigning error processes to subprocesses 162 D defining exceptions 163 database passing properties and property sets to error Siebel database, described 27 processes 162 specialized comparisons 232 using error processes 161 triggers, creating 263 using exceptions 163 Workflow Policies database tables 274 Error Message Database Operation, Workflow Policy default process property 93 program about 23 errors date calculations, comparison values 233 assigning error processes to subprocesses Decision steps 162 about conditions for 114 defining exceptions 163 about working with 112 handling 161 branches, defining 113 passing properties and property sets to error definition 298 processes 162 default SQL statements 262 using error processes 161 DeleteSize parameter 279 using exceptions to handle errors 163 deleting errors, correcting process and resuming 165 processes 92 events workflow process instances 192 generating user events 158 workflow process steps 92 handling 155 deploying workflow processes user events, configuring long-running tutorial 87 workflows to wait for user events 159 deployment of workflow processes 181 using run-time events 155 on regional nodes 184 using user events 156 to mobile clients 184 Workflow User Event business service 157 to mobile clients, restricting routing 184 events handling 155 designing workflow processes suspended interactive workflows 153 tutorial 80 user logout event 153 events, tracing and logging 196 346 Siebel Business Process Framework: Workflow Guide Version 8.0
    347. Index ■ F exceptions 152 defining 163 input arguments definition 298 defining for Business Service steps 119 explicit resumption of interactive workflows defining for Subprocess steps 122 152 field descriptions for Business Service steps, explicit suspension of interactive workflows Subprocess steps, and Wait steps 115 152 Stop steps, defining 138 External Program, Workflow Policy program Wait steps, defining 131 about 24 installation verifying Workflow Policies 59 F interactive workflow processes FDR building 146 See Siebel Flight Data Recorder files forward and backward navigation 153 field descriptions Object Id 94 Compose Condition Criteria dialog box 105 suspending and resuming, about 151 for defining workflow process steps 99 suspension, events handling 153 input arguments for Business Service steps, suspension, in-memory cache 153 Subprocess steps, and Wait steps 115 suspension, user logout event 153 output arguments for Business Service steps, synthetic events, creating 147 Subprocess steps, and Siebel synthetic events, creating Next and Back Operation steps 116 synthetic events 148 Policies applet, Workflow Policies Groups view synthetic events, creating ResumeLastIntFlow 225 synthetic events 150 Policies applet, Workflow Policies view 228 synthetic events, creating SaveWorkflow Search Specifications for Siebel Operation synthetic events 148 steps 128 invocation of workflow processes 165 Subprocess applet 121 about 165 WF Process Props applet 71 as a configured business service 170 WF Step Branches applet 102 from a run-time event 169 WF Step Recipients applet 120 from a script 167 WF Steps applet 99 from a script in the object manager, example field name modifications 247 168 from a Workflow policy 166 G Generate Trigger (GenTrig) K component-specific parameters for 266 KeepLogDays parameter 279 functions of 263 tips for running 266 L Generic Request Server, Workflow Policy LastUsrCacheSz parameter 280 program 24 license key validation 59 GenReqRetry parameter 279 logging events, table of 196 global implementations of Workflow 159 long-running workflow processes GroupName parameter 279 assigning subprocesses to end users 145 groups building 145 creating for workflow policies 224 Object Id 94 planning policy groups 203 working with for workflow policies 224 M MailTo parameter 280 I marketing campaigns, scenario with IgnoreError parameter 279 Workflow policies 289 implicit resumption of interactive workflows Message Broadcast 152 Arguments applet, about and arguments and implicit suspension of interactive workflows values 214 Siebel Business Process Framework: Workflow Guide Version 8.0 34 7
    348. Index ■ N workflow policy program type 212 Operation steps 116 migrating policies, suggested strategies for 209 P production environment, workflow policies to Page Manager 294 parameters for 271 workflow processes 185 setting up 270 migration strategy, defining for workflow troubleshooting 272 processes 58 palette items in Process Designer 73 multilingual environment parallel processing, Workflow processes, configuring workflow processes 159 supported by 108, 133 defining expressions for workflow processes persistence 160 about 154 multiple records, executing actions in a enabling, setting 155 workflow process for 172 using 154 multi-value group planning updating a field based on a 129 workflow policies, about 204 MVG workflow policies, determining what to updating a field based on a 129 monitor 205 workflow policies, planning policies and N conditions 205 name, modifying policy column and policy workflow policy groups 203 field names 247 policies naming conventions creating 226 for process properties 77 creating actions for 218 for workflow processes 77 creating groups for 224 monitoring 205 O planning for 204 Object Explorer view planning policies and conditions 205 workflow policy objects, adding to 236 Policies applet workflow policy objects, defining 246 described, Workflow Policies Groups view 224 Object Id field descriptions, Groups view 225 default process property 93 field descriptions, Policies view 228 in long-running, interactive, and service Workflow Policies Groups view, field workflow processes 94 descriptions 225 Object List Editor (OBLE) in Siebel Tools 89 policy action Object Manager See programs running workflow processes 172 creating 218 object type definition 300 definition in relation to Siebel Tools 62, 236 working with 210 program types, table of 252 policy condition Workflow Policies terms, definition 299 definition 300 workflow policy objects, modifying 248 role in workflow policies 22 workflow policy program, viewing with Policy Frequency Analysis chart, viewing 286 Program List view 252 policy groups Outbound Communications Manager creating 224 available methods, described 329 planning, about and reasons for using 203 output arguments predefined programs defining for Business Service steps 119 assigning manager as owner 261 defining for Siebel Operation steps 127 close date, changing 259 defining for Subprocess steps 123 Message Broadcast program, screen example End step, defining 140 and arguments 214 field descriptions for Business Service steps, owner, changing 260 Subprocess steps, and Siebel Run External Program 215, 222 348 Siebel Business Process Framework: Workflow Guide Version 8.0
    349. Index ■ R Send Email, using and arguments 213 Subprocess step, defining input arguments Send Quote Page 262 122 table of 295 Subprocess step, defining output arguments workflow action, using a predefined program 123 to create 23 Subprocess step, defining recipients 123 workflow policy programs 259 testing with Process Simulator, about 176 Process Designer User Interact step, about 131 design functions 64 User Interact step, defining 132 diagramming a process 90 Wait step, about 130 palette items 73 Wait step, defining 130 using 64 production environment, migrating to 294 Process Instance Id program default process property 93 definition 300 Process Properties property fields descriptions, workflow policies workflow processes, about passing to 95 252 process properties 93 workflow policy types 211 concatenating 97 Program Argument common properties, defining 96 table of 253 definition 298 Program Argument List view, about 252 naming conventions 77 Program List view, using to list workflow passing field values to example 168 policy programs 252 versus property sets 95 programs Process Simulator 177 predefined, table of 295 definition 298 workflow policy action types 23 running 178 properties testing workflow processes 176 described 62, 236 testing workflow processes, caution 178 Program Argument common, table of 253 workflow processes, using to invoke 176 Run External Program Argument 256 process steps Send Message Argument 255 Business Service step, about 114 workflow policy programs 252 Business Service step, defining 118 property sets Business Service step, defining input versus process properties 95 arguments 119 property sets, passing to workflow Business Service step, defining output processes 95 arguments 119 copying 92 R Decision step, about working with 112 recipient types, table of 217 deleting 92 recipients End step, about 139 defining for Subprocess steps 123 End step, defining 139 Recipients applet, field descriptions 217 Siebel Operation step, about 124 recovery Siebel Operation step, defining 125 workflow processes, about 164 Siebel Operation step, defining fields 126 workflow processes, automatic 164 Siebel Operation step, defining output workflow processes, manual 165 arguments 127 ReloadPolicy parameter 280 Siebel Operation step, defining search repository setting, verifying 59 specifications 126 Requests parameter 281 Start step, about 107 Run External Start step, defining 107 Program Argument properties, table of 256 Start step, defining Next Step branches 108 workflow policy program, creating action 222 Stop step, about 137 workflow policy program. about and example Stop step, defining 138 and arguments 215 Subprocess step, about 120 Run Workflow Process, about using to define Subprocess step, defining 122 Siebel Business Process Framework: Workflow Guide Version 8.0 34 9
    350. Index ■ S a policy 166 making object types available 263 run-time events 155 Siebel database, described 27 Siebel eScript, examples of invoking from S workflow process 167 S_ESCL_ACTION table 274, 275 Siebel FDR files S_ESCL_ACTN_REQ table 274 See Siebel Flight Data Recorder files S_ESCL_LOG table 274, 275 Siebel Flight Data Recorder files 198 S_ESCL_REQ table 274, 275 Siebel Operation S_ESCL_STATE table 274, 275 definition 298 SARM Siebel Operation Object Id See Siebel Application Response Management default process property 93 scripts, invoking workflow processes, Siebel Operation steps examples 167 about 124 Search Specifications for Siebel Operation defining 125 steps defining fields 126 field descriptions 128 defining output arguments 127 seeded workflow processes 57 defining search specifications 126 Send Campaign Email, using 288 updating fields based on multi-value groups Send Email 129 creating for Workflow policy 234 Siebel Server using and arguments 213 Email Manager, setting up 269 Send Message Argument, properties, table of setting up for Page Manager 270 255 Siebel Server Administration, viewing trace Send Message Arguments applet 213 files 285 Send Message Broadcast, Workflow Policy Siebel Server log directory 286 program 23 Siebel Server task trace file Send Message, Workflow Policy program 23 created for listed processes 285 Send Page viewed in Siebel Server Administration 285 about and arguments 212 viewed in Siebel Server log directory 286 Workflow Policy program about 23 Siebel Server, description 27 Send Quote Page, using and SQL statement Siebel Tools 27 examples 262 customizing Workflow Policies 236 Send to Relative recipient type, about Program List view, using 252 sending email or page 217 Validate Tool and Workflow Policies 248 server requests, submit request arguments Workflow Processes and 62 331 Siebel VB, examples of invoking from Service Request Priority, updating 222 workflow process 167 service requests simulation assigning manager as owner 261 workflow processes 177 close date, changing to today’s date 259 specialized comparisons, descriptions 232 owner, changing to today’s date 260 SQL script file 267 service workflow process SQL statements Object Id 94 created for program arguments 258 Siebel administrators types of 262 correcting processes and resuming 165 Start step deleting workflow process instances 192 defining a start step 133 stopping workflow processes 190 Start steps Siebel Application Response Management about 107 197 defining 107 Siebel ARM defining Next Step branches 108 See Siebel Application Response Management definition 299 Siebel Client step instance, defined 299 description 27 steps copying 92 350 Siebel Business Process Framework: Workflow Guide Version 8.0
    351. Index ■ T definition 299 notes on 293 deleting 92 tutorial Stop steps deploying workflow processes 87 about 137 designing workflow processes 80 defining 138 testing workflow processes 85 definition 299 input arguments, defining 138 U Subprocess applet user events field descriptions 121 configuring long-running workflows to wait Subprocess steps 159 about 120 using 156 defining 122 Workflow User Event business service 157 defining input arguments 122 User Interact next step branches defining output arguments 123 conditions 133 defining recipients 123 User Interact steps subprocesses about 131 assigning to end users for long-running branches, defining 133 workflow processes 145 creating substitute view names 134 definition 299 defining 132 synchronous server requests 330 user, workflow role described 25 synthetic events creating 147 creating Next and Back events 148 V creating ResumeLastIntFlow events 150 Validate Tool creating SaveWorkflow events 148 using for Workflow Policies 248 using for Workflow Processes 175 values T described 63, 236 testing Message Broadcast program type 214 workflow process, creating strategy for 58 Recipients applet fields 217 workflow processes, Process Simulator 176 Run External program type 215 workflow processes, tutorial 85 Send Email program type 213 testing workflow policies 293 Send Message Broadcast program type, table trace file of 214 Siebel Server log directory, viewing in 286 valid database operations program argument Siebel Server task trace file, created for listed 254 processes 285 VerCheckTime parameter, setting 42 viewing trace files 285 view names tracing creating substitutes using process properties workflow processes, increasing tracing levels 134 197 workflow processes, log levels 196 tracing and logging events 196 W trigger Wait steps database triggers, creating 263 about 130 Generate Trigger (Gen Trig), component- defining 130 specific parameters for 266 definition 299 Generate Trigger (Gen Trig), functions 263 global time calculations 160 Generate Trigger (Gen Trig), tips of running input arguments, defining 131 266 WF Process Props applet invalid trigger, avoiding in production field descriptions 71 environment 295 WF Step Branches applet troubleshooting field descriptions 102 Email and Page Manager 272 WF Step Recipients applet field descriptions 120 Siebel Business Process Framework: Workflow Guide Version 8.0 35 1
    352. Index ■ W WF Steps applet Workflow Groups, starting multiple for 283 field descriptions 99 Workflow architecture wildcards, using in standard comparisons overview 27 230 Workflow columns work item, defined 299 adding 245 Workflow adding to Workflow objects 247 associated job roles 25 applet fields in 240 definition 18 associating Workflow component with 248 deployment architecture 46 described 300 design-time architecture 43 Workflow Columns applet fields, values of enabling business services for 58 240 general principles 18 Workflow component columns global implementations 159 described 300 global implementations, configuring workflow functions of 238 processes in a multilingual properties fields 245 environment 159 Workflow Component Columns List view global implementations, defining expressions described 244 for workflow processes 160 function of 240, 242 global implementations, Wait steps and global Workflow components time calculations 160 architecture 27 interaction with other Siebel components 52 associating with Workflow column 248 invocation mechanisms 49 defining 246 processing modes, 7.0 Flow 143 described 238, 300 processing modes, about 141 relationship between 239 processing modes, Interactive Flow 144 relationship between component and primary processing modes, Long Running Flow 143 250 processing modes, Service Flow 144 relationship between Workflow object and 239 requirements 56 Workflow Components List view run-time architecture 47 displayed 243 Siebel Tools and 62 function of 240 simulation architecture 45 Workflow condition, defined 300 upgrading 60 Workflow Conditions applet Workflow Action Agent using specialized comparisons in 230 functions of 281 workflow groups starting 273 creating 203 to run processes of 282 defining a workflow policy group 291 to shut down 282 description 24 Workflow Action Arguments Workflow Agent processes, starting multiple applets, described 210 283 Workflow Actions workflow policy group, described 301 creating Assign to Campaign Email 290 Workflow Groups applet creating Create Email Activity 290 about using 224 creating Database Operation Program type field descriptions 225 222 Workflow Groups view, function of 210 creating Message Broadcast Program type Workflow Instance Admin view 194 214 Workflow Instance Monitor view 194 creating Run External Program type 215 Workflow Manager creating Send Campaign Email 289 See Workflow Policies creating Send Message Program type 213 Workflow Monitor Agent creating Send Page Program type 212 parameters 278 using Database Operation program type 216 starting 275 Workflow administrator, role of 25 testing workflow policies 293 Workflow Agent process Workflow object properties fields 242 starting automatically 283 Workflow objects 352 Siebel Business Process Framework: Workflow Guide Version 8.0
    353. Index ■ W adding columns to 247 Workflow Policies Explorer view 210 adding new 247 Workflow Policies Groups view defined using Object Explorer views 246 Policies applet fields, table of 225 described 301 Policies applet, described 224 functions of 238 Workflow Groups applet 224 relationship between Workflow components Workflow Policies Log view 210 and 239 Workflow Policies module, described 17 Workflow Objects List view 239 Workflow Policies Policies view workflow persistence Actions applet field, table of 233 about 154 working with 225 enabling, setting 155 Workflow Policies Report page, about 287 using 154 Workflow Policies view, function of 210 Workflow Policies Workflow Policy Action Agent 203 definition 22 workflow policy actions license key validation 59 creating 218 overview 21 working with 210 policy condition, about 22 Workflow Policy applet fields 228 program types, list of 23 workflow policy column, definition 300 repository setting, viewing 59 workflow policy component column, required components 59 definition 300 structure, about rule structure (diagram) 22 workflow policy components, definition 300 verifying installation of 59 workflow policy groups views, administered by and example 25 creating 224 workflow groups, about 24 definition 301 workflow policy action, parts of (diagram) 22 planning 203 workflow policies Workflow Policy Log 293 Assign Non-Respondents policy, creating 292 Workflow Policy Monitor Agent 203 conditions, table of specialized comparisons workflow policy objects 232 definition 301 created for Send Email 234 modifying 248 creating 225, 226 Object Explorer, adding to 236 described 300 workflow policy program Email for CD-ROM Campaign policy, creating property field descriptions 252 291 viewing with Program List view 252 invoking a process 166 workflow process migration 209 copying workflow processes 92 moving from one group to another, note 228 defining new workflow processes 76 planning policies and conditions 205 defining parameters 75 planning, about 204 defining process properties 96 planning, determining what to monitor 205 defining step details 91 production environment, migrating to 294 defining steps 75 program types 211 deleting steps 92 Siebel Operation steps, using different object deleting workflow processes 92 layers, described 129 diagramming steps 90 testing 209, 293 field descriptions for definitions 99 using specialized comparisons 230 modifying existing definitions 78 using standard comparisons 229 naming conventions 77 views, list of 210 process properties 93 Workflow Policies Actions view process properties versus property sets 95 applet, field descriptions 211 reviewing existing definitions 76 applets, description of 210 types, 7.0 Flow 143 Message Broadcast Arguments applet 214 types, about 141 Recipients applet 217 types, Interactive Flow 144 Workflow Policies Arguments applet 211 types, Long Running Flow 143 Siebel Business Process Framework: Workflow Guide Version 8.0 35 3
    354. Index ■ types, Service Flow 144 process properties and property sets 95 workflow process instance purging instances from the log 192 definition 299 recovery 164 Workflow Process Manager requirements 56 about running workflow processes in batch running in batch mode 172 mode 172 running in the application object manager 172 server component, running a workflow running in the Workflow Process Manager process 171 server component 171 Workflow Process Manager business service running on Object Manager 172 passing inputs and outputs 339 Siebel Tools and 62 workflow process parameters simulation 177 about defining 75 stopping all instances of a specific process workflow process steps definition 190 about defining 75 stopping instances 190 workflow process, designing testing 176 definitions, working with 76 testing caution 178 Workflow Processes testing, defining and migration strategy 58 overview 19 testing, Process Simulator 177 sample scenario 20 testing, running the Process Simulator 178 workflow processes testing, Validate Tool 175 administering 188 testing, workflows involving server business services, enabling 58 components 180 considerations for planning 57 tracing events 294 copying 92 troubleshooting, about 193 definition 299 troubleshooting, increasing tracing levels 197 deleting 92 troubleshooting, Siebel Application Response deploying 182 Management 197 deploying, about 181 troubleshooting, Siebel Flight Data Recorder deploying, on regional nodes 184 files 198 deploying, restricting mobile client routing troubleshooting, tracing and event log levels 184 196 deploying, to mobile clients 184 Workflow Processes module, described 17 existing process definitions, reviewing 76 workflow processes, designing exporting process definitions 187 process steps, about diagramming 90 gathering information for 55 process steps, diagramming procedure 90 importing process definitions 187 workflow processes, monitoring invocation 165 correcting processes and resuming 165 invocation, as a configured business service deleting workflow process instances 192 170 stopping 190 invocation, from a run-time event 169 tracing and logging events, table of 196 invocation, from a script 167 Workflow programs invocation, from a script in the object Assign to Campaign 289 manager, example 168 configuring predefined 259 invocation, from a Workflow policy 166 Create Email Activity 288 invocation,about 165 creating or modifying 256 invoking from a run-time event, about 169 described 251, 300 invoking from a script, examples 167 five types of 251 invoking from a workflow policy 166 Send Campaign Email, using 288 migration from development to production Workflow User Event business service 185 generating user events 158 monitoring, about 193 Workflow Utilities, arguments 333 monitoring, levels 195 overview of developing 61 planning tips 57 354 Siebel Business Process Framework: Workflow Guide Version 8.0
    SlideShare Zeitgeist 2009

    + jmartinez19682jmartinez19682 Nominate

    custom

    614 views, 1 favs, 0 embeds more stats

    manual de workflows para Siebel 8.0

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 614
      • 614 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 1
    • Downloads 23
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    -->
    What's New

    © 2009 SlideShare Inc. All rights reserved.