Ignite 2015 Wrap up

For the past few days I was lucky enough to attend the Microsoft Ignite conference in Chicago to hear about all the new stuff coming from Microsoft and I have to tell you, it’s pretty exciting.

Microsoft Ignite 2015

The conference itself was massive, over 23,000 attendees as a result of merging Tech Ed, Microsoft Management Summit, the SharePoint Conference, Project Conference, Exchange Conference and Lync Conferences together. If I had to think about it, I would say it was a little too big and Project looked to suffer for it, but their was some great content.

The keynote was massive, but seemed a little disjointed. Talking to a number of people, it felt as if all the good stuff had been announced earlier or at Build the week before. Ignoring that though, there was some great demo’s from Julia White and my ex-colleague Ben Walters. The highlight had to be Gurdeep Pall (sorry Ben) , who was funny and engaging.

SharePoint 2016 Roadmap Investment Areas

This conference was to be the coming out party for SharePoint 2016, and whilst it’s still early days for the on-premises product, there were some key announcements, including:

  • MinRole concept – simplifying the ability to define which roles servers will take and the knock on effect of significantly reducing the patching overhead
  • Hybrid – SharePoint 2016 on-premises will make hybrid a first class citizen and augment on-premises capabilities with cloud services
  • Next Gen Portals – Awesome ready to go, quick and simple portals that can be up in a matter of minutes
  • Improved Management Tooling including zero downtime patching – Wow
  • Fast Site Creation – Sites will be created within the DB, instead of having to create templates with their various feature dependencies, making the process much much simpler.
  • and finally, the official announcement of the merging of the Project DB into the SharePoint Content DB.

I’ve heard about the merging for a while now for Project Online and it’s a pretty impressive achievement. When a PWA instance was first created, Project Online used to provision a Project DB per tenant. So if there were 100’s of tenants, there would be 100s of databases, all needing to be managed, maintained etc. driving up the cost of goods sold (COGS). Now between going live and early 2014, the Project team managed to consolidate all these databases and fold them into the SharePoint Content DB’s without a single incident or impact on availability. A massive achievement for the team at Project.

From a Project perspective, there were a couple of great sessions where with demo’s and announcements of new capabilities including the new multiple timeline support for Project Pro and the new Resource Engagements capability, both of which I will cover in a bit more detail in other posts.

Multiple Timelines

Finally, there was an interesting session on Project Online Customisation Best Practices, which gave some great insights into how to performance tune Project Central, although I am not sure I agree that taking the web parts off the page or removing indicators is the way to go.

image

The session was timed to highlight a great new whitepaper published by Microsoft on the subject of Project Online Perf, covering:

  • Choosing the right Permission Mode – SharePoint or Project Server and it’s impact on Queue Processing
  • Project Site Creation – When to create a project site in online to keep demand management workflow moving along quickly
  • PWA Page customisations
  • OData – Using Server Side Filters to improve oData Perf

You can read more of the white paper at https://support.office.com/en-us/article/Project-Online-performance-best-practices-12ba0ebd-c616-42e5-b9b6-cad570e8409c?ui=en-US&rs=en-US&ad=US&fromAR=1 or at http://aka.ms/projectonlineperf

All in all Ignite was really big, full of sessions and it’s going to take me a few days physically to get over it, but it was great to catch up with old friends, make new ones and learn. I am looking forward to Ignite 2016!

Help shape Microsoft’s Ignite Conference

Ignite - Spark the future

I’ve posted before about how fantastic the Microsoft Project & SharePoint Conferences are, well a couple of months ago Microsoft announced that they were merging those two conferences along with Exchange, Lync, Office 365 and pretty much everything in between into a new conference called Microsoft Ignite.

The Microsoft Ignite team have been hard at it planning what the event will be and it looks to be a cracker, but in a break from usual conferences, the team at Ignite want to hear from the community at large as to what content they want to see in the conference and have put up a survey at http://ignite2015.eventpoint.com/survey/callfortopics to understand the kind of content you want to see.

The team are also holding a series of TweetJams on twitter to engage with the wider audience. If your not sure what a TweetJam is, you can read more here.  But essentially, a TweetJam is a public discussion on twitter where posts are marked with a hashtag to allow the discussion to be tracked. Typically they have a host and a hashtag to follow. You can read more about TweetJam’s  here.

ProjectTweetJam

However I wanted to call out the Project specific TweetJam which is happening on the 9th December, the details of which are below:

Date / Time

Location Local time Time zone UTC offset
Seattle (U.S.A. – Washington) Tuesday, 9 December 2014 at 9:00:00 AM PST UTC-8 hours
London (United Kingdom – England) Tuesday, 9 December 2014 at 5:00:00 PM GMT UTC
Melbourne (Australia – Victoria) Wednesday, 10 December 2014 at 4:00:00 AM AEDT UTC+11 hours
Corresponding UTC (GMT) Tuesday, 9 December 2014 at 17:00:00

The Hashtag to follow is #IgniteJam

The team would like feedback on the following during the TweetJam, so get thinking :)

  1. What’s one thing you’ve loved in a past event that you’d like to see included in Microsoft Ignite?
  2. How can we help showcase your community at Microsoft Ignite?
  3. What is your preferred way to engage with our engineering teams at the event?
  4. What specific sessions do you want to see?
  5. What have you seen done at ANY event you’ve attended, Microsoft or other, that we should consider doing at Microsoft Ignite?
  6. How interested are you in learning about other Microsoft products, such as Azure and Windows 10?
  7. What’s one “can’t miss” thing to do in Chicago?

Finally, if you haven’t already, registration for the Ignite conference is now open, I would recommend you taking a look at this landmark conference and move heaven and earth to get there.

Introducing Nintex Workflow for Office 365

Nintex Workflow for Office 365You couldn’t have helped but notice the blog has been a bit quiet recently. The reason is that I have been pretty busy in my day job at Nintex. Well, I am pleased to say I can finally reveal what I have been working on. This week we released Nintex Workflow for Office 365, a new product in the Nintex family that brings the power of Nintex Workflow to the Office 365 platform.

Nintex Workflow for Office 365 - Workflow Designer

Nintex Workflow for Office 365 allows you to build workflows for Office 365 directly from within the browser, providing full access to the new workflow manager as well as world of cloud services through the Nintex Store. What makes it even more impressive is that it’s all done in the new SharePoint app model.

Nintex Store

You can find out more by checking out nintex.com/workflowo365 or by heading over to the SharePoint store, installing the app in your Office 365 tenant and signing up for a trial.

Normal Project Server service will now resume :)

Skipping stages with ‘Change / Restart Workflow’ in Project Server 2013 and Project Online & SharePoint Designer

SharePoint Designer 2013 is another tool that provides a means for building workflows, what is new in the 2013 release is it can now build Demand Management workflows for Project Server 2013 and Project Online. Now I am not going to go into the specifics of the tool, as you probably already know my preference, but irrespective of that, I thought it important to share how to build workflows that leverage the Skip to Stage functionality with SPD.

Now I have been advocating using Skip to Stage in workflows forever, if your building a long running workflow, which demand management workflows always tend to be, you would be foolish not to think that the workflow will be perfect from day one and not need updating and restarting at some point. Obviously the more complex your process (and thus the number of tasks, approvals etc. that need to be reapproved / declined) the more painful it becomes to restart a workflow and then progress through to the point you were at before the restart. This is where skip to stage comes in, when the workflow is restarted using Project Server’s inbuilt ‘Change or Restart Workflow’ function and a stage to skip to is selected, the workflow is passed some special settings letting it know that it needs to restart and skip through to the stage the user chose. However, Skip to Stage only works if you build your workflow to take it into account, it doesn’t ‘just work’.

Change Restart Workflows

I should note, this post comes as the result of a question in the Project forums on MSDN / Technet. Specifically, the original poster was having trouble understanding what was happening when using the Skip to Stage functionality of a SPD Project Server 2013 workflow.

So how do you build a workflow to take into account Skip to Stage logic?

Assume the following SPD workflow, it consists of three simple stages, each sequentially transitioning to one another. For each stage, there is a simple Log to workflow history list action, so we can see what the workflow is doing, and a Wait for the Project to be Submitted action (this stop the workflow executing and zooming through to the end).

Example Workflow without skipping

In normal operation, when this workflow runs it will enter stage one, log ‘Stage 1’ to the workflow history list, and then pause waiting for the project to be submitted via PWA. Once submitted, it will move into the next stage, and so on, until it gets to the last stage, when on the final submit the workflow will complete.

If you try and restart this workflow via the Change / Restart Workflow feature, and choose to Skip the workflow on to Stage 3, you would logically expect the workflow to just kick off in Stage 3. However this is not the case, even though the new Workflow Manager workflows allow you to build workflows that jump back and forth, they are still sequential behind the scenes, meaning your workflow needs to start on Stage 1 and move through the various stages to get to Stage 3, including any logic that is defined.

In order to skip the logic, the secret is to use a new action in SharePoint Designer called ‘Include Stage’. When you add the ‘Include Stage’ action, you will see a step entitled ‘If Project Web App starts the workflow normally or restarts the workflow and includes this stage’ added to the designer. This step is the key for ensuring when a workflow is restarted using Change / Restart workflow.

Skip to Stage logic

So what you will see:

  • If a workflow is stated normally, i.e. when creating a project, then the actions within will be run (in the example, the Wait for Event: When a project is submitted action)
  • If the workflow is restarted using Change / Restart Workflow and the stage being evaluated is the one being skipped to, or follows it, then the actions within the step will be run.
  • If the workflow is restarted using Change / Restart Workflow and the stage being evaluated is prior to the stage being skipped to, then the actions within the step will NOT be run.

It is important to remember that any other actions outside of the ‘Include Stage’ step will continue to be run, irrespective of whether the workflow was started normally or restarted.

So there you have it, if you’re going to be building demand management workflows using SPD, then best practice has to be to wrap all your business logic / approvals in one of these ‘Include Stage’ steps.

One final bit of info, the ‘Include Stage’ action also is available for use in the Transition section of the stages, meaning you can change the logic and flow of your workflows depending if the workflow was restarted or not. I am not going to dig into this too much now, but it is there.

Many thanks to John from the Project Product Team for his assistance with the above.

SharePoint Sydney Wrap Up

At SharePoint Saturday Sydney, I presented a session on the great new Work Management capabilities in SharePoint 2013 with a little bit of Project 2013, Project Server 2013 and some Project Online thrown in for good measure. As part of the session we gave away a few Project USB sticks for the best questions, a big thank you to the Project Marketing team at Microsoft Sydney for donating them.

The deck from the session is available below for your reference.

As promised in the session, here are some of the links:

Project Online Trial site – http://go.microsoft.com/fwlink/p/?linkid=257733

Project Online overview – http://www.microsoft.com/project/en-us/preview/project-benefits.aspx

SharePoint Preview Site – http://office.com/preview

If you came along to the session, thanks for being a great audience, if you didn’t, check out the deck and comment on this post if you have any questions. I will be posting up an overview post in the coming weeks to cover all aspects of work management.

Building advanced Project Server workflows with Nintex Workflow for Project Server

Over the past week or two, Microsoft have been quietly uploading all the sessions from the recent Project Conference held in Phoenix to the Project channel on Microsoft Showcase. This morning the Project team officially announced the availability, so I am pleased to announce that the video of Mark McDermott’s and my session is now available for your viewing pleasure. I encourage you to watch it and let me know if you have any questions.

image

Finally, the session deck, including notes is available for download at slideshare.net.

Hiding & Disabling ribbon items in Project Server, Part II

In the last post, we covered a few things you will need to know when hiding or disabling ribbon buttons in PWA. In this post we will look at how to actually hide the buttons.

Where to start?

Irrespective of whether you wish to hide or disable a button in the ribbon, you will need to follow the same basic process by building a solution in Visual Studio that will deploy your ribbon customisation.

To start, open up Visual Studio and choose to create an Empty SharePoint Project.

Create Empty SharePoint Project

Enter a name and then click on OK. You will then see the SharePoint Customisation Wizard, enter the local site you wish to use for debugging and choose to ‘Deploy as a sandboxed solution’.
SharePoint Customisation Wizard

On clicking finish, Visual Studio will create a solution ready to be customised.

To start with we need to create a feature,  this is a logical container for our customisation and allows the user to turn on and off the customisation by activating and deactivating the feature. To do so, right click on Features in the solution explorer and choose Add Feature.

Add Feature

A feature will be created and Visual Studio will show a page where you can enter information about the feature such as the name, description and the scope. In this case we are going to choose Web (for an individual site) as we want this change to deploy only to the /PWA site and not all the children sites.

Hidebutton Feature

Next we want to add an element to the solution, this is where the real work is done and contains the XML that will be used to configure our ribbon.

To add an element, right click on the project name, choose Add, New Item

Add New Item

In the dialog that is displayed, scroll down and select Empty Element and give it a name.

Add Element

Once you click add, the element will be created.

Blank Element

Now the empty element is created, all that is needed is to add the relevant XML to either disable or remove the button.

Disabling a button

For this example, we shall be disabling the EPT Change button from the Project Centre ribbon. To do so we need to know the ID of the item as defined in the ribbon so we can build up some XML that defines what we want to do to that item. To find the ID, we need to look through the PWARibbon.xml file, which can be a bit daunting, but after a while you will understand the structure and finding the Id’s will become simple.

SharePoint ribbon customisations use a defined XML schema which describes the structure and behaviour of the ribbon and the items that make it up. In order to disable the EPT Change button, we need to override the current structure and behaviour to change the configuration of what the button will do, in this case, pointing to a command that doesn’t exist.  In doing so, the ribbon will disable the button for us, giving us the desired effect.

To get the various attributes of the button, the PWARibbon.XML is your friend, containing all the configuration information you will need. In this case I have taken the configuration of the button and changed the command to point at a non existent command, which will cause the button to be disabled. This XML then needs to be put in the Element.xml file ready to be built, but more on that later.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<CustomAction
			Id="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change"
			Location="CommandUI.Ribbon"
			Title="Disables the EPT Change button in the Project Center Ribbon">
		<CommandUIExtension>
			<CommandUIDefinitions>
				<CommandUIDefinition Location="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change">
					<Button
						Id="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change"
						Command="ChangeReplacement"
						Sequence="10"
						Image16by16="/_layouts/$Resources:core,Language;/images/ps16x16.png"
						Image16by16Top="-112"
						Image16by16Left="-190"
						Image32by32="/_layouts/$Resources:core,Language;/images/ps32x32.png"
						Image32by32Top="-352"
						Image32by32Left="-96"
						LabelText="$Resources:pwafeatures,WEBPARTS_PROJECTCENTERPART_CM_CHANGE"
						TemplateAlias="o1"
						ToolTipTitle="$Resources:pwafeatures,PAGE_PDP_CM_CHANGE_WORKFLOW"
						ToolTipDescription="$Resources:pwafeatures,SUPER_TOOLTIP_CHANGE_PROJECT_TYPE"
						/>
				</CommandUIDefinition>
			</CommandUIDefinitions>
		</CommandUIExtension>
	</CustomAction>
</Elements>

Removing a button

The XML code required to remove a button is simpler. Instead of defining the XML for the whole button, all that is required is to redefine the CommandUIDefinition as per below.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<CustomAction
			Id="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change"
			Location="CommandUI.Ribbon">
		<CommandUIExtension>
			<CommandUIDefinitions>
				<CommandUIDefinition Location="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change" />
			</CommandUIDefinitions>
		</CommandUIExtension>
	</CustomAction>
</Elements>

When PWA parses the XML it uses this to remove the button as key items are not defined. Once again, all that is required to remove the button is to move this XML into the Elements.XML file and save ready for building.

In both cases, if you wish to hide or disable more than one button, you will need to duplicate the Custom Action mark up and change as necessary for each button.

How to Build

Finally once the configuration is completed, all that is required is to build and deploy the solution. To do so, right click on the project name and choose build, if everything is ok, you should see something similar to this in the build output:

Build Succeeded

If the build fails, then there may be a problem in your code. I have packaged the code up I used to build this post into a zip file which is available from my Skydrive account so you can compare or copy.

Once the build is successful you can deploy the solution by right clicking on the solution name and choosing deploy. VS 2010 will then deploy the solution to the site you entered for debugging and activate the solution in the site collection.

Activate Feature

Once the solution has been activated, you should see the changes to the ribbon in Project Center.

As you can see from above, creating a custom feature to hide or disabling buttons in the ribbon is relatively simple once you have the basic structure in place. Hopefully this post has explained how to build these customisations for use in your next project or internal implementation.