Unexpected Error from GetListItemsChangesSinceToken Using SPServices

An unexpected result from GetListItemChangesSinceToken using SPServicesThis is another post in the vein of “it happened to me and it took me a long time to figure it out, so why should you go through the same pain”?

I’ve got an application running at a client that sits on top of SharePoint 2007. It uses KnockoutJS and lots of other modern Web development goodies, even though we’re on a very old SharePoint version. In fact, most of the time, I’m debugging in Internet Explorer 8, because that’s still the corporate standard.

Fun stuff, right? Well, the application serves them great, and I still get to have fun because it’s modern development.

Over the last few weeks, I’ve been trying to figure out why some of my calls to the SPServices function SPGetListItemsJson haven’t been returning what I expected. The calls were happening and I was getting valid responses in Firefox and Chrome, but in IE8, the data wasn’t all there. I was using localStorage to store a local cache of the data so I had data from weeks back there, but more recent data wasn’t coming back from my calls. (See Caching SharePoint Data Locally with SPServices and HTML5’s Web Storage for information on storing data locally in the browser cache.)

You can say what you want about my skills, but debugging Web Services calls in IE8 is well-nigh impossible. There’s simply no straightforward way to see the packets going out and back. Adding to the difficulty, Fiddler won’t run properly in this environment and the machine I remote into is locked down so that I can’t update it. Yup, three hands tied behind my back.

I finally got into the bowels of one of the calls using the IE8 Developer Tools (ick) and grabbed the innerHtml from the call. Here’s what I saw:

<xml:namespace prefix = soap />
<xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <?XML:NAMESPACE PREFIX = [default] http://schemas.microsoft.com/sharepoint/soap/ NS = "http://schemas.microsoft.com/sharepoint/soap/" />
    <GetListItemChangesSinceTokenResponse xmlns="http://schemas.microsoft.com/sharepoint/soap/">
        <listitems xmlns:rs="urn:schemas-microsoft-com:rowset">
            <Id ChangeType="InvalidToken">
          <?xml:namespace prefix = rs />
          <rs:data ItemCount="0">

Note the highlighted lines. I’d never run into that response before, so off the to MSDN documentation for GetListItemsChangesSinceToken, which underlies the SPGetListItemsJson function.

The basic documentation page for GetListItemsChangesSinceToken doesn’t say anything about InvalidToken and I’d never run into it before, so I had no idea what it meant. But in an article marked as

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

(Hey, we’re working with SharePoint 2007 here) there’s an explanation of several other possible responses to calls to the function:

Table 4: Change Events

Change Events Description
<Id ChangeType=”InvalidToken” /> The token is either invalid or old. You must do a full synchronization.
<Id ChangeType=”Restore” /> The list has been restored from the recycle bin or from a backup. You should perform a full synchronization.
<List></List> If the list schema has changed, or if a change token was not provided, the complete list is returned. The format is the same as returned by GetList.

In the first two cases above, the client should ignore other changes and do a full reconciliation of the list.

(See: https://msdn.microsoft.com/en-us/library/cc264031(v=office.12).aspxThe )

Like I said, I’ve never seen this response, so I had never built anything into SPGetListItemsJson to handle it.

The issue really came down to the fact that I was using localStorage rather than sessionStorage and I’d not built in a capability to occasionally throw away the localStorage cache and fully refresh it. Yes, my bad.

The quick fix was to switch to storing the cache in sessionStorage instead. On a lot of levels, that’s a good idea, anyway. Using localStorage means that I have a persistent cache, but if something goes wrong with that cache – corruption, or something exactly like this – there’s no quick fix. By switching to sessionStorage, I’ve made the cache volatile in that it will be purged at the end of each browser session. Now when someone has a problem with their cache (something they won’t ever understand from a user perspective), I can simply say “Please shut down your browser and restart. Let me know if that fixes the problem.”

I hope this helps someone else along the way.

Moving from SPServices to REST, Part 1: Introduction

In this series, you’ll learn how to transition from the SOAP Web Services – which SPServices supports – to REST. If your organization is making a transition to SharePoint 2013 or Office 365 & SharePoint Online (and anything hybrid in between), this series will help you develop new patterns, migrate your codebase, use OData effectively and more.

It’s been a nice, long ride for SPServices. If you aren’t familiar with SPServices, it’s freely available on Codeplex, Microsoft’s waning open source repository.

SPServices is a jQuery library that abstracts SharePoint’s Web Services and makes them easier to use. It also includes functions that use the various Web Service operations to provide more useful (and cool) capabilities. It works entirely client side and requires no server install.

The Web Services that SPServices abstracts for you are the older SOAP Web Services, sometimes known as XML services, or ASMX services. As I’ve said repeatedly at conferences and in posts (like this one) before, I think we still have many miles to go with the SOAP Web Services. Microsoft officially “deprecated” the SOAP Web Services as of the launch of SharePoint 2013, but I can’t see them fully disappearing for a good long time given the number of different ways they are used.

Two API sets are still supported in the SharePoint 2013 framework for backward compatibility, but we recommend that you not use them for new projects: the ASP.NET (asmx) web services, and direct Remote Procedure Calls (RPC) calls to the owssvr.dll file.

See: https://msdn.microsoft.com/en-us/library/office/jj164060.aspx#DeprecatedAPIs

I started writing this series just after SPTechCon San Francisco in 2014, having talked to Andrew Connell and Scot Hillier about how I might be able to contribute to IT Unity for the site’s launch. Obviously the series fell by the wayside for quite a while, but these topics are even more relevant now than they were when they first came to me.

Like many of you, I drive an older model car. It is fun to drive, is comfortable and seems to be in great shape. The car may last me a while, yet from time to time I think about what I might want to drive next.

Moving from SPServices to REST is like deciding to trade in your reliable car for a model with more safety features. You should do it, eventually.

Photo Credit: “FIAT 600” by Andrea~S on Flickr http://ow.ly/wqxGN

At some point, we’ll all want to head into the dealer and get ourselves something shiny and new. To me, that something new is REpresentational State Transfer, also known as REST.

While SharePoint’s client-side object model (CSOM) can do a lot, it’s a SharePoint-specific technology. REST, however, is a Web standard. Many Web developers use REST to get their work done every day outside the SharePoint world. It’s time for those of us who develop on top of SharePoint to catch up with the rest of the Web development community. Most SharePoint developers have caught onto this reality in the last year or so.

When REST was first offered as an option in SharePoint 2010, it let us get some work done with lists, but that was about it. With SharePoint 2013 and even more so on Office365 with SharePoint Online and the Office365 APIs, the SharePoint team at Microsoft continues to give us more and more RESTful – or REST-driven – capabilities. New REST services have been introduced regularly and the existing services have been extended many times.

If you’ve loved working with SPServices, or at least you’ve gotten some good work done with it, this series of articles will help you to make the transition from the SOAP Web Services that SPServices wraps to the more open – and undoubtedly more robust over time – REST services offered in SharePoint 2013 and Office365. If you’re still running SharePoint 2007 or 2010 – as I know many of you are – this should still be a valuable series to you. By making some adjustments in your development style and the coding patterns that you follow, you can put yourself in an excellent position to move to REST when it becomes appropriate for you to do so.

Here are some of the things I plan to cover in this series:

  • New patterns I suggest you follow with your SPServices code so that you’ll be better prepared to move to REST when the time comes. A side benefit of these new patterns will be better modularity and reusability in your SPServices-based code.
  • You will learn ways to move parts of your code from SPServices to use REST even now with less effort than you might think. We’ll talk about where the most likely places in your codebase probably are and how to get started.
  • We’ll look at how the functionality in the SOAP Web Services maps to the current REST services and where there are still gaps.
  • We’ll talk about where OData comes in and how best to understand the OData componentry that sits under the SharePoint-specific implementation of REST. There are some differences from the standard (these gaps are narrowing all the time), and it’s important to know what those differences are and why they matter.
  • As Microsoft adds more functionality to REST in SharePoint 2013 and Office 365, I’ll write new articles in the series to augment the base set of content. It’s not your father’s Microsoft anymore – the SharePoint team is moving fast and improvements are going to be coming Fast and Furious (see what I did there?)

It’s hard to give up the old car that you’ve driven for years, but sooner or later, it’s time. Maybe the engine starts knocking too much or the springs in the seat get uncomfortable. Maybe you just want to try out something new. It is sad letting the old girl go, but at some point, it’s simply time. I once held onto a car until the engine simply stopped working. You don’t want to be in a similar situation with your SharePoint functionality built on top of SOAP. Let’s start to plan for the future, and let’s do it together.

Cooler with better design and safety features. Your new code using REST, using practices favored by the rest of the Web development community.

Photo Credit: “2014 Fiat 500” by Abdullah AlBargan on Flickr http://ow.ly/wqynJ

This article was first published on IT Unity on March 25, 2015. Visit the post there to read additional comments.

Great Resource: Responsive SharePoint from Eric Overfield

2015-03-20_10-55-33This week I was working on moving a design into SharePoint 2010. The design was made up of the standard sorts of things: HTML mockups with graphics, CSS, etc. The mockups are using Twitter Bootstrap as the styling framework.

I’ve done this sort of branding implementation many times, and it’s always interesting because what I get to start from is different every single time, even if it comes from the same designer. Over time we all change our approaches and styles because we learn better ways of doing things. That’s a good thing, but it means that every design implementation is like a new experience, albeit with many common components.

When I’m implementing a design in SharePoint, I find that there are use one of three basic approaches, regardless which version of SharePoint it is:

  • From the top down – In this case, I’m changing SharePoint’s master pages very little. We might want to change some colors, fonts, and basic functionality, but it still will look like SharePoint from a structural standpoint: banner across the top, Quick Launch down the left, etc. Here I just make a copy of default.master, v4.master, or seattle.master – depending on the version – and add some CSS and script references.
  • From the bottom up – This is the most extreme branding, where I start with a minimal master page and build things from the ground up. This is most common with Internet-facing sites, but can also be the case for an Intranet. Everything is customized in the master page: the HTML markup, the content placeholders and their placement, etc.
  • Something in between – This was the case with the current project. Even though the end goal is a site that look little like SharePoint, it doesn’t require a total disemboweling of the master page.

For the latter two bullets, we have some excellent choices available to us which have been created by the SharePoint community. To me, the shining lights here are Randy Drisgill (@drisgill), Eric Overfield (@EricOverfield), and Kyle Schaffer (@kyleschaeffer). (That’s an alphabetical list by last name; they are all equally awesome.)

All three of these brilliant guys have free starter solutions on Codeplex:

In this particular project, Eric’s master pages seemed to be the best match. As I was struggling to get the ribbon to behave with Bootstrap, I realized that I didn’t need to fight the battle again myself and that Eric’s master page would probably be just the tickets. Indeed it was! After grabbing his project, I was able to get the design up and running in just a matter of hours.

If you’re even considering coming up with a responsive and/or Bootstrap-driven design, save yourself a lot of trouble and look at Kyle or Eric’s work It probably won’t be exactly what you want out of the box, but they have solved a huge majority of the problems you’ll run into already. This is what makes the SharePoint community so awesome. This is really deep capability and work that is out there for you to use – for free.


Simple OneDrive Better Practice

This morning I saw a post on Facebook (the other Yammer) from my friend Jasper Oosterveld (@jasoosterveld):

Great start of the morning! OneDrive for Business Sync lost my Visio file with my sitemaps and page lay-outs. Un&*@(believable….

It truly pains me to see posts like this for several reasons.

First of all, I hate to hear that someone has lost some work. Technology is supposed to make our lives easier, but sometimes I miss index cards.

OneDrive-forBizMicrosoft-OneDrive-logo-largeMore importantly, OneDrive ought to be awesome no matter which flavor you are using: OneDrive for Business, OneDrive [for Consumer], or whatever other adjunct flavor you may run into. (It’s OneDrive, but there’s more than one!)

The OneDrive team is making huge strides on the reliability of the product  – six months ago this would have just been a flat out rant – but there still a way to go. For example, here’s a recent post about how Managing your work files in the browser keeps getting easier on the OneDrive blog.

As I replied to Jasper, I’ve found that the most reliable approach using OneDrive for Business is to edit in one place only. By this, I mean to always edit locally or always edit in the host Document Library. What I’ve found works best for me is to use the Document Library only for central storage and always edit locally. It’s faster (the file is here already) and I know I’m backing it up with CrashPlan regularly.

OneDrive (none of the flavors) is *not* a backup mechanism – it’s a syncing mechanism. It’s main purpose – at least for me – is to make sure that I can access my files from any device. If I edit a file on my Surface Pro 3, then I know that I’ll see those edits on my ASUS laptop and vice versa.

OneDrive is getting better and better, but for now it requires a bit of caution. At some point in the not too distant future, I plan to throw that caution to the wind when OneDrive lives up to its promise.