Ever since v1 of SharePoint Team Services, Microsoft has used OWSSVR.DLL to remotely invoke functions against SharePoint.  With the incorporation of Web Services in v2, this need is partly deprecated and even more so in v3.  Nonetheless, OWSSVR.DLL is still around and still plays an important role with external applications such as SharePoint Designer.  It is part of FP-RPC (Front Page – Remote Procedure Call) but should not be confused with Front Page extensions.

Knowing this nifty utility can provide you a number commands for your developer tool bag.  Here are some examples I’ve come up with on how it can be used:

1. Returning all data for a SharePoint list, including its XSD:
http://WebApp/[site]/_vti_bin/owssvr.dll?Cmd=Display&List={ListGuid}&Query=*&XMLDATA=TRUE

2. Or, how about just returning all data for a SharePoint list, but based on a specific view from the list:
http://WebApp/[site]/_vti_bin/owssvr.dll?Cmd=Display&List={ListGuid}&View={ViewGuid}&XMLDATA=TRUE

The response for a simple view looks like this:

<xml xmlns:s='uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882'
     xmlns:dt='uuid:C2F41010-65B3-11d1-A29F-00AA00C14882'
     xmlns:rs='urn:schemas-microsoft-com:rowset'
     xmlns:z='#RowsetSchema'>
<s:Schema id='RowsetSchema'>
   <s:ElementType name='row' content='eltOnly' rs:CommandTimeout='30'>
      <s:AttributeType name='ows_City' rs:name='City' rs:number='1'>
         <s:datatype dt:type='string' dt:maxLength='512' />
      </s:AttributeType>
      <s:AttributeType name='ows_ID' rs:name='ID' rs:number='2'>
         <s:datatype dt:type='i4' dt:maxLength='4' />
      </s:AttributeType>
   </s:ElementType>
</s:Schema>
<rs:data>
   <z:row ows_City='Berlin' ows_ID='1' />
   <z:row ows_City='Paris' ows_ID='2' />
   <z:row ows_City='Honolulu' ows_ID='3' />
   <z:row ows_City='Munich' ows_ID='4' />
   <z:row ows_City='Bordeaux' ows_ID='5' />
   <z:row ows_City='New York City' ows_ID='6' />
</rs:data>
</xml>

Either of these two could be useful for consuming in an XML Web Part or from any external application that can make HTTP requests and process XML output.  This includes the browser using XMLHTTP technology as covered in this article.  The example covered in this blog discusses how to consume the XML output in an InfoPath form.  Clever.

3. Aside from returning XML data, you can also get definition information.  For example, you can return the CAML-based definition of a list.  This can be real handy at times, especially if you are creating your own list definitions.  You can create the list using the UI and then scrape its definition this way:

http://WebApp/[site]/_vti_bin/owssvr.dll?Cmd=ExportList&List={ListGuid}

4. How about getting the ONET.XML (site definition) that was used to create a web site:

http://WebApp/[site]/_vti_bin/owssvr.dll?Cmd=GetProjSchema

5. And, finally, I’m not sure how this is helpful, but you could return all of the field types registered into SharePoint:

http://WebApp/[site]/_vti_bin/owssvr.dll?Cmd=GetProjSchema&SiteTemplate=fldtypes

As you can see, there are a number of practical and interesting ways of using this DLL.  I’ve found it useful for just extracting structure and content out of a SharePoint environment, and consuming this data from within applications.  There are a few more commands that you can also try, but I’ve chosen to not list them here.  You can learn more about it from this blog http://msdn.microsoft.com/en-us/library/ms478653.aspx.  This article isn’t dated, but I suspect much of it was pulled over from STS v2 as many of the commands no longer work in WSS 3.0.

With that, have fun and let me know what other uses you can find for the output!

Notes:

1. This command will respect your SharePoint security.  So, any clients that call into it will need to be authenticated by the defined provider and object specific permissions are in force.

2. Some of the querystring parameters, such as XMLDATA are case sensitive.  If you follow the syntax above exactly, you shouldn’t have any problems.

3. You may have noticed that in some places, you must supply a GUID.  In case you didn’t know, you can easily extract these using the SharePoint UI.  For example, if you go to the settings page for any list (_layouts/listedit.aspx), you can extract the List GUID from the querystring.  If you edit the view for a list, you can also get the view’s GUID as well.

Technorati: SharePoint