Professional Documents
Culture Documents
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.
Workflow
Processes
Activity
Template
State Model
Assignment
Manager
SmartScript
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 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.
7.0 Flow. A 7.0 workflow process provides backward compatibility for existing
Siebel 7 (pre-7.7) workflows.
Page 4 of 56
2. Define Processes
in Siebel Workflow
4. Validate and
Simulate Process
5. Migrate to
Production
6. Monitor Process
Key Advantages
Limitations
Page 5 of 56
Workflow
Process
Workflow
Policies
Siebel Script
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.
Actions
Events
Workflow Policies
Run-time Events
Siebel Tools
Object Events
Database
Operation
Invoke a Service
Pause a Workflow
Rules
Scripted Business
Services
Page 7 of 56
Type
Description
When Useful
Workflow
Policies
Runtime
Events
Raised by OM
Belong to 3 objects:
Application, Applet,
Business
Component
Tools
Object
Events
Trigger based on
database changes
Configurable from
Administrative
interface
Raised by OM
Belong to 4 objects:
Application, Applet,
Business
Component,
Business Service
Limitations
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
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
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
S_ESCL_REQ
Triggers fire
Siebel
Database
Reads records
Workflow
Process Mgr
Server
Request Broker
Workflow
Monitor Agent
Type
Description
Workflow
Decision
Step
Scripted
Business
Services
Limitations
Need a simple
articulation of
whether one or
more alternative
actions in flow
should be taken
Conditional expressions
lack support for some
key operators including:
o AND
o OR
o Order of
precedence
control (such as
parentheses)
Undermine readability
and simplicity of
workflow by hiding logic
within a service
Workflow
decision step
semantics not
sufficiently
expressive to
encapsulate
decision criteria
Page 9 of 56
Other
Specialized
Rule
Frameworks
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.
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
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
Database
Operation
Wait
Need to execute
potentially
complex, but
reusable set of
logic
Need to execute
simple record
operations within
the workflow
Useful to support
time-based
escalations or
long running
flows that may
last for days or
weeks for
example, waiting
for a customer
response
Page 11 of 56
2.
DataTransfer
GetActiveViewProp
QueueMethod
TryMockMethod.
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
Page 12 of 56
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
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
Page 14 of 56
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.
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.
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.
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
3. Activate (writes
definition to
runtime tables)
Siebel Tools
Workflow
Import/export
utility
XML
Repository
tables
1.
Tools
Export
2. Tools
Import
Runtime tables
Repository
tables
Runtime tables
Production Test
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 12:
Page 17 of 56
Siebel Tools
Siebel Client
- 2. Client-side
Workflow export
utility
import
XML
Repository
tables
1.
Tools
E
t
2. Clientside
Tools
Repository
tables
Runtime tables
Runtime tables
- Workflow V2
Test DB
Production Test
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.
ii.
iii.
iv.
v.
vi.
vii.
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.
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.
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 <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>
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
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
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
Now you will give each step a meaningful name. Select each step and change its name as
follows:
Step
Name
Start: <Id>
Siebel Operation: <Id>
User Interact: <Id>
End: <Id>
Start
Add Activity Plan to Oppty
Display Activity Plan
End
Page 22 of 56
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
Business Component
Operation
Value
Activity Plan
Insert
Page 23 of 56
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
Notice that the WF Steps applet was replaced by the Input Arguments applet. Add a new
record to the Inputs Argument applet.
Field Name
Template
Type
Literal
Value
Any valid activity template
name. For HOR 7.7,
Introductory Sales Call. For
SIA 7.7, Consumer Account
Approval.
Page 25 of 56
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
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
Page 26 of 56
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.
Summary
Verify Debug Options for launching the Simulation Client
Set a process property for the Opportunity Id
Launch the 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
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
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
Page 31 of 56
Right-click the Simulation Applet and choose Stop from the menu. This will terminate the Mobile
Session.
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
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.
Preview the applet.
Page 32 of 56
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
Page 33 of 56
Validate the process. If there are no errors, you are ready to deploy the workflow.
Summary
Deploy the workflow from Tools
Activate the Deployed Workflow in the Runtime Admin Client
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 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
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
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
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 17. Test the workflow using the UI.
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
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 39 of 56
Workflow Mode:
Project:
Description:
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 40 of 56
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 41 of 56
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
Description
Literal
Literal
Research
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:
Description:
Research
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
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.
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
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.
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 isnt a match for the priority, i.e., Priority not set. In this case,
dont set Commit Time, just create the activity.
Page 45 of 56
Priority 1-ASAP
Priority 2-High
Page 46 of 56
Priority 3-Medium
Priority 4-Low
Page 47 of 56
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.
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 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 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.
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.
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