Dr Adrian Colquhoun

Hi

If we query our tracking database (assuming we are using SqlTracking) by workflow type

e.g.

SqlTrackingQuery query = new SqlTrackingQuery(_connectionString);

SqlTrackingQueryOptions queryOptions = new SqlTrackingQueryOptions();

queryOptions.WorkflowType = "My base workflow type here";

query.GetWorkflows(queryOptions);

Will this query only explicitly match my base workflow type or can I make it find and retrieve any derived types as well

Thanks

Adrian




Re: Windows Workflow Foundation Workflow tracking and derived types

Dr Adrian Colquhoun

To expand upon my own question, it appears that the workflowType option will only match the explicit type of workflow that actually executed.

I have a scenario where I have created a base workflow to model a generic apporvals process and I have then extended this to a set of sub workflows that model different types of approval.

In my base workflow I track some generic data about the approval required. However, this is tracked in the Sql database against the subtype (though the code that emits it is in the base type).

I would like to query the tracking database for every workflow that "is an" approval, regardless of its actual type so that I can create some generic tracking and monitoring tools. I want this code to work without having to know the actual type of workflow that is executing other than it "is an" approval workflow, allowing new approval workflows to be added in the future with no changes to the tracking or monitoring code.

Does anyone have any comments or suggestions as to how to go about this. I was trying to avoid writing a custom tracking service as this is extra code to maintain but at the moment I am thinking that this is the only viable option

Thanks

Adrian






Re: Windows Workflow Foundation Workflow tracking and derived types

jdw - MSFT

The SqlTrackingService does not shred clr type information. The string data that you see in the Type table is all that is represented. As such there is unfortunately no way to directly query for workflow type using base type data.

However you should be able to work around this. Expose a property on your base workflow that contains the string form of it's type information. Use a tracking profile to extract this property. Because it is a string it will be stored in string form (as opposed to binary serialized) in the TrackingDataItem.Data_Str field. You can then query for all workflows that contain a TrackingDataItem row that contains a Data_Str value that matches the string form of the base type that you are interested in.

Thanks,
Joel West
MSFTE - SDE

This posting is provided "AS IS" with no warranties, and confers no rights





Re: Windows Workflow Foundation Workflow tracking and derived types

Dr Adrian Colquhoun

Joel

I did consider and try to implement the workaround that you mention (unless I misunderstand you). Unfortunately I dont think it works. It is possible to emit userdata from the base workflow type but it is not possible to query this data through the the DataItemValue object becuase it requires three items - qualified activity name, field name and field value. The qualified name is again qualified by the subtype and not the base workflow type so thesame problem applies.

However, the data could be queried directly from the database and then used to create SQLTrackingInstances manually by Id though I'm not sure how efficient this would be

If you think I'm on the wrong track vcould you post a code sample

Cheers

Adrian






Re: Windows Workflow Foundation Workflow tracking and derived types

jdw - MSFT

Sorry, I didn't realize that using the SqlTrackingQuery was a requirement, I was thinking of a direct query. So you are on the right track in terms of how to get the data that you need stored in a form that can answer your questions (query by base type) but you are also correct that you won't be able to query via the SqlTrackingQuery api.

In terms of efficiency SqlTrackingQuery.GetWorkflows retrieves a list of workflows and uses data from that single query to populate the initial set of data for each SqlTrackingWorkflowInstance (all collection properties are lazy loaded on first access). You would need to perform your query for a list of workflow ids and then ask the SqlTrackingQuery to load each SqlTrackingWorkflowInstance individually. So there will be some extra overhead but there's probably some way to offset this cost if you really want the lazy load and auto polling functionality in SqlTrackingWorkflowInstance. For example if you query returns a large amount of workflow ids you might, depending on your scenario, lazy load the SqlTrackingWorkflowInstances themselves (load and display the first 5 or 10 and then page).

Thanks,
Joel West
MSFTE - SDE

This posting is provided "AS IS" with no warranties, and confers no rights





Re: Windows Workflow Foundation Workflow tracking and derived types

Dr Adrian Colquhoun

Brilliant - thanks for the response.

SqlTrackingWorkflowInstance isnt a requirement per se - was just trying to save myself some work! I will query the tracking database via the views for now and return my own custom object with the metadata that I need and the workflow instance id embedded. Most od the time the users will just browse lists of this metadata - they can echo the id back to the server later of they need a SqlTrackingWorkflowInstance

Adrian