Just Analytics Blog | Performance Management News, Views and Op-ed

How to deploy BusinessObjects in a distributed environment (BOE Federation)

Written by Hemanta Banerjee | Oct 21, 2010 2:32:00 PM

Yesterday while talking to one of my shipping customers I realized that a traditional centralized BOE deployment would not work for them. They have multiple offices (Belgium, Luxemburg, Shanghai, Singapore). While the offices are all connected the bandwidth is an issue for them and they would like their users to use the WAN as little as possible.

While having separate deployments for each office is always an option, it also means that each BOE server would need to be managed separately, update reports in 4 places, manage security in 4 places etc. You will get the picture.

This is where Federation comes in. It is a great feature of BOE that allows BI administrators to create a process for copying BI content from one system to another while keeping the systems synchronized. The objectives of Federation are to:

  • Simplify the administration of multiple deployments.
  • Enable the distribution of content and/or security principals across geographically separated repositories
  • Avoid heavy use of Wide Area Network (WAN).

Essentially it is a great way to still manage the deployment in 1 place and replicate the content so that it can be accessed locally by the users. Federation enables administrators to distribute content and implement a consistent rights policy across this organization.One origin site can replicate an object to multiple destinations through multiple jobs. The only restriction is that you cannot replicate replicated content.

There are 2 main design patterns that can be used for such a deployment

  1. Centralized Design, distributed usage - In this business scenario, report creators and designers create reports, universes at the Origin Site. The Destination Sites then pull the content from the Origin Site and then reports are run at Destination Sites. Scheduling is performed at remote sites, instances stay at remote sites where the local databases reside. Localized instances can also be sent back to the Origin Site.
  2. Central Schedule, Distributed Access - In this case, all BI content is managed from a single origin site. This is where the data is and where the scheduling occurs. All pending job are sent to the origin site to run. The instances from the completed jobs are then sent back to the branch sites to be viewed.

Steps to create replication jobs.

Step 1: Create a Replication List on the Origin Site - A replication list is a list of objects to be replicated by a replication job. It only has pointers to the objects (reports, users, and universes) that have been selected for replication.

 

Select the objects to be replicated. If you want to replicate the entire repository then just select Replicate All repository objects and click save.

Step 2: Create a Remote Connection on the destination site - Remote Connection objects contain the necessary information to connect to the remote BOE Server. this is The remote connection is create in the destination site. The remote BOE deployment is always considered the origin site and the BOE deployment where you create the remote connection object is always considered the destination site.

 

Step 3: Create a replication job on the destination site - A replication job is used to replicate content between two BOE Servers. A replication job must have the associated remote connection, the replication list.

 

Step 4: Schedule the Replication Job to run on the destination site

Couple of points to note:

  1. Local data source connections have to be defined on the remote site. If the BOE server cannot find the definition of the local connections it will try to run the report against the origin site.
  2. Do not try to use this for moving reports from developments to production. There is a separate LCM utility to do that. Details on that will come in a separate post.
  3. Make sure that proper conflict resolution is set up to handle scenarios where reports can be modified both on the origin and destination site. Ideally the origin server should take precedence and will overwrite the changes at the destination.

More details on this can be found on the SDN website http://wiki.sdn.sap.com/wiki/display/BOBJ/Federation+in+BOE+XI+3.1