martes, 27 de mayo de 2014

Infopath: Cómo implementar menús desplegables en cascada (cascading dropdowns).

A estas alturas todos sabréis las grandes limitaciones que tiene actualmente SharePoint out of the box para generar formularios en sus listas (aunque en la siguiente versión quedará cubierto con FoSL). Si tenemos requerimientos que impliquen lógica de formulario, como ocultar ciertos campos según el valor de otros, o implementar un simple dropdown en cascada, nos veremos forzados a hacer un custom form com asp.net o tirar de Infopath. Es este último ejemplo el que vamos a explicar hoy: Cómo crear menús desplegables (dropdowns) en cascada.

El primer paso será crear dos listados en SharePoint (custom lists) donde albergar los contenidos de cada uno de los menús desplegables que queremos crear. En este post crearemos el típico ejemplo de País/Ciudad, así que la primera lista será un simple listado con una única columna de texto libre donde indicaremos los diferentes valores posibles para el campo País (Country).
image
Para la segunda lista crearemos 2 columnas, una de tipo texto libre donde indicaremos los diferentes valores posibles para el campo Ciudad (Country), y otra de tipo Lookup que apuntará a la lista de países que creamos previamente.
image
Una vez construidas estas dos listas en SharePoint, ya podremos ir al Infopath.
En Infopath tendremos que crear en primera instancia los 2 campos que queremos vincular, ambos de tipo menú desplegable (dropdown). Debería tener un aspecto similar al siguiente:

image

Evidentemente podremos continuar creando el resto de campos del formulario, pero lo siguiente para crear la funcionalidad de los dropdown en cascada será generar las 2 conexiones externas a listas de SharePoint, una para conectar a cada una de las listas creadas previamente.

Para crear estas nuevas conexiones iremos a la pestaña “Data” de la Ribbon de Infopath y pulsaremos en “Data Connections”

image

Dentro del menú de conexiones, pulsaremos en el botón de “Add…” para empezar a crear la nueva conexión.

image
Dentro ya del wizard para crear la nueva conexión, nos aseguramos de que estamos marcando “Create a new connection to: Receive data” y pulsamos en “Next”
image

En la siguiente pantalla seleccionamos “SharePoint library or list” como origen de datos y pulsamos en “next”.

image
En la siguiente pantalla introduciremos la URL del
 site donde hemos creado las listas de países y ciudades y pulsamos en “next”.

image

En la siguiente pantalla seleccionaremos la lista que hemos creado para los países y pulsaremos en “next”

image

En la siguiente pantalla seleccionaremos los campos del Título (país) e ID, y pulsaremos en “next”

image

En la siguiente pantalla, no hace falta que seleccionemos poder trabajar en offline con el formulario. Pulsamos directamente en “next”.
image
Y ya en la última pantalla nos aseguramos que el campo “Automatically retrieve data when form is opened” está marcado (garantiza la ejecución de la conexión de datos en el momento de abrir el formulario) y pulsamos en “finish”.

image

Con esto ya habremos creado la primera conexión de datos, a la lista de países. Ahora tendremos que repetir exactamente el mismo proceso para crear la conexión a la lista de ciudades, con la única excepción de que en la pantalla de selección de campos de la lista, tendremos que marcar el campo de ciudad, el de país y el de ID.

image

Una vez tengamos las 2 conexiones a las listas creadas, vamos a configurar cada uno de los campos. Vamos a empezar por el de País. Observad que lo he nombrado “CountryID”, y lo del ID al final es porque para que el dropdown en cascada funcione, este campo ha de almacenar un identificador, no el texto del país en sí mismo. Esto es así porque internamente SharePoint almacena Identificadores para los campos de tipo Lookup, y como aquí las ciudades hacen un lookup a los países, vamos a tener que lidiar con ello. De momento no os preocupéis, ya lo trataremos más adelante.

En la pantalla de configuación del dropdown de Países, tenemos que marcamos la opción “Get choices from an external data source”, y que en “Data source” seleccionamos la conexión que hemos creado para obtener el listado de países.

También hay que tener en cuenta que el valor almacenado ha de ser el ID, y no el país en sí, esto es importante por lo que he comentado 2 párrafos arriba. Si no seleccionamos un ID como valor, no funcionará el dropdown en cascada. Sin embargo en “Display Name” podemos seleccionar el país directamente sin problemas.

image

Una vez configurado, pulsamos el bótón de OK y vamos a configurar el segundo dropdown, el de ciudades. Esta vez será exactamente lo mismo que en el anterior, seleccionando la conexión al listado de ciudades y pudiendo seleccionar en el campo valor esta vez la ciudad directamente (Aquí no hace falta seleccionar el ID).

image

Al terminar la configuración, pulsamos el botón de “OK” para guardar los cambios realizados.
En este punto ya tendremos creada la base de los menús desplegables en cascada. Sin embargo, nos quedan por resolver 2 problemas:
  1. Cuando cambio el país, no borra automáticamente la ciudad seleccionada anteriormente (puede dar origen a incoherencias).
  2. El valor que se está guardando en “CountryID” es un número, y no el “texto” de la ciudad en sí.
Para solucionar el primer punto pendiente hay que crear directamente una regla de tipo “Action” sobre el campo “CountryID”. No estableceremos ninguna condición (se ejecutará siempre que haya un cambio en el campo”"), pero como acción estableceremos que el campo “City” (nuestro dropdown de ciudades) se ponga en blanco.

image
Una vez creada esta norma ya tendremos solucionado que al cambiar el valor del país, la ciudad previamente seleccionada se borre y se quede en blanco.

Ya solo nos queda solucionar el último punto pendiente (almacenar el valor real de Country, no únicamente su ID). Para ello, primero crearemos un nuevo campo en el formulario, de tipo String, que esta vez sí llamaremos “Country” a secas. Este será el campo que contendrá el valor deseado para Country (un texto y no un número), así que este será el campo que publicaremos como visible en el listado de SharePoint.
image

Una vez tengamos el campo “Country” creado, volveremos a crear una nueva regla de tipo “Action” sobre el campo CountryID. La regla se basará en “Set a field’s value”, donde el campo Field será el recién creado nuevo campo de texto “Country”, que recibirá el valor del campo que especificaremos a continuación (pulsad en “Insert Field or group”)

image

El campo a seleccionar será, de nuestra conexión secundara al listado de Paises (cambiar la conexión “main” que sale por defecto), en el conjunto de “dataFields”, el campo “Country” (ver imagen abajo). Sin embargo, este campo tendremos que filtrarlo (pulsar en botón “Filter Data”) de forma que el campo “ID” (también de la conexión secundaria y en el grupo de “dataFields”) sea igual al campo principal del formulario “CountryID”, que es nuestro dropdown de países (este último sí que se encuentra en la rama “Main”).

Filtering

Una vez establecido este filtro, aceptamos todo hasta salir de todas las ventanas y volver nuevo al formulario principal. Sobretodo recordar que al publicar, el campo que debéis mostrar en el listado de SharePoint es "Country" (texto) y no "CountryID" (número).

Ahora sí, ¡Ya lo tenemos! Al hacer una vista previa o publicar el formulario, podremos comprobar que si seleccionamos un país en concreto, tan solo podremos seleccionar las ciudades relacionadas con dicho país.

image

Así que eso ha sido todo por hoy, aunque espero poder contaros a la vuelta del verano las novedades que FoSL nos traerá en la edición de formularios y que supondrá la sustitución definitiva de nuestro “viejo amigo” Infopath.

¡¡Un saludo!!

lunes, 26 de mayo de 2014

SPD 2013: Cómo tratar en un Workflow cada fila de las repeating tables de Infopath.

Si alguna vez habéis utilizado Infopath para implantar formularios con lógica, vistas y estructuras de repetición, sabréis que estas últimas tan solo se pueden trabajar cuando SharePoint se basa en una “form list”, ya que la optimización con infopath que se nos permite hacer en el resto de listas está “capada” y muchas de sus opciones no se pueden utilizar, como el caso de las “repeating tables”.
En una FormList, las columnas de datos, no se crean en SharePoint para ser interpretadas por Infopath, sino que es a la inversa: Infopath genera las columnas al publicar el formulario. Algunas de ellas son de tipo especial y no existe forma de poderlas editar posteriormente desde la administración de listas de SharePoint.
Las repeating tables son ese tipo de estructuras que se pueden visualizar en las vistas de SharePoint, pero no podemos manipularlas desde él. Imaginemos un formulario de “informe de gastos mensuales”, donde el usuario puede reportar “n” filas de gastos en función de lo que haya viajado ese mes, o de los diferentes proyectos en los que ha trabajado. Ese informe posteriormente debe ser tratado por un flujo de trabajo, que sirva tanto para autorizar o no los gastos reportados (validación), como para extraer la información fila a fila, de cada gasto reportado, para tratarlos de forma individual en una lista de “gastos mensuales por proyecto”. En esta lista final se sumarían tanto los gastos provenientes del “informe de gastos mensuales” como de otros reportes posibles, tales como “solicitudes de compra” o “solicitudes de viaje”. Pues bien, ¿Cómo tratar esas filas de las repeating tables de InfoPath una a una en el Workflow de SharePoint Designer? Hoy mostraremos la solución en este post.
Para nuestro ejemplo, utilizaremos una repeating table con los siguientes campos:
  • Project: Indica el proyecto donde imputa el gasto
  • Date: Indica la data en la que se produjo el gasto
  • Expense Type: Indica el tipo de gasto
  • Description: Líneas de texto libre para comentar detalles sobre el gasto
  • Amount: Cantidad que hemos gastado.
image
Lo primero que tendremos que hacer desde Infopath es asegurarnos de que todas las columnas incluidas en la repeating table (en nuestro ejemplo “Project”, “Date”, “Expense Type”, “Description” i “Amount”), cuando las publicamos en la Form List con el Publishing Wizard, están añadidas en la sección de “..will be available as colums in SharePoint sites…” y que además la función con las que se representen sea “merge”.

image
Esta función almacena los “n” valores que pueda haber en una repeating table, separados por un salto de línea cada una. En el ejemplo que he mostrado, estas columnas se verían así desde el listado de la Form List de SharePoint:
image
Una vez tengamos las columnas de la repeating table publicadas en SharePoint de este modo, ya podemos empezar con nuestro workflow en SharePoint Designer.
Es importante crear el flujo en modo “SharePoint 2013”, pues utilizaremos algunas funciones que únicamente tiene 2013 y no existían en 2010. Lo primero que haremos será crear las variables que necesitaremos en nuestro flujo. Crearemos 2 variables de tipo String para cada uno de los campos que tiene nuestra repeating table (Projects i Project, Dates i Date, Amounts i Amount, etc.). También necesitaremos una variable de tipo integer (En mi caso la llamé “index”) que haga de índice de iteración por cada fila de la repeating table y otra de tipo number (En mi caso la llamé “calc”) como receptora del cálculo de incremento del índice en cada iteración.
image
Bien, vamos a empezar con el Workflow en sí mismo. En mi caso me interesa que el flujo se ejecute una vez la solicitud de gastos haya sido aprovada, y el proceso de validación pongamos que sea algo tan sencillo como que el campo “Approval Status” cambie a estado “Approved”. Utilizo aquí el “Content Approval” definido en “Yes” dentro de los settings de la Form List (Version Settings) para no complicar el flujo en exceso.
image Así pues, configuramos el flujo para que se ejecute cada vez que el ítem cambie, y su primera línea será la siguiente condición:
image Después de esto estableceremos el valor de las variables que hemos creado para almacenar los strings completos de cada columna de datos. Es decir, usaremos la acción “Set Workflow Variable” (en "Core Actions") para cada una de las columnas que están en la repeating table. Al final podemos poner un “Log to history list” para tener un punto de control sobre el valor inicial de estas variables.
image
Recordemos que estas variables almacenan todos los valores contenidos en la repeating table para cada columna, separados por un salto de línea.
A continuación utilizaremos la acción “Find Substring in String” (en "Utility Actions", únicamente en SPD 2013) para encontrar en qué posición existe un salto de línea. Para ello usaremos cualquiera de las variables inicializadas con los campos de la repeating table del paso anterior. En el ejemplo utilizo la variable “Projects”. Tras esta acción la variable Index almacenará la posición del primer salto de línea.
image

A continuación crearemos el bucle que irá separando cada línea (cada valor) de las columnas de la repeating table. Para ello utilizaremos el "Loop with condition" (En el menú "Loop") y le indicaremos que se ejecutará cuando la variable "index is greater tan 0". De esta forma nos aseguramos que siempre que continúen habiendo saltos de línea el bucle irá extrayendo nuevos valores de la repeating table.

image

 A fin de facilitar la comprensión y implantación del flujo, recomiendo en este punto crear un nuevo step con un título claro sobre lo que vamos a implantar a continuación: Extraer un valor particular de una variable con múltiples valores.

image

Dentro de este step, la primera acción a utilizar será "Extract Substring from Start of String" (en "Utility Actions"). Copiaremos los n caracteres marcados por la variable "index" desde uno de los strings que habíamos inicializado al principio del flujo (contenedor de todas las líneas de la repeating table) a uno de los segundos strings creados para cada variable. En mi ejemplo el substring lo creo desde "Projects" a "Project".

image

El siguiente paso es incrementar en una unidad el valor de la variable Index (para que se situe una posición posterior al salto de línea). Para ello utilizaremos la acción "Do calculation" (En "Core Actions"). El resultado lo guardaremos en la variable que habíamos creado de tipo "Number" (en caso de no haberla creado, SPD la generará automáticamente).

image

Ahora tenemos que actualizar la variable Index con el resultado de este cálculo (la acción "Do Calculation" no permite almacenar el resultado en una variable de tipo "Integer", y por eso tenemos que hacer este paso intermedio). Para ello utilizaremos la acción "Set Workflow Variable" (En "Core Actions").

image

La siguiente acción será "Extract subtring from index of string" (en "Utility Actions"), mediante la cual eliminaremos la línea ya extraída hasta el salto de línea del string inicial que contenía todos los valores de la repeating table. De esta forma dicho string se reducirá en una línea (ya extraída) y entrará en la siguiente iteración del bucle con esa línea menos.

image

Esta acción será la última del Step que habíamos creado. Sin embargo, este Step contiene únicamente las acciones necesarias para extraer una línea de una de las columnas de la repeating table. Ahora tendríamos que hacer exactamente lo mismo para el resto de columnas que la componen. Una de las ventajas de haberlo contenido en un Step, es que podremos, simplemente, copiar y pegar ese Step, y hacer las modificaciones únicamente relativas a las variables que afectan a cada columna en concreto. En la siguiente pantalla, muestro 3 de los 5 Steps que necesito en mi flujo, los otros 2 serían exactamente iguales, como podréis ver en el pantallazo final del flujo al final del post.

image
Tras los Steps de cada una de las columnas de datos de la repeating table, recomendaría hacer un "Log to History List" (en "Core Actions") para poder visualizar en el log del flujo algunas de las variables tratadas y poder tener un punto de control de las mismas.

image

En este punto procederemos a copiar todos los datos de la fila de datos extraída a un nuevo ítem de la lista de "Monthly Expenses", que como expliqué al inicio del ejemplo, contendrá información que vendrá de diversas solicitudes (solicitudes de gasto, solicitudes de viaje, solicitudes de compra...). Para ello utilizaremos la acción "Create List Ítem" (en "List Actions"). SPD creará por defecto una nueva variable de salida (output) donde almacenará el GUID del nuevo ítem creado en la lista de destino.

image

En el detalle de la acción deberíamos tener algo similar a lo siguiente:

image

Y ya como último paso del bucle (loop), actualizaremos de nuevo la variable Index para que tras toda la operativa realizada en la última iteración del bucle, este sepa si ha de volver a realizar una iteración más o no. Para ello volveremos a utilizar la acción “Find Substring in String” (en "Utility Actions", únicamente en SPD 2013), de forma exacta a la descrita antes de entrar en el bucle.

image

Ya fuera del bucle, hay que tener en cuenta que el último retal del string original (última línea de la repeating table) no se habrá copiado dentro del bucle (ya que al no haber más saltos de línea Index será inferior a "0"). Por lo tanto, esta última línea la crearemos una vez el bucle ya haya finalizado, de nuevo con la acción "Create List Ítem" (en "List Actions") tal y como la habíamos utilizado anteriormente en el flujo. También podemos añadir aquí un último Log en el historial del flujo con la acción "Log to History List" (en "Core Actions"), para tener un último punto de control del mismo.

image

¡Y ya lo tenemos listo! Por fin hemos descompuesto todas las filas de la repeating table, únicamente con InfoPath y SharePoint Designer. ¿Alguien lo dudaba?

El flujo final tendrá un aspecto similar al de la siguiente imagen:

Ya con esto me despido por hoy. Espero con este tipo de ejemplos dejar claro que aunque SharePoint Designer e InfoPath tienen sus limitaciones, se pueden construir aplicaciones y flujos relativamente complejos con ellos. Tan solo hay que saber encontrar la manera de ir resolviendo cada reto.

¡¡Un saludo SharePointeros!!

jueves, 22 de mayo de 2014

SP 2013: Wildcard (*) por defecto en todas las búsquedas

El lenguaje para realizar cualquier query en SharePoint 2013 es el KQL, que le da una potencia extraordinaria a los search webparts y otros componentes de búsqueda, pero tiene algunas pegas de cara al usuario “de a pié” con las búsquedas estándar. Una de ellas es que si tu quieres buscar, por ejemplo, resultados que contengan la palabra “Methodology”, tendrás que poner en el cajetín de búsqueda la palabra entera, o los primeros caracteres con el asterisco (wildcard) al final: “method*”.

A los que hemos estado delante de un ordenador toda la vida, y especialmente a los que trabajamos en TI, nos resultará lo más normal del mundo, pero puede que os sorprenda la cantidad de personas que nunca entenderán que al final de una búsqueda se tenga que poner un asterisco. ¿Asterisco? ¿Qué es eso? ¿Por qué? (y la frase “estrella”) ¡¡En Google nunca pongo asterisco!!

image

Si vuestro cliente os pide que el asterisco vaya incluido por defecto en todas las búsquedas, para no tener su servicio de helpdesk sacando humo todo el día, quizás el primer impulso sea contestar que no se puede, que SharePoint viene así por defecto, y que se puede analizar en un desarrollo a medida… Por suerte, en este caso hay solución, simple y gratuita. Vamos allá.

En SharePoint 2013 han desaparecido los ámbitos de búsqueda (Scopes) y ahora han sido substituidos por los “Result Sources”. Qualquier búsqueda que se realice sobre SharePoint 2013 se asocia a un Result Source concreto, que especifica los siguientes parámetros.

  • Un proveedor de búsqueda: Como por ejemplo SharePoint Local, SharePoint Remoto o Exchange.
  • Un protocolo:  Como por ejemplo OpenSearch.
  • Un query transform: Nos permite especificar el subconjunto de resultados pre-configurando la query que se utilizará en todas las búsquedas del result source definido.
  • Un sistema de autenticación: Se puede especificar el método de autenticación entre los disponibles en la configuración de la granja de SharePoint.

SharePoint 2013 viene por defecto con 16 result sources preconfigurados, entre ellos, el que se usa de forma predeterminada en las búsquedas es el “Local SharePoint Results”.

Lo que tenemos que hacer para incluir el wildcard (*) en las búsquedas básicas es sustituir ese result source predeterminado por otro que crearemos nosotros mismos. Para ello lo primero es saber que un resoult source se puede definir tanto a nivel de Site, como de Site Collection como de Administración Central de SharePoint. En función de dónde lo definamos, las “capas inferiores” heredarán los cambios de las “capas superiores”. Por lo tanto, en función de dónde queramos modificar las búsquedas, configuraremos en uno u otro nivel.

En caso de querer modificar a nivel de Site o Site collection, se accederá por el menú de Site Settings, y en la sección de “Search” o “Site Collection Administration”, selecciónar “Result Sources” o “Search Result Sources” respectivamente.

En el caso de querer modificar todas las búsquedas a nivel global, en la administración central iremos a “Application Management” – “Service Applications” – “Manage Service Applications” – “Search Service Application” y una vez dentro de la administración de las búsquedas, pulsar en “Result Sources” en el menú vertical izquierdo, en la sección de “Queries and Results”.

Una vez dentro del listado de Result Sources, crearemos un nuevo Result Source (New Result Source), y en la siguiente pantalla introduciremos la siguiente información:

  • Name: (introducir un nombre que nos parezca apropiado para el nuevo Result Source)
  • Protocol: Local SharePoint
  • Type: SharePoint Search Results
  • Query Transform: {searchTerms}* 

(es aquí donde estamos forzando el asterisco al final de cada búsqueda)

  • Credentials Information: Default authentication

Finalmente, pulsad el botón “Save” al final del formulario para generar el nuevo Resoult Source de forma definitiva.

image

Una vez hayamos creado el nuevo Result Resource, debemos seleccionarlo en el listado de “Defined for this search service”, y en el menú desplegable seleccionar la opción de “Set as Default”.

image

¡¡Voila!! A partir de ahora, todas las búsquedas por defecto incluirán el wildcard del asterisco, esto incluye los siguientes componentes de búsqueda:

  • Búsqueda estándar

 image

  • Búsqueda avanzada

image

  • Búsqueda en listas/bibliotecas

image

Por supuesto, también aplicará a todas aquellas páginas personalizadas donde hayamos introducido algún control de búsqueda estándar.

Y con esta pequeña introducción a los Result Resources de 2013 terminamos por hoy. Esta vez ha sido un buen día, pues hemos resuelto exitosamente un nuevo reto / requerimiento de cliente!

¡Salud!

martes, 20 de mayo de 2014

Incoherencias de Workflows en SharePoint Designer 2013

Cuando uno viene de pelearse con múltiples Workflows en SharePoint Designer 2010, tiene unas ganas tremendas de trabajar con los Workflows de SharePoint Designer 2013 y sus flamantes nuevas características tales como: Bucles, llamadas a Web Services, Variables de tipo “Diccionario”, Invocación interna a otros Workflows… ¡Y es cierto! SPD 2013 viene con muchas características nuevas de las que podemos sacar buen provecho en nuestros nuevos flujos, sin embargo… ¡¡ALERTA!! No empieces a implantar un flujo en SPD 2013 sin haber analizado previamente los requerimientos que necesita tu Workflow, porque, desgraciadamente, SPD 2013 también tiene pérdidas funcionales respecto SPD 2010. Por increíble que suene, es cierto: Por un lado SPD 2013 tiene nuevas y atractivas funcionalidades, pero por otro pierde algunas también muy básicas y en ocasiones imprescindibles, que te pueden llevar al arrepentimiento de haberte embarcado en la aventura de los flujos en 2013.

En este post analizaremos todas esas carencias (incoherencias según mi punto de vista), y como se podrían llegar a corregir (alguna de ellas). Sobre todo ten bien presente esto: No todos los nuevos Workflows los debes implantar en 2013, algunos serán posibles únicamente en modo 2010. Recordad que SPD 2013 permite trabajar con flujos de tipo 2013 o 2010, según elija el usuario. Quizás hoy entiendas realmente el por qué.

image

1.- No existe la posibilidad de crear un “Impersonation step”: Cuando un usuario lanza un workflow, este se ejecuta con las credenciales del usuario iniciador. Si se desea realizar tareas con permisos de otro usuario concreto, en 2010 teníamos la opción de crear “impersonation steps”. Estos pasos se ejecutaban con las creedenciales del usuario que había implantado el flujo (se debía vigilar que si el usuario dejaba la empresa y se borraba del AD, previamente se había cambiado los permisos de estos “impersonation steps” a un usuario distinto). Pues bien, esto en 2013 ya no existe. No hay posibilidad de simularlo. Simplemente los permisos de un flujo serán siempre los del usuario que lo ejecute.

2.- No se puede modificar la seguridad de un elemento (ítem o documento): Esta es una carencia muy grave, pues muchos flujos requieren este tipo de acciones. En 2010 sólo se podía hacer mediante un “impersonation step”, pero como en 2013 no existen… tampoco se pueden utilizar las acciones que sí teníamos en 2010:  “Add List Item Permissions”, “Inherit List Item Parent Permissions”, “Remove List Item Permissions” y “Replace List Item Permissions”.

image

Entonces, si tengo un workflow en 2013 que necesita modificar los permisos de un documento en una biblioteca o de un ítem en una lista. ¿Cómo puedo hacerlo? Agarraos fuerte: Invocando un flujo de SharePoint 2010 desde el flujo de 2013

3.- Wait for a field change extremadamente limitado: En muchas ocasiones, para aseguraros de que vuestro flujo se ejecuta una única vez, o una cierta parte se ejecuta únicamente cuando se ha informado correctamente un campo del formulario del documento/item original, la única acción de SPD que os puede ayudar es la de “Wait for a field change”. Esta acción permite que el flujo se quede “a la espera” de que el valor de un campo indicado concreto cambie para seguir. Imaginaos un flujo con estados, por ejemplo. El estado inicial puede ser “Pending”, y podría cambiar a “Approved” o “Rejected” en función de la decisión del validador. Bien, en 2010 podíamos utilizar “Wait for Approval Status to not equal Pending”, pero en 2013 no se puede, porque no existe el “to not equal”, la única opción aquí es “to equal”. Esto que a simple vista puede parecer una tontería, puede invalidar un flujo por completo realizado en 2013. Observad las diferencias:

En SPD 2010:

image

En SPD 2013:

image

Como veis “to equal” no permite ninguna sustitución, limitando enormemente esta potente acción de 2010. Uno podría pensar que se podría compensar usando un bucle que se ejecutara continuamente hasta que “Approval Status” not equals “Pending”, pero, amigo mío, eso implicaría tener el flujo continuamente en ejecución (consumiendo recursos de servidor), y si tu empresa es grande y tiene 600 flujos (o 60.000) recorriendo bucles constantemente, más vale que te apartes lejos antes de “sentir” la explosión.

Ya pensando a la desesperada, podrías llegar a pensar: “pongo un flag”. Un flujo en 2010 que sí tenga el “Wait for Approval Status to not equal pending” que cuando cumpla la condición modifique un campo (flag) del ítem a un valor establecido, y otro flujo en 2013 esperando que ese campo (flag) cambie a ese valor establecido (rocambolesco, eh!?), pues bien, en caso de que tengais el “content approval” de una biblioteca/lista activado tampoco os va a funcionar, porque esa característica incluye en sí misma que una modificación en un campo del ítem invalida la validación previa, de forma que si alguien valida un documento y el WF 2010 cambia el flag de 0 a 1, automáticamente el documento se “desvalida” y vuelve a quedar a “Pending”, así que cuando el WF 2013 se active porque el flag ha cambiado de 0 a 1, el documento ya no estará validado (mas rocambolesco todavía!!). Total, que no existe una solución medianamente “polite” a esta encrucijada (¡Bravo Microsoft!). Personalmente he tenido que tirar a la basura flujos de 2013 por este motivo, y rehacerlos de nuevo en 2010.

4.- Lookups con campos adicionales: En SPD 2010, si tu tenías una lista donde habías definido algún campo de lookup con campos adicionales de la lista origen, estos campos eran accesibles desde SPD en un Workfow asociado a esta lista. En SP 2013 únicamente puedes acceder al campo base, pero no a los relacionados. Otra pérdida insustituible.

En SPD 2010:

image

En SP 2013:

image

Aquí podríais pensar que si el listado muestra el “Título” del campo origen, podrías hacer un query a la lista relacionada y devolver el resto de campos que vinculan a ese elemento. Pero… ¿Y si diversas tareas pueden tener el mismo título? Podrías encontrarte que no te retorna los valores que deseas… Un desastre en toda regla. Triste

5.- En SPD 2013 no existe el “else-if”, tan solo “else”:

En SPD 2010:

image

En SPD 2013:

image

En este caso (también incomprensible) está claro que no queda otra que incrustar ramas condicionales independientes (sin “else”) para ir evaluando en cada caso las posibles condiciones. Evidentemente este flujo gastará mayor tiempo de proceso, al tener que analizar cada condición, cuando con el if-else tan sólo hubiera tenido que analizar de forma descendiente hasta encontrar la condición que se cumple en cada caso. En fín, ¡Es lo que hay!

6.- Tan solo se pueden invocar flujos de 2010: SPD 2013 tiene una nueva acción de “Start a List Workflow”, que puede venir estupenda para invocar otros flujos desde el propio flujo, pero ¡Atención!… ¡Sólo se pueden invocar flujos de 2010!

image

7.- Los procesos de aprobación están mucho más limitados en 2013: En SP 2010 podíamos generar una acción de tipo “Start Approval Workflow”, que nos daba la posibilidad de configurar múltiples parámetros de un proceso de validación. Ahora esta acción ya no existe, y en cambio hay otra llamada “Start a Task Process”. Todo cuando permite esta tarea aparece en la siguiente imagen

image

Comparado con la versión 2010 que podíamos modificar el comportamiento de las tareas o del proceso completo, en 2013 nos daremos cuenta enseguida que hemos perdido muchísimas posibilidades de configuración. Un ejemplo flagrante: En 2013 no se puede hacer un “Change Requests” como en 2010 (retornaba la tarea al solicitante para pedirle cambios antes de continuar la validación).

Además, como podréis apreciar en la siguiente imagen, el número de tareas que se pueden realizar en la sección “Task Actions” ha quedado reducida de 6 en 2010 a 2 en 2013. Ahora tan solo podremos asignar una tarea individual a una persona o iniciar un proceso de validación (el que hemos mostrado con más detalle en la imagen anterior).

image

Pues ahí tenéis todas las “incoherencias” que de momento he encontrado en SPD 2013 construyendo flujos de trabajo en modo 2013 (que no son pocas). Supongo que no seré el único en concluir que hay muchas incongruencias en estos flujos. Sobre todo recordad: No os pongáis a implantar flujos en modo 2013 a diestro y siniestro. Si necesitáis acciones como modificar permisos de ítems/documentos, controlar bien un proceso de validación o dejar el flujo pausado hasta que una columna asuma diversos valores posibles, lo tendréis que implantar en modo 2010… o en Visual Studio, claro está.

La duda que dejo en el aire es: ¿Cuando salga SharePoint 2016 (a finales de 2015), los flujos construidos en modo 2010 seguirán siendo compatibles/migrables? Nunca perdáis la esperanza, siempre hay que soñar con un mundo SharePoint mejor…

Entre tanto, ya salió el Cumulative Update 2 para Workflow Manager 1.0, que aporta corrección a bugs, mayor velocidad de proceso (sí, por favor) y acciones para detener y reanudar flujos (habrá que probar si aplican tanto en modo 2010 como 2013): http://support.microsoft.com/kb/2799754

¡¡Saludos!!