Workflow, as far as I can tell at this point, is one of the most overhauled functionalities from SharePoint 2010 to SharePoint 2013. The first major difference is that it’s no longer contained within SharePoint. Workflow is now handled by Windows Azure Workflow (WAW).

“Whoa, whoa, whoa! Does that mean I’m going to have to pay Microsoft some hefty usage fees to have Workflow in my 2013 environment? I really don’t see how that’s going to fly with the bosses,” you say.

Fortunately, no, that’s not the case. While I’m sure there will be a model for this, it’s not the only one. You can host WAW on-premises just like SharePoint. We’ll delve into that momentarily. Windows Azure Workflow is built on Windows Workflow Foundation 4.5 (WF4.5). WF4.5 introduces several new features as detailed in the MSDN article “What’s New in Windows Workflow Foundation.” This will require a separate install that can run on a SharePoint server or its own environment. We’ll also look at the architectural implications in a bit.

The “meat” of this post is going to focus on three areas: Architecture, Development, and how these would affect the design of an existing SharePoint 2010 Workflow project. The architecture changes only start with WAW and WF4.5. We’ll discuss the installation requirements, how it’s hosted, security, and the Pros and Cons of WAW. The development story has changed, at least to me, far more. I’ll explain the changes to coding (Hint: You can’t…directly), how web services can remedy the last statement, and custom actions. Finally, we’ll take a look at the project I discussed in my last post “Developing Multi-Tiered Solutions in SharePoint” and how that design would be changed for a SharePoint 2013 environment.

Read More…

Windows 8 Desktop

Microsoft has been a busy company this year with refreshes on most of its biggest solutions. Not only has SharePoint gone through a massive update, but so has Windows. If you’re still unfamiliar with the changes in Windows 8, then be prepared for a shocker. In the new UI, applications have been stripped of chrome and are full-screen solutions. Windows 8 was designed with touch as a first-class input method.

SharePoint 2013 brings several new features, but the two that will empower client application development the most are the greatly expanded Client-Side Object Model (CSOM) and the REST APIs. While the maturity of these features is important for Microsoft’s push to SharePoint Online and client-side development, it also opens up complex functionality for Windows, mobile, and external web applications. Read More…

N-tier development is not a new methodology. I remember learning about it in 200-level courses back in 2000, and I used it in ASP.NET development before I jumped on the SharePoint bandwagon. However, one of the things I’ve noticed over the years as a SharePoint developer is that most project development is done in the SharePoint object’s code behind or a few helper classes. This isn’t always the case —sometimes the solution isn’t complex enough to warrant a tiered approach (i.e. a single Event Receiver). But a recent project highlighted the power behind N-tiered architecture.

The client has a custom solution that they provide as a service: A master document (Microsoft Word) is split into section documents (also Word) by a project manager. Each section is assigned to a person to be modified in Word (the client also provides a Word plug-in for this modification). Once the sections are properly marked up, the master document is recreated from the sections. We were brought in to implement this solution in SharePoint 2010. Read More…