Consideraciones y buenas prácticas en el diseño de Soluciones WSS v3 (I)

Recientemente en el CIIN nos hemos embarcado en un interesante proyecto de WSS 3.0 y MOSS en el que se cubrirá todo el ciclo de vida de definición, diseño e implementación de soluciones WSS 3.0 / MOSS. Aunque ya habíamos publicado algunos posts en nuestro bog respecto a que aspectos hay que considerar en proyectos de este tipo, me he decidió a publicarlos en Geeks, puesto que creo que es un tema muy interesante a contar.


 


Diseñar adecuadamente una solución de WSSv3 implica tener en cuenta una serie de consideraciones que empiezan con conocer las necesidades y requerimientos de una organización, pasando por determinar cómo se tienen que estructuras los contenidos, que niveles de seguridad se necesitan,… hasta la creación de sitios, y pruebas de rendimiento. Este es el primero de una serie de posts en el que se intentará resumir las buenas prácticas que Microsoft recomienda a la  hora de diseñar soluciones de WSSv3. Muchas de las ideas expuestas se basan en el libro (disponible online) Planning and architecture for Windows SharePoint Services 3.0 technology.


Necesidades de la Organización y del Usuario


Uno de los primeros puntos a determinar es que necesidades tienen la organización y el usuario individual, es decir, aspectos como si la organización requiere de un entorno de comunicación, de almacenamiento de documentos, de colaboración, y aspectos más dependientes del trabajo diario del usuario: revisión de documentos, versionado, aprobación, suscripción a eventos, comunicación con mis iguales y superiores, etc.


Además de estas consideraciones funcionales, en nuestra labor como diseñadores de soluciones WSSv3 tenemos que tener en mente otros aspectos igualmente importes como si el entorno a crear es una Extranet o una Intranet, de cuantos modos posibles se puede acceder a estos entornos, cuantos sitios de WSSv3 forman cada entorno, etc. En definitiva, son muchas las cosas que tenemos que tener en la cabeza al concebir y diseñar una solución de WSSv3, y Microsoft nos da un buen punto de partida con las plantillas de recogidas de especificaciones para el planning y diseño de dichas soluciones. Empecemos pues.


Paths para la instalación de WSSv3


 


En WSSv3, los Site Collections están contenidos en los llamados paths de WSSv3, igual que nuestros archivos están contenidos en carpetas. Cuando se crea una Web Application en WSSv3, por defecto se crean dos paths:



  • El path raíz (/), que sólo puede contener un único site collection (inclusión ímplicita).

  • El path Sites (/sites), que puede contener varios site collections (inclusión wildcard).


Además, si es necesario desde la administración central de WSSv3 se pueden añadir nuevos paths que nos permitan agrupar site collections que consideremos relacionados, y en previsión de que el número de site collections crezca en el futuro o bien por para poder aplicar restricciones de acceso.


 


Número de Sitios y Collecciones de Sitios


 


En general es una buena práctica que cada sitio de WSSv3 esté focalizado para un propósito único o bien para que sea utilizado por un único grupo de trabajo. Si se utiliza un sito de WSSv3 para distintos usos y por demasiada gente, se pude complicar su mantenimiento y actualización, al tiempo que se vuelve menos útil. Así por ejemplo, no tiene sentido utilizar un mismo sitio para realizar un seguimiento de clientes, almacenar políticas de empresa o compartir documentación de productos, ya que organizar el sitio puede ser realmente complicado. Por otro lado, tener demasiados sitios dificulta la tarea de encontrar información. Por tanto, se trata de llegar a una situación de compromiso de acuerdo a los siguientes puntos:



  • El número de usuarios que van a utilizar los sitios.

  • El vínculo o relación entre los usuarios o qué tipo de interacción existe entre ellos.

  • Cómo van a utilizar los usuarios los sitios: visualizar información, crear o añadir elementos, etc.

  • El tipo de contenidos que se va a almacenar en los sitios.

  • La complejidad (en cuanto a organización) de la información a almacenar, etc.

La primera decisión que se ha de tomar antes de empezar el diseño de soluciones de WSSv3 es si se van a utilizar sitios de tipo top-level, cada uno perteneciente a una Site Collection diferente o por contra se van a utilizar una única Site Collection en la que se definirán los subsitios necesarios. Pero, ¿qué escenarios son aplicables a cada caso?.  En este caso hemos de considerar:



  • Si los sitios tienen ciertos elementos en común y requieren compartirlos, lo más adecuado es definir subsitios dentro de una site collection para compartir elementos como la navegación, content types, workflow, etc.

  • Si por contra, nuestros sitios no tienen nada en común y además queremos manejarlos de manera individual, lo más adecuado es definir sitios top-level. Escenarios que aconsejan esta opción son los siguientes:


    • Las políticas de seguidad para cada sitio tienen que ser diferentes y no compartidas.

    • Necesidad de hacer el back up y restore de un sitio.

    • Mover el sitio a una BD diferente.

    • Definir scopes únicos por sitio para workflows y búsqueda.

    • Manejar individualmente el espacio de almacenamiento disponible por sitio.

    • Descentralizar la administración y poder crear la figura de administradores a nivel de site collection.

Determinar contenidos y estructura a nivel de sitio individual


Crear un sitio de WSSv3 es un proceso sencillo y rápido. Sin embargo, especificar los contenidos del mismo y como organizarlos es muy tedioso y suele llevar bastante tiempo. Para llevar a cabo esta tarea, existen dos métodos:



  • El método formal, que consiste en preguntar a los usuarios potenciales, a través de reuniones formales o mediante encuestas, que es lo que quieren visualizar en el sitio. Este método es recomendable para crear sitios grandes y complejos, con múltiples audiencias y diferentes necesidades.

  • El método informal, que consiste en realizar un primer prototipo de sitio e ir evolucionándolo a partir del feedback recibido de los usuarios y de las necesidades que vayan apareciendo.

Planning de Contenidos y Búsqueda


Hasta ahora, hemos hecho referencia a las consideraciones  y aspectos que hay que tener en cuenta a la hora de determinar el número de sitios y colecciones de sitios de WSSv3 que pueda necesitar la organización, es decir, si lo más adecuado son sitios top-level de WSSv3, o con un único sitio top-level y subsitios por debajo, y los dos métodos que se utilizan para determinar los contenidos y la estructura a nivel de sitio individual. La idea de esa sección  es detallar que aspectos (muchos como veremos) hemos de tener en mente a la hora de estructurar los contenidos de un sitio de WSSv3, y algunas aspectos sobre las búsqueda en WSSv3.


El planning de contenidos pasa por establecer qué elementos de WSSv3 necesitamos para organizar  los contenidos de nuestros sitios:



  • Listas, que son colecciones de información que puede ser compartida entre los usuarios de un sitio de WSSv3:





































Lista


Descripción


Anuncios (Announcements)


Permite compartir noticas y estados, así como proporcionar recordatorios.


Calendario (Calendar)


Proporciona distintas vistas de calendario, permite realizar el track de milestones de los usuarios de un sitio de WSSv3: deadlines, releases, etc. Permite integración con programas clientes que lo soporte como es el caso de Microsoft Office Outlook.


Contactos (Contacts),


Pensada para almacenar la información de contactos con los que la organización trabaja. También está integrada con programas de correo electrónico que soporten WSSv3. No permite gestionar los miembros del sitio.


Customizada


Se puede crear a partir de definir las columnas necesarias o bien importándola desde WSSv2, Excel, Access u otro programa compatible con WSSv3 y que presente esta capacidad. Desde el punto de vista de desarrollo, también se pueden crear estas listas desde VS 2005 utilizando o no las extensiones de WSSv3 para Visual Studio y desplegando la lista creada como una feature.


Paneles de Discusión (Discussion Boards)


Define un repositorio centralizado donde registrar y almacenar los debates del equipo. Además, si está habilitado por el administrador, permite almacenar comentarios y debates recibidos por e-mail.


Issue Tracking


Almacena información relativa a ciertos issues del equipo. Desde esta lista se pueden asignar issues, categorizarlos, relacionarlos con otros, etc. Además, se puede crear un histórico de comentarios


Enlaces (Links)


 


Tareas de Proyecto (Project Tasks)


Lista de tareas que dispone de una vista tipo diagrama de Gantt. Permite seguir el estado de ejecución de las tareas y el % de realización. También permite realizar este tipo de tareas desde un programa gestor de correo gestor de tareas que soporte WSSv3.


Encuestas (Surveys)


Permite añadir page breaks para mejorar el look & feel de una encuesta, añadir lógica para controlar que preguntas visualizar en función de las respuestas que se vayan realizando. Además, permite exportar los resultados de la encuesta a una hoja excel, una BD o un programa que soporte WSSv3.


Tareas


Pensada para hacer el tracking de información de proyectos, procesos de gestión documental (recogida de firmas, aprobación, recogida de feedback, etc.), acciones a realizar, etc. Como sucedía con los issues, las tareas se pueden asignar a usuarios, tienen habilitado seguimiento, etc. De nuevo, es posible visualizarlas y operar con ellas desde un programa cliente que lo permita (Microsoft Outlook).



  • Librerías de documentos, que son colecciones de archivos que pueden ser compartidos entre los distintos usuarios de un sitio de WSSv3. En WSSv3 hay dos tipos de librerías de documentos:


    • Librerías de documentos en mismas, que permiten almacenar documentos de propósito general, documentos de colaboración,… y que habilita un sencillo mecanismo de compartición de documentos.

    • Librerías de Imágenes, que permiten compartir, gestionar y reutilizar imágenes digitales.

  • Content Types, que son unidades de agrupación de WSSv3 que define los atributos de un elemento de una lista, de un documento o de una carpeta.

  • Worflows, o flujos de trabajo, que permiten modelar y definir procesos de gestión documental, colaboración, o de otro tipo en WSSv3.

v  Planning de Listas Customizadas


Ante de crear una lista customizada (una nueva o extender alguna de las estándar) para almacenar o compartir información, hay que pensar en que estructura es la más adecuada para ello. Definir una estructura adecuada, implica considerar una serie de puntos:



  • ¿Qué tipo de campo permitirá que los usuarios puedan visualizar y utilizar la información de un modo más efectivo? Buena práctica: Definir una lista test en la que ir probando las distintas combinaciones de campos. No hacer esto en una lista real, puesto que se corre el riesgo de perder la información almacenada.

  • Conocer los límites en cuanto a número de campos de un cierto tipo que se pueden utilizar. En principio en WSSv3 este número es ilimitado en la mayoría de los casos, pero es algo muy a tener en cuenta de cara a no penalizar el rendimiento de una lista.

  • ¿Qué tipo de campo permite introducir datos de un modo más sencillo?

  • ¿Qué vistas de información podrían necesitar los usuarios? Por ejemplo, una vista en formato hoja excel habilita tanto la introducción como la visualización de datos.

  • ¿Es necesario compartir información o columnas entre listas? Compartir información implica utilizar campos de tipo lookup. Compartir columnas implica crear column types.

v  Planning de Librerías


A la hora definir y configurar como van a ser las librerías de documentos, se pueden considerar los puntos comentados para el planning de listas customizadas puesto que tenemos que pensar que una librería de documentos es un tipo especial de lista pensada para almacenar ítems de tipo documento. Además, hay que tener en cuenta consideraciones más particularizadas para documentos como son: versionado, aprobación de contenidos, Check In / Out e IRM.


Versionado


WSSv3 admite tres tipos de versionado:



  • Ninguno, lo que no permite recuperar versiones previas de documentos ni disponer de un histórico.

  • Sólo versiones major, lo que permite versionar documentos utilizando un esquema de versionado simple (1,2,3,…). Se puede especificar el número de versiones a utilizar. Buena práctica: Usar este tipo de versionado cuando no es necesario distinguir entre versiones draft y versiones publicadas.

  • Versiones major y minor, las versiones que termina con .0 son de tipo major (1.0, 2.0,…), y las que terminan con un valor no nulo son de tipo minor (1.1,1.2,…). Este tipo de versionado se utiliza cuando se requiere diferenciar entre versiones draft y versiones publicadas.


Aprobación de Contenidos


Es el mecanismo mediante el cual los usuarios de un sitio con permisos de aprobación controlan la publicación de contenidos (un draft se encuentra en estado pendiente mientras no se apruebe). La aprobación de documentos se puede configurar de dos modos:



  • A través de un cambio de estado: de pendiente a aprobado.

  • A través de un workflow de aprobación asociado a la librería de documentos.

Usar un mecanismo u otro depende del tipo de versionado que se esté utilizando:



  • Si no se utiliza versionado o se utilizan sólo versiones major, entonces el mecanismo ha de ser el cambio de estado.

  • Si se utilizan versiones major y minor, tiene más sentido utilizar un workflow de aprobación.

Check-In y Check-Out


Las ventajas de utilizar el check In / Out de documentos son las mismas que el Check In/Out de archivos fuente en desarrollo de código.  Estas son:



  • Mejor control del momento en que se crean versiones del documento. Cuando se hace el check-out del documento, este queda bloqueado para el resto de los usuarios.

  • Creación de un historial rico del documento, puesto que el autor puede añadir sus propios comentarios que permiten a los lectores conocer la naturaleza de los cambios producidos.

v  IRM


Information Rights Management es la característica que permite a los creadores de contenidos controlar y proteger los documentos. Esta característica se habilita en WSSv3 a través de la instalación de un “protector” para ciertos tipos de documentos. Este protector es un programa que se encarga de encriptar y desencriptar aquellos documentos que se encuentra protegidos. En concreto, se necesita instalar el cliente Microsoft Windows Rights Management Services v1 en cada frontal web de de la granja de servidores y se nesita tener en el mismo segmento de red un servidor con Microsoft Windows Rigth Management Services for Windows 2003 Server (Service pack 1 o superior).


v  Content Types


Un content type es una unidad de agrupación de WSSv3 que define los atributos de un elemento de una lista, de un documento o de una carpeta. Cada content type puede especificar:



  • Las propiedades a asociar con un cierto tipo de elemento.

  • Los workflows que pueden ser lanzados en elementos de un cierto tipo.

  • Las plantillas de documentos (para content types de documentos).

  • Conversiones en documentos.

  • Custome features.

Los content types se asocian a listas o librerías de documentos, de manera que cuando se añaden elementos se puedan vincular a un cierto Content Type (Nota: El número de content types que puede contener una lista o librería es ilimitado). Los content types se definen en WSSv3 en la Content Type Gallery, de manera que una vez definidos en un sitio de WSSv3, estarán disponibles en él y todos los subisitos relacionados. Si se quiere que un content type esté disponible en el mayor número de sitios y subsitios posible, es recomendable definirlo en la Content Type Gallery de aquel sitio más alto dentro de la jerarquía de una Site Collection. Por ejemplo, supongamos que en la Intranet de nuestra empresa queremos utilizar una cierta plantilla oficial para los documentos funcionales que se entregan al cliente y que de alguna forma queremos aplicar de una manera automática esta plantilla cada vez que se cree un nuevo documento funcional en la Intranet. La solución pasaría por definir un content type en la Content Type Gallery del sitio de WSSv3 con un nivel jerárquico más alto dentro de la site collection en la que tenemos definida toda nuestra Intranet. En este content type especificaríamos los metadatos que debe incluir cada documento funcional que subamos, la plantilla que debe seguir, los workflows necesarios (por ejemplo, un workflow de recogida de feedback), etc.



 ¿Cómo hacemos el planning de los content types que necesitemos?


Por defecto, los elementos de las listas y librerías (Contact, Task, o Document) por defecto de WSSv3 llevan asociados su correspondiente content type (ubicado en la correspondiente galería). Estos content types pueden ser reutilizados o bien definir nuevos content types que hereden de ellos, o incluso modificarlos según las necesidades. Una característica muy importante de los content types es que se organizan de manera jerárquica, lo que habilita que cada content type herede las características de su padre. En la práctica, esta característica se traduce en que podemos categorizar nuestros documentos de manera que compartan diferentes elementos a lo largo de la organización.



Column Templates


Como hemos comentado, cada elemento o metadato asociado con un content types es una columna de una lista o librería de documentos. Cada columna de una lista o librería de documentos puede estar asociada a más de un content type, y para facilitar esta asociación múltiple WSSv3 define la Column Template Gallery (una por cada Site collection).



Folder Content Types


Este tipo de content types define los metadatos asociados con una carpeta de una lista o librería de documentos. Su uso es interesante para definir vistas personalizadas de carpetas que estén asociadas a un cierto content type, o para definir vistas.


Planning de Content Types para documentos


Las settings del content type asociado a cada documento individual deberían heredar del content type asociado al tipo de documento al que pertenece o de uno que descienda de él. De este modo, se asegura que columnas básicas como Title o Created By están por defecto presentes y se puede asociar una plantilla al content type.


El primer paso en el planning de content types pasa por revisar y listar los distintos tipos de documentos que tenemos o podemos tener para ver si por defecto existen content types para esos tipos de documentos, o necesitamos crearlos. Una vez que hemos realizado esta revisión, el proceso de planning de content types pasa por los siguientes puntos:



  • Realizar una lista en la que especifiquemos el Tipo de Documento, la URL del sitio en el que se van a utilizar este tipo de documentos, el content type para ese tipo de documento, el content type padre del que hereda.

  • Especificar las columnas que van a estar englobadas dentro del content type, indicando información como el propósito de la columna, el tipo, si se trata de una columna nueva, si va a ser una columna heredada,…

  • Determinar la plantilla (extensión, como por ejemplo docx para documentos word de Office 2007) asociada al content type.

  • Determinar los workflows vinculados con el content type.


Planning de Content Types para Listas


El proceso de planning para content types de listas es idéntico al descrito para librerías de documentos. La única diferencia es que los content types ahora se aplican a elementos (ítems) de una lista, mientras que en el caso de librerías de documentos se aplican a documentos.


Después de hacer el planning de Content Types


Después de determinar los content types que vamos a necesitar, los pasos lógicos son:



  • Identificar por sitio que nuevas columnas son necesarias.

  • Identificar las nuevas plantillas a diseñar.

  • Identificar los nuevos workflows a desarrollar / adquirir e instalar.

v  Workflows


Los workflows en WSSv3 se pueden vincular a listas, librerías de documentos y content types. La base de definición, creación y uso de workflows es la integración de WF con WSSv3. Para la creación de workflows en WSSv3, es necesario hacer un análisis previo del proceso que se quiere modelar, así como los siguientes puntos:



  • Ámbito de aplicación, si el workflow ha de estar disponible en una única lista / librería de documentos o en todo los sitios y subsitios de una site collection.

  • Si el workflow se va arrancar de modo manual o automático.

  • Los eventos de que depende que el workflow se arranque.

  • El tipo de workflow: secuencial vs máquina de estados.

  • Si en el workflow se van a necesitar puntos de interacción humana, por lo que serán necesarios definir formularios.

En función de los requisitos recogidos, la creación de workflows podrá realizarse a través de Sharepoint Designer 2007 para los casos sencillos y de tipo secuencial y en la que el workflow sólo se quiera vincular a una única lista o librería de documentos, o bien a través de Visual Studio 2005 (con los Add-Ins para WF, las plantillas de workflows para WSSv3 y las actividades OOB para crear workflows para WSSv3) para workflows más complejos (tanto de tipo secuencial como de máquina de estados), que tengan que estar disponibles en todos los sitios (y requieran ser desplegados a través de una feature de WSSv3) de una site collection y que puedan ser desplegados en otras site collection.


Nota: WSSv3 por defecto únicamente dispone de un workflow por defecto: Three-State. Aunque en el SDK viene un ejemplo de workflow de recogida de feedback que nos puede servir como base para construir los workflows que necesitemos.


v  Planning de Búsqueda


Muchas de las capacidades de búsqueda de WSSv3 se configuran durante el proceso de instalación, de manera que son pocas las opciones de búsqueda que pueden ser configuradas a posteriori. Estas se configurarán en el planning de seguridad, capacidad y rendimiento.


Consideraciones sobre la búsqueda en WSSv3


Cuando en el diseño de una solución de WSSv3 se quiera incluir funcionalidad de búsqueda, hay que tener en cuenta una serie de consideraciones respecto a las capacidades (y limitaciones) de la búsqueda en WSSv3:



  • Escalabilidad, el ámbito de búsqueda en WSSv3 se establece a nivel de site sollection, es decir, sólo se puede hacer el crawling a nivel de site collection. Sólo se pueden buscar contenidos dentro de los sitios del site collection, y no en bases de datos, servidores de correo, servidores de aplicaciones, o sitios web o archivos compartidos que estén  fuera del site collection.

  • Fuentes de Contenido, por cada web application se crea de manera automática un Content Source cuyos detalles no son expuestos, por lo que no es posible ningún tipo de configuración.

  • Scopes de búsqueda, están restringidos a sitios, subsitios, listas, librerías o carpetas de cada site collection.

  • Número limitado de IFilters para buscar contenidos en ciertos formatos.

  • Crawling, en su versión completa se realiza de manera automática sin posibilidad de planificación y control por parte del administrador.

Y hasta aquí la primera entrega de buenas prácticas en el diseño de soluciones de WSSv3. Espero que os haya resultado interesante. En la próxima entrega hablaremos sobre aspectos a tener en cuenta a la hora de definir la seguridad de sitios y contenidos en WSSv3.


 

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.

7 comentarios en “Consideraciones y buenas prácticas en el diseño de Soluciones WSS v3 (I)”

Deja un comentario

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