Best Practices for using the Import Wizard to migrate Repository Objects across SAP Business Objects XI 3.1

• The Import Wizard in Business Objects Enterprise uses a combination of CUID(Cluster Unique Identifiers) and Object Names to move or update Objects from a Source 3.1x/XI-R2 Environment to a target 3.1x/XI-R2 environment.

• When moving the objects over, there are three distinct scenarios that determine how the import wizard would migrate the objects over -

          a.   The object to be migrated has the same CUID and same Object Name in both the source and the Target Environment.

          b. The objects to be migrated has the same CUID but different Objects Name in the Source and the Target Environment

          c. The object to be migrated has different CUID but the same object Name in the source and the Target Environment.

• The newly created target environment i.e. a new CMS would not have any objects and hence the three scenarios would not apply to such an environment. The import wizard can be used to move objects to a newly created target environment without being concerned about the three scenarios above. However, successive migrations after the initial move will require keeping the above scenarios in mind prior to moving the objects over.

•  The import wizard allows for two options during the migration phase of the objects from a source to a target environment - 'Merge' and 'Update'. In a environment that has been managed in compliance with Best Practices, scenario (2.a) in the above would always exist i.e. CUID and Objects names will always be in sync. In such a scenario, using either a Merge or Update options should produce identical results.

•  However, in a target enviornment, that has been updated with incosistent sources, scenarios (2.b) and (2.c) can exist. In order to avoid this situation, it is good to comply with the following best practices -

• Ensure that the source and target environments are always in sync. This can be accomplished by using a single tool to perform the migration e.g. always use the Import wizard to carry out the migration.

• Ensure that successive  migrations are performed with the 'update' option of the import wizard. This will ensure that the existing CUID and Objects are updated if they eixst and duplicated are not created.

• Ensure that when using 'biar' files to move the content over, the files are the latest copies from the source system. Ensuring version management of the biar files will help minimize any human errors in the import process when using the biar files. If version management of the biar files is not feasible, switch to online migration from source to target system..

• Always ensure proper backups of the BusinessObjects Enterprise system with a backup copy a CMS database and FRS File System. In the event of inconsistency betweend CUID's and Objects Names between source and target environment, it may be quicker to restore the system from backup then fixing individual objects.

Hope you find this useful.

Cheers,
Umang Patel
+919979084870
SAP BO BI Solution Architect/Consultant

Actions needed when restoring only the CMS database when it is crashed in SAP BI 4.0.

Note:

Only perform this procedure if only the CMS database has crashed. If the database is corrupted or other components have been compromised you must perform a full system restore.
Repair or replace the CMS database host-machine. If replaced, ensure that it has the same system name as the previous host-machine, as well as the same port settings and database credentials.

Note:

If it is not possible to restore the machine using the same name and credentials, you will need to use the CCM to update this database connection information for each node in the cluster and restart those nodes.

1. Stop all BI platform nodes using the CCM.
2. Locate the latest CMS database backup set.
3. Using your database tools, restore the CMS database.
4. Locate the most recent CMS database transaction log—that is, the log that contains transactions performed after the last backup.
5. Replay the entire transaction log for the CMS database.
6. Use the CCM to start the BI platform nodes.

 Once you have verified the system is working properly, take the following actions:

•  Run the Repository Diagnostic Tool to remove any unused temporary files and check repository consistency.
• Any publishing jobs in process at the time the system was backed up will display as failed. Do not rerun these instances, start a new publishing jobs.

Hope you find this useful.
Cheers,
Umang Patel
+919979084870
SAP BO BI Solution Architect/Consultant

SAP BO Disaster Recovery in clustered enviroment

Issue

• Take a backup of the Production System's database and then create a new ODBC connection pointing to this database.
• On a new server that has SAP BusinessObjects XI 3.1 installed, take the existing Server Intelligence Agent (SIA) and then point the database to the prod backup.
• Start up the SIA. 
• In the Central Management Console (CMC) for your DR system, you will now see SIA nodes for the Production System. 
• In the CMC, you will now see the new SIA that you added. 

Cause

• The backup of the Central Management Server (CMS) repository contains remote node information for the existing database. 
• Even though the CMS is using a separate physical database, the remote nodes contained within the metadata will connect to each other and show up in the CMC. 
• They will link each other when the SIA is started on the DR system. 

Solution

• The goal of these steps is to prevent the DR system from connecting to the Prod system. As an added precaution, you can create loop backs in your local hosts file that will return 127.0.0.1 when Production SIA nodes are referenced. 
• Take a backup of the Production System's database and then create a new ODBC connection pointing to this database. 
• On a new server that has SAP BusinessObjects XI 3.1 installed, create a new SIA and point it to the prod backup. 
• Open the Central Configuration Manager (CCM), go to the properties of the newly created SIA. 
• Click on Startup and you should see remote CMS nodes from your production environment. Remove these remote nodes. 
• Start up the SIA. 
• In the Central Management Console (CMC) for your DR system, you will now see SIA nodes for the Production System, you will now have to remove these. 
• In the CCM, create a new SIA with exactly the same SIA name for each of the SIA nodes from your production environment. 
• Once the SIA is created, click delete and then delete it from this DR system. 
• Repeat this until all the production nodes are cleaned up. You will be left with a system that only has DR servers on it now. 

Hope you find this useful.Cheers,
Umang Patel
+919979084870
SAP BO BI Solution Architect/Consultant