¿Debe morir el fichero ‘Web.config’ en SharePoint on-premise?

El fichero Web.config, es un mecanismo muy versátil a la hora de configurar y paramétrica ciertas propiedades de SharePoint on-premise, como los desarrollos personalizados. La mayoría de las configuraciones establecidas en el fichero, están enfocadas en un principio a las secciones connectionStrings y appSettings.

No se hace referencia a otras secciones del fichero Web.Config, como puede las configuraciones a servicios de terceros, configuraciones de la autenticación por formulario (FBA) o la activación de los portales en modo anónimo para portales públicos, simplemente porque estas configuraciones se realizan mucho antes que el portal salga a producción.

Teniendo en cuenta el enfoque principal que se suele dar al fichero Web.Config y tras muchos años trabajando con las versiones on-premise de SharePoint (2003/2007/2013), la conclusión que desprendo con mi experiencia es que debe morir definitivamente. No me refiero a que Microsoft elimine el fichero del IIS, sino que no se debería modificar, salvo por contadas excepciones.

A la hora de trabajar con el fichero Web.config, hay que tener en cuenta los siguientes aspectos:

• Su accesibilidad en la granja. Normalmente la manipulación de los ficheros recae sobre el equipo de IT de la organización, con todo lo que conlleva la coordinación entre departamentos.

  • Las intervenciones en las granjas lo marca el calendario del equipo de IT, tanto en día y hora.

  • Elaboración de manuales detallados para el equipo de IT, donde se especifica los pasos a realizar.

  • Prácticamente el 99% de las modificaciones se realizan de forma manual sobre el fichero y puede producirse algún fallo humano.

  • Los equipos de IT, por seguridad en la organización, suelen encriptar los ficheros, con lo que puede provocar más problemas.

• Su topología en la granja. Por norma general las granjas de SharePoint constan de cuatro servidores, distribuidos en dos frontales y dos aplicaciones. Pero dependiendo del negocio de la organización, suele haber muchos más frontales. Esto podría provocar que algún nodo de la granja no quedase actualizado correctamente.

• Su actualización, por mínimo que sea, supone una caída de servicio, por un par de minutos, hasta que todos los servicios de SharePoint on-premise, se restablecen. Si el negocio de la organización es imprescindible que sus servicios dispongan de una alta disponibilidad, este factor puede ser muy crítico. Pensar en las empresas dedicadas a la comprar/venta de productos online.

Teniendo en cuenta estos aspectos negativos del fichero Web.config, ¿qué alternativas viables, se podría aplicar para evitar todas o al menos las más críticas?.

Con las herramientas de básicas de las que se suele disponer, es decir, nuestra propia granja de SharePoint on-premise en la organización, se pueden aplicar las siguientes alternativas al fichero Web.Config:

• Configuraciones a nivel de SQL Server
• Configuraciones a nivel de lista de la colección de sitios
• Configuraciones a nivel de property bag de las colecciones de sitio

Configuraciones a nivel de SQL Server

Las configuraciones a nivel de SQL Server, suelen tener como ventaja las siguientes características:

• Son versátiles de la hora de crear repositorios de configuraciones.

• Proporcionan una centralización de las configuraciones, ya que así todos los frontales de la granja acceden al único repositorio de configuraciones.

• Se puede acceder en su totalidad o parcialidad a las configuraciones establecidas.

Pero a la vez que se establece este mecanismo de configuración, se sigue manteniendo algunos factores negativos con respecto al fichero Web.Config:

• Se mantiene la dependencia con el equipo de IT para su creación y manipulación.

• Se sigue manteniendo un punto de entrada en el Web.Config para poder conectarnos con el SQL Server.

• No se recomienda, implementar bases de datos externas, dentro del SQL Server de SharePoint. Con lo que, si se coloca en un SQL Server de otra granja, hay más dependencias del equipo de IT. Hay que tener en cuenta estos aspectos.

  • La comunicación entre granjas.

  • Los mantenimientos en otras granjas ajenas a las de SharePoint. Si el mantenimiento es en la granja de SharePoint, el tráfico se pasaría a la granja de contingencia, con lo que el servicio no se quedaría interrumpido.

• Mas recursos por parte del equipo de IT, para el mantenimiento y backpup de la nueva base de datos.

• No se dispone de in interfaz de usuario para una visualización clara de las configuraciones.

Configuraciones a nivel de lista de la colección de sitios

Las configuraciones a nivel de lista de la colección de sitios suelen tener como ventaja las siguientes características:

• Son versátiles a la hora de crear repositorios de configuración, ya que se pueden crear a nivel de colección de sitios o a nivel de un subsitio dentro del portal web en SharePoint.

• Proporcionan una centralización de las configuraciones, ya que así todos los frontales de la granja acceden a la misma base de datos de contenidos de SharePoint.

• Se puede acceder en su totalidad o parcialidad a las configuraciones establecida.

• Desaparece la dependencia con los equipos de IT de la organización para su mantenimiento y actualización.

• Los planes de mantenimientos de las listas de configuración están integradas en los planes de mantenimiento de los portales web de SharePoint.

• Posibilidad de colocar dependencias de cache a las listas de configuración, que hacen que, al detectar una actualización en las configuraciones, se elimine de la cache el contenido final y se vuelva a generar el contenido con las nuevas configuraciones establecidas, siendo trasparente para los usuarios finales.

• Se dispone de un interfaz de usuario integrado, ya que sería el mismo que se usa para la visualización de cualquier otra lista de SharePoint. Y si se agrupa las configuraciones por categorías, se mejora notablemente el mantenimiento de las configuraciones establecidas.

• Se puede almacenar las configuraciones sensibles de forma encriptada, para una mayor seguridad.

• Se puede aplicar configuraciones diferentes, dependiendo del nivel de permisos del perfil de usuario.

Pero a la vez que se establece este mecanismo de configuración, hay que tener en cuenta algunos factores negativos de este tipo de configuraciones:

• Al migrar una base de datos de contenido de un entorno a otro distinto, te llevas las configuraciones de ese entorno. Se puede reconfigurar de una forma fácil y sencilla, las configuraciones necesarias para el nuevo entorno. La recomendación en estos casos es usar plantillas de SharePoint PnP, para reconfigurar entornos.

• Aunque las configuraciones están centralizadas en un solo lugar, no hay conectividad entre colecciones de sitio. Pero dependiente de las necesidades del negocio, se puede plantear alternativas similares con algún tipo de desarrollo. .

Configuraciones a nivel de property bag de las colecciones de sitio

Las configuraciones a nivel de property bag, consiste en almacenar las configuraciones a nivel de los objetos SPStie, SPWeb o SPItem. Estos objetos disponen de una propiedad muy similar al objeto HashTable donde se almacenan información o configuraciones. Las ventajas que proporciona son las siguientes:

• Los rendimientos de acceso a la información son muy buenos, teniendo en cuenta que no se realizan consultas CAML.

• Proporcionan una centralización de las configuraciones, ya que así todos los frontales de la granja acceden a la misma base de datos de contenidos de SharePoint.

• Se puede acceder en su totalidad o parcialidad a las configuraciones establecida.

• Desaparece la dependencia con los equipos de IT de la organización para su mantenimiento y actualización.

• Los planes de mantenimientos de las de configuración están integradas en los planes de mantenimiento de los portales web.

• Se puede almacenar las configuraciones sensibles de forma encriptada, para una mayor seguridad, pero teniendo en cuenta que no dispone de interfaz usuario, no sería en un principio necesario.

Pero a la vez que se establece este mecanismo de configuración, hay que tener en cuenta algunos factores negativos de este tipo de configuraciones:

• No existe la versatilidad a la crear este tipo de repositorio, ya que se usan los propios objetos de SharePoint, para almacenar las configuraciones.

• No se dispone de un interfaz de usuario, para mantener las configuraciones, por lo que hay que usar script para su mantenimiento. Se disponen de herramientas de terceros, para disponer de un interfaz.

• Al migrar una base de datos de contenido de un entorno a otro distinto, te llevas la configuración, pero con un simple script, se puede actualizar las configuraciones correspondientes al nuevo entorno.

• Aunque las configuraciones están centralizadas en un solo lugar, no hay conectividad entre colecciones de sitio. Pero dependiente de las necesidades del negocio, se puede plantear alternativas similares con algún tipo de desarrollo.

• Por defecto, los objetos que usan las property bag ya tienen otras configuraciones establecidas por el SharePoint, por lo que una mala gestión de las propiedades puede perjudicar al portal web.

¿Qué otras implicaciones rodean al fichero Web.Config?

Antes de tomar una decisión sobre las alternativas de la propuesta, hay que tener otros factores ajenos a las características del fichero Web.Config, que puede determinar la viabilidad en el proyecto hacia el cambio.

• Si el proyecto se realiza en una aplicación web nueva y no se dispone de ninguna dependencia, no debería de haber problemas en aplicar alguna de las alternativas propuestas.

• Si el proyecto se realiza sobre un portal web ya en producción, hay que estudiar como poder afrontar el cambio, con la menor repercusión sobre la calidad del servicio que se ofrece. Se pueden afrontar de las siguientes formas:

  • A través de una pequeña nueva funcionalidad a desarrollo, para disponer de un feedback y posteriormente evaluar su eficacia, para futuros desarrollos y mantenimientos.

  • A través de solicitudes del cambio a funcionalidades actuales en producción.

  • A través de pequeñas refactorizaciones, que se suelen realizar para optimizar los procesos que se realizan en el portal web.

• Si el proyecto se realiza sobre un conjunto de portales interconectados o con funcionalidades parecidas pero parametrizables, es muy parecido al caso anterior, pero con la decisión de donde ubicar las configuraciones comunes y el mecanismo para poder acceder de forma independiente a las configuraciones comunes.

La decisión final

La verdad es que no hay solución definitiva, ya que en todas las alternativas hay algún factor negativo que deberá asumir la organización. Por lo que la decisión final de implementar una alternativa al fichero Web.Config como repositorio de configuraciones recaerá en exclusividad de las necesidades reales de la organización con los portales web en SharePoint.

Recordad que si se migra las aplicaciones de SharePoint on-premise a SharePoint online, no se dispone fichero Web.Config, con lo que alguna alternativa hay que evolucionar.