Migración de Oracle Discoverer a Oracle Business Intelligence 11g

Por Edelweiss Kammermann
Publicado en noviembre 2011

Introducción

Desde la publicación del “Statement of Direction” de Discoverer en enero del 2009, donde Oracle sugiere a los usuarios de Discoverer trasladarse paulatinamente a Oracle Business Intelligence (OBI), la pregunta principal es : ¿ cuál es la estrategia para poder realizar esta migración?. ¿Cómo realizar este cambio de una tecnología a otra?.

Lo primordial es tratar de realizar este pasaje a Oracle BIEE de tal forma que se pueda reutilizar la mayor cantidad del trabajo realizado previamente en Discoverer, minimizando de esta manera el impacto tanto para el personal de TI como para los usuarios finales y pudiendo aprovechar todas las ventajas y avances que posee Oracle BIEE.

En este artículo vamos a ver los pasos necesarios a seguir para realizar esta migración, teniendo en cuenta la reutilización de lo implementado en Discoverer.

Pasos para la migración

Para realizar este pasaje tenemos que migrar los siguientes objetos:

1. El EUL(End User Layer): que contiene toda la metadata utilizada por Discoverer para la realización de consultas.
2. Los Workbooks o Libros de trabajo que son las consultas realizadas con dicha herramienta.

1. Migración de EUL.

A partir de la versión 10g (10.1.3.4) existe un utilitario en Oracle BI, el Oracle Discoverer Metadata Conversion Assistant, que permite crear a partir un de un export de la EUL (.eex) un repositorio en BI (archivo .rpd). El nombre del archivo se llama MigrateEUL.exe y se encuentra en la versión 10g, bajo el directorio OracleBI/server/bin y en la versión 11g, en el directorio Oracle_BI1/bifoundation/server/bin.

Los pasos a seguir para realizar esta migración son los siguientes:

1) Realizar el export de la EUL desde Discoverer, generando el archivo .eex correspondiente
2) Correr el utilitario dentro de Oracle BI (ya sea 10g u 11g) para convertir el archivo .eex en un archivo de repositorio (.rpd)
3) En el caso que se migre a OBI 11g (11.1.1.5), se debe asignar una password al repositorio.
4) Habilitar el repositorio utilizando Enterprise Manager si estamos en 11g, o modificando el archivo NQSConfig.ini en la versión 10g.

Nuestro ejemplo va a consistir en migrar una EUL de Oracle Discoverer versión 10.1.2.1 a un repositorio de Oracle BI 11.1.1.5. Esta EUL contiene un esquema estrella típico, formado por una tabla de medidas, SALES, y cinco dimensiones que se llaman CHANNELS, PRODUCTS, PROMOTIONS, CUSTOMERS y TIME.

1.1 Export del EUL

En Oracle Discoverer Administrator, ir a la opción File -> Export. Al abrirse el Export Wizard seleccionar la opción The Entire End User Layer, para exportar toda la EUL.

Export del EUL

Apretamos el botón Next, y en el segundo paso del Wizard seleccionamos la ubicación y el nombre del archivo .eex que va a contener el export.

segundo paso del Wizard

Luego, apretamos el botón Finish y después de crear el archivo se muestra una ventana de log, dando la posibilidad de guardarlo como un archivo txt.

crear el archivo

1.2 Ejecutar el utilitario Oracle Discoverer Metadata Conversion Assistant

El utilitario Oracle Discoverer Metadata Assistant se ejecuta desde línea de comando y como mencionamos anteriormente, se encuentra en la versión 11g, en el directorio: Oracle_BI1/bifoundation/server/bin. (Prerequisito: se tiene que ejecutar en la misma máquina donde se encuentra instalado el OBIEE). Dentro de esta carpeta, también se encuentra un archivo de propiedades de configuración que se llama MigrationConfig.properties. Con este archivo podemos refinar la ejecución de la migración.

Adicionalmente, existe un archivo de documentación que se llama DiscovererMetadataConversionAssistant.pdf , que se encuentra en el directorio Oracle_BI1/bifoundation/server/document. Es un documento de menos de treinta hojas que da un poco más de detalle sobre la migración y la transformación de los respectivos objetos.

Las opciones de configuración que podemos modificar mediante el MigrationConfig.properties son las siguientes:

Propiedad

Seteos

CreateAggregatedCols TRUE – Por cada una de las columnas de medida se generan columnas con las agregaciones SUM, MIN, MAX, AVG and COUNT. FALSE – Se crea una sola columna por columna de medida con la agregación que esté especificada en la propiedad DEFAULT AGGREGATION property en el EUL.
CreateSeparateRPDs TRUE – Se crean repositorios separados por cada Business Area FALSE – Todas las business areas se migran a un solo repositorio.
ExcludeJoins Lista de joins que no se quieren migrar identificados por JOIN_ID y separados por coma.
ConsiderMultiplePaths TRUE – Se consideran los joins que forman caminos de acceso múltiple. FALSE – El asistente no tendra en cuenta dichos joins
IncludePathsForFolders Una lista de folder_id separados por comas, para los cuales los joins obviados deben ser tenidos en cuenta en la migración.
Connection pool parameters Nombre de fuente de datos, Usuario

En la imagen siguiente tenemos un ejemplo del archivo de configuración:

archivo de configuración

Luego de modificar el archivo de configuración, ejecutamos el utilitario sobre el archivo de export de la EUL.

archivo de configuración

archivo de configuración

Una vez finalizada la ejecución del Migration Assistant, tenemos además del repositorio generado de BI 11g (export_eul.rpd), dos archivos de logs: el export_eul.migration.log que tiene información del proceso de migración a alto nivel y el export_eul.exception.log que indica cuales son los ítems que no fueron migrados.

Como mencionamos anteriormente, en la versión 11g de OBIEE, el repositorio se guarda encriptado. Para esto, se requiere de una contraseña propia, adicionalmente al usuario y password con permiso de administración.

El nuevo repositorio export_eul.rpd resultado de la migración, tiene contraseña nula, que es el valor que se genera por defecto. No existe ninguna opción dentro del archivo de configuración para modificar esto previo a la migración.

Para abrir el archivo de repositorio tenemos que utilizar la herramienta Administration Tool de OBI y abrir el repositorio Off line o Fuera de Línea. La figura siguiente muestra como queda el repositorio producto de la migración.

Administration Tool de OBI

1.3 Asignación de un valor a la password del repositorio

Si bien nuestro repositorio ha sido creado con una password nula, para que pueda ser habilitado para consultas (por parte de los usuarios finales), necesitamos asignarle un valor, ya que de lo contrario Oracle BI no permite utilizar el repositorio.

Para esto, lo que debemos hacer, es abrir el Administration Tool de Oracle BI y abrir el repositorio en forma Offline (Fuera de Línea). Una vez abierto, ir a la opción Archivo -> Cambiar Contraseña. Aparece la ventana que se muestra en la siguiente figura:

Administrador Tool de Oracle BI

1.4. Habilitar el repositorio

Para habilitar el repositorio para consultas, se tiene primero que mover el mismo al directorio instances\instance1\bifoundation\OracleBIServerComponent\coreapplication_obis1\repository como indica la figura.

Habilitar el repositorio

Luego, ejecutar el Enterprise Manager 11g Fusion Middleware Control:

Ejecutar el Enterprise Manager 11g

Business Intelligence Elegir del panel de la izquierda, la instancia de inteligencia de negocios (Business Intelligence): core application.

En el panel de la derecha seleccionar el tab de Despliegue y la opción Repositorio.

Para cargar el nuevo repositorio, tenemos que apretar el botón de Bloquear y Editar Configuración para poder modificar la misma.

Bloquear y Editar Configuración

Posteriormente, apretar el botón de Examinar bajo la opción de Cargar Repositorio de BI Server y una vez seleccionado nuestro repositorio e ingresada la contraseña del mismo, apretar el botón de Aplicar y luego el de configuración de Liberación. Con esto se aplican los cambios

Cargar Repositorio de Bi Server

Una vez aplicados estos cambios aparece un mensaje que nos indica que se deben reiniciar los servicios de BI para que dichos cambios tomen efecto.

Reiniciar los servicios de BI

Apretamos el botón reiniciar para que se reinicien los servicios de BI y nuestros cambios quedan activos, por ende ya tenemos nuestro repositorio listo para poder realizar consultas.

NOTA: Para habilitar el repositorio en la versión 10g, se guarda el repositorio en OracleBI\server\repository y se modifica posteriormente el archivo NQSConfig.ini que se encuentra en OracleBI\server\config, agregando la siguiente entrada: Star= export_eul.rpd, DEFAULT en la sección [REPOSITORY]

Que elementos son los que se migran:


1) Business Areas: Se convierten en Subjects Areas en la capa de Presentación (visibles para el usuario desde OBI Answers cómo Áreas Temáticas)

2) Simple Folders: Por cada simple folder, se crea una tabla física en la Capa Física y una tabla lógica en la Capa de Modelo de Negocio. En caso que la simple folder tenga la propiedad Visible to User = Yes se crea también una tabla de presentación en la Capa de Presentación del repositorio.

3) Complex Folders: se transforma en una tabla lógica en la Capa Lógica teniendo como Logical Table Source las tablas que la forman y los joins que existen entre ellas. Esta carpeta también tendrá un join con las carpetas bases que la forman, que serían dimensiones. Igual que en el caso de las simple folders, sólo se crea una tabla de presentación en la Capa de Presentación si tiene la seteada la propiedad de que sea Visible para el Usuario. Obs: No está soportado que una complex folder sea una dimensión y/o tenga jerarquía.

4) Custom Folders: Estas carpetas quedan migradas en la Capa Fisica del repositorio como tablas de tipo “Select”. Se crea por cada una de ellas, una tabla lógica en la capa de Negocio y en el caso que esté Seteada para que sea visible para el usuario se genera también una tabla en la capa de Presentación.

5) Columnas: Se crean como columnas en la tabla a la que pertecen y se genera una columna en la tabla de Presentación nuevamente si tiene seteada la propiedad de Visible para el Usuario.

6) Joins: quedan como foreign keys en la capa física y como logical join en la capa de Modelado, con algunas excepciones:

a. En el caso de circular joins el utilitario genera un alias de la tabla ya que no están permitidos los joins circulares en OBI. (ídem para Joins de Multiple Path).
b. Un join entre dos tablas no se migra cuando comparten entre ellas, más de una dimension en común.
c. La carpeta A tiene un join hacia la carpeta B y viceversa. Uno de estos joins no se migra (se elige en forma aleatoria).
d. Los joins que involucran cálculos en la condición del join no se migran.

7) Condiciones:

a. Obligatorias: Si la condición es de una folder simple o Custom , la condición queda como condición de where dentro de la Tabla Lógica fuente de esa carpeta. Para carpetas complejas, como todos los usuarios de Discoverer, quedan en el grupo “Everyone” , esa condición queda aplicada como filtro de seguridad.
b. Opcionales: no se pueden migrar ya que deberían pertenecer al catalógo de OBI (no se pueden definir en el repositorio)

8) Jerarquía

a. Se migran las jerarquías de ítems basadas en Folders simples no en complejas.
b. Jerarquía de fechas: si bien no hay equivalente en Oracle BI para los templates de creación de jerarquías de fechas, la jerarquía resultante de usar estos templates si se migra

9) Privilegios de usuarios: Todos los usuarios de la EUL, son migrados al repositorio como parte del grupo “Everyone” donde la password, es el nombre del usuario en mayúsculas.

Que elementos no se migran o no están soportados:

1) Los Item class: No hay equivalente en Oracle BIEE para los item class, por ende no se puede migrar. Las listas de valores en Oracle BIEE se generan en tiempo de ejecución al momento de crear algún filtro.
2) Summary Folders.
3) Las Complex folders basadas en otras complex folders.
4) No se puede migrar complex folders que sean dimensiones. En el log aparece el siguiente mensaje:
5) Jerarquías basadas en Complex Folders
6) Las Condiciones Opcionales: ya que necesitarían colocarse como parte del catálogo de OBI.

2. Migración de Workbooks o Libros de Trabajo

Si bien Oracle viene trabajando hace un tiempo ya, en una versión beta de un utilitario que migre los workbooks de Discoverer a OBI, hasta el momento no existe una herramienta que ayude a hacer esta migración de forma automática. La opción que se maneja en la mayoría de la documentación al respecto es volver a crear de cero las consultas de Discoverer en Oracle BI. Esto obliga a rehacer las consultas, lo cual implica duplicar el trabajo realizado previamente.

Una alternativa mejor es reutilizar las sentencias SQL generadas por las consultas en Discoverer y aplicarlas directamente en Oracle BI, disminuyendo considerablemente la carga de trabajo para la creación de consultas.

Para esto debemos aplicar los siguientes pasos para cada una de los Workbooks o Libros de Trabajo en Oracle Discoverer:

1) Abrir el Libro de Trabajo en Oracle Discoverer , ya sea con Oracle Discoverer Plus o con Oracle Discoverer Desktop

2) Una vez abierto, ir a la opción Tools (Herramientas) -> Show SQL

OracleBI Discoverer - Show SQL

3) Al elegir esta opción se abre una ventana en donde se muestra la sentencia SQL que es generada por el libro de trabajo. Utilizar el botón copy de la ventana para copiar la sentencia.

OracleBI Discoverer - SQL Inspector

4) Ir a OBIEE y seleccionar “Crear nuevo análisis” y luego la opción “Crear Solicitud Directa de Base de Datos” (Direct Database Request)

Crear solicitud directa de Base de Datos

En la siguiente ventana, poner el nombre de la Connection Pool y en la sentencia SQL pegar la sentencia que habíamos copiado de Discoverer. Apretar posteriormente el botón de validar SQL and retrieve columns para obtener las columnas del select.

Validar SQL and retrieve columns

Obs: el nombre y los datos de la Connection Pool se encuentran en el repositorio, en la capa física. Connection Pool

Al ir al tab de Resultados vemos los datos que nos trae esta consulta. En nuestro caso quedaría:

Resultados

Si queremos dejarlo con el mismo formato que teníamos en Discoverer, simplemente arrastramos los campos Calendar_Year_Name y Channel Name a la parte de Table Prompts (Peticiones de Tabla).

Peticiones de Tabla

Es importante tener en cuenta, que para que un usuario pueda en OBI realizar una consulta directa en la base de datos, debe tener privilegios especiales. Para esto el Administrador del catálogo tiene que ir a la opción del menú de Administración dentro de OBIEE e ir a la opción de Gestionar Privilegios (Manage Privileges).

Administración de Oracle BI Presentación Services

Luego ir a los privilegios de Respuestas (Answers) y ahí dar permisos al usuario para:

Business Intelligence

Consideraciones importantes:

1) En la capa de Modelado del repositorio de OBIEE las relaciones entre tablas deben representar esquemas estrellas. Se exige como mínimo que exista una tabla de dimensión y una tabla de medida. Con lo cual, si la fuente de Oracle Discoverer en vez de ser una implementación de Data Warehouse, es un Sistema Transaccional, es muy posible que se necesiten retoques posteriores a la migración, en esta capa del repositorio, para representar la información en la estructura necesaria. De lo contrario el repositorio no quedará disponible y habilitado para consultas.

2) El manual de OBIEE “Oracle Fusion Middleware:Integrator's Guide for Oracle Business Intelligence Enterprise 11g ”, dice que el utilitario sólo migra a la versión 10g y por ende para obtener un repositorio de la versión 11g se tiene que ejecutar el Upgrade Assistant. Esto no es necesario, ya que tanto en la versión 11g 11.1.1.3 como en la versión 11.1.1.5 el repositorio que se genera usando el utilitario ya es de la versión 11g correspondiente.




Publicado por Edelweiss Kammermann. Lider Oracle User Group Uruguay.