Jim @ imason : technical, silverlight

Rehydrating a State Machine Workflow

James Schwartz — Fri, 06 Mar 2009 21:30:00 GMT

At first glance, Windows Workflow does a good job of persisting workflows to the database for long-running State Machine Workflows.

However, what happens when you update your workflow assembly? Windows Workflow will try to retrieve the workflow from the SQL Persistence store and de-serialize the object, but it will throw an exception (You’ll see a SerializationException or IndexOutOfRangeException).

There are different ways to handle this situation. The first (and most obvious way) is to set versions on your DLLs so that the workflow will de-serialize into a previous version of a workflow and continue running in the older version. But what if the change you made to the workflow fixes an important bug in the previous version? In this case, you may want your previously persisted workflows to use the new version of the code.

A few quick Google searches will lead you to a few different options in handling this situation:

Using an assembly resolver or using the “AppliesTo” attribute [1]
Dynamic Workflows [2]
Breaking up into smaller workflows [3]

None of these options are particularly appealing to me, so I had to find a better way to handle updates to the workflow code but still allow my long-running workflows to operate.

My “outside the box” solution: Workflow Rehydration

To achieve Workflow Rehydration, I’m keeping track of the current state in a SQL database and if the current workflow can’t be de-serialized (because the workflow has been updated), I instantiate a new workflow and I set the state to the state it was previously in.

The obvious concern that comes up using this approach is “how do I avoid executing the code inside my StateInitializationActivity?”

To get around this issue, I’m passing in a boolean parameter into my State Machine workflow that indicates whether or not the workflow is being rehydrated. I then use an IfElseActivity to execute my State Initialization code only if the workflow is not being rehydrated.

The end result is that the workflow goes back into its previous state, but it’s now running inside the new updated workflow code. You might call this a “Utopia State” (Apologies for the lame pun).

The end user has no idea that the workflow has gone through this transformation from an old version of the workflow code to the new version; and it only took a little bit of code along with some IF conditions.

References:

[1] http://msdn.microsoft.com/en-us/library/aa349375(VS.85).aspx

[2] http://community.bartdesmet.net/blogs/bart/archive/2006/08/28/4322.aspx

[3] http://www.sitechno.com/Blog/WorkflowVersioningOfLongRunningProcessesSucksHereIsMyTakeOnIt.aspx

NAnt, SharePoint and Production Deployments

James Schwartz — Tue, 03 Feb 2009 21:58:38 GMT

On my current SharePoint/InfoPath project, we’re using NAnt to deploy absolutely everything. NAnt creates SharePoint pages, imports web parts to pages, activates SharePoint features, deploys assemblies, creates SharePoint lists, creates/updates SQL databases (via DBDeploy), packages and deploys InfoPath forms, copies XSLT/XML/ASPX files, and much much more.

I always boast about how when a new developer comes on the project, he/she can have a fully operational SharePoint development environment within minutes. This is an important achievement, as most SharePoint Developers know it can be painful to automate deployments to SharePoint sites.

This works great for a Development environment, but what happens when you need to deploy to Production? Some companies don’t allow NAnt to be executed directly in Production, so you’ll need to setup your NAnt build files to execute on a build server to prepare for a Production deployment.

To achieve this, I went back into my NAnt build file and updated my NAnt targets to allow for the “preparation” of a deployment rather than actually performing the deployment. This provides us the ability to run NAnt on a build server in order to package everything for an easy automated deployment in Production (without NAnt).

I’m leveraging Windows Installer XML (WiX) in order to package the deployment files into MSI packages (In a future post I’ll get into more detail about using WiX MSI’s for SharePoint deployments). For SharePoint feature installation/activations and InfoPath form deployments I’m generating a batch file from NAnt that gets packaged into the MSI and executed when the MSI is installed on the server.

First we prepare the batch files – this will create 3 new empty batch files with a line “ECHO OFF” inside them:

        1: <target name="PrepareBatchFiles"> 

       2:     <echo file ="${featuresDeployment.cmd}" append="true" message="ECHO OFF" /> 

       3:     <echo file ="${formsDeployment.cmd}" append="true" message="ECHO OFF" /> 

       4:     <echo file ="${dataConnectionsDeployment.cmd}" append="true" message="ECHO OFF" /> 

       5: </target>

Next, we append STSADM calls to the batch files – anytime we call STSADM from NAnt, we will add a row into the batch file. Here’s an example when we’re calling the “UploadForm” NAnt target:

       1: <target name="UploadFormTemplate" description="Uploads an InfoPath Form">

       2:     <choose>

       3:         <when test="${prepareDeployment=='true'}">

       4:             <echo file="${formDeploymentBatchFile}" append="true" message="echo Attempting to upload form template '${formName}.xsn'" />

       5:             <echo file="${formDeploymentBatchFile}" append="true" message="${stsadm.exe} -o uploadformtemplate -filename &quot;${deploymentFolder}\Forms\${formName}.xsn&quot;" />

       6:         </when>

       7:         <otherwise>

       8:             <exec program="${stsadm.exe}">

       9:                 <arg line="-o uploadformtemplate" />

      10:                 <arg line="-filename &quot;${publishedFormsFolder}${formName}.xsn&quot;" />

      11:             </exec>

      12:         </otherwise>

      13:     </choose>

      14: </target>

You can see from the NAnt target above that it checks whether we’re “Preparing” a deployment or if we’re actually deploying. If we’re preparing the deployment, it will generate batch files and copy files to a deployment folder. I’ve added the “choose –> while” condition into each NAnt target so that I can prepare my deployment files for the MSI.

The generated batch file will look something like this:

       1: SET STSADM=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\STSADM.exe

       2: ECHO OFF

       3: "%STSADM%" -o deactivateformtemplate -url http://sharepoint-serv -filename "C:\MyForms\MyInfoPathForm.xsn"

       4: "%STSADM%" -o removeformtemplate -filename "C:\MyForms\MyInfoPathForm.xsn"

       5: "%STSADM%" -o execadmsvcjobs

       6: ECHO Attempting to upload form template 'MyInfoPathForm.xsn'

       7: "%STSADM%" -o uploadformtemplate -filename "C:\MyForms\MyInfoPathForm.xsn"

       8: "%STSADM%" -o execadmsvcjobs

       9: "%STSADM%" -o activateformtemplate -url http://sharepoint-serv -filename "C:\MyForms\MyInfoPathForm.xsn"

Now when I add a new form to be deployed, it will be automatically added to the batch file for the Production deployment. The end result is that I can run my NAnt scripts on a development environment to actually deploy my SharePoint components, or I can run the same batch scripts on a Production server via an MSI package.

Advanced InfoPath Development with SharePoint

James Schwartz — Sun, 25 Jan 2009 15:13:00 GMT

Thanks to everyone who made it out to our Advanced InfoPath Development session yesterday at the Toronto SharePoint Camp. We had quite a good turnout; so I’m glad to see there are lots of other people out there using browser-based InfoPath forms using Forms Services on SharePoint.

InfoPath makes it easy to quickly develop forms, but it doesn’t come without its limitations. It’s very heavy on JavaScript, thus performance isn’t great when you have a lot of fields and rules. It doesn’t support multilingual, and it’s not very good at field validation. In this session we showed the audience how to get around these limitations by writing some simple C# code.

I’ve posted the PowerPoint slides as well as the source code for the InfoPath form, the Web Service, the Web Part, and the NAnt XML build definition.

If you’re interested in learning more about NAnt, send me an e-mail because I’m thinking about organizing a NAnt lunch and learn session at the imason office open to all Developers. We’re located in downtown Toronto on Adelaide Street near Peter St.

Download the source code (SharePointCamp.zip), and PowerPoint slides (SharePointCamp-2009.pptx) here.

Repeating a State Machine Activity Indefinitely

James Schwartz — Mon, 15 Dec 2008 19:30:00 GMT

While working on my .NET State Machine workflow today, I ran into an issue: I wanted to send an e-mail to a user every XX days to remind them to finish filling out a form, and I wanted those e-mails to continue being sent until the form had been filled out.

At first I thought this would be a simple While Activity with a Delay Activity timer inside it, but a Delay Activity has some limitations: I originally added it to my StateInitialization Activity, but it can’t be used inside a StateInitialization Activity because it inherits the IEventActivity interface. This also means that you can only use a Delay Activity as the first Activity in an EventDriven Activity, which prevents you from putting a Delay Activity inside a While loop.

So I took a quick look at other people running into the same issue and found this user group discussion, but I didn’t see any viable solution for repeating the Delay Activity indefinitely.

So to solve this, I added a new EventDriven Activity to my State Activity and set the Delay Activity as the first Activity in the EventDriven Activity.

Then I added an IfElse Activity to check if the form had been filled out or not. If the form is filled out, I change the state to “CompleteState”. But if the form hasn’t been filled out, I set it back to the current state which will re-trigger the EventDriven Activity, thus re-starting the Delay timer.

It will continue this loop until the form is filled out, sending an e-mail every time it executes. This is exactly the functionality I was looking for, but the approach to accomplish this was slightly different than I had expected.

Knowledge Transfer Techniques for Developers

James Schwartz — Tue, 02 Dec 2008 23:01:00 GMT

In my 6+ years in the software development business, I’ve used a variety of techniques for performing developer knowledge transfers. When I hold a knowledge transfer session, I like to set my own objectives (What am I hoping to get out of the session?), familiarize myself with the objectives of my audience (What is my audience looking to achieve?), know the audience’s skill level (If I move quickly, will they be able to follow?), and I like to be familiar with the logistics (Have I booked a training room? Do I have sufficient hardware? Software is installed? Do I have Admin privileges?)

When your audience is large, the technique is much different than when the audience is small. It’s more difficult to completely engage a larger audience, so the key is to do hands-on training to ensure your audience is following along. I’ve done sessions that weren’t hands-on, but they were far less effective than the hands-on sessions, and are usually a result of time/logistics constraints than anything else.

To date, my most effective developer knowledge transfer session involved choosing 2 or 3 small feature enhancements (Or bugs), and using a “Pair Programming” approach to develop these features. This obviously works best in a pair (i.e. training 1 other person), but I think it can also be effective for training up to 3 developers. Using a meeting room on a projector, each developer would take turns writing some code. This keeps them engaged and when they aren’t writing code they stay focused because they need to know what is happening for when it’s their turn to write the code.

I feel that this is the absolute best way for new developers to learn about the code, and it’s the most rewarding way for the developer(s) who wrote the code to showcase his/her code. In addition to the learning benefits, you are also using your time efficiently by actually addressing a new feature or existing bugs. If you’re on tight deadlines, this approach allows you to keep the project moving forward while transferring knowledge at the same time. The last benefit of this approach is you can incorporate a code review into the session by getting an objective viewpoint from the developers you are transferring the knowledge to (Assuming the recipients are experienced enough to have constructive suggestions).

In summary, the benefits of hands-on knowledge transfer are as follows:

· Productivity in that the project keeps moving forward (Tight project deadlines are a reality in our industry)

· Hands-on learning for the recipients (Make sure to use proper source control in case something goes wrong J)

· Simultaneous code-review (Find all those divide by zeros)

· Better focus from the participants (Nobody falls asleep)