Porque hacerlo fácil si se puede hacer difícil… SharePoint Tipos de Contenido, Flujos de Trabajo y cosas de esas

Flujos de Trabajo basados en el WorkFlow Foundation creados para SharePoint son algo entre maravilloso y la peor pesadilla de un desarrollador. Las posibilidades son inmensas, las ventajas de flexibilidad grandiosas y la información al respecto mínima.

Entiéndanme bien, me estoy refiriendo a Flujos de Trabajo de verdad, no los dos o tres ejemplos que Microsoft ha creado (y que vienen instalados por defecto en WSS y MOSS), o las chapuzas que se pueden hacer con el SharePoint Designer. Estoy hablando de Flujos de Trabajo para la vida real, para uso en procesos reales, no para los hipotéticos casos que uno u otro desarrollador de Microsoft se inventó en un momento de debilidad. Por ejemplo, según las especificaciones de Microsoft, a un flujo se le pueden colgar páginas Web para poderlos configurar al crearlos, al iniciarlos, para cambiarlos en medio de su funcionamiento o para que los usuarios interactúen con él. Las páginas pueden ser creadas con formularios InfoPath (la forma fácil, por supuesto con bastantes ejemplos regados por Internet y con todos los ejemplos que Microsoft proporciona), o con paginas aspx (la forma difícil, con un solo ejemplo proporcionado por Microsoft, y ningún ejemplo que se pueda encontrar en Internet). Pues bien, según Eilene Hao (Product Manager del WorkFlow Team de Microsoft, es decir, un Product Manager mas en el ejercito de PM’s de Microsoft), crear paginas aspx para interacción con usuarios en Flujos es “creating aspx forms is really just a matter creating an aspx form that makes a special workflow call. That Was Easy…Too Easy…”. La cosa es que lo fácil no es tan fácil, y nadie te cuenta cómo hacerlo, ni los problemas que te vas a encontrar. Cuando ya conoces el truco, después de días de sudor y lagrimas, de pronto tienes la tendencia a estar de acuerdo con ella, es fácil, tal vez demasiado fácil… si sabes cómo hacerlo…

El asunto es que cuando la interacción con el usuario es algo más que simplemente rellenar espacios con información, no puedes utilizar InfoPath, por sus limitadas posibilidades de programación. Validaciones complicadas, mostrar información dinámicamente dependiendo del estado del flujo, formateo especial de la pagina, todas son cosas que van entre difícil e imposibles de hacer con InfoPath. Así que en un flujo que va mas allá de preguntar el nombre y apellido, estás obligado a usar paginas aspx. Y todo se limita a crear un Tipo de Contenido de SharePoint, al que le cuelgas la pagina aspx, y al flujo le cuelgas el Tipo de Contenido… Suena sencillo, pero para que hacerlo fácil si es posible hacerlo difícil…

Luego te enfrentas a una buena cantidad de problemas de sincronización cuando el usuario guarda la información presente en el formulario aspx. Aquí la liga entre el formulario y el flujo se realiza por medio de la Lista de Tareas: en el momento que la información cambia, cambia también una tarea en la Lista, y esa es la señal para el Flujo de que algo tiene que suceder. El problema es que el formulario y el flujo trabajan en hilos separados (hilo == thread, la traducción nunca me ha sonado bien…), y puede suceder que los dos intenten “conversar” al mismo tiempo con la Lista de Tareas o con el elemento que está usando el flujo, así que los dos se pisan la soga, y el flujo se vuelve inestable. El mecanismo no está optimalizado en la Fundación o en su interacción con SharePoint, por lo que hay que poner timers por aquí y por allá para que el uno empiece a funcionar después de que el otro ha terminado, es decir, un Flujo de Trabajo para el Flujo de Trabajo… podría ser fácil, pero si se puede hacer difícil…

La actividad de Aplazamientos (“Delay Activity”) es otra maravilla. Microsoft ha tenido problemas con ella desde el principio de los tiempos, y después de dos Hot Fixes (“FIX: You experience various problems in Windows Workflow Foundation”, “A timer does not resume operation after a workflow is reloaded in Microsoft Windows Workflow Foundation”) y un Articulo KB (“A Microsoft Windows Workflow Foundation timer does not resume correctly after reloading a workflow”), funciona bien con cualquier tipo de Host para la Fundación, pero NO cuando SharePoint es el Host. Es decir, no funciona con SharePoint: el flujo llega hasta el Delay, lo comienza (dehidratación), pero nunca se recupera de el (rehidratación)… no produce ningún tipo de error, de señal de que algo no está bien, nada, nada, simplemente nunca despierta… Blanca Nieves a la que nunca le llega el Príncipe a darle el beso…

Finalmente, para no aburrirlos mas con este drama digno de una Telenovela, una perla de inconsecuencia: cuando quieres crear una Tarea acoplada al flujo, pero no desde el flujo mismo (obligatorio de hacer para poder solucionar el problema del Delay), tienes que contarle a la tarea cual es el Tipo de Contenido que tiene que usar (un formulario aspx en un flujo no es más que un Tipo de Contenido, se acuerdan?). Pues bien, creas la tarea programáticamente, en tu Lista de Tareas:

SPListItem myNewTask = myTasksList.Items.Add();

Anteriormente ya has encontrado el Tipo de Contenido de tu flujo en la Lista, y creado una instancia de él:

SPContentType myFlowContentType = null;

foreach (SPContentType myContentType in myTasksList.ContentTypes)

{

      if (myContentType.Name == “NombreDelFlujo”)

            myFlowContentType = myContentType;

}

Y simplemente le quieres decir a la nueva tarea que use ese Tipo de Contenido:

myNewTask.ContenType = myFlowContentType;

Sencillo, verdad? Pues no, por eso de lo que para que hacerlo fácil, etc., técnicas sencillas de Orientación a Objetos no funcionan en este caso… y después de mucho ensayar encuentras que lo tienes que hacer por medio de las propiedades de la Tarea:

myNewTask[“ContentTypeId”] = myFlowContentType.Id;

Lo que es cierto es que si sobrevives la tentación a suicidarte con un banano, los mal genios y depresiones, programar SharePoint nunca te aburre…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

6 comentarios en “Porque hacerlo fácil si se puede hacer difícil… SharePoint Tipos de Contenido, Flujos de Trabajo y cosas de esas”

  1. buuuuuuuuuuuu ,
    estoy al borde de un suicidio con un proyecto con sharepoint , infopath y visual studio 2005.
    y todo esto con workflow y webparts .
    lo unico que me faltaba es que en la empresa quieran integrarlo con SAP. jaja

    Si tienes algun ejemplo estable de trabajar con infopath y sharepoint programados con .net te lo agradeceria

    NICO.

  2. Hola…Entonces para el flujo de procesos, si no es esta pesadilla, ¿Qué me recomiendas?. Y piensa que además del flujo de procesos, alarmas, colgar archivos, interactuar con todos los del equipo, debo poder ingresar indicadores y hacer seguimiento y penalización de incumplimientos. Ojalá me puedas ayudar.

  3. Recien inicio a trabajar en workflow, pero tengo algunos años de trabajar en .net.

    He ingresado a un equipo donde trebajamos con Ultimus, pero queremos analizar si WWF puede ser una opción “periferica” a necesidades del cliente mas hechas a la medida.

    Cual literatura, ejemplo o referencia me sugieres para empesar a analizar un aproximamiento?; esperamos apeganos a la propuesta arquitectonica de microsoft.

    saludos

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *