This Blog

Syndication

Search

Tags

Community

Email Notifications

Archives

Enlaces Recomendados

April 2007 - Artículos

LINQ To SQL: Query Visualizer!

El otro día me comentaba Rodrigo Corral que le parecían interesantes muchos de los posts que tenemos publicados en el blog del CIIN, y que estaría bien que aparecieran también en Geeks, por lo que dicho y hecho, este es el primero de los posts que rescatamos de nuestro blog para republicarlo en Geeks, y en el futuro lo que haremos será crossposting entre ambos blogs (primero tendremos que averiguar cómo hacer Crossposting entre nuestro blog basado en WSS 3.0 y el blog del CIIN en Geeks).

Sin más preámbulos, pasemos a la acción. En un post previo introducimos LINQ To SQL. Vimos como podíamos crear consultas integradas en el lenguaje para obtener información de un origen de datos relacional SQL Server, estas consultas se realizaban contra objetos de un modelo de objetos en el que mapeábamos elementos de un esquema relacional (tablas, columnas de las tablas y procedimientos almacenados). También comentamos que LINQ se apoya en muchas de las innovaciones del lenguaje que vendrán con C# 3.0 y VB 9.0 y en características propias como la evaluación diferida de consultas, es decir, la consulta que he creado no se ejecuta hasta que itero con ella. En la práctica, este mecanismo de evaluación diferida de consultas nos da la ventaja de que podamos evaluar una consulta múltiples veces puesto que su definición permanece en memoria.

Además de estas características clave, LINQ To SQL nos ofrece herramientas interesantes para facilitar en tiempo de depuración algo tan típico como comprobar que consulta T-SQL se está enviando a la BD y probarla sin tener que irnos a SQL Server Management Studio o a la ventana de comandos de Visual Studio. Esta herramienta es el LINQ To SQL Query Visualizer, que el IDE de Visual Studio nos ofrece en tiempo de depuración al posicionar el puntero del ratón sobre el tipo que va a almacenar el resultado de la ejecución de la consulta realizada:

var ClientesMarcaCoche =

from c in BD2.Customers

join ve in BD2.Vehicles on

c.ID_Cliente equals ve.ID_Cliente

orderby c.CiudadCliente ascending

select new{NIF=c.ID_Cliente,

Nombre=c.NombreCliente,Coche=ve.MarcaVehiculo};

Para iniciar el Query Visualizer, no tenemos más que iniciar la ejecución del programa de LINQ To SQL en modo depuración y situar un punto de ruptura justo después de construir la consulta integrada en el lenguaje. Las capacidades del Visualizer aparecerán en el momento que pasamos el ratón sobre el tipo que almacena la consulta.

Si pulsamos sobre la pestaña asociada al icono de la lupa, podremos ver el LINQ To SQL Visualizer, en el que se nos mostrará:

·       La definición completa de la consulta que hemos definido en código, es decir, mostrando la llamada a los operadores estándar de consulta como métodos de extensión y las expresiones lambda que se están utilizando para luego generar la correspondiente sentencia T-SQL.

La sentencia T-SQL que se envía a la BD.

Como vemos, en el visualizador se muestra la consulta definida en un formato en el que no estamos utilizando Query Syntax y mostrando las expresiones lambda y otras innovaciones (tipos anónimos, inicialización de objeto, y uso de métodos de extensión a través de los operadores estándar de consulta) en el lenguaje que necesita para poder realizar la consulta.

Sin más, al pulsar el botón ejecutar podremos ver el resultado que nos devuelve la query T-SQL que LINQ genera a partir de la consulta definida en el lenguaje:

Como veis, esta herramienta es realmente útil (de hecho, ha causado sensación en el primer seminario que sobre LINQ impartimos en el CIIN) para comprobar que las consultas devuelven los resultados esperados sin abandonar el entorno de depuración de Visual Studio 2005. Y hasta aquí el primer post que rescatamos del blog del CIIN, comentaros también que el sábado por la mañana me instalé la Beta 1 de Orcas y por fin integra plenamente LINQ en el IDE, espero pronto poneros algún  ejemplo chulo de LINQ en Visual Studio Orcas.

Publicado 29/4/2007 22:50 por Juan Carlos González Martín | 2 comment(s)

Archivado en:

MOSS: Habilitando y Configurando la búsqueda de personas!

Una de los componentes más importantes de MOSS es el potente motor de búsqueda que lleva incorporado dentro de los llamados Shared Services Providers (que proporcionan varios servicios compartidos entre distintos sitios de MOSS: Búsqueda, Business Data Catalog, User Profiles y My Sites, Excel y Form Services, Audiencias).Los Shared Services Providers se crean y mantienen desde la administración central de MOSS:

En este post nos centraremos en las características de búsqueda de MOSS, mostrando las configuraciones necesarias para realizar búsquedas de personas en sitios de MOSS. Para ello, lo primero que haremos  es crear un subistio de búsqueda con tabs a partir de la plantilla out-of-the-box que MOSS nos ofrece para esta funcionalidad:

Una vez que MOSS acabe de crear el sitio de búsqueda, este aparecerá en pantalla utilizando la plantilla que hemos indicado (bastante potente para cualquier organización para localizar sus empleados en la Intranet).

Una vez creado el subsitio de búsqueda, para que en este podamos encontrar personas al realizar una búsqueda, son necesarios dos pasos:

·         En primer lugar, necesitamos añadir las personas que vamos a buscar en MOSS. Estas personas son lo que MOSS denomina User Profiles y para añadirlas, desde el Shared Service Provider creado, nos vamos a la sección User Profiles And My Sites y aquí seleccionamos la opción User Profiles and Properties:

Desde la pantalla que se abre, podremos añadir nuevos user profiles bien manualmente o bien definiendo una importación de perfiles de usuario programada a partir de un origen especificado para los mismos: Active Directory, LDAP o un BDC.

También podemos ver que perfiles tenemos añadidos (y sobre los que se va a realizar la búsqueda), y desde el listado de perfiles podemos añadir manualmente otros nuevos o modificar los existentes.

Nota: Es interesante ver para un perfil de usuario la cantidad de datos que se pueden tener.

·         Configurar la búsqueda en sí misma. De nuevo, desde la administración del Shared Service creado nos vamos a la sección Search -> Search Settings para configurar como se va a realizar la búsqueda.

Desde esta pantalla, lo primero que tenemos que configurar  es dónde vamos a habilitar la búsqueda y con qué periodicidad se realiza la indexación necesaria para realizar la búsqueda. Esta configuración la hacemos desde la opción Content Sources and Crawl Schedules (por defecto, al crear un Shared Service se crea un Content Source que nos permite realizar búsquedas de personas y de contenidos en sitios de MOSS).

En la pantalla que se abre, podremos ver los  Content Sources disponibles o añadir uno nuevo:

Para un Content Source, se trata de especificar sobre que sitios va a realizar la indexación de contenidos y la periodicidad de las dos posibilidades de indexación que nos ofrece MOSS: indexación total e indexación incremental.

Lo siguiente que tenemos que asegurarnos es que tengamos definidos los scopes de búsqueda necesarios. Los scopes los visualizamos desde la página Search Settings y la opción View Scopes dentro de la sección Scopes:

Al menos para el Content Source que por defecto se crea, tenemos dos scopes de búsqueda definidos:

o   All Sites, que permite realizar la búsqueda de contenidos en todos los sitios que tengamos definidos en nuestros Content Source.

o   People, que nos permite realizar la búsqueda de los profiles que tengamos añadidos.

Si vemos el detalle de cada scope, veremos que se basa en la aplicación de una cierta regla referente a contenidos para el scope All Sites, y a personas en el caso de People. Por supuesto, estas reglas se pueden cambiar por otras de las que nos da MOSS out-of-the-box.

Una vez configurada la búsqueda, tenemos que realizar la indexación correspondiente (arrancándola manualmente o simplemente esperar a que se realice de acuerdo a la programación definida). La indexación manual que se puede realizar puede ser de tipo manual o automática y están disponibles como acciones de un Content Source.

Al realizar la indexación veremos que la columna status del Content Source toma el valor Crawling Incremental o Crawling Full lo que nos indica que se está realizando la operación. Cuando dicha columna toma el valor idle, la indexación habrá finalizado y ya podremos realizar las búsquedas de personas.

Como veis, configurar adecuadamente las capacidades de búsqueda en MOSS es un proceso relativamente laborioso, pero sencillo y con resultados muy potentes. Espero que el post os haya resultado de interés.

Publicado 27/4/2007 10:23 por Juan Carlos González Martín | 13 comment(s)

Archivado en:

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

Siguiendo con la serie de posts de buenas prácticas y aspectos a tener en cuenta a la hora de diseñar soluciones en WSSv3, en el segundo post de la serie vamos a tratar cuestiones relativas a la seguridad en sitios de WSSv3.

La meta de esta fase es establecer que mecanismos de seguridad se van a utilizar a la hora de acceder a sitios de WSSv3 y a sus contenidos. Para lograr esta meta, hay que cubrir algunos de los siguientes puntos:

  • Los distintos niveles de permisos de acceso tanto a los sitios de WSSv3 como a los contenidos. Es importante recordar que en WSSv3 se ha añadido un nuevo modelo de seguridad y unas nuevas características de seguridad que hacen más fácil controlar quien tiene acceso a los distintos contenidos de un sitio (Recordemos que en WSSv3 hay seguridad a todos los niveles, llegando hasta nivel de elemento o documento).
  • Los mecanismos de autenticación utilizados para acceder a los sitios: Windows, basada en formularios, mixta, customizado, etc.

Seguridad a Nivel de Sitio

La seguridad a nivel de sitio se controla asignando permisos a usuarios y grupos sobre elementos securizables de WSSv3: un sitio, una lista o un elemento de una lista. Cuando se hace el planning de la seguridad de un sitio, hay que decidir:

  • Hasta qué nivel se quiere controlar los permisos de acceso a los distintos componentes de WSSv3: ¿Es suficiente con establecer permisos para controlar el acceso a nivel de sitio? ¿O se necesitan configuraciones específicas de seguridad para listas, carpetas o elementos?
  • Como se van a categorizar y gestionar los usuarios y los grupos de usuarios definidos.

La seguridad a nivel de sitio debe considerar los siguientes elementos:

  • Permisos individuales de usuario, garantizan la capacidad de que un usuario pueda realizar o no acciones específicas. Por ejemplo, el permiso View Items permite que el usuario pueda visualizar todos los elementos de una lista. Estos permisos se gestionan desde la Administración Central de Sharepoint, en la sección Application Security -> User Permissions For Web Application (a la que se accede desde la pestaña Application Management).

 

  • Nivel de permiso, WSSv3 define un conjunto de niveles de permisos pre-definidos que permiten  realizar ciertas acciones. Los niveles por defecto son: Limited Acces, Read, Contribute, Design, y Full Control. Cada uno de estos niveles a su vez incluye una serie de permisos individuales. Por ejemplo, el nivel Read incluye: View Items, Open Items, View Pages y View Versions, los cuales son necesarios para visualizar documentos, elementos y páginas de un sitio de WSSv3.

  • Usuario, es una persona con una cuenta de usuario que puede ser autenticada por el método de autenticación usado en el servidor. Buena Práctica: Aunque se pueden añadir nuevos usuarios y permisos a nivel de usuario individual sin que pertenezcan a un grupo, es recomendable asignar permisos a nivel de grupo, e incluir los usuarios en los grupos que correspondan (Es ineficiente, salvo excepciones, mantener cuentas individuales de usuario). Por ejemplo, usar grupos de usuarios es más flexible para situaciones tan habituales como movimientos de personas de un equipo a otro porque se ha producido un cambio de rol o responsabilidad.
  • Grupo, es un grupo de usuarios. Los grupos añadidos a un sitio de WSSv3 pueden ser directamente grupos de Windows (como un departamento) o directamente de Sharepoint (Site Owners, Site Members, Site Visitor o cualquier otro que definamos). Cada grupo de Sharepoint tiene asociado por defecto un nivel de permisos.
  • Objetos securizables, en WSSv3 se pueden establecer niveles de permisos a nivel de sitio, lista, librería de documentos, carpeta, documento o elemento. Por defecto, los permisos para una lista, librería, carpeta, documento o elemento se heredan del sitio padre o de la lista o librería de documentos padre. Esta herencia se puede romper en cualquier momento, y a nivel de objeto individual (el resto de permisos del sitio permanece inalterado), editando los permisos de los objetos a los que se les quiera aplicar unos ciertos permisos.

Herencia de Permisos y Subsitios

Como hemos visto, en WSSv3 un sitio es en sí mismo un objeto securizable al que se le pueden asignar una serie de permisos. Cuando hablamos de subsitios dentro de un sitio de Sharepoint, podemos configurarlos para que hereden (opción por defecto al crear un subsitio) los permisos del sitio padre, o bien crear unos permisos únicos para el sitio. La herencia de permisos es el mecanismo más sencillo de gestionar un conjunto de sitios web. Sin embargo, hay un inconveniente: los permisos se comparten, de modo que los usuarios propietarios de un cierto subsitio con capacidad para editar sus permisos podrán editar también los permisos del sitio padre. Si se quiere cambiar los permisos sólo en el subsitio, será necesario romper la herencia, y a continuación realizar los cambios deseados.

 ¿Cómo se rompe la herencia de permisos? Como hemos comentado, la herencia se rompe en el momento en que especificamos que deseamos crear permisos únicos para un subsitio. En ese momento, se copian en el subsitio los grupos, usuarios y niveles de permisos del sitio padre, y se rompe la herencia. El proceso contrario también es posible, es decir, en cualquier momento puedo configurar un subistio para que herede del padre. Ahora bien, en este caso hay que tener en cuenta que se perderá todo grupo, usuario o nivel de permiso creado a nivel particular del subsitio (y que por tanto no exista en el sitio padre).

El proceso contrario también es posible, es decir, en cualquier momento puedo configurar un subistio para que herede del padre. Ahora bien, en este caso hay que tener en cuenta que se perderá todo grupo, usuario o nivel de permiso creado a nivel particular del subsitio (y que por tanto no exista en el sitio padre).

Nota: La misma  filosofía de herencia y rotura de herencia que hemos descrito para permisos individuales puede ser rota en una capa de agregación de permisos superior (lo que en WSSv3 se llama Nivel de Permiso). Por ejemplo,  podríamos romper la herencia del nivel Read porque no queramos que en un cierto subsitio incluir el permiso Create Alerts.

¿Qúe niveles de seguridad escogemos para un sitio?

Como suele suceder con este tipo de preguntas, la respuesta no es sencilla. Al crear la estructura de permisos hay que encontrar el balance adecuado entre factores como rendimiento, facilidad de administración o la necesidad de controlar permisos específicos para ítems individuales de WSSv3. Si decidimos utilizar una estructura de permisos con una granularidad muy fina, nos complicaremos la gestión de los permisos (necesitaremos más tiempo), y muy probablemente penalizaremos el rendimiento de acceso a los contenidos de nuestro sitio. La idea, por tanto, pasa por aplicar el principio de que los usuarios deberían tener solamente los niveles de permisos que realmente van a necesitar.

En general, al planear la estructura de permisos para sitios de WSSv3 se recomienda empezar utilizando los grupos estándar de WSSv3: Members, Visitors y Owners, y controlar los permisos a nivel de sitio para facilitar la labor administrativa.

Planeando la herencia de permisos

Cuanto más clara es la jerarquía de permisos y la herencia, más fácil va ser la gestión de los mismos. Para lograrlo, hay que estructurar y ordenar los sitios y subsitios, librerías y listas de manera que compartan el mayor número posible de permisos. También hay que separar los datos confidenciales de los confidenciales y agruparlos en sus propias listas, librerías o subsitos. Un ejemplo de buena estructuración de un sitio que facilita la definición de la jerarquía de sitios y la herencia es el siguiente:

Objeto a Securizar

Descripción

¿Permisos Únicos o Heredados?

Sitio A

Página Principal

Únicos

Sitio A / Subsitio A

Información Confidencial

Únicos

Sitio A / Subsitio A / Lista A

Datos Confidenciales

Únicos

Sitio A / Subsitio A / Librería B

Documentos Confidenciales

Únicos

Sitio A / Subsitio B

Información de Proyecto Compartida

Heredados

Sitio A / Subsitio B / Lista B

Datos no Confidenciales

Heredados

Sitio A / Subsitio V / Librería B

Documentos no Confidenciales

Heredados

Niveles de Permisos y Grupos a Utilizar

Una de las tareas más importantes cuando se está diseñando la seguridad de sitios y contenidos en WSSv3 es como categorizar los usuarios que van a acceder a los mismos y que niveles de permisos se van a utilizar. Como comentábamos anteriormente, tenemos unos Grupos por Defecto en WSSv3 y unos Niveles de Permisos por Defecto en WSSv3.  Estos grupos y niveles de permisos que por defecto tenemos disponibles en WSSv3 están pensados para resolver las situaciones más típicas, pero podrían no ser suficientes por las características particulares de la organización en la que vamos a implantar nuestras soluciones de WSSv3.

·         Grupos por defecto en WSSv3, los grupos en WSSv3 pueden estar formados por una serie de usuarios individuales de WSSv3, corresponderse con un grupo de Windows o ser una combinación de ambos. La idead de los grupos en WSSv3 no es conferir un cierto nivel de acceso a un sitio, sino actuar como unidad de agrupación y categorización de una serie de usuarios. Por defecto, WSSv3 incluye los siguientes grupos:

 

Nombre del Grupo

Nivel de Permisos por Defecto

Nombre del Sitio \ Visitors

Read

Nombre del Sitio \ Members

Contribute

Nombre del Sitio \ Owners

Full Control

 

Además de los grupos anteriores, existen usuarios  y grupos especiales para realizar tareas a nivel de administración:

o    Administradores de Site Collection, que tiene control completo sobre todos los sitios de un Site Collection, pueden auditar todos los contenidos y recibir alertas administrativas. La creación de estos usuarios se realiza en el momento de creación de un Site Collection, y se pueden cambiar desde la Administración Central del Sitio o a nivel de Sitio.

o    Administradores de Granja, que controlan que usuarios pueden tocar la configuración del servidor y granja de servidores. Por defecto, los usuarios de este grupo no tienen acceso a los contenidos de los sitios, para ello deben configurarse como propietarios de los mismos (añadiéndoles al grupo Administradores de Site Collection). Este grupo sólo se usa desde la Administración Central de WSSv3.

o    Administradores, que son miembros del grupo de Administradores del servidor local donde tenemos instalado WSSv3 y pueden realizar, además de todas las tareas de los administradores de granja, las siguientes acciones:

    • Instalar nuevos productos y aplicaciones.
    • Desplegar Web Parts y Features en la Global Assembly Cache.
    • Crear nuevas Web Applications  y nuevos sitios Web en el IIS.
    • Iniciar / Reiniciar servicios.

·         Niveles de permisos por defecto en WSSv3, la capacidad para visualizar, cambiar o gestionar un sitio particular de WSSv3 es determinada por el nivel de permisos que se asigne a un usuario individual o un grupo. Este nivel de permisos controla todos los permisos para  el sitio y todos los subsitios, listas, librerías de documentos, carpetas, y elementos que hereden los permisos del padre. Los permisos por defecto que están disponibles son los siguientes:

 

Nivel de Permiso

Descripción de las acciones que permite

Limited Access

Permisos para visualizar ciertas listas, librerías de documentos, elementos o documentos.

Read

Permisos para visualizar elementos en las páginas del sitio.

Contribute

Permisos para añadir o modificar elementos en páginas del sito o en listas y librerías de documentos.

Design

Permisos para cambiar el layout de las páginas del sitio.

Full Control

Todos los permisos.

 

¿Cuándo necesitamos crear grupos customizados?

Básicamente, se necesitarán crear grupos customizados en las siguientes situaciones:

  • Los roles de la organización no quedan cubiertos por los grupos que por defecto ofrece WSSv3. Así, por ejemplo puede ocurrir que además de tener un Grupo de usuarios con el nivel de permisos Designer, necesitemos definir un nuevo grupo que se encargue de publicar contenidos en el sitio (Publishers).
  • Que en nuestra organización se utilicen ciertas nomenclaturas para ciertos Roles. Por ejemplo, supongamos que hemos concebido un sitio para vender los productos de nuestra organización, y queremos crear un grupo Customers para diferenciar a nuestros clientes de otros usuarios que pueden visualizar los productos.
  • Cuando se quiere tener una correspondencia uno a uno entre los grupos de WSSv3 y os grupos de usuarios de Windows.
  • Simplemente porque se prefieran otros grupos de usuarios.

¿Cuándo necesitamos niveles de permisos customizados? 

En este caso, hay que considerar las siguientes situaciones:

  • Uno de los niveles de permisos por defecto incluya todos los permisos necesarios, excepto uno o varios específicos al tipo de acciones o tareas que ciertos usuarios puedan realizar en el sitio, y que por lo tanto tienen que ser añadidos.
  • Uno de los niveles de permisos por defecto incluye un permiso que no necesitamos.
  • Se necesita excluir varios permisos de un cierto nivel de permisos, por lo que tiene más sentido definir un nuevo nivel.
  • Se necesita definir un cierto conjunto de permisos únicos para un nuevo nivel de permisos.

Escoger Grupos Seguros

Como hemos comentado, en WSSv3 podemos tener dos tipos de grupos: los propios de Sharepoint (bien grupos por defecto o creados por nosotros mismos) y grupos de Windows, que por lo tanto se basarán en la estructura de grupos de Directorio Activo.  Estos grupos se pueden añadir a WSSv3 siempre y cuando sean de tipo seguro (los grupos de Distribución no se pueden añadir directamente a Sharepoint), de manera que el AD se encargará de la sincronización correspondiente. En el caso de grupos de AD de tipo Distribución, no se pueden añadir al no ser seguros, aunque si se podrían añadir usuarios individuales (el problema de esta aproximación es que no hay sincronización, por lo que si se producen cambios en las características del usuario añadido a Sharepoint, el mantenimiento se tendrá que hacer de manera manual).

Buena Práctica: Es recomendable que los grupos de usuarios Windows a añadir permitan una gestión de permisos eficiente en WSS: (i) Sean los suficientes como para no tener que estar añadiendo grupos de manera continua. (ii) Estén lo suficientemente bien formados (en cuanto a características de los usuarios incluidos) para poder asignar adecuadamente los permisos apropiados.

Acceso Anónimo vs Acceso Autenticado

Dentro de este punto es igualmente importante determinar si queremos que todos los usuarios de nuestro dominio puedan visualizar contenidos del sitio, para lo que bastaría con garantizar acceso a todos los usuarios autenticados (y que pertenezcan al grupo de AD Domain Users Windows), de manera que no tendríamos que habilitar el acceso anónimo. También se puede dar la situación contraria, es decir, que permitamos acceso anónimo para visualizar contenidos, y que se pida autenticación para poder modificar contenidos de nuestro sitio.

El acceso anónimo debe configurarse a nivel de Web Application, de manera que los administradores del sitio podrán:

  • Habilitar el acceso anónimo a todo el sitio.
  • Habilitar el acceso anónimo solo a listas y librerías.
  • Bloquear el acceso anónimo a todo el sitio.

El mecanismo de acceso se configura desde la administración central de WSSv3: Application Management -> Authentication Providers (mi compañero Pablo ya nos comentó como configurar Sharepoint con varios modelos de autenticación).

Además, se podrían añadir políticas de permisos dependiendo de la zona en la que se haya habilitado el acceso anónimo (Internet, Intranet, Extranet u Otra) y suponiendo que la misma Web Application es la que sirve las distintas zonas. Las políticas aplicables son: None (no se aplican restricciones adicionales) Read (sólo pueden leer contenidos), Deny Write (no pueden escribir contenidos aunque se fuerce), y Deny All (no tiene acceso, aunque se haya configurado el acceso anónimo).

Nota: El acceso anónimo en WSSv3 se construye sobre la cuenta de usuario anónimo del servidor web que es creada y mantenida por el IIS (cuenta por defecto IUSR_NombreMaquina). Por lo tanto, cuando se habilita el acceso anónimo a un sitio de WSS, lo que se está haciendo es habilitar el acceso de esta cuenta a Sharepoint. El nivel de permisos que se asigna a esta cuenta es View Items, con algunas restricciones añadidas:

  • No se puede utilizar Sharepoint Designer para modificar sitios de Sharepoint (está bloqueado el RPC).
  • No pueden añadir o modificar elementos del sitio (ítems, o documentos).

Y hasta aquí llega el segundo post de la serie sobre consideraciones a tener en cuenta a la hora de diseñar y planear soluciones de WSS 3.0.

Publicado 12/4/2007 17:59 por Juan Carlos González Martín | 15 comment(s)

Archivado en:

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 2/4/2007 13:12 por Juan Carlos González Martín | 7 comment(s)

Archivado en: