Siebel 7.

7 Workflow

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

Page 2 of 56
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 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
Activity
State Model
Template

Assignment SmartScript
Manager

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 56
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 Siebel’s 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 Siebel’s 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.

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 4 of 56
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 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.

Table 1. Siebel Workflow Process Framework versus Other Siebel Mechanisms

Framework Key Advantages Limitations

Page 5 of 56
Workflow • Visual representation of business Semantics for control of flow not as
Process logic is relatively to understand rich as scripting. Specific limitations
and maintain include:

• Remote synchronous and • Limited control of flow for

asynchronous execution enables
broad horizontal scalability and
long running transactions
Workflow • Respond to database events
Policies regardless of whether they’re
initiated by an OM or non-OM
component
• May get higher transaction
throughput on a given set of
hardware for simple transactions
Siebel Script • Familiar to most developers
• Complete set of semantics/ highly
flexible
iterating through record sets,
etc.
• 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

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:
Figure 4. Palette
Start – defines the beginning of a process
Decision – defines branching in the workflow
Business Service – performs custom or pre-built actions
Sub-process – calls another process
Siebel Operation – updates the Siebel database
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
Exception – defines a branch taken outside of the normal flow,
when an exception occurs.

The Siebel Workflow User’s 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 (see Figure 4):

Page 6 of 56
 • 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 business component data,
processprocess 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.

Figure 5. Workflow Building Blocks

Events Actions

• Workflow Policies • Database

Operation
• Run-time Events
• Invoke a Service
• Siebel Tools
• Pause a Workflow
Object Events

Rules
• Workflow Decision Step
• Scripted Business
Services
• Other Specialized Rule

Events – Invoking Siebel Workflow Processes

There are basically three ways to invoke a workflow workflow process, through workflow
policiesworkflow policies, run-time events, and Siebel Tools object events.

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
updates, manual changes from the user interface, assignment manager assignments and Siebel
remote synchronization.

Table 2. Invoking Workflow

Page 7 of 56
Type Description When Useful Limitations

Workflow • Trigger based on • Need to detect and • Changes require database

Policies database changes react to data changes downtime
made outside of the
object managerObject • Relatively complex to
Manager (OM) – for configure
example, by Siebel
Remote or EIM
Runtime • Raised by OM • Need to implement • Can’t directly respond to
Events basic entry point for a event by scripting against
• Belong to 3 objects: workflow or simple the event object
Application, Applet, custom action
Business • Can be more difficult to
Component • Need to avoid pass event context to
distributing .srf files – business logic
• Configurable from e.g., because of
Administrative burden on mobile • Don’t trap data changes
interface users made by non OM
components
“Tools” • Raised by OM • Need flexibility to write • Changes must be
Object script directly in distributed through new .srf
Events • Belong to 4 objects: response to an event file
Application, Applet,
Business • Need access to an • Does not trap data changes
Component, applet event that’s made by non OM
Business Service only exposed in Siebel components
Tools
• 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 6, displays Workflow Policy architecture.

• 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).

Page 8 of 56
 • 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 6 Workflow Policies

End-user activity or server process

EIM
S_ESCL_REQ

Generate Triggers fire

triggers

Create triggers Siebel

Database
Reads records

Workflow Server Workflow

Process Mgr Request Broker Monitor Agent

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

Type Description When Useful Limitations

Workflow • Kind of step in a Workflow that • Need a simple • Conditional expressions

Decision arbitrates between one or articulation of lack support for some
Step more alternative branches in a whether one or key operators including:
flow more alternative o AND
actions in flow o OR
• Each branch out of decision should be taken o Order of
step has one or more precedence
conditions – if all evaluate to control (such as
TRUE for the branch the flow parentheses)
will continue down the branch
Scripted • Script within a business • Workflow • Undermine readability
Business service Action step that decision step and simplicity of
Services evaluates a potentially semantics not workflow by hiding logic
complex set of inputs and sufficiently within a service
returns a simplified output that expressive to
can be evaluated by a encapsulate
workflow decision step decision criteria

Page 9 of 56
Other • Other rule frameworks that
Specialized may be leveraged directly or
Rule indirectly by a workflow
Frameworks o Personalization Rules
o Assignment Rules

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.
The Compose Condition Criteria dialog box is shown in Figure 7. 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 7. Decision Criteria

Page 10 of 56
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

Type Description When Useful Limitations

Business • Workflow Step • Need to execute • Creating and destroying

Service Step that invokes a potentially business services can be
method of complex, but expensive – overhead can be
business service reusable set of reduced through caching
logic
• Business service • Incorporating too much logic with
may be a pre- a business service may limit it’s
built Siebel reusability and the transparency
service or a of the workflow
customer defined
(scripted)
business service
Database • Workflow step • Need to execute • Possible to update multiple
Operation that performs simple record records based on a search
Inserts, Updates operations within specification, but it’s not possible
and Queries the workflow to retrieve and iterate through a
against Siebel set of records such that
business subsequent workflow actions can
components execute for each record
Wait • Puts the workflow • Useful to support • Releasing event must be
into a holding time-based triggered through the OM
pattern until a escalations or
releasing event is long running
fired or a timeout flows that may
occurs last for days or
weeks – for
example, waiting
for a customer
response

Actions: 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 (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 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:

Page 11 of 56
 • 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:
• ExecuteReport
• DelOne
• DownloadReport
• GrantRoleAccess2Report
• GrantUserAccess2Report
• PrintReport
• RunAndEmailReport
• ScheduleReport
• SyncOne

Page 12 of 56
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.

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.

The example below shows how you can define a timeout based on time defined as literal values
in input arguments.

Figure 8. Wait Step

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

• 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”.

Page 13 of 56
 Figure 9. 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 10. Process Property Used as an Output Argument

Developing Workflows in Siebel Tools

The following section brings out some points with Siebel 7.7 Workflow in Siebel Tools and
developing on a local database.

Workflow is a repository object. Workflow belongs to a project. In Siebel 7.7, 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
• Merge – workflow does not participate in the 3-way merge. When workflow definitions
are imported into the repository, they maintain versioning provided by workflow
• Object Comparison – disabled for Siebel 7.7
• 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 object 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

Page 14 of 56
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).

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.

Step 4: Test and Simulate Workflow Processes

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

Page 15 of 56
Simulator
Most workflows can be tested using the simulator. Developers can use the workflow simulator
hosted in Siebel Tools to debug workflows. To use the 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. In Siebel 7.7, developers can test interactive workflow and
runtime-event-based workflows using the simulator. Long running workflows and those workflows
that invoke server components cannot be debugged using the 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.

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 condtion evaluation, business
service invocation, business component insert/update.
Refer to Siebel Bookshelf 7.7 > Siebel Business Process Designer Administration Guide > For
Administrators: Administering Workflow Processes > Troubleshooting Workflow Processes >
About Tracing and Event Log Levels > 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 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 button in Siebel Tools.
2. 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 export-import utility – this utility allows incremental migration of workflow definitions.
Using Siebel Tools, one would export the workflow from one environment and import the

Page 16 of 56
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.

Figure 11. Incremental Deployment Using Import/Export

Siebel Client
Siebel Tools
3. Activate (writes
Workflow
Import/export definition to
utility runtime tables)

XML

1. 2. Tools
Repository Tools Import Repository
tables Export tables

Runtime tables Runtime tables

Test DB Production Test

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 12:

Page 17 of 56
 Figure 12. Incremental Deployment Using Siebel Tools and Client

Siebel Tools Siebel Client

Workflow export
- 2. Client-side
utility
import

XML
2. Client-
1. side
Repository Tools Tools Repository
tables E t tables

Runtime tables Runtime tables

- Workflow V2

Test DB Production Test

Incremental deployment using Export utility from

Siebel Tools and Import utility from Siebel Client

Step 6: Monitor Processes

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 FAQ 1482 on SupportWeb.
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.
Such levels of monitoring affect performance of the workflow engine. Hence such
settings should be used for troubleshooting purpose only.

Page 18 of 56
 3. You can run the workflow process from the business service simulator using the business
service Workflow Process Manager. Here are the steps:

i. Navigate to the Site Map > Administration - Business Service > Simulator.
ii. In the top applet, create a new record and set the following fields:
Service Name: Workflow Process Manager
Method Name: RunProcess
Iterations: 1
iii. 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).
iv. 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>
v. Repeat above step for any parameter that should be passed to the process,
especially “RowId” if needed.
vi. Click the OK button in the multi-value applet opened in step iii.
vii. Click the Run button in the top applet of the Simulator view.

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 applet of the Workflow Process Instance Admin view. 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.

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, StpExec, PrcExec) on. See the Business Process
Administration Guide in Siebel Bookshelf 7.7 for procedures on how to do this.

2. Problem: You revised the workflow process and reactiviated it, but somehow the
previous workflow information was read.
Solution: For workflows running in the Workflow Process Manager server component, reset
parameter <Workflow Version Checking Interval>. By default it is 60 minutes.

3. Problem: When workflow is triggered by runtime event Display Applet, the workflow is
triggered the first time but not subsequently? Why?

Page 19 of 56
 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 no-cached view is
accessed. The workflow got triggered whenever the event is fired and worked correctly. To
make field still work in this scenario, you could explicitly set EnableViewCache to FALSE in
.cfg file.

4. Problem: If a buscomp has code on WriteRecord and the runtime event fires on
Writerecord, which occurs first?
Solution: WriteRecord runtime event is in essence a Post-WriteRecord event and will be fired
AFTER the buscomp code is executed.

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 <x-
xxxxx>. 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 re-
started.

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>

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 20 of 56
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 Summary
1.1 Lock the Oppty (SSE) project
1.2 Create a new workflow process

1.3 Add steps to the workflow process

1.4 Configure the Siebel Operation step
1.5 Configure the User Interact step
1.6 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

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:

Page 21 of 56
 • 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 Name

Start: <Id> Start

Siebel Operation: <Id> Add Activity Plan to Oppty
User Interact: <Id> Display Activity Plan
End: <Id> End

Page 22 of 56
 Figure 3. Give Each Step a Descriptive Name

The name of
Step may be
changed in the
Properties
Window OR in
the WF Steps
Applet.

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 Value
Business Component Activity Plan
Operation Insert

Page 23 of 56
 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 right-click to display the
menu. Note there are three choices at the bottom of the menu for configuring a Siebel Operation
step. Choose the Show Fields option from the menu.

Page 24 of 56
 Figure 5. Right-click a Step to Display Additional Properties for the Step.

Notice that the WF Steps applet was replaced by the Input Arguments applet. Add a new
record to the Inputs Argument applet.

Field Name Type Value

Template Literal Any valid activity template
name. For HOR 7.7,
Introductory Sales Call. For
SIA 7.7, Consumer Account
Approval.

Page 25 of 56
 Figure 6. Supply Required Field Values for the Insert Operation.

After choosing Show

Fields, Tools displays
the Input Arguments
applet.

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 or the WF Steps applet, set the
following:

Property Value
User Interact View 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 Value
Type Condition
Event Object Type BusComp
Event Object Activity Plan
Event WriteRecordUpdated

Page 26 of 56
 Figure 7. User Interact Step Requires a Conditional Branch.

Choose the branch

and set the condition
properties in the WF
Step Branch applet.

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.

Step 2: Test the Workflow Using the Simulator

In this section you will test the new workflow process using the Simulator.

Step Summary
2.1 Verify Debug Options for launching the Simulation Client
2.2 Set a process property for the Opportunity Id
2.3 Launch the Simulator

2.4 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
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.

Page 27 of 56
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 and right-click the Workflow Designer and choose Show Process
Properties from the menu. Note that the bottom applet now displays the WF Process Props.

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. 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 28 of 56
 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 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 29 of 56
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 30 of 56
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.

Review the status field in the Watch Window.

Figure 10. Simulation is Completed

If Status is COMPLETE. The workflow

ran without error.

Page 31 of 56
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 you’ve 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 Summary
3.1 Add a new pushbutton to the Opportunity List Applet
3.2 Configure the pushbutton to Invoke a new event
3.3 Configure the workflow process to run when the event is detected

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 Value
Caption - String Override Create Plan
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, we set MethodInvoked=CreateActivityPlan) you would need to write a
WebApplet_PreCanInvokeMethod script to enable the event.

Preview the applet.

Page 32 of 56
 Figure 11. Add a New Button to the UI to Invoke a Synthetic Event

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 Value
Type Condition
Event Object Type Applet
Event Object Opportunity List Applet
Event PreInvokeMethod
Subevent EventMethodCreateActivityPlan
EventCancelFlag Y

Page 33 of 56
 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.

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 Summary
4.1 Deploy the workflow from Tools
4.2 Activate the Deployed Workflow in the Runtime Admin Client
4.3 Enable Monitoring in the Runtime Admin Client
4.4 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 Deploy button at the top of the screen. The status of the Create Plan workflow will
automatically change from In Progress to Completed.

Page 34 of 56
 Figure 13. Workflow Deployment.

After the
process is
deployed, the
Status field
changes to

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 35 of 56
 Figure 14. Workflow Deployment View

Query for the Create Plan process in the top applet named Repository Workflow Process. One
row should be returned. Click the Activate button in the top applet.

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

Page 36 of 56
Figure 15. You Must Activate a Workflow After Deploying from Siebel Tools.

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.

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

Page 37 of 56
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 Action
5.1 Open the Opportunity List View and press the Create Plan button
5.2 Make and save a change to the Activity Plan
5.3 Review the workflow process log

5.1 Using the Runtime client, navigate to the Opportunity list view and press the Create Plan
button.

Figure 17. Test the workflow using the UI.

Invoke the workflow for

an opportunity.

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.

Page 38 of 56
 Figure 18. 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

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: SR Assigned - Auto Create Activities

Business Object: Service Request (object we are monitoring)
Group: <leave blank as it is not required and not used by workflow>
Autopersist: No

Page 39 of 56
Workflow Mode: Service Flow
Project: Your Test project
Description: <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.

7. Rename the steps as shown above.

Page 40 of 56
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: Business Component

Operation: Is Not Null
Business Component: Service Request
Business Component Field: 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.

Return to the Designer.

10. In the Process Designer, select the Siebel Operation icon and double-click into it to view the
OBLE

Page 41 of 56
In the Siebel Operation applet, specify the following:

Name: Create Research Activity

Operation: Insert
Business Component: 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 Value

------------- --------- -------------------

Type Literal Research

Description Literal Research the following: Siebel Bookshelf, SupportWeb

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 button.

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

Next, Query for your flow in the lower applet (Active Workflow Processes). One row should be
returned for every version that was activated.

In the lower applet set the Monitoring Level to 4-Debug.

13. Test the workflow process being invoked by the runtime event:

a. 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: Research
Description: Will research the following: Siebel Bookshelf, SupportWeb

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 43 of 56
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: New SR Created

Business Object: Service Request (object we are monitoring)
Group: <leave blank as it is not required and not used by workflow>
Autopersist: No
Workflow Mode: Service Flow
Project: Your Test project
Description: 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.

NOTE: To make the connectors bended, highlight the connector > right-click > Add Point. Then
click on the new point (small white square box) and drag it to the desired location in the Process
Designer.

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 44 of 56
6. Click on the New SR Created by User step.

Right-click and select Show Branches. Specify the following information:

Branch Name: Check SR Priority

Type: Condition
Event Object Name: BusComp
Event: WriteRecordNew
Event Object: 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.

Right click and pick Show Branches, create 5 new records if you have not done so. 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 isn’t a match for the priority, i.e., Priority not set. In this case,
don’t set Commit Time, just create the activity.

The 5 records would look like the following:

Page 45 of 56
Priority 1-ASAP

Priority 2-High

Page 46 of 56
Priority 3-Medium

Priority 4-Low

Page 47 of 56
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. To set the fields, right-click on the Operation step
and choose the Show Fields option.

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. To set the Fields, right-click on the Operation step
and select the Show Fields option.

Page 48 of 56
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. To set the Fields, right-click on the Operation step
and select the Show Fields option.

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. To set the Fields, right click on the Operation step
and select the Show Fields.

12. 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 owner can follow. Set the following
fields and values as follows:

Page 49 of 56
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.

Deploy the workflow from Tools

Activate the workflow process by clicking on the Activate button in the client.

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
going to any of the views in the Runtime Event Administration screen, select the applet menu
button > Reload Runtime Events menu item.

15. Test the workflow process being invoked by the runtime event:

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.

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

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 51 of 56
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 view’s 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 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
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”.

9. 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 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.

Page 52 of 56
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”.

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 system’s 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 argument’s 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.

Page 53 of 56
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
o 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 54 of 56
Page 55 of 56
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 56 of 56