Migration from Siebel Analytics to OBIEE

The below text outlines the self-defined process and approach why and how we need to migrate Siebel Analytics to OBIEE . There might be some gaps in the entire definition of the process as the entire view is of mine and I did not face any typical issue while doing the migration , though there are couple of known bugs flying around in OTN discussion forum and in Metalink3 (Oracle Support) . So definitely there must be something !

If there are any specific points(pros/cons) somebody could like to add I will be happy to make the alteration !!!

Introduction

Oracle Business Intelligence (BI) is a portfolio of technology and applications that provides the industry’s first integrated, end-to-end Enterprise Performance Management System, including category-leading performance management applications, MIS applications, BI applications, BI foundation and tools, and data warehousing. Oracle Business Intelligence Enterprise Edition consists of components that were formerly available from Siebel Systems as Siebel Business Analytics Platform, with a number of significant enhancements.

Background

As the “Oracle First” procurement strategy has been defined by some big companies after a close tie up with Oracle hence it force them to decide,move and built the reporting platform on newly release BI component by Oracle called Oracle Business Intelligence(OBI) .This require migration of existing reporting platform from Siebel Analytics to OBI enterprise edition .

Why to Migrate

There are ample reasons to leverage the benefits of new OBIEE framework after doing migration of the existing platform. Some of the benefits have been described below:

User Interface Integration

1) OBIEE is an emerging, popular, enhanced BI system to provide the intelligent interface for both front and back office reporting

2) Oracle BI Enterprise Edition is improved to support the business and technology requirements of application integration, not only from a user and data perspective, but also in the light of business process integration: moving from reactive looking-back-to-what-happened reporting to a pro-active, guiding, alerting intelligent business requirement

3) Technically speaking lots of new feature with the enhancement of existing functionalities have been introduced for better reporting

4) For the benefit of end use business communities lots of flexibility that can be the reason to adopt this

5) Because of the 100% web-based and standards based architecture (SOAP) of the OBIEE platform it is very easy to integrate the OBI Presentation Services with a web based application like Siebel CRM or EBS .

Security Integration

1) Besides the critical requirement of single sign on and authentication, an important and time saving characteristic of a BI Application is the integration with the base application security and visibility rules. Typically large organizations have the requirement to secure company information and transactional data based on not only the user’s role or responsibility (Sales Rep or Sales Manager) in the organization but also on his or her position (CEO vs. CFO ). Based on the user’s responsibility, he should have access to certain analytical content, i.e. dashboards, reports, alerts, subscriptions etc.; based on the user’s position; he should have access to certain areas of the database, e.g. the data belonging to division A or B, team 1 or 2

2) Oracle BI EE fully supports this role and position based security rules using the technique of row-wise initialized session variables and initialization blocks. Upon login and after authentication, queries are being executed against the database in a certain order to retrieve the security information which is stored in session variables like GROUP or POSITION. These variables are then used to control access to objects in the OBIEE repository or web catalog but also to build business model filters to restrict access to critical records. This integration becomes critical in a volatile organization where user change role and/or position frequently

Data Integration

The pre-built Business Analytics Warehouse (BAW) is one single but modular data warehouse model to support one or a combination of the source systems mentioned. The BAW is compliant with the Ralph Kimball dimensional modelling methodology and supports slowly changing dimensions, aggregate tables, hierarchy tables and many others.

Without going into detail the most important characteristics of the Oracle BI EE Platform to support successful BI Applications are:

1) The caching technology which enables a significant performance improvement for standard dashboards and reports

2) The open repository ODBC API which enables other enterprise ODBC compliant tools to access the OBIEE repository presentation layer and therefore the pre-built KPI’s, dimensional attributes, preserving the security business rules

3) The ability to join multiple different data sources and data source types in the OBIEE repository

4) The multilingual capabilities of the OBIEE platform that gives the ability to use it across wide enterprise

5) Ability to use multiple RPD hosted on a single server and distributed across multiple presentation services in parallel which offload a large subject area

Scope

Scope of this document is to orchestrate for key steps while migrating existing Siebel Analytics platform to OBI .However this is very High level plan and lots of dependency and hidden low level strategy need to gradually define. This document is not intended to define the low level features, enhancement, flexibility that has been introduced in latest OBIEE version

Step by Step Activities

There are couple of activities that need to taken care of considering the roadmap of migration from existing Siebel Analytics Platform to Oracle BI EE platform.

Environment

1) Acquiring the latest OBIEE licensed version for client from Oracle . Confirm the version to be downloaded from eDelivery metalink provided URL
2) Removing existing Siebel Analytics installation across all development and test servers and carry out the fresh installation of OBIEE
3) Do the same installation at Performance test environment to check the Single-Sign on features
4) Finally install that into production servers by Oracle Architect and configure the related key business components

RPD Changes

1) Take the latest production copy of RPD at Dev Environment and do the version up- gradation.
2) Do the sanity and consistencies check across all Business model and rectify any repository consistency error, metadata warning etc.
3) Migrate it across test environment and Single Sign-On Performance test environment.

Webcat Changes

1) Take the latest webcat copy for the respective RPD at Dev Environment and do the version up-gradation.
2) Do a sanity check and sort out all the invalid objects and there references, broken links etc after running sawmigrate utility .This need to be taken care of recursively and in reactive approach.
3) Go through all the reports, prompts and links to see everything working properly.
4) Revisit Subject Area, Dashboard, Page, Shared folder, Objects level permissions.
5) Housekeeping for invalid, redundant dashboards/reports/objects.
6) Change the ‘Help Information’ HTML paths aligning with new OBIEE installed folder structures.
7) Migrate it across test environment and Single Sign-On Performance test environment.

Environment Configurations

1) Provides a choice to deploy the Presentation Services and Presentation Services Plug-in either standalone Oracle Containers for J2EE (OC4J) or in Microsoft IIS. If J2EE will be decided to be the container then IIS need to be removed from all environments and OC4J will be act as HTTP Web server to communicate with Oracle BI Web Client .However existing IIS can act HTTP Web server but this is subject to POC to remove the whole set prior to install the OBIEE copy afresh.
2) Couple of benefits are there using J2EE as Web Container rather IIS which is out of scope of the documentation.
3) Configure the HTTP Webserver using the existing dev/test environment URL and the respective port. Configuring this into existing URL reusing the port is subject to POC and might be altered.
4) Configure the same into Production like SSO enabled environment e.g. Performance test environment.
5) Check the SSO functionality for authentication and authorisation. Also verify the same for any data and object level of security.
6) Deploy the RPD-Webcat at Production environment having basic functionality in place.
7) Any URL Port change for J2EE HTTP Server configuration need to reflect to Order Gateway URL, BI Arena URL and need communicate across users.
8) Alternatively IIS Web server can be redirected to new HTTP Server configured URL which is of no impact to anywhere. This is subject to POC again.
9) Revisit production server hardware configurations to see the capabilities.

Additional Required Configurations

1) Change the Skin file path default configuration parameters as per the new windows folder structure of OBIEE deployment.
2) Move the customized CSS, JavaScript’s, images into the Skin directory path.
3) Make the respective changes on OBIEE Analytics and Presentation Server configuration files.
4) Take the Oracle best practice approach to define the performance parameters as per the current Production hardware environment setup and Production DB Configuration parameters.
5) Configure the clustered environment setup for BI Server at production for replication.
6) Define the strategy for failover/ load balance presentation services.

Additional Optional Configurations

Below additional components is not available in default setup and can be installed and configured depending on the requirement to leverage the other business benefits and experiencing the new version features at maximum.