Error Message:

Job execution failed.
Dispatched job to resource group : Default Async...
Starting...
The password you have entered is not correct. Please enter your password again.(SBL-DAT-00569)
User error.
Status No: 1 :
Basic Error: 1000
Module: ssReport%BuildReport
Line: 113
User error.

Solution:

This Error occurs in one scenario such that Report Generation Failed when in Report Schedule.the below one such error is the example
Dispatched job to resource group : Default Async...Generating rotp:/Login ID/PRSPLSTMGMT_ENU_ENU.roi;19 ...
The password you have entered is not correct. Please enter your password again.(SBL-DAT-00569)
User error.
Status No: 1 :
Basic Error: 1000
Module: ssReport%Start
Line: 96
User error.
Resolution :Error because of Report generated Login Password is changed, To fix this We have to schedule the Report again from Application with New Password or with Admin credentials( SADMIN) to resovle permanently. This Problem will Occurs only in ADSI/LDAP Authentication

To check the website analytics like page usage, number of users etc we have tools like Google Analytics Likewise, in Siebel CRM applications, the number of times a Siebel view is accessed can provide useful insight.
In order to collect that information, we can use the Siebel Usage Collection feature. The following procedure describes how to enable it:

1. Log on to the Siebel Web Client using an administrative user account.
2. Navigate to the Administration - Runtime Events screen, Action Sets view.
3. Create a new action set named Usage Collection.
4. In the second list applet from above, click the New button to create a new action definition.
5. Set the Name and Sequence fields to 1.
6. Set the Type field to BusService.
7. In the form applet at the bottom of the view, enter Usage Tracking Service in the Business Service Name field.
8. Enter EventType=Runtime Event in the Business Service Method field.

Screen Shots:

• http://directutor.com/sites/default/files/usagecollection_Action_Set.JPG
• http://directutor.com/sites/default/files/usagecollection_Action_Set_1.JPG

1. Navigate to the Events view in the Administration - Runtime Events screen.
2. Create a new record and set the Sequence field to 2.
3. Set the Object Type field to Application.
4. In the Object Name field, click the select button and select the name of the application you are using.
5. In the Event field, enter ViewActivated.
6. Set the Action Set Name field to Usage Collection (the name of the action set created earlier).

Screen Shots:

• http://directutor.com/sites/default/files/usagecollection_Events_1.JPG

1. Navigate to the Administration - Application screen, System Preferences view.

Set the system preferences for Siebel Usage Collection according to the table below.

• UsageTracking Enabled = TRUE
• UsageTracking Log Time Period = Daily
• UsageTracking LogFile Dir = \\sharedpath\usage
• UsageTracking LogFile Format = xml

Screen Shots:

• http://directutor.com/sites/default/files/usagecollection_userpref.JPG

Reference: http://download.oracle.com/docs/cd/B31104_02/books/ContentPub/booktitle.html
 

To upload multiple ROX files into the Reports Server Encyclopedia, you can use the Actuate eReport Designer Professional (eRDPro). You might use this approach to upload multiple ROX files at one time or to upload the latest ROX version into the Reports Server. The following steps detail how to do this:
•Open the Actuate eRDPro.
•Go to View > Options and select the General tab.
•Select the check box “Enable navigator menu item and toolbar” and click OK.
•Go to File > Navigator and log in to the Reports Server Volume as the Report Server Administrator.
Enter the specified values in the following fields and click OK:
Username: administrator
Volume:
•To add multiple ROX files,select the location or folder for example, Siebel Reports.
•Open Windows Explorer and navigate to the location where your ROX files reside for example, C:\seaClientReports.
•Select all desired ROX files from the folder and drag and drop them into the Siebel Reports folder on the Actuate Navigator.
•Select Replace or Version. Selecting Version keeps the existing files.
•Repeat the same process if you intend to upload other ROX files to the Siebel Reports/ENU folder in the Actuate Navigator.
•Exit the Actuate Navigator.
NOTE: The Actuate Navigator does not have the administrative rights to change report object privileges, this must be done through the Management Console. Here are the steps to do it:
•Log in to the Reports Server Volume using the Actuate Management Console.
•Navigate to Files & Folders > Siebel Reports folder.
•Click on “Select all items” checkbox. You should see all ROX files selected.
•Click on Act Upon selected items and Properties.
•Click on the Privileges tab
•Select All from Available panel and move to the “Add these privileges” panel.
•Select the Visible, Execute, Read, and Grant check boxes.
•Click on Apply and then click OK. Similarly, grant the same privileges to the ROX files under the Siebel Reports/enu folder if necessary.

Download the list of user properties .Doc  format   http://www.directutor.com/sites/default/files/User_Properties.doc

Applet User Prop

Field user Prop

I'm sure most of you are aware of these standards / guidelines for development,  
 
Performance:
- Never put a multi-valued field on a list applet, especially if it does not have a primary
- Avoid sorts on applets / buscomps that will bring back large datasets
- Be cautious with what fields you mark as Force Active
- Avoid toggle applets - especially on list applets
 
Remote:
- Avoid new custom foreign key extension columns
- Avoid real-time integrations via UI for anything that may need to be accessible for remote users
 
Configuration:
- Never put an MVG on a form applet as editable - force the users to open the MVG to add / delete / update MVGs (otherwise it will create "bad" records in the background)
 
Script:
- Always indent your code for easier reading
- Always comment your code & include a "header" description of functions
- Put code that needs to be used in several places into Business Services
- Avoid multiple if else if else statements - use select statements instead
- Always include error handling
- Always check to be sure your objects / records are found or exist prior to using them
- Always activate ALL fields to be used prior to querying a buscomp to ensure you have access to the fields' data
- Always destroy objects after usage - in the REVERSE order of declaration
- Avoid declaring variables in while loops
- If a requirement can be done via configuration - then AVOID writing script for it
 
Other:
- Avoid Repeating Component requests as they may get skipped on nights with maintenance tasks, releases, etc.

Siebel Scripting advanced concepts - pdf file. covers following concepts -

 BusComps and BusObjects
 PropertySets
 TheApplication
 Business Services
 Scripting In Applets
 Using Windows Script Popups
 Garbage Disposal
 Final Thoughts
 
down load the pdf : 
http://directutor.com/sites/default/files/eScripting-advanced.pdf
 

When an end user clicks a view tab to navigate to a new view, a chain of processes is invoked on different machines in order to handle the request. For example, the Siebel Web Server Extension must connect to the application object manager (AOM) on the Siebel server. The AOM will issue an SQL statement to the Siebel database and the Siebel Web Engine (SWE) will put the view layout and data together and render the view.

In order to be able to make exact measurements to determine performance bottlenecks quickly, Siebel engineers have included instrumentation points in the core program code of all Siebel software components.

This feature is commonly known as Siebel Application Response Measurement (SARM). The following diagram explains how SARM works:

From the above diagram, we can learn the following about Siebel Application Response Measurement:

1. Requests from the web client are processed on the Siebel Web Server Extension (SWSE) on the web server machine.

2. The request is passed on to the application object manager on the Siebel server machine.

3. The application object manager requests data from the Siebel database.

4. The database returns the data.

5. When the Siebel code executes, a buffer in the machine's physical memory is filled with information about each single event.

6. Once the memory buffer is full or a timeout is reached, the buffer's content is flushed to files on the hard disk. These files have a .sarm suffix.

7. Administrators can use the sarmquery command line utility to convert the binary content of the .sarm files to readable formats such as CSV (comma separated values) or XML. Alternatively, SARM information can be viewed directly at the command prompt.

Next, we will discuss these major administrative tasks related to Siebel Application Response Measurement:

• Enabling SARM

• Managing SARM files

• Using sarmquery to read SARM files

• Automating SARM data retrieval

Enabling SARM

The default behaviour of Siebel software is not to produce .sarm files. In order to turn on the production of .sarm files, we have to set parameters (for Siebel Servers and their components) or environment variables (for all other variants of Siebel software such as the Siebel Web Server Extension or Siebel clients).

Enabling SARM for Siebel Servers and Components

We can use the graphical user interface (GUI) provided by the views in the Administration - Server Configuration screen or the Siebel Server Manager (srvrmgr) command line utility to set the SARM-related parameters. It is recommended to enable SARM only for a specific set of server components rather than for an entire Siebel server in order to keep the performance impact to a minimum.

The following table describes the SARM-related parameters:

The following procedure describes how we can enable SARM for an application object manager component:

1. Log in to the Siebel Server Manager (srvrmgr) command line using a command similar to the following at the Siebel server's bin directory:

   srvrmgr /g osappeval4 /e SIEBEL_EVAL /u SADMIN /p TJay357D /s Eval_1

The above example command will connect to the Siebel Gateway Name Server on the host osappeval4. The enterprise name is SIEBEL_EVAL, username is SADMIN, and the server to be set at the prompt is Eval_1.

1. At the srvrmgr> prompt, enter a command similar to the following:

   change param sarmlevel=2,sarmperiod=1,sarmthreshold=100 for comp sccobjmgr_enu

The above example command enables SARM at level 2 for the English Siebel Call Center object manager. The memory buffer's content will be flushed once a minute; only events that took longer than 100 milliseconds will be written to the .sarm files. These parameter changes are effective immediately, so no component or server restart is required.

Enabling SARM for Other Siebel Software Units

Because of the fact that only Siebel servers and their components can read the parameters from the Siebel Gateway Name Server's configuration store, we must use environment variables to enable SARM for other Siebel software units such as the Siebel Web Server Extension (SWSE) or Siebel clients such as Siebel Tools or the Siebel Mobile Web Client.

The following table relates the SARM environment variables to the parameters discussed above. Basically, the environment variable's name can be derived by adding the prefix "SIEBEL_" to the parameter name.

The following procedure describes how to set the SARM environment variables on Microsoft Windows-based operating systems:

1. Right-click the My Computer icon and select Properties.

2. In the System Properties dialog, click the Advanced tab.

3. Click the Environment Variables button.

4. In the System Variables area, click the New button.

5. Enter the correct values in the Variable Name and Variable Value fields and click OK.

6. Repeat the previous step for each environment variable you need to set.

7. Restart the application (for example the Siebel Developer Web Client or the web server).

We can verify that SARM is properly enabled by inspecting the log directory of the installation folder of the Siebel software unit. SARM files should appear in this directory after the time specified in the SARMPeriod parameter. The screenshot below shows the Siebel Server's log directory with .sarm files:

The naming convention for sarm files is as follows:

A_<Server component name>_T<Timestamp>_P<Process Id>_N<counter>.sarm

If we used the SARMLogDirectory parameter to specify a different storage location for .sarm files, we must inspect the respective directories.

Managing SARM Files

It is imperative for Siebel administrators to understand how to create usable sets of .sarm files without cluttering the server's hard drives. In environments with hundreds or even thousands of end users, the amount and size of .sarm files can grow out of bounds quickly.

The following techniques ensure that we harvest a reasonable amount of information without affecting the overall system performance more than necessary.

Always set the SARMThreshold parameter to a value of 10 or higher. This avoids too much data being written to the .sarm files. Because SARM is often used to trace long-running and therefore performance-hampering events, we can ignore the events that execute very fast.

Setting the SARMThreshold for example to a value of 100 reduces the amount of data written to the .sarm files by an average of 90%. This can be easily verified by comparing .sarm file sizes at different settings of this parameter.

Adjust the amount of .sarm files for a single process using the SARMMaxFiles parameter. After a short evaluation period, we should be able to determine the ideal number of files. We should always have the amount of files that is needed to cover a typical monitoring period. For example, if we monitor a work day (9:00 am to 5:00 pm) we should set the SARMMaxFiles parameter to a number which ensures that .sarm files for an individual process do not get overwritten before eight hours.

With regard to reading the .sarm files with the sarmquery utility or using the Siebel Diagnostic Tool, the default folder—the log directory of the Siebel software unit—should be kept as the storage location. However, we can use scheduled scripts to copy the .sarm files to an archive folder to avoid loss of data.

Using Sarmquery to Read SARM Files

The sarmquery command line utility is the primary means of converting the binary content of the .sarm files to readable output. We can choose between various output formats such as text, XML, or csv files or we can consume the output directly at the command prompt.

We can locate the sarmquery executable in the bin directory of the Siebel server's or the Siebel Gateway Name server's installation folder. In addition, the Siebel Management Agent uses sarmquery to support the Siebel Diagnostic Tool, which is discussed later in this chapter.

When we enter sarmquery at a command prompt in the Siebel server's bin directory, the utility reveals the basic usage information. The following screenshot shows the output of the sarmquery command in a Microsoft Windows command shell:

It is recommendable to use the information provided to produce text files that contain the information obtained by the -tips, -help, and -macrosyntax options.

For example, a command similar to the following will create a tips.txt file with useful first step information in the Siebel server's bin directory:

sarmquery -output verbose=tips.txt -tips

The above command uses the -output option followed by the verbose key with a value of tips.txt and the -tips option. This command produces a text file of the standard output of the -tips option. We can repeat this command to create a help.txt and macrosyntax.txt file by modifying the above command accordingly.

The main syntax of the sarmquery utility is as follows:

sarmquery -option key=value -input <directory or file>

The sarmquery command line utility accepts several options, which must be preceded by a dash ("-") and followed by a key=value pair. The -input option must be followed by the name of either a single .sarm file or a directory that contains .sarm files. If we use the directory option, sarmquery will scan the given directory and all its subdirectories recursively for .sarm files.

The following table describes the major options and example key=value pairs for the sarmquery utility:

Each option or key can be abbreviated as long as the abbreviation is not ambiguous. For example, the following is a valid sarmquery command:

sarmquery -i ..\log -agg sub -sel area=dbc

The above example uses the -input option (abbreviated to -i), the -aggregate (-agg) option followed by the subarea (sub) key and the -select (-sel) option. The abbreviation technique might come handy while using the command line but we should consider using the full text when creating scripts or macro files for the sake of better readability.

For a complete list of possible keys, we can consult the help file (generated using the -help option) or the Performance Tuning Guide in the Siebel bookshelf.

In the following, we will explore common scenarios for sarmquery:

• Specify the start and end time

• Application performance by area and subarea

• Time histograms

• Identify slow performing objects

• Create SARM output files

Specifying the Start and End Time

In a typical sarmquery scenario, we most probably want to analyze data from a specific timeframe. In order to do so, we must use the -select option for the starttime and endtime keys in every sarmquery call we make.

We can use a command similar to the following to obtain a list of users who logged on in the specified timeframe:

sarmquery -input ..\log -aggregate user -select starttime="09:00:00" -select endtime="17:00:00"

The above command—issued at the bin directory of the Siebel server—will read all .sarm files in the Siebel server's log directory and create an aggregate plot for all users who had a session between 9:00 AM and 5:00 PM. If no date is given, sarmquery takes the current day into consideration. If we wish to specify a date, we must use the same syntax as in the example below:

-select starttime="2010-05-20 09:00:00"

The example specifies 9:00 AM on the 20th of May 2010 as the start time.

The output of the above command is similar to the following:

The previous screenshot shows the typical output of sarmquery at the command line. Aggregates are plotted as horizontal bar graphs with the average response time as the scale.

Application Performance by Area and Subarea

When SARM collects event data, it not only collects the timestamp, the user, and response timings but also the area and subarea of the Siebel application infrastructure where the event occurred.

A full list of SARM data collection areas can be found in the Siebel Performance Tuning Guide in the Siebel bookshelf documentation. The following table lists the most prominent areas:

Each area has one or more subareas. We can obtain a comma-separated value (CSV) file listing all areas and subareas using the following command:

sarmquery -output map=map.csv

The above command produces a text file in CSV format, which describes all available SARM areas and subareas.

Analyzing Areas, Subareas and Instances

We use a sarmquery command similar to the following to get a horizontal bar chart, which helps us identify the area in which most of the process time is spent:

sarmquery -aggregate area -input ..\log

The above command reads all .sarm files from the log directory of the Siebel server and produces a chart similar to the screenshot below:

The above screenshot shows the output of the -aggregate area option. The chart lists all areas (sorted descending by the percentage of process time spent in the area) for which events have been recorded in the .sarm files. In the above example, 25.35% of the total process time recorded by SARM is spent in events that belong to the INFRA area.

We can "drill down" into each area by using commands similar to the following:

sarmquery -select area=objmgr -aggregate subarea -input ..\log

The above command uses the -select option to filter the output for the OBJMGR area and creates a bar chart that shows the share of process time spent for each subarea.

We can further "drill down" on the data. For example to see a list of business services that use the processing time, we use a command similar to the following:

sarmquery -select subarea=objmgr_bsvc_invoke -aggregate instance -input ..\log

The above command uses the -aggregate instance option. The instance key typically provides the name of the object involved. In the case of the subarea objmgr_bsvc_invoke, business service names are shown in the instance field.

Time Histograms

A common server monitoring scenario is the retrieval of application response data over time. The data contained in the .sarm files can be interpreted in this way using the -aggregate time option. A command similar to the following produces a histogram of the application response time for a specific day:

sarmquery -input ..\log -aggregate time=10 -select starttime="2010-02-18 00:00:00" -select endtime="2010-02-19 00:00:00"

The above command produces a response time plot at 10-minute intervals (specified by the time=10 key=value pair) over the period specified as the timeframe between the starttime and endtime key values.

Identifying Slow Performing Objects

One of the main purposes of SARM is the quick and easy identification of performance bottlenecks. We have learned above that we can aggrgate the response time information by area, subarea, and instance.

By using the correct subarea as a filter criteria in the -select option, we can create response time histograms for objects such as views, scripts, or business services and identify slow performers.

The following example command allows us to identify slow performing views with a build time over five seconds:

sarmquery -input ..\log -agg instance -select subarea=SWEPAGE_VIEW_BUILD -select selftime=5000

The above command produces a response time histogram for all views that required more than five seconds (specified as 5000 milliseconds in the selftime key value) to build (subarea=SWEPAGE_VIEW_BUILD). The following screenshot shows the output of the example command:

Views of the server management screens typically take a longer time to build because data is being fetched from the Siebel Gateway Name Server. The high response times for the Home Page View are resulting from the fact that it is the application's start view.

Similar commands can be issued using other areas such as SCRIPT (to identify slow running scripts) or OBJMGR (to identify slow performing business layer objects) or their respective subareas.

Creating SARM Output Files

The sarmquery command line utility can be used to export the content of the .sarm files to various output formats such as plain text, comma-separated values (CSV), or XML. Typically, these files are loaded into third-party software such as Microsoft Excel to further analyze the SARM data sets. We use the -output option to create SARM output files.

One of the most prominent output commands can be seen in the following example:

sarmquery -input ..\log -output sarm=sarmdata.csv#10000

The above command writes the raw SARM data to a series of CSV files. By specifying the suffix #10000, after the file name, we determine that each CSV file will contain only up to 10000 rows of data.

The CSV files can then be consumed for further analysis in spreadsheet applications such as Microsoft Excel or business intelligence tools such as Oracle Business Intelligence Enterprise Edition. The following screenshot shows a SARM .csv output file opened in Microsoft Excel:

The filter feature of Microsoft Excel allows quick creation of filtered sets of data for easier analysis.

In contrary to the raw data output of the sarm key, we can use the agg key of the -output option to write aggregated information to text or XML files. A command similar to the following yields an XML file containing information aggregated at the area level:

sarmquery -input ..\log -aggregate area -output agg=area_agg.xml

The above command uses the agg key followed by an XML file name and produces an output similar to the following screenshot.

<?xml version="1.0" encoding="UTF-8" ?> - <xml> <sarm version="20041117"/> + <Group type="Area" name="INFRA" pctCount="0.054" pctSelfTime="25.350" pctInclResp="35.387"> - <Group type="Area" name="OBJMGR" pctCount="0.316" pctSelfTime="23.219" pctInclResp="25.099"> - <Statistics> + <Self count="4871"> + <Inclusive count="665"> </Statistics> </Group> - <Group type="Area" name="SWEPAGE" pctCount="0.028" pctSelfTime="11.079" pctInclResp="7.157"> - <Statistics> - <Self count="430"> <TimeFrom>2010-01-27 07:18:08</TimeFrom> <TimeTo>2010-02-28 05:33:00</TimeTo> <SearchableTimeFrom>2010-01-27 07:18:ll</SearchableTimeFrom> - <ResponseTime units="ms"> <Average>937.010</Average> <Total>402914.472</Total> <Maximum>24627.637</Maximum> <Minimum>0.005</Minimum> </ResponseTime>

The benefit of the XML format is that SARM data can be made available to third-party analysis software more easily.

Automating SARM Data Retrieval

In order to provide the Siebel CRM project team with fresh and easily readable performance data, we must take the following into consideration:

• Ensure that .sarm files are collected and archived according to the monitoring policies of our company. We can use shell scripts to copy .sarm files to safe locations so they do not get overwritten by Siebel server processes.

• Create shell scripts, which execute the sarmquery commands that produce the most usable output for our project. We can use the SARM macro language to produce more flexible script files.

• Use a scheduling facility such as the Windows task scheduler to invoke the scripts at a regular basis.

• Provide SARM output files to third-party analysis systems for better visualization of the data.

The Siebel Server and the server components it hosts are among the most frequently used processes in a typical Siebel CRM implementation. In the case of error situations or slow performance, we must be able to quickly pin-point the root cause of the problem. One way to do this is to direct the server processes to write more detailed information in their log files.

The Siebel server infrastructure provides a logging model, which is based on event types. We can control the amount of information written to the log file separately for each server component and for each individual event type by choosing a log level for each event type.

The following log levels exist for Siebel servers or individual components:

When setting log levels to 2 or higher, we must bear in mind that a higher log level negatively impacts the performance of the Siebel server. In addition, the log files can quickly grow very large in size, clogging the log directories and making it hard to retrieve valuable information.

In the Servers view of the Administration - Server Configuration screen, we can view or modify event log levels for an entire Siebel Server (affecting all components on that server) or individual components.

In this list, we can set the log level for each event type individually. The following table lists some commonly used event types. Oracle recommends a log level of 4 for troubleshooting and 0 or 1 for normal operation.

If we wish to set the log level for one or more event types, we must execute the following tasks:

1.Verify that the event type and chosen log level is appropriate for the purpose.

2.Navigate to the Events view for either the server or the component level.

3.Select the Siebel server or the individual component.

4.Select the event type.

5.Set the log level to the desired value.

6.Restart the Siebel server or the individual server component.

Any modification of log levels should be documented and the respective log levels—especially on production systems—should be set back to 0 or 1 when no longer needed in order to avoid performance problems.

The Siebel Server's log directory holds all log files that are produced during the server's operation. If log levels have been increased, we will observe more and larger log files depending on our settings. We can observe that detailed information about the session is written to the file, including SQL statements.

Once a Siebel Server is restarted, the log directory's content is moved to an incrementally numbered subfolder of the LOGARCHIVE directory. We can control the number of archive directories by setting the Log Archive Keep parameter at the server level. This is important to know as the desired log file might reside in a subdirectory of the LOGARCHIVE folder rather than in the log directory, because the Siebel Server has been restarted.

Using the Siebel Server Manager Command Line to Set Event Log Levels

As an alternative to using the graphical user interface (GUI) provided by the views in the Administration - Server Configuration screen, we can issue commands or scripts at the Siebel Server Manager (srvrmgr) command line.

The following example illustrates how to set event log levels for an application object manager:

change evtloglvl genericlog=5 for comp sccobjmgr_enu

The above command sets the log level for the General Events event type to 5 for the English Siebel Call Center object manager.

Using the command line or script files is recommended if we frequently have to change the log level for a larger amount of event types. Scripts can also be used to ensure that log levels are reset back to lower values of 0 or 1 when the troubleshooting process is finished.