Blog del CIIN

Una de las cuestiones que se nos ha planteado recientemente es sobre la integración de la plataforma SharePoint y Microsoft Project. Aunque ya había leído algo al respecto a través de un par de posts de mi buen amigo Gustavo Vélez, Project Server y SharePoint un buen matrimonio pero uno de conveniencia y Continuando con hacer las cosas bien, no ha sido hasta hace unos pocos días cuando he indagado sobre lo bien que se integran la plataforma SharePoint y Microsoft Office Project Server 2007. La idea de este post, y espero que otros, es mostraros esta integración tan espectacular entre ambas plataformas. Empecemos.

Integración de Microsoft Office Project Server 2007 y SharePoint

Desde mi punto de vista, a la hora de integrar Microsoft Office Project 2007 y SharePoint, tenemos dos posibilidades:

• Nativa, es decir, Project Server encaja de manera natural en la plataforma SharePoint (WSS 3.0 & MOSS) como una pieza más.

En esta forma de integración, Project Server es un componente más que encaja en la plataforma SharePoint al estilo de Microsoft Office Infopath con Microsoft Office Forms Server. ¿Qué nos permite esta integración? Nos permite disponer de elementos propios de Project en un entorno SharePoint (lo veremos más adelante en la instalación), de manera que podremos pasar de un entorno a otro de forma natural:

• 
  
  Convertir una lista de tareas de SharePoint a un proyecto de tipo Proposals and Operations que se pueda gestionar a través del cliente web de Project Server.
  
  
• 
  
  Construir KPIs en Project Server y exponerlos en informes gestionados en SharePoint.
  
  
• 
  
  …

Vamos, que la integración como nos comentaba Gustavo es muy buena…pero, ¿Qué necesito para integrar Project Server y SharePoint? Pues básicamente una instalación al menos de WSS 3.0 y luego instalar Microsoft Office Project Server 2007. El mejor ejemplo de instalación de Project Server en una entorno de MOSS lo tenemos en este artículo de Gustavo. Más información sobre la integración de SharePoint y Microsoft Office Project Server 2007 a través de este ejemplo práctico.

• No nativa, en la que la integración con Microsoft Project se realiza a través de elementos visualizadores (web parts) que encajemos en SharePoint. Aquí también tenemos varias posibilidades:
  
  
  
  • Vía gadgets que al final puedan ser consumidos en SharePoint: http://blogs.msdn.com/project/archive/2008/07/09/office-online-gadgets.aspx
    
  • Mediante web part visores de Project: http://www.downloadthat.com/windows/catalog/Share_Point_Ms_Project_Web_Part
    
  • Desarrollando tu propia web part contra Project Server: http://msdn.microsoft.com/en-us/library/bb851478.aspx
    
  • Más productos de terceros (por cortesía de nuevo de Gustavo…gracias crack):
    
    
    
    • http://www.decisionedge.com/microsoft_project.html
      
    • http://www.projectviewercentral.com/news/solo_news.html
      
    • http://www.steelray.com/

Instalando Microsoft Project Server 2007 en un entorno de WSS 3.0

Para complementar el artículo sobre la instalación de Microsoft Project Server 2007 en un entorno de MOSS que hizo Gustavo, os voy a mostrar lo sencillo que es realizar dicha instalación en un entorno de WSS 3.0. Tras bajarme el SP1 de Microsoft Office Project Server 2007, los pasos de instalación son idénticos a los explicados por Gustavo para MOSS excepto en lo que a la configuraciones en la SharePoint 3.0 Central Administration se refiere (y una vez que hemos arrancado el servicio de Project Server siguiendo las indicaciones del artículo de Gusvao):

• Lo primero que tenemos que tener en cuenta es que dado que estamos en WSS 3.0, por defecto no tenemos definida una arquitectura de Shared Service Providers. Sin embargo, al instalar Microsoft Office Project Server aparece en la SharePoint 3.0 Central Administration una sección Shared Services Administration que nos indica que ahora si vamos a tener que crear un Shared Service para poder tener operativo el componente de Microsoft Office Project Server 2007 que acabamos de instalar.
  
• En la pantalla de creación del Shared Services simplemente creamos el mismo en una Web Application. En este punto me encontré con qué solo es posible crear el Shared Services que necesita Project Server en la Web Application del puerto 80. Entiendo que esto se deba a que el cliente web de Project Server ha de estar en dicho puerto.
  
• Una vez que hemos establecido todas las configuraciones necesarias del Shared Services, simplemente pulsamos OK y este se creará adecuadamente.

• Una vez que se ha creado el Shared Services, ya tendremos disponible la página de la administración del mismo. Lógicamente, como estamos en una instalación limpia de WSS 3.0, veremos que sólo aparece la sección relativa a Project Server (si hubiéramos instalado Microsoft Search Server Express, tendríamos también esta sección).
  
• Lo siguiente que tenemos que hacer es crear el acceso web al Project Server. Como vemos en la pantalla de creación, el proceso implicará que se creen una serie de BD’s necesarias para gestionar todos los elementos típicos de un entorno de trabajo con Microsoft Project.

• Una vez pulsado OK, se iniciará el proceso de creación de toda la infraestructura que necesita el cliente web de Project Server…como llevará varios minutos, nos podemos tomar tranquilamente una cerveza a a la espera de que acabe…el proceso acabará cuando se muestre el estado Provisioned.

• En este momento ya tendremos creadas todas las BD’s que necesita el cliente y sin más que abrir el vínculo al sitio web, veremos que ya está plenamente operativo. Al final este cliente es un sitio de SharePoint preparado para trabajar con elementos de Microsoft Project Server!

Y hasta aquí llega lo que por ahora os puedo contar sobre la integración de SharePoint y Microsoft Office Project Server 2007. Espero que el post os haya resultado de utilidad.

En el mundo del desarrollo del Software, hay una etapa muy importante en la que o se invierte poco tiempo o todo lo contrario. Muchas veces esto se debe a que desconocemos que existen una serie de herramientas en la red, muchas de ellas gratuitas, que nos ayudan en esta labor de diseño aumentando nuestra productividad. Con este post voy a iniciar una nueva categoría de recursos que vaya encontrando en la red y que nos faciliten las actividad de diseño, que en mi opinión es fundamental: Sobre la base de un buen diseño siempre se construirán mejores aplicaciones. Empecemos.

Diseño de aplicaciones web

En esta ocasión os voy a presentar un diseñador web (para crear prototipos) bastante original que ya hemos utilizado en el CIIN para hacer propuestas de diseño de soluciones SharePoint. Se trata de la herramienta Balsamiq Mockups de la empresa Balsamiq Studios y este es el diseñador:

Podéis probar el diseñador online antes de decidiros a comprarlo (la licencia son 79 $).

Diseño de aplicaciones SharePoint

En este caso, y gracias a mi colega Jagoba Valencia, os dejo una serie de Stencils de Visio para SharePoint que nos facilitan el diseño de sitios SharePoint con Microsoft Office Project 2003. Podéis descargaros los Stencils en este enlace.

Diseño de Arquitecturas

En este caso os presento el Enterprise Architecture Toolkit. Como se comenta en el blog de Mike Walker, se trata de un conjunto de herramientas pensadas para facilitar el trabajo de los arquitectos de software en general.

¿Y qué traerá el EAKT? Pues un resumen rápido extraído del blog de Mike Walker es el siguiente:

• Solution Accelerator for Enterprise Architecture
  
• Series of Add-Ins to Existing Products
  
• Set of Smart Architecture Templates
  
  
  
  • System Architecture Document
    
  • Architecture Decisions
    
  • Architecture Review Board
    
  • Architecture Viability Assessment
  
  
• Architecture Portal which includes:
  
  
  
  • Hosted Process and Collaboration Workflow
    
  • Knowledge Management System
    
  • Asset Management System
  
  
• Based on Industry Standards
  
  
  
  • Supports IEEE 1471
    
  • Supports TOGAF ADM
  
  
• Provides a Bill of Materials
  
  
  
  • Source Code
    
  • Whitepapers
    
  • Rich Media

Y hasta aquí el primer capítulo de la serie de post que sobre herramientas que aumenten la productividad en el diseño iremos publicando. Espero que el post os haya resultado interesante.

Para concluir la serie de post sobre los niveles arquitectónicos en la plataforma SharePoint (el resto de artículos los podéis leer en la parte I y la parte II de la serie), en este post vamos a ver el tercer nivel de arquitectura: la arquitectura de administración de la plataforma SharePoint.

Arquitectura de Administración de SharePoint

Administrar una granja de servidores SharePoint o una instalación tipo stand-alone implica añadir, editar o eliminar datos que se almacenan en las BD’s de configuración de SharePoint. Realizar estas operaciones implica usar las herramientas de administración que nos proporciona la plataforma en lugar de editar los datos directamente:

• Realizar un backup de nuestras web applications.
• Restaurar una web application a partir de un cierto backup
• Eliminar una web appliction o un site collection.
• …

Y estas operaciones las vamos a poder realizar con las dos herramientas por excelencia de la plataforma SharePoint:

• La SharePoint 3.0 Central Administration.
• La utilidad de línea de comandos stsadm.

Todas las settings de administración de la plataforma SharePoint se almacenan en una BD de configuración en Microsoft SQL Server (normalmente la BD se suele llama NombreServidor_Config):

Como hemos comentado, todas las settings de administración de SharePoint pueden visualizarse y modificarse mediante dos herramientas de administración: la SharePoint 3.0 Central Administration y la utilidad stsadm. Ambas nos permiten «tocar» la BD de configuración gracias a una arquitectura física de tres niveles:

• La UI, compuesta por páginas ASP.NET para la SharePoint 3.0 Central Administration y de la interfaz de comandos para stsadm.
• El modelo de objetos de SharePoint acceder a la BD y devolver, añadir, editar o eliminar datos de configuración.
• La propia BD.

El modelo de administración de SharePoint a su vez se basa en una arquitectura lógica de tres capas:

• La capa 1 comprende todas las características y funcionalidades de administración requeridas para la gestión de la granja de servidores. Por lo tanto, las tareas de administración a este nivel son realizadas por los administradores IT tradicionales puesto que incluye actividades como: gestión de los recursos de la granja (memoria, CPU, ancho de banda, …), monitorización de la salud de los servidores de la granja, aspectos y configuraciones de seguridad, etc. Por ejemplo, un administrador a este nivel sería el responsable de crear aplicaciones web, colecciones de sitios, gestionar las e-mail settings (para correo entrante y saliente) o gestionar la topología de l granja:

• La capa 2 comprende todas las características y funcionalidades de administración requeridas para la gestión de servicios compartidas a lo largo de la granja. Las tareas de administración a este nivel son realizadas por el administrador IT de negocio y pueden incluir actividades de gestión como establecer el nivel de servicio, configurar las búsquedas e indexaciones, o gestionar los informes de uso.

• La capa 3 que comprende todas las características y funcionalidad para gestionar sitios dentro de una granja. Las tareas de administración a este nivel son realizadas por un administrador de sitio y pueden incluir actividades como gestión de web parts, acceso a los sitios, gestión de contenidos, etc. Por ejemplo, estaríamos hablando de actividades como la creación de listas, configuración del acceso de los usuarios a un sitio y modificar la jerarquía de un sitio.

Finalmente comentaros que, aunque nos hemos centrado mucho en los ejemplos en las funcionalidades que nos da la administración central de SharePoint, estas funcionalidades también las tenemos con stsadm. Es más stsadm proporciona comandos adicionales que no tenemos en la SharePoint 3.0 Central Administration. Por ejemplo, con stsadm podemos cambiar la frecuencia de las alertas de SharePoint a otros valores que los que nos da por defecto la interfaz web:

Y hasta aquí llega lo que os quería contar sobre los niveles de arquitectónicos en la plataforma SharePoint. Espero que la serie os haya resultado interesante.

Hace un tiempo os comentaba como podemos leer User Profiles de MOSS. Como sabéis, cuando hablamos de los User Profiles de MOSS el primer punto a tener en cuenta es que MOSS a través de los Shared Services Providers (SSP), y en concreto el SSP referente a User Profiles, nos permite cargar la información de todos los usuarios de una organización de manera manual o automática definiendo un origen de importación que puede ser un DA, un recurso de DA, un directorio LDAP o bien un Business Data Catalog (BDC). Como os comentaba en aquel post, listar la información de los User Profiles es relativamente sencillo:

• A través de crear un sitio de búsqueda específico pare personas, de manera que una vez realizada la correspondiente indexación podremos buscar usuarios concretos en el listado importado.
• Atacando el servicio web UserProfile.asmx de nuestra máquina MOSS y mostrando el listado de usuarios en una web part o en una lista de MOSS.
• Atacando el modelo de objetos de MOSS y mostrando el listado de usuarios en una web part o en una lista.

Por lo tanto, listar los user profiles no tiene mayor complejidad…pero, ¿se pueden actualizar los user profiles? Esta pregunta viene a raíz de un comentario que me han hecho recientemente en el blog respecto a esta cuestión. El escenario sería el siguiente: Supongamos que la información de los user profiles de una organización está almacenada en dos orígenes distintos. Por un lado, la información clave se encuentra en el directorio activo de la organización, pero por otro tenemos que hay ciertas informaciones que se encuentra en otro origen distinto como puede ser una BD SQL Server. Entonces, ¿se puede actualizar el almacén de los user profiles con la información que está almacenada en la BD SQL Server? La respuesta es que sí, y para realizarlo tendremos dos alternativas principales:

• A través del modelo de objetos de SharePoint.
• Atacando el servicio wbe UserProfile.asmx.

En este post os voy a mostrar como se actualizaría los datos de los user profiles utilizando el modelo de objetos de SharePoint. Empecemos.

Actualizando los user profiles de MOSS

Para demostrar como actualizar los user profiles de MOSS, lo primero que vamos a hacer es crear una BD en SQL Server que contenga los datos a actualizar. Esta BD es realmente sencilla y contendrá únicamente una tabla MD_Usuarios que almacena dicha información:

Una vez que ya tenemos disponible la información a actualizar, vamos a crear un proyecto de aplicación de consola de C#. Necesitaremos añadir las siguientes referencias al proyecto:

Lo siguiente que haremos es definir en el código de la clase asociada a la aplicación de consola un método qe realice lo siguiente:

• Acceda a la BD SQL Server para obtener la información de los User Profiles que no está en el Profile Store.
• Acceda al contexto de nuestro servidor MOSS para poder instanciar el Profile Store.
• Compruebe si la propiedad a actualizar del Profile Store tiene un valor nulo o no. En caso de tener un valor nulo, se actualiza con el valor almacenado en la BD.

El código necesario para realizar lo anterior es el siguiente (os adjunto el código completo):

Sin más, lo que hace el código anterior es consultar la tabla MD_Usuarios de la BD y para cada fila devuelta va a buscar el correspondiente user profile en el objeto Profile Manager definido. Para cada user profile encontrado, se comprueba si la propiedad a actualizar tiene un valor nulo o no. En caso de tener un valor nulo, se actualiza con el valor de la propiedad almacenado en la BD. Sin más, aquí os dejo los consiguientes pantallazos en los que se puede apreciar que todo ha ido como la seda 😉

Espero que el post os haya parecido interesante.

Sin duda, la tecnología y el entorno que nos rodea son elementos que se dan claramente la mano, y como prueba tenemos el reciente lanzamiento de Eye on Earth. Se trata de un observatorio medioambiental lanzado conjuntamente por Microsoft y la Agencia Europea de Medio Ambiente (EEA):

La primera aplicación incluida en Eye on Earth es Water Wath, que nos permitirá elegir dentro del territorio europeo que zona es más idónea para darnos un baño a partir de comparar la limpieza de las aguas de 27 países. ¿Y cómo funciona esto? Pues Eye on Earth recupera datos de 21.000 puntos de monitorización, aprovechando las capacidades geoespaciales de SQL Server 2008 y luego los plasma en el mapa de Europa a través de Microsoft Virtual Earth. Tenéis más información sobre Eye on Earth en este enlace a la noticia aparecida en el diario El Mundo (Edición Dígital). Sin más, aquí os dejo el estado de a playa de los Peligros en Santander…muy apta para el baño 😉

Como os comentaba en el último post sobre SQL Server 2008, una de las novedades más interesantes que vendrá con SQL Server 2008 es Performance Studio. En este post veíamos como crear la base de datos (BD) data warehouse (DW) que necesita Performance Studio para poder monitorizar la velocidad y eficiencia de nuestras bases de datos, así como algunas de las operaciones que se realizan para llevar a cabo esta monitorización. En este segundo post, veremos a Performance Studio en acción y con toda su potencia ;). Empecemos.

Configurando las planificaciones de recogida de datos

Una vez que hemos creado el DW que necesita Performance Studio para recopilar toda la información necesaria para monitorizar nuestras BD’s, así como la recogida de datos, el siguiente paso es planificar cuando se va a realizar dicha recogida de datos, es decir, la periodicidad de la misma. Para definir esta periodicidad, nos servimos del SQL Agent:

• Lo primero que vamos a hacer es cambiar las planificaciones de recogidas de datos para que se realicen utilizando unos intervalos de tiempo más realistas (por ejemplo, cada 15 minutos). Para ello, nos vamos al Object Explorer y luego sobre la sección SQL Agent hacemos clic con el botón derecho del ratón y seleccionamos la opción New -> Schedule…
• En la pantalla New Job Schedule definimos una planificación con los siguientes parámetros de configuración:
  • Name: JobSchedule_Every_1min.
  • Occurs: Daily.
  • Occurs every: 1 minute(s).
  • Starting at: 0:00:00.
  • Ending at: 23:59:59.
• Añadimos la planificación que acabamos de crear a los siguientes jobs que tienen que ver con la recogida de datos que realiza Peformance Studio:
  • collection_set_1_noncached_collect_and_upload.
  • collection_set_3_collection.

  Para añadir estas planificaciones, hacemos clic con el botón derecho del ratón sobre cada job, a través del botón pick (en la sección Schedules) accedemos a la pantalla de planificaciones disponibles y seleccionamos la indicada con anterioridad.

• Repetimos el proceso para el resto de jobs disponibles (y relativos a la actividad de recogida de datos), aplicando una nueva planificación con periodicidad de 5 minutos.

Una vez que tenemos configurada la recogida de datos, el siguiente paso es «darle caña» al servidor con una serie de scripts que generen bastante actividad…aquí os dejo un pantallazo de como le he dado caña al servidor:

Analizando los datos recogidos

En esta sección vamos a analizar las distintas colecciones de datos que se han recogido, que información se mantiene, así como qué elementos proporciona Performance Studio en términos de resolución de problemas y verificación. Para analizar los datos recolectados vamos a seguir los siguientes pasos:

• Para ver el comportamiento que estamos teniendo de uso en disco, nos vamos a Management -> Data Collection -> Reports -> Management Data Warehouse -> Disk Usage Summary.
• Se mostrará el informe Disk Usage Collection Set en el qué:
  • Se están listando las distintas BD’s que tenemos en el servidor que estamos analizando. Para cada BD se muestra el tamaño de inicio, el tamaño actual, el crecimiento medio por día (para los ficheros de BD y log).
  • Si hacemos clic sobre el nombre de una BD, podremos acceder a toda la información recopilad en torno al uso de disco que está haciendo dicha BD en cuanto a ficheros de datos y log de transacciones:
    • Espacio usado por los datos.
    • Espacio no usado.
    • Espacio usado para indexación.
    • Etc.
  • Haciendo clic sobre una de las líneas de tendencias, podremos ver una vista más detallada del gap que existe entre el espacio usado, el espacio reservado y el espacio libre para una cierta BD.
• Si hacemos clic sobre el nombre de una BD (AdventureWorks), podremos acceder a los informes de detalle de uso de disco que hemos comentado.

• Si volvemos a la pantalla anterior, y hacemos clic sobre la línea de tendencia de la BD AdventureWorks veremos otro informe interesante en cuanto a como se ha comportado la BD respecto al uso de disco.
• Otro informe interesante es el de Disk Usage Collection Set. Para verlo, nos vamos a la sección Databases del Object Explorer, seleccionamos la BD AdeventureWorks, hacemos clic con el botón derecho del ratón y seleccionamos Reports -> Standard Reports -> Disk Usage by Top Tables.

• Otro informe intereante es el de Query Statistics History. Este informe está disponible a través de Management -> Data Collection -> Reports -> Management Data Warehouse -> Query Statistics History.
• Debajo del gráfico de consultas con una mayor duración, podemos consultar un listado de estas consultas con un mayor detalle de información relativa a las mismas.
• Hacemos clic en la primera query (es una de las más pesadas), de manera que podremos ver más detalles sobre su ejecución.

• Para visualizar la información relative a la actividad del servidor: Management -> Data Collection -> Reports -> Management Data Warehouse -> Server Activity History.
• El informe que se obtiene nos suministra información relativa a la utilización de la CPU, el uso de memoria, el uso de I/O de disco, uso de red, tiempos de espera en el servidor, etc.
• Hacemos clic en una de las barras del gráfico SQL Server Waits.

Y hasta aquí llega lo que os quería contar sobre Performance Studio. Para mi es una herramienta muy potente que va a ayudar y mucho a los DBAs.

Microsoft ha liberado recientemente tres nuevas guías para Microsoft BizTalk Server 2006 R2:

• La guía Microsoft BizTalk Server 2006 R2 Hyper-V.
• La guía Microsoft BizTalk Server Operations Guide.
• La guía Microsoft BizTalk Server Performance Optimizations Guide.

De estas tres guías, la de aparición más reciente es la Microsoft BizTalk Server 2006 R2 Hyper-V Guide. Se trata de una serie de 145 páginas disponibles en MSDN y TechNet, así como en formato DOCX, PDC y CHM (Podéis descargar la guía en estos formatos a través de este enlace).

La idea de esta nueva guía es proporcionar información relevante a los profesionales IT de cara a virtualizar de la forma más eficiente posible entornos de BizTalk Server mediante Windows Server 2008 Hyper-V. Para ello, se han establecido las siguientes secciones en la misma:

• Getting Started, que proprociona información conceptual sobre Hyper-V, así como una introducción a su arquitectura. 
• Deploying BizTalk Server on Hyper-V, dónde se describe los pasos seguidos para configurar un entorno de laboratorio virtualizado de BizTalk Server mediante Hyper-V con la idea de comparar el rendimiento de este entorno frente a uno no virtualizado. 
• Evaluating BizTalk Server Performance on Hyper-V, dónde se detallan consideraciones relevantes respecto a como medir el rendimiento de una solución de BizTalk Server corriendo en un entorno virtualizado con Hyper-V.
• Testing BizTalk Server Performance on Hyper-V, que proporciona resultados de rendimiento detallados para cuatro escenarios de test diferentes y los compara en términos de rendiemiento, tanto para un entorno virtualizado de BizTalk Server como para uno no virtualizado.

Ayer nos comentaba Percy Reyes que la versión definitiva de SQL Server 2008 está a punto de salir del horno con todas sus nuevas prestaciones y capacidades. Una de las grandes novedades que forman parte de SQL Server 2008 es Peformance Studio. Se trata de una nueva consola de administración que ayuda a monitorizar la velocidad y eficiencia de las bases de datos de una forma más efectiva. La clave de Peformance Studio está en que permite recolectar datos de rendimiento de múltiples bases de datos y almacenarlos en un data warehouse (DW) centralizado a partir del cuál construye una serie de informes de rendimiento. Además, con Performance Studio podremos:

• Comparar el rendimiento actual de nuestras BD’s con el pasado.
• Detectar y tratar problemas de rendimiento.
• Hacer el tracking de métricas de rendimiento personalizadas.
• …

Creación del Management Data Warehouse

Como hemos comentado, la clave de Performance Studio es una BD DW especial en la que se recolectan todos los datos de rendimientos de las BD’s a monitorizar. Luego el primer paso para ver a Performance Studio en acción consiste en crear dicha BD.  Por lo tanto, lo primero que vamos a hacer es crear una base de datos (BD) de gestión, denominada ManagementDW, que nos permita configurar los tipos de colecciones de datos que vamos a recolectar con Performance Studio, así como las estrategias de recogida de esta información (de forma continua o bien de acuerdo a una cierta planificación). Esta BD ManagementDW es una BD es como cualquier otra BD relacional que tengamos en nuestros sistemas, por lo que aplican las mismas reglas de administración que tengamos definidas para el resto de las bases de datos de nuestra organización.

Antes de instalar la BD ManagementDW, vamos a analizar la estructura de recolección de datos de Performance Studio:

La idea es que los Targets son instancias de SQL Server y para cada instancia tenemos definidos unos contadores que pueden ser de dos tipos: disk o bien query statistics (por lo tanto, nos permitirán recoger datos sobre el uso de disco que se está haciendo, así como estadísticas de las ejecuciones de consultas que se produzcan). La recolección de datos se realiza de acuerdo a una cierta planificación, usando el agente SQL y SQL Server Integration Services (SSIS), y los jobs y planificaciones se almacenan en la BD msdb (como cualquier otro job o planificación de SQL Server). El papel de este data warehouse de gestión es almacenar los datos, valores agregados y una histórico de información (configurable) que permita realizar una análisis de tendencias en el funcionamiento de la BD.

Para crear la BD ManagementDW, abrimos SQL Server Management Studio y seguimos los siguientes pasos:

• Desplegamos la sección Management. A continuación, seleccionamos la sección Data Collection, hacemos clic con el botón derecho del ratón y seleccionamos la opción Configure Management Data Warehouse.
• En la ventana que se abre, simplemente hacemos clic en el botón Next.
• En la siguiente ventana dejamos marcada la opción Create or upgrade a management data warehouse.

• Para configurar una data warehouse de gestión para Performance Studio, necesitamos una BD de SQL Server en la que almacenar los contadores de recolección de datos (idealmente, esta BD debería estar en un servidor diferente al servidor de SQL que vamos a monitorizar).
• En primer lugar, especificamos el nombre de la base de datos a través del botón New. Especificamos los siguientes parámetros de creación de la BD:
  • Nombre: ManagementDW.
• Pulsamos el botón Next.

• En la siguiente pantalla, Map Logins and Users, configuramos como se va a usar la BD de gestión para Performance Studio. Marcamos la opción NT AUTORITHYSYSTEM como Users mapped to this login y para esta opción marcamos los membership siguientes:
  • mdw_admin.
  • mdw_reader.
  • mdw_writer.
• Pulsamos Next y en la siguiente pantalla verificamos que la configuración se corresponde con la que hemos realizado. Pulsamos Finish.
• A continuación veremos que se pone en marcha el proceso de setup del data warehouse de gestión:
  • Creación de la BD ManagementDW.
  • Creación de los logins de acuerdo a los roles definidos.

• Una vez que el proceso ha finalizado, comprobamos a través del Object Explorer de SQL Server Management Studio que la BD ManagementDW se ha creado sin problemas y con la configuración especificada.

Configuración de la recogida de datos

Una vez que hemos creado la BD ManagementDW, el siguiente paso es configurar como se va a realizar la recogida de datos que va a utilizar Performance Studio para monitorizar la salud y rendimiento de nuestras BD’s:

• Seleccionamos de nuevo la sección Data Collection, hacemos clic con el botón derecho del ratón y seleccionamos la opción Configure Management Data Warehouse.
• En la ventana que se abre, simplemente hacemos clic en el botón Next.
• En la siguiente ventana dejamos marcamos ahora la opción Set up data collection.
• Especificamos el nombre del servidor a través del botón … . En el combo de BD’s seleccionamos BD creada con anterioridad.
• Especificamos el directorio de caché en el que almacenar datos temporales antes de cargarlos en el data warehouse.

• En la siguiente pantalla simplemente se muestra un resumen de las configuraciones realizadas y que se van a realizar. Pulsamos Finish.
• Si todo ha ido bien, en la siguiente pantalla veremos que:
  • Se inicia la recolección de datos del sistema.
  • Se habilita la recolección de datos.

Una vez que hemos habilitado y configurado la recogida de datos, el siguiente paso consiste en definir las planificaciones a utilizar en las recogidas de datos:

• En el Object Explorer de SQL Server nos vamos a Management -> Data Collection -> System Data Collection Sets -> Disk Usage. Hacemos clic con el botón derecho del ratón y seleccionamos la opción Properties.
• En la pantalla que se abre veremos las propiedades completas para las estadísticas de uso de disco. En la sección General podremos observar información diversa de cómo se puede configurar la recolección de datos para su posterior análisis en Perfomance Studio:
  • Si los datos se tienen que tomar o no de caché. En el caso de que no se tomen de caché, podemos especificar la opción de que se recojan bajo demanda o de acuerdo a una cierta planificación.
  • Los elementos de recolección definidos y la definición de los mismos.
• Si pulsamos el botón Pick podremos visualizar las planificaciones disponibles para realizar las recolecciones de datos:

• Si seleccionamos la opción Disk Usage – Data Files dentro de la sección Collection Items, podremos observar que la recolección de datos relativos a este parámetro se realizan en base a la siguiente consulta (que aparece en la sección Input parameteres):

• Si ejecutamos esta consulta contra la BD master en un editor de consultas, obtendremos el siguiente resultado:

Como vemos, se muestra una única fila de resultados que corresponde a una única BD. Sin embargo, esta query debería ser ejecutada para todas las BD’s. Este trabajo es realizado como parta de los jobs del agente de SQL Server que permiten ejecutar toda la recogida y subida de colecciones de datos.

• Si seleccionamos la opción Disk Usage – Log Files dentro de la sección Collection Items, podremos observar que la recolección de datos relativos a este parámetro se realizan en base a la siguiente consulta (que aparece en la sección Input parameteres):

• Si ejecutamos esta consulta contra la BD master en un editor de consultas, obtendremos el siguiente resultado:

Otra posibilidad que tenemos para consultar el uso de disco y logs de una BD es realizando un par de consultas SELECT como las siguientes:

El resultado de ejecutar ambas consultas es el siguiente:

Y hasta aquí llega el primer post sobre Performance Studio. En la siguiente capítulo os comentaré como explotar los datos recogidos en la BD ManagementDW mediante Performance Studio en situaciones de mucha actividad en la BD.

Hace unos meses hablábamos de un término muy de moda: Software as a Services (SaaS), y de la estrategia y redefinición por parte de Microsoft a esta filosofía en la que el Software resida en la red (la nube) y se paga por el uso que se hace de él: Software + Services (S+S). Pues bien, el pasado 24 de julio en la reunión anula Financial Analyst Meeting 2008 Steve Ballmer dio algunas pinceladas más de por dónde va a ir Microsoft con su S+S y que productos incluirá de momento dentro de los servicios ofrecidos por el propio Microsoft y su red de partners:

Básicamente, la idea es que productos clásicos de servidor van a tener su equivalente en la red de manera que tendremos versiones en modalidad S+S para Exchange, SharePoint, Dynamics, SQL Server, Active Directory y el propio sistema operativo. Podéis acceder a un resumen de lo que Steve Ballmer dijo en el meeting en este enlace.

Siguiendo con los niveles arquitectónicos dentro de la plataforma SharePoint, es importante tener claro que antes de implementar todas las características lógicas de una solución WSS 3.0 o MOSS, es necesario comprender como todas las unidades lógicas que constituyen la arquitectura lógica de SharePoint se mapean con componentes físicos de la arquitectura. Estamos hablando por tanto del nivel de arquitectura física de SharePoint…a muy groso modo y alto nivel, podríamos representar la arquitectura física de MOSS del siguiente modo:

Componentes de la arquitectura física de SharePoint

En general, la arquitectura física de SharePoint se compone de los siguientes elementos:

• Servidor de base de datos (Database Server), que almacena y gestiona los datos de configuración de nuestra instalación de SharePoint (BD de configuración), los datos y metadatos de los sitios (BD’s de contenidos), y las BD’s de indexación. Todos los miembros de una granja de SharePoint deben usar el mismo sevidor de BD puesto que se encarga de almacenar y gestionar la BD de configuración que controla todas las settings de la granja. Lógicamente, cuando hablamos de BD’s en plataforma Microsoft en general, estamos hablando de SQL Server…de hecho, SharePoint soporta las siguientes versiones de SQL Server:
• SQL Server 2000 SP4.
• SQL Server 2005 Standard o Professional Edition.
• SQL Server Express 2005.
• MSDE.

Al hilo del servidor de BD, una pregunta típica que nos suelen hacer cuando hablamos de este componente es que versión de SQL Server utilizar. La respuesta clara es que SQL Server 2005, y dentro de las versiones de SQL Server, la recomendación es utilizar como mínimo la versión workgroup (aquí tenéis una comparativa entre las distintas versiones de SQL Server 2005) y evitar poner instalaciones de WSS 3.0 o MOSS en producción por las limitaciones que presenta y el hecho de que esté pensado más para aspectos de desarrollo que para soluciones en producción. A modo de ejemplo, recojo sólo la comparativa en términos de escalabilidad y rendimiento de las versiones de SQL Server 2005 que me llevan a no recomendar SQL Server Express para entornos de producción:

• Servidor de aplicaciones (Application Server), que se encarga de proporcionar todos los servicios de aplicación que se necesiten. Por ejemplo, podemos tener dentro de la granja un servidor de aplicaciones encargado de gestionar las búsquedas e indexación (WSS 3.0 o MOSS) y otro para la importación de los user profiles y la sincronización (MOSS).
• Servidor frontal web (Web front-end server), que se encarga de gestionar todas las peticiones que llegan a las soluciones WSS 3.0 o MOSS que tengamos desplegadas. Se compone de una serie de directorios virtuales que proporciona features de aplicación como gestión de páginas, plantillas, temas y componentes registrados como son los ensamblados de Web Part.

Y hasta aquí el segundo post de la serie sobre conceptos y niveles de arquitectura en plataforma SharePoint. En breve el tercer y último capítulo. Espero que el post os haya resultado interesante.