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

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

    Extendiendo la SharePoint 3.0 Central Administration: SharePoint Administration Toolkit!

    Cuando se habla de administrar la plataforma SharePoint, tenemos varias posibilidades:

    • La más intuitiva, a través de la SharePoint 3.0 Central Administration desde la que podremos configurar y modificar elementos claves de nuestra instalación de SharePoint (WSS 3.0 & MOSS).
    • A través de la interfaz de comandos y utilizando la herramienta stsadm.
    • Extender las dos opciones anteriores.
    • Aprovechar la riqueza del modelo de objetos de administración de SharePoint para construir nuestras propias aplicaciones de administración de SharePoint.

    En esta ocasión vamos a ver como podemos extender la SharePoint 3.0 Central Administration y la utilidad stsadm a partir del SharePoint Administration Toolkit. Se trata de un paquete de funcionalidades a nivel de administración que apareció durante el mes de abril de este año y que está pensado para ayudar a administrar y gestionar WSS 3.0 & MOSS. Empecemos.

    La instalación

    El proceso de instalación de este Toolkit es realmente sencillo puesto que se compone únicamente de dos pasos:

    • La típica aceptación de las condiciones bajos las que se licencia.
    • Una pantalla de línea de comandos en la que podemos ver como se van instalando los archivos de aplicación que componen el toolkit.

    Si revisamos el directorio de instalación de SharePoint (WSS 3.0 o MOSS), podremos comprobar que aparece una nueva feature denominada BatchSiteManagerLinks y que es la que añade la instalación del Toolkit.

    image image image

    Tras instalar el Toolkit, tendremos que tanto la SharePoint 3.0 Central Administration como la utilidad stsadm han sido extendidas con nuevas funcionalidades:

    • Desde la administración central de SharePoint y en la sección Applications aparece una nueva sección de funcionalidad denominada Batch Site Manager podremos realizar operaciones a gran escala en colecciones de sitios como mover, bloquear y eliminar colecciones de sitios.
    • En el caso de la utilidad stsadm dispondremos de una nueva opción que facilita la actualización de los correos de alertas de SharePoint ante cambios en el nombre de la url: updatealert.
    image image

    Probando las opciones de la sección Batch Site Manager

    Lo siguiente que vamos a hacer es probar la funcionalidad de realizar operaciones a gran escala con colecciones de sitio. Por ejemplo, vamos a ver como podemos mover colecciones de sitios. Esta operación nos permitirá mover colecciones de sitios entre bases de datos asociadas a la misma web application (esta limitación es importante). Los pasos para definir la operación Move son los siguientes:

    • Lo primero que tendremos que hacer en la página que se abre es especificar la web application que contiene la colección o colecciones de sitios sobre las que operaremos.
    • Para poder visualizar las colecciones de sitios de la web application necesitamos iniciar un job encargado de agregarlos.
    • Para comprobar el estado de ejecución del job, pulsamos sobre Refresh progress. En mi caso, se habrá agregado una única colección de sitios. Para cada colección de sitios vemos que se visualiza cuál es su BD de contenidos, el espacio que ocupa, el número de Hits, la última modificación y el Lock Status.
    • Para probar la opción movimiento de colecciones de sitios, simplemente seleccionamos el sitio o colección de sitios a mover y pulsamos sobre el enlace de acción Move.
    image image image
    • A continuación especificaremos las configuraciones necesarias para realizar la operación de movimiento de la colección de sitios:
      • El nombre y descripción del job encargado de realizar el movimiento (se trata de un Timer Job de SharePoint).
      • El nombre de la BD de contenidos a la que vamos a mover la colección de sitios.
      • El servidor de SharePoint (primero que esté libre) al que vamos a mover la colección de sitios.
      • El path físico (puede ser una carpeta compartida) dónde se guardarán de manera temporal los archivos generados al realizar la operación de movimiento (en mi caso he especificado una carpeta local de la máquina virtual de pruebas).
      • La planificación de ejecución del job: en el momento actual vs en un instante de tiempo programado.
      • Las acciones a realizar en el caso de producirse éxito o fallo en el job (envío de una notificación por e-mail).
    • Tras realizar todas esta configuraciones simplemente pulsamos OK para que se realice la operación Move, y se hará efectivo el movimiento de la colección de sitios de una BD de la web application a otra BD asociada.

    image

    La configuración de las operaciones Delete y Lock son similares a la operación Move:

    • En el caso de una operación de tipo Lock, tendremos que especificar como es este anclaje del site o site collections seleccionados: Not Locked, Adding content prevented, Read-only, No access.
    • En el caso de una operación Delete, podremos especificar si vamos a realizar un backup de lo site o site collections y la ubicación física del backup.
    image image

    Finalmente comentaros que podéis obtener más información acerca de las funcionalidades del SharePoint Administration Toolkit en este whitepaper sobre esta extensión de la SharePoint 3.0 Central Administration y en esta entrada del blog de Chandima Kulathilake. Espero que el post os haya resultado interesante.