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.

Create a Subsite in SharePoint 2013 Using REST Calls

Today I was working on what seemed like a simple little task. I wanted to create a subsite using a REST call in SharePoint 2013. I’m not working in an “app” per se – this is for SharePoint 2013 on premises, and I want to do the subsite creation directly from a call in a plain old aspx page.

Unfortunately, there isn’t a clear example out there, at least not that I could find. It seems as though everyone has simply copied the example from this page on MSDN and quotes it verbatim. (Look for the “Creating a site with REST” example.) Unfortunately, I couldn’t get that example to work for me. Most of the examples are also focused on creating subsites in a workflow rather than directly.

I knew I’d need to have a fresh copy of the Form Digest for the request to work. There’s a great article from Wictor Wilén (@wictor) called SharePoint 2013: How to refresh the Request Digest value in JavaScript that explains several different ways to get this token. You must have the token in order for SharePoint to be willing to accept your requests to do a write to anything; it’s a part of the security features. In the page where I am working, we’re building a full application on top of SharePoint, but without using the out of the box SharePoint UI. Because of this, things like the hidden variable which usually holds the Form Digest token aren’t available in our pages. By making a quick call to the ContextInfo REST API, I can grab the Form Digest token pretty painlessly using the second method from Wictor’s post.

The breakthrough came due to some great suggestions from Matt Gibson (@Gibz) and Rob Windsor (@robwindsor) on Twitter. (You’ve got to love the #SPHelp hashtag!) Both Matt and Rob were sure this should work and gave me tips. The winning idea came from Rob. There’s a comment at the bottom of the MSDN page referenced above that shows slightly different JSON data in the REST call payload, and that did it. Bottom line, the documentation doesn’t seem to be adequate or correct in this case. At the very least, I couldn’t find it if it’s out there.

Here’s the code I ended up with. I’ve built it as a jQuery function for reusability.

// Create a new subsite
$.fn.Site.create = function(options) {

  var opt = $.extend({}, {
    siteUrl: null,
    siteName: null,
    siteDescription: "",
    siteTemplate: "sts",
    uniquePermissions: false
  }, $.fn.ProjectName.defaults, options);

  // Because we don't have the hidden __REQUESTDIGEST variable, we need to ask the server for the FormDigestValue
  var __REQUESTDIGEST;
  var rootUrl = location.protocol + "//" + location.host;

  var contextInfoPromise = $.ajax({
    url: rootUrl + "/_api/contextinfo",
    method: "POST",
    headers: {
      "Accept": "application/json; odata=verbose"
    },
    success: function(data) {
      __REQUESTDIGEST = data.d.GetContextWebInformation.FormDigestValue;
    },
    error: function(data, errorCode, errorMessage) {
      alert(errorMessage);
    }
  });

  // Once we have the form digest value, we can create the subsite
  $.when(contextInfoPromise).done(function() {
    $.ajax({
      url: rootUrl + "/_api/web/webinfos/add",
      type: "POST",
      headers: {
        "accept": "application/json;odata=verbose",
        "content-type": "application/json;odata=verbose",
        "X-RequestDigest": __REQUESTDIGEST
      },
      data: JSON.stringify({
        'parameters': {
          '__metadata': {
            'type': 'SP.WebInfoCreationInformation'
          },
          'Url': opt.siteUrl,
          'Title': opt.siteName,
          'Description': opt.siteDescription,
          'Language': 1033,
          'WebTemplate': opt.siteTemplate,
          'UseUniquePermissions': opt.uniquePermissions
        }
      })
    });
  });

}; // End $.fn.Site.create

With the function set up this way, I can call it something like this:

$().ProjectName.Site.create({
  siteUrl: "mysite",
  siteName: "My Site's Name",
  siteDescription: "This is the description that explains how to use this site.",
  siteTemplate: "sts",
  uniquePermissions: false
});

I like to publish stuff like this when I figure it out. We’re all in this together and we shouldn’t need to figure things out more than once.

Thanks Matt and Rob!

SPServices Stories #21 – Redirect If User Clicked a Button Previously

Introduction

teylynIngeborg Hawighorst (@IngeborgNZ) is a long-time SPServices user who has come up with any number of intriguing uses for the library. I’d recommend her blog anytime if you’d like to learn about interesting things you can do with SharePoint, but even more so if Excel is your bag. Ingeborg has been an Excel MVP for years running (see her profile on the MVP site). Some of the best solutions using SPServices come out of discussions in various SharePoint-oriented forums. In this case, Ingeborg spotted some suggestions from Eric Alexander (@ejaya2 aka PirateEric) and decided to build it out. Without further ado, here is Ingoborg’s article, reposted from her blog cheers, teylyn.

Redirect If User Clicked a Button Previously

I just came across this question in sharepoint.stackexchange.com. When a user visits a SharePoint site, they are presented with a splash screen and need to accept the policy before they can proceed. Upon subsequent visits, the splash screen does not show, because SharePoint will remember the  user. PirateEric outlined a possible solution: Use a SharePoint list to save the user name when the button is clicked. When the page loads, look up the user in the list. If they already exist, redirect the page, if not, show the splash page with the button to accept the policy. If the policy changes and users need to be made aware of that, simply remove all items in the list that tracks the users. All this can be done with jQuery and web services. That intrigued me and I had a go at actually building this, using Marc Anderson’s SPServices.

How to set it up

Create a SharePoint custom list with two fields, Title and UserName. The former is the out of the box field, the latter is a simple text field. Create two pages, the Splash page with the button and the page that is the desired destination page for all visitors. In my sample these are called Splash.aspx and MainContent.aspx On the Splash page the code that you can see below will be loaded before any other web part. If you use a Content Editor Web Part to load the code with a content link, make sure that it’s the first web part on the page. In many cases, JavaScript and jQuery will be placed in the last web part of the page and run after the DOM has loaded. But in this case this would mean that the Splash page appears briefly, even if it is followed by a redirect to a different page. The Splash page provides the policy (or terms and conditions) that the user must accept, and a link or a button that the user can click to accept. This link or button must then trigger a JavaScript function. That is very easy to do. I used a button and put the html straight into a CEWP like this:

<button onclick="PolicyButtonClick()" type="submit">
   I accept the policy
</button>

So the user clicks the button and the JavaScript function PolicyButtonClick() will run. This function can be found in the code below. First, the jQuery library and the SPServices library are loaded. Then the user name of the current user is retrieved with the SPServices call using SPGetCurrentUser. It returns a text string in the format DOMAIN\Account.  Next, the SPServices call uses the GetListItem. In the call, a CAML query is constructed that will return only list items where the column UserName equals the current user.  The items returned by that query are then counted. Since the user account is a unique value, we can safely assume that the query will either return one result or no result at all. If the query returned an item, this means that the user has previously accepted the policy and the script will redirect to the MainContent.aspx page.  If the query did not return anything, the current page will continue to be displayed. When the user clicks the button to accept the policy,  the user name is written into a variable. Then the SPServices operation to UpdateListItem is called and will create a new item in the list “PolicyAccepted”, storing the previously established account name in the column UserName. Then the MainContent.aspx page is loaded. The next time the user opens the Splash page, their account name will be found in the PolicyAccepted list and they will not see the Splash page again, unless the entry in the list is deleted. Here is the complete script:

<script type="text/javascript" src="/path/jquery-1.10.2.min.js" language="javascript"></script><script type="text/javascript" src="/path/jquery.SPServices-2013.02a.min.js" language="javascript"></script><script type="text/javascript">// <![CDATA[
// start the code even before the DOM is loaded, so not waiting for document ready
//$(document).ready( function() {
// get the user name
 var userName= getUserName();
// find the user name in the list
 var userAccepted = matchUserName(userName);
 if (userAccepted == 1 )
 {
 // redirecting page
 window.location.replace("http://path/Documents/MainContent.aspx");
 }
//});

function getUserName() {
 var thisUserAccount= $().SPServices.SPGetCurrentUser({
 fieldName: "Name",
 debug: false
 });
 return(thisUserAccount);
}

function createNewItem(theTitle, theUser) {
 $().SPServices({
 operation: "UpdateListItems",
 async: false,
 batchCmd: "New",
 listName: "PolicyAccepted",
 valuepairs: [["Title", theTitle], ["UserName", theUser]],
 completefunc: function(xData, Status) {
 }
 });
}

function matchUserName(userName) {
 var queryText = "<Query><Where><Eq><FieldRef Name='UserName'/><Value Type='Text'>" + userName + "</Value></Eq></Where></Query>";
 $().SPServices({
 operation: "GetListItems",
 listName: "PolicyAccepted",
 async: false,
 CAMLQuery: queryText,
 completefunc: function (xData, status) {
 itemCount = $(xData.responseXML.xml).find("rs\\:data, data").attr("ItemCount");
 }
 });
 return(itemCount);
}

function PolicyButtonClick() {
 var userName= getUserName();
 var theTitle= "Accepted";
 createNewItem(theTitle, userName);
 window.location.href = "http://path/Documents/MainContent.aspx";
}
// ]]></script>

The MOSS Show SharePoint Podcast: Episode 87 – Talking JavaScript with Marc Anderson

The MOSS ShowBack in late January, I sat down – in the virtual sense, as usual – with Hilton Giesenow (@hiltongiesenow or the slightly more active @TheMossShow) to have a chat about JavaScript for his MOSS Show SharePoint Podcast. At the time, we were in the throes of trying to figure out what had happened on Office365 with some breaking DOM changes. Breaking for us JavaScript folks, anyway. We covered a number of topics like improving the user experience in SharePoint, what’s been going on with JavaScript over the years in the SharePoint community, and more.

From Hilton’s intro to Episode 87 – Talking JavaScript with Marc Anderson:

The entire web development world seems to have had a love-hate-love-hate relationship with JavaScript over the many years of its existence, and it’s no different in the SharePoint world, albeit a few years behind in many cases. In this episode we speak with many-year industry veteran and long time SharePointer Marc Anderson about his experiences with JavaScript and SharePoint over the years, his wildly successful SPServices library, Single-Page Applications (SPAs) and lots more.

Head on over to Episode 87 – Talking JavaScript with Marc Anderson and have a listen.

2014-03-18_22-53-36

SharePoint Conference 2014 (#SPC14) Wrap Up

SharePoint Conference 2014; connect, reimagine, transform

Wow. Whew. The 2014 episode of the Microsoft SharePoint Conference aka #SPC14 is a wrap. What an amazing experience.

It seems obligatory for anyone who has more than two eyeballs on their blog to do a wrap up post after a conference like this, and I didn’t want to be the exception. So here you go…

This was what used to be called a “non-release” year. That meant that there wasn’t a new, three-year epic release coming out with the attendant marketing push from Microsoft. Now that we are living in the bold new world of Office365 with its nearly weekly updates, there’s really no such thing as a “release year” anymore. Sure, we’ve been promised a new on premises release in 2015, but odds are that it will contain the incremental improvements that we’ve been seeing on Office365 – as we recently saw with the Service Pack 1 release – and some shiny new things, but the SharePoint Product Group is all about continuous improvement now. There will still be splashes, but they won’t be as big. (Joel Oleson (@joeloleson) did a post a while back that explains how this all is going to work in great detail, if you’d like to understand more about it.)

image The keynote was a big one. Former US President Bill Clinton was the featured speaker. While he didn’t wow me with his messages, it was impressive (and no doubt expensive) for Microsoft to have him speak. From the Microsoft angle we heard from Jared Spatero (@jared_spatero – the emcee of sorts), Jeff Teper (@jeffteper), Julia White (@julwhite), Arpan Shah (@arpanshah), and Michal Gideoni.

While there were fewer “big splash” announcements, the things that were announced may prove to be impressive enhancements to the SharePoint platform once they are ready for prime time.

One big theme I was happy to see throughout the developer-focused sessions: embracing JavaScript. It’s wonderful to see the community embracing JavaScript as never before. What a difference a little time passing makes. Just a few years ago, my forays into the JavaScript world with SPServices and other methods were considered child’s play. Now many of those same naysayers have embraced the technology and new, highly useful development patterns for SharePoint pop up all the time. (Props specifically to Scot Hillier (@scothillier)here. I’ll go to one of his sessions every time I have the opportunity.)

Perhaps this change of heart is due to the splendid frameworks which have been evolving over the last few years. This isn’t your father’s JavaScript. Development approaches are evolving rapidly, with frameworks rising and falling in popularity.

Perhaps the most important session I attended from a strategic standpoint was SPC348 – Update on InfoPath and SharePoint Forms. Greg Lindhorst from the Access team and Sonya Koptyev – my new pal on the Product Group team; bless her if she’s been assigned to keep me in line – led the session.The content was extremely important to many of us in the SharePoint community. However, how the session was set up and went is even more important. Rather than simply demoing something shiny with a high wow factor and leaving it at that, the session was truly interactive.

There was an acknowledgement that progress isn’t always easy. I loved the up-front quote from Charles Kettering:

2014-03-09 19-23 page #0Greg and Sonya showed us a real timeline, with rough dates and planned enhancements.

Streamlined technical product roadmap

Streamlined technical product roadmap

As you can see, there are four planned areas of focus:

  • Excel Surveys
  • List Forms (FoSL, or Forms on SharePoint Lists)
  • Structured Documents – Maybe this will be where Word plays a role
  • App Forms – aka Access Services

Note the timeframes in the slide. (Is this really Microsoft talking?) They aren’t carved in stone, but they ought to be directionally correct. Behind those timelines, though, was a true request for all of us to participate in the journey. The Product Group doesn’t always have all the answers, and they are saying that out loud now. They want our feedback and wish list items and have set up a new User Voice to capture them at

http://officeforms.uservoice.com

Don’t think this is just some exercise to placate us by letting us make suggestions we’ll never see. The User Voice platform is already driving enhancements making it into Office365 and seems to be the main feedback mechanisms where you can make your needs known.

The reason I think that SPC348 – Update on InfoPath and SharePoint Forms was so important wasn’t about the content. It was about *how* the content was presented. To me, this is the Microsoft I’ve been trying to find: open, honest, and wanting to collaborate to attain a higher goal. That’s what I always wanted to do when I became an MVP, and it looks like they are finally catching up to me. I’m going to be all over Sonya if this Great New Attitude flags. I’ve warned her. (For an excellent, detailed write up on this session, see Nik Patel’s (@nikxpatel) post Future of InfoPath – SPC14 Notes from Office and SharePoint Forms Roadmap Update.)

Oh, and the conference was in Las Vegas, so there was some shenanigans. I managed to come out reasonably unscathed on the gambling front – merely a flesh wound! – and the parties were tadifa. From the opening attendee reception to Club SPC to the Attendee Party at the Las Vegas Motor Speeedway, there was no lack of ways for attendees to entertain themselves. Of course, this is the biggest SharePoint conference in the world (at least so far) and it’s the only time so many of us in the community manage to get together to cause trouble. This was social business at its finest.

I’m including a few of the photos I took during the conference in the slideshow below. Enjoy!