SharePointRoot

Today was my session at AUSPC – covering some developer level topics – within SharePoint 2013.

The AppModel is a new paradigm – with some changes in perspective – before embarking on a new project.

The agenda for my session was :

• Where have we come from ?
• The new AppModel (SP2013) + Why ?
• New thinking for developers
  • CSOM
  • REST
  • JSON
  • ODATA
  • OAUTH

The changes to application architecture bring some changes & challenges :

• Security – OAUTH
• Code – CSOM + REST
• Data – ODATA + JSON

There were a few demo’s covering each of these– with some code samples – I’ve uploaded these to SkyDrive.

Click here to download the slides/ZIP’s – or you can flip through the deck below :

The other very useful tip/site was the JSON viewer : http://jsonviewer.net

Please let me know if you enjoyed the session – and leave me any questions/comments – cheers !

Within SharePoint 2013, as there was with 2010 & 2007, there are a multitude of GUIDs everywhere – for Sites, Lists, Fields and so forth.

When using these inside a feature, like a custom Content Type and/or Field Ref, it can be a little tricky to determine the GUIDs.

There are a number of places you can grab the URL, and the LIST GUID is within the QueryString – but can be tricky if they are ‘encoded’.

I’ve found a very useful site that does a quick encode/decode – just need to paste in the text.

http://meyerweb.com/eric/tools/dencoder/

Another scenario is within SharePoint Designer, and needing to work with a DataViewWebPart – when you save this out to a .WEBPART, there is a “CDATA” section that is encoded.

Usually (in the past) I’ve had to change the &lt; into <, and the &gt; into >.

But – can now just past the whole slab of text into the “DENCODER”.

Thanks a lot Eric Meyer…!

I’ve been working on a project that deploys a SharePoint “Content Type” – and an associated Document Template – which works nicely…!

I’d changed the template file – and updated within Visual Studio – and then it wasn’t working anymore – what the ??

Failed to instantiate file "_cts/Outgoing Letter/OutgoingDocumentTemplate.docx" from module "Template Outgoing Letter": Source path "Features\xxxxx.Intranet.Correspondence_Content Types\Outgoing Letter\OutgoingDocumentTemplate.docx" not found.

It all looks OK in Visual Studio…>

And – the manifest file is referencing the file…>

The next step was to check the actual WSP…>

• Open Windows Explorer
• Navigate to the BIN folder – and find the WSP that Visual Studio created
• Change the name to CAB – and have a look inside

THAT’S when I noticed the file wasn’t included in the CAB file – and thus not in the WSP !

Aaaah – I know now…>

• Need to ensure that the actual file (DOCX) is included as an “ElementFile”

The default is “NoDeployment” – especially for a DOCX – not normally needed as part of the deployment.

Problem solved – phew !

Often, it’s necessary (or at least desirable) to change the field called “TITLE” into something else – after you create a SharePoint list or library.

We recently had a scenario where a user had changed it within the Item Content Type – oops !    The result was that anytime we created a new Custom List – it had a field called “ProjectNo” – instead of Title.

Simple answer would be to change the field BACK to be “Title”.

BUT – you CAN’T…!    The word “Title” is a reserved word – and so we’re stuck !

We had to crank out some PowerShell to fix the issue.

We basically have to set the “Title” (DisplayName) of the column – for the SPField :

$siteurl = “http://sharepointroot/”

$spsite = new-object Microsoft.SharePoint.SPSite($siteurl)

$spweb = $spsite.OpenWeb()

$spfield = $spweb.Fields.GetFieldByInternalName(“Title”)

$spfield.Title = “Title”

$spfield.Update()

That did the trick – and we are back to what it should be !

Hope that helps someone – it was an annoying thing for us – and now it’s FIXED.

The 4th Annual Australian SharePoint Conference will be held in Sydney on 10th & 11th April 2013 (and then Melbourne in June)

I’ve been accepted as a speaker for the Sydney conference – along with some amazing local & international speakers.

My session with be about SharePoint 2013 – and the new development model – AppModel, CSOM, REST and so on.

The topic brief is as follows >

Back to the Future with Client/Server Development

With the new SharePoint 2013 platform, the application development model changes the ways that developers will approach a solution.

This includes client-development concepts such as CSOM, REST, jQuery – AND – can also mean ASP.NET via custom apps hosted outside of SharePoint.

This session will show an overview of this approach, and some code samples / examples / demos.

As a keen workflow person, I was excited to install a new version of Nintex Workflow for SharePoint 2013.

The install instructions are very straight-forward :

• Run the installer
• Deploy solutions
• Activate Features
• Configure Database
• Import Licence file

** This hasn’t changed much from the 2010 version – it’s a quick 15-20 minute job – WITH coffee.

The new user interface is fairly ‘washed out’ – mainly due to all the WHITE within SharePoint.

I actually had a “WTF” moment – with this screen shot – wondering “what is the Commit column ??”.

Workflow Variables (2013) :

It makes more sense when you look at the “OLD” screen – in SharePoint 2010 :

Workflow Variables (2010) :

Aaaah – it’s part of the RIBBON – not the LIST.     *facepalm*

===================================================

I had another issue when I first installed Nintex 2013 – with this error :

The file ‘/_layouts/15/Seattle.master’ does not exist.

It turns out to be that I’m using the SharePoint 2013 “Preview” – not RTM version.

The default Master Page has been renamed – and Nintex 2013 is looking for “seattle.master”.

As a simple hack – NOT SUPPORTED (use at own risk) – I did the following :

• Opened Windows Explorer
• Change to C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS
• Take a copy of v15.master 
• Name the new copied file as seattle.master

As stated – THIS IS A DODGY HACK – and I’m only doing on a DEV/PLAY virtual machine – using ‘SharePoint 2013 Preview’.

Good luck with the new Nintex Workflow 2013 – it looking very much the same as Nintex Workflow 2010 – but for SharePoint 2013.

Recently, we had a client with a requirement to have a new SharePoint Team Site created, and then have a Nintex Workflow automatically provisioned.

There are a few ways to do this – via Nintex itself (!) – or using C# code.

The scenario I was dealing with was :

• Custom/3rd-Party CRM system
• On creation of new customer, need to provision a ‘client site’ in SharePoint
• Deploy the NWF as an artifact – we deployed to _LAYOUTS/Company/MyWF.NWF
• Created a Web Service that did the SharePoint magic
• A few lines of code to provision the workflow

Here’s what you need to do – within a Visual Studio project :

• Add a reference to the Nintex Workflow “web service”
• /_vti_bin/nintexworkflow/workflow.asmx
• Can then reference the class/project within C# code (NintexWorkflowWS)
• Read in the contents of the NWF (full XML) – and push/deploy to a list/library

The code steps are as follows…

(1) Add a reference to the Web Service

** NB. uses an SPWeb context – created a few steps earlier

var webServiceUrl = currentWeb.Url;

webServiceUrl += "_vti_bin/nintexworkflow/workflow.asmx";

NintexWorkflowWS wsNW = new NintexWorkflowWS();

wsNW.Url = webServiceUrl;

wsNW.UseDefaultCredentials = true;

(2) Get the contents of the Nintex Workflow (NWF)

var pathNWF = “\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\Company\MyWF.nwf”

//get the Program Files folder

var fileName = Environment.GetFolderPath(Environment.SpecialFolder.CommonProgramFiles) + pathNWF;

var contentsNWF = System.IO.File.ReadAllText(fileName);

(3) Deploy the NWF onto the list/library

//call the method to publish the workflow
wsNW.PublishFromNWFXml(nwf, “MyDocLibrary”, “Workflow Title”, true);

============================================

That’s essentially it.     You just have to call the above method – and it will deploy your workflow.

There’s a bunch of methods within the Nintex Web Service API – the above example uses this method (WSDL) :

There are a bunch of other methods – including “ExportWorkflow” – meaning that you could create a utility/program that cycles through all SPWeb’s – and SPList’s – and then exports to a file.   

(I haven’t tried it – I might have to do that next….)

Hope that helps someone – happy Nintex’ing…!