Lo nuevo de SharePoint Foundation 2010!!

Les paso un breve resumen de las novedades de SharePoint Foundation 2010, el sucesor de Windows SharePoint Services 3.0. Fuente: What's New in SharePoint Foundation 2010.

Cuando terminen de leerlo, van a querer instalarlo ya!

Business Connectivity Services  (ex BDC):

Como todos sabrán, en MOSS 2007 existe algo llamado Business Data Catalog que permite acceso de lectura a sistemas legados. Bien, BDC ha sufrido algunos cambios buenos:

1. Ahora se llama BCS
2. Ahora es lectura y escritura!
3. Ahora permite operaciones batch de múltiples registros.
4. Ahora puede trabajar con datos de tipo BLOB.
5. Lo más importante, ya no es exclusivo de MOSS, es parte de SharePoint Foundation (WSS)

Más información en What's New- Business Connectivity Services.

Modelo de objetos de Cliente:

SharePoint Foundation introduce tres API para cliente:

1. .Net Framework
2. Silverlight
3. ECMAScript (JavaScript, JScript)

Estas APIs permiten inter-operar con el servidor y son más sencillas que el uso de WebServices. Más información en What's New- Client Object Model:

Mejoras en eventos:

Algunas de las mejoras:

1. Evento On Create de listas
2. Eventos after sincrónicos!
3. Evento Add en sitios
4. Evento Add y Delete en listas

Más información en What's New- Events Improvements.

Mcirosoft Synch Framework

Es una arquitectura de sincronización global y unificada que permite a Microsoft y otras aplicaciones de terceros sincronizar más fácilmente con SharePoint 2010 Fundation. Más información en What's New- Microsoft Synch Framework.

Mejoras en el desarrollo para móviles

1. Las webparts pueden ahora adpatarse para móviles a través de mobile adapters.
2. Alertas SMS: Sí, leíste bien, ahora las alertas pueden convertirse en SMS y llegar a un celular.
3. Alrededor de 60 nuevos controles para móviles.

Más información en What's New- Mobile Device Development Enhancements.

Mejoras en consultas!!

1. Creo que todos saben que ahora existe LINQ to SharePoint Provider
2. Pero a eso agreguen la posibilidad de hacer join con CAML
3. Y a eso agreguen hacer consultas desde el modelo de objetos del cliente

Qué se elimina? En realidad se mantiene, pero se recomienda no usar:

• Web Services para acceder a datos
• Llamadas directas a owsscr.dll

Más información en: What's New- Query Enhancements.

Ribbon:

Básicamente es una nueva barra de herramientas. Una imagen vale más que mil palabras:

 

Más información en What's New- Ribbon.

Soluciones Standboxed

Permite a los usuarios subir código personalizado dentro del contexto de una colección de sitios.

Más información en What's New- Sandboxed Solutions.

Services Aplication Framework

Proporciona una plataforma que permite a los desarrolladores construir aplicaciones escalables. Ayuda a equilibrar la carga y gestión de los servicios de SharePoint. Proporciona más de 20 servicios que están integrados en el producto básico. Por ejemplo, la búsqueda de SharePoint es ejecutada por este framework.

Reemplaza al Service Application Framework Microsoft Office SharePoint Server 2007. Más información en What's New- Service Application Framework.

Silverlight & Fluid Application Model

Ahora se puede hostear una aplicación Silverlight dentro de una WebPart, de la misma manera que se pueden integrar aplicaciones externas dentro de una WebPart en forma segura. Para mayor información consultar What's New- Silverlight Integration and the Fluid Application Model.

Mejoras en la interfaz de usuario

Como ya se mencionó anteriormente, una de las mejoras es la Ribbon.

Otro cambio significativo es que ahora la master page es compartida por las applications pages y las sites pages. Esto no era así en WSS3 (consultar el artículo Master pages en SharePoint). Finalmente se renovaron las hojas de estilo, facilitando su personalización y performance. Más información en What's New- UI Improvements.

Windows PoweShell para SharePoint

Es una nueva herramienat de línea de comandos que soprota lenguaje de script que complementa CMD.EXE. Es el reemplazo de STSADM. Más información en What's New- Windows PowerShell for SharePoint.

Mejoras en flujos de trabajo

Entres las mejoras se pueden identificar:

1. Nuevas actividades.
2. Interacción con más eventos y posibilidad de crear nuestros propios manejadores de eventos.
3. Ahora los flujos de trabajo pueden depender de sitios, no sólo de listas.
4. Flujos de trabajo que pueden ser ejecutados con permisos elevados, no con los permisos del iniciador.
5. Se pueden reusar los flujos de trabajo y aplicar a varias listas.

Más información en What's New- Workflow Improvements.

 

Aquí termina. Consideren todo este material como “beta”. Acepto todo tipo de comentarios y aportes para ampliar estos temas, ya que todo es nuevo, hay poca información y pude haber cometido errores de interpretación.

Hasta la próxima!

Leer más...

Master pages en SharePoint

WSS 3 fue diseñado para trabajar con páginas maestras, lo que constituye un importante cambio respecto a WSS 2, y facilita enormemente la personalización de un sitio a través de distintas páginas. En esta artículo comentaré algunos puntos importantes a tener en cuenta a la hora de trabajar con este tema en SharePoint:

Introducción

Las páginas que están vinculadas a una página maestra se denominan content pages. Estas páginas comparten un diseño común, provisto por la página maestra. La página maestra contiene placeholders que pueden ser reemplazados por contenido único.
Un importante punto a tener en cuenta es que las páginas maestras que utilizan las application pages son distintas a las que utilizan las site pages. La mayoría de las application pages trabajan con la página maestra llamada application.master, que no puede ser personalizada. Si están buscando un método que afecte a los dos tipos de páginas, les recomiendo que lean el artículo Cambios de estilos en SharePoint.
Default.master es la página estándar  utilizada por por las site pages y pueden encontrarla en C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\GLOBAL\default.master. Cuando ustedes crean un nuevo sitio en SharePoint, se crea automáticamente la galería Master Page con una instancia de la default.master en /_catalogs/masterpage/default.master. A esta altura el lector ya habrá descubierto que las páginas maestras dentro de los sitios se comportan de la misma manera que las páginas de sitio y aplican los mismos conceptos. Por ejemplo, usted podría personalizar una página maestra desde SharePoint Designer y los cambios se almacenarían en la base de datos.
Qué podemos definir en una página maestra?

• Vínculos estándar que apliquen a todas las páginas
• Menús compartidos
• Iconos, gráficos, logos, etc.
• Componentes de navegación como el mapa del sitio
• Named Placeholders
• Delegate Controls

Named Placeholders

Como dijimos anteriormente, los named placeholders constituyen un mecanismo de extensibilidad permitiendo agregar contenido único en una página de sitio o plantilla de páhina que esté vinculada a una página maestra. El siguiente HTML es un pequeño extracto de una página maestra en SharePoint para “graficar” esta funcionalidad.

<HEAD runat="server">
<SharePoint:CssLink ID="CssLink1" runat="server"/>
<SharePoint:Theme ID="Theme1" runat="server"/>
<Title ID=onetidTitle>
      <asp:ContentPlaceHolder id=PlaceHolderPageTitle runat="server"/>
    </Title>
</HEAD>

CssLink y Theme existen también en application.master y ese es uno de los motivos por el cual afectan a ambos tipos de páginas, a diferencia de la personalización de la página maestra que estamos viendo en este momento.

Veamos ahora como se ve el named placeholder en una plantilla de página:

<%@ Page MasterPageFile="~masterurl/default.master" %>
<asp:Content ID="PageTitle" runat="server" ContentPlaceHolderID="PlaceHolderPageTitle"> Home de Surpoint
</asp:Content>

Controles de Navegación

Varios opciones de navegación pueden ser modificadas en las páginas maestras. Este tema está fuera del alcance de este artículo, pero a modo de ejemplo es bueno saber que puede alterarse mediante programación el funcionamiento de el menú lateral o superior en el evento de activación de una feature. Lo interesante de este punto es que mediante programación de pueden lograr resultados que no pueden alcanzarse con la funcionalidad OOTB (out of the box).

Delegate controls

Los controles delegados constituyen una potente funcionalidad de sharepoint que definen regiones dentro de las páginas maestras que pueden ser sustituidas para resolver algún requerimiento. Lo más interesante es que esto puede ser realizado sin necesidad de alterar la página maestra, ya que la operación se realiza a través de una feature. Para mayor información consultar el artículo Mi primer delegate control.

Personalizando default.master

Como dijimos anteriormente, esto es algo que puede hacerse mediante Sharepoint Designer. Si optamos por esa opción, sepamos que aplican las reglas de ghosting de las sites pages. En este artículo veremos como realizar estos cambios a través de Visual Studio. Esto abarca tres pasos:

1. Crear la plantilla de página maestra
2. Instanciarla
3. Redireccionar las páginas a nuestra nueva página maestra

Para crear la plantilla de página maestra, podemos hacer una copia de la default.master y modificarla o empezar desde cero. Recomiendo la primera.

Para instanciarla, usaremos una feature que incluya un elemento de módulo. Ejemplo:
<Module Name="MasterPages" List="116" Url="_catalogs/masterpage">
<File Url="Surpoint.master" Type="GhostableInLibrary" />
</Module>

Algunas observaciones:

• 116 identifica la galería de páginas maestras
• GhostableInLibrary significa que la página maestra se instanciará en una librería de páginas maestras

El último paso es redireccionar las páginas de sitio a la nueva página maestra. Afortunadamente esto se puede realizar en forma sencilla programáticamente en un evento de activación de feature.:

SPWeb sitio= SPContext.Current.Web;
string PathPagMaestra = sitio.ServerRelativeUrl;
if (!PathPagMaestra.EndsWith(@"/")) PathPagMaestra+= @"/";
PathPagMaestra+= @"_catalogs/masterpage/Surpoint.master";
sitio.MasterUrl = PathPagMaestra;
sitio.Update();

Algunas observaciones más:

• El ámbito de las páginas maestras es sitio (no colección de sitios).
• Ademas de MasterUrl existe CustomMasterUrl. Esto permite tener una segunda página maestra e intercambiarlas programáticamente.

Hasta aquí este artículo introductorio. Pueden encontrar información adcional en Automated SharePoint Site Branding.

Como siempre, espero que les sea útil. Hasta la próxima!

Leer más...

70-541 – Crear una Definición de Sitio

Continuando con los apuntes que fuimos armando para la certificación, veamos qué es y cómo se crea una Definición de Sitio.

Una definición de sitio define un tipo único de sitio de SharePoint. Una definición de sitio puede incluir más de una configuración de definición de sitio. ¿Qué significa esto? Que a partir de una única definición de sitio, podremos crear distintos tipos de sitios. Los sitios Web de SharePoint se basan en configuraciones de definición de sitio determinadas.

Básicamente, una definición de sitio está compuesto por los siguientes archivos:

• WebTemp.xml – Se ubica en \TEMPLATE\<LENGUAJE>\XML y en él se identifican las definiciones de sitio y proporciona información sobre cómo aparecerán sus configuraciones en la sección Selección de plantilla de la página Nuevo sitio de SharePoint. Si va a crear una definición de sitio personalizada, no edite el archivo WebTemp.xml original. En su lugar, cree un archivo personalizado denominado WebTemp*.XML. Esto simplifica la instalación y desinstalación de definiciones de sitio, ya que su contenido no necesita combinarse en un archivo WebTemp.xml.
• Onet.xml – Se ubica en \TEMPLATE\SITEDEFINITION\<TIPO DE SITIO>\XML y en él se define las áreas de exploración, especifica las definiciones de lista disponibles en la página Crear, especifica las plantillas de documento y sus archivos, define los tipos base para las listas y define las configuraciones y los módulos para las definiciones de sitio. Más adelante, en este mismo artículo explicaremos en más detalle el contenido de este archivo.
• Schema.xml – Se ubica en \TEMPLATE\FEATURES\<LISTA DEFINICION> Define las vistas, los formularios, la barra de herramientas y los campos especiales en una definición de lista. Cada definición tiene su propio archivo Schema.xml.

La definición de un nuevo sitio, se hace modificando estos tres archivos, los cuales puede hacerse copiando una definición de sitio existente y luego modificar la copia (no es recomendable modificar una definición de sitio standard) o creándolos desde cero. 

Onet.xml

A partir del archivoarchivo Onet.xml, se pueden hacer las siguientes definiciones:

• Áreas de exploración superior y lateral que aparecen en la página principal y en las vistas de lista para una definición de sitio
• Especificar las definiciones de lista que se usan en cada definición de sitio y si están disponibles para crear listas en la página Crear.
• Especificar plantillas de documento que están disponibles en la definición de sitio para crear listas de la biblioteca de documentos en la página Nuevo, y especificar los archivos que se usan en las plantillas de documento.
• Definir los tipos de listas base de los que se derivan las listas predeterminadas de Windows SharePoint Services.
• Especificar las configuraciones de las listas y módulos que se usan dentro de cada definición de sitio.
• Especificar los componentes de Windows SharePoint Services.
• Definir la sección de pie de página usada en el correo electrónico de servidor.

La estructura de este archivo va en dependencia a la definición del sitio que se crea y sus distintas configuraciones, siendo los siguientes elementos comunes a todas las definiciones:

• Elemento Project: especifica un nombre predeterminado para los sitios que se crean mediante cualquiera de las configuraciones de sitios en la definición de sitio y especifica el directorio que contiene las subcarpetas en las que residen los archivos para cada definición de lista.
• Elemento NavBars: contiene las definiciones para el área de exploración superior que se muestra en la página principal o en las vistas de lista, y las definiciones para el área de exploración lateral que se muestra en la página principal.
  • NavBar ID="1002" – Corresponde a la barra superior.
  • NavBar ID="1004" – Corresponde a la barra lateral.
• Elemento ListTemplates: especifica las definiciones de lista que forman parte de una definición de sitio.
• Cada elemento ListTemplate especifica un nombre interno que identifica la definición de lista. El elemento ListTemplate también especifica un nombre para mostrar para la definición de lista y si la opción para agregar un vínculo en la barra Inicio rápido aparece seleccionada de forma predeterminada en la página Nuevo. Además, este elemento especifica la descripción de definición de lista y la ruta de acceso a la imagen que representa la definición de lista, las cuales se muestran en la página Crear. Si se especifica Hidden="TRUE", la definición de lista no aparece como una opción en la página Crear.
• Elemento DocumentTemplates: define las plantillas de documento que se enumeran en la página Nuevo.
• Elemento Configurations: Cada elemento Configuration en la sección Configurations especifica las listas y módulos que se crean de forma predeterminada cuando se crean instancias de la configuración de definición del sitio. Para mas detalle, ver http://surpoint.blogspot.com/2009/10/70-541-especificar-la-configuracion-de.html.
• Elemento Modules: La colección Modules especifica los módulos para incluir de forma predeterminada al crear una colección de sitios. Cada elemento Module a su vez especifica uno o más archivos que se van a incluir, normalmente para los elementos web, que se almacenan en la memoria caché en el servidor cliente web, junto con los archivos de esquema. Para más detalle, ver http://surpoint.blogspot.com/2009/10/70-541-creacion-de-modulos-en-una.html.
• Elemento Components: El elemento Components especifica componentes para incluir en los sitios creados mediante la definición.
• Elemento ServerEmailFooter: El elemento ServerEmailFooter especifica la sección de pie de página usada en el correo electrónico enviado desde el servidor.

Nos vemos en la próxima entrega.

Leer más...

Crear un una plantilla de páginas con zonas de elementos web programáticamente

Breve post para explicar como crear un template de página con múltiples webparts zones e instanciarla. Los templates de páginas son los que ven cuándo elijen crear una página de elementos web desde el navegador.

Paso 1: Crear el template de página

Para crear la plantilla debemos construir una página ASPX que herede de Microsoft.SharePoint.WebPartPages.WebPartPage. Está página debe almacenarse en la carpeta \TEMPLATES\CONTROLTEMPLATES\. Un ejemplo sencillo de plantilla sería:

<asp:Content ID="main" runat="server" ContentPlaceHolderID="PlaceHolderMain" >

<table width="100%"> <tr>

<td valign="top" style="width:50%"> <WebPartPages:WebPartZone ID="LeftZone" runat="server" FrameType="TitleBarOnly" Title="Left Web Part zone" /> </td>

<td valign="top" style="width:50%"> <WebPartPages:WebPartZone ID="RightZone" runat="server" FrameType="TitleBarOnly" Title="Right Web Part zone" /> </td>

</tr> </table>

</asp:Content>

Paso 2: Instanciar la página

Por supuesto podemos instanciar la página desde el navegador. Nos aparecerá una página cómo la que se muestra en la imagen en la que podemos agregar nuestras webparts:

Existen dos maneras de hacerlo programáticamente, a través de un módulo o a través de la API de SharePoint.

a) Módulo

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

<Module Path="PageTemplates" Url="SitePages" >

<File Url="PlantillaSurPoint.aspx" Name="InstanciaSurPoint.aspx" Type="Ghostable" >

<AllUsersWebPart WebPartZoneID="LeftZone" WebPartOrder="0">

<![CDATA[ <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2" xmlns:iwp="http://schemas.microsoft.com/WebPart/v2/Image"> <Assembly>Microsoft.SharePoint, ...</Assembly> <TypeName>Microsoft.SharePoint.WebPartPages.ImageWebPart</TypeName> <FrameType>None</FrameType> <Title>Mi elemento web</Title> <iwp:ImageLink>https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAse6LsweeswAhy8jxIFE5sEN-jIP1IVGzj6P55_DKeDbWUTCcrhZLJE6dv2vl20SCAn07a1BeHBNk3WCqgw6vYofpLfr2tZBW7Mg8q0MX1TFnempFpCSq7o-IuNa1Ir_7lMjq4ZOHj00L/s1600-r/surpoint.png</iwp:ImageLink> </WebPart> ]]>

</AllUsersWebPart> </File>

</Module> </Elements>

b) API

SPWeb sitio = SPContext.Current.Web;           

SPFile pagina = sitio.GetFile("SitePages/InstanciaSurPoint.aspx");

SPLimitedWebPartManager Manejador;

Manejador = pagina.GetLimitedWebPartManager(PersonalizationScope.Shared);

ImageWebPart elemento = new ImageWebPart();

elemento.ChromeType = PartChromeType.None;

elemento.ImageLink = @"https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAse6LsweeswAhy8jxIFE5sEN-jIP1IVGzj6P55_DKeDbWUTCcrhZLJE6dv2vl20SCAn07a1BeHBNk3WCqgw6vYofpLfr2tZBW7Mg8q0MX1TFnempFpCSq7o-IuNa1Ir_7lMjq4ZOHj00L/s1600-r/surpoint.png";

Manejador.AddWebPart(elemento, "RightZone", 0);

Hasta la próxima…

Leer más...

70-541 Especificar la configuración de listas y módulos en una definición de sitio.

Otra de las secciones presentes en el archivo de definición de sitio Onet.xml, es la sección Configuration.

Básicamente lo que nos permite esta sección es poder reutilizar un mismo archivo de definición de sitio para poder generar distintos sitios. Sin esta sección, si tenemos dos sitios que se diferencien entre si porque uno tiene dos listas adicionales pero comparten las 10 listas restantes deberíamos armar dos definiciones de sitio uno con 10 listas y otro con 12. Con esta sección, definimos un sólo site definition e indicamos en la configuración el tipo de sitio a crear y que listas toma uno u otro.

Ahora bien, ¿qué es lo que contiene esta sección?

En el archivo Onet.xml, cada configuración de definición de sitio define un tipo específico de sitio que se puede crear a partir de la definición de sitio. Todas las configuraciones dentro de este archivo comparten un conjunto de definiciones de lista, plantillas de documento, áreas de exploración, tipos de lista base y módulos disponibles que se definen dentro del archivo.

Los principales atributos de esta sección son los siguientes:

• ID: Obligatorio – Especifica un identificador único para la configuración.
• Name: Opcional – Nombre con que se va a mostrar en la selección de plantilla.
• RootWebOnly: Opcional – Especifica si esta plantilla va a estar disponible solamente para crear sitio de primer nivel (no subsitios).
• SubWebOnly: Opcional - Especifica si esta plantilla va a estar disponible solamente para crear subsitios (no sitio de primer nivel).

Dentro de la sección Configuration, se pueden especificar las siguientes secciones (que iremos explicando en otros artículos en este mismo blog):

• ExecuteURL
• Lists
• Modules
• SiteFeatures
• WebFeatures

Hasta una próxima entrega.

Leer más...

70-541 – Creación de Módulos en una Definición de Sitios

La definición de Modules y su contenido se realiza dentro de la sección Modules del archivo de definición de sitio Onet.xml

La colección Modules especifica los módulos para incluir de forma predeterminada al crear una colección de sitios.

Cada elemento Module a su vez especifica un archivo o colección de archivos y una ubicación en la que se instalan los archivos durante la creación del sitio. Si el archivo es una página de elementos web, la definición del módulo puede especificar los elementos web que deben incluirse en la página.

Cada elemento File, especifica un archivo a aprovisionar, los principales atributos de este elemento son los siguientes:

• URL: especifica el nombre de un archivo para crear cuando se crea el sitio. Si no se especifican los atributos Name y Path, URL indica tanto el archivo físico dentro del template como el archivo virtual.
• NavBarHome: especifica si el archivo actuará o no como la página destino para el vínculo Home en la barra de navegación.
• Type: especifica si el archivo se almacena en la memoria caché del servidor y el modo de almacenamiento. Si el archivo se agrega a una biblioteca de documentos, se deberá especificar Type="GhostableInLibrary", en cambio si el archivo no se encuentra en una biblioteca de documentos se deberá colocar Type="Ghostable".

Dentro de cada elemento File, se puede especificar el elemento NavBarPage en donde se va a indicar la posición de la página respecto al área de exploración superior de una página, para que pueda ser accedida. Si lo que se quiere es que esta página aparezca en la parte superior del área de exploración, se debe especificar el atributo Position=”Start”, si quiere se que sea el último valor, se debe especificar Position=”End”, caso contrario se puede especificar un número de secuencia.

Leer más...

Plataforma de desarrollo de SharePoint 2010

Antes de ayer, Microsoft publicó un paper sobre SharePoint 2010: Developer Platform White Paper. Decidí leerlo para enterarme de las novedades de la versión 2010, pero afortunadamente me encontré con algo mucho más interesante: una excelente publicación acerca de SharePoint como plataforma de desarrollo. Aquí les dejo un resumen.

¿A quién esta dirigido este post?

1. Desarrolladores SharePoint: para que vean las novedades de la versión 2010, pero fundamentalmente para repasar y asimilar los conceptos de programación sobre la plataforma SharePoint.
2. Desarrolladores ASP.Net: porque SharePoint es una plataforma de desarrollo que no puede desconocerse. Microsoft está haciendo una apuesta muy fuerte y por lo tanto es importante conocerla y entender para qué sirve y para qué no sirve.
3. Interesados en SharePoint: analistas, testers, líderes de proyectos y clientes que quieran entender de qué hablamos cuando decimos que Sharepoint es hoy una potente plataforma de desarrollo.

Qué es SharePoint?

Lo primero que hay que saber desde el punto de vista de desarrollo, es que existen dos componentes:

Microsoft SharePoint Foundation 2010: es la base de todo lo demás en SharePoint, el sucesor de Windows SharePoint Services 3.0. Contiene los servicios básicos que utilizan los desarrolladores para crear aplicaciones sobre esta plataforma, y está disponible como descarga gratuita para Windows Server 2008.

Microsoft SharePoint Server 2010: el sucesor de Microsoft Office SharePoint Server (MOSS) 2007, este producto contiene tecnologías como la gestión de contenido empresarial, búsqueda empresarial, y apoyo para la utilización de formularios de InfoPath. Si bien se basa en gran parte SharePoint Foundation 2010, es un producto independiente con su propio esquema de licenciamiento.

SharePoint Online: ofrecido por Microsoft, permite a los usuarios y a los desarrolladores utilizar la funcionalidad de SharePoint sin necesidad de instalar ningún software.

La siguiente imagen muestra cómo SharePoint agrega valor a los desarrolladores:

Utilizar SharePoint como Framework le permite al desarrollador centrarse más en la creación de la lógica de negocio que agrega valor a la aplicación y menos en la construcción de infraestructuras.

Microsoft SharePoint Foundation 2010 (el nuevo WSS)

Los servicios que SharePoint Foundation 2010 proporciona a los desarrolladores pueden agruparse en cuatro categorías: datos, lógica de negocio, interfaz de usuario y control de acceso.

Datos

Si bien SharePoint está basado en SQL Server, no maneja tablas relacionales. Los datos se representan con un mayor nivel de abstracción: la lista. Para los usuarios finales, las listas son fáciles de entender y fácil de usar. Hay tres formas en que las que SharePoint trabaja con datos:

• Listas
• Listas externas: permiten leer y escribir distintos tipos de datos almacenados fuera de SharePoint como si fueran una lista nativa de SharePoint.
• ADO.NET: para el acceso a bases de datos relacionales fuera de una granja de SharePoint.

Para acceder a las listas, se puede utilizar el modelo de objetos de SharePoint, que proporciona formas específicas para consultar y modificar datos de un lista, o LINQ to SharePoint (novedad de la versión 2010), una versión de LINQ diseñada para ser utilizada con las listas de SharePoint.

Sin embargo, el acceso a las listas externas requieren el uso de CAML. CAML no es especialmente difícil, pero es otro lenguaje para los desarrolladores a aprender. Los datos de las listas no se exponen como estándar de tablas relacionales, lo que no facilita la integración entre SharePoint y  tecnologías como SQL Reporting Services.

Una lista externa se basa en una tecnología de SharePoint Foundation 2010  llamada Business Connectivity Services (BCS). BCS puede utilizar los servicios Web, ADO.NET, o código personalizado para acceder a fuentes de datos externas, presentándola como una lista externa. Los usuarios de SharePoint y las aplicaciones son libres de leer y escribir estos datos al igual que con las listas ordinarias. Business Connectivity Services es la evolución de Business Data Catalog (BDC), tecnología disponible en Microsoft Office SharePoint Server 2007 (no en WSS 3.0). Buena noticia para el mundo WSS. Aún más, ahora se trata de una tecnología de lectura-escritura (antes sólo lectura).

Las listas de SharePoint se puede acceder desde el exterior a través de SOAP. Para facilitar esto, Microsoft también proporciona bibliotecas de cliente de JavaScript, Silverlight y el. NET Framework. El punto clave es que los datos almacenados en una granja de SharePoint pueden ser accedidos por otro software y no únicamente para las aplicaciones de SharePoint.

Lógica de negocio

El siguiente gráfico muestra las distintas formas de implementar lógica de negocio en SharePoint:

Entre las distintas opciones que ofrece SharePoint para implementar lógica de negocios encontramos:

1. Páginas ASPX.
2. Webparts.
3. Web services
4. Windows Communication Foundation
5. Workflows (comentado más abajo)
6. Eventos (algo parecido a triggers de una base de datos)
7. Times Jobs

Cada uno de estos temas merece un post. Bajaré un poco más a detalle en el tema Workflow, porque (a mi criterio) es donde SharePoint marca la diferencia:

Un desarrollador puede aplicar lógica de negocio de una aplicación de SharePoint a través de un flujo de trabajo con Windows Workflow Foundation (WF) 3.5. Por sí mismo, WF sólo proporciona los fundamentos necesarios para crear flujos de trabajo. SharePoint Foundation 2010 llena los vacíos, ofreciendo herramientas para crear flujos de trabajo (SharePoint Designer y Visual Studio), una forma para que las personas interactúen con un flujo de trabajo en funcionamiento a través de las lista de tareas, persistencia, y más. La construcción de una aplicación de flujo de trabajo con SharePoint Foundation 2010 es mucho más sencilla que si utilizáramos sólo WF.

Interfaz de usuario

SharePoint presenta distintos elementos para trabajar la interfaz de usuario. Quizá el más potente está dado por las Web Parts. Una Web Part encapsula lógica detrás de un elemento de la interfaz de usuario. Cada Web Part puede exponer una serie de acciones. Asimismo disponemos de la capacidad de mostrar o mover el elemento Web a una nueva ubicación en la pantalla. Esto permite al usuario personalizar la página que ve, la reorganización y la configuración de elementos Web que desee. Esta flexibilidad hace que sea más fácil para los desarrolladores crear una aplicación que los usuarios puedan personalizar.

SharePoint Foundation 2010 incluye algunas mejoras en la interfaz de usuario respecto a su predecesor. Por un lado, ahora hay soporte para una amplia gama de navegadores Web. Igual de importante, ahora es posible desplegar una aplicación Silverlight en un elemento Web de SharePoint.

Control de acceso

En lugar de recrear la rueda, SharePoint Foundation 2010 se basa en IIS para autenticación.

En aplicaciones que utilicen listas, SharePoint puede hacer mucho más simple autorización. Una vez más, el objetivo es permitir a los desarrolladores centrar sus esfuerzos en las necesidades de negocio en lugar de en la escritura de código de infraestructura.

El Entorno de Ejecución de SharePoint 2010

Las organizaciones que utilizan Sharepoint ya poseen administradores capacitados: saben cómo agregar servidores, realizar copias de seguridad, instalar aplicaciones y mucho más. Gracias a esto  la vida de un desarrollador puede ser más simple.

Sin embargo,  una solución instalada directamente en los servidores de la granja puede afectar a toda la granja, perjudicar el rendimiento o desestabilizar el conjunto de servidores de SharePoint. Esto hace que los administradores establezcan ciertas restricciones.

Esta fue una preocupación con la versión anterior de SharePoint. La respuesta a este problema tiene nombre: sandboxing. Una solución puede ser instalada por un administrador de colección de sitios y ser accesible sólo a los sitios en esa colección. El código de la solución se instala en la base de datos de contenido, junto con las personalizaciones de usuario y otra información, tal como se muestra en el gráfico:

Con la versión 2010 de SharePoint Online los clientes también pueden cargar y ejecutar una aplicación con standboxing.

Herramientas de desarrollo de SharePoint

Son las mismas que antes, pero mejoradas: Visual Studio 2010 y SharePoint Designer 2010:

Algunas novedades:

• Server Explorer para listas de SharePoint en Visual Studio
• Asistentes para crear eventos entre otros.
• Posibilidad de importar desde Visual Studio un flujo de trabajo creado con SharePoint Designer.

Microsoft se propuso que el desarrollo en SharePoint sea de primera clase en Visual Studio 2010. Esta nueva perspectiva es lo que subyace a los cambios significativos en Visual Studio 2010. Motivó otros cambios, tales como la capacidad de los desarrolladores de la instalación del entorno de SharePoint en versiones de 64 bits de Windows 7 y Windows Vista.

Microsoft Office SharePoint Server 2010

Al igual que antes SharePoint Server trae un conjunto de funcionalidades out-of-the-box como ECM, Search, BI, etc. Hay algunas novedades respecto a la construcción de redes sociales, pero no es propósito de este artículo ahondar en estos detalles.

Desde el punto de vista de un desarrollador la decisión entre usar SharePoint Foundation o SharePoint Server debe basarse en el balanceo entre “pagar” o “construir”.

Concluyendo…

A pesar de que la plataforma de SharePoint debe mucho a ASP.NET y .NET Framework, no es la misma cosa. Aprender a utilizar esta plataforma bien, es esencial para crear aplicaciones efectivas de SharePoint. Incluso un desarrollador ASP.NET altamente calificado deben tomar en serio esta transición.

Cada plataforma de aplicación tiene su punto fuerte, los tipos de aplicación para la que mejor se adapta. Para SharePoint, los tipos de destino de aplicación incluyen los siguientes:

• Aplicaciones colaborativas
• Portales que acceden a aplicaciones legadas
• Aplicaciones de WebPart
• Aplicaciones que aprovechan las características de SharePoint Server
• Sitios webs corporativos públicos

También es importante entender el tipo de aplicaciones que no son para esta plataforma. Un sistema de alto volumen de transacciones no es buena idea para esta plataforma, especialmente si los datos se almacenan en las listas de SharePoint (no diseñadas para este tipo de carga). Del mismo modo, no debe utilizarse SharePoint para aplicaciones intensivas en cuanto al uso de datos, tales como procesos por lotes o software de procesamiento en paralelo. SharePoint tampoco suele ser la plataforma adecuada para la integración de aplicaciones. Un proyecto de integración de Microsoft debe basarse en BizTalk Server.

Construir una aplicación en SharePoint limita el mercado a los clientes que utilizan SharePoint. Si la aplicación sólo utiliza SharePoint Foundation, esto no parece un problema. Fundation es una descarga gratuita para Windows Server. Sobre la base de Microsoft SharePoint Server limita un poco más, ya que ahora los clientes de la aplicación también deben obtener la licencia de este producto de Microsoft.

Sin embargo, las ventajas de construir sobre SharePoint, como el tiempo de desarrollo más rápido y un entorno de ejecución estándar, podría superar estas limitaciones.

Si su organización planea construir una serie de aplicaciones Web, entender lo que la plataforma de SharePoint tiene que ofrecer vale la pena. Al proporcionar un entorno común con elementos reutilizables para interfaces de usuario, control de acceso y otras funciones típicas, SharePoint hace  que estas aplicaciones se construyan más rápido, sean más fáciles de mantener y más atractivas para sus usuarios.

¿Al final del día, no son estas las cosas que todos los desarrolladores buscan?

Agradecimiento

Un especial agradecimiento a David Chappell por haber escrito este paper tan esclarecedor.

Hasta la próxima…

Leer más...

SharePoint en el celular - Personalizando los campos de las vistas

Este es un muy breve blog para explorar una de las características de Sharepoint en cuanto al desarrollo en la plataforma móvil. En líneas generales es importante saber que Sharepoint está prepaprado para operar dentro de un móvil agregando simplemente una "/m" a la URL.
Sí, es automático:



Una vista de tipo móvil es una vista dentro de Sharepoint que está "marcada" para poder operar en un equipo móvil. Esto puede realizarse desde la misma interfaz para personalizar una vista. Si entran a una vista verán las siguientes opciones en la sección móvil:

Estos dos atributos permiten indicar si la vista es móvil y si es la vista móvil predeterminada. Esto puede ser especificado programáticamente en el CAML del elemento view de la siguiente manera:


<View BaseViewID="1" Type="HTML" WebPartZoneID="Main" DisplayName="$Resources:core,camlid4;" DefaultView="TRUE" MobileView="True" MobileDefaultView="True" Url="AllItems.aspx">


A partir de acá ya es terreno conocido. Para elegir que campos mostrar programáticamente se trabaja de la misma manera que en vistas comunes, con el elemento View.


Les dejo algunos links para ampliar el tema:
- MSDN: Introducción al desarrollo móvil (wss)
- MSDN: Vistás móviles (wss)


Hasta la próxima...

Leer más...

Documentación de SharePoint 2010 disponible para desarrolladores!

Gente, está empezando a llegar la documentación para desarrolladores de SharePoint 2010. Aquí van algunos links interesantes:

SharePoint 2010: Developer Platform White Paper

SharePoint 2010: SharePoint Developer Platform Wall Poster

SharePoint 2010: Getting Started with Development on SharePoint 2010 Hands-on Labs in C# and Visual Basic

SharePoint 2010: Professional Developer Evaluation Guide and Walkthroughs

Un dato más, en noviembre tendremos la beta de Sharepoint 2010!

Leer más...

Introducción a características (features) de Sharepoint – Parte 2

Este es el artículo número dos de la serie. Pueden consultar la primera parte en este link. Luego de haber analizado los usos más comunes de las features de sharepoint, vamos a ver tres temas que tienen que ver con despliegue de características:

Dependencia de features

Este es un concepto sencillo y permite que al activar una feature, se activen en forma automática las features que dependen de esta:

<Feature

Id=""
Title="Feature Activation Dependencies"
Description="Specify a feature that depends on another feature to activate"
Version="1.0.0.0"
Hidden="false"
Scope="Web"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ActivationDependencies>
<ActivationDependency
FeatureId=""/>
</ActivationDependencies>
</Feature>

Existen algunas reglas de aplicación. A modo de ejemplo no se permite la activación dependiente entre características de ámbitos (scope) distintos, las dependencias sólo pueden ser de un nivel y las características ocultas no pueden tener dependencias. Más información en MSDN: Ámbito y dependencias de activación y MSDN: Elemento ActivationDependencies.

Asociación de features (Stapling)

Esta técnica permite asociar features a definiciones de sitios. La principal ventaja radica en evitar crear una definición de sitio (tema algo complejo). Por el contrario lo que se hace es extender los sitios pre-existentes a través de features. Veamos un ejemplo:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <FeatureSiteTemplateAssociation

Id=""
TemplateName="STS#0" />
</Elements>

En el ejemplo, estamos asociando la feature a la definición de sitio STS y dentro de ese a la plantilla de sitio (o configuración) Team Site (#0). Si se desea asociar la feature en forma global, incluyendo Sharepoint Central Administrator, corresponde usar TemplateName="GLOBAL#0". Más información en MSDN: Asociación de características.

Localización de características

A través de un archivo de recursos se puede trabajar con la localización de aplicaciones para distintos lenguajes. Para ello es necesario construir un archivo de recursos, por ejemplo: Resources.en-US.resx (tener en cuenta que el lenguaje default se encuentra en resources.resx)

<root>

<resheader name="resmimetype">
<value>text/microsoft-resx</value>
</resheader>
<resheader name="version">
<value>2.0</value>
</resheader>
<resheader name="reader">
<value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
</resheader>
<resheader name="writer">
<value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
</resheader>
<data name="Holamundo" xml:space="preserve">
<value>Hi world</value>
</data>
</root>

Ahora, imaginemos que queremos localizar el título y descripción de una feature:

<Feature
Title="$Resources:HolaMundo"
Id=""
</Feature>

Para información más detallada consultar:

• http://www.baktek-web.com/en/topics/Localizing%20features%20with%20resources%20files.aspx
• http://blog.myitechnology.com/2009/06/localization-of-sharepoint-project.html
• http://tomblog.insomniacminds.com/2008/02/25/sharepoint-internals-resources/
  

Hasta la próxima…

Leer más...

Features, Plantillas, Definiciones de Sitio y Soluciones en Sharepoint – Parte 1

En estos artículos, voy a explicar brevemente las características de cada una de las opciones que provee Sharepoint para el desarrollo y distribución de funcionalidad por nosotros creados, y poder así identificar cuál de estos métodos utilizar para nuestros desarrollos.

Primero veamos Features y Plantillas.

Features

Una Feature permite al desarrollador resolver una necesidad de negocio agregando contenido de Sharepoint, como ser plantillas de páginas, listas, tipos de contenidos, Web parts, flujos de trabajos (WorkFlow) y eventos. Generalmente las Features se utilizan para resolver problemas comunes que puedan ser utilizados en varios sitios.

Las Features pueden ser instaladas y activadas en uno o varios sitios; cuando ésta es activada, las listas y los tipos de contenidos son creados en el sitio y se deja disponible toda la funcionalidad asociada. Para dejar de utilizar la Feature solo hay que proceder a desactivarla.

Los beneficios de desarrollar Features pasan porque no se deben desarrollar la totalidad del sitio con la complejidad que requieren las Definiciones de Sitio (que veremos más adelante), en lugar de esto se pueden desarrollar muchas pequeñas Features que se irán activando o desactivando de acuerdo a la necesidad de negocio que se quiera resolver, lo que facilita su reutilización en otros sitios.

Elementos que se pueden crear con Features:

• Páginas de Sitio
  
• Páginas de Aplicaciones
  
• Web Parts
  
• Listas
  
• Vistas
  
• Columnas de Sitio
  
• Tipos de Contenidos
  
• Eventos
  
• Flujos de Trabajo
  
• Código Personalizado
  

Tips y Consideraciones:

• Crear su propia funcionalidad en Features.
  
• Cree muchas pequeñas Features.
  
• Piense en la reusabilidad
  
• Desarrolle las Features en una solución para poder distribuirlo.
  

Plantilla de Sitio

Mediante las plantillas de sitio es fácil para el administrador de sitios de Sharepoint, crear nuevos sitios basados en una plantilla. La plantilla puede contener mucho contenido de Sharepoint, como ser listas, páginas, menúes y Features. Esta plantilla es fácil de crear incluso desde el front-end de Sharepoint, o por medio de Sharepoint Designer o incluso puede ser desarrollado por un desarrollador.

Existen muchas plantillas que se pueden descargar de la Web y ser utilizados en nuestros sitios.

Tips y Consideraciones:

• Facilidad de creación y distribución.
  
• Son creadas en la base de contenido.
  
• Las Features deben existir previamente en el servidor en que se quiera instalar.
  
• NO se pueden crear páginas de aplicación o páginas de sitio con código (para esto deberíamos utilizar las features).
  

Plantillas

Una plantilla es exactamente lo miso que una Plantilla de Sitio, pero a modo más atómico. Se pueden crear plantillas específicas para una lista y, cómo en el caso de las plantillas de sitios, se pueden generar fácilmente desde el front-end de sharepoint. Una vez creado, éste puede ser importado a nuevos sitios.

Elementos que se pueden crear con Plantillas:

• Páginas de Sitio
  
• Listas
  
• Vistas
  
• Columnas de Sitio
  
• Tipos de Contenidos
  
• Código Personalizado
  
• Opciones de Navegación
  

Tips y Consideraciones:

• Facilidad de creación y distribución.
  

Leer más...

WSS 3.0 no permite subir documentos con tamaño superior a 50 MB

Por defecto, la instalación de WSS 3.0 solo permite subir documentos con un tamaño de hasta 50 MB. En caso que nuestras listas de documentos requieran mayor o se quiera restringir a un tamaño menor, esto se puede realizar desde el Administración Central de Sharepoint.

Dentro del administrador, posicionarse en la pestaña "Administración de aplicaciones" e ingresar a la opción "Configuración general de la aplicación Web", dentro de la sección "Administración de aplicaciones Web de SharePoint".

En dicha pantalla, modificar el valor del campo "Tamaño máximo de carga", indicando el tamaño máximo de subida y guardar los cambios. En nuestro caso no fue necesario reiniciar el IIS del servidor Web.

NOTA: el tamaño máximo de carga aplica tanto si se quiere subir un único documento como si se quieren subir varios documentos a la librería, tomando como tamaño sobre el cual validar la suma de tamaño de todos los documentos. Para este segundo caso, ninguno de los documentos se guarda en la base.

Espero les haya sido de ayuda.

Saludos, Sebastián.-

Leer más...

Introducción a características (features) de Sharepoint – Parte 1

La feature es una funcionalidad de WSS 3.0 orientada al desarrollador. Permite definir elementos de sitio y agregarlos al sitio a través del proceso denominado "activación". ¿Qué tipos de elementos permite definir? Comandos de menú, plantillas de páginas, instancias de páginas, definiciones de listas, eventos, workflows entre otros.

Para crear una feature se necesita crear un archivo XML denominado "feature.xml":

Feature.xml

<Feature

Id=""
Title="Mi primera feature"
Description="Esta es la primera feature que desarrollo"
Scope="Web"
Hidden="FALSE"
ImageUrl="...gif"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="elements.xml" />
</ElementManifests>
</Feature>

Los atributos básicos de este XML son:

• Id: GUID de la característica. Puede ser creado con la aplicación "Create GUID".
• Scope: una característica se activa o desactiva dentro del alcance definido por el scope: Web / Site / WebApplication / Farm.
• Hidden: este atributo hará que la característica no sea visible por los usuarios y por lo tanto deberá ser activada en forma obligatoria desde la línea de comandos.
• ElementManifiest: contiene los elementos que define esta característica. Lo veremos más adelante.
  

Más información en MSDN: Trabajo con características y MSDN: Archivos Feature.xml.

Elements.xml

Veamos un ejemplo de elements.xml en el que definimos una custom action para el menú "Site Actions".

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction
Id="SiteActionsToolbar"
GroupId="SiteActions"
Location="Microsoft.SharePoint.StandardMenu"
Sequence="100"
Title="Mi primera accion"
Description="una acción de ejemplo"
ImageUrl="...gif" >
<UrlAction Url ="/_layouts/SampleUrl.aspx"/>
</CustomAction>
</Elements>

Esta característica agregará la custom action. Los atríbutos más importantes del XML son:

• Sequence: especifica la prioridad de ordenamiento.
• URLAction: la URL de la página que es llamada desde la acción personalizada.
  

Más información en MSDN: Creación de una característica simple y MSDN: Elemento CustomAction (Acción personalizada).

Instalar la característica

Para instalar una característica se deben realizar dos pasos:

• Instalación
• Activación

Esto se describe en otro artículo: surpoint: Instalando una feature en sharepoint.

Agregando un evento a una característica

Avancemos un poco más y veamos como agregar un evento a una característica, evento que se ejecutará cuando la característica de active por ejemplo.

using System;
using Microsoft.SharePoint;
namespace surpoint{
public class FeatureReceiver : SPFeatureReceiver {
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
SPWeb site = SPContext.Current.Web;
site.ApplyTheme("Wheat");
site.Update();
}

Esta característica modifica el tema de SharePoint en el momento en que la característica es activada. Para que funcione correctamente, debe modificarse el archivo "feature.xml" como se indica a continuación:

<Feature

Id=""
Title="Mi primera feature"
Description="Esta es la primera feature que desarrollo"
Version="1.0.0.0"
Scope="Web"
Hidden="FALSE"
ImageUrl="...gif"
ReceiverAssembly="surpoint, Version=1.0.0.0, Culture=neutral, PublicKeyToken=..."
ReceiverClass="surpoint.FeatureReciever"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="elements.xml" />
</ElementManifests>
</Feature>

Es importante realizar un ISSRESET porque los ensamblados instalados en la GAC están cacheados.

Más información en:

• surpoint: Cambios de estilos en sharepoint
• surpoint: ¿Qué eventos maneja sharepoint?
• Punto de Encuentro: Registrar un Evento mediante una Feature
  

Creando un control delegado

La forma de crear una característica con un control delegado se describe en otro artículo: surpoint: Mi primer "delegate control".

Hasta aquí la parte 1. Que la disfruten y en breve la parte 2…

Leer más...