• The Input File Repository Directory
• The Output File Repository Directory
• The CMS System Database and Audit Database
• The Operating System’s registry or other configuration files (Most admins opt for a full server backup)
• The SAP BusinessObjects Installation directory  (Most admins opt for a full server backup)
• Any Java Web Application Server (Tomcat) custom settings

Assuming that all the above components are backed-up on a recurring basis and at the same time, Administrators can rest assured that they have the components required to restore their BusinessObjects environment. However, if you have ever been involved in the restore process you might not think it is all that simple.  Depending on the type of restore, the process can be quite daunting. Performing a full system restore, where all of the above components are restored, is the most basic type. A full restore assumes that the entire server, database or file system was lost and only a full restore (to the original equipment) will bring it back to life. However there are two main questions that need to be addressed before a full restore is commenced. First, should I use this process for restoring an individual corrupt or lost info object? Inevitably a power user will “ accidentally” delete a report or a critical Universe will be lost or removed from the repository. When this happens most administrators do not want to fully restore their system to the last viable backup state. This brings us to the second question. What happens to the content that was created or modified after the last full system backup? Executing a full “in-place” restore will likely result in the loss of items modified or created after the backup occurred.  Depending on the number of days or hours between the last good backup and the proposed restore point, multiple new items can be lost. If viable copy of the content did not exist in another location or environment, the restore process has a bleak outlook. In the distant past, the only viable option to this problem was a less than desirable process. Administrators would have to setup a temporary BusinessObjects environment and restore the CMS Database and Input / output FRS directories to the temp environment. The process was anything but straightforward and typically required hacking the CMS database (to remove the server object’s records) and then re-creating the SIA to start the temporary system. The most difficult part of the temporary restore processes was that it was seldom tested and prone to issues.  However, assuming they were able to give the temporary system life, a simple Import Wizard migration could then be used to restore the lost item.

Starting with BusinessObjects XI R2 administrators had a new option where they could utilize the Import Wizard to create a Business Intelligence Archive (BIAR) file that could be used to store a portion of the CMS System Database and Input / output FRS in a portable file. Administrators could now access their BusinessObjects environment on a daily basis, generate an export of their critical BOBJ content and save it for a rainy day. While this seemed like the answer to a long awaited question, there were a few problems with the solution. First, most BOBJ administrators did not have the discipline to routinely backup their system. Second, large repositories (2 GB+) were just “too large” for this to be a practical solution.

With the release of SAP BusinessObjects 3.x, a new biarengine.jar library was introduced. This library could be executed at the Java command line and utilized to generate .BIAR files based off a CMS SDK pseudo SQL statement. Because it was driven at the command line, it could be scheduled or utilized in custom applications to generate .BIAR files. Depending on the requirements and size of the repository, this command line could be utilized to schedule the export of objects on a recurring basis. In the event that a single object needed to be restored, Administrators could utilize the Import Wizard and the .BIAR file to restore any missing objects. It could also be utilized to restore multiple objects in the event of a complete repository loss as well. With the combination of the complete system backup (Managed by the server Administrators) and scheduled .BIAR file extract, Administrators now had a viable process to recover from any type of failure.

There are, however, a few limitations to utilizing the biarengine.jar or .BIAR files in general. If you search the SAP notes database you will find note 1219208 which indicates a 2GB limit for the size of .BIAR files. This is not exactly 100% true today.  Both the biarengine.jar and Import Wizard in later versions of 3.1 and 4.0 will automatically split the .BIAR file into 512 MB files. I have generated an export of over 9000 info objects (reports and Universes) that resulted in 3.7 GB of .BIAR files (8 total files). I had no issues with files of this size when restoring from the Import Wizard. However, SAP tends to state that .BIAR files are not intended to perform backups therefore use caution with this processes if you have a large repository. If you find that you are having issues with large exports, you can look at altering the command line options and run multiple passes with smaller sets of objects in each batch. In short, use the where clause of the CMS pseudo query to limit the size of each pass. I will also state that the biarengine.jar runs under java. If you utilize the 64-bit version of the JRE to execute the biarengine.jar, the process Java heap can go well beyond the 2GB barrier of a 32-bit process.  For large repositories, the export process can take several minutes or hours, but I seldom have any issues.

With the initial release of SAP BusinessObjects 4.0 the biarengine.jar method was considerably less useful as a backup tool. The biarengine.jar still exists in 4.0 but until SP4 only the biarengine.jar command line could be utilized to import the .biar files that it generated. The import processes of the biarengine.jar required that everything be re-imported. There was no GUI to allow Administrators to restore just one deleted report. Much like the full restore scenario, this was not a viable solution assuming content had been modified following the .BIAR file export. Starting with SP4, the LCM could also be utilized to import biarengine.jar .BIAR files, but again it required that every object in the .BIAR file be re-imported.  It appears that SAP’s overall strategy relies on forcing Administrators to the LCM to promote objects. I personally think this is a huge mistake because the LCM is a really poorly implemented product. In addition, they unwittingly broke the .BIAR file restore processes by forcing all objects to be restored when re-importing. I would be completely content using the LCM if SAP would simply allow Administrators to restore a single object from a BIAR file. However I suspect that the LCM object dependency algorithms are the leading reason that everything in a BIAR must be imported.

In 4.0 SAP also created the LCM_CLI.BAT file (Command line) as an alternative to the biarengine.jar. It is a similar command line utility but it generates the next generation .BIAR file called a .LCMBIAR file. Much like the biarengine.jar command line it too will force Administrators to import all objects in the .LCMBIAR when using the LCM to restore its contents. You can review the SAP BusinessObjects 4.0 SP5 Administrator guide for more details. I personally don’t like the LCM_CLI because it generates an automatically named job in the promotion management folder each time it is executed. This will lead to a proliferation of LCM jobs that will require Administrators to routinely delete them. Jobs are generated as objects and not instances; therefore the standard instance limit options do not apply.

Until recently I thought all hope was lost in finding an out-of-the box simple and incremental BusinessObjects 4.0 restore solution. However, I recently found a posting on SAP Idea Place (Concerning the LCM) where someone listed a hidden command line option for the Upgrade Management Tool (UMT). The UMT was the version 4.0 replacement for the long-lived Import Wizard. The UMT is locked down and will only allow Administrators to connect to a source repository running XI R2 or XI 3.1 and a target repository running BOE 4.0. In short, it could only be utilized to migrate (upgrade) from a prior version of BusinessObjects to the new version 4.0.  Administrators could also use the UMT to import .BIAR files generated in XI R2 or XI 3.1 versions of the Import Wizard or the 3.1 biarengine.jar Command Line Interface (CLI). As I found in the posting above, there was apparently no technical reason that SAP prevented the  UMT from being utilized to migrate content from one 4.0 system to another. By simply adding an extension to the UMT startup command line, Administrators can now disable the version checking option within the UMT. Below is an example of the option that can be added to the startup.

-jar upgrademanagementtool.jar -internal_use_only_noversioncheck

The fact that the name of the extension includes the words “internal use only” makes me think that it is an extension that is untested or unsupported. I also wonder if SAP was simply playing nanny and forcing Administrators to use the LCM for 4.0 to 4.0 migrations. Assuming that there are known issues, A strong technical explanation on why the UMT should not be used to promote content would be very welcome. SAP Note 1797144 states that this is not a supported means to promote content from one 4.0 system to another 4.0 system (live to live). However there are no mentions of this being an issue when importing .BIAR files generated with the 4.0 BIAREngine.jar CLI.

Assuming that there are no side effects in using the “no version check” extension, it is now possible to use the UMT to incrementally import objects within .BIAR files generated with the 4.0 biarengine.jar CLI. Based on testing, this process works without any apparent side-effects. Administrators can now develop a batch or shell script to automate the backup of their repository on a recurring basis. By adding the above extension to the UMT startup, Administrators can leverage the UMT to import one or more objects from a version 4.0 .BIAR file.

As I have stated in the article there are potentially a few limitations to using the biarengine.jar file as a backup tool. Attempts to export large repositories in a single execution of the script might fail due to their size. In addition, they might require hours to execute. However, an experienced Java developer should be able to leverage the BusinessObjects SDK and the biarengine.jar to create smaller and smarter extracts of the content for large repositories. For smaller repositories the biarengine.jar has proven to work as a viable backup tool. However, it should not be the only tool used in your backup strategy. The key items I listed at the beginning of the article should be backed up to disk or tape frequently. Regardless of the size of your repository it is still best practice to back up the system using your IT department’s approved tools and methodologies. However adding the biarengine.jar export script to your strategy will give you more flexibility when choosing how to restore lost or corrupt content.

If you would like to see an example Windows .BAT file program I created, please contact me via Twitter @jdh2n or on Linked In . I also have it available on the BOB Board Download Section. The example scripts I provide is only setup to backup < 500 MB of content. If you have more than 500 MB of content, you will need to make changes to the script.

Links and other great sources for BusinessObjects Backup information:

Raphael Branger’s Backup and Recovery in BO 4.0 Article

Michael Stamback’s BusinessObjects Enterprise XI 3.1 Backup and Recovery Best Practices

APOS Storage Center

Example CMS Queries:

Select only Crystal Reports and Web Intelligence reports within the Public Folder Hierarchy, excluding report instances

SELECT * FROM CI_INFOOBJECTS WHERE DESCENDENTS(“SI_NAME=’Folder Hierarchy'”, “SI_ID=23”) AND SI_KIND IN (‘CrystalReport’, ‘WebI’) AND SI_INSTANCE = 0

Select all objects in the User Favorites Hierarchy

SELECT * FROM CI_INFOOBJECTS WHERE DESCENDENTS(“SI_NAME=’Folder Hierarchy'”, “SI_ID=18”)

Select all objects in the Inbox Hierarchy

SELECT * FROM CI_INFOOBJECTS WHERE DESCENDENTS(“SI_NAME=’Folder Hierarchy'”, “SI_ID=48”)