Workflow architecture in SharePoint Server 2013: yesterday and today
SharePoint workflows provide efficient space through structured, automated workflows that include interactive user interactions, if necessary. They provide notification mechanisms, email notifications, or any other activity relevant to employees.
The key objects of workflows are elements of lists, SharePoint libraries, content types, sites, because virtually any business process involves at any stage accessing content, retrieving it and processing data about it, making decisions on further actions within the process based on processing results.
The SharePoint platform provides users and programmers with a rich set of tools for developing workflows, as well as services and protocols for interaction between components, providing comprehensive support for the full life cycle of workflows.
The following describes the architecture of the SharePoint 2013 workflow platform, its differences and advantages compared to SharePoint 2010, gives an overview of all major components and the relationships between them.
')
In SharePoint 2010, workflows are based on the Windows Workflow Foundation 3.5 (WF) platform, which provides programming infrastructure, application development and execution tools.
In fact, SharePoint 2010 contains a workflow runtime environment ( Workflow Runtime ) and provides its own private implementation of its services. Thus, workflows are tightly integrated with the SharePoint 2010 environment and cannot be moved beyond it.
Figure 1. WF workflow architecture in SharePoint 2010
The workflow runtime integrates with SharePoint 2010 automatically during the installation of the farm, and all of its components are stored in the SharePoint content database on SQL Server. SharePoint 2010 workflows are available and work the same way across SharePoint editions — SharePoint Foundation 2010, SharePoint Server 2010.
Figure 2. Workflow data storage in SharePoint 2010
The SharePoint 2010 workflow architecture has several significant flaws, for example:
The SharePoint 2013 workflow platform uses Workflow Manager ( Workflow Manager ), which operates on the basis of WF 4.0 workflows. In turn, WF is part of the .NET Framework 4.5.
Workflow Manager is a powerful new service that can be used by many different applications, including SharePoint Server 2013. One of the main ideas for developing a new platform is to provide full-featured workflow functionality to users of SharePoint Server 2013 without being tied to the platform itself. . This approach made it possible to solve the performance, resiliency and scalability problems of SharePoint Server 2013 and the workflow manager independently of each other.
Figure 3. Overall architecture of the SharePoint 2013 workflow platform
SharePoint 2013 uses a dispatcher, responsible only for supporting workflow models and implementing action logic. Fundamental to the new architecture is the transfer of processes to the dispatcher's side, which allows them to be moved out of the SharePoint 2013 farm, ensuring fully independent use of server resources.
What is important is that the workflow manager is a completely independent software product that must be downloaded, installed and configured, after which it will be connected to the SharePoint farm.
SharePoint Server 2013 uses a specialized program interface (Application Program Interface, API) to interact with the workflow manager. All the necessary set of components for this is included in the corresponding client (English Workflow Manager Client ). In this case, all calls are implemented through the service bus (eng. Service Bus).
The SharePoint 2013 workflow platform is based on the cloud application model. At the same time, the workflow manager can be installed on a separate server in the internal network infrastructure of companies (eng. On-premises ) and deployed as a service in Windows Azure.
Note that in practice, companies often deploy a workflow manager and a service bus for Windows Server on SharePoint servers in their internal network infrastructure.
The second important point is that the customization of SharePoint 2013 workflows is available only in server editions, i.e. in SharePoint Server 2013 Standard and SharePoint Server 2013 Enterprise.
Figure 4. The architecture of the workflow platform in the company's internal network infrastructure
Figure 5. Workflow platform architecture in Windows Azure
We list the main advantages of the new workflow architecture:
The following components of the SharePoint 2013 workflow architecture are discussed in more detail.
general characteristics
Windows Workflow Foundation (WF) is a Microsoft technology that provides support for the life cycle of workflows: definition, development, execution, and management. (English workflow). WF provides programming infrastructure, development tools, and execution of workflow-based applications.
Figure 6. Windows Workflow Foundation architecture
Table 1. Main components of the Windows Workflow Foundation architecture
Workflows WF is a structured collection of “activities” (eng. Activities ), each of which represents a functional component of a business process.
Figure 7. Sample Workflow Developer Dashboard for SharePoint 2013 in MS Visual Studio 2013
The SharePoint Server 2013 platform provides an additional set of development tools, greatly expanding the standard WF features:
Figure 8. Sample workflow actions in SharePoint Designer
Figure 9. Fragment of the workflow in SharePoint Designer
It is important to note the link between WF workflow actions and SharePoint Server 2013 actions available for selection in SharePoint Designer 2013 (SPD 2013). WF workflow actions represent basic managed objects whose methods determine the workflow behavior.
Workflow actions in SPD 2013 are a wrapper that encapsulates the basic actions of WF and represents them in an understandable form of SPD 2013.
The creators of the workflows during development in SPD 2013 interact with the workflow activities, while the workflow execution module works based on the corresponding WF actions.
Types of workflows
WF creates two types of workflows:
Sequential workflows (eng. Sequential workflow) follow a certain path. It may include decision branches and loops or no end point, but the development process easily tracks the predictable path.
Examples of sequential workflows running in a SharePoint Server 2013 environment:
Figure 10. An example of a sequential WF workflow in MS Visual Studio
A state machine workflow (workflow) is a set of states, transitions and actions. Actions are executed asynchronously, which means that they are not necessarily placed in a strict sequence, and can instead be activated by other actions and states. One state is set as initial, then (if a certain event occurs), a transition to another occurs.
A state machine can be set to determine the end of the workflow.
Figure 11. Sample WF Workflow Process
SharePoint Server 2013
SharePoint Server 2013 provides a platform for workflows that model business processes related to documents, lists, content types, users, tasks, and SharePoint sites. In addition, workflows, mappings, actions, and other metadata are stored and monitored in SharePoint 2013.
Workflow Manager Client
The Workflow Manager Client client provides the management of workflow definitions. This is a stand-alone software component that, after installation in the system, interacts with SharePoint using common messaging infrastructure protocols via the service bus.
Workflow Services Application Proxy
The workflow manager client is represented in SharePoint 2013 as a workflow service proxy (Eng. Workflow Service Application Proxy ). This component allows SharePoint to interact with the workflow manager server. Server-to-server authentication is performed using OAuth.
Workflow Services Manager
All the new features of SharePoint 2013 workflows are implemented in the SharePoint object model through the workflow service manager, which includes deployment, instance, interaction, and messaging services.
Deployment Service
The deployment service provides the implementation of the functionality of publishing workflows and establishing associations between them and SharePoint objects.
Service instances
Instance service is used to access workflow instances for information and management. For example, a user may cancel a workflow.
Interaction Service
The collaboration service is used to extract and launch instances of classic SharePoint 2010 workflows. It also supports two scenarios:
In both scenarios, the collaboration service supports the correct operation of the workflows themselves and the individual actions of SharePoint 2010 in a SharePoint 2013 environment, responsible for supporting the reconciliation process between the two environments.
SharePoint Designer 2013 provides access to the new action — the launch of the SharePoint 2010 workflow. From the WF point of view, it represents the sequence of sending messages between the manager and the SharePoint 2010 workflow host running on the SharePoint 2013 platform. The general sequence of actions is as follows:
Figure 12. Overview of workflow platform component interactions when running SharePoint 2010 workflows
Figure 13. Startup action of the SharePoint workflow in SharePoint Designer 2013
Figure 14. Startup options for SharePoint 2010 workflow in SharePoint Designer 2013
Messaging service
Information about events related to SharePoint objects is sent to the workflow manager through a messaging service. When SharePoint sends an event to a workflow, it is stored in the service bus database, and then delivered to the workflow manager. He is responsible for storing information about the status of each of them and synchronizing this information with messages stored in the service bus database.
The messaging service uses a publish / subscribe feature that allows multiple workflows to subscribe to the same event. For example, there are 10 workflows awaiting data changes in a SharePoint list item. If this event occurs, SharePoint will send only one message to the service bus, and it will be responsible for delivering this message to all 10 workflows that are subscribed to it. In the classic SharePoint 2010 workflow model, the SharePoint platform will have to handle all 10 events, which leads to additional load on the farm servers.
Workflow Manager and Service Bus
SharePoint Server 2013 events that are related to the execution of a workflow, such as creating a list / library item, updating a list / library item, are sent to the workflow manager server via the maintenance bus. For callback SharePoint, the workflow manager uses the SharePoint REST API.
The image below shows an example of the interaction between the workflow manager and the service bus during the execution of a simple SharePoint 2013 workflow.
Figure 15. High-level SharePoint Server 2013 workflow model. Assign a task to a user
Figure 16. High-level workflow model of SharePoint Server 2013. User execution of the task and saving the results
The author - Lyubov Volkova
The key objects of workflows are elements of lists, SharePoint libraries, content types, sites, because virtually any business process involves at any stage accessing content, retrieving it and processing data about it, making decisions on further actions within the process based on processing results.
The SharePoint platform provides users and programmers with a rich set of tools for developing workflows, as well as services and protocols for interaction between components, providing comprehensive support for the full life cycle of workflows.
The following describes the architecture of the SharePoint 2013 workflow platform, its differences and advantages compared to SharePoint 2010, gives an overview of all major components and the relationships between them.
')
SharePoint 2010 Workflow Platform
In SharePoint 2010, workflows are based on the Windows Workflow Foundation 3.5 (WF) platform, which provides programming infrastructure, application development and execution tools.
In fact, SharePoint 2010 contains a workflow runtime environment ( Workflow Runtime ) and provides its own private implementation of its services. Thus, workflows are tightly integrated with the SharePoint 2010 environment and cannot be moved beyond it.
Figure 1. WF workflow architecture in SharePoint 2010
The workflow runtime integrates with SharePoint 2010 automatically during the installation of the farm, and all of its components are stored in the SharePoint content database on SQL Server. SharePoint 2010 workflows are available and work the same way across SharePoint editions — SharePoint Foundation 2010, SharePoint Server 2010.
Figure 2. Workflow data storage in SharePoint 2010
The SharePoint 2010 workflow architecture has several significant flaws, for example:
- Impossibility of scaling for the purpose of load balancing and using fault tolerance management mechanisms independently of the servers of the SharePoint farm;
- Orientation to the introduction in the working environments of companies, a strong limited application in cloud environments.
SharePoint 2013 Workflow Platform
The SharePoint 2013 workflow platform uses Workflow Manager ( Workflow Manager ), which operates on the basis of WF 4.0 workflows. In turn, WF is part of the .NET Framework 4.5.
Workflow Manager is a powerful new service that can be used by many different applications, including SharePoint Server 2013. One of the main ideas for developing a new platform is to provide full-featured workflow functionality to users of SharePoint Server 2013 without being tied to the platform itself. . This approach made it possible to solve the performance, resiliency and scalability problems of SharePoint Server 2013 and the workflow manager independently of each other.
Figure 3. Overall architecture of the SharePoint 2013 workflow platform
SharePoint 2013 uses a dispatcher, responsible only for supporting workflow models and implementing action logic. Fundamental to the new architecture is the transfer of processes to the dispatcher's side, which allows them to be moved out of the SharePoint 2013 farm, ensuring fully independent use of server resources.
What is important is that the workflow manager is a completely independent software product that must be downloaded, installed and configured, after which it will be connected to the SharePoint farm.
SharePoint Server 2013 uses a specialized program interface (Application Program Interface, API) to interact with the workflow manager. All the necessary set of components for this is included in the corresponding client (English Workflow Manager Client ). In this case, all calls are implemented through the service bus (eng. Service Bus).
The SharePoint 2013 workflow platform is based on the cloud application model. At the same time, the workflow manager can be installed on a separate server in the internal network infrastructure of companies (eng. On-premises ) and deployed as a service in Windows Azure.
Note that in practice, companies often deploy a workflow manager and a service bus for Windows Server on SharePoint servers in their internal network infrastructure.
The second important point is that the customization of SharePoint 2013 workflows is available only in server editions, i.e. in SharePoint Server 2013 Standard and SharePoint Server 2013 Enterprise.
Figure 4. The architecture of the workflow platform in the company's internal network infrastructure
Figure 5. Workflow platform architecture in Windows Azure
We list the main advantages of the new workflow architecture:
- Multi-server hosting. It provides high efficiency and speed of execution of workflow instances combined with ease of management. Also among its advantages is a higher level of security, flexible scaling and load balancing between remote workflow manager servers.
- Scaling. Managing the development of workflows, the implementation of business logic and the formation of their instances on the farm side of SharePoint Server 2013 within the company's network infrastructure allows you to maintain the use of farm server resources at a constant level, and at the same time allocate resources on demand that are necessary for the immediate execution of workflows. In case of placing the workflow manager in Windows Azure, it becomes possible to add and remove resources as the workflow of processing processes grows or decreases, paying only for those resources that are currently needed.
- Advanced diagnostic and monitoring tools. New functionality for monitoring and diagnosing running workflow instances uses the REST API and the workflow manager client. System administrators are provided with a specialized set of tools, while clients can view data on the status and status of running workflows, flexible management of their configuration settings.
- Fully declarative development of workflows. This new concept was first used on the SharePoint platform. The main development tools for users of SharePoint Server 2013 are SharePoint Designer 2013, MS Visio 2013, MS InfoPath 2013. For developers, Visual Studio 2012/2013 provides a set of specialized project templates and a powerful toolkit for developing workflow actions. The workflow actions developed in MS Visual Studio are oriented for later use in SharePoint Designer 2013.
- Implementation in the form of web services. SharePoint Server 2013 workflow actions are invoked using loosely coupled web services that use a programming interface to interact with SharePoint. It is based on the Windows Communication Foundation (WCF) messaging features and the use of REST requests. Support for runtime, inbound and outbound communications coordinate all phases of workflow execution, ensuring integrity and reliability.
The following components of the SharePoint 2013 workflow architecture are discussed in more detail.
SharePoint 2013 Workflow Platform Components
Windows Workflow Foundation in a SharePoint Server 2013 environment
general characteristics
Windows Workflow Foundation (WF) is a Microsoft technology that provides support for the life cycle of workflows: definition, development, execution, and management. (English workflow). WF provides programming infrastructure, development tools, and execution of workflow-based applications.
Figure 6. Windows Workflow Foundation architecture
Table 1. Main components of the Windows Workflow Foundation architecture
| Component | Description |
| Host process | An application that includes the WF workflow runtime. The host process provides support for runtime services. |
| Act | Unit of work or a separate step of a business process. |
| The working process | The sequence of actions used to implement the business process. |
| Basic Action Library | A set of workflow action patterns used in development and included in WF. |
| Additional actions | Workflow actions developed by programmers. |
| Runtime environment | Workflow instances are executed by the runtime. It also controls the changing state of workflows and the interaction between them. |
| Designers | UI tools used for development. Visual Studio includes a dedicated WF designer. |
| Runtime services | Services that provide placement and interaction between workflow components |
Workflows WF is a structured collection of “activities” (eng. Activities ), each of which represents a functional component of a business process.
Figure 7. Sample Workflow Developer Dashboard for SharePoint 2013 in MS Visual Studio 2013
The SharePoint Server 2013 platform provides an additional set of development tools, greatly expanding the standard WF features:
- A web browser, such as Internet Explorer, Firefox, or Chrome, is a tool used to interact with SharePoint Server 2013 sites. For example, you can create lists and libraries, add items to them, associate workflow with them, run it for an individual item to check the status.
- MS Visio 2013, used to create diagrams using shapes and connectors. It can be used to create workflows based on the SharePoint 2013 platform. Then the processes can be imported from MS Visio 2013 to SharePoint Designer 2013 and vice versa.
- MS InfoPath 2013 - a tool designed to develop forms. Using it, you can customize the forms that users will need to interact with the workflow.
- SharePoint Designer 2013 is the primary means by which business users create workflow definitions and publish them, as in previous versions. It is also used to package workflow definitions with or without associated SharePoint components (such as lists, libraries, content types, sites). You can create custom workflow actions in Visual Studio and import them into SharePoint Designer 2013, where they are accessible from the workflow designer.
- Development tools in Visual Studio Action for use by Designer SharePoint Designer 2013.
Figure 8. Sample workflow actions in SharePoint Designer
Figure 9. Fragment of the workflow in SharePoint Designer
It is important to note the link between WF workflow actions and SharePoint Server 2013 actions available for selection in SharePoint Designer 2013 (SPD 2013). WF workflow actions represent basic managed objects whose methods determine the workflow behavior.
Workflow actions in SPD 2013 are a wrapper that encapsulates the basic actions of WF and represents them in an understandable form of SPD 2013.
The creators of the workflows during development in SPD 2013 interact with the workflow activities, while the workflow execution module works based on the corresponding WF actions.
Types of workflows
WF creates two types of workflows:
- Sequential workflows.
- Workflow finite state machine.
Sequential workflows (eng. Sequential workflow) follow a certain path. It may include decision branches and loops or no end point, but the development process easily tracks the predictable path.
Examples of sequential workflows running in a SharePoint Server 2013 environment:
- When you add a document to the SharePoint library, the workflow adds a new task to the SharePoint task list.
- When editing a task, the workflow performs a task property check to determine if it is complete. If execution is complete, the workflow also ends.
Figure 10. An example of a sequential WF workflow in MS Visual Studio
A state machine workflow (workflow) is a set of states, transitions and actions. Actions are executed asynchronously, which means that they are not necessarily placed in a strict sequence, and can instead be activated by other actions and states. One state is set as initial, then (if a certain event occurs), a transition to another occurs.
A state machine can be set to determine the end of the workflow.
Figure 11. Sample WF Workflow Process
SharePoint Server 2013
SharePoint Server 2013 provides a platform for workflows that model business processes related to documents, lists, content types, users, tasks, and SharePoint sites. In addition, workflows, mappings, actions, and other metadata are stored and monitored in SharePoint 2013.
Workflow Manager Client
The Workflow Manager Client client provides the management of workflow definitions. This is a stand-alone software component that, after installation in the system, interacts with SharePoint using common messaging infrastructure protocols via the service bus.
Workflow Services Application Proxy
The workflow manager client is represented in SharePoint 2013 as a workflow service proxy (Eng. Workflow Service Application Proxy ). This component allows SharePoint to interact with the workflow manager server. Server-to-server authentication is performed using OAuth.
Workflow Services Manager
All the new features of SharePoint 2013 workflows are implemented in the SharePoint object model through the workflow service manager, which includes deployment, instance, interaction, and messaging services.
Deployment Service
The deployment service provides the implementation of the functionality of publishing workflows and establishing associations between them and SharePoint objects.
Service instances
Instance service is used to access workflow instances for information and management. For example, a user may cancel a workflow.
Interaction Service
The collaboration service is used to extract and launch instances of classic SharePoint 2010 workflows. It also supports two scenarios:
- Your organization has old SharePoint 2010 workflows that need to be supported in a SharePoint 2013 environment.
- A SharePoint 2013 workflow has been developed, within which you need to ensure that actions that are only available in SharePoint 2010 are performed.
In both scenarios, the collaboration service supports the correct operation of the workflows themselves and the individual actions of SharePoint 2010 in a SharePoint 2013 environment, responsible for supporting the reconciliation process between the two environments.
SharePoint Designer 2013 provides access to the new action — the launch of the SharePoint 2010 workflow. From the WF point of view, it represents the sequence of sending messages between the manager and the SharePoint 2010 workflow host running on the SharePoint 2013 platform. The general sequence of actions is as follows:
- Business Process Manager starts workflow (1). The corresponding message is transmitted to the workflow service dispatcher (2).
- The Workflow Services Manager starts the workflow inside the SharePoint 2010 Workflow Host.
- The SharePoint 2010 workflow completion event or immediately after its launch (depending on the workflow properties) causes the corresponding message to be sent to the workflow manager (3).
- Through the event publisher (4) information about the completion of the SharePoint 2010 workflow is passed to the workflow manager (5).
- The overall interaction between the components of the SharePoint 2013 workflow platform is shown in the image below.
Figure 12. Overview of workflow platform component interactions when running SharePoint 2010 workflows
Figure 13. Startup action of the SharePoint workflow in SharePoint Designer 2013
Figure 14. Startup options for SharePoint 2010 workflow in SharePoint Designer 2013
Messaging service
Information about events related to SharePoint objects is sent to the workflow manager through a messaging service. When SharePoint sends an event to a workflow, it is stored in the service bus database, and then delivered to the workflow manager. He is responsible for storing information about the status of each of them and synchronizing this information with messages stored in the service bus database.
The messaging service uses a publish / subscribe feature that allows multiple workflows to subscribe to the same event. For example, there are 10 workflows awaiting data changes in a SharePoint list item. If this event occurs, SharePoint will send only one message to the service bus, and it will be responsible for delivering this message to all 10 workflows that are subscribed to it. In the classic SharePoint 2010 workflow model, the SharePoint platform will have to handle all 10 events, which leads to additional load on the farm servers.
Workflow Manager and Service Bus
SharePoint Server 2013 events that are related to the execution of a workflow, such as creating a list / library item, updating a list / library item, are sent to the workflow manager server via the maintenance bus. For callback SharePoint, the workflow manager uses the SharePoint REST API.
The image below shows an example of the interaction between the workflow manager and the service bus during the execution of a simple SharePoint 2013 workflow.
Figure 15. High-level SharePoint Server 2013 workflow model. Assign a task to a user
Figure 16. High-level workflow model of SharePoint Server 2013. User execution of the task and saving the results
The author - Lyubov Volkova
Source: https://habr.com/ru/post/266943/
All Articles