SharePoint: ¿Donde guardamos los datos de configuración de nuestra App?

Muchas veces a la hora de realizar cualquier desarrollo es necesario disponer de ciertos parámetros que deben de poder cambiar de forma relativamente simple, éstos pueden ser modificados dependiendo de necesidades del negocio o dependiendo del entorno en el que nos encontremos. Ejemplos de esto puede ser una cadena de conexión a una base de datos, la url de un servicio web o bien el grupo de seguridad que tiene que aprobar un determinado flujo. En este post vamos a ver que opciones disponemos para guardar estos campos dentro del contexto de SharePoint.

Vamos a empezar enumerando las opciones que disponemos:

• Almacenar la información en el Web.Config
• Crear listas ocultas con los valores de configuración
• Configuración del WebPart
• Mediante Property Bag
• Mediante Magic String en el propio desarrollo (Esta opción ni os debe de pasar por la cabeza )

1.- Almacenando la información en el Web.Config

Esta opción es la más simple, pero también la menos profesional de todas. Si estamos desarrollando un producto no es nada profesional que tengamos estos valores en el Web.Config. Motivos:

• Estos valores pueden ser modificados por cualquier Administrador del sistema.
• Si la web, sufre un ataque y acceden al Web.Config es posible que incluso puedan obtener información de nuestra aplicación

Además, el Web.Config en una de estas modas hipster tiene los dias contados. Ahora cada desarrollador/producto puede elegir su fichero de configuración y no necesariamente tiene que ser un web.config. Quien quiera leer un poco más información al respecto recomiendo este post del maestro Jose Maria Aguilar

2.- Crear listas ocultas con los valores de configuración

Al utilizar esta opción, estamos utilizando elementos naturales de SharePoint. Creamos una lista y le añadimos los campos que necesitemos con sus respectivos valores. Podemos acceder a la lista utilizando las API de SharePoint, los usuarios desde la interfaz gráfica no se dan cuenta de que esta lista existe. Esta opción es utilizada por la propia Microsoft para almacenar diversos valores utilizados en nuestro servidor favorito. Si alguien tiene curiosidad que se descargue la herramienta SharePoint Manager y que observe cuantas listas ocultas hay en un Site Collection.

La principal desventaja que tiene esta forma es que una lista no esta pensada como lugar para almacenar información, su acceso no es el más rápido posible, además dependiendo de si esta configuración puede ser compartida por más de un site collection debemos de duplicar la lista y mantener la información en dos sistemas. Como ejemplo  tengo un site de Tareas, y queremos tener el número de tareas asignadas al usuario que esta logado en cualquier aplicación de la organización. De acuerdo a esta opción tengo que desplegar una lista en cada Site que tenga e introducir la url del Site de Tareas. Ahora bien dado un requerimiento de negocio, se modifica la ubicación de las tareas y esta en otro Site. El mantenimiento de todas estas listas es algo que no es muy mantenible.

3.- Mediante Propiedades de nuestro WebPart

Esta opción es ideal para pequeños WebParts en los que es necesario cierta interacción con el usuario, es la forma en la que Microsoft indica que añadamos los parámetros de configuración. Para ello con añadir las siguientes lineas dentro del code behind del WebPart lo tendríamos implementado:

  [Category("Configuración"),
        Personalizable(PersonalizationScope.Shared),
        WebBrowsable(true),
        WebDisplayName("Número de elementos"),
        WebDescription("Introduce el número de elementos a mostrar.")]
        public int NumElementos
        {
            get
            {

            }
            set
            {

            }
        }

Ahora bien esta opción, como principal ventaja tiene que es muy simple de modificar, no hace falta volver a actualizar la solución, y tan solo con ir a las propiedades del propio WebPart lo podemos de modificar. Ahora bien su principal defecto, es que los parámetros de configuración pueden ser visibles por todo el mundo, por lo que si queremos añadir una cadena de conexión como propiedad, esta puede ser accesible por personas que no deberían (siempre que tengan ciertos «permisos» dentro del site colection). Además si este WebPart lo estamos utilizando en más de una página el mantenimiento del mismo también se puede volver una locura.

4.- Mediante Property Bag
Lo primero de todo vamos a definir que es una «Property Bag», es un lugar donde podemos almacenar cualquier clave-valor dentro de SharePoint. Las propertys bugs pueden almacenar y recuperar la configuración en los siguientes niveles:

• Farm Level – SPFarm
• Web Application Level – SPWebApplication
• Site Collection Level – SPSite
• Site Level – SPWeb Level
• List Level – SPList
• Item Level – SPListItem

Para crear estas propertys las podemos hacer utilizando tanto código C#,PowerShell o JavaScript.

SPSecurity.RunWithElevatedPrivileges(delegate()
{
    using (SPSite currentSiteCollection = new SPSite("http://myserver"))
    {
        using (SPWeb currentWeb = currentSiteCollection.OpenWeb())
        {
            currentWeb.AllowUnsafeUpdates = true;
            if (!currentWeb.AllProperties.ContainsKey(key))
                currentWeb.Properties.Add(key, value.Value.ToString());
            else
                currentWeb.AllProperties[key] = value;
            currentWeb.Properties.Update();
            currentWeb.AllowUnsafeUpdates = false;
        }
    }
});

Además mediante SharePoint Designer (en una de sus pocas utilidades) se puede consultar/modificar/añadir estas propiedades:

Como podemos observar, podemos crear/consultar todas estas propiedades independientemente del contexto en el que se estén ejecutando. Se pueden compartir propiedades entre distintos «Site Collection». Están ocultas para todos los usuarios del sistema y la modificación de las mismas solamente las pueden hacer aquellas personas que sean encargadas para ello (administradores de SharePoint o encargados del desarrollo)

Conclusión

Hay muchas opciones para poder almacenar los datos de nuestra aplicación, hay muchas opciones. Por lo descrito la mejor opción es Property Bug, pero no es la única forma y el utilizar otra alternativa no tiene porque estar mal. El utilizar las propiedades que hay dentro de un WebPart es una alternativa que podemos utilizar en muchas ocasiones. Ejemplo: tengo un WebPart que lee de una fuente de RSS. ¿Donde almaceno la fuente de RSS? Sin más requisitos, la mejor opción en este caso es utilizar las propiedades del WebPart. Ahora bien pongamos por ejemplo que hemos implementado una SPA y en nuestra capa de servicio tenemos que buscar determinados grupos de seguridad propios de SharePoint. Esta claro que en este caso, la opción que se recomendaría seria la utilización de las Property Bugs. Como en muchos aspectos relacionados con el desarrollo del software, el desarrollo hay que ponerlo en el contexto en el cual se implementa.