METODOLOGÍA DE DESARROLLO

Transcripción

1 METODOLOGÍA DE DESARROLLO PLATAFORMA BUSINESSOBJECTS XI 3.1 Y BUSINESSOBJECTS 4.1 (Proyectos Nexus) Versión 1.10 Documento:Metodología Desarrollo de Business Objects Versión: 1.8 Fase: Metodología de Desarrollo Fecha: 18/12/2012

2 ÍNDICE I INTRODUCCIÓN I.1 OBJETIVOS Y ALCANCE I.2 AUDIENCIA OBJETIVO I.3 CONTENIDO DEL DOCUMENTO II METODOLOGÍA GENERAL DE UN PROYECTO BUSINESS OBJECTS II.1 PUNTOS A CONSENSUAR ANTES DEL INICIO DEL PROYECTO II.2 PUNTOS A DETALLAR EN LA ENTREGA DEL PROYECTO III REQUISITOS DE UN PROYECTO BUSINESS OBJECTS III.1 REQUISITOS HORIZONTALES III.1.1 Estructura de Carpetas III.1.2 Archivos de imágenes III.1.3 Usuarios, grupos y roles (niveles de acceso) III.1.4 Personalización del entorno III.1.5 Informes Business Objects III.1.6 Eventos, Calendarios, Publicaciones y Perfiles III.1.7 Auditoría de Datos III.2 REQUISITOS DEL MODELO DE DATOS III.2.1 Arquitectura de Bases de Datos III.2.2 Requisitos de Diseño III.2.3 Versión de la Base de Datos III.2.4 Normativa sobre objetos ORACLE III.2.5 Arquitectura y Requisitos Generales III.2.6 Nomenclatura III.2.7 Configuración del proyecto para varios entornos III Configuración de Flat Files III.2.8 Requisitos del JOB ETL III Requisitos de las sentencias SQL III Otras consideraciones generales en el uso de objetos del Job: III Uso de trazas de auditoria III Planificación/Ejecución de Jobs y registro de ficheros de log III Mantenimiento de los Jobs: III.2.9 Requisitos de Seguridad /127

3 III.3 REQUISITOS DEL UNIVERSO III.3.1 Generales III.3.2 Nomenclatura de universos III.3.3 Conexiones de los Universos III.3.4 Parámetros de los Universos III.3.5 Diseño de Objetos en el universo III.3.6 Listas de Valores III.3.7 Condiciones Predefinidas III.3.8 Cardinalidades III.3.9 Combinaciones III.3.10 Contextos III.3.11 Tablas III.3.12 Jerarquías III.4 REQUISITOS DE INFORMES III.4.1 Requisitos generales de informes III.4.2 Informes Web Intelligence III.4.3 Informes Desktop Intelligence III.4.4 Informes Crystal Reports III.4.5 Informes Xcelsius III.4.6 Informes Voyager III.4.7 Informes Live Office III.5 REQUISITOS DE SEGURIDAD IV REQUISITOS DE ENTREGA IV.1 ENTREGAS INCREMENTALES IV.2 ESTRUCTURA DE ENTREGA IV.2.1 Módulo de Base de Datos IV.2.2 Módulo de Business Objects para proyectos de BO IV.2.1 Módulo de Business Objects para proyectos de BO IV.2.2 Módulo de Data Services IV.3 CUMPLIMENTACIÓN DE FICHAS DE ENTREGA IV.3.1 Ficha de entrega de Módulo de Base de Datos IV.3.2 Ficha de entrega de Desarrollo para Business Objects IV.3.3 Ficha de entrega de Desarrollo para Data Services IV.4 ESTRUCTURA DE REPOSITORIOS DE SUBVERSION EN ICM IV.5 REALIZACIÓN DE UNA ENTREGA PARA SU INSTALACIÓN EN LOS ENTORNOS DE ICM /127

4 ANEXOS /127

5 Histórico de Cambios Versión Fecha Autor Descripción /03/2009 Arquitectura de Aplicaciones Primera Versión Liberada /11/2009 Arquitectura de Aplicaciones Modificaciones sobre versión 1.0: - Requisitos de diseño de BBDD: Eliminado rol XXXX_ETL_ALL - Nomenclatura de BBDD: Añadida nomenclatura para tablas temporales (TP). - REQ-EC-CarProyecto: Incluidos nuevos ejemplos - BP-CD-CreSubcarp: Eliminada best practice, creado nuevo requisito REQ_EC_NombreSubcarp - REQ_EC_NombreSubcarp: Nuevo requisito - REQ-EC-NivelesProf: Apliada máxima profundidad a 4 - REQ-EC-NavegaCat: Convertido en Best Practice, BP-EC-NavegaCat. - REQ-EC-CarCategoría: Cambiado ejemplo de nombre de categoría - REQ-AI-DirectorioImag: Vuelto a redactar para que quede más claro - REQ-AI-RutaRelativa: Vuelto a redactar para que quede más claro - REQ-AI-NombreImag: Nuevo requisito - REQ-US-UsuarioRoles: Vuelto a redactar para que quede más claro - REQ-US-NombreGrupos: Nuevo requisito - REQ-EC-ObjetosNoPermitidos: Nuevo - REQ-AD-AuditoriaDatos: Nuevo 5/127

6 - Normativa Objetos Oracle: Añadido prefijo "TP" para tipo de tabla temporal. Eliminados subtipos de tablas de dimensiones. - REQ-DS-NombreObj: o o o o o o Vuelto a redactar para que quede más claro. Cambiada nomenclatura de DataStores para diferenciar entre origen y destino Incluido el orden opcional en la nomenclatura Cambiado DT de Data transport a Data transfer. Cambiada nomenclatura Tables de TBL a TB, transforms para que se usen dos letras. Cambiada nomenclatura Query Transforms de QRY a QT. - BP-DS-NumerarNombres: Cambiado "se puede" por "se permite" - REQ-DS-Annotations: Modificado para sólo exigir anotaciones en los Jobs - REQ-DS-InicVars: Modificado para que se incialicen todas las variables en el Script de inicio del Job - BP-DS-Trazas: Eliminada Best Pratice, añadido requisito REQ-DS-Trazas - REQ-DS-Trazas: Nuevo - REQ-DS-CargaIni: Cambiados valores por 0/1 y cambiado variable por substitution parameter - REQ-DS-Nulos: Cambiado a best practice, BP- DS-Nulos - BP-DS-Nulos: Nueva best practice - REQ-DS-ExpCond: Cambaido a best practice, BP-DS-ExpCond 6/127

7 - BP-DS-ExpCond: Nueva best practice - REQ-DS-ParamsEntornos: Nuevo requisito - REQ-DS-ParamsNombre: Nuevo requisito - REQ-DS-ParamsConfig: Nuevo requisito - REQ-DS-ParamsDefault: Nuevo requisito - REQ-DS-ProfDStores: Modificado, reescrito y cambiada nomenclatura - REQ-DS-DStorePorSchema: Nuevo - REQ-DS-NombreFicheros: Modificado, separado en dos - REQ-DS-UbicacionFicheros: Nuevo requisito - REQ-DS-JobInicioFin: Aclarado y modificado para que los scripts estén a primer nivel - REQ-DS-JobShellScripts: Nuevo - REQ-DS-NombreJobShellScripts: Nuevo - REQ-DS-ElimFich: Modificado para aclarar - REQ-DS-NombreScriptLimpia: Nuevo - REQ-BD-Particiones: Si se usan particiones indicarlo en ficha de entrega - REQ-UN-UnivNoCiclos: Nuevo - REQ-UN-UsoContexto: Cambiado a best practise, BP-UN-UsoContexto. - REQ-WI-NombreObjet: Quitados los bloques, no se exige nomenclatura en ellos. - REQ-UN-ProductosCart: Metida excepción si autorización expresa. Metido comentario dentro del mismo contexto. - REQ-XC-EntregaFuentes: Nuevo. - REQ-SE-NivAccesoPerso: Cambiada nomenclatura Niveles de Acceso 7/127

8 Personalizados _NA_ -> _NAP_ - REQ-SE-SegCarpetaPrincipal: Nuevo - REQ-SE-SegCarpetaUniversos: Nuevo - REQ-SE-SegUniversos: Nuevo - REQ-SE-SegConexiones: Nuevo - REQ-SE-SegAplicaciones: Nuevo - Entregas Incrementales: Incluido apartado sobre entregas incrementales. - Estructura de Módulo de BBDD: Cambiado el nombre del fichero ERWIN. - Estructura de Entrega BO: Añadido directorio para archivos fuentes (XCelsius, etc.). - Estructura de Entrega DS: Incluir un fichero ATL por cada Job. - Nomenclatura BIAR: Incluida nomenclatura si hay varios ficheros.biar - Nomenclatura fichero SQL: Cambiada para poner primero el nombre del proyecto /12/2009 Arquitectura de Aplicaciones /07/2010 Arquitectura de Aplicaciones Modificaciones sobre la versión 1.1: - Inclusión de documento anexo para entregas incrementales Modificaciones sobre la versión 1.2: - REQ-BO-CaracExtr: Modificado para permitir espacios en blanco en nombre de informes. - REQ-DS-NoAsteriscos: Nuevo requisito - REQ-DS-NoTruncate: Nuevo requisito - REQ-UN-NombreDesc: Modificada para sólo permitir alfanuméricos. - REQ-DS-ScriptsShell: No es necesario que el proveedor incluya los shell scripts para ejecución de los Jobs por línea de comandos, basta con que 8/127

9 pruebe que funcionan. - REQ-DS-JobsShellScripts: Modificado. - REQ-DS-NombreJobShellScripts: Eliminado. - REQ-DS-ElimFich: Modificado. - Nomenclatura de DataStores: Modificado el ejemplo y puesto como opcional el nombre del proyecto en el de destino. - Estructura de directorios módulo BO: Especificación del subdirectorio XXXX dentro del directorio de imágenes del servidor. Modificación de estructura de entrega para biars incrementales y directorios de uso interno para validación y producción. Añadido directorio documentacion en estructura de entrega para incluir la ficha de entrega. - REQ-DS-NoDeletePrevio: Nuevo requisito - REQ-DS-NoTruncate: Modificado para alternativa a truncates. - REQ-AI-NombreImag: Añadida la posibilidad de incluir números en el nombre de las imágenes /10/2010 Arquitectura de Aplicaciones Modificaciones respecto a la versión 1.3: - Apartado Requisitos de Seguridad : Se mencionaba por error que no se exportaba la seguridad en el BIAR. - Quitado fichero con las queries SQL s de la entrega, ya no es necesario. - Modificado cómo rellenar ficha general de entrega, estaba mal el nombre de los módulos. - Modificada versión de Business Objects a la BusinessObjects Enterprise Premium XI 3.I Service Pack 3 FixPack 3.3 9/127

10 1.5 10/10/2011 Arquitectura de Aplicaciones Modificaciones respecto a la versión 1.4: Modificaciones Generales: - REQ_EC_NombreSubcarp: Se permiten caracteres acentuados y la letra eñe - REQ-EC-CarCategoría y BP-EC-NavegaCat: Se prohibe el uso de categorías salvo autorización expresa. - REQ-BD-VersOracle: Versión de Oracle 10gR2 o superior. - REQ-BO-CaracExtr: Permitidos caracteres acentuados y la letra ñ en nombre de informes Modificaciones para adaptar la normativa a los proyectos NEXUS: - Modificada audiencia objetivo para indicar que también se orienta a proyectos Nexus. - La versión de las herramientas en Nexus puede ser distinta de la En el apartado de metodología y entrega de proyectos, se hace referencia a que no aplica a proyectos Nexus. - REQ-EC-CarProyecto: Incluida nomenclatura para proyectos Nexus - REQ-EC-NivelesProf: Para los proyectos Nexus no existe máximo número de niveles de profundida - REQ-EC-EstructSeg: Para proyectos Nexus se permite seguridad a nivel de informe. - REQ-US-UsuarioRoles: Permitido asignar seguridada a informes para Nexus - REQ-PE-CambioEntorno: Todos los proyectos Nexus utilizarán un estilo visual consensuado - REQ-BD-Nexus: Nueva norma para Nexus, se puede acceder con el usuario DBA 10/127

11 - REQ-DD-HerramientaDS: La versión de Data Services puede ser distinta en Nexus - REQ-CR-EntregaPlantillas, REQ-RE- DocumEntrega, REQ-RE-GuiaErwin, REQ-RE- BusinesObjects: Requisitos no necesario para Nexus, igual que cualquier requisito de entrega /02/2012 Arquitectura de Aplicaciones Modificaciones respecto a la versión 1.5: - REQ-DD-HerramientaDS: Modificada versión de Data Services, V En el apartado de entregas: Incluida nueva ficha de instalación de módulo de base de datos /03/2012 Arquitectura de Aplicaciones Modificaciones respecto a la versión 1.6: - Eliminada de este documento la normativa específica de base de datos y pasada al documento con la normativa de base de datos y erwin /12/2012 Arquitectura de Aplicaciones Modificaciones respecto a la versión 1.7: - REQ-BO-CaracExtr: Permitidos espacios en blanco en nombre de informes (antes también estaba permitido pero se omitió por error) - REQ-EC-EstructSeg: Eliminada excepción de seguridad a nivel de informes para proyectos Nexus. - REQ-US-UsuarioRoles: Eliminada excepción de seguridad a nivel de informes para proyectos Nexus. - REQ-BD-Nexus: Requisito eliminado /02/2015 Arquitectura de Aplicaciones Se adapta la normativa para la nueva versión de BO 4.1. Actualmente solo en proyectos NEXUS. La adaptación ha supuesto incluir un nuevo apartado relativo a la entrega de 11/127

12 módulos técnicos de tipo BO. Apartado IV 2.2 Módulo de Business Objects para proyectos de BO /03/2015 Arquitectura de aplicaciones Se actualiza apartado de entregas ya que la parte de entrega de modelo de datos era incoherente con la normativa de base de datos. Se incluyen dos nuevos apartados IV.4 y IV.5 relativos a como se ha de realizar la entrega con subversion. 12/127

13 I INTRODUCCIÓN I.1 Objetivos y Alcance El presente documento tiene por objeto establecer la metodología, estándares, requisitos y buenas prácticas que deben aplicarse al desarrollo de aplicaciones Business Objects dentro del entorno de trabajo de Informática y Comunicaciones de la Comunidad de Madrid (en adelante ICM). Así mismo, este documento servirá como guía de uso para implementar dichos requisitos con las herramientas de desarrollo utilizadas en cada momento para la construcción de aplicaciones. Los objetivos perseguidos con la difusión de los requisitos se resumen en los siguientes puntos: Definir los documentos entregables que se intercambiarán entre el proveedor e ICM para el traspaso de las aplicaciones desarrolladas en Business Objects. Mejorar la calidad final de las aplicaciones, en lo que al desarrollo de componentes se refiere, evitando la adopción de soluciones no estándar. Normalizar la construcción de proyectos desarrollados con la tecnología de Business Objects. Facilitar el mantenimiento de las aplicaciones implantadas al estandarizar las soluciones adoptadas para el desarrollo. Simplificar el proceso de validación/certificación al ofrecer criterios de valoración objetivos tanto a los responsables de efectuar el control como a los desarrolladores. La difusión de tales criterios permite a los equipos de desarrollo efectuar un autocontrol previo de la calidad de la aplicación y, como consecuencia, que la entrega se realice en mejores condiciones. La realización de esta normativa se fundamenta en que sólo unas referencias unívocas y significativas pueden garantizar la correcta implementación y funcionamiento de los diferentes proyectos Business Objects que se vayan a implantar en ICM, garantizando la homogeneidad de los mismos y facilitando su mantenimiento. El conocimiento del sistema operativo, el entorno de red y las herramientas BOE utilizadas resulta muy útil para comprender los diferentes puntos tratados en este documento. Para ello, previamente se ha generado el documento ICM-Libro Blanco Business Objects, que incluye toda la información básica sobre la plataforma BusinessObjects, incluyendo los conceptos, las herramientas que la componen, la introducción al desarrollo y administración y las buenas prácticas generales. El conocimiento de los niveles de servidor Web, servidor de BusinessObjects y Base de datos, ayuda a clarificar muchos de los conceptos y términos utilizados en este manual. Sin embargo, para abarcar 13/127

14 todos los niveles de experiencia de los diferentes desarrolladores, se detalla a alto nivel ofreciendo suficiente información básica y conceptual para clarificar todos los puntos. La información ofrecida en este documento se basa en los módulos de Business Objects que ICM ha elegido como herramientas de Business Intelligence, que son los siguientes: BusinessObjects Enterprise Premium XI 3.I Service Pack 3 FixPack 3.3, que incluye o o BusinessObjects Web Intelligence BI Widgets BusinessObjects Live Office XI 3.I BusinessObjects Voyager XI 3.I BusinessObjects XI 3.I Integration for SAP Solutions Crystal Reports 2008 BusinessObjects Xcelsius Enterprise (Instalándose aparte el FixPack 1 y 2) Data Services 3.1 (llamado Data Integrator en las versiones anteriores de Business Objects) *Nota: En los proyectos NEXUS se utilizará la versión de los productos consensuada con ICM, que puede no coincidir con la indicada en este documento. I.2 Audiencia Objetivo Este documento va dirigido a todos aquellos proveedores de ICM que vayan a desarrollar o trabajar con la plataforma BusinessObjects XI y necesiten conocer la metodología y requisitos de las herramientas que lo componen, su utilización y las buenas prácticas técnicas. Asimismo, también es de utilidad para el personal interno de ICM que se encarga de controlar el cumplimiento de los estándares de calidad de los proyectos entregados. Estos estándares de construcción de aplicaciones serán aplicables a cualquier proyecto de nuevo desarrollo en el que se construya una aplicación que tenga que utilizar alguna de las herramientas de Business Objects. A partir de su versión 1.5 este documento incluye información adicional para los proyectos de Business Objects de NEXUS, incluyendo las particularidades concretas para este tipo de proyectos. 14/127

15 I.3 Contenido del documento. Todo proveedor de ICM deberá cumplir los requisitos expuestos en este manual para homogeneizar todos los proyectos Business Objects que se solicitan y se gestionan a través de ICM. En el apartado II - Metodología general de un proyecto Business Objects se muestra la metodología general de proyectos, en donde se expone la forma general de trabajo con proyectos Business Objects en ICM. El apartado III.1 Requisitos Horizontales, se refiere a todos los temas horizontales de la plataforma (Estructura dentro de la plataforma BusinessObjects, gestión de carpetas, roles, grupos y usuarios, seguridad, archivos de imágenes, etc). Seguidamente, en el apartado III.2 Requisitos del modelo de datos se definen los requisitos del modelo de datos (versión utilizada, normativa sobre objetos, estándares, nomenclatura de campos, etc) A partir del siguiente apartado, se entra en el detalle de los requisitos y buenas prácticas que deberán tomarse en cuenta para cada una de aplicaciones implicadas en las fases de un proyecto Business Objects en ICM: III.3 - Requisitos del proceso ETL (Data Services), III.4 - Requisitos del Universo, III.5 - Requisitos de Informes (Web Intelligence, Desktop Intelligence, Crystal Reports, Voyager, Live Office y Xcelsius) El apartado III.6 Requisitos de seguridad expone la manera en que la seguridad deberá de establecerse en los entornos Business Objects de ICM una vez instalados los desarrollos entregados por el proveedor. Finalmente, el apartado IV Requisitos de entrega indica al proveedor como deberá cumplimentar las fichas de entrega para cada desarrollo efectuado. 15/127

16 II METODOLOGÍA GENERAL DE UN PROYECTO BUSINESS OBJECTS (*Nota: Este apartado se refiere a la metodología general de proyectos con Business Objects en ICM no relacionados con NEXUS. La metodología en los proyectos NEXUS puede no coincidir con la indicada en este apartado). La definición de la arquitectura y las herramientas utilizadas durante el proyecto deberá ser consensuada con el personal de ICM, que será el encargado de recibir la aplicación, instalarla en los distintos entornos, y finalmente ponerla en producción donde también se encargará de realizar todas las tareas de mantenimiento. No será necesaria la presencia de ningún representante del proveedor para instalar el proyecto en los distintos entornos dentro de ICM, por lo que todo lo referente a dicha instalación deberá ser fielmente reflejado por el proveedor en las fichas de entrega del proyecto (ver anexos correspondientes). En los entornos de ICM, varias aplicaciones compartirán la misma instalación del producto. Por este motivo, es de vital importancia que se cumplan las siguientes normas: Todos los elementos del proyecto deberán poder ser identificados por su nombre y/o ubicación como correspondientes al proyecto al que pertenecen. Así, por ejemplo, todos los informes y universos se ubicarán por debajo de una carpeta que se llamará igual que el nombre del proyecto. Es importante definir muy bien la seguridad a nivel de carpeta para que los usuarios sólo puedan acceder a los objetos de su proyecto. Un proyecto no puede llevar asociadas modificaciones en el servidor y/o plataforma BO que puedan afectar al resto de proyectos (por ejemplo, cambiar la imágenes y/o estructura de las páginas de Infoview, etc.). Los usuarios dentro de los entornos de ICM se autenticarán a través del LDAP corporativo. Por este motivo, en la documentación de entrega habrá que indicar los usuarios y roles de la aplicación, para que el personal de ICM que la instale en los entornos se encargue de actualizar la información del LDAP. 16/127

17 II.1 Puntos a consensuar antes del inicio del proyecto Previo al inicio del proyecto, existen una serie de puntos que deben de quedar perfectamente consensuados entre ICM y el proveedor. Dichos puntos son los siguientes: Herramientas y módulos utilizados. Se detallarán todos los módulos utilizados de los productos Business Objects (Diseñador, WebIntelligence, Xcelcius, ) y si se va a utilizar alguna Herramienta o producto para la implementación que sea necesaria para el posterior mantenimiento. Ejemplo (Editores utilizados para la modificación del código Java, implementación de WebServices, etc.). Necesidad de fase ETL. Deberá definirse si el proyecto incluye una fase de ETL (Extracción, Transformación y Carga), o el Datawarehouse ya está construido y el proyecto parte de esa base (en tal caso no es necesario el uso de la herramienta Data Services). Necesidades de configuración en el servidor. Si el proyecto necesitará la configuración propia de servidor, como puede ser la utilización de discos de red para guardar documentos, configuración de perfiles de usuario/grupos, configuración de cuentas de correo u otras necesidades. Tamaño estimado del datawarehouse y necesidad de tablas particionadas: Para dimensionar el espacio asignado en base de datos, deberá estimarse el tamaño final de todo el modelo, así como consensuar la necesidad del uso de tablas particionadas. Número estimado de informes y universos. Para dimensionar el tamaño de la aplicación. Número estimado de usuarios finales de la aplicación. Se tiene que establecer un máximo de usuarios, además de la concurrencia esperada. Accesos a Informes de los usuarios de la aplicación. Se tendrá que definir si los usuarios tienen acceso on-line a los informes (y por tanto pueden ejecutarlos en cualquier momento), o planificado (por ejemplo con informes que se ejecutan por la noche y se generan instancias que son las que los usuarios pueden consultar). Desarrollos adicionales. Si se van a realizar desarrollos adicionales externos a la plataforma BO y que accedan de alguna manera a esta (por ejemplo, aplicaciones web que tengan incrustados visores de informes, etc.). Tiempos razonables de respuesta. La ejecución de un informe desarrollado en Business Objects no deberá superar un tiempo razonable consensuado por las partes involucradas en el proyecto. 17/127

18 Cualquier otra identificación necesaria para el proyecto que no quede reflejada en el alcance de este documento así como la implementación de módulos adicionales no instalados en producción, tiene que ser consensuada con el equipo de ICM antes del inicio del proyecto. II.2 Puntos a detallar en la entrega del proyecto (*Nota: Este apartado se refiere a la metodología de entregas en ICM no relacionados con NEXUS. La metodología en los proyectos NEXUS puede no coincidir con la indicada en este apartado). Para la correcta entrega del proyecto, deberán cumplimentarse las fichas de entrega correspondientes (ver anexos). En dichas fichas deberá al menos indicarse toda la información relativa a los siguientes puntos: Funcionalidades que se implementarán en los informes (Análisis, link, envío por correo, planificación ). Se detallará si se utilizan las herramientas de BusinessObjects Enterprise u otras herramientas. Modelo de base de datos implementado (ver anexo correspondiente). Seguridad a implementar para los usuarios finales. Detallando a nivel de acceso tanto permisos en las diferentes herramientas, como permisos de acceso a datos. Si existe algún tipo de implementación en java, se identificará el tipo y las aplicaciones afectadas y la descripción general de la implementación. Identificar las herramientas necesarias para el mantenimiento, las necesidades de algún tipo de instalación, ya sea para los puestos de usuario final como para los encargados de realizar el soporte de la plataforma. Si se establecen permisos a los usuarios para poder utilizar módulos Cliente/Servidor, como Designer, se tendrá que especificar la necesidad de instalar este módulo. Dentro de la implantación del proyecto a los usuarios hay que especificar la necesidad de componentes instalados en los ordenadores de los usuarios, como puede ser java runtime, Shockwave Flash, Adobe Reader, etc. Programación planificada de informes. Si ciertos informes se ejecutan en batch, deberá indicarse en la entrega del proyecto. Puntos exclusivos para Data Services: Fuentes de datos origen: Definiciones de fuentes de datos origen para el proceso ETL. Incluye ficheros externos, bases de datos necesarias para el correcto funcionamiento de los Jobs. 18/127

19 Plugins/DataStores personalizados: tales como Webservices o plugins de terceros fabricantes. Planificación de los Jobs. Detalles sobre la ejecución planificada de cada uno de los Jobs. 19/127

20 III REQUISITOS DE UN PROYECTO BUSINESS OBJECTS En este apartado se indican todos los requisitos, reglas y buenas prácticas que repercuten en las aplicaciones y herramientas que intervienen en cada una de las fases de un proyecto Business Objects para ICM. Los requisitos definidos son de obligado cumplimiento por parte de los proveedores para asegurar la homogeneidad y buen funcionamiento de los proyectos desarrollados. Si por algún motivo no pudiese cumplirse algún requisito, esto deberá ser previamente consensuado con ICM. Los requisitos se identifican en el documento precedidos de REQ-xx-Desc. Siendo xx una abreviación del apartado al que se refieren, y Desc una descripción del tema al que referencian. Para facilitar su identificación, los requisitos en este documento se incluyen dentro de un cuadro amarillo: REQ-xx-Desc: Las buenas prácticas son consejos originados desde la experiencia, y como su propio nombre indica no son requisitos estrictos de obligado cumplimiento. Sin embargo es muy aconsejado su cumplimiento para facilitar el desarrollo de las distintas aplicaciones a las que hagan referencia. Las buenas prácticas vendrán precedidas de BP-xx-Desc. Para facilitar su identificación, las buenas prácticas se colocan en este documento dentro de un cuadro gris: BP-xx-Desc: * Nota: Existen ciertos requisitos y/o buenas prácticas que no son aplicables a los proyectos NEXUS. Se ha incluido una nota en ellos indicándolo. 20/127

21 III.1 Requisitos Horizontales En este punto se definen los requisitos para la creación de la estructura básica dentro de la plataforma Business Objects, incluyendo gestión de carpetas, roles, grupos y usuarios, seguridad, archivos de imágenes, etc. III.1.1 Estructura de Carpetas La estructura de carpetas dentro de la plataforma BusinessObjects se define para establecer permisos de acceso a los objetos y poder definir grupos de usuarios que tienen acceso a las carpetas y a la información que contiene. Ya que es posible que varios proyectos de Business Objects compartan la misma plataforma del producto, se definirán los grupos, usuarios y derechos para que sólo puedan acceder a los informes del proyecto para el que sean creados. Existen dos tipos de carpetas; las utilizadas para almacenar los documentos que a su vez pueden contener subcarpetas y las utilizadas para almacenar universos. En este apartado se describe la nomenclatura para las carpetas de los documentos, la metodología para las carpetas de los universos se describe en el apartado Nomenclatura de universos. En las carpetas para documentos se almacenarán todos los informes BusinessObjects (Web Intelligence, Xcelsius, Excel, Live Office ). Se indican los siguientes requisitos y buenas prácticas para las carpetas: REQ-EC-CarProyecto: Se debe de crear una carpeta de documentos general para el proyecto, de la que colgarán todos los documentos. La nomenclatura de la carpeta de documentos debe de ser la siguiente: XXXX. Conjunto de cuatro caracteres en mayúsculas, representativo de cada proyecto. (Ejemplos: PROY, BITA, GRAF, BIEM, etc.) * Nota: para los proyectos NEXUS, el nombre de la carpeta inicial de documentos será el siguiente dependiendo del proyecto:nexus-eccl, NEXUS-RRHH, NEXUS-EDUCACIÓN 21/127

22 REQ_EC_NombreSubcarp: Se permite la creación de todas las subcarpetas que se requieran dentro de la carpeta del proyecto (no existe limitación en el número). El nombre de las subcarpetas del proyecto debe cumplir la siguiente nomenclatura: Sólo se pueden utilizar caracteres alfanuméricos: a-z, A-Z, 0-9, permitiéndose también el uso de caracteres acentuados y la letra ñ. Se permite el uso de espacios en blanco Deberá comenzar con una letra mayúscula y el resto en minúsculas, con un máximo de 100 caracteres. Si el nombre de la carpeta estuviese compuesto por varias palabras, se permite (opcionalmente) utilizar letras mayúsculas al principio de cada una de ellas. Carpeta Raíz Business Objects Nombre proyecto (4 caracteres) Subcarpeta 1 Subcarpeta 2 Subcarpeta 11 Subcarpeta 21 Subcarpeta 12 I Ilustración: Estructura de Carpetas Un posible ejemplo de estructura de carpetas sería el siguiente: 22/127

23 II Ilustración: Estructura de Carpetas REQ-EC-NivelesProf: No se podrán superar los 4 niveles de profundidad en la estructura de carpetas. Si se desea utilizar más de cuatro niveles de profundidad, se tendrá que consensuar previamente con ICM. * Nota: para los proyectos NEXUS, no existe un número máximo de niveles de profundidad de carpetas. Con cuatro niveles se deben cubrir todas las necesidades de organización de los informes en carpetas. La creación de más niveles se complica la asignación de permisos y el mantenimiento de la seguridad, ya que las carpetas heredan los permisos desde la carpeta de la que dependen, y se tiene que establecer los permisos a todos los niveles de subcarpetas. 23/127

24 REQ-EC-EstructSeg: La estructuración de carpetas y subcarpetas se realizará orientada a la seguridad: Los derechos de acceso de los usuarios a los informes/objetos se definirán para cada carpeta y no para cada informe. REQ-EC-CarCategoría: Se prohíbe el uso de categorías en lugar de carpetas para la agrupación de documentos, salvo autorización explícita por parte de ICM. En el caso de utilizarse las categorías, deberá crearse una categoría general para el proyecto, de la que colgarán todas las categorías creadas. La nomenclatura de la categoría principal será igual que la de la carpeta principal. III.1.2 Archivos de imágenes Si los informes requieren imágenes propias (por ejemplo para incrustar en un informe en pdf, logos, etc.), estas imágenes se tienen que situar físicamente en el filesystem de la máquina de Business Objects. Para ello, junto con la entrega del proyecto, se incluye los ficheros con las imágenes necesarias para el proyecto. REQ-AI-DirectorioImag: Todas las imágenes necesarias para el proyecto se incluirán en un directorio con el nombre del proyecto, situado en el directorio raíz donde se ubican todas las imágenes de Business Objects. (Por ejemplo en windows: ${Install Dir}\Business Objects\BusinessObjects Enterprise 12.0\images\XXXX). Durante la entrega, todas las imágenes del directorio se incluirán dentro de la carpeta destinada para ello. REQ-AI-RutaRelativa: No se permite el uso de rutas absolutas en la ubicación de las imágenes de los informes. Si un informe contiene alguna imagen a incrustar, la ruta con la que se referencia dicha imagen en la estructura de carpetas del desarrollador deberá ser relativa. Por ejemplo, si una imagen se sitúa en la carpeta : ${Install Dir}\Business Objects\BusinessObjects Enterprise 12.0\images\XXXX\ejemplo.jpg, se deberá hacer referencia a ella con la ruta XXXX\ejemplo.jpg. 24/127

25 Con las rutas relativas se garantiza que al cambiar de entorno, aunque la instalación de Business Objects no se encuentre en el mismo directorio las imágenes sigan localizándose correctamente. REQ-AI-NombreImag: Los nombres de los archivos de imágenes sólo podrán contener caracteres en minúscula (de la a a la z ) o numéricos (del 0 al 9 ), sin espacios en blanco, ni caracteres acentuados ni la letra ñ. Por ejemplo, nombres correctos serían: madrid.jpg logo.gif III.1.3 Usuarios, grupos y roles (niveles de acceso) En cada proyecto se definirá una lista de los distintos Roles de usuario que existen, así como los usuarios pertenecientes a cada ROL, creándose un grupo de usuarios para cada uno de los roles definidos, de manera que los derechos sobre cada carpeta de informes se definirán siempre a nivel de grupo de usuarios, y no de usuarios sueltos. REQ-US-UsuarioRoles: Obligatoriamente, los permisos de los usuarios se agruparán por roles. Siempre se asignará la seguridad de las carpetas a los roles, nunca a usuarios concretos. Si se requiriese autorización de documentos particular por usuario (y no basada en Roles), se deberá consensuar una autorización explícita por parte de ICM. REQ-US-NombreGrupos: Los grupos de usuarios deberán cumplir la siguiente nomenclatura: XXXX_GRP_NOMBRE_DEL_GRUPO, donde: XXXX: Es el nombre del proyecto _GRP_: Son caracteres fijos _NOMBRE_DEL_GRUPO: Es el nombre del grupo, escrito con todos los caracteres en mayúscula, y con guiones bajos separando las palabras (si se compone de varias). 25/127

26 III.1.4 Personalización del entorno Puesto que es posible que varios proyectos utilicen el mismo entorno de acceso, no se puede personalizar la página de acceso al proyecto (Infoview), ni realizar ningún cambio que pueda afectar al entorno general de Business Objects (salvo en los proyectos Nexus, tal como se indica en la siguiente norma): REQ-PE-CambioEntorno: No se permiten modificaciones en la configuración del servidor Business Objects, que puedan afectar al resto de proyectos desplegados sobre la misma instalación. * Nota: Para los proyectos NEXUS, todos los proyectos utilizarán el mismo estilo visual en las herramientas de usuario (portal Infoview, etc.) consensuado con ICM, no permitiéndose estilos personalizados para cada proyecto concreto. III.1.5 Informes Business Objects REQ-IN-IdentificaObj: Se debe referenciar los informes, excels, flash, etc. a través de su ruta de carpetas y nombre del documento, y no utilizando el identificador interno de BO (que cambia al importar y exportar el fichero BIAR). III.1.6 Eventos, Calendarios, Publicaciones y Perfiles REQ-EC-ObjetosNoPermitidos: No se permite el uso de los siguientes objetos de la plataforma de BO, salvo autorización expresa por parte de ICM: Eventos. Calendarios Publicaciones Perfiles 26/127

27 III.1.7 Auditoría de Datos REQ-AD-AuditoriaDatos: Si se desea utilizar la auditoría de datos incluida con la plataforma BO, deberá ser consensuado previamente con ICM. III.2 Requisitos del Modelo de Datos III.2.1 Arquitectura de Bases de Datos En el siguiente esquema se muestra la arquitectura de base de datos, esquemas y usuarios Oracle que siguen los distintos entornos de ICM para los proyectos basados en Business Objects: 27/127

28 III Ilustración: Esquema arquitectura de la base de datos Se definen tres niveles en la arquitectura de acceso a las los datos desde las aplicaciones cliente de la plataforma BO: 1) Capa de Base de Datos: No se accederá a ningún esquema con usuarios DBA para su uso normal desde la herramienta. En lugar de esto, para el acceso a cada esquema 28/127

29 DBA_{Nombre} se utilizará un usuario BO_{Nombre} que tendrá todos los permisos sobre los objetos de dicho esquema. * Nota: En los proyectos Nexus no es necesario utilizar un usuario alternativo al DBA para acceder a base de datos, por lo que no existirá el usuario BO_{Nombre} Adicionalmente a los esquemas comunes para todos los proyectos instalados en la plataforma BO, existen dos esquemas asociados a cada proyecto en concreto. REQ-BD-NombreDW: Suponiendo que el nombre del proyecto es XXXX, el nombre del esquema en el que se almacena el DataWarehouse del proyecto debe ser DBA_DW_XXXX. REQ-BD-RepositorioETL: Todo proyecto con Business Objects que utilice Data Services constará de su propio repositorio local. Suponiendo que el nombre del proyecto es XXXX, el nombre del esquema en el que se almacena el repositorio de Data Services debe ser DBA_ETL_XXXX. Estas conexiones se configuran independientemente para cada proyecto. 2) Capa Servidor: El servidor de BO o Data Services accederá al modelo de datos común para todos los proyectos. Adicionalmente, accederán a los esquemas de cada proyecto utilizando conexiones con usuarios particulares de cada esquema, que tendrán permisos sobre todos los objetos de dicho esquema (estos usuarios no son DBA, excepto en los proyectos Nexus que se podrá acceder con el usuario DBA). 3) Capa Cliente: El modo de acceso normal de las aplicaciones cliente a la base de datos es a través de la plataforma BO o Data Services. Si se accede a través de la plataforma, la autenticación se realizará a través de ella (a través del LDAP correspondiente), y será la plataforma la que utiliza una conexión al modelo de datos del proyecto, utilizando las conexiones configuradas según el apartado anterior. 29/127

30 III.2.2 Requisitos de Diseño Para la definición del modelo de datos deberá utilizarse la herramienta ERWIN según se indica en la normativa correspondiente. En la arquitectura de base de datos para proyectos con Business Objects existen una serie de diferencias con respecto al modelo de trabajo con otro tipo de aplicaciones (estas diferencias no se aplican a proyectos Nexus): a) En un pre-script del modelo de ERWIN a nivel de schema que se ejecutará antes de la creación del resto de objetos, se crea un rol denominado XXXX_DW_ALL para la base de datos del DataWarehouse. b) En los post-scripts de cada tabla, además de la creación de sinónimo público, se realizará la concesión de permisos GRANT ALL para el rol creado: Ej: GRANT ALL ON XXXX_DW_NOMBRETABLA TO XXXX_DW_ALL c) Para poder conectarse a la base de datos del Datawarehouse, después de la creación del modelo de datos a partir del ERWIN se creará el usuario BO_DW_XXXX, al que se le asignará el rol XXXX_DW_ALL y será el usuario que se utilice para el acceso habitual a los datos tanto desde el propio BO como desde las aplicaciones que accedan directamente al modelo de datos. III.2.3 Versión de la Base de Datos REQ-BD-VersOracle: La base de datos a utilizar para el DataWarehouse de los proyectos que utilicen la plataforma Business Objects es Oracle 10gR2 o superior. III.2.4 Normativa sobre objetos ORACLE Para consultar la normativa específica sobre objetos Oracle en proyectos de Business Intelligence, consultar el apartado específico para Business Objects del documento Normativa de Modelado de Bases de Datos y Uso de la Herramienta ERWIN. 30/127

31 Requisitos del proceso ETL (Data Services) III.2.5 Arquitectura y Requisitos Generales En este punto se definen los requisitos en la creación de la estructura dentro de la plataforma Data Services (en adelante DS). Data Services es la última versión de herramienta ETL de Business Objects, con mejoras y correcciones respecto a su versión predecesora: Data Integrator (DI). En este documento se hará referencia al término Data Services para referirse a ella. En el siguiente esquema se muestra la arquitectura general de la herramienta: IV Ilustración: Arquitectura general de Data Services Para el trabajo con Data Services en ICM, cada Proveedor dispondrá de su repositorio correspondiente (Repositorio Local de DS). La entrega de un módulo de Data Services se hará a través de un fichero ATL exportado de la herramienta, y una serie de ficheros con los archivos adicionales necesarios para el proceso de ETL que no vengan en el fichero ATL. * Nota: En los proyectos Nexus no queda definido explícitamente el procedimiento de entrega al no realizarse las instalaciones directamente por ICM. 31/127

32 En el siguiente apartado se muestra la estructura general del contenido del repositorio: V Ilustración: Estructura general del contenido del repositorio de Data Services A continuación se listan una serie de requisitos generales para la realización de ETLs utilizando la herramienta Data Services: 32/127

33 REQ-DD-HerramientaDS: Todo proceso de ETL (Extracción, Transformación y Carga de Datos) se realizará utilizando la herramienta Business Objects Data Services V * Nota: Para los proyectos Nexus, la versión de la herramienta Data Services puede ser distinta a la definida en esta norma (será consensuada con ICM). REQ-DS-NoAccesoDirecto: Toda escritura de información en la base de datos del DataWarehouse deberá ser realizada a través de un Job de Data Services. No se permite la escritura directa de una base de datos origen al DataWarehouse (por Ejemplo a través de una inserción directa desde PL/SQL). Si se desea acceso directo a la base de datos deberá consensuarse previamente con ICM. REQ-DS-BBDDDestino: El esquema destino de todo proceso de ETL siempre será en la base de datos del DataWarehouse (Oracle 10gR2). El nombre del esquema siempre será DBA_DW_XXXX, donde XXXX es el nombre del proyecto. III.2.6 Nomenclatura A continuación se enumeran los requisitos y buenas prácticas para las nomenclaturas que todo proveedor deberá usar en los diferentes objetos que conforman la ETL de DS: 33/127

34 REQ-DS-NombreObj: El nombre de los objetos de un Proyecto de Data Services debe cumplir la nomenclatura: XXXX _TIPO_ORDEN _Descripcion_Detallada, donde: - XXXX: El nombre del proyecto - TIPO: El tipo del objeto, según el tipado descrito en la metodología - ORDEN (Opcional): Opcionalmente se puede incluir un orden en la ejecución del objeto, según se indica en BP-DS-NumerarNombres - Descripcion_Detallada: Se compondrá de una o varias palabras separadas por guión bajo, con la primera letra de cada palabra en mayúsculas y el resto en minúsculas, no permitiéndose el uso de espacios en blanco. Sólo se podrán utilizar caracteres alfanuméricos: a-z, A-Z, 0-9, no permitiéndose el uso de caracteres acentuados ni la letra ñ. Ejemplo: PROY_WF_Ventas_Directas El número de caracteres máximo que se puede usar en el nombre de cualquier objeto es de 100 caracteres. BP-DS-NumerarNombres: Para un mejor seguimiento del orden de ejecución de los objetos del proyecto, se permite indicar este orden de procesamiento mediante una numeración, por ejemplo: XXXX_WF_002_001_Load_Dimension Identificaría el proyecto XXXX, este WF (WorkFlow) sería el primero en ejecución, en el segundo nivel, dentro de otro elemento 002). A continuación se enumeran las siglas usadas para cada tipo de objetos principales: o o o o o o o o Job JOB WorkFlow WF DataFlow DF Conditional CD Script SC While Loop WL Try TR Catch CA 34/127

35 o o Annotation AN DataStore DS_TIPO. Existen dos posibles valores para TIPO: ORIG: DataStore de origen de datos (de entrada). Ej: XXXX_DS_ORIG_EDUCACION. DEST: DataStore de destino de datos (de salida). Ej: XXXX_DS_DEST_PROY. * El nombre de proyecto final en el DataStore de destino es opcional, ya que coincidirá con el nombre del proyecto (XXXX). o o o o o o o Template Table TT Template XML TX Table TB SAP R/3 R3 Flat File FF (El objeto deberá llamarse igual que el archivo externo al que hace referencia, sin la extensión. Ver requisito REQ-DS-NombreFicheros). Data Transfer DT Query Transform QT REQ-DS-NomenclaturaOtros: Para el resto de objetos no principales cuyo tipo no esté definido en la tabla de la metodología (como transforms que no sea el más usado Query Transform), se antepondrá TF a las iniciales del nombre del tipo de transform. Ejemplo: PROY_TFKG_Economico_Financiero A continuación se muestra un ejemplo de cómo se mostraría el área del proyecto en la herramienta Data Services con objetos definidos según la nomenclatura: 35/127

36 VI Ilustración: Data Services Área del Proyecto III.2.7 Configuración del proyecto para varios entornos Cualquier proyecto de ETL deberá poder ser instalado en todos los entornos de ICM (entorno de desarrollo, validación y producción). Con este objetivo, dentro del proyecto no deben existir características específicas del entorno, todo tiene que ser configurable para que al migrar entre entornos no sea necesario realizar ninguna modificación en los objetos del proyecto, simplemente se elija otra System Configuration y todo funcione en el nuevo entorno. Para ello se definen los siguientes requisitos, que permiten la definición de los DataStores y Substitution Parameters de un proyecto para los tres entornos: REQ-DS-ParamsEntornos: Toda aplicación de data services deberá poder ser migrada de un entorno a otro sin modificar ninguno de sus objetos (Jobs, Workflows, Scripts, etc.). Cualquier parámetro que dependa del entorno en el que la aplicación esté instalada deberá ser configurado utilizando un substitution parameter. El resto de parámetros de la aplicación que no dependan del entorno no deben ser definidos como substitution parameters, sino como variables. REQ-DS-ParamsNombre: El nombre de todos los substitution parameters de un proyecto deberá comenzar por spin_, seguido del nombre del parámetro en letras mayúsculas. Si el parámetro tiene varias palabras, se separarán con un guión bajo. Ejemplos: spin_path_ficheros 36/127

37 REQ-DS-ParamsConfig: Todos los substitution parameters de una aplicación deberán tener tres configuraciones denominadas XXXX_DESARROLLO, XXXX_VALIDACION y XXXX_PRODUCCION, donde XXXX es el nombre del proyecto. Los valores para los substitution parameters en cada una de estas configuraciones serán rellenados durante la instalación de la aplicación. REQ-DS-ParamsDefault: La configuración por defecto para los substitution parameters deberá ser XXXX_DESARROLLO. En la siguiente figura se muestra un ejemplo de substitution parameters definidos para las tres configuraciones: VII Ilustración: Data Services Substitution Parameters Al igual que los substitution parameters, los DataStores del proyecto también deberán definirse para los tres entornos. Además, deberá existir un DataStore distinto para cada esquema origen de datos: 37/127

38 REQ-DS-ProfDStores: Todos los DataStores de una aplicación deberán tener tres configuraciones denominadas XXXX_DESARROLLO, XXXX_VALIDACION y XXXX_PRODUCCION, donde XXXX es el nombre del proyecto. Los valores para la conexión en cada una de estas configuraciones serán rellenados durante la instalación de la aplicación. REQ-DS-DStorePorSchema: En Data Services, deberá existir un DataStore de origen de datos por cada esquema distinto de base de datos al que se acceda. Por tanto, un mismo DataStore no puede utilizarse para acceder a tablas de dos esquemas distintos. En la siguiente figura se muestra un ejemplo de DataStore definido para las tres configuraciones: VIII Ilustración: Data Services Configuraciones de DataStore 38/127

39 También deberán definirse tres System Configurations, de manera que cada una de ellas utilice la configuración oportuna de los substitution parameters y los datastores del proyecto: REQ-DS-SystemConfig: Un proyecto de data services debe tener tres configuraciones o system configurations denominadas XXXX_DESARROLLO, XXXX_VALIDACION y XXXX_PRODUCCION, donde XXXX es el nombre del proyecto. Cada una de estas tres system configurations deberá tener definidos los substitutions parameters y las configuraciones de los DataStores correspondientes según la configuración. En la siguiente figura se muestra un ejemplo de System Configurations definidas para los tres entornos: IX Ilustración: Data Services System Configurations III Configuración de Flat Files Si un proyecto utiliza ficheros de tipo Flat File, estos deberán seguir una nomenclatura determinada, según se indica en el siguiente requisito: 39/127

40 REQ-DS-NombreFicheros: El nombre de los ficheros externos utilizados por el proyecto, ya sean Flat Files, Excel o XMLs (con DTD incluida), deberá seguir la siguiente nomenclatura: XXXX_FF_Descripcion_Detallada.ext, donde: - XXXX: Nombre del proyecto - Descripcion_Detallada: Se compondrá de una o varias palabras separadas por guión bajo, con la primera letra de cada palabra en mayúsculas y el resto en minúsculas, no permitiéndose el uso de espacios en blanco. Sólo se podrán utilizar caracteres alfanuméricos: a-z, A-Z, 0-9, no permitiéndose el uso de caracteres acentuados ni la letra ñ. - ext: Extensión del fichero (csv, xls, etc.) El número de caracteres máximo que se puede usar en el nombre de cualquier fichero es de 100 caracteres. Ejemplo: PROY_FF_Admin_Proces.csv Es necesario que la configuración de la ubicación de los ficheros pueda modificarse dependiendo del entorno. Para ello se utilizará un substitution parameter que indicará dicha ubicación: REQ-DS-UbicacionFicheros: En todo proyecto de data services, todo fichero externo (flat file, excel, etc.) utilizado deberá estar ubicado dentro de un directorio o carpeta denominado igual que el proyecto XXXX. La ubicación de esta carpeta es relativa y comenzará con /. La posición de relatividad estará dada por un substitution parameter denominado spin_path_ficheros. A continuación se muestra un ejemplo de configuración del nombre y ubicación de un flat file: 40/127

41 X Ilustración: Data Services Nombre y Ubicación de Flat File III.2.8 Requisitos del JOB ETL Los Jobs son los procesos que contienen todos los elementos para realizar el proceso completo de la definición de la ETL. El conjunto de Jobs forman el proyecto (aunque un proyecto puede estar formado por un solo Job). A continuación se definen los requisitos que deberán cumplir los Jobs desarrollados con Data Services. REQ-DS-MinimoJob: Un proyecto ETL realizado con Data Services deberá contener al menos un Job. REQ-DS-JobInicioFin: Todo Job de la ETL debe comenzar y finalizar con un script de inicialización y finalización, registrándose estado inicial y estado final. Ambos scripts deben estar en el primer nivel de profundidad del Job. Se deberán añadir comentarios a las acciones que se lleven acabo en ellos. REQ-DS-Annotations: Se deberán incluir anotaciones en todos los Jobs en las que se describa con detalle la funcionalidad del Job dentro del proyecto de la ETL. Si el Job de la ETL tiene variables globales (IN/OUT) se deberán indicar en dichas anotaciones. 41/127

42 REQ-DS-InicVars: En el script de inicialización de cada uno de los Jobs de la ETL, se deberán inicializar todas las variables del Job, por ejemplo: de fecha inicio del Job, carácter de sustitución de nulos, de número por defecto, de texto por defecto, de fecha por defecto, etc. A continuación se muestra un ejemplo de un Job de Data Services, con anotaciones y un script de incialización (el de finalización, en este ejemplo, se encuentra dentro del Workflow PROY_WF_Fin_Job): XI Ilustración: Data Services Ejemplo de Job con Script de Inicialización y Comentarios III Requisitos de las sentencias SQL En ocasiones es necesario realizar consultas a la base de datos utilizando la sentencia sql() que proporciona Data Services para ejecutar una sentencia SQL sobre el Data Store indicado. Ejemplo: sql('xxxx_ds_dest','select CAMPO1, CAMPO2 FROM TABLA\'') Si necesitamos realizar consultas directas a la base de datos, es importante no utilizar nunca SELECT * FROM TABLA, ya que esto puede dar problemas durante la migración entre entornos o en la futura evolución del proceso ETL. Por tanto, si necesitamos obtener todos los 42/127

43 campos de una tabla no se utilizará el asterisco, sino que se listarán uno a uno los campos de la tabla. REQ-DS-NoAsteriscos: No se permite utilizar el asterisco en ninguna de las sentencias SQL que se ejecute desde la herramienta Data Services. Si se desea obtener todos los campos de una tabla, se listarán uno a uno los campos de la tabla. Ejemplo: Incorrecto: sql('ds_orig_xxxx','select * FROM TABLA\'') Correcto: sql(' DS_ORIG_XXXX','SELECT C1,C2,C3 FROM TABLA\'') En la ejecución de sentencias SQL desde el proceso ETL, tampoco es posible borrar tablas de base de datos utilizando sentencias TRUNCATE, deberán borrarse las tablas utilizando DELETE, según se indica en el siguiente requisito: REQ-DS-NoDeletePrevio: En un Job de Data Services, NO se permite activar la casilla Delete Data before loading. Esto es debido a que internamente la herramienta traduce esta casilla a una sentencia TRUNCATE de oracle, que no está permitida pues el usuario de base de datos que se utiliza no tiene permiso para realizar este tipo de operaciones. * Nota: Esta norma no se aplicará en los proyectos Nexus, donde puede utilizarse el usuario DBA para conectarse a la base de datos (y por tanto el usuario tiene permiso para realizar TRUNCATE). REQ-DS-NoTruncate: No se permite utilizar TRUNCATE en ninguna de las sentencias SQL que se ejecute desde la herramienta Data Services. Si se desea borrar el contenido de una tabla, se utilizará una sentencia DELETE sobre dicha tabla. Ejemplo: Incorrecto: sql('ds_orig_xxxx','truncate TABLE TABLA\'') Correcto: sql(' DS_ORIG_XXXX','DELETE FROM TABLA\'') En ocasiones tampoco es factible hacer DELETE sobre una tabla, debido a que contiene demasiada información y esta sentencia puede tardar demasiado o incluso desbordar los segmentos de Rollback de Oracle. En este caso se deberá consultar con ICM, para utilizar una solución alternativa que permite hacer TRUNCATE utilizando un procedimiento almacenado propiedad del usuario DBA_DW_XXXX. 43/127

44 III Otras consideraciones generales en el uso de objetos del Job: Se debe tener en cuenta los aspectos descritos a continuación con el objetivo de diseñar una ETL con una estructura robusta y optimizada: Cuando se realice carga de tablas de hechos, al ser tablas normalmente pesadas, de deberá realizar mediante scripts, los procesos necesarios de mantenimiento. Por ejemplo, comprobar que no se haya cargado la información con anterioridad o tener en cuenta una variable que distinta si es un caso inicial o es una carga delta (incremental). A continuación se muestran una serie de recomendaciones y buenas prácticas relacionadas con el uso del Job: REQ-DS-CargaIni: En las cargas iniciales de un Job de la ETL de DS, se debe aclarar, si las tablas son vaciadas o deben continuar donde acabó la última carga. Para ello debe existir una variable global para cada Job llamada varin_load_init que indique si se trata de una carga inicial (valor=1) o una carga incremental (valor=0). El valor 1 es el equivalente a vaciar las tablas al iniciar el JOB. En el proyecto se debe desarrollar la lógica correspondiente. REQ-DS-RecoverAuto: En los casos de necesidad de recuperación automática de errores del Job de la ETL, se deberá usar los transforms TableComparision. No se debe contemplar la opción en el Workflow (Recover as a Unit) ya que no se usará en los Jobs la opción Automatic Recover. REQ-DS-PrimKey: Se debe habilitar el control, en los procesos que requiera el uso del Transform Key Generation, que las inserciones de las tablas de destino de la ETL no violan las Primary Keys, para evitar errores de ejecución futuros. REQ-DS-RowGeneration: Para la generación de claves en una ETL de DS con el transform Row Generation, se deberá usar el valor dado por la variable global como valor por defecto. 44/127

45 REQ-DS-Exec: Queda prohibido el uso de EXEC sin el consentimiento expreso de ICM, salvo para la eliminación de ficheros temporales. Si se desea usar la instrucción EXEC dentro de un proyecto ETL con otro objetivo, esto deberá ser previamente autorizado por ICM, y documentado en la ficha de entrega. REQ-DS-Reusar: En los proyectos de ETL de DS, no se reusan los objetos DataFlows previamente definidos. BP-DS-LookUp: En un proyecto de ETL de DS, se recomienda el uso de lookup_ext, sólo si no es posible hacerlo con joins por los siguientes: no es única constraint (primary key) en la búsqueda, la tabla de búsqueda es menor filas, las filas a retornar no son compresibles fácilmente por el dataflow (el lookup está oculto en la query mientras que la join es obvia en el diseño). Por ello, se recomienda usar joins, siempre que sea posible. BP-DS-Bifurc: Se deberá evitar en la medida de lo posible pasar por DataFlows y WorkFlows no necesarios en los proyectos de ETL, para ello se usará el bifurcador/objeto conditional. Este no deberá tener valores harcodeados en la condicción, para ello se deberá usar variables. BP-DS-RendCommit: Si el rendimiento es prioritario ante el commit de los procesos en el proyecto ETL, se deberá solicitar el habilitar particiones y ejecuciones en paralelo. En el caso que se requieran commits simultáneos se deberá habilitar en las tablas destino, en Transaction Control, el Transaction Order. BP-DS-XMLNodes: En todo proyecto ETL, se recomienda no crear nodos raiz en ficheros XML vacíos ya que el impacto en la ejecución del JOB es muy alto. 45/127

46 BP-DS-Nulos: Se recomienda usar la función NVL() para gestionar los valores nulos dentro de todo el proyecto de la ETL. Dentro de esta función no se usará valores introducidos manualmente, para ello usar variables inicializadas en el Job. BP-DS-ExpCond: En todo proyecto de ETL los Query Transforms, en la propiedad WHERE, no se recomienda usar expresiones de más de una condición (expresiones de filtro, no expresiones necesarias para los joins). En el caso que sean más largas, se recomienda usar funciones personalizadas y creando los campos en las tablas de destino mapeadas a estas funciones. En el caso de lookup s, se recomienda no usar las funciones sql (salvo circunstancias inevitables) puesto que estas últimas realizan la apertura de una nueva conexión a BD con el consiguiente detrimento del rendimiento, además de impedir la ejecución en paralelo. 46/127

47 III Uso de trazas de auditoria A continuación se muestran una serie de buenas prácticas para el uso de trazas de auditoria. BP-DS-Audit: Trazas de auditoría: Para auditar los jobs de ETL se recomienda el uso del método siguiente: auditar a través de las filas leídas y cargadas. Esto permitirá que ICM pueda testear los resultados en la consola Web del operacional. A continuación se muestra una imagen con las propiedades de activación y uso: XII - Ilustración: Data Services Propiedades de activación y uso de trazas de auditoría 47/127

48 Para el proveedor, en caso necesario de acceso a las tablas de auditoria, podrá acceder a esta información mediante la tabla de auditoría al_audit_info a través de sql(.. ): XIII Ilustración: Data Services Sentencia SQL de la tabla de auditoria El segundo método es visto desde un ámbito del tratamiento de la calidad de datos, mediante la transform Validation: 48/127

49 XIV Ilustración: Data Services Ejemplo de Transform Validation XV Ilustración: Data Services Acción a realizar si la transformación falla 49/127

50 XVI Ilustración: Data Services Opciones de transformación de validación Estas trazas pueden ser deshabilitadas cuando se ejecuta el Job. III Planificación/Ejecución de Jobs y registro de ficheros de log El objetivo de este apartado es informar de los requerimientos necesarios para la planificación de/los Job/s existente/s en el proyecto, así como el volcado de log tanto por la consola de Data Services como a ficheros de log destinados para ello. REQ-DS-Trazas: Todo Job dentro de un proyecto deberá mostrar trazas para poder seguir su ejecución, usando el comando print( Mensaje ). Dicha traza se activará a través de una variable global que deberá existir para cada Job, llamada varin_debug que podrá valer 0 ó 1 para desactivar o activar las trazas respectivamente. Para definir la planificación de los Jobs del proyecto, el proveedor deberá completar la siguiente información en la ficha de entrega: Periodicidad de la planificación (Diario/Semanal/Mensual) Duración máxima expresada en minutos. Parámetros o variables de inicialización del Job Permisos en ficheros y directorios en caso de que sean lectura(r)/escritura(w) o de ejecución (X). Nombre de los ficheros planos (XML, Flat Files, DTD s, CopyBooks y Excel) usados para transaciones temporales y su tamaño máximo en el disco expresado en Mb. Memoria RAM requerida (nunca superior a la disponible para el proyecto) Filas aproximadas afectadas en cada ejecución y tamaño de cada una de ellas expresada en Kbytes. Exec usados (previa autorización por parte de ICM) y parámetros implicados en el comando. 50/127

51 Orden de ejecución, en el caso de que sea prioritario sobre otros jobs y/o requiere ejecución en cascada basada en triguers (se debe indicar cual es el desencadenante) Planificación basada en CMS: si la planficación está basada en el planificador de BOE usando la CMS. Indicar detalles y motivos. Si la planificación es lanzada desde línea de comandos mediante script. Se debe indicar detalles y motivos. En el entorno de ICM, es posible que la planificación de los Jobs no se realice utilizando la herramienta Data Services, sino una herramienta externa que ejecutará dichos Jobs por línea de comandos (para que las tareas se planifiquen con herramientas externas como ControlM). Para ello se ha de probar que todos los Jobs pueden ser ejecutados correctamente por línea de comandos: REQ-DS-ScriptsShell: Todos los Jobs de un proyecto deberán poder ser ejecutados por línea de comandos desde la máquina del ETL, invocando a la utilidad AL_RWJobLauncher (por tanto se deberá haber probado esta tipo de ejecución con todos los jobs). Para ejecutar los Jobs por línea de comandos en la máquinas de ICM, se utilizará un script (.sh) que recibe como parámetros todos los valores necesarios, e invoca a la utilidad AL_RWJobLauncher con dichos valores. A continuación se muestra dicho shell script para la ejecución de un Job, que podrá ser utilizado para probar que todos los Jobs del proyecto se ejecutan correctamente por línea de comandos (y que por tanto se cumple el requisito REQ-DS-ScriptsShell: # Script de ejecucion de Job #################### comprobacion previa #################### echo "Llamada al script con los par\341metros: $@" var_project_name=$1 var_dataservices_directory=$2 var_log_directory=$3 var_nombre_job=$4 var_jobserver_machine=$5 var_jobserver_port=$6 var_database_instance=$7 var_database_user=$8 var_database_password=$9 var_fecha_actual=`date +%Y%m%d\_%H\_%M\_%S` var_nombre_script=${var_nombre_job}.sh 51/127

52 var_jobserver_log_directory=${var_dataservices_directory}/log/${var_project_name}_jobserv var_log_path_name="${var_log_directory}/log_$var_nombre_script$var_fecha_actual" ########################################################### echo " $var_fecha_actual -- Inicio de la ejecucion del script $var_nombre_script -- " >>$var_log_path_name echo " $var_fecha_actual -- Llamada al script con los par\341metros: -- ">>$var_log_path_name ########Llamada al proceso AL_RWJobLauncher.sh######### ${var_dataservices_directory}/bin/al_rwjoblauncher "" -w "inet:${var_jobserver_machine}:${var_jobserver_port}" " -PLocaleUTF8 - S${var_database_instance} -NOracle -U${var_database_user} -P${var_database_password} - s${var_nombre_job} --r1000 -T14 -Ksp${var_project_name}_DW -LocaleGV -CtBatch - Cm${var_jobserver_machine} -CaAdministrator -Cj${var_jobserver_machine} - Cp${var_jobserver_port} " ret=$? if [ $ret -ge 2 ] then echo " $var_fecha_actual -- Error en la llamada a AL_RWJobLauncher con error $ret -- " >>$var_log_path_name exit $ret fi echo " $var_fecha_actual -- Fin de la llamada a AL_RWJobLauncher -- " >>$var_log_path_nam exit 0 Este script recibe los siguientes parámetros: XVII Ilustración: Ejemplo de shell script de ejecución - Nombre del proyecto: XXXX - Ruta de instalación del producto Data Services - Ruta en la que se volcarán los ficheros de log - Nombre del Job a ejecutar - Nombre de la máquina en la que está el Job Server - Puerto en el que está instalado el Job Server para ese proyecto - Instancia de Base de Datos del ETL - Usuario de acceso a Base de Datos del ETL - Contraseña de acceso a Base de Datos del ETL Un ejemplo de ejecución del script sería la siguiente:./ejecuta_job.sh "PROY" "/usr/producto/data_integrator/dataservices" 52/127

53 "/usr/producto/bo/bobje/proyectos/prue/ficheros_externos" "PROY_JOB_Prueba" "icmdesbi01" "3502" "desbi" "BO_ETL_PROY" "password" III Mantenimiento de los Jobs: A continuación se enumeran los requisitos y recomendaciones para el correcto mantenimiento de los jobs: REQ-DS-JobsShellScripts: Todos los shell script incluidos en un proyecto de Data Services deberán incluirse en la subcarpeta scripts dentro de la carpeta externo de la entrega, y recibirán todos los valores dependientes del entorno como parámetros. REQ-DS-ElimFich: Eliminar ficheros usados temporalmente: Si la ejecución de los Jobs del proyecto genera cualquier tipo de fichero temporal, junto con la entrega se deberá adjuntar un shell script que permita borrar dichos ficheros temporales. Dicho script deberá ser llamado por alguno (o varios) de los Jobs (se permite utilizar la función EXEC), garantizando así que cada vez que se ejecute el Job se borran los ficheros temporales innecesarios anteriores a una fecha determinada (Por ejemplo, ficheros de log con antigüedad mayor a tres meses). Cualquier variable del script que pueda depender del entorno no irá incluida dentro del propio script, sino que será recibida como parámetro (ver REQ-DS-JobShellScripts). REQ-DS-NombreScriptLimpia: El nombre del archivo de shell script para la eliminación de los ficheros temporales del proyecto debe ser limpia.sh. Dicho script deberá incluirse en la subcarpeta scripts dentro de la carpeta externo de la entrega del módulo de Data Services. III.2.9 Requisitos de Seguridad La seguridad de DS viene dada por la seguridad de la base de datos del repositorio y de la seguridad de la base de datos de orígenes y destinos. Todo proyecto de DS suele estar acompañada de ficheros temporales, scripts de ejecución y aviso por mensajería. 53/127

54 El uso de la mensajería, deberá ser previamente autorizado por ICM. III.3 Requisitos del Universo III.3.1 Generales Un universo es la base para un desarrollo con informes de Business Objects proporcionando una interfaz sencilla para que aquellos usuarios que no tienen un perfil técnico sean capaces de analizar la información existente en las bases de datos corporativas. El diseñador del universo debe tener un alto conocimiento de la estructura de la base de datos en la que se basa. Así mismo debe disponer de información sobre los requisitos de los informes para cuyo desarrollo se utilizará dicho universo. En la medida de lo posible, los universos deben ser diseñados de forma que sean útiles tanto para el desarrollo de grupos de documentos cerrados como para consultas ad-hoc. El siguiente diagrama muestra el ciclo típico en el proceso de desarrollo de un universo. XVIII Ilustración: Ciclo de desarrollo de un universo La herramienta de creación y modificación de universos es el Designer. Los universos del proyecto serán exportados junto con el resto de los objetos en un archivo BIAR. Estos universos deberán estar situados dentro de una carpeta lógica con el nombre del proyecto. Los universos vinculados son universos que comparten componentes comunes, tales como parámetros, clases, objetos o uniones. Cuando vincula dos universos, un universo tiene la función 54/127

55 de universo de referencia y el otro, de universo derivado. Cuando se hacen cambios en el universo de referencia, se propagan automáticamente a los universos derivados. El objetivo de los universos vinculados es reducir el tiempo de mantenimiento de los mismos. REQ-UN-UnivVinculado: No se permite el uso de Universos Vinculados en los proyectos Business Objects, salvo autorización previa por parte de ICM. La utilización fundamental de los universos vinculados es reducir el mantenimiento en la definición de objetos y tablas. Cuando se cambia un objeto en el universo de referencia se cambian en el universo derivado. Esta reducción de tiempo es exclusivamente para el desarrollo, pero se necesita un mayor mantenimiento de seguridad y complica el paso de universos entre los diferentes entornos. Además el uso de universos vinculados penaliza el rendimiento cuando se crean nuevos documentos. Según indica el requisito REQ-BD-VersOracle, el DataWarehouse estará siempre en una base de datos Oracle versión 10gR2, y por tanto la conexión del universo apuntará al esquema del proyecto dentro de esta base de datos. Se deben tener en cuenta los aspectos descritos en los siguientes apartados con el objetivo de diseñar un universo con una estructura robusta y optimizada. III.3.2 Nomenclatura de universos Los universos tienen dos nombres: Nombre del universo: Es el nombre largo del universo. Es el nombre que los usuarios ven en la lista de universos cuando deben elegir entre un universo u otro. Nombre del fichero de universo: Es el nombre que se le da al fichero del universo, con extensión UNV. Los usuarios nunca lo verán. Para la correcta localización de los universos, se hace necesaria también su organización en carpetas, según el siguiente requisito. 55/127

56 REQ-UN-NomUniverso: Todos los universos de un proyecto deben estar situados dentro de una carpeta lógica común, cuyo nombre será igual que el nombre del proyecto. El nombre de los universos debe seguir la siguiente nomenclatura: <XXXX>_ UNV_<NombreDescriptivo> : Siendo <XXXX> cuatro caracteres representativos del proyecto, y <Nombre descriptivo> una descripción que identifique a cada uno de los universos del proyecto. El NombreDescriptivo se compondrá de una o varias palabras, con la primera letra de cada palabra en mayúsculas y el resto en minúsculas, no permitiéndose el uso de espacios en blanco. Sólo se podrán utilizar caracteres alfanuméricos: a-z, A-Z, 0-9, no permitiéndose el uso de caracteres acentuados ni la letra ñ. El número de caracteres máximo que se puede usar en el nombre de un universo es de 100 caracteres. Ejemplo: PROY_UNV_UniversoParaVentas REQ-UN-NomFichero: El nombre del fichero del universo será el mismo que el nombre largo que se le de en la herramienta, añadiendo la extensión UNV. III.3.3 Conexiones de los Universos Una conexión es un conjunto de parámetros con un nombre que define de qué manera la aplicación Business Objects accederá a un esquema de base de datos. Una conexión vincula Web Intelligence al middleware. Se debe tener una conexión para acceder a los datos. Las conexiones se guardan automáticamente en la carpeta de conexiones del entorno Business Objects. No existe la posibilidad de crear subcarpetas para cada proyecto. 56/127

57 REQ-UN-NombreCone: El nombre de la conexión utilizada en un universo debe ser el mismo en todos los entornos por los que transcurra su ciclo de vida (migración entre entornos). Sólo deberán cambiarse en los diferentes entornos los parámetros de conexión a la base de datos origen. El nombre de la conexión se formará de la siguiente manera: XXXX_CNX_<Descripción>, donde XXXX son los cuatro caracteres en mayúscula idendificativos del proyecto, y <Descripción> es un nombre descriptivo de la conexión. La Descripción se compondrá de una o varias palabras, con la primera letra de cada palabra en mayúsculas y el resto en minúsculas, no permitiéndose el uso de espacios en blanco. Sólo se podrán utilizar caracteres alfanuméricos: a-z, A-Z, 0-9, no permitiéndose el uso de caracteres acentuados ni la letra ñ. El número de caracteres máximo que se puede usar en el nombre de la conexión es de 100 caracteres Por ejemplo: PROY_CNX_BaseDatosGraf 57/127

58 III.3.4 Parámetros de los Universos Todos los universos tienen que cumplir los siguientes parámetros como máximo, dejando la posibilidad de ser más restrictivos. Estas medidas se establecen para evitar problemas por consultas masivas o erróneas que penalicen gravemente el rendimiento o incluso puedan parar el servicio en la base de datos, afectando al resto de usuarios o a otras aplicaciones. PARAMETROS DE UNIVERSOS LNombre del Universo: a (Tiene que ser suficientemente Descriptivo o relacionado con el proyecto.) Consulte el requisito REQ-UN-NomUniverso para más información m Descripción : Es obligatoria una descripción del propósito y contenido del universo. o Esta descripción es visualizada por los usuarios de WebIntelligence, de d manera que la información de este campo puede facilitar información útil i sobre la función del universo f icontroles c Limitar el tamaño del resultado a: Número de filas según cada proyecto. Deberá a consensuarse con ICM al inicio del proyecto. c ilimitar el tiempo de ejecución a: Minutos según cada proyecto. Deberá ó consensuarse con ICM al inicio del proyecto. navisar si el coste estimado excede: No activar Limitar los objetos de texto largo a: 1000 d esql Permitir los operadores Union, Intersect y Minus e Permitir operadores complejos s tpermitir seleccionar varios contextos o Productos Cartesianos s No activar No activar No activar Impedir 58/127

59 parámetros para un grupo o usuarios, aumentando estos, será realizada exclusivamente por el administrador de BO correspondiente en ICM. No esta permitido que se aumenten dentro del universo por los desarrolladores. BP-UN-ParamDesconec: Dentro de los parámetros de un universo, se recomienda establecer el parámetro Desconectar después de cada transacción. El parámetro Desconectar después de cada transacción implica que se abran y cierren conexiones repetidamente pero también evita que las conexiones se mantengan abiertas demasiado tiempo (como ocurre con la opción mantener la conexión activa durante toda la sesión ). Con respecto a la opción mantener la conexión activa X minutos, el número de minutos que se debe mantener activa dependerá de los criterios de consulta implicados que a priori se desconocen. De utilizar esta opción se sugiere que no se superen los 10 minutos. Hay que tener en cuenta el tiempo que tarda en iniciar la conexión ya que las BD Oracle usan un tiempo largo para establecer la conexión con el Listener. BP-UN-ParamTamaño: Dentro de los parámetros de un universo se recomienda ajustar el parámetro Tamaño de Array fetch según las limitaciones de cada instalación. El parámetro Tamaño de Array fetch indica la cantidad de registros que serán enviados en cada paquete de red. Depende, por tanto, de la tipología y velocidad de red pero se recomienda que se establezca lo más alto posible dentro de las limitaciones características de cada instalación. Un valor alto condiciona la ejecución simultánea de informes, pero devuelve de una forma más rápida los datos (tamaño del bloque de datos) al informe. III.3.5 Diseño de Objetos en el universo A continuación se enumeran una serie de requisitos y recomendaciones sobre los objetos del universo. REQ-UN-ObjOculto: En caso de existir objetos ocultos en el universo, sólo deberán ser utilizados para generar listas de valores o variables/constantes. 59/127

60 REQ-UN-ObjConstantes: No se permite que haya objetos ocultos dentro de otros objetos dentro de un universo, salvo los usados por las constantes. REQ-UN-FuncAgrega: No se permite el uso de funciones de agregación en las condiciones de los objetos de un universo. REQ-UN-ObjDefCorrecta: Todos los objetos del universo tienen que estar definidos correctamente (no serán válidos los objetos que contengan el texto Unknown en su definición). REQ-UN-ObjNumericos: Todos los objetos numéricos del universo deben definirse como indicadores. REQ-UN-NombreDesc: Los nombres de los objetos del universo deben ser descriptivos para el usuario final.. Sólo se podrán utilizar caracteres alfanuméricos y espacios en blanco: a-z, A-Z, 0-9, no permitiéndose el uso de otros caracteres como letras acentuadas, la letra ñ, etc. REQ-UN-OpcPuedeUtil: Las opciones avanzadas Puede utilizarse en de Resultado, Condición y Ordenación deberán estar activadas en los indicadores del universo. REQ-UN-TexDescrip: Todos los objetos del universo incluirán un texto de descripción de forma que sirvan de ayuda al usuario a la hora de crear nuevas consultas Puede utilizar la para crear un objeto interactivo. Las peticiones se pueden utilizar para restringir los datos o para hacer que los objetos con valores grandes sean más fáciles de utilizar. 60/127

61 Se puede utilizar la en la cláusula WHERE de un objeto para forzar al usuario a introducir un valor para una restricción cuando el objeto se utiliza en una consulta o a seleccionar un valor o lista de valores. Cuando el usuario ejecuta la consulta, un cuadro de petición de orden aparecerá pidiendo la introducción de un valor. BP-UN-Promt: Se recomienda el uso de la para las peticiones de orden que se definan en el universo. BP-UN-CondCaracter: Es recomendable evitar la utilización de objetos de tipo carácter y tamaño superior a 10 posiciones como condición en un universo BP-UN-ObjFormato: Se recomienda definir un formato de objeto, dentro del universo, siempre que los valores correspondientes a un determinado objeto vayan a mantener un formato específico. Se pueden definir índices para un objeto del universo. El índice creado es transparente para el usuario final y se utiliza a nivel SQL para diferenciar distintos valores en una dimensión que puede devolver varios valores idénticos en una consulta. De este modo, la definición de índices: - Reduce el número de combinaciones en una sentencia SQL. - Permite al motor de base de datos filtrar valores según el índice único en lugar de un nombre de dimensión. Por ejemplo, se pueden filtrar directamente mediante claves en una tabla de hechos, con lo que se reduce el número de filas a filtrar cuando se tienen en cuenta las combinaciones del producto y la tabla de hechos. - No se ignoran los duplicados. En un campo de descripción con dos valores iguales, únicamente se recuperará uno a menos que se indique que cada valor tiene una clave principal diferente 61/127

62 BP-UN-TabIndices: Se recomienda la definición de índices únicos en los objetos de las tablas del universo cuando su uso vaya a mejorar el rendimiento de la sentencia SQL.. BP-UN-ConcaClausula: Se recomienda, en la medida de lo posible, evitar el uso de concatenaciones en las cláusulas WHERE Si se concatena un campo numérico con otro campo, el formato del campo numérico podrá verse afectado, de manera que no respete el formato diseñado originalmente. Por ejemplo, si tiene un campo Identificador definido como numérico, y lo concatena con un literal, el campo numérico puede verse afectado de manera que el resultado final sea: Identificador: 15,00, en lugar de Identificador: 15 BP-UN-ConversionNum: Se evitará, siempre que se pueda, la conversión de campos numéricos dentro de los objetos del universo. BP-UN-FuncAgregac: Los objetos de tipo indicador deben llevar una función de agregación de la base de datos siempre que sea posible y una función de proyección de forma que sean dinámicos en los informes, aunque no siempre es compatible la función de proyección y agregación. Todas las cláusulas WHERE de los objetos de una consulta pasan a formar parte de la cláusula WHERE de la sentencia SQL generada por el documento Business Objects lo que podría producir sentencias erróneas desde un punto de vista lógico. En determinadas situaciones, hay dimensiones que conceptualmente están asociadas a un ámbito de datos, por ejemplo: [Tiendas de Londres], claramente sólo devolverá información de tiendas cuya región sea Londres, luego en este tipo de situaciones si requiere complementar para el objeto la opción WHERE. BP-UN-ClausWhere: Se recomienda evitar las cláusulas WHERE en los objetos del universo en el sentido de que los usuarios finales podrían crear consultas que no devolvieran datos. 62/127

63 III.3.6 Listas de Valores BP-UN-JerarqPerson: Se recomienda crear las listas de valores en cascada asociadas a una jerarquía personalizada o predeterminada. Esto se realiza desde el menú Herramientas Listas de valores Crear listas de valores en cascada de la herramienta Designer. Se definen peticiones de forma que cada nivel jerárquico devuelva una lista de valores basada en dicho nivel. Éstas aparecen como peticiones en cascada en Web Intelligence. BP-UN-PermitUsuarios: Se recomienda desactivar la opción Permitir a usuarios editar listas de valores en el universo. REQ-UN-ModifLista: Si se modifica la lista de valores por defecto de un objeto, se debe activar la opción de exportar con el universo la lista de valores. REQ-UN-IndicadorListaVal: No se permite asociar listas de valores a los objetos de tipo indicador. III.3.7 Condiciones Predefinidas BP-UN-CondicPredefi: Es recomendable que aquellas condiciones que se utilizan con más frecuencia en las consultas a generar se definan como condiciones predefinidas en el universo. 63/127

64 III.3.8 Cardinalidades La cardinalidad entre las tablas es una parte vital del desarrollo de universos, estableciendo cuántas filas en una tabla encontrarán filas en otra. Las cardinalidades son necesarias para determinar el path válido de la consulta así como los posibles contextos que se utilizan para resolver bucles. No tienen un sentido final en el documento, su uso es exclusivamente para la detección de contextos de forma automática dentro del universo. REQ-UN-CardinCombinacion: Se deben definir las cardinalidades en todas las combinaciones existentes entre las tablas del universo. BP-UN-CardinNaN: Se debe evitar en lo posible el uso de cardinalidades del tipo N-a-N en las combinaciones de las tablas del universo, para prever, entre otras cosas, la obtención de resultados erroneos inherentes a SQL (por trampas de abismo y de abanico - chasm traps y fan traps). La cardinalidad N-a-N espera que una o más filas en una tabla coincidan con una o más filas en la otra. Esta cardinalidad es rara en bases de datos relacionales y de hecho recuperará filas duplicadas incidiendo en el rendimiento y potencialmente en la obtención de resultados inapropiados. III.3.9 Combinaciones Una combinación es una condición que vincula los datos por separado pero en tablas relacionadas. Las tablas normalmente tienen una relación padre-hijo. Si una consulta no contiene una combinación, la base de datos devuelve un conjunto de resultados que contiene todas las combinaciones posibles de las filas de las tablas de consultas. Este tipo de resultado se conoce como producto cartesiano y muy rara vez tiene alguna utilidad. 64/127

65 REQ-UN-ProductosCart: Un universo no podrá contener productos cartesianos dentro de los objetos del mismo contexto, salvo autorización expresa por parte de ICM. Todas las tablas deben estar ligadas mediante las correspondientes combinaciones en la estructura del universo. Los tipos de combinaciones que se permiten utilizar en un universo son Equicombinaciones Vincula tablas basándose en la igualdad de valores de la columna de una tabla y los valores de la columna de otra tabla. Debido a que la misma columna está presente en ambas tablas, la combinación sincroniza las dos tablas. BP-UN-Equicomb: Las columnas comunes no siempre tienen el mismo nombre. Es necesario verificar los nombres de columna de las claves principal y externa en la base de datos. XIX Ilustración: Universos - Ejemplo de Equicombinación Combinaciones theta (combinaciones condicionales) Vincula tablas basándose en una relación que no sea la igualdad entre dos columnas. 65/127

66 XX Ilustración: Universos Ejemplo de combinación theta Combinaciones externas Vincula dos tablas, una de las cuales tiene filas que no corresponden a la columna común de la otra tabla. XXI Ilustración: Universos Ejemplo de combinación externa La tabla que se define como externa contiene la columna para la que desee devolver todos los valores, aunque no tengan correspondencia. 66/127

67 BP-UN-CombinExternas: Debe evitar en lo posible el uso de combinaciones externas en bases de datos no indexadas, ya que el rendimiento del proceso de consulta puede ser más lento. Combinaciones de acceso directo Combina proporcionando una ruta alternativa entre dos tablas, omitiendo tablas intermedias, llevando al mismo resultado, independientemente de la dirección. Optimiza el tiempo de la consulta acortando rutas de combinaciones largas lo máximo posible. XXII Ilustración: Universos Ejemplo de combinación de acceso directo BP-UN-CombinAcceDirecto: Designer no considera las combinaciones de acceso directo en la detección automática de bucles y contextos. No obstante, si se define la cardinalidad para una combinación de acceso directo, se evitará la recepción del mensaje 'Algunas cardinalidades no se han definido' al detectar contextos. 67/127

68 Combinaciones de autorrestricción Combinación de una sola tabla utilizada para establecer una restricción en la tabla. XXIII Ilustración: Universos Ejemplo de combinación de autorrestricción REQ-UN-CombinAuto: La definición de la cardinalidad para una combinación de autorrestricción ayuda a evitar que se reciba el mensaje 'Algunas cardinalidades no se han definido' al detectar contextos. En toda combinación de autorrestricción se debe definir la cardinalidad en "1 a 1" Alias Los alias son referencias a las tablas existentes en un esquema. Un alias es una tabla que es un duplicado exacto de la tabla original (tabla base), con un nombre distinto. Los datos de la tabla son exactamente iguales a los de la tabla original, pero la diferencia de nombre "engaña" al SQL de una consulta para que acepte que está utilizando dos tablas diferentes. BP-UN-MuchosAlias: Se recomienda evitar la utilización de forma masiva de Alias, ya que produce duplicidad de objetos (se trata de un mal visual, no funcional o de rendimiento). 68/127

69 BP-UN-AliasConfu: Para evitar confundir las tablas base con las de alias, se recomienda mostrar los alias con el nombre de la tabla base que representa en el título de tabla de la siguiente manera: seleccione en el Designer: Herramientas > Opciones > Gráficos y, a continuación, activar la casilla de verificación Alias y nombre de tabla. III.3.10 Contextos XXIV Ilustración: Universos Ejemplo de Alias Los contextos son una colección de combinaciones que proporcionan una ruta de consulta válida para que Web Intelligence genere un SQL. Los contextos se utilizan para: Resolver trampas de abismo. Es un tipo de ruta de combinación entre tres tablas cuando dos combinaciones "N a 1" convergen en una tabla única y no hay contexto presente que separe las rutas de combinación convergentes. 69/127

70 XXV Ilustración: Ejemplo de trampa de abismo Obtendrá resultados incorrectos sólo en las siguientes condiciones: Existe una relación de tipo "varias a una a varias" entre tres tablas en la estructura de un universo. La consulta incluye objetos basados en dos tablas, ambas en el extremo "varias" de sus combinaciones respectivas. Para una dimensión única, se devuelven varias filas. Resolver una trampa de abanico. Es un tipo de ruta de combinación entre tres tablas cuando una combinación "1 a N" vincula una tabla que a su vez está vinculada por otra combinación "1 a N". El efecto de abanico de las combinaciones de "una a varias" puede provocar la devolución de resultados incorrectos cuando una consulta incluye objetos basados en ambas tablas. XXVI Ilustración: Ejemplo de trampa de abanico Resolver bucles. 70/127

71 Detectar incompatibilidades entre objetos que utilizan aggregate awareness Puede utilizar la función en la sentencia SELECT para un objeto que dirige una consulta a ejecutarse en tablas agregación en lugar de en una tabla que contenga datos no agregados BP-UN-ContextoDectec: Hay que tener en cuenta durante el desarrollo, que la detección automática de contextos es incorrecta cuando una relación del tipo 1 a 1 se encuentra al final del path, ya que no será detectada como parte del contexto al que pertenece. BP-UN-ContextoModif: Cuando se realizan modificaciones sobre combinaciones o cardinalidades en el universo es importante recordar que los contextos no se actualizan de forma automática, sino que será necesario editarlos y realizar las modificaciones necesarias.. Si se detectan ciclos en un universo, será necesario eliminarlos para que no existan ambigüedades a la hora de componer la sentencia SQL de un determinado informe. REQ-UN-UnivNoCiclos: No se permite la existencia de ciclos (o bucles) en los Universos, salvo autorización expresa por parte de ICM. BP-UN-UsoContexto: Cuando existan bucles en un universo, se recomienda, siempre que se pueda, utilizar alias de tablas para resolver dichos bucles. Sólo se aconseja la utilización de contextos para la ruptura de bucles en el caso en el que no sea posible resolverlos fácilmente con alias. III.3.11 Tablas REQ-UN-TablaCond: Si fuera necesario aplicar condiciones sobre las filas de una tabla, deberá aplicar una combinación de autorrestricción sobre dicha tabla. Para más información sobre combinaciones de autorrestricción ver el apartado de combinaciones. 71/127

72 BP-UN-TablaIndices: Se recomienda que todas las tablas tengas correctamente definidos todos sus índices. Las tablas derivadas son tablas que se definen en el esquema del universo. Son estructuras lógicas a nivel del universo y no físicas a nivel de la base de datos que se crean a partir de una sentencia SQL. Una vez creadas podrán ser tratadas dentro del universo como cualquiera de las otras tablas. REQ-UN-TablaDerivada: No se utilizarán Tablas Derivadas en los universos, a no ser que se valide con ICM la necesidad de su uso. 72/127

73 III.3.12 Jerarquías Una jerarquía es una serie ordenada de dimensiones relacionadas. Por ejemplo, una jerarquía como Geografía, que puede agrupar dimensiones como País, Región y Ciudad En Web Intelligence se utilizan las jerarquías para sintetizar o profundizar en los datos, realizando de este modo análisis multidimensionales. Las jerarquías implícitas en los datos dependen de la naturaleza de éstos y del modo en que están almacenados en la base de datos. De forma predeterminada, Designer proporciona un conjunto de jerarquías predeterminadas para el análisis multidimensional. Se trata de clases y objetos organizados en el orden en que aparecen en el panel Universo. REQ-UN-Jerarquias: Al crear objetos en el universo, deberán organizarse jerárquicamente para garantizar que las jerarquías predeterminadas tengan sentido para los usuarios. REQ-UN-NuevaJerarquias: Se deberá crear una nueva jerarquía cuando necesite incluir en una sola jerarquía objetos de diferentes clases del universo. REQ-UN-ElimJerarquias: Se deberá eliminar del universo todas aquellas jerarquías predeterminadas que el usuario no necesite utilizar. 73/127

74 III.4 Requisitos de Informes A continuación se detallan los requisitos que deben de cumplir los informes desarrollados, así como las buenas prácticas de desarrollo, según el tipo de informe Business Objects del que se trate. III.4.1 Requisitos generales de informes Las siguientes reglas de nomenclatura se aplican a todos los documentos Business Objects, ya sean Web Intelligence, Voyager, Crystal Reports, Live Office o Xcelsius. REQ-BO-CarpetaProyecto: Los documentos Business Objects se deberán guardar en la carpeta específica del proyecto, dentro de la subcarpeta que corresponda para el documento. Si se utilizase navegación por categorías, todo informe debe estar al menos en una categoría. REQ-BO-CaracExtr: En el nombre de un informe Business Objects sólo se podrán utilizar caracteres alfanuméricos: a-z, A-Z, 0-9, incluido espacios, caracteres acentuados y la letra ñ. No podrá superar los 100 caracteres de longitud total. BP-BO-DescrNombre: Se recomienda que el nombre que se le de a un informe Business Objects sea descriptivo que permita identificarlo fácilmente de entre los demás informes contenidos en la misma carpeta de proyecto. REQ-BO-ObjetoInneces: A fin de reducir el tiempo de ejecución de las consultas, se eliminarán de la consulta de un informe todos aquellos objetos innecesarios. De igual manera, y con el fin de reducir el tiempo de cálculo del documento, elimine todas aquellas variables que hayan quedado obsoletas o que no se van a volver a utilizar dentro del documento. 74/127

75 REQ-BO-DescripInforme: Se deberá añadir en el informe una descripción del objetivo de cada documento desarrollado de forma que sirva de ayuda a los usuarios finales para entender cual es el propósito de un determinado documento. 75/127

76 III.4.2 Informes Web Intelligence Los requisitos, normas y mejores prácticas para la creación de informes Web Intelligence son los siguientes: REQ-WI-NombreObjet: Los proveedores de datos y variables contenidos en cada documento deberán tener un nombre representativo que cumpla con la nomenclatura descrita en el requisito REQ-BO-CaracExtr. BP-WI-NumeroDatos: Se recomienda desarrollar el informe de manera que obtenga el menor número de datos posible. Aunque obtener un mayor volumen de datos en un mismo documento puede evitar sucesivas actualizaciones, esto tiene efectos adversos en el periodo de cálculo del documento. BP- WI-NumeroProveedor: Se recomienda que los informes se desarrollen con el menor número de proveedores de datos posible.. BP-WI-VariableLocal: Se recomienda utilizar el menor número de variables locales posible BP-WI-DiviDocum: Se recomienda dividir un documento en varios siempre que tenga como objeto disminuir el tiempo de cálculo y actualización total. El procesamiento de un documento único que contenga toda la información será más lento que el procesamiento de varios documentos independientes que contengan la misma información. BP-WI-CondicConsulta: Se recomienda utilizar condiciones en la consulta en lugar de filtros globales en los informes. 76/127

77 Siempre que sea posible, utilice los filtros globales de un documento como restricciones en la consulta de forma que el número de datos recuperado sea el menor posible. De esta forma se disminuye el tiempo de actualización. BP-WI-SinDatos: Se recomienda publicar los documentos al repositorio Business Objects sin datos con objeto de ocupar el menor espacio posible en el servidor. En los informes Web Intelligence no se puede usar una plantilla predefinida para cada informe. El aspecto original de un informe Web Intelligence es el mismo para todos los informes generados en un mismo entorno. La única forma de cambiarlo sería modificando en el servidor de Business Objects la plantilla general del informe, y esto no se puede realizar porque afectaría al resto de proyectos que comparten el entorno. REQ-WI-ModifPlantilla: No se permite modificar la plantilla original de un fichero Web Intelligence, ya que esto podría afectar a los informes de otros proyectos instalados en el mismo entorno. III.4.3 Informes Desktop Intelligence REQ-DI-DeskIntell: Como norma general para el desarrollo de informes de Query & Reporting, los informes deberán desarrollarse a través de Web Intelligence. No se permite el uso de Desktop Intelligence para el desarrollo de informes, salvo autorización expresa por parte de ICM. En el caso de utilizar Desktop Intelligence con autorización expresa de ICM, son aplicables todos los requisitos, buenas prácticas y nomenclatura mencionados para el caso de desarrollo de documentos Web Intelligence. III.4.4 Informes Crystal Reports A continuación se listan todos los requisitos, normas y buenas prácticas para el diseño y realización de informes con la herramienta Crystal Reports: 77/127

78 REQ-CR-AccesoDatos: Los informes Crystal Reports que se desarrollen accederán a la base de datos a través de universos o conectándose directamente a la base de datos utilizando el driver de Oracle. Los subinformes incrementan de forma considerable el tiempo de ejecución de los informes ya que cada objeto de este tipo contenido en el informe debe procesarse. REQ-CR-SubinfDetalle: Los Subinformes no deberán estar incluidos nunca en la sección de detalle del informe principal. En caso de que fuera necesario por circunstancias excepcionales deberá justificarse y consensuarse con ICM.. REQ-CR-DescripObjetivo: En todo informe de Crystal Reports se deberá añadir una descripción del objetivo de cada documento desarrollado de forma que sirva de ayuda a los usuarios finales para entender cual es el propósito de un determinado documento. XXVII Ilustración: Crystal Reports Propiedades del documento 78/127

79 REQ-CR-FormulaComent: Durante el desarrollo de un informe Crystal, se deben de incluir comentarios en las fórmulas (textos explicativos precedidos por // ) que expliquen exactamente la operación que se está realizando. REQ-CR-ParamVincul: Si los parámetros del informe principal se deben pasar a los subinformes, entonces los parámetros deberán vincularse ya que en caso contrario la petición de parámetros le aparecería por duplicado al usuario.. XXVIII Ilustración: Crystal Reports Inserción de un subinforme REQ-CR-WhilePrint: En el caso de utilizar variables compartidas para pasar valores entre subinformes (del informe principal a un subinforme o viceversa) las variables compartidas deberán utilizar la función WhilePrintingRecords para forzar la ejecución en el orden de las secciones. 79/127

80 REQ-CR-NumeroFila: El desarrollo del informe Crystal Reports debe de devolver el menor número de filas posible.. BP-CR-DiseñoInforme: Se recomienda que antes de comenzar a diseñar el informe Crystal Reports se definan las opciones por defecto. Opciones por defecto tales como el tipo y tamaño de la fuente, opciones de base de datos, etc. De esta forma se facilitará el proceso de diseño de los informes. Las opciones definidas afectarán tanto a la presentación de los informes como a su funcionalidad. Este tipo de opciones se encuentran en el menú Archivo-Opciones o Archivo-Opciones de Informe desde la barra de herramientas. Cualquier opción establecida desde el menú Archivo- Opciones afectará a todos los informes diseñados en ese puesto cliente en concreto. En cambio las opciones establecidas desde el menú Archivo-Opciones de Informe aplicarán al informe que se está desarrollando en ese momento. Algunas de las opciones disponibles se describen a continuación: Ficha Diseño. Contiene opciones relativas al desarrollo y formato del informe. Se recomienda activar las siguientes opciones: 80/127

81 XXIX Ilustración: Crystal Reports Ficha Diseño - Líneas de guía y Cuadricula (en la vista de diseño) ya que es útil para posicionar y mover objetos dentro del informe. - Nombres cortos de sección ya que dejamos más espacio libre para diseño. - Mostrar secciones ocultas ya que marca la sección con líneas diagonales. Ficha Base de Datos. Se recomienda activar las opciones, - Mostrar nombres. - Usar indices y servidor para rapidez. 81/127

82 XXX Ilustración: Crystal Reports Ficha Base de Datos Ficha Formula. En este caso se recomienda que la mayoría de los parámetros no se modifiquen. En el caso del procesamiento de valores nulos por defecto se establece permitir la distinción entre valores nulos y valor cero, aunque se deberá modificar si aplica. 82/127

83 XXXI Ilustración: Crystal Reports Ficha Editor de fórmulas Ficha Informe. Se recomiendan las siguientes opciones: XXXII Ilustración: Crystal Reports Ficha Informes 83/127

84 - Activar la opción Actualizar objetos del repositorio al abrir de forma que al abrir el informe aquellos objetos que pudieran haberse modificado se actualicen al abrir el informe. - Desactivar la opción Guardar datos con informe de forma que los informes se publiquen en el repositorio sin datos para ocupar menos espacio. Las opciones a establecer en el resto de fichas ( Campos, Fuentes, Vista Previa, Comprobador de dependencias) se establecerán en función de las necesidades específicas de cada informe. Cada informe se divide en 5 secciones: Encabezado del informe, Encabezado de la página, Detalles, Pie de y Pie del informe. Estas secciones no se pueden eliminar pero se pueden ocultar según las necesidades del informe a desarrollar. - Encabezado del Informe, aparece una vez al principio del informe. Situar aquí el título del informe y la información de resumen. - Pie del informe, aparece una vez al final del informe. Situar aquí la información totalizada (valores globales). - Encabezado y pie de página, aparecen en la parte superior e inferior de cada página del informe. Se utilizan para mostrar títulos y números de página en cada página del informe. - Detalle, contiene los bloques de datos. BP-CR-SecccSubsecc: Se recomienda que se aproveche al máximo la posibilidad de dividir las secciones en subsecciones que ayuden a organizar de forma adecuada los objetos a mostrar en el informe o añadir nuevas secciones insertando grupos. Las opciones relativas a estas secciones se modificarán desde el menú Informe Asistente de Sección. 84/127

85 XXXIII Ilustración: Crystal Reports Asistente de sección Algunas de las opciones a tener en cuenta son las siguientes, En la pestaña Común - Suprimir secciones en blanco. No se imprimirán aquellas secciones que aparezcan vacías. En la pestaña Paginación - Nueva página después. Activar esta opción si se desea que la información relativa a cada sección aparezca en una página diferente. En caso de que la sección correspondiente al Pie del informe se encuentre vacía, la última página del informe aparecería en blanco por lo que para evitar mostrar esta página en el editor de fórmulas incluir la sentencia not onlastrecord. - Nueva página antes. Para evitar que la primera página aparezca en blanco, incluir en el editor de fórmulas la sentencia not onfirstrecord 85/127

86 BP-CR-SeccionGrupo: En el caso de que la información pueda presentarse, ordenarse o resumirse de forma significativa para el usuario final es recomendable crear grupos. Sin embargo, siempre que sea posible se establecerán las agrupaciones de datos directamente en la base de datos ya que se mejora el rendimiento de los informes. Si utilizamos los filtros predefinidos con peticiones de orden procedentes del universo en los subinformes de un informe, tendremos las peticiones repetidas por lo que el usuario deberá introducir los valores varias veces. BP-CR-PeticInforme: En el caso de utilizar informes que contengan subinformes que necesiten peticiones de orden, se recomienda crear las peticiones dentro del informe en lugar de en el universo. BP-CR-TratamNulos: En el caso de querer definir en el informe Crystal la manera en que se tratarán los valores nulos que recupere de la base de datos, se recomienda definir el tratamiento de dichos valores nulos para una fórmula concreta, para un informe concreto o para todos los informes respectivamente tal y como se describe a continuación, según convenga en cada caso, i. Desde el editor de fórmulas. 86/127

87 XXXIV Ilustración: Crystal Reports Definición de nulos en el editor de fórmulas ii. Desde las opciones del informe. XXXV Ilustración: Crystal Reports Definición de nulos en las opciones del informe iii. Desde la ficha Editor de Formulas en el menú Opciones. XXXVI Ilustración: Crystal Reports Definición de nulos en la ficha Editor de fórmulas BP-CR-SqlConver: Siempre que sea posible se recomienda evitar las funciones SQL de conversión de tipos de datos. 87/127

88 BP-CR-PaginaNdeM: Si es posible, se recomienda evitar el uso de n de m ya que ralentiza el tiempo de construcción de la primera página en las peticiones bajo demanda ya que antes de mostrar la primera página debe calcular todas las demás para calcular el número total de páginas del informe. Una plantilla de Crystal Reports es un archivo de informe existente cuyo formato se puede agregar a un informe nuevo. Al mismo tiempo, el formato de los objetos de informe y de los campos del informe de la plantilla se aplica al informe nuevo. Las plantillas se utilizan para proporcionar un aspecto coherente a una serie de informes sin tener que aplicar formato individualmente a cada uno. BP-CR-PlantillaCrystal: Se recomienda el uso de ficheros de plantillas Crystal Reports, en el caso en que se vayan a crear varios documentos con un formato común. En este caso, los ficheros de plantillas Crystal Reports deberán situarse en la carpeta ${Dir instalación}\crystal Reports 11.5\Templates de los equipos locales en los que desarrolle el proveedor. Esta práctica solo aplica en los desarrollos locales a partir de la herramienta cliente de Crystal Reports. REQ-CR-EntregaPlantillas: En el caso de que se utilicen plantillas comunes para los informes de Crystal Reports, estas se deberán adjuntar a la entrega del proyecto. * Nota: La aplicación de este requisito no es obligatoria en los proyectos Nexus, porque la instalación en los distintos entornos no va a ser realizada directamente por ICM. 88/127

89 III.4.5 Informes Xcelsius A continuación se listan todos los requisitos, normas y buenas prácticas para el diseño y realización de informes con la herramienta Xcelsius. Cuando se previsualiza o exporta una visualización Xcelsius, todos los datos, lógicas, formatos incorporados a partir de la hoja de cálculo de Microsoft Excel están compilados como Adobe Flash para producir un archivo Shockwave Flash (SWF). BP-XC-AdobeFlash: Se debe de tener en cuenta que cuando distribuye su visualización Xcelsius como un SWF, todos los usuarios finales necesitan el Adobe Flash Player (versión 9 o posterior) para poder visualizarlos Nota: Microsoft Excel sólo se requiere en tiempo de diseño al construir un informe Xcelsius. Si exporta a Microsoft PowerPoint, Microsoft Word, HTML, o ejecuta en su escritorio el SWF, puede que el SWF no funcione si se intenta recuperar datos o ir a una página Web debido a las restricciones de seguridad de Adobe Flash. BP-XC-AplicConfianza: Para ejecutar un SWF en su escritorio, necesita definir que es una aplicación de confianza, de manera que pueda tener acceso a sitios web o datos locales. Para definir un SWF de confianza puede usar el Administrador de configuración global (Global Settings Manager) o a través del archivo de configuración FlashPlayerTrust. Xcelsius 2008 admite muchas de las funciones de Microsoft Excel. BP-XC-FuncionExcel: Es recomendable asegurarse que la Hoja de cálculo de Excel utiliza sólo las funciones de Excel que son soportadas por Xcelsius 2008 de otra forma, durante la vista previa, podría ser que la visualización del informe no fuera la esperada. La versión de Excel utilizada debe ser soportada por Xcelsius /127

90 A continuación se listan todas las funciones de Microsoft Excel admitidas por Xcelsius 2008: XXXVII Ilustración: Funciones de Microsoft Excel admitidas por Xcelsius /127

91 Todas las funciones Microsoft Excel se compilan en Adobe Flash en tiempo de previsualización o exportación. Algunas de estas funciones tienen un rendimiento más alto sobre pequeños conjuntos de datos (decenas de filas), al compilarse en Adobe Flash. BP-XC-EvitFuncion: Para mejorar el rendimiento, siempre que sea posible se recomienda evitar el uso de las siguientes funciones en grandes conjuntos de datos: - SUMAR.SI - CONTAR.SI - BUSCARH - BUSCARV Si necesita accedes a grandes cantidades de datos, realice la agregación de los datos en el servidor. BP-XC-ColorEtiquet: Para facilitar el uso y mantenimiento de los informes Xcelsius, se recomienda el uso de colores, etiquetas y bordes, para identificar en las hojas Excel, las celdas o rangos de celdas que se utilizan, y el uso que se hace de ellas..se recomienda igualmente crear una leyenda en la hoja de cálculo para indicar lo que representan los diferentes colores (Entrada de Xcelsius, cálculos en la hoja de cálculo, búsquedas, datos dinámicos). De esta manera puede generar un esquema de colores que tenga sentido dentro del proyecto ICM que se esté desarrollando. BP-XC-SeleccDatos: Para facilitar la selección de los datos dentro de la hoja de cálculo, se recomienda colocar en la parte de arriba de la hoja de cálculo aquellas filas y celdas que contienen la información utilizada en los informes Xcelsius. 91/127

92 XXXVIII Ilustración: Xcelsius Ejemplo de uso de colores y etiquetas, y acceso rápido a los datos Xcelsius 2008 no admite la utilización de hojas de cálculo que tienen enlaces a otras hojas de cálculo o que contengan macros. BP-XC-HojaVacia: Se recomienda comenzar un informe Xcelcius con la hoja de cálculo vacía que está incrustada en Xcelsius Usando la hoja de cálculo vacía reduce el riesgo de que utilice funciones de Microsoft Excel o plugins de Xcelsius 2008 que no se soporten. 92/127

93 Contra más información tenga en la hoja de cálculo, más tiempo tardará en generarse el fichero SWF, y más tiempo en abrirse. Igualmente, si la información contenida en la hoja de cálculo contiene muchos cálculos, cualquier cambio en algunas celdas alargará el tiempo de recalculo del informe total. BP-XC-EliminDatos: Se recomienda eliminar de la hoja de cálculo toda aquella información que no necesite para la visualización del Xcelsius. BP-XC-DatosFijos: Si se utilizan funciones o valores que no cambian (no son dinámicos o usados en escenarios what-if), para asegurarse una visualización más eficiente, se recomienda que convierta esos datos en valores fijos usando Copiar y Pegar Especial (como valores) de la hoja de cálculo. Frecuentemente querrá esconder o mostrar diferentes componentes dentro de Xcelsius en función de un cambio de datos o interactuación del usuario. Para controlar cuando los componentes son visibles, puede usar la visibilidad dinámica. Por ejemplo, cuando la celda A1 tiene el valor 1, este componente está visible, de lo contrario, está oculto. BP-XC-DinamVisual: Es recomendable el uso de la dinámica de visualización en las visualizaciones Xcelsius que desarrolle para que pueda probar la interactividad de ocultar y mostrar los componentes 93/127

94 BP-XC-PlantillasXC: Se recomienda el uso de ficheros de plantillas Xcelsius, en el caso en que se vayan a crear varias visualizaciones documentos con un formato común. En este caso, los ficheros de plantillas Xcelsius deberán situarse en la carpeta ${Dir instalacion} \Xcelsius 2008\assets\template de los equipos locales en los que desarrolle el proveedor. Se recomienda organizar las plantillas por categorías. Para ello puede crear en la ruta ${Dir instalacion}\xcelsius\assets\template los directorios que necesite, apareciendo posteriormente en la aplicación una categoría por directorio creado, con las plantillas de cada categoría en su interior. Esta práctica solo aplica en los desarrollos locales a partir de la herramienta cliente de Xcelsius. BP-XC-IncrustarSwf: Para incrustar de manera más sencilla la visualización Xcelsius SWF en una página Web, se recomienda exportar a HTML desde Xcelsius de manera que el SWF asociado será exportado también. BP-XC-ProbarSwf: Se recomienda probar el SWF en modo de vista previa, y también en el entorno ICM donde se vaya a desplegar. Es importante comprobar este punto porque cuando se ejecuta fuera del diseñador de Xcelsius 2008, Adobe Flash tiene ciertas restricciones de seguridad, explicadas a continuación. Seguridad Flash Player Dependiendo de cómo se distribuye o se ejecuta el SWF generado con Xcelcius, pueden existir ciertas restricciones de seguridad por parte del Adobe Flash Player que lo ejecuta. Para que se puedan consultar los datos que necesita en tiempo de diseño o de visualización previa, Xcelsius 2008 no aplica las restricciones de seguridad, de manera que si exporta su visualización Xcelsius Adobe Acrobat, no se aplicarán dichas restricciones en su SWF. 94/127

95 Si se exporta el SWF a otro tipo de de salida si que podrían existir restricciones de seguridad en tiempo de ejecución al ejecutar el SWF. La lista de posibles errores Adobe se encuentra en esta dirección: Puede exportar un fichero Xcelsius a numerosos formatos, a través de la opción Exportar del menú de ficheros XXXIX Ilustración: Xcelsius Menú de Exportar visualización de Xcelsius Xcelsius 2008 incluye una serie de plantillas que se pueden utilizar para crear visualizaciones. Puede utilizar estas plantillas o bien crear una visualización nueva y guardarla como plantilla. Las plantillas se utilizan para proporcionar un aspecto coherente a una serie de informes sin tener que aplicar formato individualmente a cada uno. REQ-XC-EntregaPlantillas: En el caso de que se utilicen plantillas comunes para los cuadros de mandos de Xcelsius, estas se deberán adjuntar a la entrega del proyecto. REQ-XC-EntregaFuentes: En el caso de que en un proyecto se utilicen informes de XCelsius, los ficheros fuente de dichos informes (tanto los archivos de xcelsius como las hojas Excel independientes si existiesen) deberán ser incluidos en la entrega, en el directorio fuentes del módulo de bo destinado para ello. 95/127

96 III.4.6 Informes Voyager Voyager es una herramienta de análisis OLAP basada en Web con la que podrá acceder a datos multidimensionales, representados mediante cubos de datos. XL Ilustración: Cubos de datos para su explotación con Voyager A continuación se listan todos los requisitos, normas y buenas prácticas para el diseño y realización de informes con la herramienta Voyager: REQ-VO-PopUp: Para usar correctamente Voyager, se debe habilitar los cuadros de diálogo Pop-up en el navegador. De no hacerlo, no estarían accesibles algunas funcionalidades de Voyager. BP-VO-DimensEjes: Hay que tener en cuenta al desarrollar un informe Voyager que cuando crea o modifica una consulta realizada con Voyager no se pueden agregar miembros de la misma dimensión a dos ejes Cuando se coloca una dimensión en un eje de fila, columna o sector, el miembro predeterminado de la dimensión se selecciona automáticamente. Con Microsoft Analysis Services, el miembro predeterminado de la dimensión se puede establecer en el servidor OLAP. Para otros proveedores OLAP, el miembro predeterminado es el primero del nivel superior de la dimensión. 96/127

97 BP-VO-InsertGrafico: La mejor manera para insertar un gráfico en el área de trabajo de Voyager, es arrastrar el botón de familia de gráficos que elija a la ventana de análisis. De esta manera, se agregará el tipo de gráfico predeterminado de la familia de gráficos que ha escogido, y a continuación, puede cambiar el tipo de gráfico de entre los disponibles. Si los miembros principales están ocultos, puede que el gráfico no muestre exactamente los mismos datos que la tabla de referencias cruzadas vinculada a la misma consulta. BP-VO-ExplorarDatos: Al analizar los datos OLAP, puede explorar los datos de las transacciones relacionales subyacentes que han contribuido a un determinado valor de celda Se debe tener en cuenta que: La función de exploración sólo está disponible al ejecutar Análisis Services de Microsoft SQL Server 2000 u orígenes de datos posteriores. Con Analysis Services de Microsoft SQL Server 2000, la función de exploración debe activarla el administrador de base de datos en el nivel de cubo. A su vez, el administrador de base de datos debe concederle permiso para realizar una operación de exploración en una función de cubo. BP-VO-ExportarExcel: Si decide exportar datos a Excel desde un área de trabajo publicada y, a continuación, guarda la hoja de cálculo de Excel recién creada, tenga en cuenta que los datos se guardan en un disco duro local y no en BusinessObjects Enterprise. Un área de trabajo de Voyager contiene varias páginas y el área de trabajo predeterminada contiene tres páginas. Las páginas son útiles para agrupar análisis relacionados juntos en un área de trabajo. Por ejemplo, un área de trabajo de Voyager podría representar la solución a un determinado problema y cada página representa un paso de la solución. 97/127

98 El desplazamiento entre las páginas se realiza con las fichas de página y los controles de página de la parte inferior de la ventana de análisis. Se puede cambiar el nombre de las páginas, así como copiar, agregar y eliminar haciendo clic con el botón derecho en una ficha de página. Hay que tener en cuenta que: Al guardar las áreas de trabajo, se conservan el estado de la página activa y el estado del panel de fichas. Por ejemplo, si guarda un área de trabajo con la página 3 activa, dicha página estará activa la próxima vez que se abra el área de trabajo y el panel de fichas reflejará los metadatos y las consultas de la página 3. Cada página posee su propio conjunto de consultas y componentes, que no se comparten y que no se pueden vincular entre las páginas. Por tanto, las consultas y los componentes de una página pueden tener los mismos nombres que las consultas y los componentes de otras páginas. La longitud máxima de un título de página es de 60 caracteres. BP-VO-AreaTrabajo: Para guardar un área de trabajo en el repositorio de BusinessObjects Enterprise, debe tener derechos suficientes por parte del administrador del entorno Business Objects de ICM Si deja el área de trabajo inactiva, Voyager guarda automáticamente el área de trabajo en la carpeta Favoritos como "Guardar automáticamente (Voyager)" antes de que termine la sesión. Normalmente, una sesión termina después de aproximadamente 20 minutos de inactividad, a no se que el administrador del sistema haya establecido la duración del tiempo de espera a un valor diferente. Tenga en cuenta que: Puesto que el área de trabajo "Guardar automáticamente (Voyager)" se sobrescribe cada vez que se guarda automáticamente un área de trabajo, debe guardar manualmente las áreas de trabajo que desee conservar, con nombres de archivo únicos. 98/127

99 Además de guardar áreas de trabajo, puede exportar datos de áreas de trabajo de Voyager a Microsoft Excel o a un archivo de valores separados por comas. BP-VO-BaraHerram: Hay que tener en cuenta que algunos de los botones de la barra de herramientas podrían estar desactivados, según los derechos que se hayan asignado a los usuarios en la Consola de administración central, y dependiendo de qué objeto o componente esté seleccionado en la ventana de análisis. La opción Suprimir nulos elimina una fila o una columna únicamente si todas las celdas de esa fila o columna son nulas. BP-VO-SuprimirNulo: Hay que tener en cuenta que la inclusión de un cálculo en una celda que contiene un valor nulo (como por ejemplo un ranking) provoca que reaparezcan las filas o columnas suprimidas anteriormente. BP-VO-PersonaInfow: Hay que tener en cuenta que no se puede definir simultáneamente en la página de My Infoview ( de inicio de infoview para cada usuario del entorno Business Objects en ICM) más de un área de trabajo de Voyager, aunque defina la página de inicio con dos o más ventanas. 99/127

100 BP-VO-FiltradoDatos: Se recomienda que se realice el filtrado de datos de un campo con las opciones mayor que o menor que, en lugar de no igual a, ya que esta última opción provoca que no se filtren correctamente algunos campos con un valor muy aproximado al utilizado en el filtro. III.4.7 Informes Live Office A continuación se listan todos los requisitos, normas y buenas prácticas para el diseño y realización de informes con la herramienta Live Office: Al usar Live Office para insertar datos en un documento, puede elegir entre el contenido de Crystal Reports o Web Intelligence almacenado en el repositorio de BusinessObjects Enterprise. Los informes almacenados en el repositorio de Business Objects se denominan objetos de informe. BP-LO-ObjetoInforme: Hay que tener en cuenta que en Live Office, se trabaja con objetos de informe porque están conectados al contenido más reciente almacenado en las bases de datos. De modo que, al crear un informe, se asegura que contiene la información actualizada. Cuando se crea un informe con Crystal Reports o Web Intelligence Report Panel, su información puede proceder de varias bases de datos. El informe de origen se denomina objeto de informe, porque es un objeto de datos de origen y contiene información de varios orígenes de datos. El objeto de informe devuelve datos del origen de datos subyacente, a petición de la base de datos o según la opción de actualización elegida. Instancias de informe: Una instancia es una versión del objeto creado por Business Objects Enterprise cuando los usuarios modifican el documento de origen o programan los informes. Cada instancia contiene datos actuales en el momento de procesar el informe de origen. 100/127

101 En concreto, una instancia de informe es un objeto de informe que contiene datos de informe recuperados de una o varias bases de datos. Normalmente, los objetos de informe están diseñados de manera que se pueden crear varias instancias con características diferentes. Por ejemplo, si los usuarios ejecutan un objeto de informe que contiene parámetros, pueden programar una instancia que contenga datos de un departamento determinado y programar otra que contenga información sobre otro departamento, aunque ambas instancias procedan del mismo objeto de informe. Secciones de informe: Una parte de una sección de un informe que se muestra sola, sin el resto de la página del informe, se denomina sección de informe. De forma más precisa, las secciones de informe son objetos que utilizan hipervínculos para señalar desde un objeto de informe de origen a un objeto de destino de Live Office. Las secciones de informe incluyen objetos como texto o gráficos. El siguiente diagrama muestra la relación entre los objetos de informe, las instancias de informe y las secciones de informe en Live Office. XLI Ilustración: Relación entre los objetos, las instancias y las secciones de informe en Live Office 101/127

102 La tabla siguiente explica cómo funciona la compatibilidad con campos y secciones de informe, por ejemplo gráficos y texto, en Live Office. XLII Ilustración: Tabla de contenidos de Live Office Nota: No se admiten los subinformes de Crystal Reports incrustados. Después de insertar un objeto de Live Office en el documento de Microsoft Office, se puede realizar un conjunto de tareas comunes: Publicar y ver archivos Se puede utilizar Live Office para publicar documentos en BusinessObjects Enterprise. BP-LO-PublicVer: Hay que tener en cuenta que para publicar un documento en BusinessObjects Enterprise, debe tener derechos de publicación. Para ver el documento, los usuarios deben tener derechos de visualización sobre el documento Consulta de un documento publicado Se puede abrir un documento publicado si tiene derechos de visualización sobre el documento en BusinessObjects Enterprise. 102/127

103 BP-LO-DocumPublica: Hay que tener en cuenta que para ver el documento publicado, debe tener instalados en el equipo la aplicación correspondiente de Office: Word, Excel, Outlook o PowerPoint. Abrir un documento en una unidad local BP-LO-DocumUnidad: Es posible abrir un documento en su equipo local sin conectarse a BusinessObjects Enterprise. Sin embargo, si no se conecta a BusinessObjects Enterprise, no se podrá utilizar la funcionalidad de Live Office para modificar el objeto ni para actualizar los datos. Si se ocultan los datos al guardar el documento, los usuarios que lo abran deberán actualizar los objetos para ver los datos importados. Para actualizar los objetos, los usuarios deben tener instalado Live Office y disponer de acceso al objeto de origen en BusinessObjects Enterprise. Publicación de un documento en BusinessObjects Enterprise Cuando se finaliza un documento, se puede publicar en BusinessObjects Enterprise para que lo consulten otros usuarios. Se puede utilizar BusinessObjects Enterprise para administrar cualquier documento de Microsoft Word, Microsoft Excel, Outlook y Microsoft PowerPoint. El documento no tiene que contener ningún dato importado. Resolución de problemas comunes en Live Office /127

104 A continuación se describen problemas que puede encontrarse de manera común trabajando con Live Office 3.1, y las mejores prácticas para su resolución. Problema: El menú de LiveOffice ha desaparecido Causa: El complemento de Live Office no está activado adecuadamente. Solución: Debe ejecutar el archivo enable_addin.exe que se encuentra en la ruta ${Install Dir}\Business Objects\BusinessObjects Enterprise 12.0\Live Office 12.0 Problema: Falló la actualización del documento Causa: Por diseño, existen casos conocidos en los que falla la actualización del objeto de Live Office. La causa más común de estos errores de actualización es que la estructura subyacente del informe de origen ha cambiado desde que se actualizó el objeto de Live Office por última vez. Por diseño, podrían ocurrir fallos de actualización por una de las siguientes causas. o o o o o El tipo de sección de informe ha cambiado. Por ejemplo, de una tabla a un gráfico. El archivo de origen de Web Intelligence o Crystal Reports se ha eliminado de BusinessObjects Enterprise. El universo de origen ha cambiado o se ha eliminado Los campos de tabla o restricciones de base de datos SQL han cambiado o se han eliminado. Por ejemplo, el tipo de campo o restricción de base de datos especificado no es válido o no está disponible. No está disponible ninguna instancia. Solución: Debe aparecer un mensaje de error e indicar el origen del problema. Si no aparece o no resulta útil, compruebe el archivo de registro y si la estructura del informe ha sufrido algún cambio reciente. Problema: El orden y el filtro del informe se pierden al actualizar. Causa: Las operaciones de ordenación y filtrado basadas en Microsoft Excel no se admiten por completo en Live Office. Solución: Vuelva a aplicar estas operaciones después de actualizar el objeto de Live Office. El resto del formato del informe se conserva. Problema: Acceso denegado a un universo 104/127

105 Causa: No tiene suficientes derechos de acceso para el universo. Se muestra un mensaje de error cuando intenta actualizar una consulta o no puede ver los objetos en un universo mostrado. Solución: Póngase en contacto con el administrador del sistema ICM para que le proporcione suficientes derechos para acceder al universo. Límites de tamaño de objetos de Live Office Para cada aplicación Microsoft Office que es compatible con Live Office, hay un número máximo de filas y columnas que puede existir en una tabla u hoja de cálculo. Esto afecta a la cantidad de datos que puede insertar en un objeto porque Live Office inserta los datos en forma de tabla o como filas y columnas en una hoja de cálculo. Estos límites los definen las aplicaciones Microsoft Office, de modo que es útil conocer estos límites al planificar a partir de qué datos va a crear un objeto. Microsoft Word Número máximo de filas = Número máximo de columnas = 63 Microsoft Excel Número máximo de filas = Número máximo de columnas = 256 Nota: Si en lugar de MS Excel 2003 se usa MS Excel 2007 no se aplicarán las anteriores limitaciones. PowerPoint Número máximo de filas = 50 Número máximo de columnas = 25 III.5 Requisitos de Seguridad Los ficheros BIAR que los proveedores entregan a ICM, y que contienen todos los objetos Business Objects que se van a exportar (universos, informes, etc), contienen la información relativa a la seguridad de estos elementos asignada a los grupos de usuarios. 105/127

106 BP-SE-EstrucSeguridad: Business Objects recomienda que se estructure la seguridad del sistema entorno a dos ejes: Lo que un usuario puede hacer (basado en roles) A qué contenido puede acceder un usuario. La distinción es importante, porque pudiendo hacer algo por derecho, como actualizar un documento o tener acceso a un universo, siempre se relaciona con el contenido al que puede acceder el usuario. Un modelo de seguridad debería ser fácil de administrar y lo suficientemente restrictivo en cuanto a la funcionalidad y el contenido para que los usuarios no puedan hacer o acceder a cosas que no deben. También se debe garantizar que los usuarios pueden ver lo que tienen permiso para ver y hacer lo que tienen permiso para hacer en el nuevo entorno. 106/127

107 Para la administración de derechos habrá que tomar en cuenta los siguientes puntos obligatorios: REQ-SE-NivelesAcceso: Es obligatorio el uso de niveles de acceso. Estos conjuntos de derechos predefinidos simplifican la administración agrupando los derechos asociados con las necesidades comunes del usuario. Se utilizarán por defecto los cuatro niveles de acceso que vienen predefinidos con la plataforma (Control total, Programación, Ver y Ver a petición), aunque se permiten niveles de acceso personalizados. REQ-SE-NivAccesoPerso: En el caso de utilizarse Niveles de Acceso Personalizados, la nomenclatura para ellos será la siguiente: XXXX_NAP_Descripción, donde XXXX es el nombre del proyecto, y la Descripción se compondrá de una o varias palabras, con la primera letra de cada palabra en mayúsculas y el resto en minúsculas, no permitiéndose el uso de espacios en blanco. Sólo se podrán utilizar caracteres alfanuméricos: a-z, A-Z, 0-9, no permitiéndose el uso de caracteres acentuados ni la letra ñ. El número de caracteres máximo que se puede usar en el nombre del niver personalizado es de 100 caracteres. REQ-SE-DerecCarpetas: Si se van a importar documentos sobre una carpeta ya existente en el entorno Business Objects, se deben establecer los derechos adecuados para usuarios y grupos en el nivel de dicha carpeta y, a continuación, publicar los objetos en la carpeta. De manera predeterminada, los usuarios o grupos que tienen derechos sobre una carpeta heredan los mismos derechos para cualquier objeto que se publique posteriormente en esa carpeta. REQ-SE-DererGrupos: Se deben organizar los usuarios en grupos de usuarios. Seguidamente asignar niveles y derechos de acceso a todo el grupo. Sólo se asignarán niveles y derechos de acceso a miembros específicos cuando sea necesario, y previa autorización por parte de ICM. 107/127

108 Los entornos de ICM contendrán simultáneamente varios proyectos desplegados, por lo que es necesario establecer todas las políticas de seguridad de manera que un usuario autenticado en la plataforma sólo tenga acceso a los objetos de los proyectos que puede utilizar (carpetas, universos, conexiones, etc.). Para asegurar este requisito, en los entornos de ICM por defecto se deniega la seguridad a todos los usuarios sobre todos los objetos (se quita el permiso al grupo Todos ), de manera que hay que asignar explícitamente la seguridad sobre todos los objetos a los grupos de usuarios que conforman el proyecto. Para ello se definen los requisitos listados a continuación: REQ-SE-CarpetaNivSuper: Se deben establecer los derechos y los niveles de acceso en las carpetas de nivel superior. Al activar la herencia se permitirá que estos derechos se transmitan por el sistema con una intervención administrativa mínima. REQ-SE-SegCarpetaPrincipal: La carpeta principal del proyecto (con nombre XXXX) deberá tener denegado el permiso al grupo de usuarios Todos, y asignados los permisos necesarios a cada uno de los grupos del proyecto. A continuación se muestra un ejemplo de definición de la seguridad para la carpeta principal de un proyecto: 108/127

109 XLIII Ilustración: Seguridad de Carpeta Principal REQ-SE-SegCarpetaUniversos: La carpeta de universos en la que se incluyen todos los universos de un determinado proyecto (llamada XXXX), deberá tener denegado el permiso al grupo de usuarios Todos, y asignados los permisos necesarios a cada uno de los grupos del proyecto según la necesidad. REQ-SE-SegUniversos: Todos los universos de un proyecto por defecto heredan la seguridad de la carpeta de universos. Si se desease restringir el acceso a un determinado universo sólo a ciertos grupos del proyecto, se definirá dicha restricción en la seguridad del propio universo, sobrescribiendo la seguridad heredada de la carpeta. A continuación se muestra un ejemplo de definición de la seguridad para la carpeta que contiene los universos de un proyecto: 109/127

110 XLIV Ilustración: Seguridad de la carpeta de Universos A continuación se muestra la configuración de seguridad para un universo de un proyecto, que sobrescribe la seguridad de la carpeta para ciertos grupos a los que se les quiere liminar el acceso a ese universo: 110/127

111 XLV Ilustración: Seguridad de Universo REQ-SE-SegConexiones: Las conexiones de un proyecto deberán tener denegado el permiso al grupo de usuarios Todos, y asignados los permisos necesarios a cada uno de los grupos del proyecto. A continuación se muestra un ejemplo de definición de la seguridad una conexión de un proyecto: 111/127

112 XLVI Ilustración: Seguridad de Conexión REQ-SE-SegAplicaciones: Por defecto, los usuarios no tienen permiso para utilizar ninguna de las aplicaciones de la plataforma. Se deberá otorgar permiso explícitamente a los grupos de usuarios de un proyecto para el uso de las aplicaciones (por ejemplo, en la seguridad de InfoView). A continuación se muestra un ejemplo de definición de la seguridad de la aplicación Infoview: 112/127

113 XLVII Ilustración: Seguridad de InfoView 113/127

114 IV REQUISITOS DE ENTREGA En este apartado se indican los requisitos que deben cumplir los proveedores durante la entrega de los desarrollos Business Objects. * Nota: La aplicación de los requisitos definidos en este apartado no es obligatoria en los proyectos Nexus, porque la instalación en los distintos entornos no va a ser realizada directamente por ICM. Son los siguientes: REQ-RE-DocumEntrega: El proveedor deberá rellenar y entregar los documentos Ficha de Entrega General, Ficha de Entrega de Desarrollos en Business Objects y Ficha de Entrega de Desarrollo con Data Services, indicando claramente toda la información que se le solicita. * Nota: La aplicación de este requisito no es obligatoria en los proyectos Nexus, porque la instalación en los distintos entornos no va a ser realizada directamente por ICM. REQ-RE-GuiaErwin: Se debe entregar un fichero ERWIN para el módulo de Base de Datos, según se define en la normativa específica para diseño del modelo de datos. * Nota: La aplicación de este requisito no es obligatoria en los proyectos Nexus, porque la instalación en los distintos entornos no va a ser realizada directamente por ICM. REQ-RE-BusinessObjects: Las entregas del proveedor deberán seguir la nomenclatura y estructura de carpetas definidas en la normativa. * Nota: La aplicación de este requisito no es obligatoria en los proyectos Nexus, porque la instalación en los distintos entornos no va a ser realizada directamente por ICM. Todos los desarrollos que el proveedor tenga que entregar (ficheros Excel, XCelsius, Webi, etc.) deberán ser previamente publicados en el repositorio del proveedor, a partir del cual se generará el fichero BIAR a entregar. 114/127

115 La carpeta para las imágenes en la entrega, se utilizará para aquellas imágenes que no puedan ser adjuntadas dentro del BIAR y que deban ser copiadas directamente en el servidor (no están dadas de alta en el repositorio de Business Objects). IV.1 Entregas Incrementales No es objeto de esta metodología definir el procedimiento para entrega de proyectos de manera incremental (entregas parciales una vez que el proyecto se encuentra en producción). Por tanto, todo lo indicado en los siguientes apartados se limita a entregas totales de proyectos. La metodología para entregas incrementales se describe en el documento adjunto ICM-Metodología Entregas Incrementales Business Objects. * Nota: La aplicación de la normativa para entregas incrementales no es obligatoria en los proyectos Nexus, porque la instalación en los distintos entornos no va a ser realizada directamente por ICM. IV.2 Estructura de Entrega * Nota: La aplicación de los requisitos definidos en este apartado no es obligatoria en los proyectos Nexus, porque la instalación en los distintos entornos no va a ser realizada directamente por ICM. XXXX se refiere al nombre del proyecto. La entrega contendrá un directorio para cada módulo entregado. Los módulos que se identifican para este tipo de proyecto son: Módulo de Base de Datos: Contiene toda la información de la entrega relativa a modelo de datos de DataWarehouse. Módulo de Business Objects: Contiene toda la información de la entrega relativa a Business Objects. Módulo de Data Services: Contiene toda la información de la entrega relativa a Data Services (sólo existe si el proyecto contiene una fase de ETL). En los siguientes apartados se muestra la estructura de entrega para cada uno de los módulos. IV.2.1 Módulo de Base de Datos La entrega del módulo de datos se hará según la normativa correspondiente de base de datos. 115/127

116 IV.2.2 Módulo de Business Objects para proyectos de BO 3.1 El nombre del módulo seguirá la nomenclatura XXXX_bo_dw. Existirá una carpeta con este mismo nombre, en la que se incluirán la estructura de carpetas descrita en la siguiente tabla: /XXXX_bo_dw/biar SOLO EN ENTREGAS TOTALES: Contendrá el fichero XXXX.BIAR con todos los objetos exportados de la plataforma de desarrollo Business Objects del proveedor para su entrega a ICM. Si se utilizasen varios ficheros biar, se numerarán consecutivamente: XXXX1.BIAR, XXXX2.BIAR, etc. /XXXX_bo_dw/biar/incremental SOLO EN ENTREGAS INCREMENTALES: Contendrá el fichero XXXX.BIAR con los objetos exportados de la plataforma de desarrollo Business Objects que corresponden a esta entrega incremental. Si se utilizasen varios ficheros biar, se numerarán consecutivamente: XXXX1.BIAR, XXXX2.BIAR, etc. /XXXX_bo_dw/biar/validacion /XXXX_bo_dw/biar/validacion/incremental USO INTERNO: Directorios de uso interno para la Unidad de Paso a Producción /XXXX_bo_dw/biar/validacion/version_anterior /XXXX_bo_dw/biar/produccion /XXXX_bo_dw/biar/ produccion /incremental /XXXX_bo_dw/biar/produccion/version_anterior /XXXX_bo_dw/img Contendrá los ficheros con las imágenes (logos, fotos, etc) que deben situarse en el directorio ${Install Dir}\Business Objects\BusinessObjects 116/127

117 Enterprise 12.0\images\XXXX /XXXX_bo_dw/plantillas/creports /XXXX_bo_dw/plantillas/xcelsius /XXXX_bo_dw/fuentes En el caso de que se hayan utilizado plantillas para Crystal Reports, contendrá dichas plantillas. En el caso de que se hayan utilizado plantillas para Xcelsius, contendrá dichas plantillas. En el caso de que se hayan utilizado archivos fuente que no se incluyan en el BIAR (por ejemplo los archivos fuente de Xcelsius con extensión xlf, o las Hojas Excel con extensión xls), se incluirán dichos archivos fuente en este directorio. El proveedor utilizará el fichero BIAR para exportar los siguientes objetos de la plataforma Business Objects: Grupos de usuarios Carpetas y objetos Universos y conexiones Documentos de empresa, personales y de la bandeja de entrada Documentos "agnósticos" (como.pdf,.ppt,.doc,.xls,.txt,.rtf) Categorías personales y de plataforma Objetos de Information Designer Niveles de acceso personalizados (no los predeterminados con la plataforma). IV.2.1 Módulo de Business Objects para proyectos de BO 4.1 Para los proyectos que se desarrollen para BO 4.1 la nomenclatura y las carpetas van a ser las mismas pero va a ser distinto del contenido de la carpeta biar. En la versión BO 4.1 la herramienta para generar los ficheros biar (lcmbiar) es Promotion Manager (administrador de promociones) que está accesible a través de la consola de la CMC. Dentro de las carpetas del sistema existe una carpeta LCM que es donde se crean las distintas tareas de la herramienta Promotion Manager. Dentro de esta carpeta vamos a crear una estructura de 117/127

118 carpetas que nos permite organizar las entregas. Se creará una carpeta por cada proyecto y dentro de dicha carpeta aparecerán dos carpetas: entregas e instalaciones. En la carpeta XXXX/entregas con la siguiente nomenclatura (fecha y version de la entrega): fecha_vx.x.x. Ejemplo: _v1.0.0 Esta etiqueta se debe corresponder con el nombre de la carpeta de la entrega en subversion. Una vez creada la carpeta ya se pueden crear las tareas para exportar los contenidos a un fichero con extensión lcmbiar. Para garantizar el correcto exportado/importado de los ficheros lcmbiar vamos a generar tres tareas distintas con la nomenclatura siguiente: 118/127