Since the very first version of SharePoint, workflows have always been an important feature for the platform as a whole. This is due to the fact that for a long time, companies have found workflows indispensable for automating business processes. Over the years, in the various versions of SharePoint, workflows have become more powerful, flexible, customizable, and easier to create. However, some criticism remained regarding the performance and scalability of SharePoint workflow services. As an administrator, you will be happy to learn that these issues have been addressed in SharePoint 2013.
The architecture of the workflow platform for SharePoint 2013 has been changed quite dramatically compared to what it is in SharePoint 2010. First off, the old SharePoint 2010 workflow platform is still available in SharePoint 2013, but there’s also a new workflow platform available that is based on .NET 4.5.
Note Workflows hosted in SharePoint 2013 and built using the old SharePoint 2010 workflow platform are typically called SharePoint 2010 workflows, while workflows created using the new workflow platform introduced in SharePoint 2013 are called SharePoint 2013 workflows. Both terms are a bit misleading: SharePoint 2010 workflows can actually run in SharePoint 2013, not just in SharePoint 2010. And it can be argued that, as you’ll soon find out, SharePoint 2013 workflows don’t run in SharePoint at all. Never mind its shortcomings, make sure you’re familiar with this terminology.
The new workflow platform allows you to take SharePoint workflows and actually run them outside of your SharePoint farm. Taking SharePoint features and run them outside of the SharePoint farm is a general trend in SharePoint 2013, you will see the same in other SharePoint 2013 technologies such as Office Web Apps and the new SharePoint App model. This is a good thing, since this reduces the surface of custom programs that negatively impact the stability and performance of your SharePoint farm. Architecturally, this is a huge break from previous SharePoint platforms.
Other than the biggest eye catcher, meaning the architectural changes mentioned, the SharePoint workflow platform offers more new improvements, which will all be discussed in the rest of this blog post.
Best Practices The old SharePoint 2010 workflow platform is still available in SharePoint 2013 for compatibility reasons and is based on the Windows Workflow Foundation (WF), included with the .NET 3.5 framework. However, it is recommended to base new custom workflow efforts on the new model.
Workflow Architecture
In this section, we will give you an overview of the new workflow architecture platform and discuss which things are changed regarding workflows in SharePoint 2013. With the arrival of SharePoint 2013 the architecture of the workflow platform has completely changed. In SharePoint 2010 the workflow platform was an integrated part of SharePoint itself, running within the SharePoint farm. The .NET 3.5 Workflow Foundation Runtime was hosted by SharePoint 2010, which acted as the so-called custom workflow service host. In SharePoint 2013, this is absolutely not the case, as the workflow host provider is taken out of the SharePoint farm altogether.
Before delving into this new architectural change, it might be comforting to know that SharePoint 2013 keeps hosting the 2010 workflow platform, so every SharePoint 2010 workflow will still work in SharePoint 2013.However, the new 2013 workflow platform will not be hosted by SharePoint at all. Instead, the new workflow execution host (or workflow server) is Windows Azure Workflow (WAW). We have to be real careful here, as the name WAW implies that such workflow execution hosts run in the cloud which doesn’t have to be the case, and most of the times are not. On premises SharePoint farms use workflow servers that are real machines running on premises as well. As a matter of fact, on premises SharePoint deployments only work with on premises workflow servers running WAW. As of yet, they are not able to leverage Azure based WAW servers. Opposed to that, Office 365 does leverage Azure based WAW servers.
Note This is another trend you will see frequently in SharePoint 2013: whenever possible, SharePoint 2013 will offer built-in cloud support.
This new SharePoint 2013 workflow model is based on Windows Workflow Foundation 4.5 (WF), part of the .NET framework 4.5, and is substantially redesigned compared to earlier versions. Not only are SharePoint 2013 workflows powered by Windows Azure Workflow, a powerful new workflow service part of the .NET 4.5 framework, Windows Azure Workflow itself is built on Windows Workflow Foundation 4.5. In its turn, Windows Workflow Foundation makes extensive use of the messaging functionality provided by Windows Communication Foundation (WCF).
Note Windows Workflow Foundation is a technology that makes creating workflows within .NET easy. It provides a workflow API, an in-process workflow engine, as well as a rehostable workflow designer. Windows Communication Foundation is a set of application programming interfaces (APIs) that can be used for building connected, service-oriented applications (SOAs). Essentially, SOAs are applications that deal with exchanging messages. As is the case with WF, WCF is also a part of the .NET framework.
You can use workflow models to give structure to business processes. To put it in other words, a workflow is a representation of a business process. In Windows Workflow Foundation 4.5, each workflow consists of a structured collection of workflow activities. Each activity represents a functional component of a business process, such as sending an e-mail message, checking out a document located in SharePoint, or logging information to a SharePoint history list.
The Windows Workflow Foundation 4.5 activity model is adopted by SharePoint 2013 to represent SharePoint-based business processes. Another concept you will find in SharePoint workflows is the concept of conditions, which are indispensable decision makers that will allow workflows to behave intelligently and decide which activities need to be executed. Examples of conditions are: if x happens do something, wait until time to perform an operation, as long as is true do nothing. Most often, conditions in SharePoint workflows rely on some type of information about a document in a SharePoint document library or a SharePoint list item.
As a new addition to activities and conditions, SharePoint 2013 provides a new stage model. Stages provide a convenient way to group conditions and activities together and now are the building blocks for the new recommended best practice surrounding the construction of workflows that don’t have fixed execution paths, replacing the old and deprecated state workflow model.
Note Workflows can be sequential where the order of the execution path is fixed. State workflows are event driven and their execution paths are determined by external factors.
A final concept you will need to know about is workflow actions. So far, we have only talked about workflow activities, but it is also important to know the difference between workflow activities and workflow actions. Workflow activities are a lower level concept and represent the underlying managed objects whose methods drive workflow behaviors. Workflow developers will interact with workflow activities via code or using a specific development environment. Workflow actions, on the other hand, are wrappers that encapsulate the underlying activities and present them in a user-friendly form in SharePoint Designer 2013 or Visual Studio 2012 (more about these tools later). When you create a workflow you will work directly with workflow actions. At the level of the workflow execution engine, the engine acts directly on the corresponding activities.
Workflow activities, which are implementations of activity classes, are implemented declaratively by using XAML. Workflow activities are invoked using loosely coupled web services that use messaging APIs to communicate with SharePoint. These APIs are built on the messaging functionality that is provided by Windows Communication Foundation (WCF). The messaging framework is very flexible and supports virtually any messaging pattern that you need. Within your SharePoint 2013 farm, Windows Workflow Foundation and WCF are hosted in a component called the Windows Azure Workflow Manager Client server (located on premises, or, for Office 365, in the cloud), so that is also the place where the workflow activities actually run.
Note XAML is a declarative XML-based language for describing structures such as Windows Presentation Foundation (WPF) user interfaces, or, in this case, workflows.
Figure 1 depicts a high-level view of the SharePoint 2013 workflow framework. Notice, first, how the new workflow infrastructure introduces the Windows Azure Workflow Manager Client as the new workflow execution host (denoted in the Figure as Azure Workflow). Whereas in previous versions workflow execution was hosted in SharePoint itself, this has changed in SharePoint 2013. Workflow Manager Client is external to SharePoint and communicates using common protocols (REST API calls over HTTP or HTTPS) over the Windows Azure service bus, mediated by OAuth 2.0.
Note OAuth is a security protocol that allows applications to communicate with other applications, if need be across domains, without actually sharing user credentials. As a best practice, communication between such applications will be over HTTPS, to ensure all OAuth tokens are sent safely across the network.
Other than that, the architectural overview contains no big surprises; the SharePoint “box” contains the features that you would expect to see: content items, events, apps, and so on. As promised before, notice that there is also an implementation of the SharePoint 2010 workflow host (that is, the Windows Workflow Foundation 3.5 engine). It’s there for backward compatibility reasons.
Let’s take a further moment to define the major workflow related components found on Figure 1:
Windows Azure Workflow Manager Client server (or, as it is called in the Figure, just Azure Workflow) takes care of managing the workflow definitions and is responsible for hosting the execution processes for workflow instances.
SharePoint 2013 provides the framework for SharePoint workflows, which model SharePoint-based business processes that involve SharePoint documents, lists, users, and tasks. Additionally, SharePoint workflows, associations (where SharePoint workflows are tied to SharePoint entities such as lists, libraries, sites or content types), activities, and other workflow metadata are stored and managed in your SharePoint 2013 farm.
SharePoint Designer 2013 is a tool for creating, designing, and publishing workflows. Because of its ease of use, the main target audience for this tool consists of power users.
Figure 1 SharePoint 2013 workflow architecture.
The Workflow Manager Client needs to be present on every SharePoint machine running workflow services and sits on top of the Workflow Manager Client Service Application Proxy (also shown in Figure 1). The Workflow Manager Client allows SharePoint 2013 to communicate and interact with the Workflow Manager Client server. Server-to-server authentication is provided using OAuth 2.0 (hence the Azure Access Control component). The various SharePoint events to which a SharePoint workflow can be listening, like itemCreated, itemUpdated, and so on, are routed to Workflow Manager Client using the Windows Azure service bus. For the return trip, the platform uses the SharePoint Representational State Transfer (REST) API to call back into SharePoint.
Note A service bus is a software architecture model used in SOA architectures to describe a piece of software that facilitates interaction and communication between various distributed applications. As such, it is a more advanced form of client/server architecture models, which are typically used in heterogeneous and complex infrastructures. REST can be seen as a light version of SOAP. The REST protocol leverages the HTTP protocol and allows clients to interact with server resources in various ways, supporting HTTP verbs such as GET, POST, PUT, and DELETE.
There are additions to the SharePoint workflow object model that allow you to manage and control workflows and their execution by interacting with the Workflow Services Manager. These additions are also known as the Workflow Services Manager object model and are part of the bigger all-encompassing SharePoint 2013 object model (as can be seen in Figure 1).
Note Typical reasons to leverage the Workflow Services Manager object model are related to workflow deployment, messaging, instance control, and interoperability with SharePoint 2010 workflows. A new and interesting feature of the Workflow Services
Manager is that it allows 3rd party vendors to create separate workflow designers that leverage it and build a new UI to create workflows, and offer such separate workflow designers to the audience in the form of SharePoint Apps.
Workflow authoring can be done in various ways. SharePoint Designer, in its 2013 version, can now be used to create and deploy both SharePoint 2010 and SharePoint 2013 workflows, and Visual Studio 2012 not only provides a designer surface for creating declarative workflows, but can also create apps for SharePoint and solutions that fully integrate Workflow Manager Client functionality.
Workflows in SharePoint 2013
Let’s start with some good news: the workflows that you have built for SharePoint 2010 will continue to work in SharePoint 2013. When you install SharePoint 2013, the SharePoint 2010 Workflow platform is installed automatically. But to make use of the new SharePoint 2013 Workflow platform you have to install and configure Windows Azure Workflow (WAW)separately from SharePoint 2013. Probably the easiest way to get it is using the Microsoft Web Platform Installer (Web PI at http://www.microsoft.com/web/downloads/platform.aspx) and searching in it for windows azure workflow. When the search results display, make sure you see the Workflow 1.0 and Workflow Client 1.0 versions. The Web PI then allows you to install both pieces of software, and starts a configuration wizard that you need to follow.
Note If you’re installing a development environment where SharePoint 2013 runs on a domain controller, you need to enter the Fully Qualified Domain Name of any end user names you’re using during the installation of WAW. So, instead of entering contoso\username, you need to enter contoso.com\username.
So, in a typical SharePoint 2013 farm, you will have two different Workflow platforms installed that you could use to create workflows. Other than SharePoint 2010 Workflows, and SharePoint 2013 Workflows, there is a 3rd workflow platform option of the type SharePoint 2013 Workflow – Project Server. This type requires the presence of Project Server 2013 and falls outside the scope of this blog post.
You can choose to install the Windows Azure Workflow component on a separate server or farm of servers and connect it to your SharePoint farm. This allows you to scale the Workflow component according to your needs, and manage it separately. There are two different topology models for handling scale out scenarios: collocated and federated.
In a collocated topology model, every SharePoint web front-end (WFE) is connected to its own dedicated Workflow Manager server, which is responsible for storing persistent data in a database that can be accessed by every Workflow Manager server. If there are multiple nodes in the SharePoint farm, traffic between SharePoint WFEs and Workflow Manager nodes takes place via HTTP and goes through SharePoint’s Network Load Balancer (NLB) or hardware NLB, if you’re using it.
In a federated topology model, you can create a Workflow Manager farm, also known as a Workflow cluster, consisting of multiple Workflow Manager servers. A Workflow cluster can be reused by multiple SharePoint farms and can be managed completely independent of SharePoint. According to current best practices, workflow clusters should contain up to 3 Workflow Manager servers to ensure high availability. Based on Microsoft findings, this is more than enough to handle all kinds of high demanding workflow solutions.
Important Both topology models require the presence of the Workflow Manager client on every SharePoint node in the farm. See http://technet.microsoft.com/en-us/library/jj658588(v=office.15) for more information on how to do that. Workflow clusters can be created by specifying a farm scope in the Register-SPWorkflowService PowerShell cmdlet that will be discussed shortly hereafter.
Note This is a perfect example of the trend where pieces of custom software are encouraged to run outside of your SharePoint 2013 farm. This includes pieces of custom software such as workflows, InfoPath forms, SSRS reports, SharePoint Apps and so on. For administrators, this is great news as this is a huge step towards securing your SharePoint farm health.
After installing and configuring Windows Azure Workflow, you need to run the Register-SPWorkflowService PowerShell cmdlet to configure the communication between Windows Azure Workflow and SharePoint 2013. The easiest way to do this is to run this cmdlet within the SharePoint 2013 Management Shell and pass it at least the URL of the SharePoint site collection, the URI of the Windows Azure workflow host, and some optional arguments. For example:
Register-SPWorkflowService –SPSite “http://myserver/mysitecollection” –WorkflowHostUri “http://workflow.example.com:12291″ –AllowOAuthHttp
Security Alert For production environments, OAuth expects the use of SSL so that all OAuth tokens are sent securely. Allowing OAuth over HTTP is a setting intended for use in development and test scenarios.
Port 12290 is used by default by the Windows Azure workflow host for HTTPS, while port 12291 is used by default for HTTP. If you’re not sure about the port number, you can always take a look at IIS Manager to find out which port you are using. The –AllowOAuthHttp flag must be added when you’re using HTTP instead of HTTPS, which ensures secure communication between your SharePoint 2013 site collection and the Windows Azure Workflow host.
Important You cannot connect Windows Azure Workflow to SharePoint Foundation. Installation of the features required for Windows Azure Workflow rely on files only found in SharePoint Server 2013 installations, specifically in the OSFSERVER install files. These files are not available in SharePoint Foundation, and therefore it is only possible to connect Windows Azure Workflow to SharePoint Server 2013.
See Also More information about connecting Workflow Managers on servers that are not a part of your SharePoint 2013 farm can be found at http://technet.microsoft.com/en-us/library/jj658588(v=office.15).
Workflow subscriptions and associations
As you have learned, the most significant change to SharePoint 2013 workflows is the moving of workflow processing onto an external workflow hosts (Windows Azure Workflow). Because of this, it was essential for SharePoint messages and events to connect to the workflow infrastructure in Windows Azure. In addition, it was necessary for Windows Azure to connect the infrastructure to customer data. Workflow associations (which are built on the WF concept of subscriptions) are the SharePoint infrastructure pieces that support these requirements.
Before we can discuss workflow associations and subscriptions, we must take a look at the Windows Azure publication/subscribe service, which is sometimes referred to as pub/sub, or simply PubSub. PubSub is an asynchronous messaging framework. Message senders (publishers) do not send messages directly to message receivers (subscribers). Instead, messages are rendered by publishers as classes which have no knowledge of the message subscribers. Subscribers, then, consume published messages by identifying messages of interest, regardless of the publisher, based on subscriptions that they have created.
This decoupling of message creation from message consumption allows for scalability and flexibility. It enables multicast messaging on the publisher side (where one message sent by a single publisher is received by multiple subscribers), and for promiscuous message consumption on the subscriber side (a subscriber receives messages by multiple publishers).
Note The PubSub feature is a part of the Windows Azure Service Bus, which provides connectivity options for WCF and other service endpoints. These include REST endpoints, which can be located behind network address translation (NAT) boundaries, or bound to frequently changing, dynamically assigned IP addresses, or both. For more information about the Windows Azure Service Bus, see http://msdn.microsoft.com/en-us/library/windowsazure/ee732537.aspx .
Workflow associations bind workflow definitions to a specific SharePoint scope, with specific default values. The associations themselves represent a set of subscription rules that are stored in the Windows Azure publication/subscription service that process incoming messages to ensure that they are consumed by appropriate (that is, subscribed) workflow instances. By default, the messaging infrastructure supports workflows at the following scopes:
SPList (for list workflows)
SPWeb (for site workflows)
Unlike previous versions, SharePoint 2013 does not support workflows that are scoped to a content type (SPContentType). However, the messaging infrastructure is extensible, so it can support any arbitrary scope.
Note Although outside of the scope of this blog post, it may be of interest to know that developers of custom workflows can set the EventSourceId property on a given WorkflowSubscription instance to any Global Unique Identifier (GUID). Workflow developers can then use that EventSourceId value to call the PublishEvent(Guid, String, IDictionary<(Of <<’(String, Object>)>>)) method, which triggers a new workflow instance of the specified WorkflowSubscription. In other and simpler words, this allows custom solutions to notify SharePoint workflows of their own custom events.
Workflow Modeling and Development Tools
Typically, administrators won’t be responsible for creating custom workflows. Having said that, there are exceptions to this rule, and it’s certainly to be expected of SharePoint administrators that they have a working knowledge of existing workflow modeling and development tooling.
Important If you want to be able to understand the complete workflow architecture in SharePoint and its surrounding workflow tooling, it’s unavoidable to learn about the workflow modeling and development tools. A basic working knowledge of these tools will make you more effective in your job as a SharePoint administrator.
The following tools are available for creating custom workflows:
Visio 2013 can be used to create a graphical design of a workflow. It is not possible to create a fully active workflow that can be published to SharePoint directly. What you can do is use Visio 2013 to transform business processes into SharePoint workflow artifacts and import such workflows into SharePoint Designer 2013, where it can be processed further and published to SharePoint. Business analysts are the primary audience for this tool.
SharePoint Designer 2013 can be used to model new workflows or edit existing workflows in a graphical, non-programming, way. You can create fully active workflows using this tool. SharePoint power users are the primary audience for this tool.
Visual Studio 2012 is used to create workflows that can be associated with any list or library. This is the most powerful tool for creating custom workflows, as it provides its users full access to the programmatic capabilities concerning SharePoint workflows. It must come as no surprise that Visual Studio 2012 is primarily aimed at developers.
Using Visio 2013, a business analyst or information worker can design a workflow. The building blocks of the workflow can be put into place but the values of those building blocks not. This effectively allows business analysts to design the logical structure of a business process and capture that workflow artifact in a form that can be taken for further processing. The actual configuration of SharePoint workflow artifacts can be further handled in SharePoint Designer 2013.
Visual Studio 2012 and SharePoint Designer 2013 both provide a fully declarative, no-code authoring environment for creating custom workflows. A declarative workflow is a workflow that is fully described in the XML language XAML without using any code, which, from a security standpoint, is a huge advantage. XAML is interpreted at run time by the workflow engine and is derived from the stages, steps, actions, and conditions, etc. that you have used to create a custom workflow in either SharePoint Designer 2013 or Visual Studio 2012. The building blocks that are available for creating XAML documents differ depending which tool you use.
Note All workflow modeling and development tools mentioned in this section are examples of Domain Specific Language (DSL) tools. A DSL is a programming language dedicated to a particular problem domain, using its own particular problem domain visualization techniques. The various SharePoint 2013 workflow tools offer a graphical language that allows you to create workflows without having to write a single line of XAML.
You have learned that Visio 2013 cannot be used to actually create workflows that can be published directly to SharePoint, and that you would actually need to use either SharePoint Designer 2013 or Visual Studio 2012 to do this. So, when should you use which tool? That is always the question and we will take a moment to delve a little deeper into the answer.
Since SharePoint Designer 2013 and Visual Studio 2012 are both suitable to create declarative workflows, we will take a look at the different kinds of persons that would be interested in creating workflows. SharePoint Designer 2013 is easy to use and allows for Rapid Application Development (RAD). Therefore, in that respect, SharePoint Designer 2013 is suitable for use by all interest groups: information workers, business analysts and SharePoint developers. On the other hand, SharePoint Designer 2013 is quite powerful and to be able to create a workflow using SharePoint Designer 2013 you have to be familiar with the core workflow components, like stages, actions, conditions and loops. Because of this: the general audience for SharePoint Designer 2013 is described as consisting of power users: users that have a considerable working knowledge of SharePoint. Generally, this means that business analysts will stick to using Visio 2013: they will have extensive knowledge about the specific problem domain, but typically won’t have much SharePoint knowledge (or the need to learn about SharePoint at the power user level).
The target audience of Visual Studio 2012 is quite limited: it consists of intermediate or advanced software developers as the tool allows you to do actual programming. These developers have to be familiar with both Visual Studio itself as well as SharePoint.
Having described the general audiences for both tools, let’s take a look at their specific advantages and disadvantages. The overview below discusses the most important workflow features, and then explains which of the available tools is most suitable for handling those features.
Rapid workflow development Using either SharePoint Designer 2013 or Visual Studio 2012, you can create workflows very quickly. This is because the workflows are created in a declarative fashion and both tools contain building blocks to create such workflows in an easy and visual way. Having said that, SharePoint Designer 2013 has a definite edge when it comes to rapid workflow development.
Enable reuse of workflows A workflow created with SharePoint Designer 2013 can only be used on the list or library for which it was developed. SharePoint Designer 2013 does provide reusable workflows which can be used more than once in the same site. However, using Visual Studio 2012 you can create a workflow that can be associated with any list or library on any site and also be reused. That is a big advantage, so here the advantage lies with Visual Studio 2012.
Create a SharePoint workflow solution or workflow App for SharePoint Using SharePoint Designer 2013 it is absolutely not possible to create these. However, Visual Studio 2012 is created for these types of artifacts. Therefore, this tool has an absolute advantage over SharePoint Designer 2013.
Create custom actions Using SharePoint Designer 2013, you cannot create custom actions, you can however use custom actions created and deployed with Visual Studio 2012. Visual Studio 2012 does allow you to create custom actions.
Create custom code This is not possible using either SharePoint Designer 2013 or Visual Studio 2012. Even in Visual Studio 2012, you now only have a visual design surface to create workflows.
Note As stated repeatedly, Visual Studio 2012 does allow developers to create custom code in a form. They will have to do so in the form of creating custom actions or calls to separate WCF services, since it’s not possible anymore to add custom code to workflows directly.
Make use of workflows created by Visio 2013 In SharePoint Designer you can import workflows made using Visio 2013, this is not possible with Visual Studio 2012.
Deployment In SharePoint Designer 2013, deployment is done automatically once you’ve clicked the Publish button. Using Visual Studio 2012, you can create a SharePoint solution package and deploy your workflow to a site. With both tools you can package the workflows and deploy them to a remote server, although Visual Studio 2012 allows you more control over this process, whereas SharePoint Designer 2013 makes deployment just a little bit easier.
Debugging It is not possible to debug custom workflows in SharePoint Designer 2013; with Visual Studio 2012 you can debug workflows. This is an essential capability for workflows that are more complex in nature.
Concluding, you have seen why Visio 2013 is the premier tool of choice for business analysts (it is great for capturing business processes but can’t be used to publish workflows to SharePoint), why SharePoint Designer 2013 is the premier tool of choice for power users (in general, it’s easier to use then Visual Studio 2012, and does allow you to publish workflows to SharePoint), and why Visual Studio 2012 is the premier tool of choice for developers (it’s the most powerful of all tools). In the next sections, you will take a closer look at each of the different SharePoint workflow development tools.
Visio 2013
In this section, you will take a closer look at the Visio 2013 tool. Visio 2013 makes it easy to create workflows if you’re used to working with Visio. As a result, this tool is specifically interesting for business analysts and process consultants who know exactly about the logical steps of a workflow/business process, but aren’t experienced (or SharePoint savvy) enough to implement it themselves using SharePoint Designer 2013 or Visual Studio 2012. These users will typically use Visio 2013 to create a mock-up workflow, and hand this workflow artifact over to either developers or power users that will use it as a starting point for the further implementation and configuration of the workflow.
After creating a workflow using Visio 2013, it can be exported to SharePoint Designer 2013. In SharePoint Designer 2013, after importing the Visio 2013 workflow, power users can add logic to the workflow steps by using the workflow text editor or/and the new Visual Workflow Designer. When they’re done, the power users can publish the workflow to SharePoint 2013.
Note SharePoint Designer 2013 contains a new Visual Workflow Designer which shows a visual representation of the workflow in the way the workflow is shown in Visio 2013. This is done via a Visio 2013 add-in in SharePoint designer 2013. This requires Visio 2013 to be installed on the same machine as SharePoint Designer 2013. Check for available licenses as Visio 2013 is a part of Office 2013 and is not free, as opposed to SharePoint Designer 2013.
Visio 2013 contains a new template called the SharePoint 2013 Workflow template. This template contains three stencils: Actions, Conditions, and Components, as shown in Figure 2.
Figure 2 Visio 2013 workflow stencils.
Using the shapes in these stencils you can build a workflow. That is very easy because the only thing to do is to drag the workflow shape onto the drawing canvas. It is only the visual that you’re dragging onto the canvas, since using Visio 2013 you cannot add the logic behind the visual. This can be added later using SharePoint Designer 2013. Figure 3 shows a sample Visio 2013 workflow diagram.
Figure 3 Example of a Visio 2013 workflow diagram.
Best Practices After modeling the workflow in Visio 2013, you can check if the workflow contains any errors by clicking the Check Diagram button in the ribbon. You should do this every time before exporting the Visio 2013 workflow diagram.
SharePoint Designer 2013
If you are knowledgeable about SharePoint and want to take it to new limits, or even want to develop SharePoint applications, there comes a time when you need to take a look at SharePoint Designer 2013, a tool that enables rapid SharePoint development. SharePoint Designer 2013 allows advanced users and developers to create no-code solutions for a variety of problems. This is especially true when it comes to creating custom workflows; traditionally this has been made quite easy via SharePoint Designer 2013.
New functionality in SharePoint Designer 2013
SharePoint Designer 2013 contains support for the new workflow platform specifically designed for Windows Azure Workflow. This platform is called the SharePoint 2013 Workflow Platform. The new functionality that can be found in SharePoint Designer 2013 to support this new platform includes:
A new visual designer that makes use of a Visio 2013 add-in.
A new action called Call HTTP Web Service with which you can make no-code web service calls from within a SharePoint Designer 2013 workflow.
New actions for assigning a task and starting a task process. With both actions you can edit the Task Creation Email and the Task Overdue Email.
Real World These features are very popular and have been requested for a long time. Expect that these actions will be used a lot. I’m especially excited about the ease with which custom tasks can be made, and the amazing new opportunities to access external lists. Think, for example, of a customer list. Now think that just by entering customer names, a workflow kicks off and fills in the rest of the customer details in the list, such as phone numbers, addresses, and such. By the way, all web services responses are handled asynchronously by the Workflow Services Manager and managed using a throttling mechanism, so you don’t have to worry about blocking your workflow or workflow timer jobs. You can even poll a web service repeatedly by creating a stage that calls a web service, followed by another stage that pauses for, let’s say 1 hour, and then goes back to the first stage that calls the web service. That way, the information retrieved from a web service always stays up to date.
New actions for starting a List workflow or a Site workflow that are built on the SharePoint 2010 platform.
A new Dictionary type that can be used to store variables. When creating a workflow, most of the time the workflow creator will save a value in some variable (i.e. x = 10, or currentDate = 10/8/12) so you can use this value in other parts of the workflow. The Dictionary variable type is a container that is designed to hold a collection of different variables. So suppose you want to store the name and the birthday of an employee, you could use the Dictionary variable type to create an Employee Dictionary instead of creating two separate variables EmployeeName and EmployeeBirthday. In other words, dictionaries allow you to create logical groups that make it convenient to store related information together. The following new actions are designed specifically for working with the Dictionary variable type:
Build Dictionary With this action you can create a Dictionary variable type, create the various variables that are part of this dictionary, and give the Dictionary variable itself a unique and descriptive name.
Note You can nest Dictionary variables, in other words, you can put Dictionary variables into another Dictionary variable. This can be very beneficial, and helps to make your custom workflows clean, structured, and easy to understand. For example, you could have an Employees dictionary containing multiple Employee dictionaries. In other words, the Employees dictionary acts as a collection of Employee entities. Each employee dictionary could, in its turn, contain the name of the employee, address and job title. This way, SharePoint workflow development introduces some techniques commonly found in traditional object oriented (OO) programming.
Count Items in a Dictionary Using this action, you can count the number of variables that a Dictionary contains and store that number in an Integer variable. This can be handy in case you would want to loop through all the items in a Dictionary, a very common task.
Get an Item from a Dictionary This action can be used to retrieve the value of a specific variable from a Dictionary and store it in another variable.
There are new workflow building blocks:
Stage Using the building block Stage you can group conditions and actions together. Before moving on to the next stage, all conditions and actions are processed in the order as listed within the stage. Again, this is an improvement that makes it easier to create workflows in a clean and structured way. Improvements such as these go a long way towards making complex workflows easier to build and manage.
Loop A loop contains a series of actions that is executed repeatedly for just as long as the specified conditions are true (i.e. while a task isn’t completed, send reminder e-mails).
Note Loops have been a much requested feature for SharePoint Designer. Probably the most anticipated one. In SharePoint 2010, workflow Loops where only available in Visual Studio 2010 as it was considered too dangerous to hand the power of Loops and its possible disastrous side-effects to power users. One misconstrued infinite loop in a custom workflow could have a definite impact on SharePoint farm performance. Now, since SharePoint 2013 workflows run outside the SharePoint farm, such risks are considered to be acceptable.
App-Only Step The contents of this step will run as the workflow application.
You can choose on which workflow platform you want to build a workflow, 2010 or 2013.
Windows Azure Workflow capabilities
Figure 4 The Visio 2013 add-in available in SharePoint Designer 2013.
Because workflows are built using Windows Azure Workflow these workflows automatically gain several new capabilities like:
High Density and Multi-Tenancy The multi-tenant hosting capabilities provide for safe, high efficiency and high performance execution of workflow instances.
Elastic Scale Elastic scale refers to the fact that the workflow service is able to manage scaling up and down of the required system capacity whenever it is necessary. This is a typical trait of cloud solutions. This advantage applies to Office 365 only.
Activity / Workflow Artifact Management There are also new capabilities for managing activities and workflows in the system. You can upload your activity via a REST API or client library, and the activities are stored in a scaled out, reliable repository. The relations between the activities, workflow definitions and the versions of the workflow definitions are also managed.
Tracking and Monitoring There are several ways to monitor your workflow including:
Performance Counters Performance counters are grouped by counter sets. There are two counters sets available: Workflow Management and Workflow Dispatcher. Figure 5 shows the Performance Monitor. The available performance counters for workflows are:
Management requests per second
Workflow events per second
Management request failures per second
Authorization errors per second
Publish workflow event duration
Episodes outstanding
Episodes failed per second
Events processed per second
Figure 5 Relevant SharePoint 2013 workflow performance counters available via the PerfMon tool.
Event Tracing Event Tracing for Windows (ETW) is used for tracing since this has the least overhead in terms of performance. The Event Tracing for Windows provider is called Microsoft-Workflow and the following channels are used: Operational, Debug, and Analytic. You can find a complete list of events generated by Windows Azure Workflow (version 1.0) at the following location: [InstallDrive]\Program Files\ Windows Azure Workflow\1.0\Workflow.
PowerShell Using PowerShell you can easily administrate your workflow server. There are a couple of PowerShell cmdlets provided by Windows Azure Workflow that you can use to check the state of the workflow server and the health status. You must pay specific attention to two cmdlets: Get-WFFarm and Get-WFFarmStatus. The Get-WFFarm cmdlet provides a quick overview of details about your workflow farm, the hosts in your farm, and the endpoints on those hosts. The Get-WFFarmStatus cmdlet provides an overview of the basic status of the farm and the various nodes within the farm.
System Center Operations Manager Management Pack This specific SCOM pack for Windows Azure Workflow allows you to leverage SCOM as an alerting mechanism that activates whenever a workflow failure is detected.
Instance Management The hosting and management part of the workflow service and its instances are more advanced compared to SharePoint 2010.
Fully Declarative Authoring This includes fully declarative authoring of workflows via an expanded activity library, expression translation and a new declarative data modeling feature.
REST and Service Bus Messaging For REST and Service Bus Messaging, there are integrated messaging capabilities available. These messaging capabilities are integrated with the hosting runtime to ensure that inbound and outbound messages are coordinated with workflow persistence to guarantee the reliability and integrity of your processes.
Managed Service Reliability All capabilities are provided as part of a managed service offering, which delivers the reliability and service availability that your business demands. This includes service health monitoring and management, performance and scale management, 24×365 operations support, fault tolerant design, cross-data center disaster recovery, service and platform upgrades and management, and standards compliance. This advantage applies to Office 365 only.
Windows PowerShell cmdlets that manage workflow With the Get-SPDesignerSettings PowerShell cmdlet you can retrieve the SharePoint Designer 2013 settings that are enabled on a specific web application:
Get-SPDesignerSettings [-WebApplication] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>]
You can also set the SharePoint Designer 2013 features of a specific web application by using the Set-SPDesignerSettings cmdlet:
Set-SPDesignerSettings [-WebApplication] <SPWebApplicationPipeBind> [-AllowDesigner <$true | $false>] [-AllowMasterPageEditing <$true | $false>] [-AllowRevertFromTemplate <$true | $false>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ShowURLStructure <$true | $false>] [-WhatIf [<SwitchParameter>]]
Creating and Deploying Workflows in SharePoint Designer 2013
We will take a quick tour on how to create workflows in SharePoint Designer 2013 and show you how to deploy the workflows to SharePoint 2013. In this tour, you will also learn how to import a workflow created using Visio 2013 into SharePoint Designer 2013 and how to export a workflow created in SharePoint Designer 2013 to Visio 2013.
1. Open SharePoint Designer 2013 and open a SharePoint site.
2. You can either create a new workflow or edit an existing workflow. If you’re going to edit an out of the box existing workflow we advise you to make a copy of the original workflow. You can use one of the following options to create a new workflow or edit an existing one:
· On the New group of the Site tab of the Ribbon, you can create a new List Workflow, Reusable Workflow, or Site Workflow.
· By selecting the File tab of the Ribbon you will also have the choice to create a new List Workflow, Reusable Workflow, or Site Workflow.
· Select Workflows under Site Objects in the Navigation Pane. By selecting the New group of the Workflow tab of the Ribbon, you can create a new List Workflow, Reusable Workflow, or Site Workflow. Here you can also select an existing workflow and edit the workflow by selecting Edit Workflow on the Edit group of the Workflow tab. Or you just right click the workflow you want to edit and select Edit Workflow.
3. Open SharePoint Designer 2013 and open a SharePoint site.
4. Regardless which type of workflow you want to create, you always have to specify the Name and Description (optional) for the new workflow. For a new reusable workflow, you also have to select the content type you want to limit the workflow to. Other than that, you also have to make sure that you select the SharePoint 2013 Workflow platform type.
5. The next step is to create the workflow. SharePoint Designer 2013 contains a various set of Conditions and Actions you can add. You can also add Steps, Loops, and Parallel Blocks.
6. You can edit the settings for the workflow via the Manage group of the Workflow tab of the Ribbon. Here you can edit, for example, the workflow information, the settings of the workflow as well as other options.
For each task that you add to the workflow via a Task action, it is possible to set the task properties such as the description of the task, specify if you want to wait for task completion, and define various email options. Regarding these email options, you should know that you can specify the frequency of the email: daily, weekly, or monthly, how many times you want an overdue email to be sent and, last but not least, you can customize the Task Creation Email and the Task Overdue Email. See Figure 6 for a sample Task Creation Email edit window.
Note Customizing the tasks Task Creation Email and Task Overdue Email are certainly not the least interesting option. The ability to specify custom email messages is a popular request for almost every customer. In previous versions, this used to be more work, but in SharePoint 2013 this has become really easy.
7. After creating the workflow you can check if there are any errors. You can do this by selecting the Check for Errors menu item on the Save group of the Workflow tab.
8. If there are no errors in your workflow you can publish the workflow via the Save menu item on the Save group of the Workflow tab.
Figure 6 Creating a custom email message has become really easy.
Importing workflows from Visio 2013
It is possible to model a workflow using Visio 2013 by making use of visual building blocks, save the workflow and import this workflow into SharePoint Designer 2013. The following procedure shows you how to import a Visio 2013 workflow in SharePoint Designer 2013.
See Also See section “Visio 2013” for more information about creating Visio 2013 workflows.
1. Open SharePoint Designer 2013 and open a SharePoint site.
2. Select Workflows under Site Objects in the Navigation Pane.
3. Select Import from Visio from the Manage group of the Workflow tab of the Ribbon. This opens the Import Workflow From Visio dialog box.
4. Click Browse and select your Visio SharePoint workflow diagram and click Open.
5. Select the kind of workflow that you want to import and depending on what type of workflow you have selected you have to choose a list or a content type to associate the workflow to.
6. Click Finish.
At this point you have imported a Visio 2013 workflow in SharePoint Designer 2013 and you can edit this workflow. Then, you can start defining values for the actions and conditions that you’ve created with Visio 2013. Once you’re finished, you can publish this workflow to SharePoint 2013.
Note As a quick reminder: further configuration and workflow publication is something that can’t be done in Visio 2013 itself. This is a design choice by Microsoft: business analysts are supposed to be knowledgeable about business processes, not about SharePoint. Microsoft doesn’t want to force this audience to become SharePoint specialists before you are able to leverage their knowledge.
Exporting workflows to Visio 2013
Because SharePoint Designer 2013 contains a Visual Designer that is based upon Visio 2013, it is possible to export your workflow made in SharePoint Designer 2013 to Visio 2013 format. This is a great way to validate a workflow design and gather input from business analysts. The next procedure shows you how to export a SharePoint Designer 2013 workflow to Visio 2013 format.
1. Open SharePoint Designer 2013 and open a SharePoint site.
2. Select Workflows under Site Objects in the Navigation Pane.
3. Select Export to Visio from the Manage group of the Workflow tab of the Ribbon.
4. The Export Workflow to Visio Drawing dialog box opens, select a location where you want to save your Visio drawing, enter a name and click Save.
At this point, you’ve saved your SharePoint Designer 2013 workflow as a Visio drawing. You can now open Visio 2013 and select the workflow. You can edit the workflow and change the shapes, save the workflow or export it to work on it again in SharePoint Designer 2013.
Visual Studio 2012
Using Visual Studio 2012, you can create declarative workflows. Visual Studio 2012 contains a visual workflow designer surface to create workflows in a designer environment. For Visual Studio developers, the most significant change is that workflows are no longer compiled and deployed as .NET framework assemblies. Instead, Visual Studio 2010 creates XAML documents that are interpreted directly by the workflow engine.
Workflows are designed to run on WAW and work with Apps for SharePoint. For on-premises farms, the WAW servers also run on premises. For Office 365, WAW runs in the cloud (Azure). Running workflows on WAW enables you to remotely run and host workflows outside SharePoint Server. The workflows no longer make use of InfoPath forms, only ASP.NET forms are used. There is no distinction between state or sequential workflows anymore, as stages (discussed previously) can be used to create state workflows if needed.
Workflows now have their own identity, the App identity or App principal, which it gets as a result from the new SharePoint App model where workflows are now considered to be Apps, just like lists, libraries, events, and such. The reverse is also true: custom Apps can include custom logic as well as contain SharePoint workflows and leverage that as part of its custom logic. So, SharePoint 2013 workflows are Apps, not all Apps are SharePoint 2013 workflows, and some Apps contain SharePoint 2013 workflows. If workflows are part of another App, they run under the App identity of that App instead of having their own App identity.
The default access scope of a workflow is read/write permissions to the host site (which can be checked via Site Settings > Site App Permissions, then look at the Workflow App Display Name). If workflows run as part of another App, they run under the permissions granted to that App.
By default, when workflows access SharePoint resources, both the Workflow App identity and the end user have to have access in order for the action to succeed. Alternatively, workflows can be created that use so-called App Step actions (also available within SharePoint Designer), that are placed within Stages. Any action placed within an App Step succeeds if the Workflow App identity has sufficient permissions to complete the action, regardless of whether the end user has access or not. This is the SharePoint 2013 way of elevating end user privileges. App Steps are only available if the Workflows can use app permissions site feature is activated.
Note It’s a remarkable move that InfoPath forms are no longer used in workflows. InfoPath in combination with Forms Services is a great platform that makes it quite easy to create robust and nice looking web forms. I’ve found that one of the places where InfoPath really shines was within SharePoint workflows. InfoPath forms are rendered to HTML by Forms Services, running as a service within your SharePoint farm. To me, this is just another example of the clear trend where Microsoft tries to move custom code outside of your SharePoint environment.
If you want to create a workflow using Visual Studio 2012 you first have to create a SharePoint 2013 project, as shown in Figure 7.
Figure 7 Start developing a SharePoint workflow by creating a SharePoint 2013 solution within Visual Studio 2012.
After the creation of a SharePoint 2013 project you have to add a new workflow item to the project. When you have done this, the designer surface will open, as shown in Figure 8.
Figure 8 The workflow designer surface in Visual Studio 2012.
As stated earlier you can only write no-code workflows using Visual Studio 2012. If you want to write custom code for your 2013 workflow you’re supposed to create a custom WCF service and call that service from the new HTTP activities that are available, such as:
· HttpDelete An activity for sending an HTTP Delete request (a request to delete a server resource) and receiving an HTTP response.
· HttpGet An activity for sending an HTTP get request (a request for retrieving a server resource) and receiving an HTTP response.
· HttpMerge An activity for sending an HTTP merge request (a request for updating a server resource) and receiving an HTTP response.
· HttpPost An activity for sending an HTTP post request (a request for submitting information to the server) and receiving an HTTP response.
· HttpPut An activity for sending an HTTP put request (a request for creating a server resource if it doesn’t already exist, or update an existing server resource) and receiving an HTTP response.
Visual Studio 2012 also contains a workflow custom action-item type to create a custom activity. This custom activity can also be imported in SharePoint Designer 2013 (see Figure 9).
Figure 9 Creating a custom workflow activity.
Setting up and configuring SharePoint 2013 workflows
You can enable workflows in SharePoint 2013 without thinking about security and configurations, but that should be contrary to all of your administrator instincts. In the next sections, you will learn how to set up SharePoint workflow configuration.
Enable or disable user-defined workflows
As an administrator you’re able to decide if you want to allow users to deploy declarative workflows on a specific web application. By default, users can deploy declarative workflow to a SharePoint 2013 site. These are workflows that are created using SharePoint Designer 2013 or Visual Studio 2012. There are some scenarios where you don’t want users to deploy workflows without you, the administrator, knowing about it. The following procedure shows you how to enable or disable the deployment of declarative workflows.
1. Go to SharePoint 2013 Central Administration.
2. In the section Application Management, click Manage web applications.
3. Select the web application for which you want to change the user defined workflow settings.
4. Go to the Web Applications tab in the Manage section, click General Settings and select Workflow.
5. The Workflow Settings dialog box opens and contains the following settings (see Figure 10):
· Yes – enable user-defined workflows for all sites on this web application.
· No – disable user-defined workflows for all sites on this web application.
6. Click OK to close the Workflow Settings dialog box.
Figure 10 Inspect available workflow settings.
Configuring task notifications
SharePoint wouldn’t be as effective if end users would have to go and actively find out if there are any tasks waiting for them. Typically, end users will be notified when tasks are awaiting them. An interesting case and security issue arises when internal end users get task assignments within sites where they don’t actually have sufficient permissions, or when external end users get task assignments. As an administrator, there are several generic task notification settings surrounding these issues you can set per web application. The following procedure demonstrates how to specify these settings:
1. Open SharePoint 2013 Central Administration.
2. In the section Application Management, click Manage web applications.
3. Select the web application for which you want to configure the task notification settings.
4. Go to the Web Applications tab in the Manage section, click General Settings and select Workflow.
5. The Workflow Settings dialog box opens and contains the following settings:
· Yes – alert internal users who do not have site access when they are assigned a workflow task.
· No – do not alert internal users who do not have site access when they are assigned a workflow task
· Yes – allow external users to participate in workflow by sending them a copy of the document.
· No – do not allow external users to participate in workflow by sending them a copy of the document.
6. Click OK to close the Workflow Settings dialog box.
Configuring Workflow timer jobs
Timer jobs run by themselves according to a specific predefined schedule, or are started manually. When timer jobs are executed, they run in a specific Windows service, the SharePoint 2013 Timer service (SPTimerV4), on (depending on the timer job configuration) one or more SharePoint servers within your farm. A timer job contains a definition of the service to run and specifies how frequently the service is started. The following timer jobs are related to workflows: Workflow Auto Cleanup, Workflow, and Workflow Failover. Timer job schedules can also be specified via Windows PowerShell.
The following PowerShell cmdlets are available for timer jobs:
Disable-SPTimerJob The name speaks for itself, this cmdlet disables a timer job. The syntax is as follows (where Identity specifies the timer job to disable, this can be the GUID of the timer job, the name of the timer job, or an instance of a valid time job object):
Disable-SPTimerJob [-Identity] <