Troubleshooting Steps: How to troubleshoot workflow processes invoked by

Run-time events?
Siebel Version 7.x and 8.x provides a simplified event mechanism for automating business processes
using run-time events. Real-time monitoring of events is based on events that occur at the business
object layer minimizing the need for custom scripting and workflow policy invocation. Run-time events can
be specified in a Start step to invoke a workflow process or in a Wait step or User Interact step to resume
a workflow process.

The following document provides steps on how to troubleshoot such behaviors, by giving an example
workflow as illustration. The example here is a workflow process invoked by runtime events, initiated to
run when the Service Request [Owner] field is populate with a value. The workflow then executes, takes
the user to a view and then wait for another runtime event to occur on the view, this would resume the
workflow process. Upon workflow process resumption, the workflow will create an activity and then end.

1. The following is the sample workflow process record created in Siebel Tools:

The workflow process steps are:

2. The runtime event to initiate the workflow is specified in this branch of the workflow process called “sr
owner updated”:

3. The runtime event to resume the workflow is specified in this branch of the workflow process called
“next”:

4. After setting up this workflow process, deploy the workflow process from Siebel Tools by using the
Siebel Tools > Workflow Processes > select the workflow > click the {Deploy} button.
5. Once the workflow process has been deployed, activate the workflow process by navigating to the
Siebel Client application > Site Map > Administration – Business Process screen > Workflow Deployment
view > Repository Workflow Process list applet > query for the workflow process in the Name field. Then,
Select the workflow process and activate it by clicking the {Activate} button:

6. In the Active Workflow Process list applet, query for the workflow process’ name, it should return an
active version of the workflow as follows:

7. For this active workflow process, get the record’s ROW_ID value, by selecting the applet’s menu
button > select “About Record”:

8. When a runtime event driven workflow process is activated, the runtime event data is a) created if this
runtime event does not exist, b) updated if this runtime event already exists.
9. Verify the runtime event data for this workflow process is created correctly. Do this by navigating to
Siebel Client application > Site Map > Administration – Runtime Events screen > Evens view > query for
the runtime event data as specified in the workflow process branch connecting from the start step. An
example based on the above workflow process is:

For reference the above fields should have the same values as those specified in the workflow process
branch is:

10. For the runtime event record, drill into the hyperlink for [Action Set Name] field, this will take the user
to the Action Set Details view.

In this view, inspect the data in the More Info applet:

Business Service Name: Workflow Process Manager ; business service to run the workflow
Business Service Method: RunProcess ; business service method to run a workflow
Business Service Context: "ProcessId", "1-4PJ0" ; the workflow Process to run, identified by
ProcessId, which is also the same as the Active workflow process’ ROW_ID.

Note that the ProcessId value is the ROW_ID of the Active workflow process which is initiated by this
runtime event. Ensure this information in the Runtime Event > Action Set > More Info applet matches up
with the Active workflow process.

If the workflow process also has a runtime event to resume the workflow at a particular step, verify the
runtime event generated for this workflow step. In this example workflow, there is a runtime event that
resumes the workflow from a particular view. Navigate to Site Map > Administration – Runtime Event
screen > Events > query for the following:

Again, this information should match the runtime event information specified in the branch after the
workflow User Interact step:

11. For the runtime event record, drill into the hyperlink for [Action Set Name] field. In the More Info
applet, verify the following:
Note the following fields:

Business Service Name: Workflow Process Manager

Business Service Method: ResumeProcess
Business Service Context: "ProcessId", "1-4PJ0", "StepId", "1-4N39"

This indicates the workflow process and step to resume from. Note the ProcessId is the ROW_ID of the
active version of the workflow process. The StepId value is the ROW_ID of the step that the workflow
should resume from. To verify the step is correct, navigate to Siebel Tools > Workflow Process > select
the deployed workflow process > right-click > Edit Workflow Process > select any step to display the
Workflow Steps applet > in the Workflow Steps applet, query for the following in the [Name] field:

Execute this query and verify the step returned is the step which has the runtime event branch associated
to it:

12. Once the runtime event data has been created and verified that they are associated to the correct
workflow, then reload runtime event data for the object manager by selecting Menu > Reload Runtime
Events.
13. Test the workflow process and runtime event by navigating to the screen/view/applet, select the data
and perform the event which should invoke the workflow process.

In this case, the workflow process’ Business Object is “Service Request” and the event is on Business
Component “Service Request”. The user would navigate to Site Map > Service Request screen > Service
Request List View > select a service request. Then, the user would populate the Service Request
[Owner] field with a user’s LoginId. This would trigger the runtime event and initiate the workflow process
to run. The workflow process would navigate the user to the “Service Request Detail View”, which the
user would see the Service Request Activities list.

From the “Service Request Detail View”, if the user updates the same service request’s [Status] field, this
would cause the workflow to resume and then create an activity into the Service Request > Activity list
applet. The workflow would then end.

The following are some common symptoms and error messages if the runtime event driven workflow
process does not work correctly as expected:

Scenario # 1: The workflow process has been deployed and activated. The user goes to the
Administration – Runtime Events screen > Events view > query for the event > drill into the Action
Set Name > the Actions list applet shows multiple actions associated to the same runtime event.
An example is as follows:

Reasons for this behavior:

This can occur if the same runtime event is specified in multiple workflow processes:

a. The same runtime event is specified/used in different Active workflow processes.

b. The same runtime event is specified/used in multiple versions of the workflow processes, some of
which can be Outdated versions of the same workflow process.

Diagnostic Steps:

1. Navigate to the Site Map > Administration – Runtime Events screen > Events view for the event >
Action Set view > Actions applet.

2. In the Actions applet, select each of the Action record and inspect the following fields and values in the
More Info applet:

Business Service Name

Business Service Method
Business Service Context

These fields may have different values for each Action record.

Verify if each ProcessId value (and StepId value, if any) in the Business Service Context field is for:
a. Another completely different workflow process that is active. This can occur if the same runtime event
is used to initiate different workflow processes.

If the action is associated to multiple active workflow processes, each workflow process will get executed
in sequential order according to numerical value in the action record [Sequence] field. If no particular
order is specified, then the action is executed according to the action with the lower ROW_ID value.

b. Or, it is for the same workflow process which is outdated. This can occur if the same workflow process
has been revised, re-deployed and activated. The previous version gets updated to Status = “Outdated”,
but its runtime event action information is not deleted.

If the action is associated to a workflow process that is outdated, the particular action (workflow) will not
get executed.

3. Verify that event information and workflow process ROW_IDs are correct in Action and Action Set
parameters shown in Run-time Administration views. Run-time events created automatically by workflow
activation have a sequence of –1 in the Events applet. When a workflow process is deleted, the Run-time
Event > Event record remains, however, the Action associated to this event is deleted. When an existing
workflow process using run-time events is revised and then activated, the Run-time Event data is updated
as follows:

Run-time Event > Event record remains the same

Action Set Name remains the same
Action Set Name > Actions applet > Name field: Action Id gets updated
Action Set Name > More Info > Business Service Context: Process Id of workflow process is updated

Scenario # 2: The user navigates to the record, performs the event which should invoke the
workflow process. However, the workflow process is not executed, ie, as evidence by the actual
workflow result not occurring.

Reasons for this behavior:

1. The runtime event did not occur at all. Since the event did not occur, no action associated to the event
will execute.

2. The runtime event did occur, but the runtime event did not have any workflow process associated to it.

3. The runtime event did occur, the workflow was initiated, however, the workflow failed to execute
properly or successfully.

Diagnostic Steps:

1. Verify that Workflow Process is active. Activation or deactivation of workflow processes automatically
creates/removes appropriate event actions related to those workflow processes.

2. For the runtime event, verify there is an action associated to this event. Verify if there are other
actions associated to the same event, such as business component script on the same event handler.

Note: Scripts on the business component take precedence over workflow process with the same event.

3. Verify that the runtime events have been created and the action set information matches the ROW_ID
for the active workflow process.
4. Verify that Reload Runtime Event (Reload Personalization) has been performed, or the Object
Manager has been restarted. ‘Reload Personalization’ or ‘Reload Run-time Events’ applet menu method
in Run-time Administration views is used to refresh the cache for the Application Object Manger server
component or Dedicated Clients.

Runtime event driven workflow process are context sensitive, it is heavily reliant on the Business Object.
Current functionality requires these to be the same in order for run-time event to invoke workflow process
(Bug 10448804). When workflow process is invoked via run-time events, workflow engine uses the
Business Object on the view where run-time event is triggered. The object manager identifies the primary
business component for the business object, gets the ROW_ID from the primary business component and
passes this ROW_ID to the workflow process to be set as the workflow process’ Object Id value.

If the workflow process is based on a particular Business Object, then the user must also initiate the
runtime event at a view which is also based on the same Business Object. For example, the above
workflow process is based on Business Object “Service Request”.

a. If the user updates the SR Owner field at a view based on Service Request business object, the
runtime event will occur and the workflow process will execute.

b. If the user updates the SR Owner field at a view based on another business object, such as Account
business object at the Account screen > Service Request view, then the runtime event will occur, but the
workflow process will not execute.

In Siebel 7.7 and later versions, the following error message will appear in the client-side log file:

procinst.cpp (930)) SBL-BPR-00130: Runtime event '1-6F9HT' ignored. Event business object 'Service
Request' does not match business object 'Contact' associated with process definition '1-6DSUK'.

Thus, verify which view the user was at when performing the event. This can be done by navigating to
the view, then select the Siebel client > Toolbar > Help > About Record, this will show how the view is
configured, which business object, which applets, which business component(s), etc. Ensure the
business object of this view matches the business object specified on the workflow process.

5. If there is a need to initiate the workflow process to run when user is at a view with a Business Object
other than that specified on the workflow process, the following alternatives are possible:

a. Create multiple versions of the workflow process, each with a different Business Object to
accommodate the views the user will perform the runtime event from.

b. Do not use runtime event to initiate the workflow process. Rather, have the workflow process invoked
from a workflow policy violation, where the workflow policy conditions monitor data changes at the
table/column layer.

c. Do not use runtime event to initiate the workflow process. Rather, use custom script on the Applet or
Business Component to initiate the workflow process.

d. Do not use runtime event to initiate the workflow process. Rather, use declarative alternatives to
initiate a workflow process, such as Business Component User Property using “Named Methods”.

6. To verify if the runtime event had occurred or not, and if the workflow process has been invoked or not,
user can enable Personalization Logging. This type of logging will capture any and all runtime events
which occurred for the user session. Personalization event logging can be enabled for each type of
Siebel client as follows:

For Dedicated and Mobile Web Client:

Add the parameter value to the [Siebel] section of the client cfg as follows:

EnablePersonalization = TRUE
PersonalizationLog = <directory path for log file + file name>

For example:

EnablePersonalization = TRUE
PersonalizationLog = C:\Temp\personalization.log

For Web Clients:

Edit the Application Personal Log application object manager component parameters via the Server
Administration screen to ‘Directory path for the log file’, example: C:\Temp\Personalization.log.

For more information, review Siebel Bookshelf > Siebel Personalization Administration Guide > ‘Enabling
Personalization Event Logging’ section.

Once the personalization log is enabled, launch Siebel client session, navigate to the view to perform the
event on the record.

Locate the personalization log file, inspect the personalization log file to verify if the runtime event
occurred or not. If the event occur, did the action set get invoked. Confirm the action set and action id in
the log match the ones in run-time events administration views. Check whether the event was triggered.

If the runtime event occurred and the action set is invoked, the personalization log file would show the
following information as example:
-------------------------------------------------------------------------------
Event, at 11/04/04 12:07:04.707, sequence 123

Object type: BusComp

Object name: Service Request
Event: SetFieldValue
Sub-event: Area

Processing action set 'Workflow_1-97QJ' ...

processing action 'Workflow_1-97Q1' ...

{S(123)T(1099598824.707)U(SADMIN)K(13)Y(Event)N(N)}
-------------------------------------------------------------------------------

In the above tracing example, the entry “Processing action set 'Workflow_1-97QJ' ...” indicates that the
object manager has invoked the action associated to this runtime event.

Scenario # 3: The user is at the correct view when performing the event, the workflow executes,
but the workflow fails with error or the expected/desired workflow results are not achieved.

Reasons for this behavior:

The workflow process was initiated and it did run, however, the workflow encountered execution errors or
logical errors.

Diagnostic Steps:
It is necessary to enable tracing on the Siebel client which is performing the event. Client-side tracing can
be enabled for different types of Siebel client application as follows:

a. Siebel Dedicated / Mobile client application logging. This type of tracing will capture any runtime event
occurrence, workflow process execution, sql tracing, scripting and other details. The level of detail in the
client-side tracing file can be controlled by an Environment Variable. Set Siebel Dedicated Client tracing
as follows:

At the user’s computer > Programs > Settings > Control Panel > System > Advanced > Environment
Variables > select {New} button from either User variables or System variables. For the new variable,
supply the following:

Variable Name: SIEBEL_LOG_EVENTS

Variable Value: 5

The value for “Variable Value” ranges from 1 (least amount of details) to 5 (most amount of details).

Click {OK} to close out dialog boxes.

The log file should be located in the Siebel client\log directory as Siebel.log.

b. Siebel Web Client application logging. This type of tracing will capture any runtime event occurrence,
workflow process execution, sql tracing, scripting and other details. The level of detail in the client-side
tracing file can be Component Events on the Application Object Manager server component.

Set workflow related tracing on the Web Client by:

Navigating to Site Map > Administration – Server Configuration screen > Servers > Components. Select
the Application Object Manager server component.

In the Events applet, set the following events and log level to 5. The value for the event’s log level ranges
from 1 (least amount of details) to 5 (most amount of details).

Event Context
Context Initialization
General Events
Component Tracing
Task Configuration
Server Requests Routing Info
SQL Tracing
SQL Parse and Execute
Object Manager Business Component (Operation and SetErrorMsg Log)
Object Manager Extension Language (SetErrorMsg Log)
General Object Manager Log
Object Manager Business Service (Operation and SetErrorMsg Log)
Workflow Definition Loading
Workflow Engine Invoked
Workflow Process Execution
Workflow Step Execution

// should I just refer user to the FAQ 1482 instead ?

The log file should be located in the Siebel server\log directory.

To verify if the workflow has been executed or not, reproduce the behavior. Then, locate the client-side
log file for the client being used. Inspect the log file by searching for the string “Workflow Engine”. If such
a string is found, this indicates a workflow process was executed. An example entry in the client-side log
file is similar to the following:

EngInv EngInv 3 0 2005-10-25 17:18:01 Workflow engine requested to perform method

'RunProcess'.
EngInv Arg 4 0 2005-10-25 17:18:01 Input: @0*0*4*0*0*0*7*EventId6*1-
3X4I9*ProcessId6*1-4PJ09*Sub Event5*Owner10*Event Name13*SetFieldValue
PrcExec PrcExec 3 0 2005-10-25 17:18:01 Executing process definition '1-4PJ0'.

Next, search again in the log file for the event name “StpExec”. If the log level has been set to 4 or 5, this
keyword should return entries where each workflow process’ step has been executed. An example is as
follows:

PrcExec Create 4 0 2005-10-25 17:18:02 Instantiating process definition 'SR Owned - Create
SR Activity'.
StpExec Create 4 0 2005-10-25 17:18:02 Instantiating step definition 'start'.
StpExec Create 4 0 2005-10-25 17:18:02 Instantiating step definition 'take user to detail view'.
PrcExec Create 4 0 2005-10-25 17:18:02 Instantiating process definition 'SR Owner updated -
create opty'.
StpExec Create 4 0 2005-10-25 17:18:02 Instantiating step definition 'start wf 2'.
StpExec Create 4 0 2005-10-25 17:18:02 Instantiating step definition 'create quote'.
StpExec Create 4 0 2005-10-25 17:18:02 Instantiating step definition 'end'.

Continue to search through the log file for instances of workflow steps and process being instantiated and
executed. Verify if the workflow execution is taking certain steps that are not expected, or stopped
execution at certain steps that are not expected, or error messages have occurred.

1. If the workflow process has exited with error, check the step which generated the error message.
Inspect the error message for exact problem and correct the problem.

2. If the workflow process took a branch from a decision step that is not expected, verify if the condition
being checked at the decision step was correct or not. If the condition checks for certain field or process
property values, inspect the value for the field and process properties before the decision step was
executed. Verify if the values are expected or not.

3. If the workflow process is at a User Interact step and does not proceed to the next step, verify if there
are runtime event branches associated with the User Interact step. If there are runtime events associated
to the User Interact step, the workflow will resume from the User Interact step when the event occurs.

4. If the workflow process is at a Wait step and does not proceed to the next step, verify:

a. If there are runtime event branches associated with the Wait step, the workflow will resume from the
wait step when the event occurs.

When using runtime events to resume a workflow process from a User Interact step, please note that the
following runtime events are not supported with the User Interact Step:

. All application events.

. The DisplayRecord event.
. The DisplayApplet event.
. The SetFieldValue event for a field that has the Immediate Post Changes property set to TRUE.

b. If Wait step has Input Arguments specified for “Sleep Unit” and “Sleep Quantity”, then:

i. If the “Sleep Unit” is in Seconds, the workflow process will wait for that amount of time before
proceeding to the next workflow step.
 ii. If the “Sleep Unit” is in Minutes, Hours, Days, the workflow process will suspend and persist
the workflow instance into the database by inserting a recording into the S_WFA_INSTANCE and
S_SRM_REQUEST tables. When the amount of wait time is over, the workflow process will resume
execution by executing on the Workflow Process Manager server component.

Scenario # 4: The runtime event occurs, but multiple different workflow processes are executed.

Reasons for this behavior and Diagnostic Steps:

1. The same runtime event is used in different workflow processes.

Check the Runtime Event Action set to verify if the event should invoke the other actions/workflow
processes. If yes, then the actions/workflows are executed on after another. If no, verify if the other
workflow processes should be inactivated. Inactive other workflow processes that are no longer needed.

2. The workflow execution from the runtime event performed some operation that caused a different
runtime event to trigger off and call a different workflow.

Review the Personalization log and client-side log file to identify the secondary or subsequent workflows
that executed. For these subsequent workflows, identify the runtime event that initiates the workflow and
then verify if this event is being performed by the operation in the very first workflow.

Scenario # 5: The runtime event occurs, but the same workflow process executes repeatedly in
an infinite loop.

Reasons for this behavior:

The current workflow may perform some operation that trigger the same run-time event again, which is
the caller of the current workflow. Therefore, the same workflow that was triggered is invoking itself and
the result is an infinite loop.

Diagnostic Steps:

Check the workflow process step to ensure that it does not perform operation that causes the same
runtime event to occur.

Use applet as event object type instead of using business component. This will restrict the event to focus
on only one view instead of multiple views as business components are reused in many different ways.
Users may not encounter the problem mentioned when configuring event using the business component
object type only if it is certain that the selected business component will not be changed during the
processing of that particular workflow.

Scenario # 6: User performs the operation that triggers the runtime event. User expects the
runtime event to resume the workflow, but instead get an error message similar to the following:

“Cannot resume process ‘1-2ABX’ for object ‘1-1O44’. Verify that an instance does exist and has a
‘Waiting’ status.”

The generic error is: “Cannot resume process '%1' for object '%2'. Verify that an instance does exist
and has a ‘Waiting’ status”

Reasons for this behavior and Diagnostic Steps:

Note: Processing Mode on the workflow steps is not applicable when run-time event do not initiate the
flow and it is initiated by another method like a script or other components. (where to put this???)

1. Resuming from a workflow process is only applicable if the workflow process was initiated and
executed. Thus, ensure that the workflow process has actually executed and is currently waiting at the
step which has the runtime event. This applies for runtime event used in User Interact steps and Wait
steps.

2. The StepId associated to the runtime event is not the step at which the waiting workflow instance is
waiting on. Verify the Business Service Context field for the runtime event to ensure that the ProcessId is
the ROW_ID of the expected active workflow and the StepId is for the correct step of the active workflow
process. This can occur if the workflow process re-uses the same runtime in multiple steps of the
workflow process. Then, the same runtime event is associated to multiple action step where the
ProcessId is the same, but the StepId are different. Thus, it becomes ambiguous as to which Step the
workflow process should resume from. It is not supported to re-use the same runtime event in different
steps of the same workflow process.

3. The workflow navigated user to a view, the user then exits the client session. The user then logs back
into the application and attempts to resume the workflow and encounters the error.

User Interact steps displays views and thus relies on a GUI context. User Interact steps have an implicit
wait and a workflow process having a User Interact step can only run in the client object manager or
Application Object Manager where there is a GUI context. Once the User Interact step is invoked, a run-
time event can be used to resume process.

a. If persistence is not turned on, the run-time event must occur in the same user session to resume the
process. This functionality can be used if a series of views are to be navigated in sequence, for example
– user registration process.

This error can occur as the new user session does not have the workflow instance in memory for it to
resume.

b. If persistence is turned on, any session or task in which the run-time event occurs can trigger the
resumption of the workflow process, as persistence causes the workflow instance to be stored into the
database S_WFA_INSTANCE table.

Scenario # 7: The runtime event occurs on the mobile user’s local database, but the mobile user
receives error message that:

"Cannot execute workflow process definition '%1'"

Reasons for this behavior and Diagnostic Steps:

The runtime event data is routed to the mobile user’s local database. The runtime event occurs and the
application tries to invoke the workflow process which has the ProcessId associated to the runtime event.
However, the workflow process definition does not exist on the mobile user’s local database.

This can occur if the workflow process on the server database does not have the field [Replication] = “All”.

If the workflow process on the server database has [Replication] = “All”, the workflow process definition is
routed to the mobile user local database.

If the workflow process on the server database has [Replication] = “None”, the workflow process is not
routed to the mobile user’s local database.
To address the behavior, ensure the workflow process on the server database has [Replication] = “All”.
Then, re-extract the mobile user’s local database.

Scenario # 8: User has a button on an applet to invoke the workflow process from runtime event.
The button is clicked, but the workflow process is not executed.

Reasons for this behavior and Diagnostic Steps:

1. In the workflow process runtime event branch is using “Event Object Type” = Applet, ensure the “Event
Object” field has the correct applet name where the button is located on.

2. If the user is attempting to initiate a standard Siebel provided workflow process, verify the workflow
process has been deployed, activated and runtime events reloaded.

3. If the user has created a new applet with a button to initiate a standard Siebel provided workflow, then
ensure to revise the workflow runtime event branch to update the Event Object Type, Event Object, Event
and Subevent fields with the correct values from the custom applet.

A common scenario is when user modifies the Siebel provided workflow process “FS - Verify Entitlement
SR” to initiate from a different applet in the application.

4. If a custom button is added to an applet, ensure the button has a corresponding method name and the
applet’s WebApplet_PreCanInvokeMethod() event handler has the proper code necessary to enable this
event. For the script to use, please refer to Siebel Bookshelf > Business Process Designer Administration
Guide.

Scenario # 9: User triggers the runtime event, the user gets and error message as follows:

"Cannot find definition for WfProcMgr component"

OR

“can not connect to gateway”

Reasons for this behavior and Diagnostic Steps:

This error message can occur if the workflow process needs to run or connect to the server for the
component “Workflow Process Manager”, but the component is not available. The [Processing Mode]
field on the Workflow Process start step can affect this error:

a. Local Synchronous: Executes the process in the application object manager for Web Client, in the
Dedicated Client for Dedicated Web and Mobile Web Client. This is the default if the [Processing Mode] is
left blank.

With Local Synchronous mode, the caller (component / process) requesting the workflow process will
have to wait for the Workflow Process execution to complete before control is returned to the caller.
Thus, with this mode, if event triggered by a user at the UI, user’s client application will freeze slightly
while the workflow process is executing.

If event is triggered by another process such as script or another workflow process, the process will
freeze / get interrupted, to allow the runtime workflow process to execute. Once the runtime workflow
process is complete, then the control is returned to the called or the interrupted process, to resume
processing.
b. Remote Synchronous: Submits a synchronous request to the Workflow Process Manager server
component to execute the process.

With Remote Synchronous mode, the caller submits a request to the Workflow Process Manager server
component to have WfProcMgr component execute the workflow process logic. With this mode, as it is
synchronous, the caller will also have to wait for the WfProcMgr task to complete the workflow process.
Once WfProcMgr completes processing, then control is returned back to the caller to resume normal
processing.

If this mode is used by a dedicated client or mobile client, if the Workflow Process Manager server
component is not available, user can get the above error messages.

c. Remote Asynchronous: Submits an asynchronous request to the Workflow Process Manager server
component to execute the process. The Component that submits the request to Workflow Process
Manager with “Remote Asynchronous” mode does not wait for the Workflow Process Manager task to
complete before control is returned to the called, ie, the Application Object Manager session.

If this mode is used by a dedicated client or mobile client, if the Workflow Process Manager server
component is not available, user can get the above error messages.