Esta semana SharePoint vuelve a estar en boca de todos por el reciente artículo publicado en los blogs de Office sobre la esperada nueva versión de SharePoint llamada SharePoint 2016. Uno de los cambios que veremos en esta nueva versión, y del que Microsoft nos lleva avisando desde hace unos meses, es el relativo a la extensibilidad de SharePoint. Todo apunta a qué el mensaje oficial de Microsoft es que hay que tratar de abandonar el clásico modelo de desarrollo basado en el Framework de Featurres (Caracerísticas) por el modelo Remote Provisioning que supone dejar de usar código CAML para provisionar elementos en SharePoint y hacer uso de código, y en concreto del Modelo de Objetos en Cliente…¿Cuáles son las razones de Microsoft para esta recomendación? Pues las ya conocidas, facilitar la transición a la nube desde soluciones SharePoint OnPremises en primer lugar, reducir (como me ha comentado muchas veces mi amigo Alberto Díaz) la complejidad en las actualizaciones y migraciones entre versiones de SharePoint. Evidentemente, este cambio de paradigma nos hace retroceder todo lo que se ha ganado en productividad en desarrollo para SharePoint a través de las herramientas de desarrollo incorporadas por Microsoft desde Visual Studio 2010 para el desarrollo de soluciones SharePoint (diseñador de soluciones, diseñador de características, asistentes para crear listas y tipos de contenido de forma declarativa, etc) ya que nos lleva a un modelo que implica “picar” código y que ahora mismo no cuenta con unas herramientas que faciliten el desarrollo…en definitiva, la curva de aprendizaje en lo que a desarrollo SharePoint se refiere vuelve a hacerse “pindia” como dicen en Cantabria.
El nuevo patrón de desarrollo remote provisioning nos lleva a crear procesos que de forma remota se encarguen de ir creando todos los elementos que forman parte de una Solución SharePoint: Colecciones de Sitios, Sitios, Columnas de Sitio, Tipos de Contenido, Listas y Bibliotecas, etc. El modelo en sí no es tan nuevo como se menciona en el post indicado más arriba y ya disponemos de ejemplos sobre como hacer este provisionado remoto:
-
Código .NET ejecutándose en una Aplicación de tipo Provider-Hosted que utilice CSOM o la API REST para crear contenido en SharePoint. Como ya sabéis, Microsoft cuenta con un equipo de Patterns and Practices que ha creado un montón de ejemplos al respecto.
-
Código .NET ejecutándose simplemente en una Aplicación de Consola que utilice CSOM o la API REST para crear contenido en SharePoint.
-
Scripts PowerShell en los que se haga uso o bien de CSOM o de la API REST para crear contenido en SharePoint. Podéis encontrar ejemplos de scripts en el siguiente proyecto de Codeplex: http://sharepointpowershell.codeplex.com/
- Llamadas REST / JSOM en el lado del cliente desde código JavaScript en aplicaciones de tipo SharePoint-Hosted.
Junto con la referencia a la nueva técnica de provisionado, Microsoft está creando numerosos recursos para facilitar la transición a la misma:
-
Curso de Microsoft Virtual Academy sobre como introducir personalizaciones haciendo uso del modelo de Aplicaciones.
-
La Wiki de los ejemplos de Patterns & Practices comentados: https://github.com/OfficeDev/PnP/wiki.
-
El Grupo dentro de la Office 365 Network creado para estas cuestiones.
Y finalmente, la pregunta del millón: ¿Se van a “deprecar” en el corto plazo las soluciones de tipo Granja?
La respuesta a una pregunta tan peregrina es que “No en principio”, simplemente la base de clientes actualmente OnPremise es tan grande que en mi opinión es impensable a día de hoy que Microsoft nos sorprenda deprecando las soluciones de tipo granja para entornos OnPremises. Lo que si tenemos que hacer es evitar el uso del Framework de Features en dichas soluciones y en la medida de lo posible diseñarlas y desarrollarlas pensando en qué se puedan portar muy fácilmente a Apps.
Pasión por la tecnología... 