SPServices: What About Deprecation of the SOAP Web Services?

SPServices user JSdream asked a question in the SPServices Discussions on Codeplex the other day that’s worthy of a more prominent response.

Should we, who use SPServices, be concerned at all with Microsoft recommending not to use either the ASMX web services in SharePoint 2013 (http://msdn.microsoft.com/en-us/library/office/jj164060.aspx#DeprecatedAPIs) or the owssvr.dll (I used this one a lot when doing InfoPath stuff) for development purposes?

The Choose the right API set in SharePoint 2013 article is an important one, for sure. In it, there’s pretty clear direction about which API to choose based on the specific requirements of the solution you are building. As with anything, though, there’s a strong dash of “it depends”. It depends on things like your available skills, the device the code will run on, etc.

Figure 1. Selected SharePoint extension types and SharePoint sets of APIs

Figure 1. Selected SharePoint extension types and SharePoint sets of APIs

I would say that we should all be “cautious” rather than “concerned”. The SOAP Web Services are used by many parts of SharePoint still, with the most prominent being SharePoint Designer. If you sniff around in the traffic between processes, you’ll spot other places as well.

That said, deprecated is deprecated. If you build your solutions with the data access layer separated out from the business logic layer, you should be able to replace the calls if and when it becomes necessary.

I am not aware of any official specific time frames for the SOAP services going away, and the Product Group would need to give us a good, long lead time because lots of code depends on it, SPServices or not. Many people have built managed code-based solutions which use the SOAP Web Services as well. GetListItems is a workhorse operation no matter how you build your solutions.

There are many things you simply cannot do with REST yet, though in many cases CSOM may provide better coverage. If you are using SPServices for the operations which aren’t available in REST or CSOM, obviously you’ll want to continue doing so until there is a viable replacement. The REST coverage is improving steadily. (See Overview of SharePoint Conference 2014 and new content for developers for some information.) Keep in mind, though, that the majority of improvements will end up in Office365 first and in the SharePoint Server product at some point later or perhaps not at all. So your time horizons and cloud plans are also critical decision factors.

[If I had to put my money on a horse, it’d be REST over CSOM over the long term.]

All that said, if you are starting a new project on SharePoint 2013 of any significant size, you should be considering using the App Model, CSOM, and REST. SPServices may still fit in there somewhere, so don’t toss it out with the bath water just yet. I’ll continue evolving it as long as it has people wanting to use it. I think I still have plenty of things to do.

Bug in SharePoint’s Lists Web Service with GetListItems?

I was trying to track down some odd behavior in SharePoint’s Lists Web Service tonight, and I think I’ve found what I can only call a bug. 

Here’s the scenario.  All of these conditions must apply:: 

  • Using the GetListItems operation
  • Querying a list which has a required multi-select column
  • Specifying columns to return in the ViewFields parameter (whether or not the multi-select column above is specified)
  • The multi-select column has more than one value selected in an item (or items)

In this specific case, there are multiple copies of each item returned, one per value which is set in the required multi-select column.

I found two other posts on the Interwebs about this.  In both cases, the writer found the same problem, but was unable to determine the reason or a fix:

Both posts are from 2008, so I’m sure these guys have long since moved on, though I did leave Andy a comment.

It looks like a fix which will work is to not specify the columns in ViewFields.  This will make the GetListItems calls less efficient, of course, but it will make them work correctly.

The other solution, which doesn’t really make any sense, is to include

CAMLQueryOptions: "<QueryOptions><IncludeMandatoryColumns>FALSE</IncludeMandatoryColumns></QueryOptions>",

Setting IncludeMandatoryColumns to FALSE doesn’t do what it it is supposed to do per the SDK, but in this case it serves a useful purpose by eliminating the duplicate items. I worry when I find these seemingly kludgy fixes, but it is *extremely* unlikely that the Web Services are going to change, so I use them anyway.  Even if IncludeMandatoryColumns suddenly started doing what it should, I’d be fine here (and the calls to GetListItems would be even *more* efficient.)

Any other ideas out there?

Here’s an example.  There’s only one item in the States list for Massachusetts.  There’s a column called Staff, which is a Person or Group, allows multiple selections, and is required:

 

In my call to GetListItems, I’m specifying the two columns I would like returned:

CAMLViewFields: "<ViewFields><FieldRef Name='" + opt.relationshipListParentColumn + "' /><FieldRef Name='" + opt.relationshipListChildColumn + "' /></ViewFields>",

GetListItems returns a copy of the item per value for Staff. Note that the Staff column is being returned, even though i am *not* requesting it. (I’m only requesting the Region and State [Title] columns, but the other columns besides Staff come back regardless. Not exactly what I asked for, but it seems to be intentional in all of my experience with GetListItems. They are sort of the “base” columns which you’d need to do anything useful with the items.)

Demo Page: Using jQuery to Update an Item Without A Form

Last week, I spotted a really nice blog post from Mike Oryszak which showed how to update an item without a form by using jQuery to post changes using the SharePoint Lists Web Service. It got me thinking about a lot of things that you might do to make SharePoint feel more “Web 2.0”.  By using jQuery, you can quickly add functionality to your pages, and in this case, even use its AJAX capabilities to talk to Web Services.

I’ve created a new demo page on the Sympraxis Consulting demo site which ought to give you an idea of some of the possibilities.  The page shows how you can use SharePoint’s Lists Web Service and jQuery to update items in real time, without a roundtrip to the server.

imageEach row in the Data View Web part has buttons which allow you to increase/decrease the Potential Value column by either $1 or $10.  On each button click, there is a SOAP call to the Lists Web Service (_vti_bin/Lists.asmx, UpdateListItems operation) which updates the item.  The jQuery code then updates the value on the page and changes the fontStyle to italic.

After some DMs back and forth with Mike, at his suggestion (and for extra fun), we used the Tablesorter 2.0 jQuery library so that the table re-sorts after each Potential Value change. A bonus effect of this is that the column headers are sortable as well.  The CSS styling on the headers shows this.

A known issue (which we chose not to deal with here) is that concurrent changes will write over each other.  There is no checking for these conditions, though they could be managed fairly easily.

Take a look and let me know what you think!