Un Workflow (Flujo de Trabajo) tiene por objetivo ser un modelo de un proceso de negocio (o producción) e implica un conjunto de actividades (tareas) que se aplican y operan en forma progresiva. El Workflow describe el orden de ejecución y las relaciones de dependencia entre las distintas activdades para que estas trabajen progresivamente a través de un modelo desde un inicio a un fin. Estas son actividades realizadas por las personas en forma manual y/o con el apoyo de funciones del sistema.
El Motor de Workflow en “Tiempo de Ejecución” (Runtime)
Cada instancia de un workflow en ejecución es creada y mantenida en tiempo de ejecución por un motor que actúa en el domino de proceso de una aplicación determinada (in-process runtime engine) y que la da albergue. Pueden existir varios procesos en ejecución dentro del dominio de proceso de una aplicación, cada instancia del motor en ejecución puede soportar multiples instancias de workflow que se ejecutarán de modo concurrente y podrán orquestar un conjunto de tareas o actividades.
Cuando un módulo de workflow se compila, este puede ser ejecutado “dentro” de cualquier proceso Windows, incluyendo una aplicación de consola, aplicaciones basadas en formularios, Servicios Windows, Sitios Web de ASP.NET, y Servicios Web, entre otros, como por ejemplo, los workflows que podemos ejecutar dentro de los procesos de SharePoint (independientemente de su versión). A este proceso lo llamamos “hosted” (alojados) en proceso, la idea es que el flujo de trabajo pueda comunicarse facilmente con la aplicación que le da alojamiento.
Asi por ejemplo, un workflow asociado a una biblioteca de documentos de SharePoint puede comunicarse a través de eventos con la instancia de la biblioteca de SharePoint que le da alojamiento (con la que se vincula). Si el vinculo se pierde estas piezas de software ya no podrían comunicarse entre sí.
Estudiando la ilustración siguiente podemos comprender esquemáticamente como se realiza este proceso de alojamiento (hosting), cual es el orden en que se comunican y se determinan entre si las distintas piezas de software que los desarrolladores construimos.
En particular, respecto de SharePoint, podemos construir estas piezas de software básicamente con 3 herramientas.
1.- SharePoint Designer (una herramienta poderosa y muchas veces insustituible, seguramente con la versión 2010 lo seguirá siendo, es recomendable aprender a usarla, para un desarrollador que espera avanzar en profundidad y amplitud el peor error que puede cometer es despreciar su utilidad.)
2.- Visual Studio (2005, 2008 y ahora 2010, siempre mejorando e imprescindible a la hora de tener que satisfacer requerimientos sofisticados por parte de nuestros queridos clientes. Un programador no puede olvidar jamás esa máxima de la economía que dice: el cliente siempre tiene la razón. Y todo es posible, solo son horas sillas, algunos dolores de cabeza, pero siempre mas tiempo y costos más elevados..je..je.. cada quien paga su propio costo…je..je.je.., nosotros dispuestos a la esclavitud de la silla, y nuestros clientes a decidir entre tiempo y costos, ROI y TCO… en fin Anton Pirulero… cada cual atiende su juego.. es la moraleja.)
3.- Herramientas de Terceros. De estas hay varias en el mercado, distintas en funcionalidades y costos, la herramienta de mejor relación costo-funcionalidades es sin duda Kaldeera.
Un par de links al respecto.
Kaldeera Diseñador de Workflows.
Y el sitio de Tito… Aquí.
Para Workflow en el MSDN pulse acá.
Esperando que les sea útil, y por supuesto esperando quejas, contribuciones, insultos, etc…je..je..
Un abrazo
Rolando
