Business Objects FRS Pruning

Hello Techies,

This is the continuation of Business Objects File Repository Servers Blog and we are going to see how to optimise the File Repository Servers by FRS pruning.

Have you ever got the chance to see how a Crystal or WebI document or Instance stored internally in the File System? Here it is.

The document will be saved internally in the file system with in one or more folders named based on random name generation.
What will happen if the report or the Instance deleted?

The report or the Instance alone will be deleted and leaving the temporary folders as it is. As a result of this over the period of time, there will be thousands of folders in the FRS and will be a intricacy for the Administrator when he goes for the FRS Backup. The Backup process will be very time consuming as well as occupy more space and finally the FRS will be inefficient.

How to get rid of this?

The “-Prune” command, added at the end of the command line of the File repository servers will be handy at this moment.

Working with FRS Pruning and Tracing

-Prune command, added at the end of the command line of servers triggers the server to go through the ‘Input’ or ‘Output’ folders in the internal ‘Filestore’ folder of Business Objects Enterprise to clean up all the empty directories.

-Trace command, added at the end of the command lines of the servers logs the activity of that specific server in the ‘Logging’ folder of the BOE installation directory.

We need to periodically delete the empty FRS directories to cleanup the disk but not to be manually. Instead the FRS server should be started with the -Prune command line switch. When this switch is used, the FRS servers’ status will remain ‘Starting’ till the deletion is done. Once deletion is done, the servers will stop. The -Prune switch will have to be removed manually to allow the servers to start normally.

Working with FRS Pruning and Tracing

Add -Trace and -Prune

1. Stop File Servers (both IFRS and OFRS) in CCM (XIR2) or in CMC (XI 3.x).

2. Add -Prune command at the end of the line to FRS (Input and Output) and also –Trace Command at the end of the line to check it is cleaning up files and folders that are empty.

3. Start the servers and Monitor the pruning process, you should gain more hard disk space.

Remove -Trace and -Prune

1. Stop the Servers and remove -trace and -prune commands from the command line Parameters of FRS.

2. Start the Servers again normally.

Viewing Log files

You can find the log files in the below location (for XI 3.x)

C:\Program Files\Business Objects\BusinessObjects Enterprise 12.0\Logging

Points to remember

• After the Pruning process if any empty folders still exists, they may be used by BO to keep for its housekeeping process.

• Don’t leave the prune option enabled even after the prune completed. Once pruning completed successfully the FRS will be stopped. We have to re-modify the command line by removing –Prune and -Trace and Server has to be started manually.

• Pruning process does not clean-up any CMS object that lost the FRS files that they need to point to.

Please Note -Prune is an undocumented feature in Business Objects.

We will see more about the Business Objects Servers Tuning in the upcoming blogs.

Happy Blogging!!  Keep reading!!

Business Objects File Repository Servers

Functions of File Repository server (FRS)

The BusinessObjects File Repository Servers(FRS) are responsible for listing files on the server, adding files to the repository, and removing files from the repository. FRS also responsible for the creation of file system objects such as exported reports, and imported files in non-native formats.

Default FRS location in BOE Installation?

FRS can be found on your disk at \Program Files\Business Objects\BusinessObjects Enterprise 12\FileStore (for XI 3.x) in default installation. The two main directories under this location are Input and Output. The Input directory stores the report templates and thumbnail images, while the Output directory stores the results from running those templates. Thus, the Output directory is normally many times larger than the Input directory. Each of these directories is managed by its own BO XI File Repository server.

In every BusinessObjects Enterprise implementation there is an Input and an Output File Repository Server. Both manage their respective directories and handle all aspects of file management.

Input FRS

The Input File Repository Server manages all of the report objects and program objects that have been published to the repository. It can store .RPT, .CAR, .EXE, .BAT, .JS, .XLS, .DOC, .PPT, .RTF, .TXT, .PDF, .WID files. In the case of .RPT files, they are stored as report definition files only which do not contain any data.

The Report Properties page of the CMC shows you the location of the Input report files. The RPT report template can be found at frs://Input/a_084/004/000/1108/ca067d4f1710cbc.rpt

Exploring to this location shows two files: the RPT file with the name indicated on the report properties page of the CMC and a JPEG file, which serves as the thumbnail image.

Output FRS

The Output File Repository Server manages all of the report instances (saved data copy of the report) generated by the Report Job Server or the Web Intelligence Report Server, and the program instances generated by the Program Job Server. It also manages instances generated by the Web Intelligence Report Server and the LOV Job Server. It can store the following files: .RPT, .CSV, .XLS, .DOC, .RTF, .TXT, .PDF, .WID. For .RPT and .WID files are stored as reports/documents with saved data.

Since Output FRS stores the report instances, deleting instances would remove instances not the actual reports. However the report structure will be stored in the Input FRS.

Using Query Builder we can find the location of the Output File repository files. The following query may be handy if you already know the report name.

SELECT SI_NAME, SI_KIND, SI_FILES, SI_INSTANCE from CI_INFOOBJECTS
Where SI_NAME =’xxxx’

If the SI_INSTANCE value is false then the InfoObject is the actual report and SI_PATH will be in Input FRS. If SI_INSTANCE is true then the InfoObject would be an Instance and the SI_PATH will be in Output FRS.

Exploring to this location shows the actual instance file pertaining report data with the appropriate export format based on the scheduling parameters.

Diagnosing File Repository Servers

Repository Diagnostic Tool (RDT) is a command-line tool that scans, diagnoses, and repairs inconsistencies between your Central Management Server (CMS) system database and the File Repository Servers (FRS) filestore, or inconsistencies that can occur in the metadata of InfoObjects stored in the CMS database. This inconsistencies may occur during unexpected events such as disaster recovery, back-up restoration, or network outages. During these events, the CMS system database may be interrupted while performing a task. This can cause inconsistencies with objects in the CMS system database.

List of inconsistencies that could potentially occur in repository which RDT can identify are

Inconsistency	Description	Repair Actions
InfoObject exists, but no file	It is possible that an InfoObject exists in the CMS, but there is no file FRS	Delete the InfoObject, unless otherwise told
File exists but no InfoObject	It is possible the file exists but there is no corresponding InfoObject	User is notified to republish the object
Invalid Parent ID	An InfoObject can potentially have an invalid parent reference	The object and its children will be moved Into a folder call ‘Repair’.
Last Successful Instance	The reference to the last successful scheduled instance could be invalid	Remove the ID and let the CMS automatically recalculate it
Invalid Target ID	A shortcut could be pointing to an invalid object	The shortcut object will be deleted, unless told otherwise.
File size is wrong	There can be information discrepancies between the InfoObject and actual file	Update the InfoObject
Empty folders in the system	There may be empty folders due to old objects	Remove the empty directories, unless otherwise told.

Limitations for File Repository Servers

• The Input and Output File Repository Servers cannot share the same directories. This is because one of the File Repository Servers could then delete files and directories belonging to the other.
• In larger deployments, there may be multiple Input and Output File Repository Servers, for redundancy. In this case, all Input File Repository Servers must share the same directory. Likewise, all Output File Repository Servers must share a directory.