I know it has been a while. I’ve been meaning to blog so many times, and honestly by the time I get around to it, my creativity has been sapped for the day. However, I felt this was one that needed to be put out there for reference. I’ve been working on this for the past few months, and I had a lot of questions about it at the last event where I spoke and presented on the topic.
Way back when I first started blogging, I wrote a couple of posts about using the User Profile Service in SharePoint 2007 (yes it was that long ago) to pre-populate fields within an InfoPath form with either the logged in user’s information or information for another user. This was used very often in InfoPath solutions in a lot of organizations, and it worked great and easily in both 2007 and again in 2010. However, when you move to upgrade to SharePoint 2013, you may experience some issues. It can still be done, but you will have to make some changes.
These steps can be used for both upgraded InfoPath solutions as well as new InfoPath solutions. I would caution you, though, to consider carefully any new InfoPath forms being created until the future of InfoPath is more clear. I know there is a lot of concern about the future of InfoPath out there, and a lot of rumors that it is deprecated or “going away”. However, until there is an official announcement of that, it is still a valid product and can still be used. My advice (and this is my personal advice) is to use it wisely and give consideration to alternatives as well since there is still some confusion. InfoPath 2013 has been released, and is a supported product, and while no “new” things have been added, nothing was taken away from the product either. There’s my $.02, you may want some change back!
Now on to the real reason for this post: How to make the User Profile Service web service work with SharePoint 2013 and InfoPath 2013.
The addition of claims (and the fact that the default configuration is claims) in SharePoint 2013 causes some different behavior when connecting to web services. If you ask a developer about this, they’ll probably run screaming in the other direction, because they’ve banged their head on the desk a few times trying to get everything to work and it isn’t easy. I know, I asked my friend Becky Isserman about it just to confirm what I was hearing in general, and she did! The problem is, that the web service can’t understand that ugly thing that passes for a username in claims. If you haven’t looked at it, it looks a little like this: i:0#.w|contoso\lori. Definitely not what we are used to working with. Don’t ask me what all those things mean, I know they mean something but I don’t have it memorized by any means. If you want to know, though this is a good place to start: http://yalla.itgroove.net/2012/11/claims-based-authentication-in-sharepoint-2010/.
So now we have to figure out how to make it work. Don’t worry, if you’ve already got a form that is connected, you can do this with those as well as new forms. I’m going to be starting from scratch, but if you are starting from a pre-existing form, just remember to start at step 3.
- I have created a very basic form just to demonstrate how to do this. The form contains some user information fields and a hidden field (shown on the bottom of the form, just to see what it looks like).
- We want to connect to the user profile service to populate the name and email address automatically. So create a new data connection to a SOAP web service and use the following web service URL: http://<yoursiteurl>/_vti_bin/userprofileservice.asmx. Configure it exactly like you did in previous versions (you can use the links above for reference if desired).
- Once you have that connection, you will have to convert it to a data connection file. Click on the data connection and click Convert to Connection File.
- Name and save your data connection file to your data connection library (you will have to create one if you do not have it already). You can leave this relative to your site collection.
- Now comes the fun part. You will have to work with your SharePoint administrator if you aren’t that person and have them create an application ID in the secure store. Once you have done this once, you may not need to do it again unless you plan to have different permissions and credentials for every form with this connection. If you have this created already, skip to step 10. To do this, go to the secure store in Central Administration (Manage Service Applications>Secure Store>. Click New in Manage Target Applications. Then name your application ID. For this example I’m calling it InfoPathID as both the Target Application ID and Display Name. Then enter an email. Change the Target Application Type to Group and then click Next.
- You can click next on the page identifying the fields in the ID, leave the defaults.
- Since this is a group application ID, you will have to set administrators and users. for the Administrator, I’m just using my farm account, but you may have a specific user or group that maintains your application ID, enter that information.
- For the Members, you will need to consider how this form (or other forms if you plan to reuse the same credentials on all form connections) will be used. If all users will have access to the form to use it, you will need to add Domain Users as the members. This will allow all users to be able to use the form and connect to the User Profile Service. Click OK when completed.
- Once you have the Application ID created, it is time to set the credentials. This should be an account that has the ability to read user profiles in your environment. It could be a service account that you reuse or a new service account especially for this purpose. For my example, I’m using the farm account, but that is NOT recommended for production environments. Click the down arrow by the application ID and click Set Credentials. Enter your information and then click OK.
- While working with your administrator for the credentials, you will also have to make a change to the InfoPath Forms Services configuration. Go to General Application Settings>Configure InfoPath Forms Services in Central Administration.
- Ensure that the checkbox next to “Allow user from templates to use authentication information contained in data connection files” is checked.
- Now we can go back to the data connection. When we created the data connection, it created an XML file in our data connection library. This file contains all of the information used to connect to the web service. You’ll notice there’s a line near the bottom that is commented out for Authentication information.
- To connect with our web service, we will have to pass the authentication information that we have created in our Application ID. Delete the comment dashes and exclamation points from the node in the XML and enter the app ID you have created and the credential type of NTLM. It should look like this:
- Once you have made the change, save this back to your data connection library. Now we can start working within the form to connect.
- While we can now connect successfully to the form, the credentials that are being passed to the service to query are the credentials that were entered in the Target Application ID in the Secure Store. Probably not the credentials we need to use. This is why I have added the User Name field in my InfoPath form. But if you looked closely, it is passing that ugly claims user name. That is NOT what we want. What we will have to do is trim this using a function to show only the username itself with the domain. In the control, create a default value and insert a function of substring-after. Configure it so that it uses the username as the string and only returns the substring after the “pipe”. It should look like this:
- This should return the following when used within the form:
- Now we can use this username to populate the query fields of our data connection and query to populate our form. The way you do this part may vary, I’m doing a very simple version of it, where it populates when they first open the form. First, in InfoPath, show the Manage Rules section and select the UserName field from your data fields in the right, then click New> Action.
- Under Run these actions, click Set a Field’s Value.
- Select the Fields button in the Rule details dialog and then change the data source drop-down to the secondary data connection for your User Profile Service connection.
- You will notice there are two sections, query fields and data fields. We will want to populate the query field with the username we have in the form. Expand the section for query fields and select the AccountName query field and then click OK.
- Set the value of the field by clicking the function button and inserting the current (Username) field then click OK. It should look like this in the rule details:
- Now click Add to add an action and select Query for Data. Set the Data Connection to query to your user profile data connection and then click OK.
- Now you can add additional actions to set the field values for the Name and email fields as you have in the past with the User Profile Service and by setting the filters appropriately.
- Test it out:
This is a little more complicated at times than creating the connection without claims. However, this could have been used in previous versions as well by creating the Target Application ID and you would have to make no changes for claims other than the substring changes to remove the odd characters from the username.
It is important if you are the InfoPath forms administrator in your organization that you work with the team who will be upgrading your environment to 2013. While everything may move correctly (good luck with that) you’ll also need to work on correcting your forms to use this method of connecting to the User Profile Service either before or immediately after upgrade to ensure that users have a smooth experience with the transition.