Comenzando con WF: Paso de Datos y Runtime Services!

A menudo, en el CIIN se nos pregunta cuál es nuestro cometido, que tipo de cosas hacemos, si conocemos tal tecnología, etc. Bueno, pues la verdad es que hacemos de todo un poco, y uno de nuestros cometidos principales es actuar como difusores de tecnologías .NET en Cantabria, y para ello cada semana damos un pequeño seminario al que asisten distintas empresas TIC de Cantabria. Hasta ahora hemos dado seminarios de WSSv3 / MOSS, WF, WCF y estamos preparando otros (LINQ, BizTalk 2006, etc.). En mi caso, ya he dado un par de seminarios introductorios de WF, por lo que como ha hecho Carlos Segura con sus excelentes posts sobre WF, me he animado a contar algunas de las cosillas que contamos en el seminario que impartimos en el CIIN. En concreto, comentaré aspectos referentes al paso de datos a un workflow y el cómo añadir servicios al runtime de ejecución de workflows. Antes de empezar, no está de más recordar cómo es la arquitectura  de WF:



Como comentaba Carlos Segura en su primer post, un workflow está compuesto por una serie de componentes, llamados actividades, que se enlazan de manera adecuada (y en función de estilo de creación del workflow, secuencial o máquina de estados) para constituir un modelo ejecutable de un cierto proceso de negocio. Como vemos en el diagrama de la arquitectura de WF, tenemos 5 elementos fundamentales:


·         Un diseñador visual de workflows, para crear nuestros worflows en base a arrastrar actividades sobre una superficie por diseño. Por defecto el entorno natural para la creación de workflows es Visual Studio 2005 que actúa como hoster del diseñador visual de WF. Para tener disponible este diseñador, necesitamos las extensiones de WF para VS 2005. Como ya nos comentó Unai, el diseñador de WF se puede “sacar” del entorno de WF y hostearlo en otros entornos. Dos ejemplos de esto los tenemos con NetfxLive (un diseñador de workflows embebido en una aplicación web) o la aplicación WFPad.


·          Una librería de actividades base, que son un conjunto de actividades que por defecto nos da WF para crear nuestros workflows. Algunos ejemplos de actividades son: IfElse, While, Policy, Delay, etc. Además de estas, ya tenemos actividades especificas para crear workflows en el entorno de WSSv3: SendEmail, OnTaskChange, OnWorkflowActivated, etc (estas actividades las tenéis a partir de la dll Microsoft.SharePoint.WorkflowActions.dll que tenéis que hay que añadir como referencia en nuestro proyecto de wrokflow para sharepoint y en en la toolbox de VS 2005), interactuar con servicios de WCF, y otros muchos ejemplos en el sitio oficial de WF .


·         El runtime engine de WF, que es el responsable de la ejecución, control y gestión de las distintas instancias de workflows que tengamos creadas. Los componentes fundamentales son el motor de ejecución, los core services  para el motor de ejecución (que se encargan de controlar la ejecución de los workflows), y el motor de reglas que permite utilizar reglas de negocio en nuestros workflows.


·         Los servicios de runtime, que son piezas enchufables que permiten extender las capacidades del motor de ejecución de WF habilitando la posibilidad de persistir el estado de ejecución y los datos de un workflow, realizar un seguimiento (tracking) de las instancias del workflow en ejecución, comunicarlo con el exterior (aplicaciones locales y remotas), etc.


·         Proceso de host, que se encarga de hospedar tanto el runtime engine como los runtime services, es decir, es el que en la práctica se encarga de instanciar y arrancar el motor de ejecución de WF, así como de instanciar los servicios de runtime necesarios.  En este link podéis ver un estupendo resumen de todo lo que se puede hacer en el proceso de host de WF. Finalmente comentaros que la naturaleza del proceso de Host de WF es realmente variada, desde un servicio Windows o una aplicación de consola, pasando por un formulario Windows (justo el caso que veremos en este post) o una página ASP.NET, hasta entornos más complicados como WSSv3 o la BTS 2006 R2.


Después de este repaso arquitectónico, es momento de comenzar con los dos tópicos de este post: paso de datos a un workflow y uso de los servicios de runtime.


Paso de datos a un workflow


En el segundo post de su serie sobre WF, Carlos Segura ya nos introdujo uno de los mecanismos para pasar datos a un workflow: el paso de parámetros. La idea es explicaros un poco más en detalle cómo se implementa este paso de parámetros y que otras posibilidades tenemos para pasar información a nuestro workflow. Para ello, voy a partir de un sencillo workflow que calcula el factorial de un número y muestra un mensaje con el resultado.



Para pasar datos al workflow mediante el método de paso por parámetros, lo primero que tenemos que hacer es definir las propiedades necesarias en nuestro workflow. En nuestro caso vamos a pasar al workflow un único parámetro que vamos a pasar es el número cuyo factorial queremos calcular. Por lo tanto, en la vista de código de nuestro workflow sólo tendremos que añadir una propiedad que luego utilizaremos en la lógica que modela el comportamiento del workflow (a través de las actividades condicionales y las actividades code):







        private string numero;


 


        public string Numero


        {


            get { return numero; }


            set { numero = value; }


        }


 


El siguiente paso es definir el paso de parámetros en el momento que se crea la instancia del workflow. Esto lo haremos en el hosting process que hayamos definido. En mi caso, he creado un simple formulario de Windows en el que en una caja de texto se recoge el valor numérico cuyo factorial queremos calcular.  El código necesario para instanciar el runtime de WF, crear una instancia  de nuestro workflow y pasar el parámetro sería el siguiente:







public partial class Form1 : Form


    {


        private WorkflowRuntime WR;


        public Form1()


        {


            InitializeComponent();


        }


        private void button1_Click(object sender, EventArgs e)


        {


            if (WR==null)


            {


                WR = new WorkflowRuntime();


                WR.StartRuntime();


            }


            Dictionary<string, object> parametros = new Dictionary<string, object>();


            Parámetros.Add(“Numero”,textBox1.Text);


            WorkflowInstance MiInstancia=WR.CreateWorkflow(typeof(Ejemplo_WF.Workflow1),parametros);


            MiInstancia.Start();


        }


       


        private void Form1_FormClosed(object sender,FormClosedEventArgs e)


        {


            if (WR!=null)


            {


                if (WR.IsStarted)


                {


                    WR.StopRuntime();


                }


               }


        }


    }


 


Como vemos en el código anterior, los pasos para hostear el runtime engine de WF, crear una instancia de nuestro workflow y realizar el paso de parámetros son:


·         Crear una instancia del runtime engine, y a continuación iniciarlo.


·         Definir un diccionario de parámetros al que posteriormente le añadimos nuestro parámetro. Este diccionario lo hemos que definir de acuerdo a dos restricciones: (i) Los parámetros sólo pueden ser de tipo string y (ii) El nombre de los parámetros ha de coincidir con las propiedades que hayamos definido en nuestro workflow.


·         Crear una instancia de nuestro workflow y realizar el paso de parámetros.


Comentaros que he incluido una función asociada a la acción de cerrar el formulario y en la que se para el runtime de WF en el caso de que decidamos cerrar el formulario. Por supuesto, la gestión del runtime de WF se puede hacer mucho mejor, aquí tenéis un ejemplo de un servicio Windows que actúa como hoster de WF y que incluye métodos para gestionar el inicio, parada o ejecución del workflow a partir de sobreescribir los métodos correspondientes. Finalmente, si probamos nuestro workflow con paso de parámetros, este sería el resultado:



¿Qué otras formas hay para pasar datos a un workflow? Además del paso de parámetros, WF define cuatro mecanismos adicionales:








 


ü Mediante el uso de eventos a través de las actividades HandleExternalEvent y CallExternalMethod que habilitan respectivamente el paso de datos desde el exterior al workflow y desde el workflow al exterior.


ü Mediante la invocación de servicios web, a través de las actividades InvokeWebService, WebServiceInput y WebServiceOutput, que habilitan el paso de información en modo remoto bidireccional, entrante y saliente.


ü La misma idea que con la invocación de servicios web, pero invocando servicios WCF y utilizando para ellos las actividades ya disponibles en Codeplex.


 



 


ü  Crear una actividad customizada que nos permita realizar el paso de datos.


ü  Definir el paso de datos en una actividad de tipo code.


Añadiendo servicios al runtime


Añadir servicios al runtime de ejecución resulta bastante sencillo. En esta parte del post voy a explicar cómo se añade el servicio de tracking y que utilidad nos aporta en cuanto a información proporcionada.  Cómo su nombre indica, este servicio permite monitorizar y realizar un seguimiento de los workflows en ejecución. Como se dice en el SDK de WF, este servicio permite que el proceso de host “observe” las instancias de workflows en tiempo de ejecución a partir de capturar distintos eventos que se lanzan durante dicha ejecución. Hasta aquí todo está claro, pero ¿qué hace el servicio de tracking con la información observada? La respuesta es depende del servicio de tracking que utilicemos. WF trae por defecto una implementación out-of-the-box para este servicio que escribe la información de tracking en una base de datos creada a priori. Por supuesto, podemos definir nuestros propios servicios de tracking customizados y almacenar la información de tracking en otros contenedores (otros gestores de BD, archivos XML, etc.).


En el ejemplo de este post, voy a utilizar el servicio de SQLTracking que por defecto trae WF. Para ello, y como paso previo, necesito establecer la infraestructura necesaria para el servicio, es decir, crear la BD SQL Server y los elementos necesarios para habilitar su uso. Como os podéis imaginar, .NET Framework 3.0 viene con los scripts SQL necesarios (ubicados en C:WINDOWSMicrosoft.NETFrameworkv3.0Windows Workflow FoundationSQLEN):


·         Tracking_Schema.sql, que crea la estructura de tablas necesaria para almacenar la información de tracking en la BD que especifiquemos.


·         Logic_Schema.sql, que crea un conjunto de procedimientos almacenados necesarios para que el servicio de SQLTracking pueda almacenar la información de tracking, así como otros útiles para consultar dicha información.



Una vez creada la estructura necesaria para el servicio SQLTracking, para poder utilizarlo basta con añadir a nuestro servicio de host (en este caso un formulario Windows) las siguientes líneas:







SqlTrackingService ServicioTracking = new SqlTrackingService


                    (“Data Source=MOSS2007;Initial Catalog=WF_Tracking;Integrated Security=True”);


WR.AddService(ServicioTracking);


 Nota: Para poder utilizar el servicio de SQLTracking, tenemos que añadirlo al runtime de WF antes de iniciarlo.


Sin más, si ejecutamos nuestra aplicación y realizamos la siguiente consulta SQL en la BD de tracking creada, obtendremos información interesante relativa a las etapas de ejecución por las que ha pasado una o varias instancias de un workflow.







SELECT  TrackingWorkflowEvent.Description as Fase_Ejecución,


WorkflowInstanceEvent.EventDateTime as Inicio_Fase,


WorkflowInstanceEvent.WorkflowInstanceInternalId as WorkflowId,


WorkflowInstance.WorkflowInstanceId as InstanciaWorkflow,


Type.TypeFullName as NombreWorkflow


FROM   WorkflowInstanceEvent


INNER JOIN TrackingWorkflowEvent ON


WorkflowInstanceEvent.TrackingWorkflowEventId = TrackingWorkflowEvent.TrackingWorkflowEventId AND


WorkflowInstanceEvent.TrackingWorkflowEventId = TrackingWorkflowEvent.TrackingWorkflowEventId


INNER JOIN WorkflowInstance ON


WorkflowInstance.WorkflowInstanceInternalId=WorkflowInstanceEvent.WorkflowInstanceInternalId


INNER JOIN Type ON


Type.TypeId = WorkflowInstance.WorkflowTypeId


order by WorkflowInstanceEvent.WorkflowInstanceInternalId



De acuerdo al SDK de WF, se puede hacer el tracking a nivel de instancia de workflow de los eventos definidos en la enumeración TrackingWorkflowEvent.



Además de los eventos a nivel de instancia, el servicio SQLTracking permite capturar y almacenar información relativa al estado de ejecución de las actividades que componen un workflow. Los estados posibles de ejecución de una actividad está recogidos dentro de la enumeración ActivityExecutionStatus y son 6: Initialized, Executing, Canceling, Closed, Compensating y Faulting. Así, si ejecutamos la consulta siguiente contra la BD de tracking, obtendremos información interesante relativa a los estados de ejecución de las actividades que componen nuestro workflow.


 







select T.TypeFullName as Instancia_Workflow,AI.QualifiedName as Actividad,


A.ParentQualifiedName as ActividadPadre,AES.Description as Estado_Ejecucion


from ActivityInstance AI


INNER JOIN ActivityExecutionStatusEvent AESE ON


AESE.ActivityInstanceId=AI.ActivityInstanceId


INNER JOIN ActivityExecutionStatus AES ON


AES.ExecutionStatusId=AESE.ExecutionStatusId


INNER JOIN WorkflowInstance WI ON


WI.WorkflowInstanceInternalId=AESE.WorkflowInstanceInternalId


INNER JOIN Type T ON


T.TypeId = WI.WorkflowTypeId


INNER JOIN Activity A ON


A.WorkflowTypeId=WI.WorkflowTypeId AND


A.QualifiedName=AI.QualifiedName


order by AESE.ActivityExecutionStatusEventId



Bueno, pues esto ha sido todo. Me podría extender con la parte de los servicios de runtime de WF, pero creo que el post ya es lo suficientemente largo y espeso. Espero que os hayan resultado interesantes los temas tratados.

Publicado por

Juan Carlos González

Juan Carlos es Ingeniero de Telecomunicaciones por la Universidad de Valladolid y Diplomado en Ciencias Empresariales por la Universidad Oberta de Catalunya (UOC). Cuenta con más de 12 años de experiencia en tecnologías y plataformas de Microsoft diversas (SQL Server, Visual Studio, .NET Framework, etc.), aunque su trabajo diario gira en torno a SharePoint & Office 365. Juan Carlos es MVP de Office Servers & Services desde 2015 (anteriormente fue reconocido por Microsoft como MVP de Office 365 y MVP de SharePoint Server desde 2008 hasta 2015), coordinador del grupo de usuarios .NET de Cantabria (Nuberos.Net, www.nuberos.es), co-fundador y coordinador del Grupo de Usuarios de SharePoint de España (SUGES, www.suges.es), así como co-director de la revista gratuita en castellano sobre SharePoint CompartiMOSS (www.compartimoss.com). Hasta la fecha, ha publicado 8 libros sobre SharePoint & Office 365 y varios artículos en castellano y en inglés sobre ambas plataformas.

29 comentarios en “Comenzando con WF: Paso de Datos y Runtime Services!”

  1. Pedazo de Post… ya que has hablado tanto podrías haber hablado de los TrackingChannel y de las opciones de partición en el servicio de tracking.
    A ver si saco un rato y sigo yo también hablando en mi blog de Workflow, aunque ya casi llevo más post de WF que de mobile… me cachis!!!

    Muy bien Juan Carlos

    Unai Zorrilla Castro

  2. Muy bueno el post, a mi me pasa como a Unai, que en vez de hablar de SharePoint, me enganche con los Workflows y …. por cierto, como en la siguiente parte hablo de persistencia, te enganchare este post y más adelante con el tracking también.
    Saludos,
    cseg.

  3. Gracias por los comentarios Carlos, seguro que nos cuentas cosas muy interesantes del servicio de persistencia…creo que el próximo post mío será de nuestro amigo BizTalk o de LINQ, ya veremos de que se me ocurre algo interesante que contar la próxima vez…aunque quizas algo de WF con WCF (aqui cuento con mi compi de al lado Ángel) puede ser interesante…ya se verá.

    JC

  4. Help!!
    Como relaciono mis entidades (en este caso carpetas que pasan por distintos usuarios) que son parte de un flujo, con la base de datos de WF y mi BD. ¿WF almacena mis entidades en su BD? o ¿debo crear mis entidades en una BD? y como las relaciono.. tankYou

  5. Hola rOLO,
    No entiendo muy bien la duda que planteas…y para aclarar que problema tienes:
    ¿En qué escenario estás construyendo el flujo d trabajo?El hecho de que hables de carpetas me ha pensar en Sharepoin…
    ¿Para qué necesitas relacionar las carpetas con la base de datos de WF? Esta se utiliza para lo que es: almacenar el estado del workflow, las etapas por las que ha pasado, etc.
    En cualquier caso, esas entidades de las que hablas y para un modelo relacional de datos deberían estar en una BD separada, no en la de WF…

    JC’s

  6. Me explico mejor:

    a tu 1ra pregunta:

    Carpeta es un “Folder” que contiene un conjuntop de actividades (cronograma) en los que se indican monto q se tendra q invertir en cada actividad, la fecha y lugar de la ejecucion y algunos datos mas. Esta carpeta es un plan pero que no esta aprobado, entonces esta carpeta tendra que pasar ordenadamente por distintos usuarios=roles (validador, aprobador, verificador y por ultimo otro usuario q lo llamamos =oficial de proyecto) cada rol descrito tendra que dar un VoBo o un Rechazo, luego de evaluarlas.

    a tu pregunta:
    ¿Para qué necesitas relacionar las carpetas con la base de datos de WF?

    Perdon pero medio q estoy en la luna en este tema. mejor explicame como es que se
    relacionana lo que es el WorkFlow Found.. y mi
    aplicación:

    algo asi??:

    MiBD Tracking (BD WF)
    ================= ===============
    una de mis tablas alguna tabla WF
    ================= ===============
    campoWF1ID <-------------- campoWF1ID WorkflowInstanceId camposWF2 MiCampo1 MiCampo2 ¿debo crear mi tabla de esa manera, instanciando a algun campo clave de alguna tabla de WF? ¿la Base de datos de WF tiene relacion 1 a 1 con alguna aplicación tipo workflow?, ¿debo crear la base de datos WF (Tracking_) para cada aplicacion tipo workflow q pueda desarrollar? o ¿una vez que tenga creada la base de datos Tracking sera suficiente para N aplicaciones workflow? Gracias por tu explicacion. perdon por tardarme.

  7. Hola Rolo,
    Creo que estás confundiendo los conceptos de tracking de WF con tus requerimientos de worklfow…son cosas distintas. La BD de tracking lo que almacena es información de como se ha realizado la ejecución del workflow y nada más que esto…por lo tanto, si necesitas monitorizar como se están comportando tus workflows, entonces la tienes que instalar. Si no lo necesitas, entonces no te hace falta.

    Para el escenario que planteas, parece claro que necesitar guardar la información de los estados de aprobación en algún sitio…como no esás utilizando SharePoint (escenario más adecuado para una aprobación de documentos), tendrás que quedar tu modelo de tablas que te permita ir guardando el estado de aprobació de los distintos documentos. Luego en el workflow irás utilizando estos estados para que el proceso de aprobación continue.

    Salu2

    JC

  8. Hola

    Mi pregunta es si las tablas que crean los scripts de workflow se pueden modificar??? es decir agregar campos tal vez o cambiar los nombres de algunos indices como lo son los estados del wf dentro de las tablas??

    para que nos pueden servir los stored procedures que se crean?? o si solo los trabaja el wf como tal??

    que tipo de informacion saco de estas tablas, se que guardan algunas cosas como nombre de actividades, tipo de wf, etc, a lo que voy es que estare desarrollando un wf para aceptacion de documentos (habra personas que aprueben esos documentos o quienes los regresen a otros estados) me podria ayudar este servicio del wf?? o simplemente es un serivicio interno q el wf tiene y para los que lo utilizamos si no nos metemos con el este mismo se controla solo??

    Muchas gracias por la atencion que puedan prestar a mi consulta.

  9. Hola Danna!
    Pues está claro que puedes modificar las tablas, pero el tema es que el servicio de tracking que viene con WF no te va a llenar las columnas adicionales que vayas a añadir a las tablas…sin analizar en detalle los SP que existen en la infraestructura de tracking, estos te serviran tanto para manipular datos de tracking como para consultarlos…si vamos ya al detalle de lo que necesitas en concreto, creo que vas por el camino equivocado. El servicio de tracking te permite realizar un seguimiento de como es la ejecución del workflow independientemente de los detalles del mismo. Por lo tanto, para modelar el escenario de workflow que me dices no necesitas este servicio, sino que en el fondo estás utilizando el servicio de persistencia…de todos modos, un workflow de WF diseñado con la funcionalidad que describes no necesita necesariamente que persistas datos en una BD puesto que me estás hablando de transiciones entre estado…luego como bien dices, es un servicio interno de WF y la utilidad que tiene es que podrías crear un cliente de monitorización que permita ver de manera visual como se está realizando la ejecución del workflow…de hecho, esto es lo que se hace dentro de SharePoint…se utiliza el servicio de tracking para guardar en una History List como se ha realizado la ejecución del workflow.

    Espero que con esto tengas más claro por dónde seguir.

    Un saludo

    JC’s

    p.d: Por cierto, ¿desde dónde nos escribes?

  10. Hola de nuevo!! Te escribo desde Mexico, con las observaciones que me comentas sobre los SP del tracking del WF mi duda es como puedo hacer las consultas necesarias para explotar la informacion si desconozco en si que es lo que se guardan en esas tablas y/o campos (por eso mi pregunta de que es lo q se guarda especificamente en estas tablas y en que pudiera ayudar al desarrrollador este servicio).
    En cuanto a que me beneficiaria el servicio de persistencia pues estoy en las mismas condiciones ya que como hace la persistencia de manera trasparente en que momento yo cambiaria el estatos no del wf si no del documento q se va creando con el wf??. Y no se si se aplica lo que comentas del Sharepoint a una aplicacio Web.

    Nuevamente muchisimas gracias!!!

  11. Hola Juan Carlos.

    En un principio he entendido a medias tu post sobre workflow. La verdad me ha parecido muy bueno, por la razon de que, he visto un sinfin de paginas de workflow, pero o soy muy cabeza dura, o definitivamente los cursos que he visto de WWF son muy malos. No se les entiende nada, incluso la misma pagina de microsoft al empezar a explicar que es WWF te bombardea con un monton de informacion, hablandote de clases que no se entienden nada, para terminar con una explicacion magistral sobre fisica cuantica y ecuaciones diferenciales (ironia). En resumen, de workflow no entendi casi nada.

    Bueno, ya dejando de quejarme. Tengo varias dudas al respecto. Se como diseñar un flujo de trabajo en Visual Studio, y lo que se necesita para ejecutarlo, pero tengo muchisimas dudas acerca de como usar un workflow en una aplicacion ASP.NET.

    He leido que en ASP.NET la cosa cambia un poco. Puede haber solo UNA instancia del workflow en el application domain, esto significa que en una aplicacion ASP.NET debe existir solo 1 instancia, creandola, y agregandola al objeto Application, entonces aqui surge la primera de un monton de dudas:

    – Por motivos laborales debo comenzar a utilizar workflows. Tengo una aplicacion ASP.NET que se encarga de hacer un seguimiento de pedidos, por lo que aparentemente implementar workflow vendria como anillo al dedo. Obviamente, muchos usuarios pueden ingresar a la aplicacion con su username y contraseña… pero… como puede ser que solo debe haber 1 instancia???? Otros usuarios no podrian ver el seguimiento de sus pedidos entonces?

    Ademas, cada usuario hace muchos pedidos y quieren saber el estado en que se encuentra cada uno de esos pedidos… y pregunto nuevamente, como entonces se puede hacer si solo debe existir 1 sola instancia del workflow??? (eso de la unica instancia lo he leido en varias paginas que he visitado).

    Otra cosa, como los pedidos se tardan varios dias en llegar a su destino (estamos hablando de camiones que viajan entre ciudades distantes a mas de 600 kilometros por lo menos), entonces lo ideal es que el workflow sea persistente, y que para eso debe habilitarse el servicio de persistencia, que por lo menos tengo cierta idea de como se activa. Pero en ninguna parte explica como se usa realmente. He visto ejemplos que muestran que el servicio de persistencia esta funcionando y nada mas, no he visto algun ejemplo real (quizas no he buscado bien). El usuario que quiere ver en que estado está el pedido que hizo hace 2 dias, logicamente en algun momento apago la computadora desde donde ingresa a la aplicacion y se fue a su casa a dormir y volvio al dia siguiente para ver como va su pedido… no he encontrado informacion sobre como restaurar el workflow desde el ultimo estado en que quedo, me parece que existe un metodo Load() pero no me encaja bien como se usa correctamente si, otra vez, solo puede existir 1 sola instancia del workflow (y tengo muchos usuarios que quieren ver como van todos sus pedidos).

    Bueno, como puedes ver, tengo demasiadas dudas, te agradeceria muchisimo si me pudieras aclararlas. Me gustaria saber si eso es posible de hacer y que necesito para hacerlo, o alguna pagina o recurso que explique como hacerlo.

    Desde ya muchas gracias.

  12. Hola Juan Carlos.

    Tengo un problema con esto del workflow, y es que tenia definido un workflow y funcionaba perfectamente, pero por cuestiones de algunos cambios en las actividades para los que lo utilizaba surgio la necesidad de hacerle algunos ajustes al workflow y ahora las instancias que tenia ya creadas no las puedo cargar, no se lo que se tenga que hacer para que cada que le haga cambios a mi aplicacion los workflows ya creados pueda cargarlos sin nungun problema.

    Si tienes alguna informacion al respecto o la solucion a este problema si es que te ah pasado y veo que eres un experto con la herramienta, te lo agradezco.

  13. Bueno, vayamos por partes…no estoy seguro de si los dos últimos comentarios son de personas distintas, voy a suponer que sí…empecemos por Daniel.

    Está claro que WF es una tecnología compleja de por sí, no es tan bonito como lo pintan: arrastro mis actividades y está, sino que para hacer cosas complicadas es necesario entender muy bien la arquitecturade WF (persistencia, tracking, paso de parámetros, etc) y tener un buen bagaje en programación en plataforma .NET (un alto nivel diría yo).

    Respecto a las dudas que planteas:
    1) En entorno ASP.NET, no he tenido la oportunidad de hacer o probar workflows en aplicaciones ASP.NET puras, pero si en un entono similar como es SharePoint (que está plenamente basad en ASP.NET) y te puedo decir que me suena raro lo que has leído y más raro aún la restricción que comentas de tener una sóla instancia de wokflow por dominio de aplicaión…es más, el escenario que planteas para gestión de pedidos es idéntico al de SharePoint y getión documental, por lo que sin duda lo que has leído es incorrecto o te ha liado. Te explico lo que pasa en SharePoint y lo que mi intuición me dice que tiene que suceder en ASP.NET u otro entorno: sólo puedes disponer de una plantilla de workflow, es decir, un ensamblado y descripción del mismo cargado en la GAC, paths de tu aplicación, etc…luego el runtime de ejecución de WF ya sea en SharePoint, ASP.NET, etc se encarga de crear instancias de workflow a partir de esta plantilla (que si es única), de manera que puedes tener múltiples instancias de workflow en ejecución en tu aplicación…creo que con esta explicación resuelvo tu primera gran duda.

    2) Respecto a persistir el estado de ejecuión del workflow, es justo lo que comentas, tienes que habilitar el servicio de persistencia que hayas implementado para tu workflow y este se encargará de guardar los datos de ejecución del workflow en una BD (en SharePoint es en SQL Server y WF viene con implementación del servicio para SQL Server), de manera que cuando el flujo continue se pueda recuperar el último estado de ejecución y los datos para que el flujo pueda continuar. Algunos enlaces respecto al servicio de persistencia de WF:

    – Efectivamente, tal y como comentas, par recuperar el estado de ejecución del wokflown necesitas llamar al método Load() de la instancia en ejecución:
    http://weblogs.asp.net/gsusx/archive/2005/10/05/426699.aspx

    – Este post de Bart de Smet’s es muy descriptivo en cuanto a como usar el servicio e persistencia:
    http://bartdesmet.net/blogs/bart/archive/2006/10/14/4580.aspx

    – Otro enlace más sobre el tema:
    http://whiteknighttechnology.com/cs/blogs/bayer_white/archive/2007/04/17/1284.aspx

    Con esto espero haber resuelto tus dudas…de todos modos, te recomiendo también que adquieras algún libro sobre la tecnología. Uno que está muy bien es el de Unai Zorrilla, MVP de C# y que forma parte de Geeks.Ms y trabaja para Plain Concepts:

    http://geeks.ms/blogs/unai/archive/2007/10/15/mi-primer-libro-modelando-procesos-de-negocio-con-workflow-foundation.aspx

    Un saludo

    JC’s

  14. Hola Daniel Mata,

    Lo primero de todo, ¿en qué entorno se están ejecuntando esas instancias? De todos modos, estos problemas que tienes con las instancias antiguas son lógicos, puesto que ha cambiado el emsamblado…creo que de todos modos te estás liando un poco, si cambias tu workflow lo normal es que tengas que redesplegarlos y reconfigurar tu aplicación para que funciones con las nuevas versiones…

    Un saludo

    JC’s

  15. Que tal JC, efectivamente somos 2 personas diferentes, en cuanto a las instancias se ejecutan en paginas web ASP.NET; respecto a tu comentario no entiendo, el aspecto logico que mencionas; tengo el servicio de persistencia sql que viene por default en wf y mis instancias se persisten en dicho servicio pero se le agrego una sola actividad y ahora cuando cargo alguna intancia guardada antes del cambio me aparece el error; no se como resolver el problema, si pudieses ser mas explicito te lo agradeceria. Saludos

  16. Muchas gracias Juan Carlos.

    Releyendo tu post y los enlaces que pusiste en respuesta, me han sido de gran utilidad.

    Muchas gracias nuevamente.

    Un saludo.

  17. Quisiera saber si la persistencia de SQL solamente funciona en instancias 2005. Las he probado en 2005 y me funcionan correctamente, en 2000 tengo un mensaje de: El administrador de transacción asociada ha deshabilitado su soporte para transacciones de red o remotas. (Excepción de HRESULT: 0x8004D025)

  18. Buenas Jotaka,
    La persistencia de SQL te debería funcionar también en SQL Server 2000. De hecho, la excepción que te está dando se debe a la configuración del servidor y no al servicio de persistencia.

    Un saludo

    JC’s

  19. Daniel Mata,
    A lo que me refería es que si has cambiado la lógica de tu workflow y tenías instancias antiguas, es lógico que con la nueva versión no funcionen puesto que has cambiado el emsamblado del workflow. De hecho, y volviendo al ejemplo de SharePoint, cuando se vuelve a redesplegar un workflow porque ha habido cambios en el mismo, se eliminan las instancias anteriores.

    Espero aclararte con esto mi comentario previo

    Un saludo

    JC’s

  20. Que tal JC; yo me estoy enfrentando a lo mismo que nuestro compañero Daniel; la verdad es que recien tomo este proyecto y desconozco la parte que mencionas de desplegar de nuevo el workflow; tengo instancias obviamente ya persistidas y en codigo se agrego una nueva propiedad; que pasos tengo que hacer para revivir mis instancias anteriores ya que esa instancia la tengo relacionada con toda la informacion que arroja mi aplicacion; y no se como reestablecerlas; muchas gracias de antemano.

  21. Hola Juan Carlos,
    Te agradezco la buena disposicion de explicar estos temas con tanta paciencia.
    Tengo la siguiente consulta:
    ¿Puedo crear una aplicación que permita al usuario final administrar y crear el mismo sus flujos de trabajo de acuerdo a su logica de negocio?, hasta donde he visto el designer parece estar orientado al programador.
    Saludos y gracias
    Jorge Ojeda

  22. Hola a todos excelente publicacion..

    Me gustaria si alguien me puede ayudar a resolver una dudas que tengo con WF debido que debo usarlo con visual studio 2005 y me gustaria saber muchas cositas.. porfis

    se lo agradeceria.. mucho mucho si alguien me postea un correo para hablar con el

    Saludos a todos

Deja un comentario

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