Page tree
Skip to end of metadata
Go to start of metadata

Product versions:
Business Objects Enteprise XI 3.1

This BOpedia page is provided by the RIG team. Don't hesitate to put comments.
Main Contributors : Patrice Le Bihan, David Gonzalez

This article is part of a series on Federation XI 3.1 :


Getting started

Please read the Working with Federation of the BOE XI 3.1 admin guide.

Process flows

Various components involved in Federation

Process flow diagram for a two-way replication job

A replication job is essentially a BIAR file transferred from one repository to another. It is produced on the origin, transferred to the destination through web service, and imported into the destination repository by the job server. In order to minimize the BIAR file size, only the changes since the last job execution are included. This means only the objects that have changed between the 2 executions and, even better, only the properties of these objects that have changed are actually exported to the BIAR file.

Important concepts and limitations

Only one origin per object

If the same object exists on 2 origin sites, a destination site can only replicate it from one origin. An attempt to replicate it from the second origin will fail. See diagram.

One replication job at a time

Only one replication job can run at a time between one origin and one destination site. On any destination site, we recommend jobs with one given origin should be scheduled at different times. The system will process them sequentially anyways : the Job Server Child (replication sub system) has a lock mechanism in place to enforce this. There is no protection at the Web Service level : nothing really prevents 2 jobs to run at the same time within the consumer or producer web services, but this should never happen because of the lock at the job server child level.

If, on a destination site, 2 or more jobs with the same origin are scheduled to start at the same time, only one job will appear as running. The other jobs will try to run, fail because of the lock, and be back in pending mode until the next retry. Retry intervals are configurable with the ThrottleRetryInterval parameter. You cannot configure the number of retries, the job will keep on attempting to run until it can or someone stops it. See Known issues and common problems with Federation XI 3.1 for details.

One destination site can have multiple replication jobs running at the same time if each is coming from a different origin site. It is also true the other way around : one origin site can process multiple requests from multiple destination sites at the same time.

You can observe the lock from the destination CMC : go to "Temporary Storage" and navigate to the temp folders to find an object named "Replication lock for <origin server name>".

BE CAREFUL when manipulating this lock object, you should never have to manually delete it. Stopping the replication job currently executing should suffice.

no multiple hops

Multiple hops are not supported in XI 3.1. Once an object has been replicated from Origin to Destination, it cannot be replicated from Destination to another Destination. The supported way is to have the second Destination pull the object from the same Origin.

If a replicated object is included in a replication list, the replication will fail with the following error :

Error: Not replicating object to destination: object was already replicated to origin from site ""

See Known issues and common problems with Federation XI 3.1 for details.


During each replication the CUID of the objects will be the same.



ID = 5221, CUID = ATAQnynXGytEvaoce6vQk98

the document doesn't exist yet

Run the federation

Run the federation

ID = 5221, CUID = ATAQnynXGytEvaoce6vQk98

ID = 3986, CUID = ATAQnynXGytEvaoce6vQk98

<=== Previous Article

  • No labels