WF Framework Programming-monitoring section: monitoring

1 Structural Analysis

Reference: MSDN http://msdn2.microsoft.com/zh-cn/magazine/cc163466.aspx

WF Monitoring Reference below: WF allows multiple tracking services (that is, you can add multiple trckingservice in wrokflowruntime), allowing multiple tracking service to be added to the runtime to support different business requirements, the tracking service is responsible for specific implementation, But there is only one trace listener: The trace listener receives notification of all events, and in most cases only one subset of these events is useful, and if multiple tracking services are used, the tasks are likely to focus on only one subset of information, Trace listeners will query each configured tracking service to track the configuration files for various types of workflows

Image source: MSDN

A configuration file is actually a trackingprofile, essentially a set of tracking points, information about when to extract data and what data to extract. We can graphically configure Trackingprofile to speed up the development and deployment of trace profiles

If there is a graphical configuration to modify the Trackingprofile requirements: You can refer to the http://netfx3.com/content/WFHome.aspx inside the Trackingprofiledesigner example.

2 Design Idea Analysis 2.1 static structure

Each workflow instance in the workflow engine is run as a thread, for thread-safety considerations

The workflow engine only has dependencies with Trackingservice, and Trackingservice's job is to get trackingprofile and Trackingchannel,trackingpfofile define what states will be monitored, The default tacking Pofile records all states of the [instance's various states], the various states of the activity, and the user tracking behavior. And Trackingchannel defines how the captured information is saved. Note here: Trackingprofile is not an abstract class, it is just a container, there is no method.

2.2 Trackingprofile Structure Analysis:

It is noted that the default tacking Pofile records all states of the [instance's various states], the various states of the activity, and the user tracking behavior. The default tacking Pofile is valid for all workflows that do not have custom tacking pofile. If the workflow only needs to monitor certain state changes and can be filtered using a custom tacking pofile, we could directly modify the default tacking Pofile. Refer to the class diagram below: Trackingprofile is composed of Trackingpointcollection, Matchinglocations and excludedlocations in TrackingPoint Collections allow you to closely control the time that data is collected, matchinglocations the collection to indicate that you want to track these events, or add this information to the Excludedlocations collection to indicate that the data should not be collected.

How to join UserData?

To achieve a graphical tracking only tracking state changes is not enough, for practical use, tracking often have to track some other information, such as: The task is who (role) initiated, assigned to WHO (role), specifically by WHO, processing time and so on. So you can add custom UserData.

If you want to add user-defined data to call the Trackdata method implementation in a custom acitivity, refer to the activity definition, or you can invoke the ActivityExecutionContext method implementation.

protected void Trackdata (object userData);

protected void Trackdata (String Userdatakey, Object userData);

Calling Trackdata will trigger a custom trace event

2.3 Use of tracking by default

Default mode of use (SQL Server storage tracking information)

Condition: SqlTrackingService Join Run time

Workflowruntime.addservice (New SqlTrackingService (connectionString));

1.sqltrackingquery.trygetworkflow Get Sqltrackingworkflowinstance

2. Get the collection of three kinds of Trackingrecord

ilist<workflowtrackingrecord> = sqltrackingworkflowinstance.workflowevents

ilist<activitytrackingrecord> = sqltrackingworkflowinstance.activityevents

ilist<usertrackingrecord> = sqltrackingworkflowinstance.userevents