There are a couple of things you want to perform as Administrators to manage the Siebel Reporting environment and maintain the BI Publisher reports in Siebel. Here is a list of the tasks that the Administrators should be responsible for.
- Purging Siebel Reports
- Optimize Siebel Reporting Environment
- Enabling Logging for Debugging
Purging Siebel Reports
When the users run the Siebel reports all the generated reports output files will be stored on the Siebel database. These files can be opened from the ‘My BI Publisher Reports’ menu. However, at a certain point of time you might want to delete some of the files due to the size of keeping all the reports on the file system and also due to a compliance matter.
You as Siebel Administrator can purge such report files from the Siebel database using filters or by running a workflow process. I’m going to talk about how to set up reports to be automatically or manually purged.
Automatic Purge
You can set up to automatically purge your reports from the Siebel database after a specified time interval. The ‘BIP Delete After Days’ system preference allows you to specify any non-zero positive value that executes the Auto Purge workflow to purge the reports. Based on the value that you enter, the reports are purged from the database after the number of days specified.
To automatically purge reports
- Log in to the Siebel application with system administrator privileges.
- Navigate to the Administration - Application screen, then System Preferences view.
- In the System Preferences list, select ‘BIP Delete After Days’, and change the value to any positive nonzero value.
By default, the value is set to -1 (minus 1), which means it never purge.
- Navigate to the Administration - Server Management screen, then Jobs view.
- Add a new job
- Click the search icon to select ‘Workflow Process Manager’
- Click 'New’ button to add a Job Parameter to the job
- Select Workflow Process Name for the name
- Type ‘XMLP Purge Records’ as the value
- Click Submit.
Alternatively you can schedule this job to run periodically using the Siebel workflow, see Siebel Business Process Framework: Workflow Guide for the detail.
Manual Purge
When manually purging Siebel reports, you can specify criteria by which the reports are purged. Reports meeting that criteria will be removed from the Siebel database. You can also purge multiple reports together by selecting a date range, the reports that were generated within the specified date range will be purged. If both the report name and the date range are entered, then only those reports with that name and that were generated within that specified date range are purged. You can also purge reports for a specific user by entering his/her user ID as the criteria.
To manually purge a report:
- Log in to the Siebel application with system administrator privileges.
- Navigate to the Administration - BIP Reports screen, then Purge Administration view.
- In the Purge Administration form, you can select a report name, type From Date, To Date, and select User ID. You don’t need to fill all of them. Whatever you enter will be used as a criteria to select the reports to be purged.
- Click Run.
The reports that meet the specified criteria are purged.
Optimizing Performance for Siebel Reports
Now the next topic is to optimize the Siebel Reports runtime environment to have better performance and scalability. There are several attributes that you can use to best fit to your reporting and system requirements from performance and scalability perspective.
Here is a list of the attributes.
- Report Execution Wait Time
- Server Request Processor Wait Time
- Setting Concurrency Parameters
- Max Fetch Size (DSMaxFetchArraySize) for Large Data Volumes
- Enabling Scalable Mode
Execution Wait Time
By setting this threshold value you can cancel some of the reports, which would take longer than the specified time duration, to run. In some cases some reports might take a long time and when you have multiple reports taking long time at the same time other users might have to wait for those reports to finish the jobs. Typically such long running reports should be executed at when most of the users are not accessing such as at night time as a batch process, but there is no control to prevent the users to run such reports as long as they have access to them. So you can use this attribute to control such.
Here is a list of the steps to set the Report Execution Wait Time for Siebel Reports
- Navigate to the Administration - Application screen, then System Preferences view.
- In the System Preferences list, select BIP Report Wait Time, and then change the value to any number greater than 100. By default, the threshold is set to 100 seconds.
Setting the Server Request Processor Wait Time for Siebel Reports
Some times your database doesn’t respond due to heavy duty work currently being performed at the database or simply not available. Or there is a quick temporary issue on the network. Whatever the reason your report request trying to access to the database might not getting any response back. Typically the applications try to reconnect to the database after a certain waiting time. You can control this waiting time with this setting.
Follow the steps below to set the Server Request Processor Wait Time for Siebel Reports
- Navigate to the Administration - Server Configuration screen, Servers, and then Components view.
- In the Components list, select Server Request Processor (alias SRProc).
- Scroll down and click the Parameters subview, and then click Hidden.
- In the Parameter list, select Database Polling Interval, and change value from 10 to 1. The Value on Restart and Default Values are updated as well.
- Restart the Siebel Server.
Setting Concurrency Parameters for Siebel Reports
You can set a maximum number of tasks per XMLP Report Server, which is not the BI Publisher Enterprise but it’s the engine that takes care of the report request and response within the Siebel, per a single Siebel server. Also you can set a maximum number of MT (Multi Threaded) Servers per a single Siebel server.
Typical guideline would be:
- MaxTasks = peak (concurrent users)
- MaxMTServers = MaxTasks / 100
So, for example, let’s say you have 1000 users accessing to the reporting at the same time then the MaxTasks would be 1000 and the MaxMTServers would be 10. Note that this is a generic guide line and these numbers should not be used as a static number for your environment. Each environment and reporting needs would impact on the above numbers and requires a series of performance testing to come up with the best numbers.
You can follow the steps below to set concurrency parameters for using the GUI
- Log in to the Siebel application with administrator privileges.
- Navigate to the Administration - Server Configuration screen, Servers, and then Components view.
- In the Components list, select XMLP Report Server.
- Click on the Parameters view tab and set accordingly.
Optimizing Performance of Siebel Reports for Large Data Volumes
When you have a large data coming back for your reports then you can set a Data Source maximum fetch array size (DSMaxFetchArraySize) profile parameter value to ‘-1’ so that the size is unlimited. But again, this value should be fitting to your specific environment so you might want to increase the value to a certain threshold instead of setting it as unlimited.
You can follow the steps below to optimize performance of Siebel Reports for large data volumes
- Navigate to the Administration - Server Configuration screen, Enterprises, and then Profile Configuration view.
- In the Profile Configuration view list, select Server Datasource (alias ServerDataSrc).
- Scroll down to the Profile Parameters, and then click Advanced.
- In the Profile Parameters list, select Datasource maximum fetch array size (alias DSMaxFetchArraySize), and then change the value to -1.
- Restart the Siebel Server.
Enabling Scalable Mode for Siebel Reports
When you have a large data volume or have complex XSL transformation logic you might want to enable BI Publisher’s XSLT engine to be scalable so that the engine will transform the raw data to XSL-FO template and generate the final output by using the hard disk instead of loading the file onto the memory space. In this way you can avoid ‘out-of-memory’ related issue at the BI Publisher’s reports generation process. You can enable the scalable mode parameter by configuring the BI Publisher’s configuration file, xdo.cfg file, which is located under the %JRE_HOME%\lib directory, where JRE_HOME is the one used for BI Publisher Enterprise Server.
To enable scalable mode for Siebel Reports
- Navigate to the jre\lib installation directory.
NOTE: The path for the Java installation folder varies depending on where you installed JRE. - Open the xdo.cfg file, and in the <Properties></Properties> tag, use the following syntax to set the Scalable Mode property to true (if not already set):
<property name="xslt-scalable">true</property>
NOTE: You can set Scalable mode to either true or false. - Save the xdo.cfg file.
- Restart BI Publisher Server
Next
There are a few other critical things you can do as an Administrator such as Migrating the reports from Development environment to QA/Production environment, Enabling Logging for Debugging.
But that’s it for today and I will talk about such topics tomorrow, so stay tuned!
