Getting workflow’s state in order to control UI’s behavior (WF4)

Question

Hello everybody,

I have a scenario where the same screen in the presentation tier must offer different behaviors depending on where a workflow currently is, and where it’s coming from. All activities in the workflow are called as service operations through client code auto-generated by the Add Service Reference functionality in the presentation project. The workflow’s state is being persisted after every completed service call. How can the user interface “know” where the workflow currently is (i.e. what activity was last to execute), and how did it get there, in order to determine what behavior to adopt?

Maybe some “workflow state logic” structure could be added to the database, then have such information constantly updated from the workflow’s activities (a “the last activity executed by this workflow was ‘DoThisThing’ ” sort of data), then retrieve and use such information whenever the UI needs it to determine what kind of behavior to expose. However, I feel there must be a better approach: It just doesn’t look right trying to keep a “duplicate” track of the workflow’s each and every move, since it was already handled and persisted by the WF4 engine.

I am very inexperienced with WF4, so please be understanding if I have overlooked some very obvious stuff by asking this.

Thanks.

Answer 1

Hi,

For the information about workflow instance in database, you can refer to:

Persistence Database Schema

http://msdn.microsoft.com/en-us/library/ee943755.aspx

If you want to get the information about workflow execution, please refer to:

Workflow Tracking and Tracing

http://msdn.microsoft.com/en-us/library/ee513992.aspx

->Maybe some “workflow state logic” structure could be added to the database, then have such information constantly updated from the workflow’s activities (a “the last activity executed by this workflow was ‘DoThisThing’ ” sort of data), then retrieve and use such information whenever the UI needs it to determine what kind of behavior to expose.

You might consider promote custom, application-specific properties that can be used to query for instances in the persistence database.

Store Extensibility

http://msdn.microsoft.com/en-us/library/ee364726.aspx

Hope this information helps, thanks.

---

Leo Tang [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 2

Hello Leo,

Thank you for the links. I had already digged slightly into the tracking/tracing and persistence database schema subjects, not finding a straightforward way of accomplishing what is needed. However, promoting app-specific properties is an interesting topic and this could be what I’m looking for.

Now, the Store Extensibility document shows adding the PersistenceParticipant extension to the host in code. However, our front-end project calls activities within workflows as published services. Thus we do not control instantiation of WorkflowApplication objects. Plus, most our activities are declarative, living in xmalx files. Is there a way to promote properties in a declarative manner, having the workflow itself save these values whenever its state is persisted?

On another line of thought, our workflow services are hosted in IIS + AppFabric. Is AppFabric’s implementation of “supervised variables” related to property promotion? Could it be used as well?

Thanks in advance for any additional ideas you may kindly wish to share.

 

Answer 3

Please have a look at this example using state machine. Enabling command buttons on the UI according to current state and the available transitions. 

http://code.msdn.microsoft.com/windowsdesktop/Windows-Workflow-fee72008 

http://wf.codeplex.com/wikipage?title=Tracking%20states%20with%20WorkflowApplication

Hope it helps