domingo, 11 de março de 2012 09:39
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.
- Editado Felpudo domingo, 11 de março de 2012 20:25
Todas as Respostas
terça-feira, 13 de março de 2012 05:47Moderador
For the information about workflow instance in database, you can refer to:
Persistence Database Schema
If you want to get the information about workflow execution, please refer to:
Workflow Tracking and Tracing
->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.
Hope this information helps, thanks.
terça-feira, 13 de março de 2012 20:06
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.
domingo, 16 de setembro de 2012 13:55
Please have a look at this example using state machine. Enabling command buttons on the UI according to current state and the available transitions.
Hope it helps