locked
Workflow Tracking namespace pollution

    General discussion

  •  

    There are far too many different types involved in setting up a TrackingProfile.

     

    Why is there a different TrackingPoint class for Workflow, Activity, and User.  There's a different class for each of their Locations, these hold the same general type of information, some aspect of Workflow

     

    Just think, instead of this

     

    <?xml version="1.0" encoding="utf-16" standalone="yes"?>
    <TrackingProfile xmlns="http://schemas.microsoft.com/winfx/2006/workflow/trackingprofile" version="1.0">
        <TrackPoints>
            <WorkflowTrackPoint>
                <MatchingLocation>
                    <WorkflowTrackingLocation>
                        <TrackingWorkflowEvents>
                            <TrackingWorkflowEvent>Created</TrackingWorkflowEvent>
                            <TrackingWorkflowEvent>Completed</TrackingWorkflowEvent>
                        </TrackingWorkflowEvents>
                    </WorkflowTrackingLocation>
                </MatchingLocation>
            </WorkflowTrackPoint>
        </TrackPoints>
    </TrackingProfile>

     

    We could have had this:

     

    <?xml version="1.0" encoding="utf-16" standalone="yes"?>
    <TrackingProfile xmlns="http://schemas.microsoft.com/winfx/2006/workflow/trackingprofile" version="1.0">
        <TrackPoints type="Workflow">
                <MatchingLocation type = "WorkflowTracking">
                        <Events>
                            <Event>Created</Event>
                            <Event>Completed</Event>
                        </Events>
                </MatchingLocation>
        </TrackPoints>
    </TrackingProfile>

     

    Now,

    TrackPoints can be used for Workflow, Activity, and User

    MatchingLocation can be used for Workflow, Activity, and User.

     

    As it is now, the User and Activity TrackPoints have almost identical functionality, but no commn classes.

    With a bit more effort I could flatten the entire muddle that is Tracking, and end up with about 1/3 of the classes. and maintain the same functionality.  The My code wouldn't be so hard to read, and debug

    Thursday, October 09, 2008 2:26 PM

All replies

  •  

    "Why is there a different TrackingPoint class for Workflow, Activity, and User.  There's a different class for each of their Locations, these hold the same general type of information, some aspect of Workflow"

     

    The reason that there are different trackingpoint classes, is that it allows for 3 very different kinds of tracking to be used. From the MSDN page

     

    Workflow events include Created, Completed, Idle, Suspended, Resumed, Persisted, Unloaded, Loaded, Exception, Terminated, Aborted, Changed, and Started. Activity events describe the life cycle of an individual activity instance. Activity-execution status events include Executing, Closed, Compensating, Faulting, and Canceling. When creating the business logic for an activity, the activity author might want to track some business- or workflow-specific data. This can be achieved by calling any of the overloaded Activity.TrackData methods. The data tracked in this manner is sent to the tracking service as a User Tracking Event.

     

    By allowing the user to differentiate between these types in tracking, some users will choose to track only user tracing while others might choose to use all three but log each kind to a sepearte file, etc. Yes, you could flatten that down, and the framework could have as well, but you wouldnt have the same functionality because you would lose some of the control over how they are differentiated.

     

     

    Info From:

    http://msdn.microsoft.com/en-us/library/bb264458(VS.80).aspx
    Thursday, October 09, 2008 7:30 PM
  •  

    Yes, you could flatten that down, and the framework could have as well, but you wouldnt have the same functionality because you would lose some of the control over how they are differentiated.

     

    Sorry, I don't see how one implies the other.  My point is that there is no need to have such a vast number of differing types, and that atributes on a flattened type heirarchy would provide the same functoinality without polluting the namespace with so many different types which do essentially the same as other types

     

    example - WorkflowTrackPoint and ActivityTrackPoint are essentially the same thing.  They allow you to register a tracking point.  Why not just use a single class, and differentiate them by an attribute as in

     

    TrackPoint tp = new TrackPoint( TrackPointType.Workflow )  //   (or TrackPointType.Activity)

     

    That's clearly too simple, instead we have twe seperate types

    WorkflowTrackPoint, and ActivityTrackPoint

     

    Similarly we have to deal with WorkflowTrackingLocation vs ActivityTrackingLocation

     

    TrackingLocation tl = new TrackingLocation(TrackingLocationType.Workflow);  // or Activity

     

     

    Having seperate types is bad enough, but the naming scheme for the types is chaotic. We add TrackingWorkflowEvent to a WorkflowTrackingLocation, but we add ActivityExecutionStatus to an ActivityTrackingLocation. 

     

    Notice that the naming scheme for the two things being added tothe TrackingLocation is completely different, and thus confusing.

     

    Don't get me started on why sometimes it's 'Track' and sometimes 'Tracking'  - that's just too much for one day !

    Friday, October 10, 2008 10:12 AM