Leveraging the OBIEE 12c Baseline Validation Tool.

By: Vlamis Staff
February 25, 2016

Oracle came out with an awesome tool for regressing testing and verification of OBIEE lifecycle and migration. This is the Baseline Validation Tool (BVT). This is a command line tool that is governed by an XML config file to enable you to create a baseline of the catalog and constituent components from any OBIEE system (11.1.1.7.1 forward). Briefly, this tool is run three times in succession in a typical scenario –with command line parameters determining the type of run. The first run is against a running system (OBIEE Instance) that is used as the baseline. The second run is against the “new” version of the OBIEE (e.g. lifecycle promoted, patched or migrated). Both of these two runs collect detailed information from their respective instances. What specifically is collected and where it’s stored is based on configuration parameters in the XML file that is referred to from a command line parameter. Finally the third run compares the details from the first two runs and generates a set of reports that are used to determine what has been added, deleted or changed from the baseline to the modified instance. All this is well documented. One limitation of the BVT is that all tests and catalog items selected for a test must be hand entered into the XML file that governs a BVT run. You can certainly point to the top of your catalog and collect everything, however this can be cumbersome, especially with large catalogs, or catalogs that encompass large, disparate subject areas and owning organizations.

Another way to integrate BVT into your regression strategy without lots of hand editing, or forcing collection over more of the catalog than you may need for a particular test or migration, is to use many XML files, each specific to a subject area, owning organization or other logical division, however on the surface this seems to multiply the effort and time required. If all done by hand –absolutely! However, using the catalog manager and some clever Linux command line tools (also available on Windows http://sourceforge.net/projects/unxutils/ ), you can generate much of this automatically and negate the need for lots of manual editing of XML. Here is an example of what we employ in our regression testing projects:

(prerequisite – generate an XML “template” with the BVT that will be used to seed the generation of XML files specific to catalog trees or groups of components)

Run the Catalog Manager to generate a file with all the catalog elements listed.

Generate an XML file from the BVT that will serve as a template for many XML files to be generated each with a specific catalog area that can be a stand-alone test.

Generate a test file that has groups of the three BVT commands (pre, post, compare results) specific to each catalog tree or other logical division based on your specific testing strategy. i.e a set of BVT commands generated for each catalog area.

Output of the runcat.sh (report option) – captures the catalog tree…

Generic XML template: notice “+++”, “—“ used as strings for substitution targets from a script of sed commands

sed s:—:”/shared/01. QuickStart”:g <testconfig-template01.xml  >QuickStart.xml

sed -i s:+++:”QuickStart”:g  QuickStart.xml

Script to generate the group of XML files: – use a similar script to generate the BVT command files.

Finally, generate a text file that houses the BVT command groups (pre, post, compare results) for each XML file, and therefore each catalog tree.

Template File (used to generate specific BVT commands that can be cut/pasted into the command line or, any or all can be added to a script)

sed  s:+++:”QuickStart”:g  <bvt-command-template.bat >QuickStart-bvt.txt

After sed is run against the template file.

Wrapping up—

You can use the above technique to automate a customized set of regression tests with the BVT specific to your environment and testing policies. While this may seem a bit complicated, you only do this once and then reuse it as long as your catalog scheme is relevant. Even when your catalog changes, all you need to do is add, alter or delete these elements to reflect your new catalog scheme. Finally, there are likely more test case breakouts you may wish to employ with other XML objects and BVT plug-ins or parameters – therefore your needs and imagination are your only limits!

LinkedIn
Twitter
Facebook
Reddit

Related Posts:

Let’s discuss your options

Contact us to discuss next steps.