Siebel Experts

A user has faced an issue related to parametrized actuate report and calculated filed in parameter applet.
Click to read the rest of this article »

I have assisted 4 siebel application for the actuate report issues. I am listing down the common Reports error and their Solutions which i faced during these assignments.

1. “Report generation has failed on the  Report Server”
2. “External library not found”
3. “Use of a null instance handle”
4. “The page cannot be displayed”

Click to read the rest of this article »

If you implement actuate reports within Siebel you would know that when you create a new user you have to synchronize the user with the Actuate server so that they can generate Actuate reports. Click to read the rest of this article »

Troubleshooting Steps
All the above factors can contribute to the poor performance of reports. If you are encountering report performance issues, the following checks should be made to isolate the problem. Please refer to the previous sections as appropriate.
1. Are all the reports perform badly or is it only specific reports that are performing badly?
2. If all reports are performing badly, check the following: Click to read the rest of this article »

Network
The network is the infrastructure that allows the Client Web Browser, Actuate e.Reporting Server, and Siebel Object Manager to communicate, assuming that they are all on separate machines. When the report is requested, the Siebel Object Manager passes the request to Actuate over the network. Click to read the rest of this article »

Reports Server
Physical Machine and Factories
The Reports Server has a finite capacity that depends on the specification of the physical machine. It is able to run multiple factory processes that allow reports to be processed concurrently, increasing the overall throughput of reports per minute. The number of factories dictates the number of reports that can be run concurrently. Click to read the rest of this article »

Aggregate Functions
The use of aggregation functions impacts the performance of a report to some extent. This behavior is expected because aggregation involves the summarizing of the records in some form. Therefore, the amount of aggregate information required adds to the overhead of the report performance.
Look ahead aggregates, for example, cause the report to retrieve all records before it is able to calculate the expression that is using the look ahead aggregate. Whenever possible, it is preferable to use running aggregates, which are calculated as data is being retrieved. For more information about running and look ahead aggregates, please refer to the Actuate Online Help.
If possible consider creating calculated fields on business components using the aggregate functions rather than doing the aggregation in Actuate, or a combination.
NOTE: You cannot sort on calculated fields within the Siebel application or define a search specification on the reports object on such fields.
Table of Contents
By default, when a report is created by Actuate it includes a table of contents. The creation of the table of contents can slow down the report if it is complicated. You can disable the table of contents by setting the TocAddComponent property to TOCSkip and the TocAddContents property of the Rpt component to FALSE.
Memory Usage
If a report is configured to do a large amount of sorting in memory, or arrays are being used to accumulate data, the memory usage of the report will increase. If it increases too much, then the report may spend more time paging memory, thus increasing the run time.
General Complexity
The more complex a report becomes, the greater the chance that its performance is affected. Other general items that can affect performance are:
• Frequently calling Fetch( ), Compare( ), OnRow(), Finish(), and other row methods in a large report
• Lookup methods within inner loops as they are executed many times
• Non-simple inner loops resulting in much processing for each inner record

continued….

Search Specification in the Report Design
If it is not practical to set the search specification on the business component or to set the search specification in the report object definition, an alternative is to configure the report to apply a search specification to the business component. This causes the report to re-query the business component with the search specification. The search specification of the report object in Siebel Tools is static and overrides any queries performed in the UI just before the report submission. Therefore, setting the search specification in the report design through code is an alternative when you need to have a dynamic search specification. A typical scenario is to use a parameter applet to pass parameters to the report and then fuse the parameters to build a search expression into the ssSearchSpec global variable.
This is done as follows:
1. Override the Start method of the topmost component of the report.
2. Insert a line of code to set the searchspec as follows:
ssSearchSpec=”[End Date]>’”+DateVariable1
This example causes only records with an end date greater than the variable to be returned. The variable can be captured as a parameter to the report.
Sort Specification
Report objects in Siebel Tools can have a sort specification specified. However, this may cause the database to take longer to return the records in the order required. In these cases it may be better to have the report sort the returned data itself. This is only practical for reasonable amounts of data, since beyond a certain point it will take the report the same amount of time to sort the data. The general steps to enable the report to sort in memory are as follows:
1. Place an ssMemoryDataSorter object in the datastream slot of the report section.
2. Place the datastream from the ROL file in the Input slot of the ssMemoryDatSorter object.
3. Override the Compare method of the ssMemoryDataSorter object, then sort on the same fields that were in the sort specification property in Siebel Tools. For an example of the code to be placed in the Compare method, refer to the Siebel Bookshelf > Reports Administration Guide > Sorting Records in Memory .
When specifying sort specifications, especially on large tables, consider the same recommendations detailed in the previous section, Search Specification on Business Component, regarding indexes, and be aware that sort specifications affect the ORDER BY clause in the SQL statement generated.
NOTE: This approach should be used with caution. If the report is to retrieve large amounts of data, the execution may take a very long time and could even exhaust all the resources on the Reports Server machine.
Another important point is that the ssMemoryDataSorter object cannot be used on the master datastream of a master-detail report. For more information, please refer to “FAQ 1580: Why does adding a MemoryDataSorter component in the master report section of a master-detail report cause the detail records of only the last parent record to be displayed in the report?” available on SupportWeb.
Fields Specified for Report
When a report is defined in Siebel Tools, a set of Report Field Objects are defined. These identify one business component field to be included in the report. All these fields are retrieved for all records read. By only including the required fields, less data is retrieved from the database and sent to Actuate to be processed.

Dedicated to Rachana Agarwal , who irritated me a lot to write this Actuate page..

Performance issues for Actuate Reports can occur due to a variety of factors. This technical note discusses these factors and concludes with some general trouble shooting steps to isolate which of these factors may be affecting your report performance.
The following topics are detailed in this technical note.
 
• Report Design
• Reports Server
• Network
• Siebel Object Manager
• Volume of Data
• Troubleshooting Steps
Report Design

The report design can have a large impact on the performance of a report. Consider the following points to assess impact on any slow reports.
Search Specification on Business Component
A report processes the records retrieved from the business component. A report can be configured to process only some of the records that are returned by the business component. For example, both male and female records may be returned by the business component, but the report only wants to process the male records. You can configure the report to process records in this way by doing the following:
• Adding code into the Fetch method of the datastream. In this situation all records are retrieved into the report, and only then are they filtered. For this reason, the report may take longer to complete if a large amount of records are retrieved.
• Setting the search specification on the relevant business component.
• Setting the search specification property of the reports object. NOTE: The entire business component is queried without considering the user interface (UI) query when the report is run using this approach.
When specifying search specifications, especially on large tables, it is important to use key column fields whenever possible that match the performance indexes defined against the underlying base table. For best performance the specifications should not only cover all of the key columns for a desirable index, but also cover them in the exact index order. This encourages the database engine to use the index and prevents unnecessary physical sorts in temporary tables. Always be aware that search specifications affect the WHERE clause of the SQL statement generated.
Continued….