martes, 4 de marzo de 2014

¿Cómo mover un sitio sin perder la historia?

Introducción

El objetivo de esta prueba es identificar y validar un método para mover un sitio dentro de la estructura de sitios sin perder datos de la historia.

Escenario:

  • Tenemos una colección de sitios de nivel superior llamada “PADRE”
  • Tenemos un sitio hijo llamado “HIJO” y un sitio hijo de este hijo llamado “NIETO”.

image

El objetivo es subir un nivel en la estructura a NIETO sin que se pierda la historia:

image

No perder la historia incluye:

  • Historial de modificación de documentos (fechas y usuarios)
  • Flujos de trabajo y su historial de aprobaciones
  • Permisos (asumiendo que se heredan, aunque pueden existir permisos exclusivos)


Ambiente

Para realizar esta prueba, creamos un ambiente con las siguientes características:

  • Windows Server 2008 R2
  • SQL Server 2008 R2
  • SharePoint Server 2010 Enterprise

 

Paso 1 - Creación de sitios

A partir de una colección de sitios existentes, creamos primero el sitio HIJO, heredando permisos del padre:

image

Luego creamos un sitio NIETO, heredando los permisos de HIJO. Obtenemos una estructura como la siguiente:

image

 

Paso 2 - Creación de Información

En este segundo paso, vamos a crear la historia del sitio NIETO:

  • Listas
  • Flujo de trabajo
  • Carga de datos y ejecución del flujo de trabajo

 

Creación de Listas

Creamos una biblioteca de documentos y una lista de tareas.

image

A estas dos listas, les activamos el control de versiones:

image

image

 

Creación de Flujos de Trabajo

Creamos un flujo de trabajo para la biblioteca de documentos. Es un flujo sencillo que tienes los siguientes pasos al momento de subir un documento:

  1. Asigna una tarea a un usuario
  2. Registra un evento en el historial

image

Definimos las opciones del flujo de trabajo para que se dispare automáticamente al momento de subir un documento:

image

 

Carga de datos y ejecución del flujo de trabajo

Trabajamos primero con el Documento 1:

  • Subimos el documento
  • Completamos la tarea asignada por el flujo de trabajo
  • Más tarde hacemos una modificación al documento

La historia del flujo de trabajo muestra:

image

La historia del documento muestra la creación y una modificación posterior:

image

La historia de la tarea muestra la creación y la modificación cuando se ejecutó el flujo de trabajo:

image

 

Paso 3 - Ajustes de la seguridad

Ajustamos la seguridad utilizando el siguiente criterio:

  • El sitio hereda permisos
  • La lista de documentos hereda permisos
  • La lista de tareas posee permisos exclusivos, según se muestra en la siguiente imagen:

image

 

Movimiento del sitio

Introducción

Para realizar el movimiento del sitio, vamos a trabajar con la opción Contenido y Estructura dentro de la Configuración del Sitio:

image

Dentro de esta opción, utilizaremos el comando Mover.

 

Pasos para mover el sitio

Una vez dentro de la estructura, veremos reflejada la actual jerarquía:

image

Abrimos la lista desplegable de NIETO y elegimos la opción MOVER:

image

Aparecerá un cuadro de diálogo para elegir el sitio destino, elegimos PADRE:

image

Presionamos aceptar y esperamos... Luego veremos reflejada la nueva estructura:

image

 

Verificaciones

Movimiento dentro de la estructura

Lo primero que se observa es que NIETO ya no es hijo de HIJO:

image

Seguridad

Se observa que se mantuvieron las configuraciones de seguridad:

  • Permisos heredados en el sitio y la lista de documentos
  • Permisos exclusivos en la lista de tareas

Historial de Versiones

Al verificar el historial de versiones del Documento 1 se observan los mismos valores que antes:

image

Lo mismo sucede den el historial de versiones de la tarea:

image

Historial de Versiones en el Flujo de Trabajo

En la siguiente pantalla se ven los detalles de la historia del flujo de trabajo con los mismos usuarios y fechas:

image

Movimiento del Flujo de Trabajo

Abrimos SharePoint Designer y vemos que el flujo de trabajo existe:

image

El segundo paso es subir un segundo documento al sitio, para verificar que el flujo de trabajo funcione correctamente. Para ello luego de subirlo, completamos la tarea asignada. El resultado es el siguiente:

image

Por último, volvemos a abrir SharePoint Designer y modificamos el flujo de trabajo agregando un tercer paso. Publicamos y vemos que todo funciona sin problemas:

image

Subimos un tercer documento y verificamos que el flujo de trabajo se ejecuta sin problemas:

image

 

Conclusión

En esta prueba se observa que SharePoint 2010 permite mover sitios dentro de la estructura manteniendo la historia de la información. Es una prueba de laboratorio sencilla sin estructuras complejas.

Antes de avanzar con este método en un ambiente productivo, es conveniente revisar las particularidades de cada caso, hacer las pruebas en un ambiente de QA y tomar los recaudos necesarios de copias de seguridad.

2 comentarios:

Buenos días Juan Pablo. Quería consultarte sobre el tema de versiones que aquí nombras.
Por que cuando se aprueba un flujo de trabajo aparece que quien aprueba es "cuenta del sistema"? En nuestro caso necesitamos mantener el historial de versiones y guardar quien aprueba cada publicación. Trabajamos con SP 2013 y nos ocurre esto de que cuando se aprueba el WF aparece este usuario. Sabés por que aparece así?
Gracias por tus aportes! Saludos
Juana

Hola María. ¿Es posible que el workflow tenga un "impersonation step"?

Publicar un comentario en la entrada