¿Qué son los flujos de trabajo? ¿Qué me aporta cada versión?
Los flujos de trabajo son un conjunto de actividades que podemos construir para ejecutar nuestra lógica de negocio. En SharePoint se han utilizado ampliamente a lo largo de sus versiones porque permiten que se realice una acción cuando ocurre algo en nuestra plataforma: cuando se crea un elemento o se borra un documento, por ejemplo. Con esta herramienta no es necesario tener conocimientos de programación para automatizar nuestros procesos y además se pueden desarrollar de una manera visual.
Microsoft Flow es la nueva herramienta de flujos de trabajo que está disponible con nuestra suscripción de Office365 y el sucesor de los flujos de trabajo para SharePoint 2013/2010, tiene diferentes planes de pago por uso, teniendo el básico de forma gratuita.
Antes de analizar qué nos aporta Flow, o porqué debemos movernos a Flow, echemos una vista atrás y recordemos la trayectoria que han tenido los flujos de trabajo en entornos de SharePoint:
- SharePoint Workflow 2007/2010: Estos flujos de trabajo nos permitían automatizar tareas que no requerían una “gran cantidad de lógica”, podíamos asociarlos a listas, tipos de contenido e incluso sitios Web. Se podían editar, probar, compilar y desplegar desde SharePoint designer y Visual Studio.
Ya que trabajábamos en versiones on-premise y el servidor era nuestro, uno de los grandes potenciales de la herramienta es que teníamos libertad para poder crear nuevas actividades y acciones personalizadas a partir de código e importarlos posteriormente y utilizarlos desde el propio designer.
Esto nos daba el potencial necesario para crear flujos para cubrir cualquier casuística, de hecho, gracias a esto, incluso hubo compañías que hicieron sus aplicaciones para crear y manipular flujos de trabajo de una manera más visual sin utilizar SharePoint designer a partir de sus actividades personalizadas, permitiendo al usuario final que los creara una manera más sencilla de trabajar con ellos y una lógica personalizada.
-
SharePoint Workflow 2013: Es el sucesor que se implantó a partir de la versión SharePoint on-premise 2013 y todavía está presente hoy en día. Con esta herramienta se cambió el motor de flujos interno que se utilizaba en su totalidad.
Al ser un motor nuevo, había acciones que estaban presentes en la versión 2010 y que no estaban presentes en la versión 2013, y al revés.
La acción que marcaba la diferencia entre ambas versiones era que en los flujos de trabajo de 2013 tenían una acción para realizar peticiones a un servicio.
Si recordamos, junto con la versión 2013 de SharePoint, se implementó a la vez una API completamente nueva bajo el protocolo OData y que, por esto mismo, nos daba una amplia gama de operaciones que podíamos utilizar en nuestra colección de sitios, a través de esta API podíamos realizar todas las acciones que no estaban definidas en las actividades.
Desde el punto de vista de rendimiento, esta herramienta también era más rápida que su predecesora, porque en lugar de instanciarse en todas las ejecuciones, lo que hacíamos era movernos entre estados dentro de nuestro flujo.
¿Cuál es el futuro de los flujos de trabajo 2010/2013, por qué puedo seguir utilizándolos en SharePoint Online, por qué debería cambiar a Flow?
Si nos fijamos en la evolución del producto, nos daremos cuenta de que hemos tenido tres versiones de SharePoint designer para crear flujos de trabajo: ‘SharePoint designer 2007’, ‘SharePoint desinger 2010’ y ‘SharePoint designer 2013’.
Todos han tenido una estructura similar y no ha habido grandes cambios entre las versiones más allá del ‘look & feel’ o de poder seleccionar qué versión de flujo de trabajo queríamos crear.
SharePoint 2016 no ha venido con ninguna versión de designer, y se aplica lo mismo para la versión Online, ambos pueden utilizar designer 2013 pero no hay ninguna versión nueva. De hecho, para la nueva versión SharePoint 2019 tampoco se ha anunciado una nueva plataforma para cubrir estas necesidades.
Si nos paramos a pensar en el comienzo de SharePoint Online, cuando todo estaba todavía por hacer, recordaremos que teníamos la posibilidad de desplegar soluciones Sandbox y con esto, la posibilidad de desplegar flujos personalizados de versiones anteriores con acciones personalizadas. También podíamos seguir utilizando el modelo de desarrollo de versiones anteriores y ejecutar nuestro código de servidor en SharePoint Online.
Al tiempo, esta funcionalidad se marcó como obsoleta y se quitó de nuestros tenant, al quitar esta forma de desarrollar, se nos privó de la posibilidad de tener código personalizado dentro de la arquitectura de Microsoft.
Con este cambio, el cambio lógico para el desarrollador en SharePoint Online fue intentar simular lo mismo utilizando Add-In hosted provided, o lo que es lo mismo, el código personalizado se ejecuta fuera de los servidores de Microsoft. Esto ha generado un punto de inflexión en el modelo de desarrollo, ahora prima ejecutar la lógica en el lado del cliente y utilizar aplicaciones de pago por uso, ya no hay tareas costosas que ejecutan librerías de servidor personalizadas, y en el caso de que las haya son en un servidor nuestro
Si nos fijamos en los productos que está sacando Microsoft, los nuevos utilizan un pago por uso: ‘Azure’, ‘PowerAPP’, ‘PowerBI’, ‘Flow’… y ya está anunciado que la nueva versión de SharePoint 2019 se integre con estas tecnologías.
Por lo tanto, el cambio que debemos de hacer es ver qué cambios aportan estas nuevas tecnología y cómo podemos explotarlas para nuestro negocio.