Variaciones de sitio en SharePoint 2010

Una de las facetas de MOSS con las que más tuve que luchar fue con sus características multilenguaje. En entradas anteriores me habréis visto escribir sobre alguna de las carencias que tenía este sistema, y sobre cómo se podía hacer algo al respecto. Con SharePoint 2010 el salto en este aspecto es enorme. Se podría decir que en MOSS únicamente era posible trabajar en varios idiomas en entornos de publicación, mientras que en entornos de colaboración lo que se nos ofrecía era más bien escaso. A partir de ahora, con SharePoint 2010 podremos disfrutar de una interfaz realmente multilenguaje en cualquier tipo de sitio. Esta afirmación es bastante arriesgada porque todavía no disponemos de la versión final del producto y porque no he tenido tiempo de probar todas y cada una de las plantillas de sitio existentes pero, por ahora, yo me arriesgaría a pensar de ese modo.

En cualquier caso, esta entrada no habla sobre las características multilenguaje de SharePoint en general, sinó sobre las variaciones de sitio que, aparentemente, no han sufrido grandes cambios. Alguno se preguntará por qué voy a hablar de algo que no ha variado demasiado desde la versión anterior. Pues bien, os voy a explicar un cambio que sí ha habido y que es importante tener en cuenta para todos aquellos que ya habíamos trabajado con variaciones en el pasado.

Si establecéis todas las propiedades necesarias para el disponer de variaciones de sitio, llegará un momento en el que creéis las jerarquías, tal y como se muestra en la figura:

Cuando pulsemos el botón Create Hierarchies observaremos el cambio que ha habido en este sistema. En lugar de crearse una Long Running Operation se creará un Scheduled Job que se ejecutará según una planificación determinada.

¿Qué tiene esto de bueno, y qué tiene de malo? Bien, para comenzar, esto tiene bastante impacto en el rendimiento de SharePoint. Si habéis trabajado con variaciones de sitio en el pasado sabréis que esta operación cargaba los servidores hasta que el proceso terminaba correctamente. Además, si por lo que sea, la operación daba algún tipo de error, el proceso se paraba y dejaba las jerarquías inconsistentes. Tampoco era posible saber el grado de finalización de la tarea. La única manera de lanzar el proceso en un momento de baja utilización de los servidores era tener una persona para darle al botón en el momento necesario, o implementar una característica que emulara esta acción, lo cual conlleva un desarrollo bastante complejo. En fin, era un proceso bastante problemático. Pero, ¿qué tiene de malo? Yo creo que esta solución no tiene problemas, pero cuando estás desarrollando lo que necesitas es que las variaciones se creen en el preciso instante en que las necesitas. En condiciones naturales no debería importarnos esperar al día siguiente para ver el resultado de nuestro trabajo pero, ¿qué pasa si no nos podemos esperar?

Siempre podemos ir a la Administración Central de SharePoint, a la sección Monitoring / Check job status / Scheduled Jobs

Ahí veremos el trabajo que se ha creado, bajo el nombre de Variations Create Hierarchies Job Definition. Si accedemos a las propiedades de ese trabajo podremos cambiar la planificación según nuestras necesidades o incluso lanzar la tarea manualmente pulsando el botón Run now.

Además, si accedemos a la sección Monitoring / Check job status / Running Jobs podremos ver el estado en el que se encuentra la tarea. No sabremos cuanto tiempo queda exactamente para completar el trabajo, pero tendremos una idea aproximada del punto en el que se encuentra.

En resumen, un pequeño cambio que debería mejorar el tratamiento de las variaciones de sitio y nuestro control sobre éstas.