Scenario
Since this update (http://blogs.msdn.com/b/vesku/archive/2014/11/07/sharepoint-user-profile-properties-now-writable-with-csom.aspx) on SharePoint client libraries, we can update User Profile properties using CSOM (prior to that, you could use the “old” user profile web service). However, under some circumstances, you can see that some of the properties have been updated, and some others have not.
You are using some code like this to create the PeopleManager
|
1 |
<span id="lnum1" style="color: #606060"> 1:</span> <span style="color: #0000ff">this</span>.peopleManager = <span style="color: #0000ff">new</span> PeopleManager(<span style="color: #0000ff">this</span>.SharepointClientContext); |
Then, you have multiple calls to SetSingleValueProfileProperty to update different properties
|
1 |
<span id="lnum1" style="color: #606060"> 1:</span> <span style="color: #0000ff">this</span>.peopleManager.SetSingleValueProfileProperty( |
|
1 |
<span id="lnum2" style="color: #606060"> 2:</span> accountName, |
|
1 |
<span id="lnum3" style="color: #606060"> 3:</span> userProfilePropertyName, |
|
1 |
<span id="lnum4" style="color: #606060"> 4:</span> propertyValue); |
And finally, you commit the changes to SharePoint:
|
1 |
<span id="lnum1" style="color: #606060"> 1:</span> <span style="color: #0000ff">this</span>.SharepointClientContext.ExecuteQuery(); |
Cause
It seems that when you are trying to update different properties and you do a final ExecuteQuery, the SharePoint client library actually splits the update query into different requests to the client.svc/ProcessQuery service. I don’t know the exact number of properties where the Client library split into 2 or more requests, but in my case, I was trying to update 18 user profile properties, and considering the first request had 11 properties, seems quite clear that it will split the query if you are updating more than 11 properties in a single ExecuteQuery
I realised about that using the magic from Fiddler. Image below shows the 2 requests, after only one ExecuteQuery call:
Each request sent some XML in the body request like:
So, in my case, the first request was failing because one user profile property was not created in the SharePoint tenant, and I was able to see the error in the response body:
However, as the second request worked fine (all the properties in the body xml existed and the new value was right), the Client library is not raising an exception, so, the code worked fine, but the result was that some properties (the ones included in the first request) were not updated, and some others (second request) were updated.
In my opinion, this behaviour is kind of bug on the Client component, as it should raise an Exception if any partial request fails (or at least, warn it somehow)
Luis Manez
@luismanez
