Thursday, November 25, 2010

Managing Change in Long Running Workflows Part 1

 

I’ve been using Workflow Foundation now for over a year and it has become an integral part of our architecture and has by and large been very successful. However it is not without it’s issues, the single most being that official documentation is light at best and relevant blog posts are quite rare.  

I recently ran into a fairly serious problem after deploying a new release of our Software.

The Problem

I received this lovely email from our exception tracker:

System.Runtime.DurableInstancing.InstancePersistenceCommandException: The execution of the InstancePersistenceCommand named {urn:schemas-microsoft-com:System.Activities.Persistence/command}LoadWorkflow was interrupted by an error. ---> System.Runtime.Serialization.SerializationException: Deserialized object with reference id '73' not found in stream.

The key part is “Deserialized object with reference id '73' not found in stream.” As I’m sure you can tell this does not really provide any helpful information.

The stack trace does give you some more information as to which property failed, but depending on the object graph the stack trace can be fairly massive.

This is the part which gives you the biggest clue:

at ReadArrayOfPersonFromXml(XmlReaderDelegator , XmlObjectSerializerReadContext , XmlDictionaryString[] , XmlDictionaryString[] )

The Cause

Basically what has happened here is that when trying to load an unloaded workflow instance from the SqlWorkflowInstanceStore the deserializer spits the dummy because a property on the object that existed at the time the Workflow was persisted no longer exists on the class. 

Once you understand the cause it does seem reasonable, sort of. In my effort to clean up the solution and get rid of unused properties I had effectively broken every workflow instance which was persisted before the date of the latest release.

As it turns out it’s possible to create this issue by either removing properties or renaming existing properties.

I made the fatal mistake of using passing my Domain Entities into the workflow as an argument.

The Patch

In order to fix this issue I ended up scrambling through the check-in history over the last 6 weeks trying to figure which properties had been removed. Once I figured it out, I added them back and deployed a patch. This solved the problem and the crisis was averted for the short-term.

The Solution

When a workflow is unloaded and persisted to the data store it is serialized and all internal variables & arguments are serialized along with it.

Rules for data objects in workflows:

  • Never ever under any circumstances use Domain Entities
  • Always use DTO’s for Arguments or Variables in Long Running Workflows
  • Set IsRequired=false on the DataMember attribute for all Nullable Properties
  • Set the Name property on the DataMember attribute
  • Set the Order Property on the DataMember attribute
  • Set the Name on the DataContract attribute

 

This is an example of a class that could create problems in the future.

    [DataContract]
    public class Category
    {
        [DataMember]
        public int Id { get; set; }

        [DataMember]
        public List<Product> Products { get; set; }
    }

Based on the above lessons here is how I would suggest coding this class for use in a Workflow.

   [DataContract(Name="Category")]
   public class Category
   {
       [DataMember(IsRequired = false, Name = "Id", Order=0)]
       public int Id { get; set; }

       [DataMember(IsRequired = false, Name = "Products")]
       public List<Product> Products { get; set; }
   }

By setting the Name property on the DataMember you are then free to change the property name without fear of breaking the deserialization.

Setting IsRequired to False allows you to remove the property in the future without breaking deserialization, obviously you should set this for True for any properties that are truly required by the Workflow to function correctly.

Conclusion

This is just an example of how to deal with data that changes in workflows, in my next post I’m going to cover how you deal with workflows whose logic changes after an instance has been created and persisted.

I hope this helps anyone who’s working with Workflow Foundation or about to start using it.

Till next time.

Wednesday, November 24, 2010

MediaInfo deprecated attributes in Version 0.7.37

 

I’ve just discovered that the latest version (0.7.37) of MediaInfo has some deprecated attributes and I’ve compiled the full list of deprecated attributes split by the Track type.

General

Menu_Codec_List
Format/String
Codec
Codec/String
Codec/Info
Codec/Url
Codec/Extensions
Codec_Settings
Codec_Settings_Automatic

Video

Codec
Codec/String
Codec/Family
Codec/Info
Codec/Url
Codec/CC
Codec_Profile
Codec_Description
Codec_Settings
Codec_Settings_PacketBitStream
Codec_Settings_BVOP
Codec_Settings_QPel
Codec_Settings_GMC
Codec_Settings_GMC/String
Codec_Settings_Matrix
Codec_Settings_Matrix_Data
Codec_Settings_CABAC
Codec_Settings_RefFrames
Resolution
Resolution/String
Colorimetry
Interlacement
Interlacement/String

Audio

Codec
Codec/String
Codec/Family
Codec/Info
Codec/Url
Codec/CC
Codec_Description
Codec_Profile
Codec_Settings
Codec_Settings_Automatic
Codec_Settings_Floor
Codec_Settings_Firm
Codec_Settings_Endianness
Codec_Settings_Sign
Codec_Settings_Law
Codec_Settings_ITU
Resolution
Resolution/String
Video0_Delay
Video0_Delay/String
Video0_Delay/String1
Video0_Delay/String2
Video0_Delay/String3
Video0_Delay/String4

 

Image

Codec
Codec/String
Codec/Family
Codec/Info
Codec/Url
Resolution
Resolution/String

Menu

Codec
Codec/String
Codec/Info
Codec/Url

Text

Codec
Codec/String
Codec/Info
Codec/Url
Codec/CC
Resolution
Resolution/String
Video0_Delay
Video0_Delay/String
Video0_Delay/String1
Video0_Delay/String2
Video0_Delay/String3
Video0_Delay/String4

Chapters

Codec
Codec/String
Codec/Info
Codec/Url

 

If you want the full list of all available attributes, then download the DLL version from the MediaInfo download page and go to the Developers/List_Of_Parameters folder.

Tuesday, November 23, 2010

Consuming the SSRS ReportExecutionService from a .NET Client

 

I’ve just finished writing a nice wrapper which internally calls the SSRS ReportExecutionService to generate reports.
Whilst it was fairly simple to implement there has been some major changes between 2005 and 2008 and the majority of online and documentation is based on the 2005 implementation.

The most important change is that the Report Server and Report Manager are no longer hosted in IIS which will be a welcomed change to Sys Admins but makes the security model and hosting model vastly different. So far I’ve yet to figure out how to allow Anonymous Access, if anyone knows how to do this leave a comment and it will be most appreciated.

Getting Started

To get started you’ll want to add a service reference to http://localhost/ReportServer_SQL2008/ReportExecution2005.asmx where ReportServer_SQL2008 is the name you configure in the Reporting Services Configuration Manager.

The Web Application files are located in C:\Program Files\Microsoft SQL Server\MSRS10.SQL2008\Reporting Services, you’ll want to to create a dedicated User and grant it permissions to these application folders.

Once you’ve done that you’ll need to browse to the Report Manager logging in as an Administrator account and then add a Role for your new user under the Security page http://localhost/Reports_SQL2008/Pages/Settings.aspx?SelectedSubTabId=SecurityLinkID and also under the Properties tab in Home http://localhost/Reports_SQL2008/Pages/Folder.aspx?SelectedTabId=PropertiesTab.

Calling the API

This post is mainly about solving some of the problems you may face, for detailed information on calling the API check out MSDN which has a wealth of information on the topic, here is the Overview and more specifically how to Render a Report.

However note that you may have to pass a TrustedUserHeader type whenever calling a Web Service method, it’s ok for this value to be Null.

WCF Security

Once you’ve followed the guide and coded your solution appropriately you may come across this exception or one similar when trying to call a Web Service method.

The authentication header received from the server was 'Negotiate,NTLM'.

The key here is to set the Network Credential property before to a Windows user who has access to the Reports and has the correct Role Assignments in the Report Manager.

var rsClient = new ReportExecutionServiceSoapClient(); 

            rsClient.ClientCredentials.Windows
                .ClientCredential = new NetworkCredential("username", "password");
            rsClient.ClientCredentials.Windows
                .AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
            

Also make sure that in the Web.Config in C:\Program Files\Microsoft SQL Server\MSRS10.SQL2008\Reporting\Services\ReportServer has the following values set.

   <authentication mode="Windows" /> 
   <identity impersonate="true" />

These are the bindings I use and work well. Make sure to set all the properties to the Maximum allowed values as Report Server returns some fairly large arrays.

<system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="ReportExecutionServiceSoap" closeTimeout="00:01:00"
            openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
            allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
            maxBufferSize="65536" maxBufferPoolSize="65536" maxReceivedMessageSize="65536"
            messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
            useDefaultWebProxy="true">
          <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647"
              maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
          <security mode="TransportCredentialOnly">
            <transport clientCredentialType="Ntlm" proxyCredentialType="None" realm="" />
            <message clientCredentialType="UserName" algorithmSuite="Default" />
          </security>
        </binding>
      </basicHttpBinding>
    </bindings>
    <client>
      <endpoint address="http://localhost/ReportServer_SQL2008/ReportExecution2005.asmx"
          binding="basicHttpBinding" bindingConfiguration="ReportExecutionServiceSoap"
          contract="Services.Impl.ReportExecution2005.ReportExecutionServiceSoap"
          name="ReportExecutionServiceSoap" />
    </client>
  </system.serviceModel>

 

Conclusion

I’m all about using the right tool for the job so for Reporting when you’re using SQL Server 2008 as your data store you really can’t go past SSRS which even comes free with SQL Server Express Edition.

Also included in SSRS 2008 is the Report Builder which is a Report Designer tool accessible from the Report Manager allowing users to design reports without having to install the Business Intelligence Studio.

Hope this helps someone.