Oracle BI EE 10.1.3.4.1 – Content Accelerator Framework (CAF) Synchronizer – A review/preview – XUDML
Posted by Venkatakrishnan J on May 5, 2009
I have been on a couple of customer calls this month wherein the customer wanted to know a seamless means of migrating their web catalog from one environment to another. The first thing that came to my mind was the CAF (Content Accelerator Framework) that came out a couple of weeks back. Though i had recommended this to the customers, i also informed them of the fact that this was in its first release and hence there are bound to be one or 2 resolvable hurdles. Now that i am involved in creating a couple of custom utilities myself, i thought it was time to check out the capabilities of the utility. This blog entry is a result of that. I must thank Phillipe(CAF PM) and his dev team for working with me on this. There are certain pre-requisites for the CAF to work. Work is under way to update the documentation as well. Following are my findings.
1. CAF is certified to work on 10.1.3.4 and above.
2. CAF requires JDK 1.6 as the active JDK.
3. CAF mandates the use of a Repository with relational objects. If you have Essbase as a data source, it might not work. Though i am not sure about this one as this was the only reason i could attribute to some of my repositories not working with this utility. If you find it otherwise, just leave them in the comments section.
4. I believe CAF does not mandate BI EE itself to be installed using JDK 1.6. JDK 1.6 is required only for the client catalog manager. Ensure that the path variable (on the client catalog manager machine) points to JDK 1.6.
Now lets get into an actual use case scenario. Consider that we have 2 repositories and 2 web catalogs. One is the default samplesales repository and the other is the usagetracking repository provided with the default BI EE install. Now, BI EE provides out of the box web catalog containing reports and dashboards going against each of the repositories. Now our aim is to merge both of them together into a single repository and web catalog. To do that, lets first start with merging the samplesales and the usagetracking repository. This is done using the 3 way merge that i have discussed here before. As a first step, create a copy of the usagetracking.rpd. Once this is done, open the samplesales.rpd as the current repository. Choose the usagetracking.rpd as the original repository.
Now choose the Usagetracking.rpd copy as the modified repository. And also make the necessary mappings to ensure that the merge happens correctly.
Now you should have a merged version of both the repositories.
As a next step, we need to bring in the usage tracking reports into the web catalog of sample sales. So, log into the catalog manager and navigate to the usage tracking web catalog. And choose all the reports that we want to migrate.
This would pop up another screen wherein we would have to choose the source rpd, target rpd (which would be the merged repository in our case). Also an online web catalog would have to be chosen as a target. The major advantage with this migration is that all we need is an access to the target webcatalog (which would be accessed through the same http server port). Also, CAF utilizes another utility called nqXUDMLGen.exe and nqXUDMLExec.exe which are basically similar to the older nqudmlgen.exe and nqudmlexec.exe. The major difference lies in the fact that now the entire repository is visualized as an xsd schema containing references to the actual objects. The xsd schema is given below. And the output of the nqXUDMLGen.exe would not be a UDML text file anymore. Rather it would be an XML file which would be in accordance with the xsd.
Click on next. And select the subject area to which the reports metadata would be mapped to. So, in effect you would have to choose the reports that have their columns within a single subject area in the previous screen. In our case, it would be usagetracking.
In the next screen you would find a mapping between the source report columns and the target metadata. What i would have liked is an automapper if the source and target rpd columns match. Unfortunately, we would have to map this one by one. But to circumvent this, the mapping structure can be saved so that it can reused in future migrations as well.
In the next step, enter the path in the target catalog. This is the path the reports would be migrated to in the target web catalog.
Now, if you open up the target web catalog you would notice that the reports have been migrated successfully.
Though the extent of usage of this utility(customer adoption) is pretty small, the concept this introduces is very robust and can be reused across multiple implementations. This also introduces the XUDML which should give you a sneek peak into the world of 11g. Apart from the installation hassles, this utility does what it promises to do and does it very well. The only hiccup that i see is the Essbase related XUDML issue. But i believe this is something that can be sorted out pretty soon. Hopefully we should see more of similar tools.