XML Web service (web part) not working with AAM

Question

Hi,

I created an XML web service web part for our sharepoint intranet so that it presents a list of subsites on the home page. It all works fine at first, when navigating to http://servername:port/site.

However I created an alternate mapping for our intranet users so they can navigate with a nice easy URL. This also works fine to a point. They navigate to the site no problem, but the web part that I created is replaced with the error message

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator.



Checked back to the servername:port/site URL and the webpart is sat there happily displaying a list of subsites. Anybody got any good theories as to what causes this and a way around it?

Many Thanks in Advance.

Answer 1

Could it be a cross-domain security issue within your webpart? Where is the webservice that you're referring to? Anything in the log files to indicate an error?

---

Ch. - My Blog

Answer 2

11/02/2009 16:41:49.16  w3wp.exe (0x0D54)                        0x0F18 Windows SharePoint Services    Web Parts                      89a1 Monitorable Error while executing web part: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.     at System.ThrowHelper.ThrowKeyNotFoundException()     at System.Collections.Generic.Dictionary`2.get_Item(TKey key)     at Microsoft.SharePoint.WebControls.BaseXmlDataSource.AllowAuthenticatedExternalDataSource()     at Microsoft.SharePoint.WebControls.SoapDataSource.GetResponseString(SoapCommand currentSoapCommand)     at Microsoft.SharePoint.WebControls.SoapDataSource.ExecuteInternal(SoapCommand currentSoapCommand)     at Microsoft.SharePoint.WebControls.SoapDataSource.FetchData(String requestUrl)     at Microsoft.SharePoint.WebControls.BaseXmlDataSource.Execute(String request)     at Microsoft.SharePoint.WebControls.BaseXmlDataSource.GetXmlDocument()     ... 

11/02/2009 16:41:49.16* w3wp.exe (0x0D54)                        0x0F18 Windows SharePoint Services    Web Parts                      89a1 Monitorable ...at Microsoft.SharePoint.WebPartPages.DataFormWebPart.GetHierarchicalDocument(IHierarchicalDataSource ds)     at Microsoft.SharePoint.WebPartPages.DataFormWebPart.GetHierarchicalXPathNavigator(IHierarchicalDataSource ds)     at Microsoft.SharePoint.WebControls.SingleDataSource.GetXPathNavigatorInternal()     at Microsoft.SharePoint.WebControls.SingleDataSource.GetXPathNavigator()     at Microsoft.SharePoint.WebControls.SingleDataSource.GetXPathNavigator(IDataSource datasource, Boolean originalData)     at Microsoft.SharePoint.WebPartPages.DataFormWebPart.GetXPathNavigator(String viewPath)     at Microsoft.SharePoint.WebPartPages.DataFormWebPart.PrepareAndPerformTransform() 


I'm not much on LOG files so this is something of a stab in the dark. The above seems to appear in the log files whenever I reload a web page with this webpart error on it. There are other lines, but none that actually say "web parts" like this one does, so perhaps this is the place to start, or if you think there's more to look out for, let me know and I'll retrieve what I can.

The web service is one of the XML web services within the site _vti_bin/webs.asmx?WSDL

Not sure about security, but when I try and access the sitecollection through IE on the server itself, using the Intranet AAM as opposed to servername:port/site I get prompted for a username and password, and my usual username and password doesn't seem to work, however accessing it from our users network with the same domain, username and password works fine. Possibly a factor?


Thanks

Answer 3

What is the URL for the web service that you're connecting to?

If the URL starts with http://servername:port (i.e., the default aam entry), is is also accessible from http://niceeasyurl (your custom alternate access mapping)?

My guess is that when your users try to connect to the site, it tries to connect to http://niceeasyurl/(your_web_service) rather than http://servername:port/(your_web_service)

    Tim

Answer 4

I connected to the web service on the default URL, so http://servername:port/(webservice), I then dropped the webpart on to the default.aspx page of servername:port. It was only after I had done all this that I created the AAM.

Could it be changing the URL on it's own, or could it be trying to access http://servername:port/(webservice) as http://niceeasyurl/(webservice) causing some sort of security conflict?

Answer 5

I think as Tim says, your webpart is trying to connect to the same url regardless of the url that you use to access the site. The errors that you've posted above do suggest that your webpart isn't receiving data.

AAM works well for links and such like on a site but it doesn't do anything for webpart parameters or dataconnection urls. Those will still be using the values that you entered when setting them up.

---

Ch. - My Blog

Answer 6

AAM can only change servernames not ports.

Your datasource you configured might be poiinting to the internal url. Maybe some of your users using the new url can't access it because it crosses domains.  You need to check how your web part was deployed.  If it has full trust, cross domain shouldn't be an issue.

Try this.  Pick one of your users that uses the nice url and create a personal view for that web part page.  Then reconfigure the web part to store the datasource pointing to the nice url web service.  Now when that user hits the page, the web part will use personal settings and hopefully it will be able to connect to the web service.

But the datasource should be a relative path not an absolute.  Why doesn't _vti_bin/webs.asmx work?

Answer 7

Thanks for the help so far.

I created the web part from the XML web service in Sharepoint Designer, put http://servername:port/site/_vti_bin/webs.asmx?WSDL as the service location and selected "Don't attempt to authenticate" in the login tab, then simply dragged and dropped the web part into the default.aspx. How would I make this a relative path or give this Full Trust?

Answer 8

Try changing the url in your webpart prioerties to "/_vti_bin/webs.asmx?WSDL", that way it will automatically pick up the rest of the url from the current page.

You can grant your webpart full trust by installing it in the GAC.

Are both of your url's using the same authentication method?

---

Ch. - My Blog

Answer 9

Any idea how I would find the DLL for this webpart to install it in the GAC? Pathname??

Thanks

Answer 10

Is this a custom webpart or a built in sharepoint webpart?

it's more than likley in the bin folder of your web site (Web application in SharePoint speak) if it's a custom webpart

---

Ch. - My Blog

Answer 11

I suppose it's a custom one as it isn't a built in webpart, it's a data view webpart created from the Data Source Library pane in Sharepoint Designer! An XML file called sitedataon(servername).xml, is under _catalogs/fpdatasources in Sharepoint Designers Folder List pane, but I can't seem to find this in the virtual directory for the web application. The Bin folder is empty and when I search for sitedataon(servername).xml the results return nothing.

Answer 12

You will need to contact the developer(s) of this web part directly.

This problem may probably be caused by incorrect reference of web service.
If that's the case, nothing you did can really help you.

---

Keep It Simple and Stupid.

Answer 13

Charlie,

The web part was created in SPD with 5 simple steps through the Data Source Library. No developer as such.

Could it be something to do with a GUID?

Answer 14

hmm... SPD web part?

This might be the problem. SPD is a very very simple IDE and use straight forward logic.
It is very likely that SPD reference the URL or something in an incorrect manner.

You can try develop a new web part with AAM web services and compare the difference of the generated code.

PS: GUID problem will be an exception with the error message that GUID is conflict in Log files.

---

Keep It Simple and Stupid.