The thing about OBIEE 11g, is that there is no single way to get things “up and running”. Over the past year I have performed countless OBIEE installs and almost every one has been different to the last, due to infrastructure challenges, scale requirements or requirements for high-availability and server redundancy.

There is little we can do about infrastructure challenges, typically around policies which are in place across the IT estate and must be adhered to. Scale is simple; more users means more or bigger servers. The last point on the list is HA & server redundancy, and this is arguably the biggest area we need to address before punching in “./runInstaller” at the command-prompt.

Mark Rittman is currently pulling a wider blog posts around options for HA & server redundancy, so I’m not about to get into that in this post. What I will share in my first Rittman Mead blog post is something I have been working on recently, that is sometimes implemented as part of a HA/redundancy solution; BI Presentation Server catalog replication.

BI Presentation Server catalog replication is the Oracle supported method of moving a BI Presentation Server catalog from one running OBIEE instance to another. This is useful is many situations namly:

• Release cycle management when specific aspects of the BI Presentation Server catalog need to be moved from one OBIEE environment to another, such as development to testing.
• Full BI Presentation Server catalog synchronization between OBIEE instances to provide two OBIEE instances with exactly the same BI Presentation Server catalog for DR.

The 2nd point above is the scenario I am looking to cover here – using this utility we can make sure the BI Presentation Server catalog on two distinct OBIEE instances are the same. In a DR event we can either point users at the secondary server or reverse this utility to pump the data from the DR server to the primary server after the fault on the server has been cleared.  The RPD and other changes, such as user roles, would be managed as part of the release process and copied to the DR server when they are pushed to the production server. It is only the BI Presentation Server catalog which is constantly changing as the OBIEE instance is used, and therefore only the BI Presentation Server catalog which needs to be constantly replicated.

To set up BI Presentation Server catalog replication, we can use a command-line utility which ships with Oracle Business Intelligence 11g, called either “sawrepaj.bat” or “sawrepaj.sh” depending on your operating system (the two are functionally identical, and differ only in the way they are invoked from the command-line). “sawrepaj” has options to synchronise catalogs between servers, or to simply export a catalog for backups or as part of the release lifecycle; in addition, we can control the grain of what is exported down to an individual catalog folder or file.

The utility runs from the command-line and accepts a number of options, or commands, to specify how the replication takes place, using the following syntax:

sawrepaj.sh [/C path] command [command parameters]

• mark – instruct the OBIEE server to ‘watch’ catalog files and record changes.
• run – run the batch, as defined in the config.xml file.

Before using the utility, we need to create a config.xml file which instructs the OBIEE Presentation Services to record changes, and tells sawrepaj what to do when it executes.

The config.xml file can be placed anywhere in the filesystem and is referenced using the /C switch when calling sawrepaj – more about this /C switch later. The config file tells the sawrepaj utility which Oracle BI Presentation Servers are involved in the replication, and how to access them. The example below includes a source and target Oracle BI Presentation Server – however you could add countless other BI Presentation Servers depending on your environment.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Oracle BI Presentation Services Replication Agent Configuration File -->
<Config>
<General>
<ExportDirectory>smb://path/to/directory</ExportDirectory>
<LogExpiresHours>48</LogExpiresHours>
</General>
<Server name=”serverA" user="weblogic" pwd="Password01">
<Property name= "oracle.bi.presentation.url"
value ="http://servera:9704/analytics/saw.dll"/>
<Property name="oracle.bi.presentation.usesoaptcptransport" value="N"/>
</Server>
<Server name="serverB" user="weblogic" pwd="Password01">
<Property name= "oracle.bi.presentation.url"
value ="http://serverb:9704/analytics/saw.dll"/>
<Property name="oracle.bi.presentation.usesoaptcptransport" value="N"/>
</Server>
<Folderset name="all">
<Folder>/</Folder>
</Folderset>
<ReplicationTask destination="serverA" source="serverB" folders="all" />
</Config>

The three sections of interest in the above file are Server, FolderSet and ReplicationTask. Each

• Server tag points to an OBIEE Presentation Services instance with credentials for a user with has SOAP access.
• FolderSet tag contains a list of Folder tags which detail the folders within the webcat to replicate.
• ReplicationTask contains the instruction of what to do when we run sawrepaj. For the above example, serverA is the target and ServerB is the source.

Before any replication can begin, we need to enable each BI Presentation Server component for replication. Add the below to the instanceconfig.xml file between the <catalog> tags. This needs to be done for all all Presentation Server components, whether source or target for the replication.

<Replication>
<Enabled>true</Enabled>
<ReadLogRecordsSinceHoursAgo>120</ReadLogRecordsSinceHoursAgo>
<RecordsInFileLimit>4000</RecordsInFileLimit>
</Replication>

Now, back to the sawrepaj commands:

mark – The mark command is used to tell tBI Presentation services which webcat files to monitor for changes. We can be as specific as a single file, or as as vague as an entire webcat. You will need to run this on a BI server with the following command:

sawrepaj mark all /

run – The final part of the process, the run command will instruct sawrepaj to run all the tasks in the config.xml file. The below is an example of the command. If your config.xml file is not in the root path of the sawrepaj tool, you will need to specify it’s location with the /C switch. This command can be added to a cronjob, a Windows scheduler or can be ran manually, or as part of another script.

sawrepaj /C /my/config/file/config.xml run

That’s it! Once completed, the above steps will give you all you need to set up full catalog replication between multiple BI servers.