Confusion About the UserProfile Web Service’s GetUserProfileByIndex Operation
I had a question in the SPServices Discussions the other day about what to pass to the GetUserProfileByIndex operation in order to retrieve the User Profile information for a user. Well, it seemed simple enough after looking at the MSDN SDK for GetUserProfileByIndex; you’d simply pass in the index. But what *is* the index? Is it the ID of the user in the User Information List or something else? As is so often the case, the SDK falls flat when it comes to useful details.
In the SDK for GetUserProfileByIndex in SharePoint 2007, we get this:
Parameters
- index
In the SDK for GetUserProfileByIndex in SharePoint 2010 it gets just a teeny bit better, but is still basically unhelpful:
Parameters
- index
- Type: System.Int32
The index of the user profile to be retrieved.
After doing a little more research, it’s even less clear what this operation is even supposed to be for. In two separate blog posts (here and here), both of which seem well researched and written, there’s mention that GetUserProfileByIndex doesn’t really do what you’d expect, anyway. It seems to be more intended for iterating over all of the users who currently have a My Site than to simply get their User Profile.
So, I’m less clear on how to call GetUserProfileByIndex than I was at the outset. I think it probably makes more sense to call GetUserProfileByName or GetUserProfileByGuid if at all possible, as both of those operations seem to return what one would expect: the User Profile for the specified user.
By the way, in playing around with GetUserProfileByIndex, I realized that I had incompletely implemented both GetUserProfileByGuid and GetUserProfileByIndex in v0.6.0 of SPServices. In neither case was I passing any parameter values at all. I’ve just fixed that in the first alpha for v0.6.3. It seems that no one had needed to use those two operations (or had simply given up on them without reporting any issues).
After my quick investigation, it looks like that the Index is the Record ID of the user profile in the database. I’m not sure if this Record ID is actually surfaced anywhere at all in the documentation, but if you can surface it in your code through the API, you can use this to guarantee a reference to an existing User Profile.
Thus the confusion. And it doesn’t seem to be an ID which is available anywhere *other* than in the User Profile Store. So the only way you can know what it is is to know what it is. See? Confusing.
M.
I guess it provides an way (when combined with GetUserProfileCount) to walk all the user profiles if you needed to access each and every one for whatever reason.
If you read the posts I linked to, you’ll see that “walking” the profiles based on the count won’t work reliably, either, because the count doesn’t tell you how many are missing (deleted). All in all, confusing. Thus the post!
One would think, given that the name of the operation is GetUserPofileByIndex, that one could pass in some *known* index to get a particular User Profile. Alas, that doesn’t seem to be the case, since you can’t know the right index unless you already have the User Profile. It seems that you would need to loop through all of the existing profiles until you got a match on name or some other property which ensured you had a match. That’s horrible inefficient, if nothing else.
M.
According to ILSpy, the method isn’t actually used by anything in that class, either. Maybe it was put in there for intended future use? The confusion continues.
Confusing indeed. If you need to iterate through the users, remember to use NextValue. Not very efficient or sexy but there you go.
NextValue is mentioned in my post which you were so kind to link to, Marc (http://sharepointsharpener.wordpress.com/2008/08/08/userprofileservice-web-service-returns-multiple-instances-of-user-profiles-with-identical-names/).
Thanks.
Maybe it was intented to be used with the _spUserId variable that Sp provides.
In case someone comes across this thread, there is some additional information located on the SPServices Discussion board about this function:
http://spservices.codeplex.com/discussions/350935