Liberado el SP2 de Windows Vista y Windows Server 2008!

Aunque la RC de Windows 7 está a la vuelta de la esquina, Microsoft acaba de liberar el SP2 de Windows Vista (que por cierto yo tengo instalado en su versión RTW desde hace un par de semanas, y francamente, el portátil va como un tiro) y Windows Server 2008. De momento, este SP2 sólo estará disponible a través de TechNet y y MSDN e incluirá todas las actualizaciones que ha ido realizando Microsoft desde el SP1 de Windows Vista y Windows Server 2008…os reproduzco algunas de las novedades que vienen con el SP2 de Windows Vista tal y como se citan en el post con la noticia:

  • Windows Search 4.0 for faster and improved relevancy in searches
  • Bluetooth 2.1 Feature Pack supporting the most recent specification for Bluetooth Technology
  • Ability to record data on to Blu-Ray media natively in Windows Vista
  • Adds Windows Connect Now (WCN) to simplify Wi-Fi Configuration
  • Windows Vista SP2 enables the exFAT file system to support UTC timestamps, which allows correct file synchronization across time zones.

Finalmente, comentar que el SP2 de Windows Vista estará disponible próximamente (no más allá de junio) de forma general.

Windows Vista Team Blog

BizTalk Server 2009: Disponible de manera global!

Hace unos días os comentaba que ya teníamos disponible a través de MSDN la nueva versión de BizTalk Server, y hoy mismo acaba de liberar de forma general y global la nueva versión de BizTalk: BizTalk Server 2009. Os dejo una serie de enlaces de interés en torno a las novedades en la nueva versión y la noticia oficial de liberación:

Home

WSS 3.0 & MOSS: Preguntas & Respuestas (I)!

Sin duda, una de las ventajas de realizar formación tecnológica especializada es que aprenden tanto los alumnos como el profesor. Esto es algo que siempre me pasa cuando realizo formaciones de plataforma SharePoint, cada organización tiene una problemática diferente y también problemas diferentes por lo que resulta complicado tener respuesta para todo…pero es precisamente aquí donde aparece el gran reto: responder a las preguntas planteadas. Por eso, la idea de este post y siguientes es recopilar las preguntas y respuestas que me han surgido y me surgirán en torno a plataforma SharePoint. Empecemos.

Infraestructura e IT en SharePoint

Cuestiones de configuración típicas desde la administración central de SharePoint

Herramientas y Utilidades

Cuestiones sobre Content Deployment

Cuestiones sobre búsquedas en plataforma SharePoint

  • ¿Por qué tenemos 2 BD’s de búsquedas en MOSS? ¿Para qué sirve cada una? Las dos BD’s son necesarias para que las búsquedas de MOSS funcionen a la perfección:
    • Por un lado, la BD del servicio de búsquedas de WSS 3.0 registra todas las veces que se utiliza la ayuda. Por lo tanto, es "casi" testimonial, pero necesaria y no penaliza el rendimiento.
    • Por otro lado, la BD "buena" de MOSS es la del Shared Service Provider (SSP).

Cuestiones sobre permisos de las cuentas de servicio en SharePoint

  • ¿Qué privilegios tiene que tener la cuenta de búsqueda de MOSS? La respuesta es que depende (esta respuesta se la debo a mi compañero Pablo Sousa):
    • Si nos referimos a la la cuenta que se encarga de indexar tiene que tener por lo menos acceso de lectura a los orígenes de contenido que se quieran indexar, porque si no, no puede leer la información.

    • Si nos referimos al servicio de búsqueda , por defecto el usuario no tiene que dar ningún permiso, estas cuentas son simples cuentas de usuario sin ningún permiso, ya se encarga SharePoint de concedérselos. Aquí os dejamos una tabla donde viene especificado todas las cuentas y permisos que necesitan: http://claytonj.wordpress.com/2007/04/23/moss-2007-setup-accounts/

  • ¿Cuáles son las buenas prácticas en cuanto a cuentas de usuario para SharePoint? Es recomendable utilizar/crear un mínimo tres cuentas: Application Pool, Servicios y Búsquedas

Migración desde versiones previas de SharePoint a SharePoint 2007

Infopath & Infopath Form Services

Y hasta aquí llega este primer post sobre preguntas y respuestas en plataforma SharePoint. Espero que os haya resultado interesante.

Una primera mirada a WF 4.0 tras el PDC 2008!

Como muchos sabéis, con .NET Framework 4.0 vamos a tener una nueva versión de Windows Workflow Foundation (WF 4.0) que rompe radicalmente en lo que a arquitectura se refiere (el stack se ha re-hecho) y también en cuanto a como se diseñan los workflows…y como muestra os dejo una captura de pantalla del posible aspecto de este diseñador (digo posible, porque de momento solo lo he podido ver en videos):

image

Desde el PDC 2008 no había vuelto a ver ningún video sobre WF 4.0, pero por suerte tenemos un vídeo de WF 4.0 sobre una versión de Visual Studio 2010 más actualizada que la que yo tengo en la que Ron Jacobs nos hace una primera demo sobre WF 4.0.

Managed Extensibility Framework: Un ejemplo práctico (I)!

Hace ya un tiempo os hablé de una nueva librería .NET denominada Managed Extensibility Framework (MEF). MEF forma parte de la nueva versión del CLR (4.0) que vendrá con .NET Framework 4.0 y Visual Studio 2010, y habilita escenarios de re-utilización de aplicaciones y componentes, haciendo posible que aplicaciones .NET compiladas de forma estática puedan ser compuestas de forma dinámica. Como os comentaba, MEF está pensado para escenarios en los que se está implementando aplicaciones y frameworks extensibles o bien extensiones para aplicaciones.

MEF_Diagram 

El caso es que, tal y como os comentaba en este post sobre ADO.NET Data Services, últimamente estoy cacharreando bastante con las novedades de .NET Framework 4.0 y de Visual Studio 2010…y por supuesto, he podido ver a MEF en acción. La idea de este post es mostraros un primer ejemplo sencillo de como podemos extender aplicaciones mediante MEF.

MEF al detalle

Como hemos dicho, MEF permite habilitar escenarios en el que se pueden extender aplicaciones de forma dinámica…pero, ¿cómo es posible esto? Pues añadiendo “puntos de enganche” (hooks) en las aplicaciones para extenderlas con nuevos componentes (propios o de terceros):

  • Habilitando la declaración y consumo de puntos de extensibilidad de aplicaciones.
  • En la práctica, se trata de un simple Import/Export:
    • Añadimos puntos de importación dónde queramos extender la aplicación.
    • Añadimos puntos de exportación en las extensiones.

Por supuesto, otra gran ventaja de MEF es que permite extender las aplicaciones en tiempo de ejecución (las extensiones se pueden crear de forma dinámica sin necesidad de conocer la aplicación en la que se van a aplicar, y por supuesto, no tenemos que volver a compilar), y no en tiempo de compilación por lo que no hay acoplamiento. Para que os hagáis una idea de la potencia y utilidad de MEF, sólo comentaros que Visual Studio 2010 en sí mismo utiliza MEF para poder ser extendido con nuevas capacidades.

¿Cuál sería el uso práctico de MEF?  Por ejemplo, añadir nuevos módulos a una aplicación en tiempo de ejecución (Por ejemplo: se crean unos módulos de aplicación al principio y más tarde se añaden otros):

  • Podemos ir dejando los ensamblados en un directorio y que la aplicación, gracias a MEF, esté continuamente chequeando el directorio (Composition Container) en busca de nuevos ensamblados (catálogos) y los cargue sin necesidad de tener que referenciarlos.
  • También se podría monitorizar un cierto ensamblado buscando nuevos añadidos.
image image

MEF en acción

Para evaluar MEF en acción, vamos a crear un sencillo ejemplo utilizando un proyecto de aplicación de consola. A este proyecto le añadimos un elemento de tipo class file con el siguiente código:

 

using System; 

namespace Without_MEF

{

    //Class with a property implementing the interface

    public class Doorman

    {

        public IGreeting Greeting { get; set; }  

        public void CustomerArrived()

        {

            Greeting.SayHello();

        }

    }

    //Starting point -> Public interface

    public interface IGreeting

    {

        void SayHello();

    }  

    //First public class inheriting from the public interface

    public class HappyGreeting : IGreeting

    {

        public void SayHello()

        {

            Console.WriteLine("Hello to all my god, happy, friends!");

        }

    }  

}

Cómo veis, el código es bastante simple:

  • Definimos una interfaz IGreeting de la que hereda las clases HappyGreeting.
  • A su vez definimos una clase Doorman que tiene una propiedad Greeting de tipo IGreeting.

¿Cómo usamos estas clases habitualmente en nuestro código? Pues instanciándolas. En nuestro caso, y para la aplicación de consola, sería:

            var doorman = new Without_MEF.Doorman();

            doorman.Greeting = new Without_MEF.HappyGreeting();

            doorman.CustomerArrived();

            Console.ReadKey();

Y la salida por pantalla correspondiente es la siguiente:

image

Si utilizamos MEF, un código tan simple como el anterior se simplifica aun más. Añadimos al proyecto un nuevo elemento de tipo class file, y además necesitaremos añadir una referencia a System.ComponentModel.Composition. A este archivo de clase le añadimos el siguiente código:

using System;

using System.ComponentModel.Composition;  

namespace WithMEF

{

    //We decorate Doormanwith Export in order to use from an application

    [Export]

    public class Doorman

    {

        //We have to import IGreeting

        [Import(typeof(IGreeting))]

        public IGreeting Greeting { get; set; }  

        public void CustomerArrived()

        {

            Greeting.SayHello();

        }  

    }  

    //The original interface

    public interface IGreeting

    {

        void SayHello();

    }  

    //We export HappyGreeting because we want to use it

    [Export(typeof(IGreeting))]

    public class HappyGreeting : IGreeting

    {

        public void SayHello()

        {

            Console.WriteLine("Hello to all my god, happy, friends!");

        }

    }

}

Como podéis ver en el código anterior:

  • Por un lado, estamos exportando la clase Doorman porque la queremos consumir en otra aplicación de forma que esta sea extendida. Para poder exportar la clase, tenemos que decorarla con el atributo [Export].
  • A su vez, dentro de Doorman estamos importando IGreeting decorando para ello la propiedad que implementa esta interfaz con el atributo [Import] en el que especificamos el tipo importado.
  • Lógicamente, tendremos que exporta HappyGreeting que implementa IGreeting decorándola con [Export] y especificando que es de tipo IGreeting.

¿Y ahora como utilizamos las características de MEF en nuestra aplicación? Pues utilizando un código tan sencillo como el siguiente:

                //Monitorizamos el ensamblado actual

                var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());  

                //Definimos un objeto contenedor

                var container = new CompositionContainer(catalog);  

                //Buscamos el objeto exportable en el contenedor

                var doorman = container.GetExportedObject<WithMEF.Doorman>();

                doorman.CustomerArrived();

Cómo veis con MEF no tenemos que instanciar los objetos, sino que:

  • Definimos uno o varios catálogos desde donde nos traeremos los objetos definidos como exportables (Doorman en nuestro caso). Estos catálogos se pueden definir a partir de monitorizar un ensamblado (llamada al GetExecutingAssembly) o un cierto directorio.
  • Definimos un objeto de tipo CompositionContainer que contiene el catálogo o catálogos que nos permiten extender la aplicación.
  • Sin más, nos traemos el objeto exportable con GetExportedObject y ya lo tenemos listo en nuestra aplicación para usarlo sin que esta sea consciente de su naturaleza : no instanciamos, luego no hay acoplamiento.

Y hasta aquí llega este primer post sobre MEF. Espero que os haya resultado interesante.

SQL Server 2008: Como lanzar Report Builder 2.0 desde SharePoint!

Como os comentaba en este post, con el SP1 de SQL Server 2008 se sigue lanzando el Report Builder 1.0 desde el Repor Manager por lo que tendremos que realizar nosotros la configuración manual necesaria para que se lance el Report Builder 2.0 (os remito al post mencionado). ¿Y qué pasa en una instalación de SharePoint (WSS 3.0 & MOSS) en la que tengamos configurada la integración con SQL Server Reporting Services 2008 (SSRS 2008). Pues lo mismo, con el añadido de que tendremos que instalar el Microsoft SQL Server 2008 Reporting Services Add-in for Microsoft SharePoint Technologies. Empecemos.

Instalación del SP1 de SQL Server 2008 y el Report Builder 2.0 en un entorno con SharePoint

Como os comentaba, los pasos de instalación son los mismos que en un entorno en el que no tengamos SharePoint:

  • Instalamos el SP1 de SQL Server 2008.
  • Instalamos el Report Builder 2.0 SP1.

Instalación del Add-In de SSRS 2008 para SharePoint

Una vez que hemos instalado el SP1 de SQL Server 2008 y el Report Builder 2.0, ya estamos listos para instalar el Add-In de SSRS 2008 para SharePoint:

  • La primera pantalla nos informa de que ya existe una versión del Add-In, por lo que tendremos que confirmar que vamos a realizar la consiguiente actualización.
  • En la siguiente pantalla, simplemente pulsamos Next.
  • Tras confirmar el correspondiente acuerdo de licencia, pulsamos Next.
image image image
  • En la siguiente pantalla especificamos un nombre para la instalación (el nuestro propio) y el nombre de nuestra organización y pulsamos Next.
  • En la siguiente pantalla, pulsamos Install y ya estamos listos para que se lleve a cabo el proceso de instalación.

image image image

  • Una vez que ha concluido el proceso de instalación, simplemente pulsamos Finish.
  image  

En el caso de una instalación de SSRS 2008 integrado con SharePoint, pasa lo mismo que veíamos en una instalación normal de SSRS 2008: desde Report Manager se lanza Report Builder 1.0 y no Report Builder 2.0. Como sucedía con el Report Manager, esto se puede solucionar realizando unos pasos adicionales en este caso:

image image image
  • En la siguiente pantalla pulsamos Install y a esperar unos pocos minutos para que se realice el proceso de instalación.
  • Una vez acabado el proceso, pulsamos Finish.
image image image

Ahora bien, al igual que ocurría con Report Manager, una vez realizadas todas estas instalaciones, tendremos que configurar de forma manual el lanzamiento de Report Builder 2.0 desde SharePoint:

  • Nos vamos a la administración central de SharePoint. En la pestaña Application Management, pulsamos Set Server defaults en la sección de Reporting Services.
  • Como ocurría en la configuración del Report Manager, tendremos una sección en la que especificar la url de lanzamiento del Report Builder que en este caso tiene la forma: 

/_vti_bin/ReportBuilder/ReportBuilder_2_0_0_0.application

  • Una vez configurado, nos vamos a una biblioteca que tengamos configurada con un content type de tipo Report Builder Report. 
image image image

  • Veremos que se lanza la aplicación ClickOnce de Report Builder y que tras pulsar Run, comienza el proceso de descarga.
  • Finalmente, aparece Report Builder 2.0 en nuestras pantallas.
image image image

Y hasta aquí llega este nuevo post sobre SSRS 2008 y SharePoint. Espero que os haya parecido interesante.