¿Hasta dónde podemos llegar con Nintex y SharePoint? – Análisis y casos prácticos

Escrito por Sergio Hernandez Mancebo - 28/05/2015

Como siempre la comunidad .Net avanza a pasos agigantados, salen herramientas nuevas que ni conocemos, nos llegan las versiones de SharePoint casi sin darnos cuenta y para colmo entra en liza el mundo Cloud.  ¿Pero estamos realmente utilizando todo el poder de los componentes que tenemos a nuestro alrededor? Un ejemplo claro es Nintex, un producto integrado 100% con SharePoint desde la versión 2007, y que en mi modesta opinión al menos en los proyectos que yo he tenido el lujo de colaborar lo hemos usado sin realmente exprimir todo su potencial, y que hemos introducido más como un añadido que como un "requisito técnico" indispensable.

Nintex se puede definir como una herramienta de diseño de flujos de trabajo y procesos de negocio, que nos permite desde una completa interfaz gráfica definir nuestros procesos de trabajo sin necesidad de desarrollar código. Además, Nintex añade un potente editor de formularios "Nintex Forms" para listas de SharePoint, que nos permite editar los formularios de Creación, Edición y Detalle de forma sencilla desde la propia interfaz mediante un editor gráfico y un conjunto de reglas. Dicho esto ¿Por qué acabamos usando Nintex para pequeños proceso de negocio? ¿Podemos basar todas nuestras soluciones en Nintex sin tener preocupación alguna? ¿Podemos hacer un componente 100% basado en Nintex?

Nintex como todo en esta vida, tiene sus ventajas y sus desventajas, y en este artículo voy a intentar aclarar cuando es más recomendable o no basar nuestras aplicaciones en Nintex para soluciones SharePoint On Premises.

NINTEX COMO MOTOR DE REGLAS

Una de las preocupaciones más presentes en un cliente es el mantenimiento de la aplicación, y por ello tienden a pedir que los desarrollos sean configurables y parametrizables para evitar costes futuros en despliegues y evolutivos.

 

Con esta idea, podíamos pensar inicialmente que Nintex es una buena solución para un usuario, dado que podemos implementar en flujos gran parte de la lógica de negocio, y si necesitamos incorporar algún cambio a futuro no nos va a implicar realizar ningún despliegue.

Esto es real, y salvo una inversión inicial para desarrollar los flujos, el mantenimiento es mucho más bajo, además de que se pueden realizar cambios en los propios entornos casi en tiempo real y publicándolos sin afectar al usuario.

¿Entonces cuál es el problema? – Como siempre el rendimiento es el problema, la realidad es que Nintex 2013 es un motor de workflow y el rendimiento es cuestionable cuando hablamos de una aplicación de negocio donde el usuario espera respuestas instantáneas.

Debemos entender que los flujos de Nintex son procesos asíncronos que se ejecutan en cola y que nos puede causar retardos si el volumen de peticiones concurrentes llega a ser muy elevada.

NINTEX COMO EDITOR DE FORMULARIOS: NINTEX FORMS

Nintex Forms se nos presenta como una clara alternativa a la hora de desarrollar formularios de forma intuitiva y sin requerir tener amplios conocimientos de programación. Desde una solución grafica bastante conseguida, al más estilo Infopath podemos desarrollar formularios contra listas de Sharepoint de forma sencilla y rápida.

Imagen 1.- Comparativa InfoPath vs Nintex. 

Pero claro está para poder decir que Nintex es "el rey" de los formularios, debemos comparar antes con las otras opciones disponibles. Omitiendo las opciones de SharePoint Designer y XSLT o JSLINK, que son soluciones más orientadas a un programador (sobre todo JSLINK), vamos a intentar comparar al descontinuado InfoPath (que no retirado, ya que continúa en SharePoint 2016) con Nintex Forms, para poder poner en situación que es Nintex Forms:

Imagen 2.- Qué me ofrece Nintex frente a InfoPath. 

Analizando la comparación podemos deducir que, si conseguimos que nuestros metadatos estén 100% sobre listas de SharePoint, podemos decir que Nintex Forms es una solución idónea, dado que es mucho más mantenible que lo era InfoPath, nos permite inyectar código cliente y al no tener código servidor asociado no necesitamos desplegar para poder realizar cualquier cambio.

Por otro lado, esta solución no nos sirve para formularios personalizados que requieran llamadas a servicios web, integración directa contra base de datos o que tenga una gestión de vistas compleja. Aclarar que Nintex Forms se basa en el tipo de contenido de la lista, y que por cada cambio que hagamos sobre las columnas de la lista, deberemos revisar tanto el formulario como las reglas configuradas en él.

En conclusión, podemos decir que para un escenario en el que nuestros datos estén en listas de SharePoint, y en el que sabemos que no vamos a sufrir demasiados cambios en la estructura de la lista, esta solución es idónea y podemos obtener unos resultados excelentes.

CASO PRACTICO: GESTIÓN DE APROBACIONES

En este apartado vamos a ver cómo realizar un componente con Nintex y Nintex Forms del cual obtenemos un buen resultado tanto a nivel de rendimiento como de costes en mantenimiento. Vamos a desarrollar un componente que permita a los miembros de un departamento de una empresa firmar un documento de Word como pudiera ser un documento de Compra de forma automática. Para ello vamos a seguir los siguientes pasos:

Creación de una biblioteca

En primer lugar vamos a crear una biblioteca en SharePoint, por ejemplo una biblioteca de documentos Estándar, y añadimos una columna del tipo persona que sea Firmante. Para esta versión vamos a indicar que solo admita un usuario ya que solo vamos a permitir un aprobador por documento

Imagen 3.- Creación de la columna. 

Creación de Nintex Workflow y Nintex Forms

Creamos desde la ribbon un nuevo formulario de Nintex muy básico que únicamente va a solicitarnos el usuario firmante de este documento.

Imagen 4.- Creación del formulario de Nintex. 

Imagen 5.- Pantalla de edición del formulario. 

Creamos un nuevo workflow utilizando una máquina de estados de Nintex tal cual muestra la siguiente imagen:

Imagen 6.- Diseño del Workflow de Nintex 

Realmente para este caso concreto en el que solo hay un aprobador, podríamos no usar la máquina de estados, pero como veremos después para una aprobación múltiple de usuarios nos da muchas ventajas. Si observamos el flujo lo primero que hacemos es obtener el usuario firmante, posteriormente creamos una tarea de aprobación (Request approval) que le hará llegar un mail al usuario firmante. Podemos configurar el texto del mensaje tal cual vemos en la imagen, siempre dejando un enlace a la página de aprobación.

Imagen 7.-  Edición de la actividad de aprobación, 

Esta caja de Nintex "Request approval", lo que hace es genéranos una tarea para el usuario destinatario de la aprobación. Una vez el usuario apruebe o no la tarea firmaremos el documento de Word desde Nintex, dejando el resultado de la tarea de aprobación y la firma en el documento.

Configuraremos el flujo para que se inicie siempre que editemos el documento desde la biblioteca, así cuando guardemos el usuario firmante desde el formulario de Nintex Form se iniciará el flujo (lo encontramos en propiedades del flujo).

Plantilla Word

Para que Nintex pueda grabar datos en el documento adjunto vamos a decantarnos por introducir marcadores especiales en el documento. Esta es la forma más fácil, pero a la vez la más limitada comparada con hacerlo usando Open XML. Necesitamos acceder al documento de Word que usaremos como plantilla, y habilitar en la barra de herramientas la opción "Desarrollador". Lo conseguimos accediendo a Opciones, Personalizar Cinta de Opciones y marcamos en la parte de la derecha el check "Desarrollador" con todos sus componentes.

Ahora sobre la ribbon en Desarrollador seleccionamos "Aa", y arrastramos el control de texto enriquecido a nuestro documento, hasta conseguir un diseño de documento parecido a esto:

Imagen 8.- Diseño final del documento. 

Es muy importante darle nombres a nuestros controles de texto enriquecido (Rechazado, Aprobado), ya que este nombre es interno y único, y deberemos configurarlo en la caja del flujo para escribir en Word de la siguiente forma:

Imagen 9.- Actividad de actualización de documento. 

Configuramos que añada el texto "Documento Aprobado" al marcador de Aprobado e inserte el valor del usuario firmante desde la columna creada en el primer paso (proceso similar para escribir el rechazo del documento). Al terminar la firma del documento (aprobado o rechazado), la maquina salta a estado Aprobado o Rechazado en función de la aceptación del usuario firmante, y le llega un mail de fin de proceso al usuario iniciador del flujo (usuario que configuró la aprobación).

Iniciar Aprobación

Tal cual hemos montando el componente, basta con subir un documento de Word con la plantilla definida (podemos configurar la biblioteca para que use esta plantilla), y desde el formulario de creación (nuestro Nintex Forms), insertamos el usuario al que queremos que llegue la notificación. Debe de ser un usuario con permisos en el sitio de la biblioteca y con correo en su perfil de SharePoint.

Imagen 10.- Formulario del documento. 

Versión con múltiples aprobadores

Como hemos visto esta máquina de estados es muy sencilla porque solamente tenemos un aprobador por documento, pero si cambiáramos la columna firmante y aceptáramos multi- selección, se complicaría bastante el proceso. En este caso podríamos evolucionar nuestro flujo a algo parecido a esto:

Imagen 11.- Ejemplo de diagrama de flujo de aprobación.  

En este caso ya tratamos más de un aprobador, y la máquina de estados coge más peso en la gestión del flujo. Necesitamos obtener el número de aprobadores, y los aprobadores. Mediante una expresión regular obtenemos los aprobadores y los almacenamos en una colección de datos (similar a una lista en C#).

Imagen 12.- Continuación del ejemplo de diagrama de flujo de aprobación. 

Como vemos el flujo se encarga de evaluar si nos quedan aprobadores por tratar, y en caso afirmativo sigue mandando notificaciones vía mail para que aprueben o rechacen el documento. Si no nos quedan aprobadores y nadie ha rechazado se notifica la aceptación, en caso contrario se notifica el rechazo.

Imagen 13.- Continuación del ejemplo de diagrama de flujo de aprobación 

Esta parte del flujo se encarga de modificar el documento, y recalcular cuantos aprobadores nos faltan por tratar.

Solo nos quedaría adaptar nuestra plantilla de Word para que acepte más aprobadores o bien concatenar los aprobadores en una variable en el workflow y escribirlos en el documento. Lo importante de este ejemplo es ver que con la máquina de estados podemos crear componentes complejos con el mínimo coste de diseño. Si intentásemos diseñar este flujo mediante recorridos o condiciones (cosa que sería totalmente viable), veríamos que el tamaño del flujo crecería proporcionalmente al número de estados que tengamos en nuestra máquina.

Conclusiones

En mi opinión personal con Nintex se pueden hacer cosas bastantes completas como las que hemos podido ver, y no limitarnos a aprobar tareas, mandar notificaciones o cambiar valores de una columna en SharePoint. Le queda camino por andar todo sea dicho, a día de hoy sigue siendo una cola de procesos asíncrona que para aplicaciones de alta concurrencia y que requieran una cierta velocidad se nos queda un poco pequeño.

En cuanto al editor de formularios, es una solución que globalmente supera con creces a InfoPath, aunque aún se limita bastante a Formularios de Listas en SharePoint, y carece de integración con fuentes de datos externas.

La unión de Nintex Forms y Nintex Workflow, sumado a los potentes servicios web que tiene publicado Nintex en Sharepoint, nos proporcionan herramientas suficientes como para hacer cosas interesantes, eso sí sin huir del Visual Studio que en ocasiones nos dará menos dolores de cabeza.

 

Sergio Hernández Mancebo
Team Leader en ENCAMINA
shernandez@encamina.com

***