Accessing User Profile information is quite useful from within InfoPath. This is great for acquiring user fields such as title, phone number or any custom field created within the UPS (User Profile Service).
Within InfoPath, first, define the data connection to the UPS:
Then select the appropriate method. User Profile Service is quite a rich web service with a lot of methods:
Here’s what the user() value check looks like, on Form Load, that then is used to decide whether to change Views:
Here’s how to get the property of a user. Decide the property to get:
Decide the account for which to get the property:
Trigger the method:
Then extract the result set!
Very useful. It works like a charm.
I had an interesting problem the other day. One of the users of an InfoPath solution I had developed suddenly received errors using the InfoPath form on a VMWare instance, but it worked fine on her desktop. The InfoPath form lived in SharePoint, and had Managed Code I had written. Here’s the error.
It turns out, some clever admin restored a VMWare image that didn’t include the SharePoint runtime DLLs, yet the user’s profile contained the template. The solution was to go into InfoPath and remove the InfoPath template. On the next visit to the SharePoint site to fill out the InfoPath form, both the InfoPath form (*.xsn) as well as the SharePoint DLLs were downloaded and all worked.
It turns out the Infopath form template contains all the files needed to activate a solution, in a single file. It can include .html, .xml, .xsd, .xslt, script, and other file types that are necessary to support the functionality of the form.), such as files that define how controls in the form should appear, files for graphics that appear in the form, and programming files that enable custom behaviors in the form.
Here’s how to remove an InfoPath template on a user’s desktop:
Someone asked me today about using the SharePoint 2010 Client Object Model in Managed Code. I’ve done this in VSTA (Visual Studio for Tools and Applications) in C#. It took a bit of experimentation to get it going, here’s how I did it:
I extracted the Client Object Model runtime DLLs from the SharePoint server. That’s both Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.runtime.dll. For good measure I also took Microsoft.SharePoint.Client.Runtime.dll.deploy
In my C# (I was using VSTA) as for Managed C# in InfoPath, I:
- Added three project references:
- Added Using for SharePoint.Client
Opened AssemblyInfo.cs to deal with partial trust exception, and added:
using System.Security; //Added to try to resolve the partial trust error: JP
[assembly: AllowPartiallyTrustedCallers] //Added to try to resolve the partial trust error: JP
I had to turn the form from “Automatically determine security level” to “Full Trust”. This is an InfoPath specific setting, that may affect how this runs as a Farm Solution, and whether it needs a Farm Administrators approval.
At that point, you can use the Client Object Model. Getting data is done two different ways:
– CAML: my native old-style preferred approach for simple queries
– LINQ: for SQL-like queries; the one catch is you need to use SPMetal to create a runtime Thunk of sorts specific to your target sites/lists
Hope that helps!