SharePoint Saturday Sydney 2014

November 29, 2014 was a great day for SharePoint Saturday.

I presented "Develop and Build Workflow Apps in SP2013. Wait, Workflow Apps?" - which is a session that covers lots of the new things you can build with SharePoint 2013 workflows using primarily Visual Studio 2013.  These work on premises and in Office 365.

The REST end points opens up SharePoint

I still think my transition along with exploring new activity and suddenly jumping into REST was tough.  I need to work on how to introduce that point.

The key point stands.  As a developer, or even a power user using Workflows - the REST API opens SharePoint completely to me.  I can use it to create lists, site columns or assign permission groups.  The trouble is that creating the JSON packet to talk to SharePoint end point is quite hard.  Which is why the need (and the ability) to package existing series of Actions into a reusable Custom Activity is a big deal.

Confusion over Workflow Custom Activity

There was actually a lot of confusion over the artefact "Custom Activity".  In 2010, these were sandbox or coded solutions.  In 2013, Custom Activity is completely declarative.  It is a way for you to save a series of workflow actions into a reusable piece of functionality that you can use over and over.  In my demo project I have about 10 custom activities.

Downloads

• WorkflowApps-spssyd.pptx
• WFApp-MelbCup.zip

News Update

We announced at the beginning and the end of SharePoint Saturday 2014 that this would be the last SharePoint Saturday in Australia.  As Microsoft and Industry trends towards Office 365, we will move with that trend.

From 2015 onwards, Office 365 Saturday will return, bigger and with more coverage of Office and SharePoint Online, but also address your On Premises needs.

Hope you have a great holidays and see you soon in 2015!

Copying SP2013 Workflow XAML files between VSNET projects

The Error

If you copy Workflow or Workflow Custom Activity objects between your SharePoint VSNET projects, sometimes you would see these errors:

Project file must include the .NET Framework assembly 'WindowsBase, PresentationCore' in the reference list.

Project file must include the .NET Framework assembly 'WindowsBase' in the reference list.

Why

This is actually a result of VSNET getting quite confused.  It thinks your workflow.xaml files are WPF XAML files.

The Build Action "Page" is special and tells VSNET that this is a WPF Page object.  Which then triggers the compiler requirement that the necessary libraries are not included in the project.

This can happen when you copy Workflow or Workflow Custom Activity files from one project to another, then use VSNET to "Include in Project"

The Fix

Is to tell VSNET the correct Build Action for an Workflow XAML file:

The correct Build Action for Workflow XAML objects is XamlAppDef

Go through your project and check every XAML file.

Result

Happy again.

SPS Canberra 2014 - Building SharePoint 2013 Workflows Apps (post-show notes)

On Friday afternoon I drove down to Canberra for SharePoint Saturday.  It really was a wonderful afternoon.

Building SharePoint 2013 Workflow Apps

My talk focused on Building SharePoint 2013 Workflow Apps.  That is, practical examples of what you can build with Workflow Manager for both Office 365 and SharePoint 2013.  Lots of individual examples, Workflow Custom Activities, and a full SharePoint App with Forms, Lists and Workflows (and I found this humourous: no C# or JavaScript).

Questions

A question was asked about parallel tasks, the short-cut logic and whether it could be done for approval workflows that required (3 out of 5) votes to progress.  While I think that would be possible, the Out Of Box Composite Task covers that scenario directly so you don't need to build this via a tricky Parallel Task.  Much applause for Microsoft.

Why is REST the best thing in the slide

I didn't stress this point enough.

Traditionally, when MS adds new services or methods, we need to wait for MS (hahaha) or ask someone to build a custom activity to use them in the workflow.

Now, in SP2013 - REST is first class.  That means any new service gets a REST end point.  Want to work with Delve?  There's a REST API for that.  That means, automatically that as soon as the API is available, you can use it in your Workflow.

That means, Workflow is also first class.

That is why this is the best thing in SP2013 Workflows. 

Demo Fail

I was not able to add the Artezio Workflow Custom Activities in SharePoint Designer 2013.

https://sp2013workflowactivities.codeplex.com/

This is because Workflow Custom Activities can be packaged in a solution as part of "App" or "Sandbox Solution"

The activities that I had in my demo site were packaged as App.  That means they could be used in my App within the App Web, but not directly in the Host Web by SharePoint Designer.

If you are using SharePoint Designer and want to use the Workflow Custom Activities, you need to grab the sandbox solution and activate that on your site first separately.

The codeplex project has both types of solution.

https://sp2013workflowactivities.codeplex.com/releases

Integrated Workflow Apps

Because of time, I did not cover this point.  Integrated Workflow Apps is a variation of the Workflow App for SharePoint.  The distinction being that the workflows defined in the App (which then runs in the AppWeb) is available for Workflow Associations in the Host Web (instead of the App Web).

This is very useful if you want to build complex Approval workflows and have the logic run in the App Web, but still allow users to associate that workflow to their libraries in their own sites.

At the moment, Integrated Workflow Apps can only be created via editing the XML in the solution package.  VSNET support will be updated in the future to provide a UI for this type of set up.

The Sample Project is not completed

There are still plenty to do to complete the workflows, but the key points are there - flow-chart, parallel actions, scopes, workflow activity, permissions, app step.

Downloads

• PowerPoint presentation
• project zip file

Setting up Azure Service Bus for debugging SharePoint 2013 Workflows

If you follow the instructions on http://blogs.msdn.com/b/officeapps/archive/2013/03/21/update-to-debugging-sharepoint-2013-remote-events-using-visual-studio-2012.aspx to set up an Azure Service Bus to debug your SharePoint 2013 you need to take careful note of this starting paragraph.

Update 9/19/2014: Please note Microsoft Azure Service Bus now supports two types of connection strings: SAS and ACS. For remote event debugging via Azure Service Bus, only ACS connection string is currently supported as shown below. Follow the instructions in Service Bus Authentication and Authorization to get an ACS connection string for any new Service Bus namespace created after August 2014.

I skim read, so I missed it, twice.  And then spent a lot of time digging through why my brand new Azure Service Bus (SAS) doesn't work with SharePoint 2013's debugging.

To redeem myself and me ranting at other people (for my own fault of ... not-reading).  I present the following:

The newbie picture guide on how to set up Azure Service Bus for Office 365

Go here: http://azure.microsoft.com/en-us/downloads/

Scroll down and install the command line tools.  I went with the Windows PowerShell option on the left.

The download will run the Web Platform Installer, which then lets you install MS Azure PowerShell

Installed, it is here.

Run two PowerShell commands.

• Add-AzureAccount will open a browser window, allowing you to sign in with your Office 365 account and download a policy file
• New-AzureSBNamespace -name <name> -location '<region>' -CreateACSNamespace $true

The Service Bus can be managed via the web interface - they just can't be created.

It appears as type "Mixed"

Set Up VS.NET

This will now give you an old style ACS connection string that you can use in VS.NET's project properties.

And here is VS.NET happily debugging Office 365 workflow again.

For completeness: this is the Wrong Way, if you use the Azure Portal

Looks different.

ACS Connection String looks like this:

• Endpoint=sb://debug-jl.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=<code>=

SAS Connection String looks like this:

• Endpoint=sb://debug-bad.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=<code>=

The SAS Connection String does not currently work with VS.NET

Summary

• Download Azure PowerShell (or Azure CLI via npm) - they are two different things, don't mix them.
• Run two PowerShell commands to create the old Azure Service Bus (with ACS)
• Thank Greg Hurlman ‏@justcallme98 and ☞ Scott Hoag ☜ ‏@ciphertxt for reaching out and assisting me with my bad Azure skills.
• Apologies to people that had to read my uneducated rant.  I retract all of it.

Demystifying SP2013 Workflow AppStep

A SharePoint 2013 workflow essentially can run as two different accounts.  The current user, or AppStep (which runs the action as the Workflow App account).

You will need to activate this feature.

But this is not where these notes end.

SP2013 AppStep is not the same as SP2010 Impersonation Step

In SP2010, when you use impersonation step, you gain additional activities, and because SP2010 doesn't have the concept of different permissions impersonations - essentially those activities lets you perform the action with elevated privileges in the code.

In SP2013, everything is an App.  That includes workflows.  So, when you activate this feature, you gain:

• Ability to have App Step in your workflow designer (SharePoint Designer or Visual Studio .NET)
• App Step runs the actions inside with App Permissions, and this is important: the App only has Read and Write.  It does not have full control or manage or any other fancy pants abilities.
• When App Step updates the list item, you get a nice message on the list item that says Updated by Workflow on behalf of (user).

The power of HttpSend

You can of course call all the fancy new SP2013 REST API in your workflow.  http://msdn.microsoft.com/en-us/library/office/dn268594(v=office.15).aspx  - This gives your workflow a lot of power.  You can do this either as the current user or in the App account context.

Fabian and Chris has documented a number of really great articles on this.

• http://www.fabiangwilliams.com/2013/09/06/help-unable-to-create-list-using-sharepoint-2013-rest-api-in-spd2013/
• http://blogs.architectingconnectedsystems.com/blogs/cjg/archive/2013/09/07/Configure-Workflow-Manager-to-create-lists.aspx

Andrew Connell also has a great segment on Plural Sight on REST services.

• http://www.pluralsight.com/training/Courses/TableOfContents/sharepoint-2013-workflow-web-services

There are ways to increase that permission level

If you are on-premises, there is a powershell command to grant the Workflow App account additional permissions.

Set-SPAppPrincipalPermission

• http://blogs.architectingconnectedsystems.com/blogs/cjg/archive/2013/09/07/Configure-Workflow-Manager-to-create-lists.aspx

If you are on Office 365, there is a hidden URL that lets you re-apply a permission mask to the Workflow Account.

/_layouts/15/appinv.aspx

• http://msdn.microsoft.com/en-us/library/office/jj822159(v=office.15).aspx

Apps for SharePoint

Of course, the way Microsoft wants you to build workflows in the cloud would not be via a hidden URL.

The best way (but somewhat tricky at the moment, as tooling gets better this story will improve) is to build SP2013 workflows within an App for SharePoint.  The workflow is deployed in the App web, and has the same permissions that the user grants to the App web.  You can request additional permissions as you package your App and those will be available to the Workflow as well.

So this is fantastic for building self contained apps where lists, list definitions, javascript forms and SP2013 Workflows all tie together to form a small bit of functionality.

But having workflows in the App Web means that it can't be added to existing document libraries or lists or sites in the host web.  So there are a number of scenarios where Apps for SharePoint doesn't work that well.  I have been using SP2013's Sandbox Solutions for this purpose.  But Sandbox Solution Packages doesn't have its own App permissions (and thus you'll need to see the previous point about how to elevate that afterwards).

Integrated Workflow Apps

Microsoft has begun to talk about the new Integrated Workflow Apps in more detail.

The new syntax available for Integrated Workflow Apps will basically allow you to install workflow packaged as an App for SharePoint, but instead of deploying the Workflow to the App web, it will be deployed and made available on the Host Web. 

But tooling will need to improve in a future VS.NET update.  This is something I want to blog again later as more details are available.  But for now, there's a great link here.

• http://www.vrdmn.com/2014/09/integrated-workflow-apps-deploy.html

There are a few pieces of the puzzle missing, and one may need to build additional javascript based UI to deploy assets (lists and workflow associations) to the host web.  But I'm loving the choices and I think SP2013 Workflows is moving in a fantastic direction.