R – State Machine Persistence WorkFlow

workflowworkflow-foundation

Hey all, I have created a WinForms to handle Persistence Activities using the Windows WorkFlow Foundation. I'm using the .NET 3.0 SQL and VS2005 as the IDE with C# as the code language. Also, the environment is mandated to me by the corporate policy for development. So until the dinosaurs decide to upgrade, I'm stuck with VS2005.

My probelm is this, I'm able to work with 1 workflow at a time, and I'd like to be able to handle Multiple workflows. As in when I click the Submit button on my form, I'd like to be able to create a new WorkFlow instance.

I created the runtime and add all the appropriate services. I hook in persistence, and when I click the Submit I start an instance of the WorkFlow. I'm relatively new to the WorkFlow Foundation, and the MSDN links have provided little to no help for me. If anyone could put me in the right direciton within my source code, that would be helpful.

I have attached a link to the source for my project.

Click Here for the Source

Thanks in Advance!

Best Answer

I had a look and it appears that you are creating a new workflow each time you click submit. I get a new instance id, which is a good sign :) PopulatePSUP(string instanceID) captures the instance id for the dropdown. But you are only storing one instance id at a time in Guid _instanceID. This form level variable is then used for all the button events. You could insead use the cboPSUPItems.Text.

Something like:

    private void btnPSUPApprove_Click(object sender, EventArgs e)
    {
        string instanceId = this.cboPSUPItems.Text;

        if ( instanceId.Length > 0 )
        {
            myArgs.Approved = true;
            approved = "Yes";
            this.resumeHistory[ instanceId ].Clear( );
            this.resumeHistory[ instanceId ].Add( "Name: " + applicantName );
            this.resumeHistory[ instanceId ].Add( "Email:" + applicantEmail );
            this.resumeHistory[ instanceId ].Add( "Text:" + applicantText );
            this.resumeHistory[ instanceId ].Add( "Approved:" + approved );
            this.resumeHistory[ instanceId ].Add( "Denied:" + denied );
            this.resumeHistory[ instanceId ].Add( "PD Approval Requested:" + pDRequest );
            resumeService.RaisePSUPApprovedEvent( new Guid(instanceId) , myArgs );
            this.cboPSUPItems.Items.Remove( this.cboPSUPItems.SelectedItem );
            txtPSUPNotes.Clear( );
        }
    }

You might want to think about using a collection/list to store the instanceIds in as well. For any workflow wide logic.

Something like:

List<Guid> _instanceIds = new List<Guid>( );

...

_instanceIds.Add( instance.InstanceId );

Related Solutions

R – Windows Workflow: Persistence and Polling

I'm not sure what you mean by "handled soley through persistence services"? Persistence refers only to the storing of an idle workflow.

You could have a Delay and a Code activity in a Sequence in a While loop. When in the Delay the workflow will go idle and may be persisted if necessary. However depending on how much state is needed when persisting the workflow and/or how many such workflows you would have running at any one time may mean that a leaner approach is necessary.

A leaner approach would be to externalise the DB watching and have some "DB watching" workflow service raise an event when the desired change has occured. This service would be added to Workflow runtime.

To that end you need a service contract which is defined by an Inteface with the [ExternalDataExchange] attribute. This interface in turn defines an event that the service will raise when the desired DB change is detected. It also defines a method that a Workflow can call to specify what what change this service should be looking for. The method should accept an instance GUID so that the requesting instance can be found when the DB change is detected.

In the workflow you use a CallExternalMethodActivity to call this services method. You then flow to a HandleExternalEventActivity which listen for the event. At this point the workflow will go idle and can be persisted. It will remain there until the service raises the event.

Open alternatives to Windows Workflow

I invite you to examine Stateless further, as suggested in the answer to my SO question can-anyone-recommend-a-net-open-source-alternative-to-windows-workflow. to achieve the goal of a long running state machine is very simple in that you can store the current state of your state in a database and re-sync the state machine when needed. Consider the following code from the stateless site:

Stateless has been designed with encapsulation within an ORM-ed domain model in mind. Some ORMs place requirements upon where mapped data may be stored. To this end, the StateMachine constructor can accept function arguments that will be used to read and write the state values:

var stateMachine = new StateMachine<State, Trigger>(
    () => myState.Value,
    s => myState.Value = s);

With very little effort you can persist your state, then retrieve that state easily later on.

In respect updating the workflow dynamically, if you configure a state machine such as

var stateMachine = new StateMachine<string, int>();

and maintain a separate file of states and triggers in XML, you can perform a configuration at runtime by looping through the string int value pairs.

Best Answer

Related Solutions

R – Windows Workflow: Persistence and Polling

Open alternatives to Windows Workflow

Related Topic