Windows Workflow Foundation

Faulting Handling for Dynamic Workflows - Part 1.

ChrisD — Fri, 01 Feb 2008 08:36:02 GMT

"There is no joy in Mudville - the mighty Casey has struck out."

I've been spending some time lately reviewing and bolstering my old WF Execution code. Part of this refactoring included a revamped approach at Exception handling. With so many different kinds of activities, implementing a "standard" fault handler is proving more challenging than I had originally thought. Managing exceptions in base workflow activities is one thing, but handling exceptions in custom business activities is quite another.

Unfortunately, I haven't found a way to activity bind dynamically added properties in windows workflow. As a result, I've developed a custom activity generator that I can point to an exe or dll and have it selectively generate custom activities from exposed public methods . The generated activities support dynamic, strongly typed parameters for the method's input, output and return values. There are also a handful of helpful "converter" activities that will convert objects from one type to another, storing the results in strongly typed generated fields. This approach has a nice side benefit of being able to generate unit tests and ensure coverage of my business activities without relying on workflow execution-- but I digress. The generated activities have no intrinsic error handling of their own, but rather bubble up the thrown exceptions up the activity hierarchy to the workflow.

Left unhandled, an exception in a custom activity will fault the workflow, terminating workflow execution and tear down and unload the workflow from the runtime. Sometimes terminating workflow execution is the proper response, but not usually. All my workflows are dynamic. They are all XAML activated workflows with a root activity that points to my compiled base workflow. My goal was to implement a root level fault handling routine in my base workflow (a compiled workflow), that would act as a "safety net" for all the dynamic workflows that it hosts.

I implemented a basic fault handler via the workflow designer and ran my first unit test. The workflow failed validation. In fact, every workflow was now failing validation. Digging into the error stack I discovered the cause:

"Can not add activity in a CompositeActivity which has built in children."

So there's evidently a design decision that was made that states "if the composite activity has children, it cannot be modified at runtime." The composite activity its referring to is the base workflow itself. The children activities is actually the fault handler activity (it gets added like another activity to the workflow's children collection). This means I cannot support any activities (even fault handlers) in my base workflow.

For now, I've removed the fault handling code (at least my workflows pass validation and execute again).

My next idea is to change the root activity in my xaml workflows from the concrete class to a dynamic class, or possibly write something to set the internal CanModifyActivities flag during workflow load...

Got a thought? I'd love to hear from you.

Persisting Workflows using the NetDataContract Serializer

ChrisD — Sat, 26 Jan 2008 19:54:33 GMT

I'm currently working on a WCF/WF project where we've replaced .NET's DataContractSerializer default with the NetDataContractSerializer. The following is from the MSDN help file:

The NetDataContractSerializer differs from the DataContractSerializer in one important way: the NetDataContractSerializer includes CLR type information in the serialized XML, whereas the DataContractSerializer does not. Therefore, the NetDataContractSerializer can be used only if both the serializing and deserializing ends share the same CLR types.

Given the addition of the CLR information in serialized XML, we needed a custom Serialization Surrogate to use for Workflow Persistence. My first attempt used a BinaryReader to read and write the serialization data

public class ContractSurrogateSelector : SurrogateSelector
{
    public override ISerializationSurrogate GetSurrogate(Type type, StreamingContext context, out ISurrogateSelector selector)
    {
        //check to see if type has NetDataContractAttribute
        if (type.IsDefined(typeof(NetDataContractAttribute), false))
        {
            selector = this;
            return new NetDataContractSerializationSurrogate();
        }
        return base.GetSurrogate(type, context, out selector);
    }
}
public class NetDataContractSerializationSurrogate : ISerializationSurrogate
{
    [Serializable]
    public class DataContractRef<T> : IObjectReference
    {
        #region IObjectReference Members
        
        public object GetRealObject(StreamingContext context)
        {

            XmlDictionaryReader r = XmlDictionaryReader.CreateBinaryReader(objectData, XmlDictionaryReaderQuotas.Max);
            object ret = null;
            Message m = Message.CreateMessage(r, 2048, MessageVersion.Soap11WSAddressing10);
            ret = m.GetBody<T>();
            return ret;
        }
        byte[] objectData;
        #endregion
    }
    #region ISerializationSurrogate Members

    public void GetObjectData(object obj, SerializationInfo info, StreamingContext context)
    {

     
        Message msg = Message.CreateMessage(MessageVersion.Soap11WSAddressing10, "whocares", obj, new NetDataContractSerializer(obj.GetType()));
        MemoryStream ms = new MemoryStream();
        XmlDictionaryWriter writer = XmlDictionaryWriter.CreateBinaryWriter(ms);
        msg.WriteMessage(writer);
        writer.Flush();
        ms.Flush();
        ms.Seek(0, SeekOrigin.Begin);
       
        info.AddValue("objectData", ms.GetBuffer());
        Type t = typeof(DataContractRef<>).MakeGenericType(obj.GetType());
        info.SetType(t);
    }

    public object SetObjectData(object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector)
    {
        return null;


    }

    #endregion
    
}

The Data looked to serialize fine,and was getting persisted into my SQL Server database tables via the SqlServerPersistenceService that ships with WF. However, when I attempt to resumed a persisted workflow, Deserialization failed with an XMLException stating "the input source is not correctly formatted". The exception was being raised when the Reader began parsing the xml stream of serialized data. Not what I would have expected considering I'm using a binary serializer for both reading and writing the data. Clearly something was getting lost in translation.

After much struggling, I finally discovered that the problem was around the message encoding. I was trying to use BinaryMessageEncodingBindingElement. I switched to use the MtomMessageEncodingBindingElement and it worked like a champ. The MTOM format correctly encodes the CLR type information needed by the NetDataContractSerializer. My serialization surrogate code ended up looking like this:

[Serializable]
public class NetDataContractRef<T> : IObjectReference
{
    #region IObjectReference Members
    
    public object GetRealObject(StreamingContext context)
    {
      
            
            object ret = null;
            XmlDictionaryReader r = XmlDictionaryReader.CreateMtomReader(objectData, 0, objectData.Length, Encoding.UTF8, XmlDictionaryReaderQuotas.Max);
            XmlObjectSerializer serializer = GetSerializer(typeof (T));
            Message m = Message.CreateMessage(r, 1024 , MessageVersion.Soap11WSAddressing10); 
            ret = m.GetBody<T>(serializer);                    
            return ret;
        
    }

    private byte[] objectData = null;
    #endregion
}

#region ISerializationSurrogate Members

public void GetObjectData(object obj, SerializationInfo info, StreamingContext context)
{

    try
    {
        MemoryStream ms = new MemoryStream();
        XmlObjectSerializer serializer = GetSerializer(obj.GetType());
        Message msg = Message.CreateMessage(MessageVersion.Soap11WSAddressing10, "whocares", obj, serializer);
        XmlDictionaryWriter writer = XmlDictionaryWriter.CreateMtomWriter(ms, Encoding.UTF8, Int32.MaxValue, "text/xml");
        msg.WriteMessage(writer);
        writer.Flush();
        ms.Flush();
        ms.Seek(0, SeekOrigin.Begin);

        info.AddValue("objectData", ms.GetBuffer());
        Type t = typeof (NetDataContractRef<>).MakeGenericType(obj.GetType());
        info.SetType(t);
    }
    catch (Exception ex)
    {
        Trace.WriteLine("Workflow Persistence Serialization Exception: - " + ex.ToString());
    }
}

public object SetObjectData(object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector)
{
    return null;


}

#endregion


public static XmlObjectSerializer GetSerializer(Type type)
{
    return new NetDataContractSerializer();
}

If anyone else has had a similar experience, please post a comment, I'd love to talk more about the how's and why's.

.NET 3.5 Certification Exam Beta is Still Available

ChrisD — Fri, 25 Jan 2008 18:57:32 GMT

Microsoft has extended the deadline for the .NET 3.5 technologies certification exam betas. There are certification tests available for WCF, WPF and Windows Workflow. You can take the exams for free, if you pass they will count towards your overall MS certification. Interested? Read more about it here

HowTo: Set up your project for Window's Workflow (C# style)

ChrisD — Sat, 19 Jan 2008 16:31:08 GMT

Any C# project can contain Workflow definitions. They're just code file and/or XAML files. The trick is getting Visual Studio to recognize the project as supporting worfklows for design-time support and compilation.

To enable a project for Windows Workflow,:

Open the project in visual studio.
If you're using source control check out the project file so it becomes writable
In the Solution Explorer, right click and select Unload Project . The project tree will disappear from the solution explorer and is replaced with a single node of the project name followed by the phrase (Unloaded).
Right click on the unloaded project node in the Solution Explorer again, and select Edit Project. This will open the project file in Visual Studio. The project file is just an XML file, so we can edit it manually.
Find the entry named <ProjectTypeGuids> and make sure it includes these id's

<ProjectTypeGuids>{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

This tells visual studio its a C# project and a workflow project. Both are necessary to get design time support in your visual studio project. If you forget to include these project guid's you'll like end with an error like this when you try to edit a workflow file

The service 'System.Workflow.ComponentModel.Design.IIdentifierCreationService' must be installed for this operation to succeed. Ensure that this service is available.

Finally we have to tell Visual Studio to include the workflow compilation build targets for MSBuild when the project compiles. Add the following entry to your project's xml file inside the <Project> node

<Import Project="$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.0\Workflow.Targets" />

Save and close the project xml file.
Right click on the project node in the Solution Explorer again and select Reload Project

Your project is now Workflow-capable. You should be able to edit and compile Windows Workflow files.

Hide Custom Activity Properties from the WF Designer & Property Grid

ChrisD — Wed, 12 Dec 2007 15:54:53 GMT

Sometimes too many options is a bad thing. After all just because I create a property in my custom activity doesn't mean I want it displayed on the design surface.

To Microsoft's credit, most of the design behavior of workflow is customizable and often pluggable, making it possible and practical to extend the user experience. Microsoft provides a Browseable attribute which can be placed on properties that according to the help file :

specifies whether a property or event should be displayed in a Properties window.

Placing this attribute on your public property works. sometimes. To be clear, the attribute seems to work but its not always picked up by the compiler.

The other problem with the declarative approach is it forces me to set the visibility of the property once and only once. This assumes that the browsable value I specify is the value I want all the time.

Consider the case of a sub classed activity. Maybe in the base class I want to expose the property, but hide it in a sub class. This isn't a supported scenario using the declarative Browseable attribute (even if it did work).

My preferred way to hide unwanted properties is to hook into the PreFilterProperties method in the activity designer.

  protected override void PreFilterProperties(IDictionary properties)
        {
            base.PreFilterProperties(properties);
            string[] propertiesToHide = { "Order", "ErrorMessage" };
            ActivityDesignerHelper.HidePropertiesInDesigner(propertiesToHide, properties, this.GetType());
        }

here's the code of my MidePropertiesInDesigner which I liberated from another developer (I'm sorry I dont recall the original source of this code). I've modified it slightly to override any existing browseable attributes

public static IDictionary HidePropertiesInDesigner(string[] propertiesToHide,IDictionary properties, Type designerType )
        {
            foreach (string propname in propertiesToHide)
            {
                PropertyDescriptor prop = (PropertyDescriptor)properties[propname];
                if (prop != null)
                {
                    AttributeCollection runtimeAttributes = prop.Attributes;
                    bool hasBrowsable = false;
                    for (int i = 0; i < runtimeAttributes.Count; i++ )
                    {
                        BrowsableAttribute browseAttr = runtimeAttributes[i] as BrowsableAttribute;
                        if (browseAttr != null)
                        {
                            hasBrowsable = true;
                            break;
                        }
                    }
                    // make a copy of the original attributes
                    // but make room for one extra attribute
                    Attribute[] attrs = new Attribute[runtimeAttributes.Count + (hasBrowsable?0:1)];
                    //runtimeAttributes.CopyTo(attrs, 0);
                    // now selectively copy the attributes to a new array
                    int attrCnt = 0;
                    for (int i = 0; i < runtimeAttributes.Count; i++)
                    {
                        Attribute attr = runtimeAttributes[i];
                        // if this attribute is the browseable attribute, skip it
                        if (attr is BrowsableAttribute)
                            continue;
                        attrs[attrCnt] = attr;
                        attrCnt++;
                    }

                    // add in a new browseable(false) attribute
                    attrs[runtimeAttributes.Count] = new BrowsableAttribute(false);
                    prop = TypeDescriptor.CreateProperty(designerType, propname, prop.PropertyType, attrs);
                    properties[propname] = prop;
                }
            }
            return properties;

}

The code iterates through the property's existing attributes, ignoring the browsable attribute (if it exists) and then copies them to a new attribute array, inserts the browseable attribute value specified and assigns it back to the property.

This code works 100% of the time for me, and allows me to decide on a case-by-case basis which properties to hide and which ones to show in the design surface.

Breakpoints in XAML Activated Workflows

ChrisD — Wed, 12 Dec 2007 15:18:20 GMT

XAML only workflows (those are xoml files without a code attribute and code beside file), do not support debugger breakpoints. Right clicking on the activity in the workflow and selecting insert breakpoint does (as far as I can tell) nothing.

Since XAML only workflows have no associated code and therefore no IL, it makes sense that you can't set a breakpoint, after all what exactly are you attaching the breakpoint to?

XAML only workflows are all about process orchestration and flow control, we really want to debug into the code inside of the custom activities used in the workflow.

With the out-of-the-box breakpoint functionality not available, how can we set breakpoints in our workflows? My answer to this problem is a custom activity; DebuggerBreakpointActivity

The activity is straightforward and comes down to a single conditional statement:

    [ToolboxBitmap(typeof(DebuggerBreakpointActivity), “DebuggerBreakpointActivity.DebuggerBreakpointActivityLogo.png")]
    [ActivityValidator(typeof (DebuggerBreakpointActivityValidator))]
    [Designer(typeof (DebuggerBreakpointActivityDesigner), typeof (IDesigner))]
    public class DebuggerBreakpointActivity : Activity
    {

protected override ActivityExecutionStatus Execute(ActivityExecutionContext ctx)
{

            try
            {
                if (System.Diagnostics.Debugger.IsAttached)
                    System.Diagnostics.Debugger.Break();

            }
            catch
            {
            }

            // mark this activity as closed.
            return ActivityExecutionStatus.Closed;
        }

When executing, the activity checks to see if the debugger is attached, if so, it programmatically inserts a breakpoint. From here I can step through all my custom activity code and can monitor my workflow execution paths.

When not running in debug mode, the debugger is not present and the activity completes with no action taken.

A side note: when I drag this activity onto my design surface, I set the activity name to something useful. this way I can monitor my execution flow by simply checking the name value of the activity (which appears automatically in the locals window).