Reasons to [Still] Love SharePoint’s SOAP Web Services

There are still reasons to love the SOAP Web Services (hopefully using SPServices!) even though they have been deprecated by Microsoft in SharePoint 2013 (and one can assume to upcoming SharePoint 2016) and SharePoint Online.

There are times when the REST API just doesn’t provide functionality we need, and the SOAP Web Services are a useful fallback when that’s the case.

I’ve run into two very specific instances where this was the case lately. Since Microsoft is actively trying to get REST up to snuff, I’ve added requests to the SharePoint User Voice for both of these. If you would like to see these fixed, please go to the User Voice links and vote them up. While we’re waiting, though, it’s SOAP to save the day.

Recurring Calendar Events

It’s extremely common to have recurring events in a SharePoint Calendar list. Usually this type of event is used for a recurring meeting, or it could just be a placeholder to remind a team to check something, etc.

If you’re building client-side functionality, you may want to do something like retrieving all of the occurrences of events to show in a widget like fullcalendar. Unfortunately, the REST API doesn’t know from recurrence.

There’s a sample at the OfficeDev/PnP repo, but if you run through it, you’ll see it’s pretty ugly. Ingenious, but ugly.

You can pass a CAML fragment into your REST call to augment the OData request, and here’s a different example of how that can work:

// Example from https://karinebosch.wordpress.com/my-articles/caml-designer-for-sharepoint-2013/
$.ajax({ 
  url: _spPageContextInfo.webAbsoluteUrl + "/_api/web/lists/getbytitle('Tasks')/GetItems(query=@v1)?@v1={\"ViewXml\":\"<View><Query><Where><And><Neq><FieldRef Name='Status' /><Value Type='Choice'>Completed</Value></Neq><Membership Type='SPWeb.Groups'><FieldRef Name='AssignedTo' /></Membership></And></Where></Query></View>\"}", 
  type: "POST", 
  headers: { 
      "X-RequestDigest": $("#__REQUESTDIGEST").val(), 
      "Accept": "application/json;odata=verbose", 
      "Content-Type": "application/json; odata=verbose" 
  }, 
  success: function (data) { 
    if (data.d.results) { 
      // TODO: handle the data  
      alert('handle the data'); 
    } 
  }, 
  error: function (xhr) { 
     alert(xhr.status + ': ' + xhr.statusText); 
  } 
});

But if you need to do that, I don’t see why you wouldn’t just use SOAP.

User Voice: Add support for recurring events in the REST API

Lookup Site Columns in Other Webs

A good information architecture usually includes some list-based lookup columns. A simple example might be a list stored in the root site of a Site Collection to contain information about all of your organization’s offices. You might store things like:

  • Name of Office (using the Title column)
  • Address
  • City
  • State
  • Postal Code
  • Office Manager
  • Phone Number
  • Industry Focus
  • etc.

Then you might have a Site Column called Office Name that is a Lookup column into the Title column of that list. This enables you to offer a consistent list of options for Office Name to choose from throughout the Site Collection along with the other information (as needed), either for display purposes or for inclusion as data in other lists.

If you try to make a REST call which requests data in a column like this – when you aren’t in same site as the list – you’ll get an error like this:

{"error":{"code":"-1, Microsoft.SharePoint.SPException","message":{"lang":"en-US","value":"The field 'MyLookupColumn' is not supported in query. The lookup list is in another web."}}}

Uh-uh, it’s back to SOAP again.

User Voice: Enable support for lookup columns in other webs in the REST API

 

In case you were going to ask, I avoid CSOM/JSOM. I see it as a dead end – in this context, at least. More of Microsoft’s effort is going into REST, which is based on Web standards rather than a Microsoft-only approach.

What about you? Do you still see uses for SOAP where REST won’t do it? Respond in the comments if you know of other holes in the REST Swiss cheese.

Retrieving High Priority Tasks with SharePoint’s Query REST API

fullcalendar month view javascriptThis will be a quick post. Recently, when I wanted to make a REST call to retrieve all of the high priority tasks from a set of task lists, I figured it would be no big deal. I’d just add something into the querytext and be done with it. Unfortunately, syntax is always a cruel bedfellow.

I tried all sorts of things, like:

PriorityOWSCHCS:(1) High
PriorityOWSCHCS=(1) High
PriorityOWSCHCS='(1) High'
Priority:'(1) High'

etc.
Someone like Mikael Svenson (@mikaelsvenson) – search guru that he is – would just look at this and tell me immediately what to do, but I try not to bug him unless it’s something complicated. Oddly, I couldn’t find a single example out there of someone doing this. It would seem to be a common request: show me all of the high priority tasks in the Site Collection so that I can focus on them.

In this case, we’re showing those tasks on a fullcalendar on the home page of a parent site which has many subsites, each for a project. Fullcalendar is an excellent, full-featured JavaScript calendar widget that you can pretty easily add into a SharePoint page. You just have to feed it data in a format it can understand. So we want to retrieve all of those project tasks using the search API and massage them into the fullcalendar format.

The filtering solution turned out to be too easy:

Priority:1

Here’s the full code that I came up with for this part of my KnockoutJS view model:

// Only get tasks with Priority='(1) High'
var projectTasks = [];
$.ajax({
  url: _spPageContextInfo.webAbsoluteUrl + "/_api/search/query?" +
    "querytext=%27ContentTypeId:0x01080023AEF73C31A00C4C87FD5DB6FD82F6EE* Priority:1%27" +
    "&amp;selectproperties=%27Title,StartDateOWSDATE,DueDateOWSDATE,Path,Body,PriorityOWSCHCS%27",
  type: "GET",
  headers: {
    "accept": "application/json;odata=verbose",
  },
  success: function(data) {

    $.each(data.d.query.PrimaryQueryResult.RelevantResults.Table.Rows.results, function(index, item) {

      var searchResult = [];

      // Normalize the fields
      $.each(this.Cells.results, function(i, prop) {
        searchResult[prop.Key] = prop.Value; // { Value: prop.Value, ValueType: prop.ValueType };
      });

      projectTasks.push({
        calendar: "Project Tasks",
        color: "rgb(100,150,148)",
        title: searchResult.Title,
        path: searchResult.Path,
        eventDate: $.fullCalendar.moment(searchResult.StartDateOWSDATE),
        endDate: $.fullCalendar.moment(searchResult.DueDateOWSDATE)
      });
    });
  },
  error: function(error) {
    alert(JSON.stringify(error));
  }
});

If nothing else, the next time I need to do this, I’ll hit something when I search!

Software Adoption: A People Problem, or A Technology Problem?

I was a guest recently on the TechnologyAdvice Expert Interview Series to share my thoughts on the intersection of sales, marketing, and technology. The series, which is hosted by TechnologyAdvice’s Josh Bland, explores a variety of business and technology landscapes through conversations with industry leaders.

In this episode we discussed corporate cultures, global collaboration, and the upcoming SharePoint Technology Conference (SPTechCon) in Boston August 24-27.

Below are a few highlights from our conversation:

TechnologyAdvice: How does SharePoint help businesses and employees collaborate in a world where everything is always connected?

Marc Anderson: SharePoint has had a rather long lifespan for enterprise software — lots of things don’t last as long as SharePoint has. In the earlier days, it was very focused on teamwork– small groups of people trying to accomplish specific things. The goals might have been bigger, but that was really the focus.

Where Microsoft is going now, is they’ve moved their focus to offering services rather than software. They’re actually at the forefront of where businesses are going over the next five to ten years, whether they know they will or not. It’s not about the technology so much. The fact that it’s in the cloud or that it’s got a blue logo or something really doesn’t make any difference.

Over the last 10 to 15 years, we’ve really seen a change in the way corporate cultures and structures work compared to the way they used to. The Industrial Revolution and 1950’s military industrial complex were very hierarchical, very siloed. Now inefficient organizations are getting flatter. They’re putting teams together to solve specific problems and they’re having those teams break apart again, then go off and form new teams, so each person in that team might go do different things.

We’re seeing a lot more agile, small organizations able to accomplish things in different ways than they used to. That’s where SharePoint’s really going with some of the stuff they’re rolling out on Office 365, with more machine learning. It’s not artificial intelligence but it’s trying to get you the information you need right before you think you needed it, or before you even realize you needed it. And that’s cool stuff.

It’s shifting from team members putting things into a document repository and just knowing it’s in there, to the point where content gets put in front of you because you’re going to need it in your work soon. And with the Office Graph and Delve, we’re starting to see some real evidence that’s going to be the way people are working in the future.

TA: If people are not in an office but around the world working on different projects, something like SharePoint can continue to grow and become more powerful. Do you agree with that?

Anderson: Absolutely. In almost all cases, even a small company like mine with two people – we’re a global company. I know that sounds ridiculous because we both live in Boston, but we work with customers all over the place. There’s no geographical barrier anymore, which is part of what you’re alluding to. People are out on the road more, and they need to stay tethered somehow to their home-base. But they also need to be able to work together with people who could be anywhere.

You might have a conference call with someone in Shanghai and then work on the document with somebody in Amsterdam. That’s a normal day in this global economy. Twenty or thirty years ago those were huge exceptions. SharePoint, which gives us a large surface area to enable remote and geographically dispersed work, is a win.

It lets us work asynchronously. We don’t have to be in a room having a meeting. Meetings are god-awful things anyway, but we don’t have to be in a room talking about something. We can do it asynchronously using technology and work when we need to work or when we’re able to work. I think it changes our lifestyle, it changes our incentives, it changes the culture of organization, and SharePoint’s been a big part of that.

TA: What common collaborative software challenges do you see?

Anderson: In many ways, I don’t see a lot of the challenges as technology challenges. They’re more business and cultural challenges. One of the things I’ve seen working with clients — I’ve been in consulting for decades now — is the aspiration is rarely reached. And very specifically with SharePoint, people bring it in and they want to change the way their company works, and they end up storing documents in SharePoint and that’s about it.

Getting from the execution to the promise of what they may have thought they wanted to do — or even not realized they could do — that’s one of the biggest challenges. The challenge is in enabling their organization to work differently. Some people talk about it as an adoption problem. SharePoint is in a lot of organizations, but a lot of people don’t use it. I don’t see it as an adoption problem, I see it as we’re not offering good enough capabilities to make people want to use it.

It’s really not about the technology per se. It’s about the implementation, it’s about the cultural stuff around it, it’s about incentives. It’s about helping people understand how they can be better at what they do and enjoy that. If they don’t enjoy it, they’re just going to dig their heels in and avoid it. So those are some of the biggest challenges, whether it’s cloud or on premises, or whether you’ve got to get a fatter pipe to get the data across. Those are all solvable problems. Those are technical problems.

The harder challenge is the soft stuff around the technology. People are softer than computers. They’re quirky and they don’t like change. Working on the things outside the technology can be even more important challenges to overcome.

This podcast was created and published by TechnologyAdvice. Interview conducted by Josh Bland.

Error Saving JavaScript Files to SharePoint Mapped Drive – Minor Version Overload

Can't save JavaScript file from Sublime Text

This is a first. I was editing away in Sublime Text today and suddenly I couldn’t save my code to the mapped S: drive I was using in SharePoint 2013. S: is for SharePoint. Get it?

The error message on the PC side wasn’t all that helpful, as one might expect. (Sorry for the crappy captured image.)

Can't save JavaScript file from Sublime Text

The files I’m editing are stored in:

http://[Server Name]/sites/[Site Collection Name]/_catalogs/masterpage/_[Client Name]

I’ve found that putting all of my project artifacts in that one location works well because I can easily copy and paste from one environment to another, as needed. I have a folder per artifact type, such as

Master Pages, html, js, css, Display Templates, Page Layouts

etc. I know someone is going to tell me what a horrible idea that is, but it’s not horrible if it works. And it works.

I’m editing within a virtual machine in VMWare Workstation running Windows 8.1 because I can’t connect to the client’s VPN with Windows 10. I originally was using a HyperV VM, but when I installed the production release of Windows 10, that went defunct on me, too. (Yeah, all that’s a mouthful.) Given all that, a restart of the VM seemed like a good idea.

No joy.

The next thing I thought of was that the disks might be full on the SQL server. I’ve seen that wreak all sorts of havoc in the past. But my admin buddy told me everything was humming along and healthy.

My next move was to download SharePoint Designer onto the VM and try editing the files there.

Aha! When I tried to save my edits, I got this message, which I had never seen before:

Minor version limit exceeded

Because my files are in the _catalogs/masterpage folder, we inherit versioning and Check In/Check Out. That’s a good thing because I can always restore an older version if something dreadful happens.

Clearly this has been a project with a lot of Ctrl-S action. It turns out that I had 510 minor versions on one file, and that’s the limit. Nada mas.

Too many minor versions

As soon as I published a major version (in this case, the magical 1.0), I was back up and running.

Yeah, I probably should clean out all those old versions at some point, but disk is cheap.

BTW, this is a really cool project where I’m using KnockoutJS, KO,mapping, fontawesome, jQuery, jQueryUI, jQuery.cookie, fullcalendar, MomentJS, and more. It gets us a pretty and highly useful veneer over basic SharePoint functionality to match the business needs as exactly as possible.

RequireJS Arrives in SharePoint Online Build 16.0.4230.1217 (Or Earlier?)

A JAVASCRIPT MODULE LOADEREver watchful – and talented – guy that he is, my friend Paul Tavares (@paul_tavares) pinged me the other day on Twitter with a question.

Hey. Question. On your O365, did you add RequireJS as a SOD? Noticed it was registered when I looked at the page code the other day.

Paul has a Site Collection in my tenant that we share for R&D and I certainly hadn’t done anything, so we went back and forth on it a bit.

If you do a View Source on a SharePoint Online page, you may well see this line:

<script type="text/javascript">RegisterSod("require.js", "https:\u002f\u002fcdn.sharepointonline.com\u002f16148\u002f_layouts\u002f15\u002f16.0.4230.1217\u002frequire.js");</script>

This tells me that my tenant is on build 16.0.4230.1217. It’s on First Release, so it may be ahead of the build you see in your own tenant.

The net-net of that line is to load RequireJS if it is needed using SharePoint’s SOD (Script On Demand) framework. It’s a little funny to me that this is happening, because RequireJS’s primary purpose in life is to help load script files when they are needed (among other things).

The good thing here is that if you want to use RequireJS in your applications – as I am regularly now – it’s already there for you by default – in SharePoint Online, at least. Paul and I have no idea when it showed up, but it’s a good thing. The Microsofties ought to let us know when they add such a useful library!