SPSCBR - REST Service and jQuery AJAX

Climbed out of bed at 4am and drove myself and colleague Jumpei on a laughter-filled trip down to Canberra, where we had lots of fun at the SharePoint Saturday Canberra event.

Our best joke along the drive was debating whether Lake George is a real lake.  Our most scary moment was when the car wouldn't start back up after we took a 10min powernap.

As promised, my slide deck and a zip file of the VS.NET solution that was shown. 

While the concepts are still fresh you should build a rest service and see how this all works for you.  Enjoy :-)

Special thanks to Ishai Sagi who saved the day with an innovative 2-laptop remote-each other and project via SVG port.

Ran out of time, I couldn't cover in more detail...

• How to pass multiple parameters to REST, via a POST operation - the example is in my script and Rest service, but commented out follow that pattern.
• jQuery AJAX calls are asynchronous, you can fire 4 requests at the same time and they will run in parallel.  Number of asynchronous calls depends on browser but 4 is a common-minimum.
• Debugging javascript tips
• Packaging CSS/JS files in a sandbox solution tips
• Some consideration and discussions around sandbox solution webpart and quota

Files

• https://static1.squarespace.com/static/5527bff2e4b0b430660b0d10/5527c30de4b030eeeef09715/5527c30fe4b030eeeef0a042/1316867614343/SharePoint+REST+and+jQuery1.pptx
• https://static1.squarespace.com/static/5527bff2e4b0b430660b0d10/5527c30de4b030eeeef09715/5527c30fe4b030eeeef0a043/1316868647487/SPGSvcWp.zip

Related Links

• http://blogs.msdn.com/b/sharepointdev/archive/2011/02/22/calling-a-wcf-service-using-jquery-in-sharepoint.aspx
• http://www.wictorwilen.se/Post/Calling-a-WCF-Service-using-jQuery-in-SharePoint-the-correct-way.aspx

For 2007, unfortunately you can't easily do REST, but a lot of the SOAP service wrappers are done by awesome people so you don't have to do it yourself.  Thank Marc.

• http://spservices.codeplex.com/

My Geek Origin story, creativity meets engineering

It all started with…

LEGO

My brother and I grew up around LEGO, dad says that’s because he wanted to play lots of LEGO but couldn’t afford it when he was a kid, so he made sure we had them.  I think LEGO is unique in that as kids, we had to build with our hands what we wanted: MASK, VOLTRON, TRANSFORMERS, Knight Rider’s KITT and its mobile truck, ROBOCOP and ED-209, various Star Wars vehicles… etc.  You see something you wanted on TV or cartoons, you map it out in your mind how you’d build it, and then you build it, with your limited bricks.

PAPER and PENCIL

Mum was the one that gave us paper and pencil, which eventually led us to paper craft.  What we couldn’t do with LEGO, we improvised with our own sketches, scissors and glue, and lots of sticky tape.  With paper we drew secret bases that could withstand a full scale alien invasion, and made worlds, futuristic cities with busy interlocking highways. 

The best part about working with paper was the near-limitless freedom in your creations.  The drawback was how fragile paper was.  You can’t really “play” with the paper models you’ve made.  Yes it’s an awesome model, but god-forbid showing it to your 10 year old nephew.

MUD and LPC

In university, while learning all the wonders of assembly, operating systems and every known Artificial Intelligence method known to man, I fell in love creating MUDs.  A Multi-User-Dungeon is essentially a telnet interface to a world described in text. 

Like a great book, the environments, characters that you interact with are completely within your imagination.  Banish the thought if you think creative writing is easy, read this, and then try to write your entire city without duplication room descriptions.  While modern MMO reuse assets such as an inn (or a cave layout) over and over, we actually have high standards and reusing assets was a sign of sloppy workmanship that’d be rejected during peer review.

The language of choice for me was LPC, an object-oriented variant of C that represented everything in the world as objects.

A person login to this world is given a player object, and moves about in the world via interconnected room (objects).  Each room has X and Y coordinates, so you can work out where that person is in relation to someone else at any point in time.  Hey, we’ve just invented a GPS system.

Players have different races, and whether through racial ability or via magical or technological means, they are able to fly.  To implement flight we gave everyone a Z coordinate, and modified the world so that it constantly applies gravity to pull everyone down to the ground level.  Hey we’ve just invented gravity.

I was watching the animated series Gargoyles and loved how the creatures can’t fly, but can glide once they climbed enough height and leap off, say a clock tower.  Added soaring and swopping – hey, we’ve just invented aerodynamics and gliding.

Computers are the ultimate tool for a creative mind – you are only limited by your imagination, and not by the bricks that you don’t have.  In my world, when I say there will be something, it comes into being.

This is my Geek Origin story.  

:-)

SharePoint 2010 WCF HelloWorld Service and InfoPath

Was looking for a quick tutorial for creating a Custom WCF Service for SharePoint 2010.  For some reason couldn’t find one, so I sat down and try it out and decide to write out a few simple steps.

Use CKSDev

http://cksdev.codeplex.com/ version 1.2 included new Visual Studio Item templates for creating WCF services and makes this whole process a breeze.  Thanks to Charlie Holland’s hardwork.

Build Solution

1. Create New Blank VS.NET SharePoint Solution “HelloWorldWCF”
2. WCF Service has to be a Farm Solution.
3. Add New Item, and select WCF Service (CKSDev)
   
4. The created Service includes a stub method that returns a string.
   
   [BasicHttpBindingServiceMetadataExchangeEndpoint]
   [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
   public class HelloWorldWCFService : IHelloWorldWCFService
   {
       // To test this service, use the Visual Studio WCF Test client
       // set the endpoint to http://<Your server name>/_vti_bin/HelloWorldWCF/HelloWorldWCFService.svc/mex
       public string HelloWorld()
       {
           return "Hello World from WCF and SharePoint 2010";
       }
   }
   
5. Compile solution and Deploy to server

Verify Service

1. The service is deployed to /_vti_bin/HelloWorldWCF/HelloWorldWCFService.svc
2. The endpoint is at http://server/_vti_bin/HelloWorldWCF/HelloWorldWCFService.svc/mex
3. Browse it with your browser you should see:

Connect Via InfoPath

1. Create an External Connection
2. Select SOAP Service, use the /mex endpoint
3. You may be asked to authenticate with the service
4. Select the method
   
   
   
5. Cache, and Retrieve when form load as necessary.
   
   
   
6. Bind the result of the web service to a textbox
   
   

Test in InfoPath

1. Preview the InfoPath form
   
   

InfoPath - external data from SharePoint List error

I had this error "The operation could not be completed" when trying to connect to a SharePoint List as an external data connection in InfoPath today.

Show Details just says "Unable to connect to the SharePoint site."

Figure: The message box really doesn't tell you anything.

Turned out, I was testing with a new managed path on http://server/sites/TravelFunds/  But the web application did not have a site at the root path.  So the quick fix was to create a new team site (blank site might work too) at the root path http://server/ and then come back to InfoPath, and http://server/sites/TravelFunds/ will now work as expected.

This was one of many posts that I read regarding similar problems, and the one that actually applied to me.  http://vspug.com/ssa/2010/03/15/infopath-2010-cannot-connect-to-sharepoint-2010/

Silverlight + SharePoint 2010 - did you just deploy customizations to SharePoint via the document upload?

Just finished my presentation earlier tonight in SDDN regarding Silverlight and SharePoint.  I had some initial reservations whether true Silverlight people want to even know about SharePoint, but I was pretty blown away by their feedback, interesting questions, and I think they found the session insightful. 

This is good :-)

I think I delivered my first "shock and awe" when people first saw me deploy to SharePoint.  I finished building my XAP file, and then browsed over to SharePoint, selected my Shared Documents library, clicked upload files (and for additional effect, used the drag & drop upload facility in SharePoint 2010).  Before you knew it, I had the XAP file in my document library, and I'm adding a Silverlight web part and configuring the XAP URL.

For comedy effect, I was pretending as if this is business as usual.

You guys were too good and picked it up right away - it was just too magical.  Hold on a second!  Did you just by-passed all the system admins and deployed customization code to your SharePoint server? 

The absolutely correct answer is, no, not really, I just deployed customizations to the SharePoint UI, an additional tool if you will, that will help you do your job easier.  Technically, it is not running on the server.  Technically, you can run a separate .NET exe tool to work against SharePoint via the same web services and it can do similar things.

Depending who you are, this might be too magical, and thus, way too dangerous.  I think the thought falls into two categories, and I'm hoping by discussing this, we can compare some thoughts on the PROs and CONs of deploying Silverlight to SharePoint.

PRO

• Bypass system admins
• Can rapidly develop and test.  Can rapidly update new version
• Can create simple tools and install them on SharePoint quickly
• Deploy to SharePoint online

CON

• Unsafe code, is still unsafe
• I can deploy a Silverlight webpart that will take my boss' permissions and copy sensitive data to a public location

I suggest a compromised workaround for Production SharePoint

• Block upload of *.XAP files from Central Administration | Web Applications
• Allow sandbox solutions - which can install XAP files, via the Solutions Gallery
• Rely only on in-house developed solutions, or solutions purchased through a trusted and verified source such as Office.com, Bamboo, or ProdUShare.

At the end of the day, I believe that yes - tools can be used for evil, but for many many businesses, the need for tools to help them to be more efficient, and the need for a stable server that doesn't die all the time, far out-weights the risks of allowing Silverlight solutions.

• A badly behaving Silverlight crashes one browser, affecting one user
• A badly behaving web page customization crashes the App Pool, and affects many users

In terms of customizing SharePoint to rapidly meet business needs and still maintain high levels of server availability, you can't ignore or brush off Silverlight + SharePoint possibilities.

I hope the market will agree with me, and I think as long as you don't use your tools for evil, you can help a lot of people with what you can build.

I'm still so excited.