Siebel Workflow

Page 1 of 66

Table of Contents
Introduction ...................................................................................................................................... 3 What is Siebel Workflow? ................................................................................................................ 3 Workflow Runtime Architecture ....................................................................................................... 5 Development and Deployment Lifecycle ......................................................................................... 6 Step 1: Analyze Business Requirements Rules and Processes to be Automated .................. 6 Step 2: Define Processes in Siebel Workflow ............................................................................. 7 Workflow Basics ....................................................................................................................... 7 Events Invoking Siebel Workflow Processes ........................................................................ 8 A Word on Workflow Policies ................................................................................................... 9 Rules - Business Logic and Decision Rules ........................................................................... 10 Decision Rules: Decision Step Details .................................................................................. 11 Actions .................................................................................................................................... 12 Actions: Business Service Step............................................................................................. 13 Actions: Siebel Operation Step ............................................................................................. 15 Actions: Wait Step ................................................................................................................. 15 A Word about Process Properties .......................................................................................... 15 Developing Workflows in Siebel Tools ................................................................................... 16 Step 3: Identify and Build Exception Handling .......................................................................... 17 Step 4: Validate and Simulate Workflow Process ..................................................................... 18 Process Simulator .................................................................................................................. 18 Using Business Service Simulator ......................................................................................... 18 Event Logs.............................................................................................................................. 19 Step 5: Migrate to Production ................................................................................................... 19 Step 6: Monitor Process ............................................................................................................ 21 Externalize parameters .......................................................................................................... 21 Troubleshooting of workflows in production environment ...................................................... 21 Communicating workflow errors to Siebel Technical Services professionals ........................ 22 Troubleshooting Common Workflow Errors ............................................................................... 23 Examples ....................................................................................................................................... 25 Example 1: Attach Activity Plan to an Oppty - Test with Simulator and Runtime Client ........... 25 Step 1: Configure a New Workflow ....................................................................................... 25 Step 2: Test the Workflow Using the Process Simulator ...................................................... 32 Step 3: Call the Workflow from the UI using a Runtime Event .............................................. 37 Step 4: Deploy and Activate the Workflow Process .............................................................. 40 Step 5: Test the Workflow using the Runtime Client ............................................................. 42 Example 2: Creating Workflow Process Triggered by Runtime Event ..................................... 44 Example 3: Creating a Service Mode Workflow ....................................................................... 49 Example 4: Runtime Event Workflow with User Interact Step to Navigate User to a View ...... 60 Example 5: Externalize parameters to be used by workflow .................................................... 63 Overview................................................................................................................................. 63 Design .................................................................................................................................... 63

Page 2 of 66

Introduction
Siebel Workflow is a robust technology that allows companies to enable process automation within Siebel applications. Because the automation of typical business processes can be complex, documentation that further explains how Siebel Workflow can be used and provides examples, is useful. The intent of this document is to augment the Siebel Business Process Administration Guide with additional information and practical examples. The target audience for this document is IT Project Managers, IT developers with Workflow skills ranging from novice to advanced. The information in the document ranges from very basic and simple concepts to more advanced topics.

What is Siebel Workflow?

Siebel Workflow orchestrates other Siebel process automation technologies. Workflow processes graphically sequence a series of automation steps that support a process, and specify inputs and outputs for individual steps and for the process as a whole. Figure 1. Siebel Automation Technologies Workflow Policies

Workflow Processes State Model Activity Template

Assignment Manager

SmartScript

Technologies that enable business process computing in Siebel are: Assignment Manager Expresses rules to assign records to people, enables assignment based on skills, workload, availability, etc and supports ownership transitions within a process. SmartScript Guides users through data entry tasks, and is effective for call scripting and includes basic support for transaction level commits. Activity Template Contains a pre-defined series of to-do steps and is effective for handling asynchronous/offline tasks. Workflow Policies Generates events based on database operations and is effective for performing simple actions such as sending email, creating an activity or assignment. State Models Restricts transition of record status based on current value and position of the user. Also can enforce directional progression of status, for example so Opportunities move forward but not backward through a pipeline.

Page 3 of 66

Each of these technologies delivers specific functionality. Workflow process acts as the orchestrator of many of the services performed by each of these technologies. These technologies are part of Siebels infrastructure and together they enable business process computing in Siebel. A workflow process acts as the orchestrator either invoking each of the technologies directly, or interacting through Siebels robust event model and is the key technology behind building business processes in Siebel. The focus of this document is on Workflow. In Siebel 7.7, Siebel Workflow has been moved from the Siebel Client to Siebel Tools. Hosting Siebel Workflow in Siebel Tools would provide an integrated development environment to configure Siebel objects including workflow. An integrated development environment allows a top-down development framework for building business logic that start with a process and then provide pluggable services and data objects that make the process executable.

Page 4 of 66

Workflow Runtime Architecture

The Workflow runtime architecture is based on the Siebel Object Manager layer and the server infrastructure layer of the Siebel applications architecture. The runtime environment is available both as a business service and as a server component. Siebel Business Process Designer has four types of workflow processes that characterize runtime 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. 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 upon event invocation. The runtime architecture supports three invocation modes for invoking and resuming workflow processes: Local Synchronous, Remote Synchronous, and Remote Asynchronous. Figure 2 below shows the runtime architecture: Figure 2. Workflow Runtime Architecture

Page 5 of 66

Development and Deployment Lifecycle

Figure 3, below depicts the development and deployment lifecycle for a Workflow. Note, this is shown as a linear flow, however the typical development process is iterative. Each of these steps will be discussed in detail in the following sections. Figure 3. Development and Deployment Lifecycle
1. Analyze Business Requirements Rules and Processes to be Automated

2. Define Processes in Siebel Workflow

3. Identify and Build Exception Handling

4. Validate and Simulate Process

5. Migrate to Production

6. Monitor Process

Step 1: Analyze Business Requirements Rules and Processes to be Automated

An implementation project team will typically spend 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 will define processes he wants automated in Siebel. A developer would review these processes and when making design decisions on how to implement these, he would look for areas of: Repetitive, manual processing Timely processing of an event Escalations and notifications,

as candidates to be implemented in Siebel workflow. When making implementation decisions, a developer should consider the follow options for automating processes. Some major tradeoffs are listed in Table 1 below.

Page 6 of 66

Table 1. Siebel Workflow Process Framework versus Other Siebel Mechanisms Framework Workflow Process Key Advantages Visual representation of business logic is relatively to understand and maintain Remote synchronous and asynchronous execution enables broad horizontal scalability and long running transactions Limitations Semantics for control of flow not as rich as scripting. Specific limitations include: . Limited ability to loop through hierarchical property sets with multiple children at the same level.

Workflow Policies

Respond to database events regardless of whether theyre initiated by an OM or non-OM component

Limited direct access to object methods Changes to policies may require database downtime to implement More difficult to configure that other alternatives Limited range of executable actions Widespread scripting degrades: o Maintainability o Upgradability o Performance

Siebel Script

May get higher transaction throughput on a given set of hardware for simple transactions Familiar to most developers Complete set of semantics/ highly flexible

Step 2: Define Processes in Siebel Workflow

Workflow Basics
With Siebel Workflow, the run-time engine manages process flow, application flow and integration flow. The following basic constructs are available to define your Workflow process:

Page 7 of 66

Start defines the beginning of a process Figure 4. Palette in 8.1 Decision defines branching in the workflow Business Service calls a business service method Sub- Process calls another workflow process Siebel Operation queries, updates, deletes, or loops through data through business components. Wait pauses processing User Interact navigates to a Siebel view Stop stops the process and displays a message End defines the end of a process Connector defines sequence, can define conditions associated with it Error Exception defines a branch taken outside of the normal flow, when an exception occurs. Task Calls a Task from the Task Based UI suite.

The Siebel Workflow Users Guide provides detailed explanations on how to implement each of these steps. However, there are some key components that enable runtime execution that will be discussed in more detail here: Events Workflow processes can be invoked from events in the Siebel application or from external systems. Events can pass context from the caller, user session, for example to a workflow using a row-id. Rules The flow control is based on rules. Rules can be based on business component data or local variables, known as process properties. Rule expressions are defined using Siebel Query Language. Actions Action can perform database record operations or invoke Business Services. Also, an action can cause a pause in the workflow. Data is created or updated as the process executes. There are basically three types of data a workflow process will operate on, business component data, process properties, and Siebel Common Object data. You can think of process properties as local variables that are active during the process. The variables are used as inputs and outputs to the various steps in a process.

Events Invoking Siebel Workflow Processes

A workflow process may be invoked in a number of ways some of which are in the following list. Calculated fields through InvokeServiceMethod Applet User Properties such as Named Method Runtime Events Script Other workflow processes Workflow policies Web services Workflow policies allow you to define policies, or rules that can act as triggers to execute a workflow process. The basic construct of a policy is a rule. If all the conditions of a rule are true, then an action occurs. Typical usages of a workflow policy are EIM batch, EAI inserts and

Page 8 of 66

updates, manual changes from the user interface, assignment manager assignments and Siebel remote synchronization.

Type Workflow Policies

Description

Table 2. Invoking Workflow When Useful

Limitations Changes require database downtime Relatively complex to configure Cant directly respond to event by scripting against the event object Can be more difficult to pass event context to business logic Dont trap data changes made by non OM components Changes must be distributed through new .srf file Does not trap data changes made by non OM components

Trigger based on database changes

Runtime Events

Raised by OM

Belong to 3 objects: Application, Applet, Business Component Configurable from Administrative interface Raised by OM

Need to detect and react to data changes made outside of the Object Manager (OM) for example, by Siebel Remote or EIM Need to implement basic entry point for a workflow or simple custom action Need to avoid distributing .srf files e.g., because of burden on mobile users Need flexibility to write script directly in response to an event Need access to an applet event thats only exposed in Siebel Tools

Tools Object Events

Belong to 4 objects: Application, Applet, Business Component, Business Service Scriptable from Siebel Tools

When deciding whether to implement a workflow policy versus a workflow process there are some additional things you may want to consider. Data coming into the Siebel application via the data layer, such as EIM and MQ channels, and those that cannot be captured via the business layer are typically good candidates for a workflow policy. Some features not supported by workflow processes like eMail Consolidation, Duration, and Quantity are also candidates for workflow policies. However, workflow processes provide a better platform for development and deployment, complex comparison logic, flow management (if, then, else, or case), leverages business layer logic, can invoke Business Services and pause/stop/error handling capability

A Word on Workflow Policies

Workflow Process and Runtime events ensure most events are captured at the business layer logic level. However there are business scenarios where the Workflow Policy Manager would be the best alternative. Workflow Policy Manager ensures business logic is captured at the data layer of Siebel architecture. Some examples of such scenarios would be when bulk data uploads happen via EIM or Data Quality cleaning happens in the data layer. The diagram below, Figure 5, displays Workflow Policy architecture.

Page 9 of 66

When using Workflow Policy, the data layer business policy enforcement is done via database triggers. When a particular policy is violated, underlying triggers capture database events into a Workflow Policy Manager's queuing table (S_ESCL_REQ). A Workflow Policy Manager component (Workflow Monitor Agent) polls this table and processes requests by taking appropriate actions defined. In some cases, actions might be to invoke Workflow Process Manager. Workflow Policy Manager provides additional scalability by using an additional component called Workflow Action Agent that can be executed on a different application server within the Siebel Enterprise.

Figure 5 Workflow Policies

End-user activity or server process EIM Generate triggers Create triggers Siebel Database Reads records S_ESCL_REQ

Triggers fire

Workflow Process Mgr

Server Request Broker

Workflow Monitor Agent

Rules - Business Logic and Decision Rules

There are several different ways to implement business rules in a Workflow process. The following chart shows the major ways and a comparison on when to use them. Table 3. Business Logic When Useful

Type Workflow Decision Step

Description

Limitations Conditional expressions lack support for some key operators including: o AND o OR o Order of precedence control (such as parentheses) o Need to have a

Kind of step in a Workflow that arbitrates between one or more alternative branches in a flow Each branch out of decision step has one or more conditions if all evaluate to TRUE for the branch the flow will continue down the branch

Need a simple articulation of whether one or more alternative actions in flow should be taken

Page 10 of 66

Scripted Business Services

Script within a business service Action step that evaluates a potentially complex set of inputs and returns a simplified output that can be evaluated by a workflow decision step

Workflow decision step semantics not sufficiently expressive to encapsulate decision criteria

default step in case no condition is satisfied. o Need to make sure that different branches have clearly different conditions that would evaluate to true so that two branches are not simultaneously true. Undermine readability and simplicity of workflow by hiding logic within a service This should be a last resort. Workflow processes have many capabilities that developers used to script but that are now available inside the workflow process.

Other Specialized Rule Frameworks

Other rule frameworks that may be leveraged directly or indirectly by a workflow o Personalization Rules o Assignment Rules o Haley Expert Rules o Oracle Policy Automation

Decision Rules: Decision Step Details

Decision steps 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 or 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 or all must match, greater than or less than, between or not between, and null or not null.

Page 11 of 66

The Compose Condition Criteria dialog box is shown in Figure 6. This example shows a branch in a workflow where the branch would be followed if the Severity field from a Service Request matched the value 1-Critical. Figure 6. Decision Criteria

Actions
There are several ways to affect actions in a workflow. In other words, data is taken as an input, a transformation takes place and data is produced as output. The Table 4 below shows the major ways to cause a transformation with some explanation of how to make design decision on how to use them. Table 4. Actions in Siebel Workflow When Useful Limitations Need to execute potentially complex, but reusable set of logic Try to use configuration and the workflow process itself before writing script. Creating and destroying business services can be expensive overhead can be reduced through caching Incorporating too much logic with a business service may limit its reusability and the transparency of the workflow

Type

Description

Business Service Step

Workflow Step that invokes a method of business service Business service may be a prebuilt Siebel service or a customer defined (scripted) business service

Page 12 of 66

Siebel Operation

Workflow step that performs Inserts, Updates and Queries against Siebel business components Puts the workflow into a holding pattern until a releasing event is fired or a timeout occurs

Wait

Sub Process

Calls another workflow process passing it zero or more input properties.

Task

Calls a Task from the Task Based UI suite.

Need to execute simple record operations within the workflow Can also iterate through records in a business component. Useful to support time-based escalations or long running flows that may last for days or weeks for example, waiting for a customer response When another process already encapsulates needed logic. When operations in business components within a Business Object that is different than the current one defined for the workflow process. When a predefined task that involves user interaction is necessary. For creating interactive workflow processes.

Possible to update multiple records based on a search specification.

Releasing event must be triggered through the OM

User Interact

Takes a user to another view.

Cannot work if there is no user interface so can only be executed by a live user.

Actions: Business Service Step

Business Service steps execute predefined or custom methods in business services. Typical predefined business services used include Assignment Manager requests, Notification through the Communications Server, server requests and integration requests (EAI). Custom Business Services can be written in Siebel VB or eScript. When defining a Business Service step you must

Page 13 of 66

specify the business service, the business service method, input arguments (pass in Process Property, BusComp data, or literal value) and output arguments. Some commonly used Business Service in Workflow processes include: 1. FINS Data Transfer Utilities Description: Allows you to transfer data from source BC to a destination BC without script. Available Methods: DataTransfer GetActiveViewProp QueueMethod TryMockMethod. 2. FINS Validator Description: Validate data based on predefined rules. It is developed through Application Administration and not script. Also, supports custom messages. Available Methods: Validate

3. FINS Dynamic UI Service Description: Allows creating and rendering of read-only views with a single read-only applet based on user input. Administered through admin views and not script. Available Methods: AddRow DeleteRow SetViewName 4. Outbound Communications Manager Description: Automates sending notifications via fax and emails to contacts and employees. Available Methods: CreateRequest SendMessage SendSmtpMessage SubmitRequest 5. Synchronous Assignment Manager Requests Description: Automates assigning objects by using Assignment Manager rules. Available Methods: Assign 6. Server Requests Description: Allows sending of generic requests to the request broker. It can send it in three different modes: asynchronous, synchronous, or schedule mode. (Example, call a workflow but need to be asynchronous request) Available Methods: SubmitRequest CancelRequest 7. Report Business Service Description: Automates sending, scheduling, printing, saving, emailing reports. Also, automates administrative tasks such as synching new users. Available Methods:

Page 14 of 66

ExecuteReport DelOne DownloadReport GrantRoleAccess2Report GrantUserAccess2Report PrintReport RunAndEmailReport ScheduleReport SyncOne

Actions: Siebel Operation Step

Siebel Operation steps allow you to perform database operations of Insert, Update and Query. These steps are performed on business components. Once you have defined the Operation step, you can use the Fields child object to define any field values for the step. Also, for an Update you can use the Search Specification child object to define the records you want to update. One can also loop through the records for a business component completely within the workflow process. Examples of 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.

Actions: Wait Step

Wait steps allow you to suspend process execution for a specified period of time or until a specific event occurs. One can only use a wait step in a Long Running Flow or an Interactive Flow. The example below shows how you can define a timeout based on time defined as literal values in input arguments. Figure 7. Wait Step in 8.1.1

A Word about Process Properties

Process properties are used as input and output arguments for the entire process. Process properties are used to store values that a workflow process retrieves from the database or derives before or during processing. Decision branches can use the values in a process property and pass properties as step arguments. When a workflow process completes, the final results of the process properties are available as output arguments. Process property values can be used in expressions. With every workflow there is a set of predefined process properties that are automatically generated when you define the workflow. These are: Error Code: Populated by a step should an error occur

Page 15 of 66

Error Message: Populated by a step should an error occur Object Id: Row ID of the record against which the process is invoked Process Instance ID: Unique number assigned to the currently running instance of the process Siebel Operation Object ID: Row ID of the record inserted by the Siebel Operation step

As an example for using process properties, you could define three new process properties for a workflow. These properties are of type string shown below. They have values Welcome, to, and Siebel. Figure 8. Process Properties

You can create a fourth process property, ProcessProperty4, that concatenates these three values and displays it in an applet field. ProcessProperty4 would be of type string and would get a value as an Output Argument on a step. The Output Argument would be of type Expression as shown below: Figure 9. Process Property Used as an Output Argument

Developing Workflows in Siebel Tools

The following section brings out some points with Siebel Workflow in Siebel Tools and developing on a local database. Workflow is a repository object. Workflow belongs to a project. In Siebel, workflow does not participate in the following behaviors that are standard for other repository objects SRF workflow has its own deployment mechanism, the details of which can be found in the Business Process Designer Administration Guide

Page 16 of 66

Merge workflow does not participate in the 3-way merge. When workflow definitions are imported into the repository, they maintain versioning provided by workflow Archive workflows do not participate in .sif archive. Instead, workflows can be archived as XML files using workflow export utility.

Typically, developers use local database to develop workflows. When using local database, workflow definitions need to be checked-out from the master repository. When developing workflows in local database, it would require the local database to have all the referenced data objects. For those data objects that are not docked and hence not packaged as part of the database extract, they would need to be imported into the local database. The following objects are not docked and are referenced by workflow Data Maps Message tables To import data maps to the local database, you would use the dedicated client connected to the local database and use the client-side import utility. Message tables can be copied over to the local database. Alternatively, developers can define messages using the unbounded picklist. This allows the creation of the messages but does not check the validity of the message at definition-time. Developers can also develop or modify workflows using Siebel Tools connected to the development database by locking the project in the master repository. This way, they do not need to make sure that all the list-of-values are made available to the local database

Step 3: Identify and Build Exception Handling

An exception represents a deviation from the normal processing flow. An exception can be a system error or a user-defined error. The Stop step can be used in combination with the exception branch to notify the user of an error and terminate the workflow process instance. Here are three different types of exception handlers: 1) Use a Stop step which can show a particular error message while processing. This could be used for real-time processing for credit card authorization or order validation, etc. This provides customizable error messages including expressions.

2) You can programmatically handle exceptions and change the flow depending on when exceptions are encountered. This is done by using exception branches. This provides a granular approach to handling exceptions at each step. In the example below, when the Get Organization ID step is unable to get data, the workflow is programmed to continue and hand over to Lookup Sender by Org step and if it fails send an email (Send Lookup Error eMail).

Page 17 of 66

3) You can define a universal exception handler at the workflow level by setting Error Process Name on the workflow. This will be invoked for any exception that happens on the workflow. This is used when you need a uniform exception handler across multiple steps in a workflow or across multiple workflows. This helps also to reduce clutter on the workflow diagram itself. One would use the exception branches to handle runtime error conditions in a more manual, or granular way, for example, if three different steps must be handled differently. If all errors in the workflow process are going to be handled in the same way, then the Error Process is the way to go.

Step 4: Validate and Simulate Workflow Process

There is a two step approach to testing and troubleshooting a workflow: using the workflow process simulator, and event logs.

Process Simulator
Most workflows can be tested using the Process Simulator. Developers can use the workflow Process Simulator hosted in Siebel Tools to debug workflows. To use the Process Simulator, you need to have mobile client installed. The mobile client can connect to any database (i.e. development or test) that has the test data needed to debug a workflow. Developers can test interactive workflow 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 debug, the process variables are displayed using the dynamic watch window.

Using Business Service Simulator

Workflow can be run as a business service from the Business Service Simulator in Siebel Client. The workflows would need to be deployed before testing them from the business service simulator. This approach is useful when script needs to be debugged in conjunction with workflow. One would set breakpoints in the script and execute the workflow in the mobile client. When the workflow executes a service for which breakpoint is set, control will be returned to the Script Debugger in Siebel Tools.

Page 18 of 66

Event Logs
More detailed information on the execution can be viewed in log files by setting event logs. Events used for logging are as follows: Event: Workflow Engine Invoked (EngInv) Description: Trace methods invoked and arguments passed Event: Workflow Definition Loading (DfnLoad) Description: Trace process and step definitions loaded into memory Event: Workflow Process Execution (PrcExec) Description: Trace process instance creation/completion. Trace process property get/set. Event: Workflow Step Execution (StpExec) Description: Trace step creation/completion, branch condition evaluation, business service invocation, business component insert/update. Refer to Siebel Bookshelf Version 8.1 >Siebel Business Process Framework: Workflow Guide > Administering a Workflow Process > Monitoring a Workflow Process >Setting Monitoring Levels for Tracing and the Event Log > for an explanation on how to set these.

Step 5: Migrate to Production

Once the workflows are tested, they are marked for deployment by clicking the Deploy or Publish button and then checked into the master repository. Deployment of workflow is a two-step process: 1. Using Siebel Tools, workflow definitions are marked for deployment. This is done by clicking the Deploy or Publish button in Siebel Tools. 2. There is a Publish/Activate button in Siebel Tools as of Siebel 8.0.x that allows this to be a single step. This button will deploy and activate the process in one step.

3. Using the Siebel Client, workflows are activated from the Business Process Administration view. The process of activation, writes the definitions from the repository tables to the runtime tables for the workflow engine to execute. Workflow definitions can be migrated across environments, from Development to Production for example, using one of the following migration utilities: 1. Repository Migration Utility this utility allows export/import of all repository objects. This utility is best used to migrate workflow definitions when the business is ready to rollout the release (for example, migrate all repository objects) 2. Workflow Import/Export this utility allows incremental migration of workflow definitions. Using Siebel Tools, one would 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: a. Using Siebel Tools, you would import the definition into the repository of the target environment. Then the definitions are ready to be activated. This approach ensures that the version of the workflow definition that exists in the repository tables and the runtime tables are the same.

Page 19 of 66

Figure 10. Incremental Deployment Using Import/Export Siebel Client 3. Activate (writes definition to runtime tables) XML Repository tables Runtime tables
1. Tools Export 2. Tools Import

Siebel Tools
Workflow Import/export utility

Repository tables Runtime tables

Test DB

Production Test DB

b. Using Siebel Client, you could import the definitions directly into the runtime tables. This approach bypasses the step of writing the definition into the repository tables of the target environment and activation from Siebel Client. This would cause the latest version of the workflow definition in the runtime tables, used by the workflow engine, to be different from the version that resides in the repository tables. This approach is good for testing a workflow in different environment but not a best-practice recommendation for migrating workflows across environments. See Figure 11:

Page 20 of 66

Figure 11. Incremental Deployment Using Siebel Tools and Client

Siebel Tools
Workflow export utility

Siebel Client - 2. Client-side

import

XML Repository tables Runtime tables

1. Tools Export 2. Clientside Tools Import

Repository tables - Workflow V1 Runtime tables - Workflow V2

Test DB

Production Test DB Incremental deployment using Export utility from Siebel Tools and Import utility from Siebel Client

Step 6: Monitor Process

Externalize parameters
As best practice development guidelines, workflow definitions should have parameters that are externalized and not hard-coded. Having parameters hard-coded in workflow, developers would need to change the definition when the workflows are migrated between environments and executed. For example, if the workflow is sending emails to a list of customers and the parameter is hard-coded with the customer list, the workflow would not work correctly in the production environment. Developers need to make sure that such input arguments are read in dynamically. In the examples section, a best practice example is provided on how to externalize parameters that are used by workflows.

Troubleshooting of workflows in production environment

Workflows in production environment can be debugged in one of the following manners. 1. Turn on tracing on the corresponding component, Workflow Process Manager, Workflow Process Batch Manager, Application object Manager and view the event log files. For details on how to turn on tracing please refer to Business Process Designer Administration Guide or look at How Can Tracing Be Increased for Workflow Process Manager and Workflow Process Batch Manager? (Doc ID 476283.1) on My Oracle Support Portal. 2. Turn on monitoring level to 3-Detail or 4-Debug. At this level, each execution of a process (whatever component it is run from) will record state and process properties value for each step. The information is then available in the Site map > Administration Business Process > Workflow Instance Monitor > Process Instances/ Step Instances.

Page 21 of 66

Such levels of monitoring affect performance of the workflow engine. Hence such settings should be used for troubleshooting purpose only. 3. You can run the workflow process from the business service simulator using the business service Workflow Process Manager. Here are the steps: i. ii. Navigate to the Site Map > Administration - Business Service > Simulator. In the top applet, create a new record and set the following fields: Service Name: Workflow Process Manager Method Name: RunProcess Iterations: 1 In the Input Arguments applet, create a new record, and set the "Test Case #" field to 1 and open the Property Name field (which opens up a multi-value applet). Click the New button and set the following fields and then click the Save button: Property Name: ProcessName Value: <the name of the workflow process> Repeat above step for any parameter that should be passed to the process, especially RowId if needed. Click the OK button in the multi-value applet opened in step iii. Click the Run button in the top applet of the Simulator view.

iii. iv.

v. vi. vii.

You can for instance set the monitoring level to 4-Debug, launch the workflow this way and then look at the process execution information as described in step 2 above.

Communicating Workflow Errors to Siebel Technical Services professionals

Workflow errors can be communicated to Siebel Support professionals in one of the following ways Send the log files (as was done previously) generated by turning on tracing With the exception of service flows, when a workflow process encounters an error, the process state will be persisted with an In-Error status. If a workflow process encounters an error in one of its sub-processes, the sub-process state will also be 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 in Site map > Administration - Business Process > Workflow Instance Admin > All Workflow Process Instances. When a record is selected from the All Workflow Process Instances, 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.

Page 22 of 66

Troubleshooting Common Workflow Errors

The following lists some commonly encountered errors for Workflow Process Manager. 1. Problem: You activated your workflow but it is not executing Solution: Verify if <Reload Runtime Events> performed. In order to tell if a process has been triggered, Turn workflow logging (EngInv, DfnLoad, StpExec, PrcExec) on. See the Business Process Administration Guide in Siebel Bookshelf for procedures on how to do this. 2. Problem: You revised the workflow process and re-activated it, but somehow the previous workflow information was read. Solution: Restart Siebel Server service to refresh the cached version. 3. Problem: When workflow is triggered by runtime event Display Applet, the workflow is triggered the first time but not subsequently? Why? Solution: Since the DisplayApplet event is a UI event, and the default web UI framework design is to use cache, the event only got fired when the first time a non-cached view is accessed. The workflow gets triggered whenever the event is fired and worked correctly. To make the trigger work each time, you could explicitly set EnableViewCache to FALSE in .cfg file. NOTE: Setting EnableViewCache to FALSE is not recommended as this may severely impact performance. 4. Problem: If a business component has code on WriteRecord and the runtime event fires on Writerecord, which occurs first? Solution: Runtime events fire before any script events. 5. Problem: After you triggered workflow from a runtime event, you do not get the row-id of the record on which the event occurred. Solution: Runtime event passes the row-id of the object BO (i.e. primary BC) and not the row-id of the BC. Retrieve the row-id of the active BC using searchspecs (e.g. Active_row-id (process property) = [Id] defined as Type = Expression and BC = BC name) 6. Problem: Encountered the error <Cannot resume Process <x-xxxxx> for Object-id <xxxxxx>. Please verify that the process exists and has a waiting status. Solution: This error typically occurs in the following scenario: (1) A workflow instance is started and paused, waiting for a runtime event (2) The runtime event fires. The workflow instance is resumed and run to completion. (3) The runtime event fires for a second time. Workflow engine tries to resume the workflow instance and fails, since the workflow instance is no longer in a Waiting state. Deleting existing instances will not help. You should ignore the error message and proceed. Steps (1)-(3) need to occur, in that order, in the same user session for the error message to be reported. As a result, the error message would disappear when the application is restarted. Also, Purge only works on stopped/completed instances. In order to delete persisted/incomplete instances, you will need to manually stop the instances first. 7. Problem: How do you access a different business object (BO) from a workflow process? Solution: Workflow architecture restricts the use of 1 BO to a workflow. Use a sub process step to access a different BO. 8. Cannot initiate process definition <process name>

Page 23 of 66

Solution: Verify that the workflow process exists, process status is set to Active, and the process has not expired. 9. Problem: OMS-00107: (: 0) error code = 4300107, system error = 27869, msg1 = Could not find 'Class' named 'Test Order Part A' OMS-00107: (: 0) error code = 4300107, system error = 28078, msg1 = Unable to create the Business Service 'Test Order Part A Solution: Make sure at least one .srf file is copied to SIEBEL_INSTALL\objects\<lang> directory

Page 24 of 66

Examples
Example 1: Attach Activity Plan to an Oppty - Test with Simulator and Runtime Client
Step 1: Configure a New Workflow
In this section you will create a new workflow process that creates an activity plan on an opportunity record and then navigates the end-user to a view to display the new plan. Step 1.1 1.2 1.3 1.4 1.5 1.6 Summary Lock the Oppty (SSE) project Create a new workflow process Add steps to the workflow process Configure the Siebel Operation step Configure the User Interact step Complete the End step

1.1 Open Siebel Tools and lock the project, Oppty (SSE). 1.2 Using the Siebel Tools Object Explorer, locate the Workflow Process objects and create a new record with the following properties: Name = Create Plan Business Object = Opportunity Workflow Mode = Interactive Flow Project = Oppty (SSE) Figure 1. Create a New Workflow Process

Page 25 of 66

1.3 Open the workflow process designer by right-clicking on the new row and choosing Edit Workflow Process. Drag the following objects from the Palette to the Designer: Start Siebel Operation User Interact End Place a connector between the steps as shown:

Figure 2. Add Four Steps and Connectors

Now you will give each step a meaningful name. Select each step and change its name as follows: Step Start: <Id> Siebel Operation: <Id> User Interact: <Id> End: <Id> Name Start Add Activity Plan to Oppty Display Activity Plan End

Page 26 of 66

Figure 3. Give Each Step a Descriptive Name

1.4 Select the Siebel Operation (Add Activity Plan to Oppty) step in the Designer. You need to instruct the workflow about what operation you want to perform (for example, query, insert, or update) and which business component to use for the operation. Using the Properties Windows or WF Steps applet, set the following attributes for the step: Property Business Component Operation Value Activity Plan Insert

Page 27 of 66

Figure 4. Set the Business Component and Operation Type

Select the step and then use the Properties Window or WF Steps Applet to set the Business Component and Operation Type.

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. Select the Siebel Operation Step (Add Activity Plan to Oppty) step and add the fields that must be inserted into the multi-value property window that, by default, is at the bottom of the Tools screen. Three will be tabs for the Field Input Arguments, Search Spec Input Arguments, and Output Arguments.

Page 28 of 66

Figure 5. Right-click a Step to Display Additional Properties for the step

Choose the step and click on View > Windows > Multi Value Property Window to get Multi Value Property Window. Click on Field Input Arguments tab, under Field Name right click to choose New Record to add a new input argument. Notice that the WF Steps an Applet was replaced by the Input Arguments applet. Add a new

Page 29 of 66

record to the Inputs Argument applet.

Field Name Template

Type Literal

Value Any valid activity template name. For HOR, Introductory Sales Call. For SIA , Consumer Account Approval. Oppty Action, is in HOR and SIA.

Figure 6. Supply Required Field Values for the Insert Operation.

Page 30 of 66

1.5 Now you can configure the User Interact step to display a view. Select the User Interact (Display Activity Plan) step. Using the Properties Window, set the following: Property User Interact View Value Opportunity Activity Plan

1.6 Now you must tell the workflow what 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. Select the Connector between the User Interact and End steps. Use the WF Step Branch applet to set the following properties for the branch: Property Type Event Object Type Event Object Event Value Condition BusComp Activity Plan WriteRecordUpdated

Figure 7. User Interact Step Requires a Conditional Branch.

Page 31 of 66

Now that you have finished configuring the workflow, you will validate it for correctness. Right-click inside Designer and choose Validate from the menu. When the Validation dialog opens, press Start. If any error is reported, follow the instructions to fix it and repeat the validation until no errors are reported.

In addition, the user who will be executing the workflow process needs to be set up to have access to the view specified in the User Interact step in the application in order to navigate to the view successfully when the step is invoked

Step 2: Test the Workflow Using the Process Simulator

In this section you will test the new workflow process using the Process Simulator. Step 2.1 2.2 2.3 2.4 Summary Verify Debug Options for launching the Simulation Client Set a process property for the Opportunity Id Launch the Process Simulator Step through the workflow using the Watch Window to monitor status

2.1 The Workflow Designer launches an instance of the Mobile Client executable to perform

Page 32 of 66

the Simulation. From the View menu in Siebel Tools, choose Options and the Debug tab. Review the settings and modify as needed for your environment. Click OK to close the dialog window.

Confirm that the Debug Options are correct by launching a test client using the F5 key. 2.2 Navigate to the Opportunities List view in the session and get the row-id of one record. Return to Siebel Tools. See the process properties in the multi-value property window at the bottom of the Tools screen..

Because this workflow is based on the Opportunity Business Object and attempts to add an Activity Plan to an existing opportunity, you need to specify an opportunity row-id for the simulation otherwise all the opportunities in the query will be updated! Find the Object Id process property in the list applet and set its default value to the Opportunity row-id found in the prior step.

Page 33 of 66

Use the Object Id Default String to provide a row-id for Simulation.

2.3 Close any running Mobile Client sessions now. You will not be able to use the Process Simulator if there are running sessions. Confirm there are no Siebel Client icons in the Task Bar before continuing. Right-click the Workflow Designer and choose Simulate from the menu.

Click the Start button at the top of the Simulation applet. This will launch the Mobile Client executable. Wait for the Simulation In Progress dialog box to appear.

Page 34 of 66

Figure 8. Wait for Simulation in Progress Dialog to Appear before Returning to Siebel Tools.

2.4 Alt-tab to return to the Tools session. To make the session easier to use, you may wish to hide the Object Explorer and Properties Window. You may also wish to resize the Tools window so it not does cover the full display. Figure 9. Simulation View

Page 35 of 66

If the Watch Window is blank, right-click the Simulation applet and choose Watch Window from the menu. This will refresh the display. Click the Next Step button to move between the steps.

After the Opportunity Activity Plan View is displayed in the Mobile Client, note that you cannot reach the End step by pressing the Next button. Since you specified a condition on the branch you must satisfy the condition before reaching the End step. Therefore, using the Mobile Client session make and save a change to the Activity Plan BusComp (for example, change the Planned Start Date or Description). Press Alt-Tab to return to Siebel Tools and click Next to complete the End step. When the last step is reached, the mobile client will display a dialog box reporting Simulation terminated! Please check the watch window for details. Acknowledge the message and Alt-tab to return to Siebel Tools.

Page 36 of 66

Review the status field in the Watch Window. Figure 10. Simulation is Completed

Right-click the Simulation Applet and choose Stop from the menu. This will terminate the Mobile Session.

Step 3: Call the Workflow from the UI using a Runtime Event

Now that youve built and simulated a workflow, you need to decide where and how it will be invoked from the user interface. For the purposes of this example, you will add a button to the Opportunity list applet to invoke the workflow. Step 3.1 3.2 3.3 Summary Add a new pushbutton to the Opportunity List Applet Configure the pushbutton to Invoke a new event Configure the workflow process to run when the event is detected

Page 37 of 66

3.1 Return to your Siebel Tools session. If you have hidden the Object Explorer, press Ctrl-E to re-expose it. You may also hide the Watch Window. Locate the Opportunity list applet and edit its Web Layout for Edit List Mode. Drag a button control to the layout and set its properties as follows: Property Caption - String Override HTML Type MethodInvoked Name Value Create Plan MiniButton EventMethodCreateActivityPlan 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, we set MethodInvoked=CreateActivityPlan) you would need to write a WebApplet_PreCanInvokeMethod script to enable the event or use one of the Applet User Properties such as CanInvokeMethod or Named Method. Preview the applet.

Figure 11. Add a New Button to the UI to Invoke a Synthetic Event

Page 38 of 66

Save the applet changes and compile a new SRF in your client directory. 3.3 Now you will modify the workflow so that it launches whenever the method EventMethodCreateActivityPlan is invoked. Return to the workflow process objects and query for the Create Plan process created earlier. Right-click to edit the process. Select the Connector between the Start and Add Activity Plan to Oppty steps. Set the properties on the branch using the WF Step Branch applet as follows: Property Type Event Object Type Event Object Event Subevent EventCancelFlag Value Condition Applet Opportunity List Applet PreInvokeMethod EventMethodCreateActivityPlan Y

Figure 12. Supply a Start Condition for the Workflow.

Call this workflow whenever the method named EventMethodCreateActivityPla n occurs on the Opportunity List Applet.

Validate the process. If there are no errors, you are ready to deploy the workflow.

Page 39 of 66

Step 4: Deploy and Activate the Workflow Process

Now you are ready to deploy and activate the workflow. These steps are required before the new workflow can be called in the Runtime client. Step 4.1 4.2 4.3 Summary Deploy and Activate the workflow from Tools Enable Monitoring in the Runtime Admin Client Reload Runtime Events in the Runtime Admin Client

4.1 Return to your Siebel Tools session. Double-click the Workflow Process category in the Object Explorer so that the list of workflow processes is displayed. If Create Plan is the not the active row, query for it and select it. Click the Publish/Activate button at the top of the screen. The status of the Create Plan workflow will automatically change from In Progress to Completed. Figure 13. Workflow Deployment.

4.2 Launch the Runtime Administration Client using a short-cut or the F5 key. Connect using SADMIN or an equivalent admin account. Using Site Map, navigate to Administration-Business Process > Workflow Deployment. This will display the following view:

Page 40 of 66

Figure 14. Workflow Deployment View

Now query for Create Plan in the lower applet. One row will be returned for every version that was activated for the process.

4.3 In the lower applet named Active Workflow Process, set the Monitoring-Level to 4-Debug. Now you can verify that a runtime event was created for this workflow. Using Site Map, navigate to Administration Runtime Events > Events. 4.4 From the applet menu, choose Reload Runtime Events. Query for the method you are using to invoke the workflow (Subevent = EventMethodCreateActivityPlan). It should return one row.

Page 41 of 66

Figure 15. A Runtime Event will Invoke the New Workflow.

Step 5: Test the Workflow using the Runtime Client

Now you are ready to call the workflow using the button on the Opportunity list applet. Step 5.1 5.2 5.3 Action Open the Opportunity List View and press the Create Plan button Make and save a change to the Activity Plan Review the workflow process log

5.1 Using the Runtime client, navigate to the Opportunity list view and press the Create Plan button. Figure 16. Test the workflow using the UI.

Invoke the workflow for an opportunity.

Page 42 of 66

5.2 After the workflow navigates you to the Opportunity Activity Plan view, verify that a new plan was created. Edit the plan description and save the change. Figure 17. New Activity Plan was Added to the Opportunity.

5.3 Using Site Map, navigate to Administration Business Process > Workflow Instance Monitor. Query for the Create Plan process. The related instance data will be displayed in the bottom applet. Select the Step Instances tab to review the detail. If your workflow runs without error, you can turn off monitoring by using Administration Business Process > Workflow Deployment. Query for Create Plan in the lower applet. Set Monitoring Level to 0-None

Page 43 of 66

Example 2: Creating Workflow Process Triggered by Runtime Event

In this example, you will create a simple workflow process that is initiated by a runtime event. You will become familiar with elements involved with setting up this workflow and see that the workflow process and runtime events work. Business Scenario: A workflow detects a service request being taken ownership of, then automatically creates an activity of type, Research. It then provides the owner with initial items that can be used to research. Steps 1. Launch Siebel Tools connected to sample database. 2. Create a Test project 3. Create a new Workflow with the following properties: Name: Business Object: Group: Autopersist: Workflow Mode: Project: Description: SR Assigned - Auto Create Activities Service Request (object we are monitoring) <leave blank as it is not required and not used by workflow> No Service Flow Your Test project <Provide something>

4. Open the Workflow Process Designer by right-click on the new row and choose Edit Workflow Process. 5. Drag the following objects from the Palette to the Designer: Start Siebel Operation End 6. Once the icons are on the palette, drag Connector icons () onto the palette and connect from one step to another. NOTE: Ensure that when the connector is highlighted, the end points of the connectors are in red, which means the connector is fully connected to the steps.

Page 44 of 66

7. Rename the steps as shown above. 8. Create a condition on the branch coming from the Start step. Branch Name: SR Owner field updated Type: Condition Event Object Name: BusComp Event: SetFieldValue Event Object: Service Request Subevent: Owner

9. In the Conditions applet, create a condition to check that SR [Owner] field must be set to a value (the SR has to be assigned and can not be left blank). Create a new record and specify the following: Compare to: Operation: Business Component: Business Component Field: Business Component Is Not Null Service Request Owner

In the Values field, leave this blank because we are checking [Owner] field is not null, thus no need to check against any particular value.

Page 45 of 66

Return to the Designer. 10. In the Process Designer, select the Siebel Operation icon and double-click into it to view the OBLE In the Siebel Operation applet, specify the following: Name: Operation: Business Component: Create Research Activity Insert Action

Right-click to open the Fields applet. In the Fields applet, specify the fields to populate when inserting a new record into the Action business component. Please note that when performing inserts into a business component, ensure 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. For our test case, we will populate the following fields: Field Name ------------Type Description Type --------Literal Literal Value ------------------Research Research the following: Siebel Bookshelf, My Oracle Support

Page 46 of 66

In the Process Designer view, do a quick check of all icons and connectors to ensure they are connected. 11. Go back to the All Processes applet. Query for you process. Click the Deploy or Publish button.

12. Activate the workflow. Launch the client. Navigate to Site Map > Administration-Business Process > Workflow Deployment. Query for your workflow. Then, click the Activate button.

Page 47 of 66

Next, Query for your flow in the lower applet (Active Workflow Processes). One row should be returned for every version that was activated with Deployment Status = Active. In the lower applet set the Monitoring Level to 4-Debug.

13. Reload Runtime Events. Do this by going to any of the views in the Site Map > Administration Runtime Events screen, click on the Menu button > Reload Runtime Events menu item. 14. Test the workflow process being invoked by the runtime event: a. Log into application, navigate to Site Map > Service Requests screen > All Service Requests view, create a new service request record and step off the record. b. Re-select the service request record and click on the Activities tab, this will display an activity with the following: Type: Description: Research Will research the following: Siebel Bookshelf, My Oracle Support

c. Once this activity is created, this confirms that the workflow was triggered by the runtime event and the workflow was invoked and executed accordingly.

Page 48 of 66

Example 3: Creating a Service Mode Workflow

The goal of this example is to introduce you to the Workflow Mode [Processing Mode] field and its effect on the workflow process execution. Business Scenario: A new Service Request is created by a user, workflow detects this and performs the following: Automatically assign the new service request to the creator Changes the SR Sub-status to Assigned to reflect the ownership Automatically set the Commit time on the SR depending on the priority Create an activity with a set of steps which the owner can follow towards researching for the SR Steps: 1. Launch Siebel Tools connected to the sample database. 2. Create a Test project 3. Create a new Workflow with the following properties: Name: Business Object: Group: Autopersist: Workflow Mode: Project: Description: New SR Created Service Request (object we are monitoring) <leave blank as it is not required and not used by workflow> No Service Flow Your Test project provide some description

3. Open the Workflow Process Designer by right-clicking on the new row and choosing Edit Workflow Process. 4. Drag the following objects from the Palette to the Designer: Start Decision Point Siebel Operation Siebel Operation Siebel Operation Siebel Operation Siebel Operation End 5. Once the icons are on the palette, arrange them as seen in the diagram below, then drag Connector icons () onto the palette and connect from one step to another.

Make sure that when the connector is highlighted, the end points of the connectors are in red color, which means the connector is fully connected to the steps. Double-click on each step and branch to rename them as is shown in the diagram below:

Page 49 of 66

6. Right-click the Check SR Priority branch coming from the Start step and click the Show Properties choice on the popup menu. Branch Name: Type: Event Object Name: Event: Event Object: Check SR Priority Condition BusComp WriteRecordNew Service Request

This information is to have workflow run when a new Service Request is being created.

7. Select the Decision Point step. If not done yet, set the Name = Check SR Priority. This step checks the value of the Service Request [Priority] field.

Page 50 of 66

Drag 5 new connectors to the decision step if you have not done so and connect one end to the decision step and the other end to one of the Siebel Operation steps. Set the Type field to Condition. Select the Connector, right click, pick Edit Conditions and define the Conditions: 4 corresponding to a Priority value. Depending on the priority value, the workflow sets a different value for the Commit Time. 1 is for default when there isnt a match for the priority, i.e., Priority not set. In this case, dont set Commit Time, just create the activity.

The 5 records would look like the following: Priority 1-ASAP

Page 51 of 66

Priority 2-High

Page 52 of 66

Priority 3-Medium

Priority 4-Low

Page 53 of 66

If Priority not set

There are no conditions on this branch. Once all conditions and values are set, return to the Designer canvas. 8. Select the Siebel Operation step named Set Commit Time In 1 Hour that comes from the Prio 1 branch. In this step, we 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. Set the following fields and values as follows. Click on the step and choose the Field Inputs Arguments tab in the Multi Value Property window. Insert new records into the applet and fill in the values as shown below.

Page 54 of 66

9. Select the Siebel Operation step named Set Commit Time In 2 Hours that comes from the Prio 2 branch. In this step, we 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. Set the following fields and values as follows.

Page 55 of 66

10. Select the Siebel Operation step named Set Commit Time In 24 Hours that comes from the Prio 3 branch. In this step, we 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. Set the following fields and values as follows.

Page 56 of 66

11. Select the Siebel Operation step named Set Commit Time In 48 Hours that comes from the Prio 4 branch. In this step, we 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. Set the following fields and values as follows. .

12. Select the Siebel Operation step named Create Plan of Action. This step will create an activity for the service request with a set of actions that owner can follow. Set the following fields and values as follows:

Page 57 of 66

The Comments field value can contain any text of your preference, such as below:

Plan of Action: 1. Verify if 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 if there is anything that can be tested for the behavior. 4. Request logs where appropriate and applicable. 5. If any references found in Bookshelf, provide them to customer for review.

13. Verify the workflow process works in real-time, invoked by runtime event. Publish and activate the process from Siebel Tools. 14. Since the workflow process has a runtime event that initiates the workflow, the personalization data and cache needs to be updated via reloading runtime events. Do this by

Page 58 of 66

going to any of the views in the Site Map > Administration Runtime Events screen, click on the menu button > Reload Runtime Events menu item.

15. Test the workflow process being invoked by the runtime event: Log into application, navigate to Site Map > Service Requests > All Service Requests view, create a new service request record, set a value for [Priority] field or leave it blank. Save the record. When you step off the record, you will notice the client application freeze or delay slightly with an hourglass. Re-select the service request record and check the [Owner], [Substatus] and [Date Committed] fields. Verify they have been populated correctly. Check the Service Request > Activities view for the new activity. Click on the Activities tab, this will display the new activity record. View the Comments field.

16. Test out a few scenarios by creating service request records with different [Priority] values and see how the workflow process decision step behaves.

Page 59 of 66

Example 4: Runtime Event Workflow with User Interact Step to Navigate User to a View
The goal of this example is to create a simple workflow process that is initiated by runtime event and takes you to a view. This is an Interactive Flow. Business Scenario: A new Service Request is created by a user, workflow detects this and performs the following: a. Automatically assign it the new service request to the creator b. Changes the SR Sub-Status to Assigned to reflect the ownership c. Automatically set the Commit time on the SR depending on the priority d. Create an activity with a set of steps which owner can follow towards researching for the SR. e. Navigates the user to the Service Request > Activities view to display the newly created activity. Steps 1. Launch Siebel Tools connected to sample or server database. 2. Navigate to Workflow Process. For this example, we will re-use the workflow process from the previous example and modify it slightly. 3. Select the workflow process New SR Created. Revise this workflow process for an In Progress version. For the In Progress version, rename it to New SR Created - Take User to SR Activity view Change the Workflow Mode to Interactive Flow 4. Deactivate all previous workflow processes based on Business Object = Service Request, so that they do not run or interfere with invocation of the workflow for this lab. 5. In the Process Designer, perform the following: a. Highlight the User Interact icon, drag and drop it into the Process Designer in between the steps Create Plan of Action Activity and End Workflow. b. Then, 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 follows:

Page 60 of 66

6. Select the User Interact step in the Process Designer. In the User Interact step details view, make the following modifications: a. Change the Name of the step to Display SR Activities View b. For the View field, bring up the pick applet and select Service Request Detail View, click OK on the User Interact View pick applet. If you are not sure which is the correct view corresponding to the UI, this can be checked by going to the Service Request screen > All Service Requests view > Activities view tab, then perform Help > About View. This will show the views configuration and the repository view name. c. Create an event coming from the User Interact step.

7. Deploy the workflow. Go to the Process list applet and click the Deploy or Publish button. 8. Open the client and navigate to Administration-Business Process > Workflow Deployment. Query for the New SR Take User to Activity. Press the activate button. In the lower applet Active Workflow Processes query for the same process. One row will be returned for every version that was activated. Make sure only the latest version is active. Set the Monitoring Level to 4-Debug. In the upper applet menu choose Reload Runtime Events.

In addition, the user who will be executing the workflow process needs to be set up to have access to the view specified in the User Interact step in the application in order to navigate to the view successfully when the step is invoked.
9. Test the New SR Created - Take User to Activity workflow process as follows: a. Log into application, navigate to the Service Request list view

Page 61 of 66

b. Create a new service request and specify a Priority level and step off the record. Note that the application freezes with an hourglass. Afterwards, the [Owner], [Sub-Status] and [Date Committed] fields are populated and a new activity is created. Additionally, the application automatically navigates the user to the Service Request > Activities view to display the new activity record. Also verify that the Workflow Process Log view has a process instances for New SR Created Take User to Activity.

Page 62 of 66

Example 5: Externalize parameters to be used by workflow

The purpose of this example is to provide a framework to externalize workflow parameters such that workflows using business services that interact with external systems do not require repository changes when migrating between development, test and production Siebel instances.

Overview
Workflows 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 workflow using the EAI HTTP Transport business service would point to an integrated test systems external URL in the testing instance and point to a production external system URL in the production instance. Basic idea for the design of the framework is to store all the Input Arguments of a business service that are in use in a given workflow into a file. In the Service_PreInvokeMethod Event of Business Service, add the script to read values of these substitutable Input Arguments of a business service in use in a workflow from a file and set the Input Argument of the business service with values read from a file. This way, the file residing on production Siebel instance server(s) will contain values for production external systems, and the file residing on development or test Siebel instance server(s) will contain values for development test external systems. In other words, Input Arguments 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 file, with a particular name, on each Siebel server being available for reading. Otherwise, the business service will fail and the workflow will throw an error at that business service step, which is a 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 arguments value matches that 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 Following are key requirements of framework for externalizing workflow parameters for certain business services: Framework should make migration of repository workflows between development, test, and production Siebel instances transparent. for example, workflows should no longer require any changes during migration between various Siebel instances. Framework should support current business services as well as future requirements. Framework should support all usage scenarios of a given business service used in various workflows. 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 repository between development, test, and production Siebel instances. EAI HTTP Transport o SendandReceive Method Input Argument(s) HTTPRequestURLTemplate EAI SQL Adapter

Page 63 of 66

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 above two services, the Input Arguments mentioned above for respective business services need to be supplied in the Workflow step definition where these services are used. The following is an arbitrary XML Hierarchy file named ebizint.xml containing Input Arguments for above two services and their values. The parameters under Finance, HR, and UAN are for illustration purpose only. 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 XML Hierarchy is completely arbitrary, one shown here is for illustration purpose only.

Given the above structure of the file, the following eScript code can be added to the Service_PreInvokeMethod event of the two services mentioned.

Page 64 of 66

Page 65 of 66

Note the location of the ebizint.xml file. In a Windows environment, this file should be present on C:\ on all Siebel server(s) where above services could be invoked. The file needs to be made read-only for the user id under which the Siebel service runs and write access should be denied to all users. There is no other ongoing maintenance required for this file. Whenever the values in the file changes, for example, external system URL, this file needs to be updated with the correct values on all Siebel Servers. The following is an example usage of the EAI HTTP Transport business service, which has the above eScript code in the Service_PreInvokeMethod event.

Concepts shown in this example could be easily 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.

Page 66 of 66