Cuestiones sobre el diseño de soluciones en SharePoint (3)

Uno de los primeros puntos a tener en cuenta cuando se desarrolla una solución para SharePoint es cómo vamos a organizar el contenido y la información.

SharePoint nos ofrece distintas posibilidades que veremos a continuación, pero también hay que tener en cuenta algunos factores importantes.

Granjas, Aplicaciones Web, Colecciones de Sitios, Sitios y Subsitios

En primer lugar tenemos que comprender las opciones que nos brinda SharePoint para estructurar nuestra solución.

Debemos de tener claro que todos los datos de SharePoint son almacenados en distintas bases de datos en un servidor de SQL. Con lo cual desde el punto de vista del diseño de aplicaciones de SharePoint, tenemos que contemplar cuando menos un plan de contingencias y de mantenimiento de las bases de datos que conforman nuestra instalación.

Bases de datos de SharePoint 2007

Dicho esto tenemos que entender ahora 5 piezas fundamentales. No quiero extenderme más de lo necesario, a modo de resumen:

Una granja de servidores es un conjunto de servidores que trabajan en unidos, donde podemos dividir distintas responsabilidades entre distintos servidores. Podemos tener una granja de un único servidor donde todos los servicios funcionen sobre una única máquina (servidor web, búsquedas, Excel services, Forms services, SQL Server …) lo más lógico desde el principio es dividir en dos partes la granja, es decir dejar un servidor para el SQL Server y otro con el resto de servicios. Conforme van aumentando los clientes o la demanda de servicios podemos ir añadiendo servidores y establecer las nuevas funcionalidades de las cuales se ocuparan esos servidores, así por ejemplo podemos añadir un nuevo servidor a nuestra granja que se ocupe únicamente del servicio de búsquedas de modo que descargaremos a otros servidores de dicha responsabilidad.
En el caso de una granja pequeña en crecimiento, pongamos por ejemplo 3 servidores, los roles podrían ser los siguientes, servidor de SQL, servidor Web Front End, y un servidor que se ocupara del resto de los servicios, búsquedas, Excel services, Form Services, Shared Services etc…

En el caso de una instalación de Windows SharePoint Services, también es recomendable dividir siempre que sea posible al menos los roles de SQL Server y de Web Front End.

Obviamente todo esto pasa por un estudio de las licencias necesarias, para montar la infraestructura que deseemos, esto lo dejaremos al margen.

Una vez que tenemos clara la estructura de nuestra granja, tenemos todavía una importante labor, establecer cómo será la jerarquía de nuestros sitios.

En la terminología de SharePoint, tenemos otro punto importante, el de la aplicación web. Una aplicación web será el punto raíz de la estructura de una solución, cuando creamos una aplicación web, SharePoint crea un nuevo sitio de IIS en una dirección y un puerto de nuestra máquina, así como una base de datos en donde albergará el contenido de dicha aplicación web.

Una aplicación web, no es más que un vinculo o una dirección y una base de datos de almacenamiento con el objetivo de albergar cuando menos una colección de sitios. Es por esto que una vez creada una aplicación web a través de la administración central de SharePoint, lo siguiente es crear una colección de sitios que quedará enlazada con la raíz de la aplicación web.

Una aplicación web como mínimo contiene una colección de sitios, pudiendo a través de de la administración central fijar un punto de anclaje para nuevas colecciones de sitios.

En una granja de servidores podemos tener distintas aplicaciones web como una intranet, una extranet, o un sitio web publico), ahora bien, aunque podemos usar la misma dirección web, cada aplicación web deberá tener su propio puerto; no podemos tener dos aplicaciones corriendo sobre el mismo puerto.

Una colección de sitios, es como un árbol, del cual pueden colgar sitios y subsitios, una colección de sitios es el inicio de una jerarquía de sitios, y al igual que en árbol una colección de sitios tiene un sitio raíz. Todo esto es importante porque debemos de tener en cuenta diversos factores como veremos luego que afectan en su conjunto a una colección de sitios.

Antes de continuar, terminaré de matizar que es un sitio y que es un subsitio. Un sitio es un apartado o nivel en el cual encontraremos contenido (entender aquí, páginas, listas, bibliotecas de documentos, subsitios, etc…) y un subsitio es un sitio que tiene padre.

La importancia de las colecciones de sitios consiste en que dentro de una colección de sitios existen ciertos elementos y recursos comunes dentro de la colección y este es un aspecto muy importante a la hora de diseñar una solución de SharePoint.

Dentro de esos elementos comunes estan:

–    Flujos de trabajo
–    Tipos de contenido
–    Columnas de sitio
–    Seguridad por grupos
–    Ámbito de búsquedas (WSS)
–    Características (features)
–    Papelera de reciclaje
–    Informes de uso
–    Web Parts
–    Páginas maestras
–    Plantillas de sitios
–    Plantillas de listas
–    Quotas (limites de espacio)
–    Copias de seguridad

Para que quede claro, dentro de una aplicación web como he dicho anteriormente puede haber más de una colección de sitios, pero todos estos elementos son dependientes de la colección de sitios, de modo que en una colección podemos tener una plantilla personalizada para crear listas de tipo “Pedido” pero en la otra colección esta plantilla puede no existir.

Organización

Al igual que las empresas y corporaciones tienen una estructura determinada debemos establecer cómo queremos estructurar nuestras aplicaciones web en SharePoint. Esto aunque puede parecer sencillo, es sin duda una de las cosas más complicadas.

Veamos un pequeño ejemplo, tomemos una organización dedicada a la fabricación de muebles, supongamos que tiene tres fábricas ó delegaciones en Madrid (central), Barcelona y Sevilla. Dentro de cada delegación, hay diversas divisiones  ó departamentos, Almacén, Fabricación, Ventas, Financiero y Postventa.

Podemos hacer una estructura por delegación

–    Madrid

o    Almacén
o    Fabricación
o    Ventas
o    …

–    Barcelona

o    Almacén
o    …

–    Sevilla

o    Almacén

O bien podemos hacerla por departamentos

–    Almacén

o    Madrid
o    Barcelona
o    Sevilla

–    Fabricación

o    Madrid
o    Barcelona
o    Sevilla

–    ….

Aquí empieza el dilema, ¿Cómo estructuramos nuestra aplicación web?.

Cada organización es muy particular, de modo que no existen formulas magistrales. Por proponer un comienzo, deberíamos analizar qué información es la que va almacenar cada sitio y que seguridad ha de tener cada elemento. ¿Los usuarios de Sevilla solo deben ver lo de Sevilla o pueden ver también lo de Barcelona y Madrid? ¿Deben los del departamento de Almacén ver los datos de Ventas? ¿Le interesan al departamento de Posventa los incidentes de las tres delegaciones?

¿Debo crear una colección de sitios por cada delegación? ¿Por cada departamento? ¿Debería una delegación ser un sitio y un departamento un subsitio? ¿Debería ser al revés? ¿Debería tener dos estructuras, por departamento y por delegación? ¿En colecciones de sitios diferentes o en la misma colección?

A la hora de desarrollar una solución debemos tener en cuenta un montón de aspectos, cuestiones como la seguridad, la información y su flujo, las búsquedas y los recursos con los que va a contar son algunas de las más importantes.

Debemos empezar haciendo un análisis muy cuidadoso de todos estos aspectos para no llevarnos sorpresas luego.

3 comentarios sobre “Cuestiones sobre el diseño de soluciones en SharePoint (3)”

  1. Si en una aplicación web hay más de una colección de sitios, ¿se pueden copiar los permisos de una colección a otra? ¿Cuando nos das otra charlita?

  2. Nosotros procuramos no tener mas de una colección de sitios por aplicación, actualmente la base de datos de contenido tiene más de 200Gb, ¿hay limite de tamaño?, ¿se puede dividir la base de datos de contenido?
    Gracias, buen post, estaría bien que dieses consejos sobre la organización de las aplicaciones.
    Fran.

  3. @Julia, No, hay que hacerlo a mano. Te llamo.
    @Francisco, En principio los lñimites de SQL, mira (http://blogs.msdn.com/sharepoint/archive/2006/08/03/sharepoint-content-database-restrictions-there-are-none.aspx)
    La base de datos de contenido se puede dividir siempre y cuando tengas más de una colección de sitios, cada colección se sitios puede residir en una base de contenido, pero una coleción no puede usar dos bases de datos.
    Trataré de poner algunos consejos personales sobre la organización.
    Saludos,
    CSeg.

Deja un comentario

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