La forma en la que desarrollamos en SharePoint/Office 365 está cambiando a pasos agigantados. A parte del modelo de desarrollo, los flujos de trabajo y tareas en Background (algo que esta mejorando mucho), hemos pasado de los Event Receviers, Tareas Programadas en la Administración Central, al uso de WebHooks y Azure Functions. En este artículo vamos a ver cómo utilizar Azure Functions de forma óptima, como solucionamos el tema de la autenticación y en qué escenarios lo podemos incluir.
¿Qué es Azure Functions?
Por decirlo de una forma simple, Azure Functions es la implementación que ofrece Microsoft para llevar a cabo una arquitectura «Servesless», es decir, arquitectura sin servidor.
Se caracteriza porque nuestro código se va a ejecutar en algún lugar del cloud y solo vamos a pagar por el tiempo que esté en ejecución. Es el máximo exponente de llevar un desarrollo al cloud y maximizar los beneficios que nos aporta.
Si queréis introduciros en los conceptos base de Azure Functions podéis consultar otros artículos que hemos escrito en nuestro blog dedicado al cloud.
En qué escenarios podemos utilizar Azure Functions
El escenario típico, es cualquier entorno de Office 365, ya que no disponemos de acceso a la Administración Central para programar una tarea que se ejecute de forma periódica.
Por ejemplo: todas las noches queremos importar los datos de nuestros clientes en una lista de SharePoint, o bien queremos enviar un mail con información de nuestra actividad.
Otro escenario en el que podemos utilizar Azure Functions, es para responder a determinadas acciones que se han producido bien en otras aplicaciones, bien en nuestro propio SharePoint Online: Queremos enviar un mail cada vez que se inserte un elemento en una determinada lista. Para este caso, nos suscribimos al propio WebHook que nos ofrece SharePoint Online y que ahí ejecute nuestro código. También podríamos implementar el cliente de WebHook que esté permanentemente a la escucha. No obstante, por un lado tenemos que pensar que éste cliente debe estar alojado en algún sitio y debemos encargarnos de su mantenimiento, por lo que sería más costoso en esfuerzo y en recursos económicos.
Es decir, Azure Functions no solo lo podemos utilizar para programar tareas sino que puede desencadenarse por muchas acciones: eventos de otros servicios que ofrece Azure, WebHooks, peticiones Http, etc. Esto además hace posible que la integración con otros elementos sea relativamente simple.
¿Cuál es el problema?
Esto de ejecutar código en un lugar que no nos importa y que solo paguemos por ello suena fantástico. Ahora bien, ¿cómo podemos autenticar esto contra nuestro Office 365?
Cuando ponemos el código dentro de SharePoint, este ya está en el contexto de seguridad y por este motivo, prácticamente no le prestamos atención. Cuando ejecutamos una App utilizamos OAuth (bien Full Trust, bien la propia de Azure). Pero, ¿cómo lo podemos hacer en una Azure Function?
La cuestión es que en el Active Directory de Azure, utilizando ADAL tenemos dos posibles formas de autenticarnos:
- El usuario introduce su usuario y contraseña
- Autenticamos a la aplicación que se ejecuta
Está claro que la primera no es una opción, ya que ese código no sabemos donde va a estar y no va a tener una interfaz en la que podamos poner estos datos (y aunque la tuviera tampoco sería una opción). Dicho esto, tendremos que autenticar a nuestra aplicación contra el directorio de Azure y que nos genere un Token para poder consultar los servicios que nos hacen falta. ¿Cómo lo hacemos?
- Registramos nuestra App en el directorio de Azure.
- En el Azure Function tenemos que poner el siguiente código:
public class AuthenticationService:IAuthenticationService
{
public string aadInstance { get; set; }
public string tenant { get; set; }
public string clientId { get; set; }
public string appKey { get; set; }
public string authority { get; set; }
public string apiResourceId { get; set; }
public string apiBaseAddress { get; set; }
public AuthenticationService(string aadInstance, string tenant, string clientId, string appKey, string apiResourceId, string apiBaseAddress)
{
this.aadInstance = aadInstance;
this.tenant = tenant;
this.clientId = clientId;
this.appKey = appKey;
this.apiResourceId = apiResourceId;
this.apiBaseAddress = apiBaseAddress;
authority = this.aadInstance + this.tenant;
}
public async Task<string> GetTokenAppOnly()
{
var authContext = new AuthenticationContext(authority);
var clientCredential = new ClientCredential(clientId, appKey);
var result = await authContext.AcquireTokenAsync(apiResourceId, clientCredential);
return result.AccessToken;
}
}
El código es muy simple. Solo hay que utilizar la librería de Nuget Azure Active Directory Library y obtener las credenciales de la aplicación para obtener su token. Dado que los datos que se solicitan son propios de cada tenant, los almacenaremos dentro del Web.config de la Function, y accederemos a los mismos de la misma forma que a cualquier elemento del Web.config, en una WebApp normal (al final nuestra Azure Function está alojada en una Azure Function)
Inconvenientes de Azure Functions
Azure Functions tiene dos modos de pago, uno por computación (es decir por el tiempo que nuestra aplicación está en ejecución), y otro, el modo de pago de una WebApp, en el que tiene asignado una máquina con unas determinadas características y en caso de que queremos, puede escalar.
El inconveniente que tiene el primer caso es que el código ejecutado en una Azure Function no puede superar los 5 minutos, por lo que no podremos beneficiarnos de este modelo si nos planteamos tareas largas. También hay que tener en cuenta que hay procesos que a SharePoint le pueda costar más de este tiempo, por ejemplo crear una site collection.
Resumen
Estamos viendo como nuestro horizonte como desarrollador de SharePoint/Office 365 se está incrementando considerablemente. Ahora mismo debemos conocer no solo SharePoint, sino todo lo que le rodea, como Azure, para incorporar alguno de sus servicios y mejorar nuestro día a día con la plataforma.
¡Suscríbete a nuestras RRSS!
