Programar para SharePoint hoy (I): el legado

En esta serie de posts intentaré hacer un resumen de las posibles opciones que tiene un desarrollador (o desarrolladora) para programar una aplicación que tenga que comunicarse de algún modo con SharePoint, en cualquiera de sus variantes.

<ModoAbueloCebolleta> En los tiempos en los que los dinosaurios vagaban por la Tierra, el ser humano vivía en cuevas y SharePoint era novedad todavía, para programar tenías dos opciones. Cada nueva versión de SharePoint traía algún modo nuevo, así que hoy en día tenemos bastante elección y a veces se hace difícil saber que enfoque es el mejor para una situación dada. Por favor...que viejo me siento contando batallas. ¡Que alguien me sacrifiqueeeee! </ModoAbueloCebolleta>

El legado

Desde que SharePoint corre sobre .NET Framework (es decir desde su versión 2003), hay dos métodos de desarrollo que están todavía presentes sin muchos cambios. Son el "full-trust code" (FTC) y los servicios web SOAP (o ASMX).

Full-Trust Code o SSOM (Server-Side Object Model)

Full-Trust Code o SSOM es el modelo de programación de SharePoint donde nuestro código se ejecuta dentro de los procesos de SharePoint (IIS y/o servicios Windows), como una parte adicional al propio código de Microsoft, para lo bueno (la velocidad) y lo malo (hundir el rendimiento de SharePoint mismo).

Este es el modelo "clásico" de los programadores SharePoint "de los de antes". Si eres uno de ellos, tengo una mala noticia y otra buena.

La mala es que este modelo es cada vez menos relevante en los desarrollos de SharePoint. Así que si tu idea de especialización era focalizarte en código de SharePoint y te memorizabas las listas de los objetos que empiezan por SP*, tendrás que reciclarte, ¡y pronto!

La noticia buena es que FTC no desaparecerá. Siempre habrá alguna funcionalidad que es necesaria para los desarrollos de SharePoint on-premises, y no habrá otra solución tan elegante y eficiente que el código de SharePoint en el mismo servidor de SharePoint. Vaya..que saber SSOM será el equivalente de programadores COBOL en el siglo XXI.

Las limitaciones serias de este modelo son tener que desplegar en los servidores de SharePoint (y dar ataques al corazón a los administradores de sistemas cuando les explicas que necesitas un Visual Studio en el servidor), usar autenticación implícita (tu código se ejecutará con los permisos del usuario actual) y que no es compatible de ninguna manera con SharePoint Online de Office 365.

Los servicios web SOAP

Evidentemente, alguien siempre ha tenido la necesidad de integrar SharePoint con otros sistemas (¿qué otros sistemas hay? diría algún SharePointero "de los de antes"). En los tiempos en los que nació SharePoint, eso significaba usar el lenguaje universal de la web: los servicios web SOAP (o ASMX, por la extensión del fichero ASP.NET en los que se programan).

SharePoint incluye una capa de servicios web SOAP, accesibles a cualquier plataforma que sepa hacer una llamada SOAP (y que pueda autenticar el usuario correctamente, claro está). Las operaciones que expone son bastante de bajo nivel, y con muchos parámetros obligatorios, y para muestra sólo hay que mirar la documentación de los estándares. Hablando en claro, son prehistóricas.

Hoy en día han quedado bastante en desuso ya que el modelo de REST API los hace casi obsoletos. Sin embargo, es posible que todavía haya cosas que se pueden hacer con los servicios web y con la API REST no, así que es posible (pero no probable) que tengas que recurrir a ellos.

En el siguiente post expondré las opciones modernas de desarrollo con SharePoint.