#layout.single-post .dfd-single-style-advanced {

margin-top:0 !important;
margin-bottom:0 !important;
}
#layout.single-post .dfd-single-style-advanced {margin-top: 0 !important;margin-bottom:0 !important;}
h1.page-title {font-size: 30px!important}

1.0 Introduction

The objective of this article is to share an interesting activity on migrating IBM Cognos (Cognos) reports to Oracle Business Intelligence Enterprise Edition (OBIEE) for a leading financial service client (Client).  The client was using Cognos extensively for their financial management reporting areas.  As they were not getting the intended results out of Cognos, they decided to move onto OBIEE not only to get a holistic view of their financial reporting pack at enterprise-level but also to align with their corporate reporting strategy.

Just to let you know, these two BI tools (Cognos and OBIEE) uses a different frame-work altogether. So, achieving a 100% automation on migration is not possible. However, with the help of Java APIs and Unique Processes, many of the manual efforts have been automated resulting in almost a 35% saving in terms of cost, efforts and timelines.

Some of the other things to be noted:

Some of the high-level migration steps followed:

Now, let’s talk in detail about the migration process which has been divided into three stages – (1) Identification (2) Evaluation (3) Implementation.

2.0 Identification

This particular step played a crucial role in eliminating un-wanted/duplicate reports and migrate only the reports that are actually being used by Business Users, from Cognos Connection Catalog.

Reviewed the list of identified reports for enabling Security both at Object and Data levels and categorise them into business-area wise.

3.0 Evaluation

Based on the list of migrated reports, an evaluation strategy prepared with the help of Business Users to determine:

3.1 Manual Process

High-level manual steps for migration:

3.2 Automation Process

High-level automated steps for migration:

As you may be aware, Cognos uses Java programming interfaces for managing its meta-data. A custom Java API has been developed to:

With the help of the above automated steps, a good amount of information on reports has been gathered which not only helped for a realistic estimation but also to migrate the reports to OBIEE in a structure manner.

Another task was to identify a relational DW model requirements by analysing different objects based on the below diagram:

The most challenging task was to migrate Cognos Cubes to relational dimensional models in Oracle DW environment. To support roll-ups and high-performance, a number of aggregates and hierarchies have been built in OBIEE RPD.

4.0 Implementation

This section talks about implementation which has been carried-out in three phases:

4.1 Datawarehouse Customisation and ETL Development

Based on the evaluation processed in (2) above, the immediate task was to develop a relational model requirements using ETL tools and database objects with features like partitions, etc.

4.2 OBIEE RPD Development

Based on the design and development of Oracle Datawarehouse, OBIEE RPD has been developed to support:

5.0 Benefits

To summarise, the entire activity has been completed in 24 weeks to migrate 200 Cognos reports along with 4 cubes and with resources as follows:

Migrating from Cognos to Oracle Business Intelligence resulted in a multitude of benefits for a customer including cost savings and increased business value.

To realize these benefits at the lowest possible cost, it is extremely important to follow a best and proven migration method and technical best practices developed through experience.

This blog outlined a proven-process that used automation techniques along with manual processes as well as a case-study of customer that have achieved the success after migration from Cognos to OBIEE.

If you need more information, please do not hesitate to contact us at +44 (0)207 7780091 or info@reliason.com. Alternatively, visit us at www.reliason.com to learn about how we can help your Organisation on Oracle BI technologies and to access our whitepapers and test-drives.

The post Migrate IBM Cognos Reports to Oracle Business Intelligence Enterprise Edition appeared first on Reliason.

margin-top:0 !important;
margin-bottom:0 !important;
}
#layout.single-post .dfd-single-style-advanced {margin-top: 0 !important}

As you may be aware, Oracle released its latest BI tech-stack version 12c during October 2015 which is packed with abundant new enhancements and stunning new visualisations. The latest version is 12.2.1.0.0 and you can visit OTN page to learn more about it.

Here’s a quick snapshot of its features:

To learn more about OBIEE 12c features, check Oracle’s documentation.

This blog talks about all the detailed steps involved upgrading your OBIEE 11g tech-stack to 12c version.

Basically, the upgradation is a two-step process and is carried out by using BI Migration Script (migration-tool.sh):

The BI Migration Script is used to generate the BI Migration Tool jar file.

2.0 Migration Process Steps

The entire migration process is covered by these high-level steps with more details in the later sections:

One important note to mention here is – it is going to be an Out-of-Place upgrade meaning you will be installing a new OBIEE 12c environment and then migrate metadata from OBIEE 11g environment. The new OBIEE 12c instance can be installed alongside the existing OBIEE 11g instance. Having both OBIEE 11g and OBIEE 12c instance also gives an opportunity to validate the reports in OBIEE 12c side by side with OBIEE 11g.

2.1 Pre-requisites

Take a quick look at these pre-requisites as these will help in achieving a smooth installation and avoid further re-works during the migration process:

2.2 Generate BI migration to .jar file

The BI Migration Tool is self-executing and self-contained. You need to generate BI Migration Tool jar file by using BI Migration Script (migration-tool.sh). This tool will copy the RPD and Catalog along-with the necessary files so they can be used in 12c environment.

Follow these to generate BI migration tool jar file:

Replace the ORACLE_HOME with the actual path to your 12c ORACLE_HOME which is created during 12c installation.

2.3 Creating Export Bundle

The export bundle is a ‘.jar’ file and consists of the metadata information from the 11g Oracle home.

To create an export bundle:

Following is a sample command for creating an export bundle:

2.4 Import Export Bundle

You need to follow the below procedure only if you are configuring 12c system for the first time.

If you have already configured 12c system, you will have BI Domain and BI Service instance created. Now, need to perform the procedure to import the export bundle using the BI Migration Script.

Steps:

The Configuration Assistant starts and the Welcome screen is displayed.

The Prerequisite Checks screen is displayed.

The Database Schema screen is displayed.

2.5 Perform Import using BI Migration Script

Use the BI Migration Script (migration-tool.sh) to import the 11g data in to the 12c system, if we have already configured the 12c system. The BI Migration Script automatically determines the Oracle home and the Domain home directories.

To import the metadata in to the 12c system:

2.6 Validate Oracle BI Deployments

Now we can logon to OBIEE12c and see the Reports and Dashboards working. We can use 11g weblogic password and the Dashboards and Reports should work

3.0 Post Migration Steps

After completing the data migration for Oracle BI EE, manually migrate the configuration settings for catalog groups and other components such as security for WebLogic and Enterprise Manager, BI Server, and BI Presentation Services.

Below are the post migration steps need to be performed after the upgrade:

For detailed instructions on post migration steps please refer to oracle’s documentation.

The post Upgrade OBIEE 11g to 12C appeared first on Reliason.

The redshift cluster was made up of 8 dc1.large nodes, which provided an approximate equivalent to their existing Oracle RAC cluster in terms of CPU and Memory, as well as using SSD storage.

Migration to Redshift

In the interest of time, we decided to export one of the clients smaller star schemas in terms of number of dimensions, but one which contained a suitably large row set to give some meaningful performance results. The Star schema we used was based on site visit analysis, and contains 4 dimension tables, 1 bridge table, 1 lookup table and 1 fact table. There is also a view overlaying the fact table which provides some in-DB calculated fields. The model is displayed below.

To get the data into Redshift we generated a CSV export of each table, split these into 16 chunks each and then posted these to S3. We then used the Redshift copy command to load them into the a schema called tableau in the database. For the time being the tables in Redshift were creating using equivalent DDL as per their existing database, but without any performance enhancements, e.g. no compression, sort or distribution keys.

Configuring Tableau

The first thing we needed to do was to download the Redshift drivers. As the user base was large Apple Mac based we fetched the driver from http://docs.aws.amazon.com/redshift/latest/mgmt/install-odbc-driver-mac.html
Once installed, you can then Start up Tableau and create a connection to the database.

Once connected you can select the tableau schema from the drop down, and the list of available tables and views will display. We can then configure the Data Source by selecting the tables/views we want to perform analysis against, configure the join between them, and add any appropriate calculated fields and filters. We’ll start off by
building a straightforward analysis on the number of visits by property for 2014.

We’ve added two calculated fields, ‘Total Visits’ and ‘Visit Group’. Total Visits is simply a count against the table’s primary key. Visit Group is a way of classifying the popularity of each site, and uses some logic against the Total Visits field to identify if a site has a large number of visits. We define it as:

Finally, we add a filter against dim_date to restrict the output to 2014.

You can then test validity by clicking Update Now, which will return a rows set for the query.

Visualisation

Now that we have a data source defined, we can create a visualisation for it, using Tableau’s built in set of graphical options. If we click on Sheet1, we are presented with a blank worksheet, and the dimensions and measures from the data source we just defined:

We’ll start by creating a pie chart analysis show all the visits against sites classified as ‘Large’. For this we require at least 1 dimension and 1 measure (for this example we’ll use Property Name and Total Visits). We first drag the measures and dimensions into the Marks panel. We’ll display each property slice in a different colour, as well as show the property name next to the slice, so we move Property Name on the Color and Label sections. We would like the number of visits to be reflected by the size of the slice and also have this display next to the slice, so similarly we drag Total Visits onto the Size and Label sections. So our Marks panel now looks like this:

Next we drag the Visit Group onto the Filters Panel, which allows us to restrict by Large sites:

Finally, we want to have the year displayed above the Pie Chart, so we drag the Financial Year dimension into the Columns section, and we’ll add a title. The Pie Chart renders like this:

To ensure this is returning sensible results, we’ll run a query against the database to validate:

Looks good! So whilst this is only a basic analysis, it’s a good start to show that we can start running our existing reports against Redshift with little or no modification.

The post Tableau for Desktop and Server/Dashboard analysis appeared first on Reliason.