InfoPath Dev

I have an InfoPath 2003 form published on SharePoint 2003. In this form I'd like to auto-populate the "User" field with the SharePoint login/profile name when the user fills out the form from SharePoint. I was able to set up a data connection to UserProfileService.asmx?WSDL, but when I opened the form up in SharePoint I get this error:

The following DataObject either cannot be created or cannot be initialized: GetUserProfileByName
The query cannot be run for the following DataObject: GetUserProfileByName
InfoPath cannot run the specified query.
The SOAP response indicates that an error occurred:

System.Web.Services.Protocols.SoapException: Invalid input for account name, cannot be empty or null.
   at Microsoft.SharePoint.Portal.UserProfiles.UserProfileService.GetUserProfileByName(String AccountName)"

Here are the instructions that I followed:
http://blogs.microsoft.co.il/blogs/itaysk/archive/2007/04/05/InfoPath-_2D00_-Get-the-current-user-without-writing-code.aspx

What could I be doing wrong? Any help would be greatly appreciated.

Thanks,
Tom

Hey Tom.

Your issue is that you have SharePoint 2003 and that tutorial is for 2007.

I would look at the AD Web Service here http://www.qdabra.com/en/products/ADWebService.aspx

You can checkout the video or the documentation. It gives you not only name, but email, address, manager, what ever is in Active Directory.  This can be a big benefit in most forms to be able to complete forms for people and be able to identify the form user for auditing and security.

There is a funky way to get the person's name but that is all you can get from SP2003.

It involves submitting to SharePoint on Open.

Query Library for filename that you submitted the form as

Delete the file form the library using a CAML.

Then filter the created name from the SharePoint list data.

 

Hi Clay,

THanks for the help again. I don't have experience working with ADService or CAML, so I'll have to explore these options.

There was another solution posted by somebody on here that makes use of accessing WScript via ActiveX, but that displays a security dialogue every time the form is opened unless the form has Full Trust. Since the form will be published on the intranet, are there any problems with giving the form Full Trust privileges?

Tom

 Hi

First off I will point out some of the bad points of Full Trust:

it has to be installed locally, so each update has to be installed and updated by the individual;

the install each time has to be managed as a java app or a .MSI with 4 to 5 steps in each.  If the form was on the intranet it would mean an install each time.

I have written a bit of code in C# that i converted from VB that uses a web service run on a web server to call AD to return the "cn", surname, email address etc.  Works a treat.  Best thing is is that it does not require full trust and places little load on the server.

I researched a couple of options and this one was within my grasp (not much programming let alone C#) and does work well.

I can dig it out if you want the code in C# or point you to the blog if you are happy in VB.

Cheers 

The AD web service is nice because there is no code and it is very simple.

The bummer with Full Trust is each user has to install the form on their computer, and that is each form template that uses the code. And if it is changed you have to reinstall.

The AD web service is nice since once it is available, any form or form developer can use it.

I could show you a quick demonstration if you wanted.

Hi Tom,

Deployment is the biggest issue. Full Trust forms need to be signed with a digital certificate or installed using an MSI. Either way costs time and possible consternation for your end users. We typically tell people not to use Full Trust except in extreme situations. 99% of our forms are not Full Trust. You don't need it.

Is the user name the same as the SharePoint logon? I'm assuming it isn't which is normal for people accessing over the Internet.

There is a trick you can do. You can save the form and then call SharePoint to get the name of the user that saved it from the form library. I believe we have samples of this. Let us know if you need help. We are kind of busy today, and if you want to contribute an hour of support time or something, that would help. It will require some code to submit to SharePoint and get a document id and then lookup the SharePoint record and filter for the document ID to get the user name.

Active Directory won't work if you are not joined to the domain with the SharePoint site.

Cheers!

Hi guys,

Thanks a lot for the quick responses. I looked up the ADService product, but unfortunately $250 is out of the budget for me. It looks like calling ActiveX is also out of the question for me because I need the deployment to be as effortless as possible. The option to use the C# code seems promising, however my current form is already making use of JScript (script.js) -- is it possible to have both script.js and script.vbs or script.cs in the same form??

To answer your question, YES, the form user name can be the same as the SharePoint login. Would it be possible to access the SharePoint SPUser.Name or SPUser.LoginName property from within the form's JScript code (assuming the user fills out the form from within SharePoint)?

Thanks,
Tom

OK

Getting somewhere.  The web service is in C# (this runs on the web server and gets called by InfoPath as a secondary datasource), the code on the form is in VB (this does the calling), but should be very easy to convert to script.js.

As Clay says it is extremely user friendly as it is silent check on the load up of the form.

Cheers