Failed to load workflow.

Really frustrating error because it gives you absolutely nothing to go on. I do want to mention that I also tried building a brand new workflow and selecting one of these custom workflow activities and the behavior was odd. If i tried to add one as an ACTION inside my workflow designer, nothing would happen. No error, but the activity wasn’t added to the step either. It was as if my click/selection had no effect.

So I made the decision to completely remove and reinstall the custom activities. The codeplex solution comes nicely packaged using the SharePoint Installer, so all I had to do was run a remove and then a reinstall. Normally, a final step to getting this working according to the InstallGuide.txt is to:

Go to Central Administration -> Application Management -> Manage Web Application Features and activate the feature for desired web applications (usually it’s Sharepoint – 80 or Sharepoint – 443).

The odd thing was that I found this step was already done for me and the solution was listed as already deployed. So back to SharePoint Designer I went, double clicked on the .xoml file, damn, same error! I found several blog posts indicating that I should clear the SharePoint Designer cache. So I closed down SD, deleted the folders starting with 12.x.x.x and loaded SD back up. I tried to open my xoml file, still no luck, same error.

At this point I was getting pretty confused. I manually did a check of the Assembly to make sure it contained the DP.SharePoint.Workflow dll, I double checked the Features folder to make sure it contained the DP.SharePoint.Workflow folder and I make sure the .ACTIONS file was contained within the Workflow folder and that the permissions on it were not wonky. I also verified the web.config contained the safe control entries for that dll. All looked good to me.

FINALLY, I decided to compare my web.config against the old server’s web.config to make sure that I wasn’t missing anything. I did a quick search on DP and found that the old web.config contained one more entry than my new web.config did:

1

<authorizedType Assembly="DP.Sharepoint.Workflow, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0298457208daed83" Namespace="DP.Sharepoint.Workflow" TypeName="*" Authorized="True" />

So it would appear that I was missing this authorized type necessary for custom workflow activities. How or why this did not get added when I did my reinstall, I have no idea. But once that entry was added back, I was good to go again. My workflows open just fine without error.

I hope this helps someone else out there!

List Item Not Found

For this particular scenario, here was my setup:

1. I have two lists: Survey and Customers
2. Survey has a custom column called Customer that is of type Lookup. This column is configured to lookup on the Title column in Customers
3. My custom SD workflow has a single activity, the Update List Item activity, configured to update the Customers list, on the Survey Status column, and the criteria for determining what item to update is based on the Customer lookup in the Survey list

Pretty straight forward stuff. I’ve done this a thousand times before and it’s worked without issue. However, I ran into a specific list where the workflow would error every single time, with the List Item Not Found message. Unfortunately, it’s very difficult to get any information other than what’s in the workflow history log. I attempted to read through the operations logs as well, but the information wasn’t really too helpful.

Doing some basic troubleshooting by adding an email activity and outputting the lookup variables in the body helped me determine that the Customer column in the Survey list was returning a blank value. That’s strange. Adding, editing and displaying items in the Customer list gives me no issue, I can select customers from my lookup and they read just fine. So why the heck does my workflow not properly record this value?

It gets a bit more puzzling when I grant myself Site Collection Administrator access to my site. Now all of a sudden, the workflow works and the lookup executes without issue. My entry in the Customers list is updated, all is happy for once. But granting users Site Collection Administration access is not a viable solution. It’s actually pretty crazy, so that’s not going to happen.

So after much frustration, I am sorry to report I don’t have much new information. What I did attempt to do however, was build my own version of the Update List Item activity in Visual Studio 2008. That turned out to be relatively straight forward. I used a bit of reflector to get the bits that I needed to successfully write this. That gave me the debugging capabilities that I desperately needed.

What I was now able to see with my custom activity was that the ListItem property was returning -1, and thus the GetItemById call on the Customers list was unable to find the item. Now why in the world was it returning -1? I’m still puzzled by this, and I’m not 100% sure if this is indeed a permissions related problem or if it’s something a entirely different.

I’m opening this up to anyone out there who might have some information regarding this particular issue. In the end, I wrote a custom Visual Studio sequential workflow, with literally 5 or so lines of code that essentially does the update for me and that runs without issue. I didn’t want to have to do that, but it was the only option I was left with for this particular list.

If anyone has any info, please drop me a line @ shereen at qumsieh dot ca. I would LOVE to get to the bottom of this.

Server returned a non-specific error when trying to get data from the data source

KB article 923173 deals specifically with this error, but none of the suggestions were the fix for me. I was not using a Proxy nor was I behind a firewall. In fact, my environment was totally virtualized and I was working on a stand alone installation of MOSS. SharePoint Designer happened to be installed on the same virtual environment. This was particularly frustrating because I was trying to give a Web Services demo for a class I was teaching on SharePoint Designer and kept running into this roadblock.

With the help of a fellow SharePoint guru, Bruce Redfern, we were able to track down the issue to the following two things:

1. Using the machine name or http://localhost as the Service description location for the web service was not working for us. We could connect to the web service and we could properly browse through the list of Operations, but after creating the data source and trying to Show Data, we would get that error above. In order to get around this, we had to specify the actual IP of the machine. So an example would be: http://10.0.1.15/_vti_bin/usergroup.asmx?WSDL
2. So if you got as far as the above, you’ll find that the web service will still not work. The final thing you have to remember is within the Data Source Properties window, click on the Login tab. You’ll want to select Save this username and password in the data connection. Enter in your moss/wss service account credentials and give it a go again.

1. Backed up a site collection from a server on domainA
2. Restored it to a separate server on domainB
3. Made my user account a site collection administrator
4. Opened up the site in Sharepoint Designer, and only had Contributor mode access. This access was insufficient because I was trying to create a workflow.

Solution:

The issue is related to the fact that I did a backup and restore from one environment to another, within different domains. Making myself a site collection administrator was not enough. There were residual accounts within my restored site collection that no longer applied. What I noticed is that when creating a new site collection, my account is automatically added to the site owners group for that site; however, when doing a restore, this doesn’t seem to happen.

It seems that sharepoint designer actually looks at the site owner group permissions, so i simply added my account to the site owners group, and my problem was solved. The next time I opened SharePoint Designer, I was no longer in Contributor mode.

So the key thing to note here is make sure your account is a member of the site owners group.