Una de las novedades de SharePoint 2010 es la posibilidad de crear artefactos de SharePoint 2010 en modo SandBox, es decir, que se ejecuten en un entorno aislado de manera que si hay algo erróneo en los mismos, no se afecte a la granja completa sino a un nivel inferior. Ese nivel inferior es el que determinan las Colecciones de Sitios ya que son los administradores de las mismas los encargados de subir y cargar las soluciones SandBox. De esta forma, si el artefacto desplegado presenta un problema que introduzca una penalización en el rendimiento, alguna mala práctica de codificación o la simple violación de una regla, únicamente afectará a la Colección de Sitios donde se haya activado.
Precisamente al ser los administradores de la Colección de Sitios los encargados de subir y activar esta solución introduce otra ventaja: no es necesario recurrir al administrador de la granja para que despliegue este tipo de soluciones. De esta manera, se puede dedicar a monitorizar que soluciones están dando problemas en una cierta Colección de Sitios, monitorización que por otro lado es realizada automáticamente por el sistema que se encarga de generar los correspondientes avisos y bloquear aquellas soluciones SandBox que estén dando problemas. Por otro lado, este tipo de soluciones vienen a resolver el problema que se encontraban los administradores de SharePoint a la hora de desplegar estos artefactos: como securizarlos. Una solución de tipo SandBox se ejecuta de forma segura per sé y evita estos quebraderos de cabeza a los administradores. En este primer post sobre soluciones de tipo SandBox veremos cuales son sus características principales.
¿Qué artefactos se pueden crear en modo SandBox?
Básicamente aquellos que no impliquen que se tiene que subir archivos a disco o ensamblados a la GAC. Por lo tanto, no podremos crear web parts de tipo visual. Estos artefactos son:
- Web Parts clásicas.
- Listas.
- Plantillas de lista.
- Acciones personalizadas.
- Workflows
- Manejadores de eventos.
- Tipos de contenidos.
- Columnas de Sitio.
¿Cuál es el límite que tengo en mis desarrollos a nivel de modelo de objetos?
Pues básicamente, dentro de una solución SandBox sólo se permite desarrollar desde el nivel de Colección de Sitios hacía abajo. Además, hay restricciones como que no es posible utilizar SPSecurity y otras clase de seguridad. Asimismo, no es posible crear colecciones de sitios con SPSite. Visual Studio 2010 se encarga de ocultar en el intellisense el que se pueda hacer uso de estas clases…ahora bien, como veremos, esta limitación se puede superar de forma sencilla :-(.
Probando las prestaciones de las soluciones SandBox
Para probar las prestaciones de las soluciones SandBox, voy a crear una WebPart clásica en la que incumpla alguna de las condiciones comentadas. En mi caso, voy a hacer uso de SPSecurity:
-
Para ello, en primer lugar he creado un proyecto vacío de SharePoint 2010.
-
En el asistente de creación del proyecto he indicado que el despliegue se va realizar en modo SandBox.
-
A continuación he añadido un nuevo elemento al proyecto de tipo Web Part (la clásica) al proyecto.
-
En el método CreateChildControls() de la Web Part, he intentado hacer uso de SPSecurity, pero el intellisense de Visual Studio 2010 no me lo mostraba por ningún lado como era de esperar, ya que no se permite su uso en soluciones de tipo SandBox.
-
Ahora bien, nada impide que añadamos SPSecurity porque conocemos esta clase y entonces el intellisense si que aparece…mi gozo en un pozo :-(. Una clase que está prohibida en las soluciones de tipo SandBox se puede usar sin problemas, ya que no se hace ningún tipo de chequeo en tiempo de codificación y de compilación de que el código que se está utilizando sea permitido o no. El problema viene dado porque nuestro proyecto tiene una referencia al ensamblado Microsoft.SharePoint.dll almacenado en la carpeta ISAPI, es decir, a todo el modelo de objetos de SharePoint.
-
Pero veamos que pasa si la usamos. Para ello, en el método CreateChildControls de la Web Part he añadido el siguiente código:
|
base.CreateChildControls();
Label lblData = new Label();
SPSecurity.RunWithElevatedPrivileges(delegate
{
lblData.Text = "This shouldn’t work";
});
this.Controls.Add(lblData);
|
Usando la Web Part en un Sitio de SharePoint 2010
Para utilizar una Web Part creada en modo SandBox, tenemos que:
-
Navegar hasta la administración de la Colección de Sitios dónde se ha desplegado.
-
Dentro de la sección Galerías, hacemos clic en Soluciones. Esta biblioteca especial contiene todas las soluciones de tipo SandBox (por supuesto, son archivos .WSP) que se hayan desplegado en la Colección de Sitios.
-
Comprobamos que nuestra WebPart aparece y está activada (Visual Studio activa la Web Part en el proceso de despliegue…realmente activa la característica correspondiente.
-
Si ahora utilizamos nuestra Web Part en nuestro Sitio de SharePoint 2010, veremos que se muestra un error…estamos utilizando un objeto no permitido, es decir, en tiempo de ejecución si que se comprueba que el código del artefacto desplegado esté utilizando elementos permitidos.
¿Cómo evito estas situaciones?
Esta es la pregunta que muchos os estaréis haciendo, y la respuesta es que de dos formas:
-
La primera es marcar a fuego a tu equipo de desarrollo de SharePoint que cuando creen soluciones SandBox utilicen la librería Microsoft.SharePoint.dll contenida en [..]\14\UserCode\Assemblies\Microsoft.SharePoint.dll que contiene aquellos elementos del modelo de objetos de SharePoint 2010 que se pueden usar en soluciones SandBox. De esta forma, se evita que se usen objetos no permitidos ya que Visual Studio 2010 mostrará el correspondiente error. Luego, cuando el artefacto de SharePoint 2010 esté concluido cambiamos la referencia por la original y que contiene toda el modelo de objetos de SharePoint 2010. Cómo veis, el error que se muestra es que SPSecurity no existe en el contexto actual.
-
La segunda es crear un validador de soluciones SandBox que en el proceso de despliegue de la solución analice el código y no active la solución en el caso de detectar algo erróneo. SharePoint 2010 por defecto incluye un validador, pero no chequea el código. Si chequea por ejemplo que no se esté intentando desplegar un artefacto que requiera copiar archivos en disco o ensamblados en la GAC.
Y hasta aquí llega este primer post sobre soluciones SandBox. Espero que os haya parecido interesante.
Pasión por la tecnología... 