I have a workflow that has a bunch of properties on it. One of those properties is the name of the user that initiated the workflow (it is passed into the workflow via the Dictionary<string, object> class.
I have SQL persistence working just fine (well, I can't figure out how to 'auto persist', so I am manually calling 'Unload' when the workflow idles), and I run through the list of workflow IDs persisted when my application starts up. What I want to do is access the properties on that workflow (they're public) once I have the instance ID. I just can't seem to find a way to access those properties.
Anyone
SQL Persistence, Loading Workflows and Workflow Properties
Kaushik j
I am using the SQL Tracking Service as well as SQL Persistence Service. Is there any way to configure the SQL Tracking Service to track the values that I need, or am I actually going to have to hand-write my own custom tracking service every time I need to maintain a single code-beside property between instantiations If I can't use SQL Tracking Service to do this out of the box, then I'm thinking there's an oversight in the design of this feature, as I think this functionality should be standard and not something people should have to write custom classes for.
Cardiff Ed
Ok, I found out how to gain access to my state machine workflow (using the StateMachineWorkflowInstance class helper). The problem is that all of the public properties that I have on my workflow don't appear to be reconstituting from the database.
They are simple properties like:
public string Blah { get { return blah; } set { blah = value;} }
Is there something I need to do in order to make sure that this information gets serialized along with the rest of my workflow
ericcwhung
I think that your need to implement your own database system to support the workflow.
To each GUID you assign some values to show in lists and something like that.
What I did not realise yet is how can I show some workflow to someone without put this information in the support database, just giving the information to the workflow.
I think that, this is the way you could resolve your problem.
regards
Paulo Aboim Pinto
Odivelas - Portugal
mkamka
The data exchange service is one approach that should work fine, depending on your specific scenario.
Another way you could do it is by adding a custom service from your host (workflowRuntime.AddService(myService)). This service will be available to your workflow in the OnActivityExecutionContextUnload/Load methods, and other signal methods as well. You can get/set values from/onto this service in these methods. The host can then listen for the WorkflowLoaded event on the workflow instances and retrieve the corresponding value(s) from the service.
-Angel
zhoang
Hi Angel,
Not to hijack this thread or anything, but I've seen the "Write your own Tracking Service" response being given for a few questions already, and I've been wondering about this a little bit. It is pretty cool that most of the runtime services that are included out of the box in WF can be replaced as needed, but isn't this kind of thing pretty common
What I mean is that writing a complete tracking service is certainly a lot of work (besides the fact that you need to test it pretty throughly) just to get some data out of the workflow engine. It really sounds like an overkill solution that, at least to me, suggest something really is missing at the core level that would make live inspection of a workflow state more accessible...
David_H
Paul Czywczynski
How would you use the EDX service in this scenario Obviously we'd need to do something event-related since the EDX is specifically designed to not maintain state (EDXs are scoped at the runtime, therefore there's one per runtime and one per multiple workflows, so it can't maintain workflow-specific state).
I would just need something that would let me extract a couple bits of key property data from the workflow so that the workflow host has some 'pretty' data to display in a listview instead of just the workflow's Guid.
Also note: I tried to override the event handler you mentioned. I'm using a StateMachine workflow, and it has no such method 'OnActivityExecution....' to override.
Andrew XYZ
Kevin,
Through persistence, your property will be serialized for you on Unload and restored on Load. If you need to "verify" this, you can do so from within the workflow itself by overriding the OnActivityExecutionContextUnload/Load methods and logging it out there.
However, the host cannot see these instance values. As I mentioned in my previous post, the StateMachineWorkflow property does not return the live instance, it returns the workflow definition - the template used to create each instance. This definition will NEVER have actual instance data, as it is not executing. What is actually executing is a "clone" of this which you do not have direct access to from the host.
The host cannot directly modify the live instance of the workflow (e.g. set property values on it). If you need to verify/modify instance data of a running worklfow, then you either need to do it from within the workflow itself, or your need some form of communication from the host to the workflow (e.g. external data exchange service).
-Angel
gbabu17
Kevin,
From the host, you do not have access to the actual workflow instance. The StateMachineWorkflowInstance class helper gives you information about the workflow and allows you to perform instance operations on it (e.g. Suspend, Unload, etc.), but the actual "live" activity graph is abstracted from you.
The StateMachineWorkflow property on StateMachineWorkflowInstance returns you the workflow definition, not the live instance. This is why you don't see any of the expected values during execution, it's not that they are being lost in persistence.
If you need to transfer data from the workflow to the host or vice versa, you should look into an ExternalDataExchangeService or some other custom service.
Thanks,
Angel
darth24_01
hi,
Anybody tried XMl persistance I dont want to save my workflow in SQL. I read somewhere that workflow supports XML persistance also. Anybody have any sample for this
Thanks in Advance
Jobs
ireland
You're right in your assumptions about the external data exchange, in that it would either need eventing or state to do the job. Ideally it should not contain state, but if managed correctly it could (although it can be troublesome).
As for the methods OnActivityExecutionContextLoad/Unload, these can be found in the Beta2.2 release, not Beta2.
Now that I see what you're trying to do (UI population and workflow monitoring), it sounds like Tracking would fit your needs well. We have several examples of how to write a Tracking service and this would very effectively help you extract data from your workflow synchronously. In your case, your tracking profile would be set to extract the properties you desire and make them available on the host side.
-Angel
Findekano
My question had nothing to do with exchanging data between the workflow instance and the host.
My problem is this: Through the course of the workflow , several properties on the workflow class itself (the code-beside partial class) such as several date stamps and a couple strings are set. I want the persistence medium to take those properties and store them during the unload. When the workflow is restored, I need those properties to be loaded from the persistence medium as well.
Example:
In the code-beside for my workflow, I have a property:
public string PartyName { get { return pn; } set { pn = value; } }
The PartyName is a parameter supplied when the workflow is started. After the workflow is persisted and then re-loaded from the persistence medium, I need to guarantee that this value has been restored from the persistence medium.
And, as an aside, I can access the actual workflow instance, its a property on the StateMachineWorkflowInstance instance. From there I can typecast the WorkflowInstance to the data type of my actual workflow and then access instance-level data.
So, what I really need is a way to get the persistence medium to read and write the properties of my workflow instance.
labfox
Writing a tracking service is relatively straight forward. There is some text about it on Moustafa's blog and there is a tracking service in the SDK samples under Technologies\Tracking\FileTrackingServiceAndQuerySample. The tracking service in this is just 202 lines of C#.
The out of the box services (including tracking) were never intended to cover all scenarios. They were originally intended as examples and we focussed on providing the means for developers to replace them easily. They are of course supported and we have been attempting to round them out a bit as we have got closer to release so they should fit many of your scenarios now.
Regards,
Paul
rob444
Paul,
Just how reliable is the 202 lines tracking service How production ready is it Mind you, 202 lines of code is actually a little bit (that is, 202 lines) longer than I really want to write (and test) for what should be out of the box functionality. It is pretty basic after all.
Examples Wow, that's the first I heard of that. Honestly, this does not inspire much confidence on them, and, seriously, it really signals to me that you're really not thinking about them adressing the core needs, then, and just the "basic" scenarios (which are never a problem, btw). Also, since they are supposed to be samples, then, will you be providing the source code and documentation for each of those services with the SDK Otherwise, not much point of them being examples, if developers can't look at the code to learn about them (yes, I know reflector, but you can't ship an example without code, it defeats the purpose).
I know I'm probably being a little melodramatic here about it, but, really, I honestly believe the services provided should provide a clear support for the interesting scenarios, and not just the very basic ones. Furthermore, it really seems to me that the way the existing services are written, they are meant to be replaced in whole, instead of merely extended, which pretty much forces you to (as a wf developer) to do much more work to replace an entire service instead of just being able to hook into it to provide extensions. At this point, I feel I don't know enough to say how much this might cause problems later on in cases where you bring multiple workflows and activities from multiple providers/parties, but it does seem to me that it could become a bit troublesome to support if you end up with the need to support conflicting replacement services.