Sharepoint Gotchas

How to check if a sharepoint 2007 workflow is running

Adrian Hara — Wed, 13 Aug 2008 22:00:21 GMT

Searching for a way to check if a workflow is running on a list item (useful, for example, in an item event handler), I found some code like this:

        public static bool IsWorkflowRunning(SPListItem listItem, Guid workflowId)
        {
            foreach (SPWorkflow workflow in listItem.Workflows)
            {
                if (workflow.ParentAssociation.BaseTemplate.Id == workflowId &&
                    workflow.InternalState == SPWorkflowState.Running)
                {
                    return true;
                }
            }
            return false;
        }

What this code does is iterate the workflows list for the item (point to remember: listItem.Workflows contains not only running workflows, but also cancelled or otherwise) and checks the InternalState for the given workflow id. While it might seem ok, as I found out the hard way, it's not. Correct way to check is like so:

        public static bool IsWorkflowRunning(SPListItem listItem, Guid workflowId)
        {
            foreach (SPWorkflow workflow in listItem.Workflows)
            {
                if (workflow.ParentAssociation.BaseTemplate.Id == workflowId &&
                    (workflow.InternalState & SPWorkflowState.Running) == SPWorkflowState.Running)
                {
                    return true;
                }
            }
            return false;
        }

The somewhat subtle thing to notice is the check: it denotes that the SPWorkflowState is an enum decorated with the [Flags] attribute, which means that the check has to be changed like above.

Refresh SPWorkflowActivationProperties Item

Adrian Hara — Fri, 08 Aug 2008 16:28:51 GMT

If you're developing workflows for SharePoint 2007, you are probably familiar with the Item property of the SPWorkflowActivationProperties class. Usually your workflow gets an instance of SPWorkflowActivationProperties when the OnWorkflowActivated activity executes, which is bound to a public field on the workflow class so you can hang on to it for the lifetime of the workflow. Perhaps one of the more useful properties of this class is Item, which returns an instance of SPListItem, representing the list item on which the workflow runs.

This is all fine, but maybe for more than two step workflows or for a better design/maintainability of the code, it makes sense (and I try to do it) to encapsulate the properties (access to) and whatever manipulating logic of the list item in a business class, representing the business concept you're dealing with (for example, I find that using classes like Contract or Customer to work with the item's metadata is nicer than working with SPListItem). A small problem with this approach is that you can't simply wrap the SPListItem instance in your business class, because it's not [Serializable], which means that you'll get some nasty error when SharePoint tries to dehydrate your workflow. In light of this, what I do is wrap a reference to the SPWorkflowActivationProperties instance and have a private property called ListItem which just calls the Item property, like so:

        private SPListItem ListItem
        {
              get { return workflowProperties.Item; }
        }

This worked very good for me until a few days ago, when I had a workflow that runs over items in a document library and had to replace the actual document file at some point (like replace a .doc with a generated .pdf from it). The replacement worked fine (I won't go into details, google has answers ;)), but after the replacement, if, during the same call (meaning before the workflow gets dehydrated again), I wanted to do something else with the file, or even call Update() on the SPListItem, exceptions got thrown, with messages like "the file has been modified by blah blah". After some investigations I realized that that although I was modifying the SPFile (which i got from SPListItem.File) and calling Update() on it, this didn't do anything (for example, looking at the SPListItem.File.Name, I'd still get "somepath/somename.doc" instead of "somepath/somename.pdf"). Also, the next logical solution, calling Update() or SystemUpdate() on the SPListItem itself would throw, as stated above. However, if, after modifying and/or replacing the file, I wouldn't do anything else and just let the workflow dehydrate, whenever it would get hydrated again, everything would work: this makes sense, since the SPListItem is not serialized and would be created again after rehydration.

So, the next step would be looking when is the SPListItem of SPWorkflowActivationProperties created and how can we refresh it "on the fly". Reflector shows the following:

As you can see, the item is actually cached after the first call. This means that when updating the SPFile associated with the item and calling Update() on it, since this doesn't cause the item itself to update (or at least update its SPFile), we have to somehow refresh the whole SPListItem. While the SPWorkflowActivationProperties class doesn't expose some method to do this, it's easy to do with reflection: just set the m_item to null and on the next call to the property, it will be recreated. One thing to note here is that, as seen in the picture above, there are two cases where the item can be refreshed:

for non super user workflows, a call is made to the list directly for the item
for super user workflow, a call is made to SPWorkflow.ParentItem

Looking at the SPWorkflow.ParentItem with reflector, it turns out that the value backing the property is also cached:

So, in order to be fully covered for all situations, the method to invalidate the list item and make sure it's refreshed should look like so:

        private void InvalidateWorkflowPropertiesItem()
        {
            FieldInfo parentItemField = workflowProperties.Workflow.GetType().GetField("m_createdParentItem", BindingFlags.NonPublic | BindingFlags.Instance);
            parentItemField.SetValue(workflowProperties.Workflow, null);

            FieldInfo itemField = workflowProperties.GetType().GetField("m_item", BindingFlags.NonPublic | BindingFlags.Instance);
            itemField.SetValue(workflowProperties, null);
        }

Normally, you should just call this method after doing something that causes the SPFile for an item to change, but I guess there are probably other situations where refreshing of the list item would come in handy.

ps: another approach to the basic problem that the SPListItem isn't serializable would be to keep it's unique id and retrieve it like that every time you need it, but this could mean implementing the caching and getting mechanisms yourself if you want to have some business class wrapper over it (meaning that you can't just GetByUniqueId() it every time you need to change a property, because you'd end up with a different instance every time and would have to be careful about updating it)

Sharepoint 2007 - List vs. inherited content types gotcha

Adrian Hara — Wed, 16 Jul 2008 22:16:52 GMT

The following gotcha was a pretty nasty one for me (I'd say about 2 hours of lost time worth). Supposing you have some content types deployed at the site collection level and you want to add them to a document library of a sub-site (web) plus configure them a little bit, like so:

            foreach (string contentTypeName in ToAttachToListContentTypeNames)
            {
                // Get site collection content type
                SPContentType siteContentType = web.AvailableContentTypes[contentTypeName];

                // Add to library and configure
                SPContentType libraryContentType = library.ContentTypes.Add(siteContentType);
                libraryContentType.DocumentTemplate = string.Empty;
                libraryContentType.Update(false);

               // Maybe some more work, like adding some linked fields here?...
            }

This turned out to result in some weird behavior: supposing I had 3 content types to add to the document library, the first one of them (which would also be the first one added) always got some of its properties wrong. For example, even though the code sets the DocumentTemplate explicitly to string.Empty, the resulting document library content type (the first one added) would always get the "template.doc" template instead. Weird stuff happened also to some linked fields I was adding, like the first content type would always get one linked field less than the others

Now, unfortunately (or fortunately?) I didn't have the time to Reflect over the sharepoint code to see why this happens, but after some trial-and-errors I found that it seems the call to "library.ContentTypes" somehow merges the "web.AvailableContentTypes" with the library's content types. Since this call is done in the foreach loop, it means that, for each subsequent loop step, some settings for the content types added in prior steps are "merged" (read overwritten) with the ones of the site collection content types. What's weird is that:
1. It only seemed to happen for the first added content type (so the first step in the loop). The other two were fine.
2. It only "merged" some of its properties, like DocumentTemplate and *some* field links, not all

Anyway, the fix is to take the call to "library.ContentTypes" out of the loop and assign to a variable. Then you can just iterate over that "local" collection and do stuff:

            SPContentTypeCollection availableContentTypes = web.AvailableContentTypes;
            foreach (string contentTypeName in ToAttachContentTypeNames)
            {
                // Get site collection content type
                SPContentType siteContentType = availableContentTypes[contentTypeName];

                // Add to library and configure
                SPContentType libraryContentType = library.ContentTypes.Add(siteContentType);
                libraryContentType.DocumentTemplate = string.Empty;
                libraryContentType.Update(false);
            }
            library.Update();

            // Add some fieldlinks to the library content types
            SPContentTypeCollection libraryContentTypes = library.ContentTypes;
            foreach (string contentTypeName in ToExtendWithFieldLinksContentTypes)
            {
                SPContentType libraryContentType = libraryContentTypes[contentTypeName];

                SPFieldLink someFieldLink = new SPFieldLink(web.Fields["some field"]);
                libraryContentType.FieldLinks.Add(someFieldLink );

                // Maybe add some more...

                libraryContentType.Update(false);
            }

This seems to work, but granted, is strange enough to do...

Sharepoint custom content type without columns problem

Adrian Hara — Sun, 13 Jul 2008 16:59:28 GMT

To paraphrase a heavyweight blogger, this is the first post in (probably) a infinite number of posts about Sharepoint Gotchas.

Today's gotcha: why doesn't my custom content type have any columns?

It took me quite some time (including a little foaming-at-the-mouth time) to figure this out. Suppose you declare a custom content type in CAML that you'd like to just inherit all its columns from its base content type, without defining any of its own, like so:

<ContentType
      ID="0x010100D4C041607B6A400dB211CC424B2D153BAB"
      Name="My Content Type"
      Description="Foobar content type"
      Version="0"
      Group="Foobar Group" >
</ContentType>

All is well, it deploys fine, just that when you want to use it it turns out it didn't actually inherit any of its parent type's columns, but rather has an empty Columns list. The problem is pretty subtle, if you ask me, and stems from the fact that you should've declared the content type like so:

<ContentType
      ID="0x010100D4C041607B6A400dB211CC424B2D153BAB"
      Name="My Content Type"
      Description="Foobar content type"
      Version="0"
      Group="Foobar Group" >
    <FieldRefs/>
</ContentType>

Did you spot the difference yet? It's the <FieldRefs/> element. So even if you don't declare any columns, you still have to include the empty FieldRefs element. What's even nastier is that the schema validates without it :(...

Sharepoint 2007 ID and GUID conventions

Adrian Hara — Sun, 06 Jul 2008 22:18:59 GMT

Due to much frustration and lost time, I'll try to summarize in this post the "naming" conventions to be used when defining and/or referencing IDs (some of which are, in fact, GUIDs, and others contain GUIDs) in Sharepoint 2007.

If you're thinking "what the heck?! aren't GUIDs always the same format?!" you're half-right: they should be, but not in sharepoint. So if you're a newbie to sharepoint 2007 (or wss 3.0) like me, the following tips regarding how element id's should be written might save you some time (because if you get them wrong, the error messages from sharepoint are somewhat... cryptic). I've two conventions pinned down so far, but I'm just learning, so if you know any more, please share.

Site Column definitions: defined using a <Field> xml element (more info on MSDN), their id's must have the form {GUID}. Note the brackets, they are mandatory, else you'll get an error (in the logs only) along the lines of "unable to locate the xml-field definition for FieldName with FieldId 'your_guid'". Another thing to remember is that the brackets are also mandatory wherever this site column is referenced (like in a content type). Thanks to Edwin Vriethoff for this tip.
Content Types: as you probably know, the content type id is not actually a GUID, but a concatenation of the base content type id, "00" and a Guid. The catch here is that the Guid (third part in the concatenated string) must be written without dashes. So, instead of "0x010012B0E62B-D58E-4d6e-94A1-E36B3F7807E1", write "0x010012B0E62BD58E4d6e94A1E36B3F7807E1". Easy one to get wrong, especially if you use vs.net's guid generator in registry format. The error message from sharepoint in this case is very clear and helpful: "value does not fall within expected range" :)

It's actually too bad that 1) these gotchas exist and 2) the problems are not easy to figure out using the error messages from sharepoint. Hopefully, this post will help somewhat.