Handling ShortTerm CheckOut Locks in your Records Center Workflow

Posted Thursday, January 29, 2009 2:39 PM by CoreyRoth

The other day, I posted about how to write a simple workflow to copy files to the records center whenever they were created or modified.  Well the workflow I provided worked in all of the following cases.

  • Add new item
  • Upload Item
  • Upload new version to existing item
  • manual check out then check back in (with no changes to the doc.)
  • Edit document properties (When checkout required is set on the library)

Of course there was one place that I found that it doesn't work.  It is when you use the New Document button or edit an existing document directly with Office 2007.  The reason for this is that when you have a document open with Office, it creates a Short Term Check Out for the period of an hour.  It also continues to reestablish the lock until you close the Office application (i.e.: Microsoft Word).  Records Center will not accept any document that is currently checked out.  This presented an interesting challenge on how to deal with this.  The first thing I tried was adding code to check in the file (i.e.: SPFile.CheckIn).  This method does not work when the CheckOutType is ShortTerm.

I tried an ItemEventReceiver to see if closing Office would trigger the ItemCheckedIn event, but it in fact does not.  This means I can't handle this scenario that way either.  So what I came up with was a hack, but it does in fact get the job done (provided the user eventually closes the Office application).  Here is what it looks like.


I did say hack, didn't I?  That's exactly what it is.  The While activity contains the following code condition.  All it does it execute the contents of the while activity as long as the CheckOutStatus is set to ShortTerm (meaning the user still has Microsoft Word open).

private void IsShortTermCheckedOut(object sender, ConditionalEventArgs e)


    e.Result = (workflowProperties.Item.File.CheckOutStatus == SPFile.SPCheckOutStatus.ShortTerm);


As you can see there is a Delay activity in there.  These actually seem to work now, but you do need to be sure that you have the latest version of the .NET Framework installed as well as all updates applied to SharePoint.  Otherwise there is a good chance that your workflow will never wake back up.  I have the delay set to 15 minutes.  This is because the workflow timer job runs every 15 minutes (by default).

Other than that the code is all the same from the previous post.  I've ran it through several tests and it seems to work for me.  I'd like to think there is a better way to handle this, but I can't think of anything right now.  You might consider adding code to the while activity so that it eventually terminates if the user never closes Office, but that is up to you.


No Comments

Leave a Comment