WSS 3.0 & MOSS: Algunos Tips & Tricks (II)

Hace un par de semanas iniciábamos una serie de posts respecto a algunos trucos, y también buenas prácticas, a la hora de trabajar con WSS 3.0 & MOSS. En el primer post nos centrábamos en algunos trucos que habíamos aprendido en el CIIN a la hora trabajar con el modelo de objetos de Sharepoint.  La idea de este segundo post es  comentar la forma usual de utilizar algunos de los objetos clave de Sharepoint y también comentar algunos aspectos de planning a tener en cuenta a la hora de abordar un proyecto basado en WSS 3.0 o en su hermano mayor MOSS. Empecemos.

El modelo de objetos de WSS 3.0

Como muchos sabéis, el modelo de objetos de WSS 3.0 es bestial y ha experimentado muchos cambios con respecto a WSS 2.0:

  • EL modelo de objetos de administración se ha rehecho completamente.
  • Los objetos SPSite y SPItem se “han cambiado” a mejor, de manera que soporta no sólo items de lista, sino también documentos de una biblióteca de documentos y carpetas.
  • Cambios en la concepción de las web parts, aprovechando el trabajo hecho en ASP.NET 2.0

Pero, ¿Dónde están todos estos objetos? A nivel de ensamblado, se encuentran en Microsoft.Sharepoint.dll el cuál podéis localizar en el siguiente path de vuestra instalación de WSS 3.0 o MOSS:

C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12ISAPI

Post_Tips_Tircks_II_1 Post_Tips_Tircks_II_2

¿Y qué puedo desarrollar en WSS 3.0? Pues como diría alguno: “de todo”. Y siendo serios, la respuesta sería:

  • Se puede desarrollar cualquier elemento propio de WSS 3.0: listas, librerías de documentos, content types,columnas, tipos de datos, etc.
  • Llamar a los servicios web de Sharepoint para interactuar con elementos del mismo. Ya vimos un ejemplo en un post previo.
  • Desarrollar assemblies específicos para crear manejadores de eventos, controles personalizados, user controls, etc.
  •  Crear ficheros XML para desplegar y crear features, archivos de definición de sitios, listas, etc.
  • Crear páginas ASPX renderizables.
  • Crear plantillas de workflow.
  • Personalización de sitios WSS 3.0: extensión de web parts existentes (mediante CAML, XSLT) o creando nuevas.
  • Crear aplicaciones Windows Forms, servicios windows o simplemente aplicaciones de consola que nos permitan enriquecer nuesras soluciones de Sharepoint.

Cómo en todo modelo de objetos, hablamos de jerarquías. En este post nos interesa la jerarquía de los objetos relativos a los conceptos de web application, site collection, site, lista y elemento de lista de Sharepoint pues son los elementos claves a la hora de estructurar una solución de Sharepoint. Justamente la jerarquía para estos objetos sigue la enumeración comentada:

Post_Tips_Tircks_II_3

Pero como hemos comentado, el modelo de objetos de Sharepoint permite desarrollar “casi de todo” y es realmente extenso (imaginad el de MOSS), y como muestra este fenómenal póster que mi compañero Ángel utiliza en sus charlas y cursos sobre desarrollo en plataforma Sharepoint:

Post_Tips_Tircks_II_4

Vista la teoría, vamos a pasar a la práctica.

Ejemplos de uso de los objetos SPSite, SPWeb, SPList,…

  • El objeto SPSite representa un Site Collection, y por lo tanto una jerarquía de sitio/s hijos. La formas más usuales de utilizar este objeto son las siguiente:

//Cuando se dispone del contexto
SPSite spSitio1 = SPContext.Current.Site;
//Cuando no se dispone del contexto
SPSite spSitio2 = new SPSite(@”
http://litwaredemo);

Ya hemos visto en otros posts (por ejemplo en este) que esta no es la única forma de utilizar un objeto SPSite, por ejemplo:

//Obteniendo el contexto dentro de una web part
SPSite spsSitio = SPControl.GetContextSite(this.Context);
//A partir del objeto SPWorkflowActivationProperties
SPSite site = new SPSite(workflowProperties.SiteId);

Y seguro que hay más formas de acceder a una colección de sitios.

  • El objeto SPWeb representa un sitio individual de Sharepoint. Como ocurría con SPSite, hay dos formas habituales de utilizar este objeto dependiendo de si se dispone del contexto de la web o no (en cuyo caso partimos de un objeto SPSite para acceder a un objeto SPWeb):

//Cuando se tiene el contexto
SPWeb spwWeb1 = SPContext.Current.Site;
//A través de un objeto SPSite
SPSite spSitio = SPContext.Current.Site;
SPWeb spwWeb2 = spSitio.RootWeb;
SPWeb spwWeb3 = spSitio.OpenWeb();
SPWeb spwWeb4 = spSitio.OpenWeb(“/Subisitio1”);

Como ocurría con SPSie, estas no son las únicas posibilidades de acceder a SPWeb. Por ejemplo, si estamos desarrollando un workflow de nuevo nos podemos aprovechar de los miembros del objeto SPWorkflowActivationProperties para poder instanciar un objeto SPWeb:

SPWeb web = site.OpenWeb(workflowProperties.WebId);
  • SPSite y SPWeb: Recorriendo los subisitios de un site collection…algo habitual es a partir de un cierto Site Collection listar todas las webs contendias:

SPWeb spwWeb1 = SPContext.Current.Site;
//Recorrer los subsitios de un Site Collection
foreach (SPWeb spwWeb in spSitio.AllWebs) { }
foreach (SPWeb spwWeb in spSitio.RootWeb.Webs) { }

  • SPList y SPListItem, modelan respectivamente listas (también bibliotecas de documentos) y elementos de una lista de WSS 3.0. Las formas de utilizar estos objetos son también variadas:
//A partir de un Guid único
SPSite spsSitio=SPContext.Current.Site;
SPWeb spwWeb = spsSitio.OpenWeb();
string sListId = Request.QueryString[“ListId”];
SPList splLista=spwWeb.Lists[new Guid(sListId)];
//Mediante el nombre de la lista
SPList splLista2=spwWeb.Lists[“Lista”];
//Mediante el objeto SPWorkflowActivationProperties

SPList splLista3 = spwWeb.Lists[workflowProperties.ListId];

Una lista está compuesta por elementos de lista, es decir, a nivel de objetos un objeto SPList es una colección de objetos SPListItem. Por lo tanto, podemos utilizar estos objetos a partir de recorrernos dicha colección o bien aprovechando alguno de los métodos que nos ofrece el objeto SPList:

//Recorriendo la colección de items de la lista
foreach (SPListItem spliItem in splListaDestino.Items) { }
//Utilizando el método GetItmById
SPListItem spliItem = splListaDestino.Items.GetItemById(Convert.ToInt32(iItemId));

Y hasta aquí algunas formas de utilizar los objetos más habituales de WSS 3.0 & MOSS en lo que se refiere al trabajo con site collections, sitios de un site collection, listas y elementos de listas. Ahora me gustaría comentar algunas cosas básicas de planning en base a la experiencia que estamos teniendo en los distintos proyectos de Sharepoint en los que estamos participando y teniendo en cuenta las recomendaciones que hace Microsoft.

Algunas cosas de planning: objetivos de la solución de sharepoint y elementos de la misma

Cuando afrontamos un proyecto de WSS 3.0 y / o MOSS, debemos preguntarnos una serie de aspectos (contestar a una especie de check list) que luego van a ser claves en la implementación final de nuestra solución. Como siempre, la clave está en seguir una cierta estructura en cuanto a que aspectos necesito determinar para ver el grado de complejidad de nuestro proyecto:

  • Lo primero y más importante es determinar el objetivo u objetivo de la solución a implementar con WSS 3.0 & MOSS:
    • Si se trata de modelar alguno de los escenarios estándar para los que está pensado WSS 3.0 & MOSS: Comunicación, Colaboración, Publicación, …. y por lo tanto podemos seguir el estándar y aprovechar la funcionalidad out-of-the-box que nos da, extendiendo aquellos elementos que sean necesarios.
    • O bien queremos aprovechar algunas de las capacidades de WSS 3.0 & MOSS, pero implementar una solución cuya concepción se sale de la filosofía de WSS 3.0 & MOSS…un ejemplo de esto lo tenéis en un post reciente de Patrick Tisseghem en el que nos comenta que Sharepoint no está pensado por ejemplo para almacenar datos relacionales.
  • ¿De qué entorno estamos hablando? Intranet, Extranet o Internet.
  • Determinados los objetivos de la solución a implementar y que se traduce en una enumeración de sites (bien site collections o bien subistios dentro de un site collection), el siguiente paso está en determinar que elementos de los ofrecidos por WSS 3.0 & MOSS vamos a utilizar en estos sitios: calendarios, blog, wiki, … y que requerimientos especiales tenemos y que no son cubiertos con elementos out-of-the-box: workflows personalizados, web parts, etc.
  • Para aprovechar la idea de reutilización, el siguiente paso sería determinar que contenidos son comunes a los distintos sitios que hemos identificado: workflows de aprobación, integración necesaria con sistemas LOB, etc.

Evidentemente, para “acertar bien” y automatizar estos puntos lo ideal es disponer de unas fichas de recogida de este tipo de información y que de un vistazo nos permitan comprender la naturaleza de nuestra solución, los elementos que la componen y los puntos comunes. En msdn ya tenenmos un montón de plantillas tipo que podemos utilizar o bien enriquecer para facilitarnos el diseño de una solución de Sharepoint…como ejemplo, estas son algunas de las hojas excel que hemos elaborado en el CIIN para esta labor.

Post_Tips_Tircks_II_5

¿Y que más hay que tener en cuenta en el plannig?…ufff, esa si que es la pregunta del millón! Pues muchas cosas que espero contaros más adelante: columnas de sitio necesarias, content types necesarios, nuevos tipos de datos, workflows, tipo de acceso de los usuarios, etc. Por eso hasta aquí lo que os quería comentar sobre aspectos de desarrollo en plataforma de Sharepoint y planning de soluciones. Lógicamente, en ambos casos hemos tocado una pequeña parte de lo mucho que se puede hablar. En futuros posts seguiremos contando cosas de desarrollo y de planning. Espero que el post os haya resultado interesante.

Publicado por

Juan Carlos González

Juan Carlos es Ingeniero de Telecomunicaciones por la Universidad de Valladolid y Diplomado en Ciencias Empresariales por la Universidad Oberta de Catalunya (UOC). Cuenta con más de 12 años de experiencia en tecnologías y plataformas de Microsoft diversas (SQL Server, Visual Studio, .NET Framework, etc.), aunque su trabajo diario gira en torno a SharePoint & Office 365. Juan Carlos es MVP de Office Servers & Services desde 2015 (anteriormente fue reconocido por Microsoft como MVP de Office 365 y MVP de SharePoint Server desde 2008 hasta 2015), coordinador del grupo de usuarios .NET de Cantabria (Nuberos.Net, www.nuberos.es), co-fundador y coordinador del Grupo de Usuarios de SharePoint de España (SUGES, www.suges.es), así como co-director de la revista gratuita en castellano sobre SharePoint CompartiMOSS (www.compartimoss.com). Hasta la fecha, ha publicado 8 libros sobre SharePoint & Office 365 y varios artículos en castellano y en inglés sobre ambas plataformas.

3 comentarios en “WSS 3.0 & MOSS: Algunos Tips & Tricks (II)”

  1. HOLA MI NOMBRE ES OLVER ME GUSTARIA CONOCER MÁS ACERCA DE OBJECT MODEL DE MOSS Y WSS, AGRADECERIA MUCHO TU APORTE YA QUE ME ENCUENTRO REALIZANDO UNA TESIS Y PARA MI ESTE ES UN MUNDO NUEVO EN EL CUAL ESTOY CONOCIENDO SHAREPOINT, WORKFLOWS, ENTRE OTROS.

    MI CORREO ES oparra@cognos.com.bo, agradezco tu aporte.

    Hasta luego

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *