jueves, 25 de febrero de 2010

MSS 2010: Business Connectivity Services (BCS)

Otro de los nuevos conceptos de interoperabilidad que incorpora SharePoint 2010 es el Business Connectivity Services (BCS) que es una muy positiva evolución del Business Data Catalog (BDC). También se le llama Business Data Connectivity Services.

Si nos pidieran de forma muy breve las principales diferencias entre BCS y BDC, podríamos hacer referencia a la siguiente tabla comparativa:

Sin embargo BCS incorpora mucha más potencia de que que esa tabla refleja. En este post intentaré repasar los conceptos más interesantes del nuevo servicio.

El BCS proporciona integración entre datos externos y SharePoint-Office, permitiendo interactuar con ellos, reutilizar de forma ágil esos datos tantas veces como queramos y permitir a los usuarios finales ganar visión dentro de los datos subyacentes. 

El BCS utiliza como estructura básica para construir las conexiones (Building Blocks) los External Content Types (ECT). Un External Content Type es un fichero xml que define la estructura de datos almacenada en un sistema externo compatible, como una base de datos SQL Server, otras bases de datos relacionales, un sitio de SharePoint, un Web service, o un conector de datos personalizado. Los ECT se añaden directamente al Business Data Conectivity Service.
 Un ECT contiene información sobre:
  • Los campos de datos que contiene el objeto
  • Los métodos para crear, leer, editar, consultar o eliminar un objeto.
  • Las acciones que el usuario puede realizar con el objeto
  • Información de soporte a la conexión de la fuente externa, que proporciona los datos del objeto.
 Los ECT pueden ser creados desde SharePoint Designer (crear modelos a partir de conectores ya creados) o con Visual Studio (crear conectores y modelos).

Una vez que hayamos creado el ECT, podremos realizar diversas acciones sobre él, como definirle

los permisos de acceso, ver todos los ECTs contenidos en un modelo o en una istancia del BCS, añadir una nueva acción al ECT, crear o modificar una página de perfil para el ECT, eliminar el ECT... 

 
Hasta aquí hemos visto por encima la estructura del BCS, pero una vez que tengamos los modelos de conexión externa definidos, ¿Qué podemos hacer con ellos? Quizás, la novedad más destacable en SharePoint 2010 sea la posibilidad de generar Listas Externas de Datos, y tratarlas como si fueran una lista más de SharePoint. Para poder crear una lista externa, deberemos haber creado previamente un ECT y haberlo incluido en el BCS.
 
Las listas externas en SharePoint 2010 tienen realmente un amplio abanico de posibilidades y opciones de interacción con el usuario:
  • Permiten acciones de Crear, Obtener, Actualizar y Borrar items
  • La interface de usuario y navegación es totalmente familiar (como las listas internas de MSS)
  • Permite filtrar, ordenar y agrupar
  • Se tiene acceso programático a las listas externas via SPList
  • Se obtiene una vista de detalle para cada item de la lista
  • Genera un formulario out-of-the box que podemos convertir a infopath
  • Permite el trabajo offline de los datos

Sin embargo, con ECT de los BCS podemos realizar muchas más integraciones en nuestra plataforma, a parte de las listas externas. 
 
  • Columnas Externas de datos --> Añaden columnas de datos externos a listas estándar de SharePoint. Estas columnas pueden además estar disponibles como controles de contenido en Word.
  • Búsquedas --> Permite integrar datos externos como resultados de búsqueda.
  • Outlook --> Integración con contactos, tareas, calendarios y posts
  • Word
  • InfoPath
  • Access
  • Otras aplicaciones Office via código .NET
  • Workflows --> Se puede acceder a los datos de los External Content Types definidos a través de los Workflows de SharePoint.

Todas las conexiones a office se realizan mediante un BCS Client Runtime.
 
Existen también, diversos WebParts en MSS 2010 que permiten tratar e interactuar con los datos obtenidos a partir de los external content types del BCS:
  • External Data List 
  • External Data Item
  • External Data Item Builder
  • External Data Related List
  • External Data Connectivity Filter
  • Chart Web Part

Además, también podemos trabajar de forma offline con los datos del BCS mediante el SharePoint WorkSpace, que  permite tanto la importación de listas externas como de librerías de documentos con columnas de datos externas. La integración offline incluye también algunas funciones extras para el tratamiento propio de los ETC, como la subscripciones o la detección automática de conflictos.

Por último comentar que la integración de los BCS se extiende hasta niveles bastante profundos de la arquitectura de SharePoint, permitiendo por ejemplo realizar operaciones masivas o en lote sobre los ETC, soporte a la validación por Claims, integración en el ciclo de vida mediante soluciones de empaquetado automático (WSP) para el manejo de despliegue de aplicaciones, Thorttling, optimización del refresco de la caché para mejorar los tiempos de respuesta (performance), etc.

Como veis, la integración de los Business Connectivity Services con la plataforma Microsoft es enorme, permitiendo aprovechar al máximo las conexiones de datos externas y reutilizarlas de múltiples formas tanto en SharePoint como en el resto de aplicaciones Office.


Hasta aquí el breve resumen del BCS, el tema es extenso y daría para muchos posts especializados, pero de momento me conformo con ir dejando claros algunos conceptos base sobre los que ya iremos profundizando con el tiempo.

¡ Saludos !

lunes, 22 de febrero de 2010

MSS 2010: El estándar CMIS

CMIS (Content Management Interoperability Services)  es un estándar creado para potenciar la interoperabilidad entre diversos repositorios y aplicaciones de Enterprise Content Management (ECM), permitiendo a las aplicaciones que ataquen a uno o más repositorios de ECM de forma uniforme mediante un conjunto unificado de servicios web.

El estándar CMIS fué creado en el año 2006 por IBC, EMC y Microsoft, y en 2007 se anexaron Alfresco, OpenText, Oracle y SAP. En octubre del 2009 se transfirió a OASIS Technical Committee,para proceder a la estandarización que actualmente está en la especificación 1.0, lanzada el 22 de diciembre del 2009.

CMIS permite mapear fácilmente los sistemas ECM existentes, exponiendo un conjunto de APIs estándar para las capacidades existentes de los repositorios de CM y permitiendo aprovechar el contenido ya existente, comunicándose entre ellos a través de un interfaz web.

El estándar incluye un "modelo de dominio" y soporte para 2 protocolos: SOAP (Simple Object Access Protocol ) y REST/Atom (Representational State Transfer). También ha sido diseñado para ser proyectado en los sistemas de ECM actuales.

De hecho, CMIS consiste en un interfaz de servicios web (web services) estandarizado. El modelo conceptual de arquitectura del CMIS es el siguiente:

Aunque en el momento de aparición de la Beta 2 CMIS todavía estaba en versiones Draft y por tanto no se incluyó en la misma, Microsoft anunció que SharePoint 2010 soportará la especificación 1.0 de CMIS. ¿Qué significa exactamente eso? Pues, básicamente que entre los webservices que podremos invocar desde SharePoint, se incluirán todos aquellos que define el estándar CMIS. Dicho de otro modo, en SharePoint 2010 podremos comunicarnos con otros ECM, como Documentum o Filenet, sencillamente invocando webservices incluidos en el core del SharePoint. Estos web services incluirán un montón de funciones para realizar operaciones de lectura, escritura, check-in, check-out, relaciones, versionado, etc.

En este sentido, Alfresco dispone de más información actualizada que os puede servir para haceros una idea (se supone que los servicios y funciones son comunes entre plataformas).

Así que para poder probar el estándar CMIS en acción todavía deberemos esperar un tiempo: Primero a que Microsoft lo incluya la especificación en la versión RTM de SharePoint 2010 (¿RTM?)y después a que tengamos la fortuna de tener la ocasión de implantarlo en alguno de nuestros proyectos realizando una integración con un ECM corporativo (Esto no es algo que se pueda probar fácilmente en nuestro entorno de "test" habitual).

Posiblemente, llegado el momento nos daremos cuenta de que CMIS es todavía un estándar muy joven, con algunas dificultades y limitaciones y que necesitará de un tiempo más para madurar correctamente (ya se empieza a hablar de la especificación 2.0). Sin embargo que todos los ECM destacados del mercado hablen un mismo lenguaje y utilicen una misma librería de funciones y webservices solo puede tener un único resultado final: grandes beneficios para el usuario necesitado de dichas integraciones.

Bravo por Microsoft y su esfuerzo por integrarse con otras plataformas del mercado.

sábado, 20 de febrero de 2010

MSS 2010: Remote BLOB storage (RBS)

¿Que es un BLOB? El acrónimo viene de Binary Large OBject (Objetos Grandes Binarios) y se define como la corriente de datos asociada a un fichero (es el fichero en sí mismo).

En SharePoint, como todos sabemos, los BLOBs se guardan out-of-the-box directamente en una base de datos SQL Server. Dicho de otro modo, cuando subimos un fichero a SharePoint, este queda almacenado en el SQL. Esto permite que copiando una base de datos de contenido podamos recrear portales enteros con todos sus contenidos (ficheros, imágenes, vídeos, etc.), pues absolutamente TODA la información de contenido está embebida en la propia Base de Datos. El esquema de funcionamiento vendría representado por el siguiente diagrama:

El almacenamiento de BLOBs en el SQL Server es una de las mayores polémicas que suscita el uso de SharePoint. A muchas empresas (sobre todo las más grandes) no les gusta que todos sus datos estén incluidos en una o varias bases de datos. ¿Qué sentido tiene embeber en un SQL un vídeo de 300MB? ¿Qué sentido tiene verse obligado a manejar bases de datos de crecimiento exponencial de varios TB? (con la carga adicional de mantemiento que conlleva administrar esas BD )

Hay que tener en cuenta que los BLOBs suelen ocupar entre el 60 y el 70% del total del contenido de una intranet, y puede ser superior en proyectos donde el protagonismo lo lleven las librerias de documentos y Record Centers.

Entre los principales problemas que suponen almacenar los BLOBs en las bases de datos de contenidos es el impacto en el rendimiento del propio SQL Server (hace un uso intensivo del disco al estar continuamente cargando los ficheros que contiene), impactando por consiguiente en todo el rendimiento de nuestra granja de servidores. Otro factor es el coste de manejabilidad de nuestras copias de seguridad y restauración, debido al inmenso tamaño que adquieren las Bases de Datos que contienen todos los BLOBs.

En SharePoint 2007 SP1 ya existía la posibilidad de que los BLOBs no se almacenaran directamente en el SQL y lo hicieran de forma totalmente externa. A ese servicio le llamábamos External Blob Storage (EBS).

Sin embargo SharePoint 2010 mejora el EBS en múltiples aspectos, consiguiento un tratamiento muy mejorado de los BLOBs externalizados llamado Remote BLOB Storage (RBS). A continuación se muestra una tabla que narra la evolución de los BLOBs remotos en las diversas versiones de SharePoint:


SharePoint 2010 también soporta EBS, aunque está catalogado como "deprecated", y no estará soportado en futuras versiones (RBS sí que tiene soporte garantizado en futuras versiones de SharePoint).

En la siguiente tabla se mustran las diferencias más destacadas entre el antiguo EBS y el nuevo RBS:


¿Cómo funciona realmente RBS en SharePoint 2010? Es indispensable que un proveedor externo de blobs nos proporcione una API en forma de add-in descargable (en nov. 2009 ya estaban disponibles EMC²; OpenText; AvePoint; Commvault y NetApp). El almacenamiento para todos los BLOBs en las Bases de Datos de contenido estará disponible cuando activamos la API del proveedor y a partir de entonces, los clientes pueden elegir el proveedor de BLOBs que van a utilizar.

De hecho, lo único que se almacena en el SQL Server cuando se ha activado el RBS son los metadatos propios del item y su BLOB ID. Con este BLOB ID podremos posteriormente recuperar el BLOB en questión en sistema de almacenamiento de BLOBs proporcionado por cada proveedor. A continuación se muestra un esquema de un flujo típico de escritura mediante RBS:

Para instalar RBS en SharePoint 2010 necesitaremos disponer de un SQL Server 2008 R2, donde instalaremos el Add-in de RBS en el propio SQL Server. Después instalaremos las librerías (.dll) de las APIs del BLOB del proveedor en cada servidor frontal (WFE). Finalmente activaremos el RBS utilizando PowerShell (todo el RBS se administra con PowerShell).

Para mantener el RBS se instalará un recolector de basura (garbage collector) en el propio SQL o un WFE de SharePoint que se encargará de realizar las tareas de mantenimiento. Este recolector se podrá activar periodicamente mediante un procedimiento programado (schedule) y que podrá parametrizarse con políticas de retención

A modo de conclusión, podemos decir que el uso de RBS proporciona las siguientes ventajas destacadas:
  1. Capacidad de almacenar los BLOBs de forma separada a los metadatos
  2. La gestión del almacenamiento de datos se realiza independientemente del SQL Server, con la liberación de carga de trabajo y aumento de "performance" que conlleva este hecho en nuestra granja de MSS 2010.
  3. Aprovecha las ventajas de las características de almacenamiento avanzado de datos que proporcionan los proveedores de BLOBs externos (expurgar, múltiples localizaciones de almacenamiento, escrituras inmutables, garantía de retención, garantía de supresión, etc.)
  4. Administración jerárquica del almacenamiento: El uso de SQL y diversas capas de BLOBs se supone que ahorran costes en CapEx y OpEx .Este tipo de administración también proporciona patrones de acceso eficientes para el tratamiento de datos.

Realmente parece que el RBS va a ser mucho más fácil de implantar que el EBS, más fácil de administrar (PowerShell), más eficiente y con mayor soporte de los diversos proveedores de BLOBs. Personalmente estoy deseando poderlo probar en alguna implantación real y comprobar así la eficiencia de tener los archivos en repositorios externos, utilizando el SQL Server solo para almacenar los metadatos y otros tipos de elementos menos pesados del SharePoint.
¡Saludos!

viernes, 19 de febrero de 2010

MSS 2010: Tipos de licencias y SKUs

Echándole un ojo a las presentaciones que me llevé de la "SharePoint Conference 2009" en Las Vegas, he encontrado una información que intenté buscar sin éxito anteriormente en la web. El tipo de licencias y los servicios que incluirán cada una de las versiones de SharePoint 2010. Si vamos a la web oficial de Microsoft sobre el tema, nos llevamos una gran decepción por la casi total ausencia de concreción. Así que, aun siendo conscientes que estas diapositivas son previas a la beta 2 y que pueden variar algo respecto la RTM, por lo menos nos dará una idea más definida sobre la cual comenzar a plantear nuestras instalaciones/migraciones a 2010.

Empezamos con una diapositiva que muestra, a grandes rasgos, las diferenencias entre las 3 versiones de SharePoint 2010: SharePoint Foundation (equivalente a WSS 3.0 y gratuito) Sharepoint Standard y Sharepoint Enterprise:
Recordemos que el término Insights es el que sustituye a "Business Intelligence" (Performance Point y demás). Viene a ser lo mismo, pero parece ser que el BI es un término que se ha quedado algo "anticuado" o "desvirtuado" y Insights es mucho más "cool".

A continuación veremos las diferencias básicas entre la versión estandard y enterprise. La siguiente diapositiva especifica las funcionalidades de la version estandard:


La versión enterprise está construida con la misma base, pero (como no) incorpora toda una importante serie de servicios adicionales. ¿Cuales exactamente? La diaposiva siguiente es bastante reveladora al respecto:

Personalmente me genera algunas dudas, también: Tal y como hemos visto en la Beta 2, Infopath no es un servicio de SharePoint 2010, sino que está integrado en el núcleo de su framework. A pesar de ello, ¿Existirá alguna limitación con el infopath entre standard y enterprise? Habrá que esperar un poco más para tener la certeza. Para el "FAST Search Use Rights" se necesitará tener FAST Search Server.

En la próxima diapositiva se ven las diferentes versiones del producto, enfocadas tanto para intranets, extranets y portales de internet. Como vereis hay 4 novedades al respecto: 

  1. SharePoint Server 2010 for internet sites standard (Anteriormente solo existia la enterprise en dicha modalidad). Lo que significa que podremos construir portales de internet con licencias mucho más baratas que en la anterior versión (aunque con servicios limitados, claro)

  2. FAST Search Server 2010 for SharePoint (Intranets)

  3. FAST Search Server 2010 for SharePoint internet Sites (Internet/Extranet)

  4. FAST Search Server 2010 for internet Business (Internet/Extranet)
Como veis FAST Search Server, a pesar de lo que pensaban algunos, será un producto a parte (No viene incluido en la Enterprise). Para poder disfrutar de FAST se deberá tener SharePoint Server 2010 y licencias Enterprise. Hay que decir también que FAST no irá con CAL's de cliente (menos mal) sino que se activará mediante una única licencia por servidor (running instance).

Por otra parte, también existirán más licencias de tipo Online, también divididas según si son para intranets o extranets/Portales de Internet:

Para finalizar, incluyo el siguiente cuadro de resumen donde se explica a groso modo el funcionamiento de cada tipo de licencias:

 
Como veis, la base gratuita sigue siendo la misma: SharePoint Foundation, SharePoint Designer y Search Server Expresss.

El detalle exacto y los precios de cada tipo de licencia tardarán aproximadamente un mes más en llegar, pero al menos espero haber aclarado dudas al respecto y tener una idea más próxima de las SKUs del SharePoint que tenemos a la vuelta de la esquina.

¡Saludos!

jueves, 18 de febrero de 2010

MSS 2010: Quotas por puntos

Hasta ahora estábamos acostumbrados a que cuando hablábamos de quotas de SharePoint nos referíamos a la cantidad de megas que asignábamos a los usuarios para crear sus sites. Si el usuario estaba cerca de rebasar la quota MOSS nos enviaba un correo electrónico y si esta alcanzaba su límite se bloqueaba el site y el usuario no podía crear nuevos contenidos hasta que hiciera "limpieza" y liberara unos cuantos megas.

En SharePoint 2010 el concepto sigue partiendo de la misma base, pero ya no solamente podemos limitar por espacio ocupado en disco, sino también (y ahí la novedad) por puntos. El sistema de quotas se asigna a nivel de site collection y básicamente está pensado para soluciones que incorporan código (como por ejemplo una sandbox solution).

¿Cómo funciona exactamente? Desde la administración central en Aplication Management --> Quota Templates podremos acceder a la pantalla de configuración de la quota y asignarle los valores que consideremos necesarios, tal y como muestra la siguiente imagen:

En este caso hemos asignado 300 puntos para esta plantilla de quota.

De hecho, el funcionamiento es similar al carnet de conducir por puntos: Inicialmente tenemos unos puntos, pero por cada "sanción" nos irán restando puntos (dependiedo de la gravedad del "delito"). Quando lleguemos a cero, el site collection bloqueará el site collection.

SharePoint tiene una tabla interna donde define una serie de acciones que consumen puntos y la equivalencia con los mismos. Por ejemplo "cuando una aplicación consuma el 85% del uso de la CPU", se consumirá un punto, o "cuando haya un Abnormal Process Termination" se consumirá otro punto. Esta tabla se representa en el siguiente gráfico, aunque matizo que es la que está operativa en la beta 2 y podría sufrir modificaciones respecto la RTM:
Los puntos se renuevan cada dia, y no son nunca acumulables (si la quota está en 300 puntos y ayer gastaste 100 no significa que mañana tengas 500, sino que cada dia partirás de 300).

Como las quotas se asignan a nivel de site collection, los puntos que asignemos serán consumidos por la suma de las aplicaciones que corran en él.

La siguiente imagen muestra cómo funciona el proceso de monitoreo de quotas.

Esto permitirá que si tenemos una solución instalada que está dando muchos problemas o consume muchos recursos, el sistema pueda bloquearla y no permitir su ejecución, volviendo a liberar los recursos que estos consumía en la granja.

¿Qué os parece? A partir deberemos tener especial cuidado en el desarrollo de nuestras aplicaciones, no sea que nuestro cliente nos identifique como un "consumidor de puntos" desmesurado... ;-)

martes, 16 de febrero de 2010

MSS 2010: Concepto de Claim

Hoy quisiera hacer una introducción a lo que posiblemente sea uno de los conceptos nuevos que incorpora SharePoint 2010 más abstractos de todos, pero quizás también con más recorrido en el futuro (realmente suena a concepto futurista). Se trata del concepto de Claim Based Autentication (que además no está del todo completamente implantado en la Beta 2).

Hasta ahora estamos acostumbrados a trabajar con el concepto de "identidad" o "perfil" de usuario. Un usuario se define como un conjunto de atributos (nombre, apellido, departamento, contraseña, etc.)

Un Claim es un único atributo de esa identidad. Por ejemplo la "edad" de un usuario sería un Claim. Saber que ese usuario tiene "18 años" es un rasgo concreto de la identidad de esa persona que por sí misma podría bastar para permitirle entrar o no en determinados portales web (páginas de contenido para adultos, por ejemplo). Otro Claim podría ser, por ejemplo, saber que el usuario pertenece a un perfil "comercial", o que reside en "Barcelona".

Hasta aquí podríais pensar que un Claim es simplemente un atributo de un perfil de usuario. ¿Por que entonces se le llama claim (se traduce al español como "afirmación" o "aserción") y no como "attribute"? Porque para que el Claim tenga verdadera entidad como sistema de validación, debe estar respaldado por una entidad (Autentication Provider) que certifique que ese atributo es cierto y se cumple. Es decir, alguien afirma que ese atributo es real.

Además, hay que añadir que el concepto "claim" no es un concepto abstracto de Microsoft para Microsoft, sino que se basa en 3 estándares abiertos:
  1. WS-Federation 1.1: Proporciona la arquitectura para una separación limpia entre los mecanismos de confianza, formatos de seguridad de tokens y los protocolos para la obtención de tokens
  2. WS-Trust 1.4: Especifica cómo solicitar y recibir tokens.
  3. SAML Token 1.1: Lenguaje XML utilizado para representar los claims en un entorno de interoperabilidad.
Se considera que el concepto de claims es la evolución del de "federación", ya que ofrece mayor claridad al permitir que proveedores de claims sean externos a la propia aplicación.
 
El funcionamiento de los claims se basa en un sistema de tokens (sí, parecido a kerberos) en el que una entidad (Autentication Provider) te entrega el token conforme cumples con ese atributo identificativo, y ese token viaja hacia la aplicación con la que te has de validar.
 
 
Por tanto, la autenticación de claims se basa en un sistema de confianza (trust) entre diversas entidades: Una entidad está dispuesta a acudir a otra entidad para que le emita una serie de afirmaciones (claims) sobre un usuario concreto.
 
 
 
Sharepoint  2010 tiene su propio servicio de "Autentication Provider", es un servicio más que podemos manejar desde la administración central (Security Token Service), que soporta diversos tipos de creedenciales y escenarios federados. Se considera un proveedor "neutral".
 
De echo, en SharePoint 2010 ya no existe el concepto aislado de "Autenticación por Formularios" o FBA, sino que pasa directamente a "FBA-Claims" (las migraciones de FBA implicarán la configuracion y activación de claims).
 
¿Cual es el resultado de todo esto? Pues que por ejemplo (esto me lo invento), si entramos en la web de Ferrari (digo Ferrari porque ya sabemos todos que está construida con SharePoint) y esta tuviera autenticación basada en claims, podría no dejarnos entrar a subscribirnos a información de ciertos modelos de gama alta si una entidad certificadora (digamos "Hacienda" ) le certificara que nosotros no tenemos unas ganancias anuales suficientes para aspirar a ellos, o podría mostrarnos en la página principal el modelo que más se ajuste a nuestra edad, siendo la edad un claim que le otorgó otra entidad certificadora (digamos Facebook).
 
Personalmente pienso que los claims es un paso más en el gran esfuerzo que Microsoft ha hecho en esta versión para tener un producto "in the cloud" ("en la nube", o "en internet"), que permita hacer negocio con el hosting y las páginas web (SharePoint 2010 da un gran avance como generador de webs públicas, no solo intranets y extranets). Con claims pronto empezaremos a ver webs que nos mostrarán productos ajustados a nuestro perfil de usuario, o que nos aceptarán o denegarán el acceso porque pertenecemos a ciertos grupos de redes sociales... Sin embargo, si hablamos de intranets o extranets, probablemente tardaremos más tiempo en verle utilidad al concepto, ya que muchos seguiremos usando el "Windows Classic Autentication" de toda la vida durante los próximos años.
 
Sin embargo, empezad a empaparos del término, estoy seguro que tiene futuro... ¿Alguien quiere apostarse conmigo que en un futuro no muy lejano el Active Directory de Windows pasará a ser una entidad certificadora de claims?

jueves, 11 de febrero de 2010

MSS 2010: Servicio de Metadatos Administrados (III) Ejemplo de uso

Para finalizar de momento con el servicio de metadatos administrados (MMS) y entenderlo bien del todo, hoy me gustaría guiaros a lo largo de un ejemplo práctico.

Para empezar accederemos al Panel de Administración Central--> Application Management --> Manage service applications

Una vez dentro de la administración de los servicios, crearemos un nuevo servicio de metadatos a través del menú de la Ribbon: New--> Managed Metadata Service

Nos aparecerá un formulario donde pondremos los datos de nuestro nuevo servicio, tales como su nombre, el servidor de la base de datos, el nombre de la base de datos, el tipo de autenticación, el nombre del servidor de alta disponibilidad (en caso que hubiera), el application pool del que va a depender el servicio, el nombre de la cuenta que lo va a administra y el nombre del "Content Type Hub" (aquí es donde se define cual es la aplicación web que publica los tipos de contenido).


Una vez rellenados todos los campos y completada la creación del servicio, veremos que volvemos a la página de administración de los servicios administrados, y que nos ha creado tanto el servicio como el proxy de servicio



Si pulsamos sobre el nuevo servicio creado (ha de ser sobre el texto del servicio) nos abrirá la pantalla de administración del servicio. En la zona central de la pantalla podremos indicar qué usuarios pueden administrar este servicio, así como establecer un idioma por defecto y especificar en qué idiomas vamos a publicar nuestro servicio de metadatos (siempre que hayamos instalado los correspondientes languages packs)

El servicio por defecto crea un Term Store (Managed Metadata) y un Term Set Group (System) donde se almacenan todas las palabras clave y términos que queden huérfanos.

Nosotros creamos nuestro propio Term Set Group pulsando el desplegable a la derecha del Term Store y seleccionando "New Group"

Le damos el nombre que queramos a nuestro grupo y veremos que al crearse este, la zona central de la pantalla cambia para mostrarnos las opciones del Term Set Group (Nombre, Descripción, Quien tiene permisos de Manager y Quien tiene permisos de contribución).

Ahora abrimos el menú propio del Term Set Group que acabamos de crear y seleccionamos "New Term Set" para crear nuestro conjunto de Términos. Observad que también nos deja eliminar el grupo e importar un Term Set.

Le ponemos el nombre que queramos, pulsamos intro y esperamos a que se cree nuestro Term Set.


De nuevo la zona media de la pantalla vuelve a cambiar para mostrar ahora las opciones propias del TermSet (Nombre, Descripción, Propietario, correo de contacto, grupo de usuarios interesados y varias opciones interesantes donde podemos decidir si los usuarios pueden ampliar los términos del Term Set o solo los administradores pueden hacerlo, y también si permitimos que el usuario etiquete (con tags) contenidos del portal con estos términos.

Podemos crear tantos Term Sets como queramos, repitiendo el paso anterior.

Ahora empezamos a crear Terminos abriendo las opciones del TermSet y seleccionando "Create Term". Observar que en el menú de opciones también nos permite copiar el Term Set, Reutilizar Términos, Mover el Term Set o Borrar el Term Set.

Una vez más la zona central de la pantalla cambiará para mostrarnos las opciones propias del Término (si está disponible para etiquetas (tags), su idioma, descripción, literal y palábras sinónimas, así como un cuadro donde veremos de dónde es miembro el término.

Repetimos esta operación de crear términos tantas veces como queramos hasta completar nuestra librería de términos.

Si abrimos el menú de opciones de un término veremos que éste nos permite crear más términos copiar, rechazar, mover, eliminar o dejar deprecated (un término "deprecated" no aparecerá como disponible en adelante, pero seguirá operativo para las estructuras que anteriormente lo usaron)

Ahora que ya hemos creado nuestra biblioteca de términos salimos de la administración central y vamos a nuestro portal web de SharePoint 2010. En él creamos una nueva lista personalizada, y una vez creada creamos una nueva columna del tipo "Metadatos Administrados". Al crear dicha columna veremos que nos pregunta si queremos que el valor del campo sea el término o toda la ruta del término, y seleccionar el Term Set que queremos utilizar como posibles valores del campo, así como personalizar el conjunto de términos o seleccionar el valor predeterminado del mismo.

Una vez completada la creación de la columna, podemos ver el resultado final: Cuando creamos un nuevo ítem en la lista nos pide el campo de metadatos, y nos deja escoger entre los posibles valores del TermSet

Además de utilzarse en las columnas de las listas, también sirve para etiquetar (tags) elementos de las listas, y para filtrar de forma ágil los resultados de búsqueda, entre otras cosas.

Como veis el MMS tiene muchísimas opciones de configuración, y lo mejor de todo es que una vez definidos, nunca más tienes que volver a definir la misma estructura, estés en la aplicación web que estés y sin importar si estás en un u otro site collection, pero como este post se ha hecho demasiado largo, comentaré este tema en concreto en un próximo post dedicado especialmente a los tags.

Con el servicio de metadatos administrados, podremos tener una taxonomía jerárquica de términos realmente consistente en nuestra empresa.

Espero que esta serie de posts os hayan servido para comprender la potencia de este nuevo servicio, ¡ un saludo!

miércoles, 10 de febrero de 2010

MSS 2010: Servicio de Metadatos Administrados (II) Content Type Hubs

En el post anterior vimos la definición del nuevo servicio de metadatos administrados (Term Store Management). Sin embargo, este servicio ejerce una funcionalidad extra en la arquitectura lógica de nuestra granja de servidores MSS 2010, el de Content Type Hub.

El concepto de Content Type Hub es simple: Tenemos una apliacación web que tiene una serie de Tipos de contenido definidos (Content Types). Estos Tipos de Contenido son publicados (compartidos) hacia otras aplicaciones web. Todas aquellas aplicaciones web que se subscriban a ese Hub podran tener acceso a los mismos tipos de contenido, incluso si estos son actualizados desde la aplicación web original.

Los tipos de contenido se pueden modificar en la aplicación web que los publica, pero solo son de lectura en las que se suscriben.

El esquema gráfico donde se ve todo más claro es el siguiente:


Tan solo se permite crear un Content Type Hub por MMS (Metadata Managed Service), pero una aplicación web puede subscribirse a múltiples Hubs.

La gran ventaja de esta arquitectura es que podemos gobernar de forma central un sistema de tipos de contenido que se pueda reutilizar entre diversas colecciones de sitios, aplicaciones web o granjas de servidores, consiguiendo una fuerte consistencia de contenidos a lo largo de toda la arquitectura MSS 2010.

Interesante, ¿no creeis? Parece que las colecciones de sitios ya no serán islas incomunicadas de contenidos.

En el próximo post veremos un ejemplo práctico de cómo configurar y utilizar el servicio de metadatos, y como se configura un Content Type Hub.

Hasta entonces, ¡Un saludo!

martes, 9 de febrero de 2010

MSS 2010: Servicio de Metadatos Administrados (I)

Hoy empezaré una serie de 3 posts donde revisaré uno de los nuevos servicios que incorpora SharePoint 2010 y que me parece particularmente interesante, se trata del servicio de metadatos administrados (Managed Metadata Service) y básicamente proporciona una forma ágil y eficaz de definir taxonomías de datos jerárquicos definidos de forma global que pueden ser invocados y utilizados en múltiples contenidos del portal.

El servicio de Metadatos Administrados genera estructuras con 4 componentes básicos:
  1. Almacen de términos (Terms Stores): Es la raiz de la estructura de metadatos. Es un contenedor de Set Groups. Solo puede haber un Term Store por SA, pero muchos Set Groups en un Term Store. Contiene la configuración del idioma.
  2. Grupo de conjunto de términos (Term Set Group): Es un grupo de Term Sets, un Term Stores puede incluir muchos de ellos
  3. Conjunto de términos (Term Set): Es una colección de Terms organizados de forma jerárquica. Se pueden almacenar 30.000 términos por cada Term Set, y un máximo de 1.000 terms sets por Term Stores (creo que ninguno llegará a definir nunca tal estructura de metadatos)
  4. Término (Term): Es una palabra o frase que puede estar asociada con un objeto en SharePoint Server 2010. Se pueden combinar, borrar, dejar en "deprecated", traducir y mover. Puede incluir sinónimos, descripciones, traducciones y propiedades personalizadas. Puede haber un máximo de un millón de términos por cada Term Store.
De esta forma podemos crear estructuras como la que muestra la siguiente imagen:


Las ventajas de utilizar el Servicio de Metadatos Administrados son que podemos disponer de una mayor consistencia en el uso de la terminología empresarial, y unos resultados de búsqueda mejores debido a la capacidad de filtrar directamente por la propia estructura de metadatos.

Esta taxonomía de metadatos puede utilizarse en múltiples elementos del portal, como en los nuevos tipos de columna para las listas (columna de metadatos) donde forzamos al usuario a introducir uno de los términos de un conjunto de términos.

También se pueden utilizar para etiquetar (tags) elementos de nuestras listas, con la ventaja de tener una categorización unificada que además no es obligatoria pero sí puede ser común en todas las aplicaciones web y sites collections del portal.

Otro uso posible del servicio de metadatos administrados es que nuestras búsquedas podrán filtrarse por los términos que tengamos definidos.

Como veis, el servicio tiene múltiples aplicaciones y personalmente considero que muy útiles. de nuevo me viene el pensamiento "si hubiera tenido esto en el 2007..."

En el siguiente post veremos como el Servicio de Metadatos Administrados, además, ejerce de Hub para los Tipos de Contenido (Content Type Hub)
Además, en un tercer post de esta misma serie, veremos un ejemplo de cómo usar de forma práctica el Servicio de Metadatos Administrados.

Hasta entonces, ¡Un saludo!

domingo, 7 de febrero de 2010

MSS 2010: Proxy de servicio y grupos de proxys

Como ya comenté en un post anterior, en MSS 2010 el concepto de SSP ya no existe y ahora todo son Service Applications (SA). Cada Servicio (p.e. el de importación de usuarios) es un SA.

Profundizando algo más en esta nueva arquitectura, hay que saber que cada SA consta de:
  1. El servicio en sí mismo
  2. Un proxy de servicio
 ¿Qué es el proxy de servicio?  Conceptualmente podemos entenderlo como "un punto de enganche" entre el servicio y la aplicación web que lo incluye. La definición que da Microsoft es "un link virtual para conectar aplicaciones web al SA".

Un Proxy de Servicio se crea automáticamente cuando se crea un SA (nunca son creados de forma manual). Podemos verlos en la Administracion Central, y algunos de estos proxys tienen parámetros configurables que podemos administrar, como podeis ver en la siguiente imagen:

Por otra parte, también existe el concepto Grupo de Proxys. Un Grupo de Proxys es el conjunto de proxys de servicio que utiliza una aplicación web. Es decir, cada aplicación web va ligada a un grupo de proxys, que le proporciona toda una serie de servicios (puede ser uno, dos, tres o n servicios). Por defecto, todos los servicios que disponemos tras la instalación de SharePoint se incluyen en un "Default proxy group". Cuando nosotros generemos una nueva aplicación web, podremos escoger si engancharla al grupo de proxys por defecto, o crear un nuevo grupo de proxys personalizado para ella (donde escogeremos que servicios van incluidos).

Un proxy de servicio de un SA, puede estar vinculado a múltiples Grupos de Proxys, de forma que un único servicio puede ser compartido en múltiples aplicaciones web.

Esta arquitectura de servicios proporciona una gran flexibilidad en la plataforma, permitiendo tener aplicaciones web conectadas únicamente a aquellos servicios que va a utilizar, y reaprovechando servicios ya definidos y operativos en múltiples aplicaciones web.


Por ejemplo, si creamos una arquitectura de metadatos empresarial, esta podría estar presente en todas nuestras aplicaciones web, y por tanto, mediante una única definición, ser utilizada en cualquier site collection.

¿Que opinais? Mucho mejor que los inflexibles SSP, ¿No?

viernes, 5 de febrero de 2010

MSS 2010 y VS 2010: Entornos locales de desarrollo

En el caso que tengamos un portatil o PC con Windows 7 de 64 bits, y un hardware suficientemente potente para permitirlo, podremos instalar en él tanto SharePoint 2010 como Visual Studio 2010.

Esto vendrá genial para los desarrolladores que quieran desarrollar y debugar en sus máquinas locales sin necesidad de estar conectados a un Servidor SharePoint, y sin necesidad de arrancar máquinas virtuales que siempre consumen más recursos de nuestro ya de por sí justito terminal de trabajo.

Seguramente esto será una buena noticia también para los desarrolladores que el entorno de testeo suponia un problema en proyectos con únicamente entornos de Producción o Preproducción, aunque supongo que como siempre habrá defensores y retractores al respecto. Bien, simplemente una opción más a tener en cuenta.

jueves, 4 de febrero de 2010

MSS 2010: El concepto de Sandbox Solution.

Otra nueva característica de MSS 2010 es el concepto de "Sandbox Solution".

Hasta ahora, todas las soluciones de personalizaciones desarrolladas en Visual Studio con .NET se realizaban mediante librerías .dll, retoques en el web.config y más ficheros en la carpeta /12 (habitualmente los xml de definición del feature o webpart) de nuestros servidores front-end de la granja . A este tipo de desarrollos Microsoft les llama "Farm Solutions" o "Full Trust".

Por supuesto, este tipo de desarrollos sigue existiendo en 2010 (ahora el directorio es /14), pero además se añade una modalidad nueva de desarrollos llamada "Sandboxed solution".

Para comprender bien este concepto hay que considerar que ha sido creado con la finalidad facilitar servicios de Hosting a través de SharePoint (2010 hace mucho incapié en todos los conceptos de "cloud computing"), permitiendo securizar los desarrollos personalizados en entornos de host.

Una Sandbox Solution es un desarrollo que no se implanta con librerías .dll, ni configuraciones del web.config ni ningún fichero físico que deba ser instalado en los servidores WFE. Su implantación se realiza únicamente y directamente en Base de Datos SQL Server.

Con ello se consigue solucionar el problema de código personalizado en entornos de Hosting, facilitando enormemente la tarea de implementación y administración de las soluciones (el administrador ya no ha de aprobar el código y deployarlo). Además, mejora la estabilidad de los servidores al ser un código aislado con un proceso de trabajo que opera en un site collection específico (monitorizable, por supuesto).

 Hasta aquí todo perfecto, seguro que muchos pensais "si es más fácil de implantar, ¿Por qué no lo usamos siempre?". La respuesta es que a cambio de una implantación ágil en entornos host, las Sandboxes tienen muchas limitaciones a nivel de programación:
  • No pueden ejecutar procesos externos (como llamadas a webservices, http o conexiones externas de datos)
  • Están sujetas a limitaciones de quota (este es un tema curioso que trataré en un pos a parte)
  • Están limitados por Code Acces Security (CAS). CAS es un modelo de seguridad que otorga o deniega permisos en función de las propiedades de un assembly.
  • Solo se puede acceder a una parte limitada del Modelo de Objetos (OM) de .NET

La idea principal es securizar al máximo el entorno del servidor (host), a pesar de permitir ejecutar todo tipo código en el cliente.Detallando un poco más estas limitaciones:
  • No puede realizar Off-Box connections, http, webservices, etc.
  • No puede utilizar ADO.net
  • No puede invocar las Características Enterprise de MSS (Búsquedas, BCS, etc.)
  • No puede utilizar threading
  • No puede utilizar P-invoke
  • No puede realizar operaciones de entrada/salida
  • No puede comunicarse con otros sites collections
Como veis, el catálogo de restricciones es bastante considerable, sin embargo, antes de caer en "mi gozo en un pozo", también hay que saber que existen formas de saltarse algunas de ellas. Como comentamos antes, Microsoft quiere securizar el entorno del servidor, pero el del cliente es otro cantar, y con aplicaciones Ajax, Silverlight, JavaScrip... sí que podríamos realizar aplicaciones más completas con acceso a recursos del lado del cliente.

También se puede comunicar una Sandbox mediante un "Full-Trust Proxy"

Las Sandboxes pueden ser activadas o desactivadas como soluciones desde el panel de administración del site collection, y desde el panel de administración central podremos bloquearlas, monitorizarlas o establecer quotas.

Realmente es un concepto interesante que sin duda Microsoft utilizará para vender Hostings de Sharepoint y potenciar su "cloud computing". Veremos hasta que punto se puede utilizar en nuestras intranets...

MSS 2010: Por fin paquetes wsp completos

Sin duda una característica de MSS 2010 (recordad, ya no se llama MOSS) que vamos a apreciar muchísimo todos aquellos que hemos sufrido las múltiples epopeyas de los pasos a producción o despliegue de aplicaciones es que ahora MSS paquetiza el contenido de la plantilla de un site como un fichero .wsp (adiós a los .stp). Y no solo eso, sino que también incluye en ese paquete objetos como el propio site, las listas y bibliotecas que lo componen, los workflows y los formularios infopath que incluyen.

Estas plantillas de site se pueden crear desde el propio sharepoint en el menú de administración del site, o desde SharePoint Designer:


Una vez la plantilla esté creada nos informará mediante la siguiente pantalla


Si pulsamos en el vínculo que nos muestra la pantalla anterior (también se puede llegar por el menú natural de la administración del sitio), nos llevará a la pantalla de gestión de soluciones de usuario, donde veremos el .wsp con la plantilla del site que hemos generado. Si desplegamos el menú de opciones para la solución, la podemos activar.

A continuación nos mostrará una pantalla con más información específica de la solución (como su GUID) y volveremos a clickar en el botón "Activar" de la Ribbon.


Una vez activada la solución nos regresará a la pantalla de soluciones de usuario, donde podremos comprobar que nuestra solución está ahora en estado "activa"


A partir de aquí ya podemos crear sites con esta plantilla, mediante el menú de acciones de sitio--> Nuevo Sitio
y en la siguiente pantalla, veremos que nuestra plantilla está disponible para crear nuevos sites


Por supuesto, podemos bajarnos el fichero .wsp para desplegarlo en otros entornos o construir un autoejecutable.

Este es un cambio en el propio modelo de objetos de SharePoint, así que también se pueden crear este tipo de paquetes con Visual Studio 2010. Con VS 2008 podíamos paquetizar .wsp, pero solo incluía .dll, xml y modificaciones del web.config. Ahora podemos paquetizar sites enteros, con todos sus componentes...

¡¡Por fin un método claro, sencillo y preciso para hacer deployments!!

No mas MOSS 2010, se llama MSS 2010

En el curso de partners de hoy, entre muchas otras cosas, nos han informado de que en realidad la nueva version de sharepoint no se abrevia como MOSS (Microsoft Office SharePoint Server), sino como MSS (Microsoft SharePoint Server), ya que han quitado el "Office" de sus siglas. Ignoro si es por la broma popular de que SharePoint es un "subproducto" o los motivos del cambio.

También sabreis que la nueva versión del core gratuita ya no se llama WSS 4.0 (Windows Shared Services), sino SharePoint Foundation 2010.

Siempre hay que cambiar las siglas, para que parezca distinto... ;-p

miércoles, 3 de febrero de 2010

MOSS 2010: Algunas mejoras en la gestión de permisos

A pesar de que básicamente los permisos en SharePoint 2010 funcionan de la misma forma que en 2007, las funcionalidades se han repartido mejor por las diversas pantallas administrativas de forma que resulte menos lioso gestionarlos. Ribbon también aporta su ayuda al respecto en este apartado:


Además, si que existen un par de funcionalidades nueva que facilitaran la administración de los permisos en SharePoint. La primera de ellas se accede desde la misma pantalla de administración de "permisos del sitio", donde veremos que en la Ribbon hay una opción de "Comprobar permisos".

Esta opción nos sirve para ver de forma rápida qué permisos tiene un usuario o grupo dentro de un site, pero solo a nivel de site (no granula a listas o items). Esto nos evitará tener que entrar grupo por grupo para ver qué usuarios habían dentro de cada uno de ellos.


La otra opción nueva que agradecerán los administradores es que una vez seleccionado un grupo de permisos específico, veremos una nueva pantalla con los integrantes de ese grupo en concreto, y el Ribbon cambia de opciones, para mostrarnos en una de ellas el "Ver permisos del grupo"


Esto nos dirá de forma automática qué nivel de permisos tiene ese grupo a nivel de sitio, pero también granula a nivel de listas y bibliotecas (siempre que hayan roto la herencia y sus permisos disten de los del padre).
Esta funcionalidad está muy bien, pero tiene la limitación que solo aplica a grupos, lo cual es una lástima porque estaría realmente bien poder ver de un vistazo que permisos tiene un usuario a nivel de sitio, listas y bibliotecas.

Es un pequeño avance en la administración de permisos que seguro todos agradeceremos.

¡Saludos!