The Catch of Developing Application Using SharePoint Web Services

Posted in: Blog, SharePoint 2007, SharePoint 2010, SharePoint 2013 | Jan 29, 2013 at 7:59 AM

No comments

INTRODUCTION

For me SharePoint is such a great platform because not only does it have many built-in functionalities, it also allows integration of external systems and applications using various approaches such as web-parts, user controls, custom ASPX pages and web services.

On this particular article I would like to discuss few gotchas that we need to be aware of when we are integrating our application with SharePoint using its web services especially if you are using the web service to upload  a document into SharePoint document library.

The issue I have encountered was the fact that the web service will not work properly if it is executed under a proxy. And unfortunately, most big companies and clients implement proxy within their organisation.

For example: you have a feedback form on your website which will pump data into an internal SharePoint list and you are using SharePoint web services to do so. The form allows someone to also attach a document.

If your website calls the web services directly and someone under a proxy submits the form, he will either get a web service error (can be timeout error) or the data is not submitted into the list and library properly. In my case the uploaded documents were all 0-kb in size.

ASSUMPTIONS

With this article I assume that you have a web server in the DMZ which public users access which then talk to an internal SharePoint server within your corporate network.

If you have a simple topology (which is not recommended obviously) whereby public users can access your internal SharePoint system directly from the Internet then this article may not be applicable.

RESOLUTION

The solution I’ve used is a “chain of web services”. I implement 3 web services to make this work. The topology looks like the following:

DMZ
– Public website calls the first web service located on the same server (I call it Source web service)
– The Source web service then calls the second web service which is located in the internal network (I call it Destination web service)

INTERNAL
– The Destination web service then calls the third web service which is also located in the internal network (I call it SP Uploader web service)
– And finally the SP Uploader web service then calls the SharePoint web services to perform the list and upload functions.

I think the main problem lies with the fact that the IIS worker process of your public website can’t access the internal SharePoint web services directly if executed under a proxy.

With this approach, the proxy somehow allows your public website worker process to talk with a web service in the same server. It’s the Source web service worker process that then calls and passes the data to the internal web services. During this process the proxy no longer interferes with the web service calls.

Hope this helps,

Tommy

No Comments Yet.