MOSS: Cómo actualizar los User Profiles!

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:

MOSS_User_Profiles_Post_4

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:

using System.Web;

using Microsoft.Office.Server;

using Microsoft.Office.Server.UserProfiles;

using Microsoft.SharePoint;

using System.Data;

using System.Data.SqlClient;

MOSS_User_Profiles_Post_1  MOSS_User_Profiles_Post_3  

image

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):

using System;

using System.Collections.Generic;

using System.Text; 

//Espacios de nombres necesarios!

using System.Web;

using Microsoft.Office.Server;

using Microsoft.Office.Server.UserProfiles;

using Microsoft.SharePoint;

using System.Data;

using System.Data.SqlClient; 

namespace CIIN_MOSSUserProfiles_Service

{

    class Program

    {

        //Constants needed

        const string SPS_SITIO = «http://litwaredemo»;

        const string PROFILE_PROPERTY_DEPARTMENT = «Department»;

        const string sCadenaConexion =

            «Data Source=localhost;Initial Catalog=BD_Usuarios;Integrated Security=True»;

        const string sQuery = «Select * from MD_Usuarios»;

        //***************************************************

        //Campos Ususario BD

        //***************************************************

        const string CAMPO1_USER = «sAccountName»;

        const string CAMPO2_USER = «sDepartment»; 

        static void Main(string[] args)

        {                   

            UpdateUserProfile();

            Console.ReadLine();

        } 

        public static void UpdateUserProfile()

        {

            //********************************************************************

            //Data connection!

            //********************************************************************

            SqlDataAdapter sqldaAdaptador =

                new SqlDataAdapter(sQuery, sCadenaConexion);

            DataTable dtUsuarios = new DataTable();

            sqldaAdaptador.Fill(dtUsuarios); 

            using (SPSite spsSitio=new SPSite(SPS_SITIO))

            {

                //********************************************************************

                //Server Context!

                //********************************************************************

                ServerContext scContexto =

                    ServerContext.GetContext(spsSitio);

                UserProfileManager upmProfiles =

                    new UserProfileManager(scContexto);

                UserProfile upProfile;  

                foreach (DataRow drFila in dtUsuarios.Rows)

                {

                    upProfile =

                        upmProfiles.GetUserProfile(drFila[CAMPO1_USER].ToString());                   

                    if (upProfile[PROFILE_PROPERTY_DEPARTMENT].Value == null)

                    {

                        upProfile[PROFILE_PROPERTY_DEPARTMENT].Value = drFila[CAMPO2_USER];

                        upProfile.Commit();

                        Console.WriteLine(«Se ha actualizado la propiedad {0} del usuario {1}»,

                            PROFILE_PROPERTY_DEPARTMENT, drFila[CAMPO1_USER].ToString());

                    }

                    else

                    {

                        Console.WriteLine(«No se ha actualizado la propiedad {0} del usuario {1}»,

                            PROFILE_PROPERTY_DEPARTMENT, drFila[CAMPO1_USER].ToString());

                    }

                }             

            }

        }

    }

}

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 😉

MOSS_User_Profiles_Post_7 MOSS_User_Profiles_Post_5  

MOSS_User_Profiles_Post_6

Espero que el post os haya parecido interesante.

Eye on Earth: Observatorio online medioambiental!

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):

image

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 😉

image

SQL Server 2008 RC0: Performance Studio (II)!

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.

image image  

image

  • 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:

image

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.
image image  

image

  • 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.
image image  

image

  • 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.
image image  

image

  • 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.
image image  

image

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.

Nuevas guías para Microsoft BizTalk Server 2006 R2!

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

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 proporciona 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 rendimiento, tanto para un entorno virtualizado de BizTalk Server como para uno no virtualizado.

SQL Server 2008 RC0: Performance Studio (I)!

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:

image

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.
image image  

image

  • 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.
image image  

image

  • 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 AUTORITHY\SYSTEM 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.
image image  

image

  • 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.

image

 

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.
image  image

image

  • 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.
image image

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:
image image  

image

  • 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):

DECLARE @dbsize bigint

DECLARE @logsize bigint

DECLARE @ftsize bigint

DECLARE @reservedpages bigint

DECLARE @pages bigint

DECLARE @usedpages bigint 

SELECT @dbsize = SUM(convert(bigint,case when type = 0 then size else 0 end))

      ,@logsize = SUM(convert(bigint,case when type = 1 then size else 0 end))

      ,@ftsize = SUM(convert(bigint,case when type = 4 then size else 0 end))

FROM sys.database_files 

SELECT @reservedpages = SUM(a.total_pages)

       ,@usedpages = SUM(a.used_pages)

       ,@pages = SUM(CASE

                        WHEN it.internal_type IN (202,204) THEN 0

                        WHEN a.type != 1 THEN a.used_pages

                        WHEN p.index_id < 2 THEN a.data_pages

                        ELSE 0

                     END)

FROM sys.partitions p 

JOIN sys.allocation_units a ON p.partition_id = a.container_id

LEFT JOIN sys.internal_tables it ON p.object_id = it.object_id

SELECT

        @dbsize as ‘dbsize’,

        @logsize as ‘logsize’,

        @ftsize as ‘ftsize’,

        @reservedpages as ‘reservedpages’,

        @usedpages as ‘usedpages’,

        @pages as ‘pages’ 

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

image

    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):

— SET NOCOUNT ON added to prevent extra result sets from

— interfering with SELECT statements.

SET NOCOUNT ON;

DECLARE @tran_log_space_usage table(

        database_name sysname

,       log_size_mb float

,       log_space_used float

,       status int

);

INSERT INTO @tran_log_space_usage

EXEC(‘DBCC SQLPERF (LOGSPACE) WITH NO_INFOMSGS’); 

SELECT

    database_name,

    log_size_mb,

    log_space_used,

    status   

FROM @tran_log_space_usage 

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

image

    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:

select * from ManagementDW.snapshots.disk_usage 

select * from ManagementDW.snapshots.log_usage

    El resultado de ejecutar ambas consultas es el siguiente:

image image

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.

S+S: Microsoft se va a la nube!

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.

WSS 3.0 & MOSS: Niveles arquitectónicos (II)!

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:

image

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.

image

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:

Escalabilidad y rendimiento

 

Característica

Express

Workgroup

Standard

Enterprise

Comentarios

 

Número de CPU

1

2

4

Ilimitado

Es compatible con procesadores multinúcleo

 

RAM

1 GB

3 GB

OS Max

OS Max

Memoria limitada a un máximo compatible con el sistema operativo

Admite 64 bits

Windows on Windows (WOW)

WOW

clip_image001

clip_image001

clip_image002

Tamaño de la base de datos

4 GB

Ilimitado

Ilimitado

Ilimitado

clip_image002

Partición

clip_image002

clip_image002

clip_image002

clip_image001

Compatibilidad para bases de datos a gran escala

Operaciones de índice paralelo

clip_image002

clip_image002

clip_image002

clip_image003

Procesamiento paralelo de operaciones de indexación

Vistas indizadas

clip_image002

clip_image002

clip_image002

clip_image001

Se admite la creación de vista indizada en todas las ediciones. La correspondencia de vista indizada por el procesador de consulta sólo se admite en la Enterprise Edition.

  • 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.

WSS 3.0 & MOSS: Niveles arquitectónicos (I)!

Cuando estamos pensando en la plataforma SharePoint como alternativa más adecuada para resolver una cierta problemática de negocio, es necesario tener muy clara cuál es la arquitectura de la solución de cara a lograr un modelado de la misma lo mejor posible. En este sentido, cuando hablamos de arquitectura en plataforma SharePoint, tenemos que hablar de varios niveles de arquitectura:

  • Arquitectura lógica.
  • Arquitectura física.
  • Arquitectura de administración.

Asociado a cada nivel existen una serie de conceptos asociados que es necesario comprender a la perfección de cara a garantizar el mayor éxito posible en la implementación de nuestras soluciones. En este primer post hablaremos de la arquitectura lógica de la plataforma SharePoint.

La arquitectura lógica de la plataforma SharePoint

Las soluciones basadas en SharePoint se construyen sobre una jerarquía de componentes lógicos, cada uno de los cuales proporcionan unas funcionalidades específicas.

image

Por lo tanto, SharePoint en general se compone de las siguientes unidades lógicas:

  • Server Farm (Granja de Servidores), aunque una granja es un «lugar dónde se crían animales» (cuántas veces se lo habré oído contar a mi compañero Pablo Sousa), en el caso de la plataforma SharePoint se define como la unidad lógica más alta de la jerarquía y que se compone por una serie de servidores web y de aplicaciones que se agrupan de manera lógica y que comparte una base de datos (BD) de configuración común.
  • Web Application (Aplicación Web), elemento que proporciona funcionalidad de servidor web y que se corresponde con un sitio web de Internet Information Services (IIS).

image

  • Site Collection (Colección de Sitios), elemento que define las características y el contexto para agrupar una serie de sitios y subsitios (os recuerdo que en teoría en SharePoint tenemos jerarquías ilimitadas…en la práctica siempre hay un límite). Un site collection es similar al clásico directorio virtual top-level de IIS, si bien no existe un mapping en el IIS entre directorios virtuales y site collections.

image

  • Site (Sitio), elemento que proporciona un punto de entrada a una funcionalidad especifica o a un conjunto de funcionalidades. Un site es similar a una subcarpeta en un directorio virtual top-level clásico de IIS.
  • Feature (Característica), elemento que proporciona funcionalidad y datos como parte de una cierta solución. Una feature puede contener datos, metadatos y funcionalidad. Un apunte importante respecto a las features es que aunque se suelen usar típicamente dentro de sites y site collections, pueden tener diferentes scopes (ámbitos). De manera que dependiendo del scope, las features se pueden activar a nivel de sitio, site collection, web application o server farm.

image

Y hasta aquí el primer post sobre conceptos de arquitectura en plataforma SharePoint. Espero que el post os haya resultado interesante.

Disponible la primera Preview de ASP.NET AJAX 4.0!

Ya está disponible la primera preview de las nuevas características de AJAX en ASP.NET o o que es lo mismo AJAX 4.0. La preview aparece dentro de las releases de la sección ASP.NET de Codeplex. En esta primera preview se incluyen las siguientes características:

  • Client-side template rendering.
  • Declarative instantiation of behaviors and controls.
  • DataView control.
  • Markup extensions.
  • Bindings.

    Podéis acceder al roadmap de ASP.NET AJAX en este otro enlace.

  • S+S: CTP versión R12 de BizTalk Services!

    Microsoft acaba de liberar una nueva CTP de BizTalk Services, o lo que es lo mismo la plataforma en la nube para SOA (Service Oriented Architecture) y BPM (Business Process Management). Además de esta nueva CTP, y ya van 12, se ha liberado una nueva versión para el SDK de BizTalk Services.

    Como sabréis, BizTalk Services permite a las organizaciones modelar escenarios de Internet Service Bus (ISB), es decir, modelar sus procesos de acuerdo a la filosofía SOA más allá de los límites de la organización y en la nube (o lo que es lo mismo, a través de Internet). En definitiva, BizTalk Services permite definir mecanismos estándar de conexión de aplicaciones distribuidas utilizando la red como medio.

    image

    Por otra parte, BizTalk Services se enmarca dentro de la estrategia Software + Services (S+S) de Microsoft que consiste en ofrecer una serie de servicios hosteados en la nube (Internet) al más puro estilo Amazon o Salesforce.com. Además, no hay que olvidar que BizTalk Services se enmarca también dentro de la estrategia de Microsoft de proporcinar los elementos necesarios para simplificar SOA y enlazar con la estrategia S+S, o lo que es lo mismo: OSLO

    En cuanto a las novedades de esta nueva CTP de BizTalk Services, sin duda destaca la capacidad de definir servicios de orquestación en la red habilitados por Windows Workflow Foundation (WF). Tal y como se comenta en esta noticia, la clave de esta capacidad está en un runtime de WF hosteado en la red y el uso de servicios web de mensajería. Además de esta novedad, la release R12 de BizTalk Services incluye:

    • Extensión del servicio de identidad, de manera que se permite que los usuarios puedan dar cierto control a los socios comerciales en los procesos de negocios modelados.
    • Comunicación Rest-Based como alternativa para el intercambio de información de las identidades involucradas.
    • Soporte multiprotocolo en el intercambio de información. Por ejemplo, se ha añadido soporte a TCP (hasta ahora solo se soportaba HTTP). También se han añadido nuevas estrategias de intercambio de mensajes, como mensajería FIFO.
    • La información se puede enviar en modo broadcast a múltiples destinos sin necesidad de autorización.

    Podéis ver el resumen completo de las novedades de esta CTP en este enlace. Os podéis bajar la nueva versión del SDK en este otro enlace.