Основные сведения о рабочих процессах SharePoint

В этой статье представлен высокоуровневый обзор инфраструктуры рабочих процессов в SharePoint, в том числе описание архитектуры платформы и мост взаимодействия рабочих процессов.

Примечание.

Рабочий процесс SharePoint 2013 устарел с апреля 2023 г. и будет отключен для новых клиентов 2 апреля 2024 г. Она будет удалена из существующих клиентов и будет полностью прекращена со 2 апреля 2026 г. Если вы используете рабочий процесс SharePoint 2013, рекомендуется переходить на Power Automate или другие поддерживаемые решения. Дополнительные сведения см. в статье Прекращение использования рабочих процессов SharePoint 2013 в Microsoft 365. Поддержка рабочих процессов SharePoint 2010 для новых клиентов прекращена с 1 августа 2020 г., и они удалены из существующих клиентов 1 ноября 2020 г. Если вы используете рабочие процессы SharePoint 2010, рекомендуется перейти на Power Automate или другие поддерживаемые решения. Дополнительные сведения см. в статье Прекращение поддержки рабочего процесса SharePoint 2010.

Обзор рабочего процесса в SharePoint

Рабочие процессы SharePoint основаны на платформе Windows Workflow Foundation 4, которая была существенно переработана по сравнению с предыдущими версиями. Windows Workflow Foundation (WF), в свою очередь, основана на функциях обмена сообщениями, предоставляемых Windows Communication Foundation (WCF).

По сути, модель рабочие процессы моделируют структурированные бизнес-процессы. Поэтому рабочие процессы Windows Workflow Foundation 4 — это структурированная коллекция "действий" рабочего процесса, каждое из которых представляет функциональный компонент бизнес-процесса.

Платформа рабочих процессов в SharePoint использует модель действий Windows Workflow Foundation 4 для представления бизнес-процессов на основе SharePoint. Кроме того, в SharePoint реализована высокоуровневая модель "шлюз-стадия", на основе которой создаются рабочие процессы.

Важно отметить связь между действиями рабочего процесса идействиями SharePoint. Действия рабочего процесса представляют базовые управляемые объекты, методы которых определяют поведение рабочего процесса. С другой стороны, действия рабочего процесса — это оболочка, инкапсулирующая базовые действия и представляющая их в понятное SharePoint Designer форме. Создатели рабочих процессов взаимодействуют с действиями рабочего процесса, в то время как модуль выполнения рабочих процессов работает на основе соответствующих действий.

Действия, т. е. реализация классов действий, декларативно реализуются с помощью XAML.

Действия рабочих процессов вызываются с помощью слабосвязанных веб-служб, использующих API-интерфейсы для взаимодействия с SharePoint. Эти API основаны на функциях обмена сообщениями, предоставляемых Windows Communication Foundation (WCF).

Инфраструктура обмена сообщениями очень гибкая и поддерживает практически любой шаблон обмена сообщениями, который вам может понадобиться. Обратите внимание, что в ферме SharePointWindows Workflow Foundation и WCF размещены в Workflow Manager Client 1.0.

Workflow Manager Client 1.0, SharePoint и SharePoint Designer 2013 предоставляют важные компоненты новой инфраструктуры:

  • Workflow Manager Client 1.0 обеспечивает управление определениями рабочих процессов. В нем также размещаются процессы выполнения экземпляров рабочих процессов.

  • SharePoint предоставляет платформу для рабочих процессов SharePoint, которые моделируют бизнес-процессы на основе SharePoint, связанные с документами, списками, пользователями и задачами SharePoint. Кроме того, рабочие процессы, сопоставления, действия и другие метаданные рабочих процессов SharePoint хранятся и контролируются в SharePoint.

  • SharePoint Designer 2013 — это основное средство, с помощью которых бизнес-пользователей создают определения рабочего процесса и публикуют их, как и в предыдущих версиях. Оно также используется для упаковки определения рабочего процесса со связанными компонентами SharePoint или без них.

Архитектура платформы

На рисунке 1 показано высокоуровневое представление платформы рабочих процессов SharePoint. Во-первых, обратите внимание на то, как новая инфраструктура рабочих процессов представляет Workflow Manager Client 1.0 в качестве нового узла выполнения рабочего процесса. В предыдущих версиях выполнение рабочего процесса размещалось в самой SharePoint, но в SharePoint это изменилось. Workflow Manager клиент 1.0 является внешним по сравнению с SharePoint и обменивается данными по общим протоколам через служебную шину Microsoft Azure при посредничестве OAuth. В противном случае SharePoint включает функцию, которая будет отображаться: элементы содержимого, события, приложения и т. д. Но обратите внимание, что существует также реализация узла рабочего процесса SharePoint 2010 (то есть подсистемы Windows Workflow Foundation 3) для обратной совместимости. Дополнительные сведения об этом см. в статье Использование взаимодействия рабочих процессов для SharePoint.

Рис. 1. Высокоуровневая архитектура инфраструктуры рабочих процессов

Высокоуровневая архитектура рабочего процесса

Workflow Manager Client 1.0 представлен в SharePoint в виде прокси приложения-службы Workflow Manager Client 1.0. Этот компонент позволяет SharePoint взаимодействовать с сервером Workflow Manager Client 1.0. Межсерверная проверка подлинности выполняется с помощью OAuth.

События SharePoint, для которых прослушивается рабочий процесс, например itemCreated, itemUpdated и т. д., направляются в Workflow Manager client 1.0 с помощью служебной шины Microsoft Azure. Для обратного вызова SharePoint платформа использует API REST SharePoint.

Существуют также дополнения к объектной модели рабочих процессов SharePoint, которая называется совместно диспетчером служб рабочих процессов, что позволяет управлять рабочими процессами и их выполнением и управлять ими. Основными зонами взаимодействия диспетчера служб являются развертывание, обмен сообщениями, управление экземплярами и (для обратной совместимости) взаимодействие с рабочими процессами SharePoint 2010.

Наконец, существует компонент создания рабочих процессов. Теперь SharePoint Designer может создать и развертывать рабочие процессы SharePoint 2010 и SharePoint. Visual Studio 2012 не только предоставляет поверхность разработки для создания декларативных рабочих процессов, но и позволяет создавать Надстройки SharePoint и решения, которые полностью интегрируются с Workflow Manager Client 1.0.

Подписки и сопоставления рабочих процессов

Поскольку наиболее значительное изменение рабочих процессов SharePoint — это перемещение обработки рабочих процессов на внешние узлы, такие как Microsoft Azure, было крайне важно связать сообщения и события SharePoint с инфраструктурой рабочих процессов в Microsoft Azure. Кроме того, в Microsoft Azure было необходимо связать инфраструктуру с данными клиента. Сопоставления рабочих процессов (основанные на концепции подписок WF) — это компоненты инфраструктуры SharePoint, которые поддерживают эти требования.

Служба публикации и подписки Microsoft Azure

Перед обсуждением сопоставлений и подписок рабочих процессов необходимо изучить службу публикации и подписки Microsoft Azure, которую иногда называютpub/sub (PubSub). PubSub — это асинхронная платформа обмена сообщениями. Отправители сообщений (издатели) не передают сообщения напрямую получателям (подписчикам). Вместо этого сообщения обрабатываются издателями как классы без каких-либо сведениях о подписчиках. Затем подписчики определяют интересующие их сообщения, независимо от издателя, основываясь на созданных подписках.

Это разделение создания сообщений от потребления сообщений обеспечивает масштабируемость и гибкость. Он включает многоадресную рассылку сообщений на стороне издателя и для неразборчивого потребления сообщений на стороне подписчика.

Примечание.

PubSub — это компонент служебной шины Microsoft Azure, который обеспечивает возможности подключения для WCF и других конечных точек службы. К ним относятся конечные точки REST, которые могут быть расположены за границами преобразования сетевых адресов (NAT) или могут быть привязаны к часто изменяющимся, динамически назначаемым IP-адресам (или и то, и другое). Дополнительные сведения о Служебная шина Azure см. в разделе Служебная шина.

Сопоставления рабочих процессов и область сопоставлений

Сопоставления рабочих процессов связывают определения рабочих процессов с областью SharePoint и определенными значениями по умолчанию. Сами связи представляют собой набор правил подписки, хранящихся в службе публикации или подписки Azure, которые обрабатывают входящие сообщения, чтобы убедиться, что они используются соответствующими (то есть подписанными) экземплярами рабочих процессов.

По умолчанию инфраструктуры обмена сообщениями поддерживает рабочие процессы в следующих областях:

  • SPList (для рабочих процессов списка);

  • SPWeb (для рабочих процессов сайта).

В отличие от предыдущих версий SharePoint не поддерживает рабочие процессы, относящиеся к типу контента ( SPContentType ). Тем не менее, инфраструктура обмена сообщениями расширяема, поэтому она может поддерживать произвольные области. Разработчик может задать в свойстве EventSourceId экземпляра WorkflowSubscription любой идентификатор guid. Затем это значение EventSourceId можно использовать для вызова PublishEvent(Guid, String, IDictionary<String, Object>), который активирует новый экземпляр рабочего процесса указанного WorkflowSubscription.

Служба рабочих процессов в Microsoft Azure

Сопоставления рабочих процессов SharePoint представляются службой рабочих процессов в Microsoft Azure. Если приложению требуется получить сопоставление рабочего процесса и его данные, сначала оно запрашивает все службы рабочих процессов, доступные в заданной области.

Аналогичным образом экземпляры рабочих процессов содержат указатель на соответствующую службу рабочих процессов. С его помощью определяется правильное сопоставление.

Запуск рабочих процессов

Рабочие процессы можно запустить вручную или автоматически.

Ручные рабочие процессы

Ручные рабочие процессы запускаются, когда служба PubSub получает сообщение StartWorkflow. Оно содержит следующие сведения:

  • Идентификатор сопоставления (т. е. экземпляр WorkflowSubscription).

  • Идентификатор исходного контекста элемента. Он передается с параметром ItemId и свойством EventSource при вызове метода PublishEvent .

  • Тип события для запуска вручную ( WorkflowStart).

  • Дополнительные параметры запуска рабочих процессов (из подписки или формы Init). Это может быть CorrelationId для подписки или WFInstanceId для формы Init.

Рабочие процессы с автоматическим запуском

Рабочие процессы с автоматическим запуском инициируются с помощью сообщения Add, передаваемого службе PubSub. Оно содержит следующие сведения:

  • Идентификатор исходного контекста элемента.

  • Само событие это обычное событие SharePoint Add.

  • Параметры инициации рабочих процессов.

Примечание.

Если рабочий процесс запускается автоматически для повторяющегося события (например, OnItemChanged), он не может запустить другой рабочий процесс данного сопоставления до завершения выполнения существующего экземпляра рабочего процесса сопоставления.

Подписки рабочих процессов

Естественным дополнением сопоставлений служат подписки, которые позволяют рабочему процессу взаимодействовать с сопоставлениями. Рабочий процесс должен создать подписки в шине обслуживания Azure с помощью методов create и delete.

Сигнатуры методов, которые создают подписки и экземпляр рабочего процесса, определяют обязательные и необязательные параметры. Списки параметров указывает автор рабочего процесса, поэтому они могут отличаться для разных определений рабочих процессов. Список параметров подписки указывается в виде метаданных в определениях рабочих процессов. Параметры подписки предоставляются при ее создании. Список параметров инициализации указывается в XAML как часть определения рабочего процесса. Параметры инициализации предоставляются при создании экземпляра рабочего процесса.

Подписки привязаны к определенному объекту SharePoint (экземпляру SPList или экземпляру SPWeb). Тип объекта подписки передается как значение обязательного параметра при создании подписки. Тип объекта определяет область подписки, чтобы последняя реагировала только на события, происходящие в объекте, на который есть подписка.

Взаимодействие рабочих процессов SharePoint

Взаимодействие рабочих процессов SharePoint позволяет вызывать рабочие процессы SharePoint 2010 (основанные на Windows Workflow Foundation 3) из рабочих процессов SharePoint, которые основаны на Windows Workflow Foundation 4. Это позволяет выполнять рабочие процессы SharePoint 2010 из рабочих процессов SharePoint.

Это важно, так как у вас может быть среда SharePoint 2010, которую вы можете использовать повторно вместе с рабочими процессами SharePoint. Кроме того, вы можете использовать действия или функции SharePoint 2010, который еще не реализованы в SharePoint

Полное обсуждение взаимодействия с рабочими процессами SharePoint см. в статье Использование взаимодействия рабочих процессов для SharePoint.

См. также