TheWorkflowElement

Web Deploy Talk

Thanks to the good sized group of people who attended Wednesday's combined Architecture SIG and Connected Systems SIG meeting on Web Deploy. You had some great questions!

Here is my slide-deck from the talk:



Download Web Deploy.pptx

VS 2010 Release Candidate & Update MSDN Docs Now Available!

The new bits are available to MSDN subscribers. What's more, there have been a lot of great updates to the WF documentation!

Cathy Dumas posted an excellent entry on the updates here:
http://blogs.msdn.com/cathyk/archive/2010/02/09/rc-is-here-and-so-is-the-workflow-designer-documentation.aspx

DevConnections Article: Routing in AppFabric

In this article I show how you can take advantage of the WCF Router in combination with AppFabric's hosting functionality to quickly enable routing for your workflow services scenario.

Routing in AppFabric

DevConnections Article: Reliable Workflow Services

In this article I show how you can designer workflow services in .NET 4 that are fault tolerant, and how hosting in AppFabric helps you with this goal.

Reliable Workflow Services

DevConnections Article: Windows Application Server Extensions

In this article, I broadly introduce what is now known as Windows Server AppFabric. This article was based on an earlier build of AppFabric, but if you're looking for a good overview of what AppFabric is, this article makes a great starting point. Stay tuned for an updated article on this! Check out my article on DevConnection's website:

Windows Application Server Extensions

Talk: Deploying Websites, Applications & Services with Web Deploy

Come see me speak at this month's (updated: the meeting is February 10th) San Diego .NET Architecture SIG meeting and learn how Web Deploy can help you automate your deployment to your dev boxes, test servers and of course production.We will cover how to acquire, install and configure Web Deploy and then delve into how to use it to create/configure packages, import packages, export packages and publish packages using Visual Studio's One-Click Publishing. Time permitting we will dive into useful other useful areas, such as deploying sites that depend on the Entity Framework, creating config transforms to automatically re-generate config files based on the deployment target (e.g., test versus production) at compile time, and creating parameters whose values can be specified during import.

Full event details here.

DevConnections: Monitoring & Troubleshooting .NET 4 Services

 In this article I explore the use of the MicrosoftVisual Studio Debugger, Event Tracing for Windows (ETW), and Windows Application Server Extensions (code-named "Dublin", now known as Windows Server AppFabric)  to help you troubleshoot both imperative .NET 4 Windows Communication Foundation (WCF) services and declarative workflow services from development through production deployment.

Read my entire article on DevConnections Magazine's Website:

http://www.devproconnections.com/article/aspnetpro/monitoring-and-troubleshooting-net-4-service.aspx

ASP.NET Pro Article: Workflow Services

Interested in Workflow Services? Checkout my article in the September issue of ASP.NET Pro. Stay tuned for an announcement and more articles in the queue covering "Dublin" and Workflow Services...

Introducing .NET 4 Workflow Services

Geeking out on GeekSpeak: Workflow Services & .NET 4

This Wednesday I will be doing a GeekSpeak around Workflow Services and .NET 4. It's free, fun and cutting edge!

When:
Wednesday, October 07, 2009 12:00 PM Pacific Time (US & Canada)

 

Where:
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032427071&Culture=en-US

Configuring a Reasonable Tracking Profile

In the previous post, we took a survey of all the Tracking Record types that the workflow runtime emits and made a recommendation that balances the volume of data logged with capturing key information. Namely, I suggested tracking the following combination:

WorkflowInstanceRecord - to track the big events in the lifetime of a workflow particularly Start, Idle and Completed.
ActivityTrackingRecord - activities with a state of closed have completed.
ActivityScheduledRecord - to track what activities the workflow was about to execute.
FaultPropagationRecord - looking for those with IsFaultSource set to true to find the source activity of the exception (and the exception itself).
WorkflowInstanceUnhandledExceptionRecord - to capture the particular exception that bubbled all the way up, possibly causing the workflow instance to abort.

In this posting we introduce Tracking Profiles and show how we configure one to get us the above "Just Right" set of logged events.

Profiles Introduced

Tracking Profiles are effectively detailed configuration of what records a given Tracking Participant (an object registered with the workflow runtime that is responsible for logging the records somewhere- there can be many of these loaded at once) may log.  Think of a Tracking Profile as a filter that the Tracking Participant applies to all incoming records. If the record matches the conditions specified in the profile, the record is logged. Otherwise, the record is ignored. A TrackingProfile is usually defined declaratively in the web.config for a Workflow Service. There is also an object model for building TrackingProfile instances in code and registering them programatically, but that will not be covered here.

Within a single config file, a Tracking Profile can be associated with one or more Tracking Participants and multiple Tracking Profiles can be defined which enables the following use case:
Applying different Tracking Profiles to different Tracking Participants.
Keeping debug and production profiles readily available for easy switching between them.

From a high level,  a config file registers a Tracking Participant and attaches a Tracking Profile:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <system.serviceModel>

  <services>
         <service name="Service1" behaviorConfiguration="MyServiceBehavior"/>
      </services>

      <behaviors>
         <serviceBehaviors>
           <behavior name="MyServiceBehavior">

              <trackingComponents>
                 <add name="EtwTrackingParticipant" />
              </trackingComponents>

           </behavior>
         </serviceBehaviors>
      </behaviors>

  <tracking>
     
         <participants>

               <add name="EtwTrackingParticipant"
                type="System.Activities.Tracking.EtwTrackingParticipant, System.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
                profileName="JustRightDebugProfile"
                />

                <!-- Additional Tracking Participants -->

         </participants>

         <profiles>

           <trackingProfile name="JustRightDebugProfile">
                 <workflow>
                      <!-- Tracking queries for profile are defined here -->
                 </workflow>
            </trackingProfile>
  

            <!-- Additional Tracking Profiles-->

         </profiles>

  </tracking>

 </system.serviceModel>
</configuration>

The above defines the EtwTrackingParticipant (which will emit ETW traces, viewable in Event Log) and configures it with the tracking profile JustRightDebugProfile via the profileName attribute. The Workflow Service is told to use the ETW Participant by virtue of adding tracking components to its service behavior configuration. With our service now configured to use a tracking participant and that participant configured with a tracking profile, we can dive into configuring the JustRightDebugProfile. 

Configuring a Tracking Profile

We will build this profile up until we have configured the five tracking queries in the list above. Let's begin by configuring the profile to collect all WorkflowInstanceRecords. To this between, we the <workflow></workflow> tags we need to add the following:

              <workflowInstanceQuery>
                     <states>
                       <state name="*"/>
                     </states>
                  </workflowInstanceQuery>

You may recall from the previous post that the WorkflowInstanceRecord has a State property- this corresponds to the state of the workflow instance (Start, Idle, Completed, etc). We want to capture records generated for all of these states, so we specificy and asterisk for the state name.

Next, we want to capture records everytime a an activity completes. We do this by using an activtiy tracking query that records records with activities entering the Closed state:

                  <activityQueries>
                     <activityQuery activityName="*">
                       <states>
                          <state name="Closed"/>
                       </states>
                    </activityQuery>
                  </activityQueries>

Notice that the activity query also enables us to be very specific about which particular activitie's state changes we capture, because it allows us to specify the activity name. You may be wondering what value to use here, since activities don't have a Name property- it's the value of the DisplayName property. This time, because we want to capture activity records when the activity completes, we look for the Closed state name.

On top knowing which activities have completed (by virtue of the previous query), it's very useful to know what activities could execute next in the workflow. The queueing up of these activities is performed by the workflow runtime's scheduler, and this is tracked by activity scheduled records, which we query for as shown:

       <activityScheduledQueries>
           <activityScheduledQuery activityName="*" childActivityName="*"/>
        </activityScheduledQueries>

Activity scheduled records are unique in that they identify two activities: the parent activity who is scheduling a child activity. The record is emitted, therefore, when the child activity is being scheduled.

Next we want to track the site where an exception occurs, we do that with a faultPropagationQuery. This will also provide for us a "stack trace" as the exception bubbles up the activity graph. This is configured as shown:

                  <faultPropagationQueries>
                     <faultPropagationQuery activityName="*" extractFaultData="true" faultHandlerActivityName="*"/>
                  </faultPropagationQueries>

The key attribute to configure here is extractFaultData which will capture the exception as a payload of this record. Unfortunately, there is no way to configure a filter for IsFaultSource so as to only capture the initial exception- so you must look for IsFaultSource = true in the emitted records to find the exception throwing activity.

Finally, sometimes an exception might bubble all the way through the activity graph unhandled. To find out which exception killed your workflow, it's enough to track Workflow Instance Unhandled Exception records, using a query like:

            <workflowInstanceUnhandledExceptionQuery includeException="true"/>

You want to ensure to set includeException to true so that you can the details of the exception that went unhandled.

With that we have all of the queries we need for the JustRightDebugProfile, which you can see in its completed form here.

Extracting Variable Values

Beyond the general queries shown above, there is one other useful query you can enable that help your troubleshooting. The tracking infrastructure supports extracting the value of a variable at the time when a tracking record matches the condition of a tracking query. For example, you can extract the value of the currDocument variable when the Submit Invoice  activity completes with:

   <activityQueries>
                <activityQuery activityName="Submit Invoice">
                  <variableQueries>
                     <variableQuery name="currDocument_afterSubmitInvoice" variable="currDocument" isRequired="false"/>
                  </variableQueries>
                  <states>
                     <state name="Closed"/>
                  </states>
                  </activityQuery>
    </activityQueries>

A couple of things to note, first you should give the variable query a descriptive name. In ETW traces, the name is what is shown, not the value specified for variable. Second, you can have multiple queries- for example you may have on activityQuery that extracts the variable and another more general query that just captures all activity closed records. Only one of the set will be logged, and while there are sophisticated precendence rules in effect here: The query that identifies a specific activity by name and has a matching state will be chosen over one that does not. Finally, variable extraction is not just limited to activity queries- it can also be applied in a similar fashion to ActivityInitialized, ActivityScheduled, CancelRequested and FaultPropagation queries.