Thursday, July 27, 2006
WinWF - assigning tasks from a state machine
After sporadic dalliances with WinWF (or is it just WF?) I think I've solved one problem.
Often workflow activities need to assign a task to a person, rather than a system. My example is a credit control process that needs a human to call the customer and chase a debt.
At the client end of the application, we need to be able to see the workflows (and the tasks) that users need to complete. When the task is complete, the task needs to be closed.
The workflow runtime itsself is not much use in this context - there is no concept of assignment and not much in the way of a query function to locate tasks of certain types, either persisted or in memory.
My initial approach (with a state machine workflow) was to add StateInitialization and StateFinalization activities to a state that needed action by a human. In these I could set up and then close down a task in my database application. Although this concept worked it did mean I had to be careful to always have both in each state, and it meant setting up each 'user' state manually when encountered.
Instead I realised that a better way was to create a subclass of StateActivity, and add my task setup and closedown into the State directly. Then whenever I needed to create a task for a user, I dragged my StateWithTask onto the designer. I had to create some properties (DSN, AssignTo, TaskDescription, TaskOutcome) that could be bound to workflow values.
The next challenge is for the client app to be able to 'see' what events can be fired and build the list of possible actions from the design rather than hard-code into the application so it automatically
Often workflow activities need to assign a task to a person, rather than a system. My example is a credit control process that needs a human to call the customer and chase a debt.
At the client end of the application, we need to be able to see the workflows (and the tasks) that users need to complete. When the task is complete, the task needs to be closed.
The workflow runtime itsself is not much use in this context - there is no concept of assignment and not much in the way of a query function to locate tasks of certain types, either persisted or in memory.
My initial approach (with a state machine workflow) was to add StateInitialization and StateFinalization activities to a state that needed action by a human. In these I could set up and then close down a task in my database application. Although this concept worked it did mean I had to be careful to always have both in each state, and it meant setting up each 'user' state manually when encountered.
Instead I realised that a better way was to create a subclass of StateActivity, and add my task setup and closedown into the State directly. Then whenever I needed to create a task for a user, I dragged my StateWithTask onto the designer. I had to create some properties (DSN, AssignTo, TaskDescription, TaskOutcome) that could be bound to workflow values.
The next challenge is for the client app to be able to 'see' what events can be fired and build the list of possible actions from the design rather than hard-code into the application so it automatically
