Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I am experiencing difficulty creating a file in a document library using the client object model. My custom Visual Studio 2010 workflow is not detecting the updates I am making to the file's list item after it is created.

I'd like to give an idea of the infrastructure to answer some likely questions:

  • The document is uploaded to a web service, which is responsible for actually inserting the document in the library and configuring the values of its list columns
  • The web service is performing this operation using the Client Object Model
  • The web service is authenticating against the SharePoint site with an account created for business intelligence automation that DOES NOT RUN as the system account when interacting with SharePoint; it is, however, a member of SharePoint owners
  • The operations in the custom workflow depend on the file's list item columns being populated before it can proceed to assign tasks to the users in two of those columns; for that reason, I created a While activity to monitor changes in the list item until those two columns are no longer null

The following is a sample of what the web service is doing. It is running in IIS under the Business Intelligence user identity. I've added some comments as to which operations I was anticipating the workflow would respond appropriately.

Using client As New ClientContext(My.Settings.SharePointSiteURL)

    // Pre-processing to determine appropriate user ID values for columns

    Dim fci As New FileCreationInformation() With {
        .Content = IO.File.ReadAllBytes(storagePath),
        .Overwrite = True,
        .Url = String.Format("{0}/{1}", theList.RootFolder.ServerRelativeUrl, theFileName)
    }

    Dim theFile As Microsoft.SharePoint.Client.File = theList.RootFolder.Files.Add(fci)

    // Expecting the workflow to be activated here
    client.ExecuteQuery()

    theFile.ListItemAllFields("Project_x0020_Manager") = pmId
    theFile.ListItemAllFields("Project_x0020_Accountant") = paId
    theFile.ListItemAllFields.Update()

    // Expecting the onWorkflowItemChanged activity to be invoked here
    client.ExecuteQuery()
End Using

The workflow does activate when a file is uploaded and continues on to wait for a change event from SharePoint, but that event never arrives as a direct result of the web service's operations. I'm able to modify the item manually and successfully continue on.

Is there a consideration when using the Client Object Model that might preclude these events from firing normally?

share|improve this question
add comment

3 Answers

up vote 0 down vote accepted

I'm having similar issue here. Almost exactly the same scenario. As far as it seems the upload of the file and update is happening too close together. I've tried updating an item after a while and the workflow continued with OnWorakflowItemChanged event.

Perhaps you could try with Thread.Sleep(1000) or a bit more time before second update - just for experimenting?

share|improve this answer
    
I got similar sentiments from a reply on StackOverflow. This may be a bug in the process model for SharePoint workflows that results in a race condition in detecting the first change event. I've elected to move my code inside the workflow proper. I don't like the solution, but trying to wait out a race condition is too non-deterministic for my tastes. It does appear, however, that a thread sleep could have some efficacy in resolving the problem. –  lthibodeaux Nov 20 '12 at 21:45
    
Could you explain how do you plan to move your code into worklfow? Do you have a workaround for "waiting for data"? –  Gomiunik Nov 20 '12 at 22:45
1  
In my case I was able to parse the name I gave the file in my web service to get the bare minimum data I needed and used it to retrieve the rest from a database. It was a contrived solution but it worked around the problem I was having. There was only so much intellectual ping-pong I had time to play with because of looming deadlines. –  lthibodeaux Nov 21 '12 at 14:12
add comment

After a lot of painstaking research and experiments, endless uploads to document library and deletes, at the end what did the trick for me is as follows:

I have the OnWorkflowItemChanged event in a loop - the same as you have.

I've added a method on invoked and changed the WaitForIdle to true in the event args

private void OnWorkflowItemChanged(object sender, ExternalDataEventArgs e)
{
    e.WaitForIdle = true;
}
share|improve this answer
    
This is interesting. I'll be sure to check it out. –  lthibodeaux Nov 21 '12 at 14:10
    
I'm afraid this approach didn't prove at all fruitful in any of my testing. –  lthibodeaux Nov 21 '12 at 14:54
add comment

Another thing that worked for me (and was even better than holding up threads) was to put after the line

Dim theFile As Microsoft.SharePoint.Client.File = theList.RootFolder.Files.Add(fci)

the following:

theFile.CheckOut();

and after

theFile.ListItemAllFields.Update()

the following:

theFile.CheckIn("", CheckinType.MajorCheckIn)

The checkout and checkin somehow got the workflowstarted event a head start before the onworkflowitemchanged, I gues.. The best would be that MS would fix this issue in a hotfix, so events wouldn't get ahead of themselves.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.