views:

761

answers:

3

We are using an infopath form that when submitted is supposed to fire off a custom .NET workflow. Basically, the information within the form is used to create a new sharepoint site. What I am seeing happen is that the first time the workflow runs (which is automatic after the form is submitted), the workflow errors out. When I run the workflow manually immediately after it fails, the workflow runs fine.

this.workflowProperties.Item["Client Name"]

I've debugged the issue down to the above line where workflowProperties is of type Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties. The first time the workflow runs, the property listed above (and all others) are null. The second time it is run the client name property is as it should be (populated from the infopath form).

Another important piece of information is that this workflow was working fine for over a year and suddenly started not working correctly a few weeks ago for no particular reason. We were having some permissions issues the past month but I cannot see how that could be related to the workflow issue. The user I am logged in as is a site collection administrator. I use the same user to kick the workflow off manually (which succeeds). I do not think that the workflow runs as the user that is logged in though (when it is run automatically on form submission).

Another interesting wrinkle to the whole situation: there are a total of 3 custom workflows that the application uses. 2 were made in visual studio - one of these works fine and other is displaying the behavior described above. The last was made in sharepoint designer and is failing.

I'm willing to try just about anything at this point. I am on a dev server (which displays the exact symptoms as production) so I can try just about anything.

+1  A: 

I'm guessing this has to do with the workflow being fired asynchronously from the commit operation that sets the fields values. Can you try and fetch the item explictly from the list instead of using the Item from the workflow properties. something like the following:

SPListItem l_item = 
      workflowProperties.Item.List.Items.GetItemById(
                 workflowProperties.Item.Id
      );

i'm not certain, but it may be worth a try.

The other thing to keep in mind is the SPContext.Current object will be null if being called from an EventReceiver, but will be valid if called manually. It doesn't sound like this is the issue, but its something to be aware of nonetheless.

Jason
I'm in the process of trying the code above. I inserted the exact code snippet above - l_item is not null which I think may be a good sign. Please bear with me - I'm a sharepoint beginner.
sestocker
I added an edit above. Would it be possible at all that permissions could play a part in the problem? When I successfully run the workflow I am logged in as the site collection administrator.
sestocker
has the permission been changed on the underlying list? if the user doesn't have permission to create a new listitem might they have still kicked off the workflow which is then checking for a value that doesn't exist? Can you login with a different account and test with various permissions?
Jason
I am submitting the infopath form as a collection admin. I'm unclear under what account the workflow runs under.
sestocker
the workflow runs as the user that initiates it. create another account and give it contribute permisssions on the list. ensure the workflow runs properly, try w/design permissions. Hopefully this will help you narrow down what is going wrong.
Jason
Jason, its been quite a while since I've had a chance to work on this. The permissions may still be causing the issue but it seems odd that one of the workflows is working perfectly fine.
sestocker
A: 

Try looking in your SharePoint Logs.

They are located under the 12-Hive in the LOGS folder - open up the latest and look for something with 'Workflow infrastructure' in it, maybe that can point you in the right direction.

Brian Jensen
A: 

The "solution" was to do an export and transfer to a new server. Basically just use STSADM to do the export operation and then import the same file on the new server.

SEE:

http://sharepointdogs.wordpress.com/2008/07/30/content-migration-or-backuprestore-in-moss-2007/

I was on the phone with Microsoft Support for hours on this issue - transferring to a new server would be my recommendation for anyone else that might encounter this problem.

sestocker