En la última versión de SharePoint 2013, Microsoft hizo algunos cambios drásticos en el motor de flujo de trabajo, en la forma en que interactúa con SharePoint y en la forma en que los clientes pueden crear flujos de trabajo personalizados. Antes de SharePoint 2013, Microsoft implementó el flujo de trabajo haciendo que SharePoint alojara el tiempo de ejecución de Workflow Foundation. Esto significaba que el flujo de trabajo escalado a medida que SharePoint escalaba y cualquier cosa que los clientes quisieran hacer con los flujos de trabajo, como iniciar nuevas instancias en un elemento de la lista o interrogar al tiempo de ejecución para los flujos de trabajo que se estaban ejecutando actualmente, o incluso para obtener datos de telemetría sobre los flujos de trabajo ejecutados anteriormente, todo tenía que hacerse a través de SharePoint. Si bien esto estaba bien en muchos escenarios, también era muy desafiante y limitante porque la API de SharePoint no exponía todos los detalles del tiempo de ejecución del flujo de trabajo. Para implementar esta arquitectura, todos los flujos de trabajo se ejecutaron bajo una cuenta altamente privilegiada que, si bien era aceptable para las implementaciones de SharePoint in situ, causaba problemas significativos en las implementaciones alojadas, como el popular servicio Office 365 ofrecido por Microsoft. Como tal, los clientes sólo podían implementar flujos de trabajo creados con el Diseñador de SharePoint ya que eran totalmente declarativos y, por lo tanto, no tenían un código personalizado que requiriera la cuenta altamente privilegiada para ejecutarlos.
SharePoint 2013 introdujo un cambio dramático en esta arquitectura. Los equipos de Windows Azure y de flujo de trabajo trabajaron juntos para crear un nuevo producto, Workflow Manager 1.0, que actúa como host para el tiempo de ejecución del flujo de trabajo. Este producto puede correr tanto en Windows Azure como en implementaciones locales. ¿Cómo afecta esto a SharePoint 2013? En la última versión, Workflow Manager está configurado como una aplicación con SharePoint y SharePoint transmite todo el procesamiento del flujo de trabajo y el trabajo a él. Esto separa la carga de trabajo del flujo de trabajo de SharePoint 2013 que proporcionará más opciones de extensibilidad, escalabilidad y debido a que Workflow Manager fue diseñado para las implementaciones en la nube y en las instalaciones desde el principio, todo lo que se puede hacer en una implementación en las instalaciones también se puede hacer en la nube y viceversa.
La subcontratación del flujo de trabajo al Administrador de Flujo de Trabajo ordena algunos cambios
No debería sorprender que un cambio arquitectónico tan drástico obligue a realizar algunos cambios en los flujos de trabajo que los desarrolladores de SharePoint están acostumbrados a construir. De todos los impactos que este cambio tiene en los flujos de trabajo personalizados, se pueden agrupar en dos categorías: un nuevo cliente-API y servicios web. Ambas categorías tienen un montón de cosas que impactan, así que permítanme tocar algunas de ellas.
Un paso gigante para el flujo de trabajo: Se necesita una nueva API de cliente
Una mejora significativa en la historia del flujo de trabajo en SharePoint 2013 es la cobertura añadida de la infraestructura de servicios de flujo de trabajo en el modelo de objetos del lado del cliente. Esta implementación, disponible en forma de código del lado del servidor (comúnmente conocido como CSOM) o del cliente como JavaScript (comúnmente conocido como JSOM) permite a los desarrolladores hacer prácticamente cualquier cosa con el flujo de trabajo en SharePoint 2013. Los desarrolladores pueden crear soluciones personalizadas que validen e instalen nuevos flujos de trabajo, crear nuevas asociaciones de flujo de trabajo y modificar las existentes en listas, bibliotecas y sitios, así como iniciar nuevas instancias de flujo de trabajo e incluso interactuar con las que están en vuelo y actualmente en funcionamiento!
Estos cambios fueron necesarios por múltiples razones con la nueva arquitectura, pero uno se destaca de los otros ya que simplificó dramáticamente una tarea común para los desarrolladores de flujo de trabajo: la creación de formularios personalizados. En versiones anteriores de SharePoint, crear formularios personalizados de asociación e iniciación del flujo de trabajo era una tarea engorrosa usando ASP.NET con un código personalizado especial y complejo del lado del servidor que se usaba para organizar la comunicación del formulario al motor de flujo de trabajo o usando formularios InfoPath que eran difíciles de desplegar y depurar.
Esto no es así en SharePoint 2013. La inclusión del flujo de trabajo en el CSOM & JSOM significa que ahora, todos los formularios son esenciales sólo los formularios HTML que utilizan JavaScript para crear la asociación o disparar una nueva instancia del flujo de trabajo. De hecho, las plantillas incluidas en Visual Studio cuando se agrega un nuevo formulario eliminan el 98% del JavaScript necesario para agregar estos formularios; todo lo que tienes que hacer es llenar algunos espacios en blanco para tus campos personalizados!
Workflow Manager 1.0 también introdujo una nueva capacidad para los desarrolladores de flujos de trabajo de SharePoint que anteriormente sólo estaba disponible para aquellos que construían flujos de trabajo codificados utilizando Visual Studio: la capacidad de interactuar con servicios web externos.
La capacidad de llamar a servicios web externos, idealmente servicios OData o REST, es muy importante en este lanzamiento como otro gran cambio en la plataforma. Los nuevos flujos de trabajo del estilo de SharePoint 2013 + Workflow Manager 1.0 sólo soportan flujos de trabajo declarativos; los desarrolladores ya no crean flujos de trabajo en Visual Studio con un modelo de código detrás… incluso los flujos de trabajo creados por Visual Studio son ahora 100% declarativos.
Cuando usted tiene una lógica de negocios personalizada que necesita implementar en su flujo de trabajo, Microsoft recomienda refactorizar esta lógica en un servicio de OData y llamar a ese servicio desde su flujo de trabajo.
Estos servicios pueden ser servicios anónimos o pueden configurarse para escenarios sólo autenticados con varias opciones empleadas para proteger los servicios de llamadas no autorizadas.
Además de llamar a sus propios servicios personalizados, otro poderoso caso de uso para aprovechar los servicios web en los flujos de trabajo personalizados es llamar a la API REST de SharePoint 2013 cuando algunas de las acciones o actividades proporcionadas en SharePoint Designer o Visual Studio no se ajustan a las necesidades de su empresa. En esos casos, puede aprovechar al máximo la potente API REST de SharePoint para lograr cualquier cosa que necesite hacer en su flujo de trabajo!
Microsoft hizo algunos cambios significativos en la implementación del flujo de trabajo en la última versión de SharePoint, SharePoint 2013. Estos cambios facilitan a los desarrolladores y usuarios avanzados la creación de flujos de trabajo personalizados y robustos que automatizan el proceso de negocio. Además, la nueva arquitectura también hace del flujo de trabajo una plataforma mucho más transparente, fiable y escalable para los clientes de SharePoint, independientemente de si tienen implementaciones en sus instalaciones o aprovechan soluciones alojadas como Office 365.