Whenever a component crashes, its logs are not made in the normal log folder in siebsrvr directory. Its logs are made in the form of FDR files(Flight Data Recorder files) and stored in BIN directory of siebsrvr folder. Here’s a simple step by step guide for finding and analyzing fdr files for component crash:

1. Identify the FDR file :

Go to BIN directory and sort the files by modified date column, you’ll find some fdr files at the top(if the crash happened recently otherwise you can filter files by *.fdr). The name of FDR files are in the format:

T<YYYYMMDDHHMM>_P<process id value>.fdr

For e.g. T201205011020_P5176.fdr

By date and time you can find the correct fdr file(resembles to crash date and time) and the process id(5176 in above example) is the process thread id which crashed.

2.      Decode the file :

FDR files are written in binary format, so you’ll have to convert it into normal format to analyze. To decode, a utility (present in BIN directory itself) known as sarmanalyser is used. Go to command prompt and change directory to BIN folder of siebsrvr, then use following command:

sarmanalyzer -o <output_csv_file> -x -f <fdr_file>

For example:

sarmanalyzer -o FDR1may.csv -x -f T201205011020_P5176.fdr

The resulted output file FDR1may.csv file would be made in the same directory (BIN).

3.     Analyze :

Open the output file(FDR1may.csv) and filter SubAreaDesc column by this value : **CRASHING THREAD** .

Go to the row where you find last **CRASHING THREAD** and note the value of ThreadId column(in above example it will be 5176).

Now filter the ThreadID column with the thread id you just got.

Now go to **CRASHING THREAD** row and start analyzing the sequence of actions in the last 10-15 rows from there. You’ll find the most important information in columns SubAreaDesc, UserStr1 and UserStr2. If you are unable to analyze by this info then go to Server Configuration -> Servers -> Events  and increase the log level of ‘FDR logs’ parameter to 5 and perform the crash again and then analyze. Good Luck.

Requirement:
We need to disable a PDQ on a specific view.

Solution:
The above requirement can be implemented by using an Application User property called as “PDQDisabledView” as below:
1. In Siebel Tools, query your application name in the Application object. expand the Application object and create a new User property as below:
Name                                                 Value
PDQDisbaledView                               < View Name>

2. Compile the Application object and lauch the client application to see the PDQ disabled for that view.
There is more to this subject than adding a user property.
Lets say I try and add value as a view name which is not the default view of “My Contacts”, “All Contacts” or any other under the Contacts screen say “Contact Service Agreement View” as below:

In this case, PDQ will not be disabled for this view.
Now I change the value of the user property as below:

In this case, the PDQ is disabled for all the views under this Contacts Screen. However the dropdown of the PDQ is still enabled for user i.e. this user property just does not run the PDQ when loading the view.
Henceforth, PDQDisabledView user property will disable all the PDQs under the screen if the value column of Application user property is set to the default view under the screen.

This article has been contributed by David Boukhors

It is sometimes difficult to reproduce a problem on Siebel, and you think the problem can be reproduced only with a specific user.

First of all, you should try with the same position and the same responsibilities as the concerned user. If the behavior is still not as expected, you should try the following tip. It allows you to connect as another user.

How it works

It is based on the Business Service SiebelUserProfileService, method SetContactContext which modifies the context of the logged in user. Please note that this method will work only on version below 8.1.1.9.

What you need

Your user must be authorized to access Business Service Test View, and you need to know the ROW_ID of your target user:

Select ROW_ID from <table_owner>.S_USER where login = <Target Login>

Your user must have access to the view you need to test. The easiest way to achieve this is to give your user all responsibilities owned by your target user, plus the Siebel Administrator Responsibility.

How to do it:

1)      Log in as your normal user, and go to Administration – Business Service screen, Simulator view.

2)      In the Simulator list applet, click New to add the business service you want to test.

3)      Specify the Service Name = SiebelUserProfileService and the Method Name = SetContactContext

4)      Specify the input parameters for the Business Service Method in the Input Property Set applet:

Property Name = Login Id

Property Value = the ROW_ID of your target user

5)      Click Run to run the Business Service

6)      Now go to Help>Technical Support>User Id and check your user now correspond to your target user

7)      From now, all you do in Siebel will be recorded as if you were the target user.

Note:
As described on Oracle Support in document Doc ID 1551728.1, the method SetContactContext is replaced with SetContactContextEx on Siebel version 8.1.1.9 and above. You’ll need to know the target user’s password to use this method.