Общие сведения о Windows Workflow Windows Workflow Overview
Рабочий процесс — это набор элементов, которые называются действиями , которые хранятся в виде модели, описывающей реальный процесс. A workflow is a set of elemental units called activities that are stored as a model that describes a real-world process. Рабочие процессы позволяют описывать порядок выполнения этапов краткосрочных и долгосрочных работ, а также зависимости между этими этапами. Workflows provide a way of describing the order of execution and dependent relationships between pieces of short- or long-running work. Работа проходит по модели от начала и до конца, а действия могут выполняться как людьми, так и системными функциями. This work passes through the model from start to finish, and activities might be executed by people or by system functions.
Среда выполнения рабочих процессов Workflow Run-time Engine
Каждый работающий экземпляр рабочего процесса создается и обслуживается внутрипроцессной подсистемой среды выполнения, с которой ведущий процесс взаимодействует с помощью одного из следующих инструментов: Every running workflow instance is created and maintained by an in-process run-time engine that the host process interacts with through one of the following:
WorkflowInvoker, который вызывает рабочий процесс как метод. A WorkflowInvoker, which invokes the workflow like a method.
WorkflowApplication для явного управления выполнением одного экземпляра рабочего процесса. A WorkflowApplication for explicit control over the execution of a single workflow instance.
WorkflowServiceHost для взаимодействия с помощью сообщений в многоэкземплярных сценариях. A WorkflowServiceHost for message-based interactions in multi-instance scenarios.
Каждый из этих классов является оболочкой для среды выполнения основной операции, представленной как объект ActivityInstance, ответственный за выполнение операции. Each of these classes wraps the core activity runtime represented as a ActivityInstance responsible for activity execution. В домене приложения может быть несколько объектов ActivityInstance, работающих параллельно. There can be several ActivityInstance objects within an application domain running concurrently.
Каждый из трех предыдущих объектов взаимодействия узлов создается из дерева операций, называемого программой рабочего процесса. Each of the preceding three host interaction objects is created from a tree of activities referred to as a workflow program. Используя эти типы или пользовательский узел, который является оболочкой ActivityInstance , рабочие процессы могут выполняться внутри любого процесса Windows, включая консольные приложения, приложения на основе форм, службы Windows, веб-сайты ASP.NET и службы Windows Communication Foundation (WCF). Using these types or a custom host that wraps ActivityInstance, workflows can be executed inside any Windows process including console applications, forms-based applications, Windows Services, ASP.NET Web sites, and Windows Communication Foundation (WCF) services.
Компоненты рабочего процесса в хост-процессе Workflow components in the host process
Взаимодействие между компонентами рабочего процесса Interaction between Workflow Components
На следующей диаграмме показано взаимодействие компонентов рабочего процесса. The following diagram demonstrates how workflow components interact with one another.
На предыдущей диаграмме используется метод Invoke класса WorkflowInvoker для вызова нескольких экземпляров рабочего процесса. In the preceding diagram, the Invoke method of the WorkflowInvoker class is used to invoke several workflow instances. WorkflowInvoker используется для упрощенных рабочих процессов, не требующих управления с сервера. Рабочие же процессы, требующие управления с сервера (например, возобновление Bookmark), должны выполняться с помощью Run. WorkflowInvoker is used for lightweight workflows that do not need management from the host; workflows that need management from the host (such as Bookmark resumption) must be executed using Run instead. Чтобы вызвать экземпляр рабочего процесса, не обязательно ждать завершения другого. Среда выполнения допускает одновременное выполнение нескольких экземпляров рабочего процесса. It isn’t required to wait for one workflow instance to complete before invoking another; the runtime engine supports running multiple workflow instances simultaneously. Вызываются следующие рабочие процессы: The workflows invoked are as follows:
Действие Sequence, содержащее дочернее действие WriteLine. A Sequence activity that contains a WriteLine child activity. Переменная Variable родительского действия привязана к InArgument дочернего действия. A Variable of the parent activity is bound to an InArgument of the child activity. Дополнительные сведения о переменных, аргументах и привязке см. в разделе переменные и аргументы. For more information about on variables, arguments, and binding, see Variables and Arguments.
Настраиваемое действие ReadLine . A custom activity called ReadLine . OutArgument действия ReadLine возвращается в вызывающий метод Invoke. An OutArgument of the ReadLine activity is returned to the calling Invoke method.
Настраиваемое действие, происходящее от абстрактного класса CodeActivity. A custom activity that derives from the CodeActivity abstract class. CodeActivity может обращаться к возможностям среды выполнения (например, к отслеживанию и свойствам) с помощью CodeActivityContext, доступного в качестве параметра метода Execute. The CodeActivity can access run-time features (such as tracking and properties) using the CodeActivityContext that is available as a parameter of the Execute method. Дополнительные сведения об этих функциях времени выполнения см. в разделе Отслеживание рабочего процесса и Свойства выполнения рабочего процесса. For more information about these run-time features, see Workflow Tracking and Tracing and Workflow Execution Properties.
Windows Workflow Foundation Windows Workflow Foundation
В этом разделе описывается модель программирования, примеры и средства Windows Workflow Foundation (WF). This section describes the programming model, samples, and tools of the Windows Workflow Foundation (WF).
в этом разделе In This Section
Руководство по документации по рабочим процессам Windows Guide to the Windows Workflow Documentation
Список тем для ознакомления с учетом степени подготовленности (от новичка до хорошо ознакомленного с предметом разработчика) и требований. A set of suggested topics to read, depending upon your familiarity (novice to well-acquainted), and requirements.
Новые возможности в Windows Workflow Foundation (WF) What’s New in Windows Workflow Foundation
Описываются изменения некоторых парадигм разработки по сравнению с предыдущими версиями. Discusses the changes in several development paradigms from previous versions.
Новые возможности Windows Workflow Foundation в .NET 4.5 What’s New in Windows Workflow Foundation in .NET 4.5
Описывает новые возможности Windows Workflow Foundation в .NET Framework 4.6.1 .NET Framework 4.6.1 . Describes the new features in Windows Workflow Foundation in .NET Framework 4.6.1 .NET Framework 4.6.1 .
Особенности возможностей Windows Workflow Foundation Windows Workflow Foundation Feature Specifics
Описание новых функций в Windows Workflow Foundation в .NET Framework 4. Describes the new features in Windows Workflow Foundation in .NET Framework 4.
Общие сведения о рабочих процессах Windows Windows Workflow Conceptual Overview
Набор разделов, в которых обсуждаются более крупные понятия Windows Workflow Foundation. A set of topics that discusses the larger concepts behind Windows Workflow Foundation.
Учебник по началу работы Getting Started Tutorial
Набор пошаговых руководств, посвященных программированию Windows Workflow Foundation приложений. A set of walkthrough topics that introduce you to programming Windows Workflow Foundation applications.
Программирование в Windows Workflow Foundation Windows Workflow Foundation Programming
Основные темы, которые нужно изучить, чтобы стать профессиональным программистом WF WF . A set of primer topics that you should understand to become a proficient WF WF programmer.
Расширение Windows Workflow Foundation Extending Windows Workflow Foundation
Набор разделов, в которых обсуждается расширение или Настройка Windows Workflow Foundation в соответствии со своими потребностями. A set of topics that discusses how to extend or customize Windows Workflow Foundation to suit your needs.
Примеры Windows Workflow Windows Workflow Samples
Содержит образцы приложений, демонстрирующих функции и сценарии WF. Contains sample applications that demonstrate WF features and scenarios.
Обзор Windows Workflow Foundation на примере построения системы электронного документооборота [Часть 2]
Разработка системы документооборота – неподъемная задача для небольшой команды?
В предыдущем посте я рассмотрел архитектурные особенности WF, когда лучше применять эту технологию. В данной части передам, как применяется WF в конкретном проекте.
Итак, стоит задача реализовать систему электронного документооборота.
Для удобства разобью эту часть на несколько блоков.
Данный модуль был реализован с помощью технологии ASP.NET MVC. Позволяет создавать и редактировать различные типы документов, запускать потоки работ над ними. Обозначим его здесь, чтобы можно было ссылаться в будущем, но подробно рассматривать не будем.
Будем считать, что мы имеем классы-документы, реализующие примерно следующий общий интерфейс*:
*Здесь и далее для упрощения используется сильно урезанная версия production-кода.
Пользователи запускают активности по работе с документами (далее – Общие активности). Общие активности имеют 2 входных аргумента:
, здесь DocumentId – ключ документа, а UserId – ключ пользователя, запускающего активность.
Таким образом, в Общих активностях крутится только ключ документа, а не объект целиком, что поможет избежать проблем при восстановлении состояния сохраненных потоков работ, если нам в будущем потребуется модифицировать класс документа (добавить свойство, например).
Кроме того, к каждой Общей активности отдельно сохраняется некоторый набор метаданных: привилегии для запуска, типы документов, по которым разрешено запускать активность, Dynamic LINQ – выражение к документу для проверки возможности запуска и другие.
Общая активность – настраиваемая часть нашей системы – кодируется дизайнером потоков работ и сохраняется в виде XAML. Реализацию дизайнера рассмотрим ниже.
Далее приведу код по запуску активности в среде выполнения WF.
Тут требует пояснения один момент: для того, чтобы поток работ мог сохранить свое состояние в случае необходимости, среде выполнения с помощью Property Injection передается экземпляр класса хранилища SqlWorkflowInstanceStore.
Передача аргументов в поток работ
Итак, Общая активность запущена и работает. Но в какой-то момент ей могут понадобиться дополнительные данные от пользователей системы для своей работы. На основе этих данных в соответствии со своей логикой она выбирают ветку исполнения, изменяет свойства документа, производят отправку уведомлений, а также другие действия.
Следовательно, необходимо описать эти данные (далее – Аргументы). Здесь было 2 варианта. Описать один универсальный тип (коллекцию “ключ – значение”), который бы использовался при передаче любой информации в поток работ. Но я выбрал преимущества строгой типизации и реализовал динамически подгружаемую библиотеку пользовательских Аргументов. Классы реализуют интерфейс IAssignArgument:
, где UserId – ключ пользователя, производящего передачу Аргумента в поток работ.
Теперь перейдем к самой активности, которая ожидает получения входных данных. Для этих целей в базовой библиотеке активностей предусмотрен класс NativeActivity , где T – результат работы активности – наш Аргумент. Унаследуем наш класс от NativeActivity:
Как видно, эта активность на первом этапе сохраняет данные, необходимые для восстановления состояния в хранилище (ключ документа, ключ пользователя, на которого назначена задача, тип Общей активности, тип Аргумента, наименование действия, «закладку» для восстановления). На втором этапе получает входной Аргумент и передает его в out-параметр для использования в теле Общего потока.
Модуль работы с документами, в свою очередь, видит задачи, назначенные на пользователя, при запуске процесса восстановления потока работ динамически формирует view на основании типа Аргумента (при необходимости возможно задать custom view, конечно) получает Аргумент от пользователя и передает его для восстановления Общей активности.
Строгая типизация Аргументов (антипод – Argument[“Prop1”]) позволяет валидировать обращения к свойствам Аргумента на этапе построения активности в дизайнере.
Поток с нарушением правил приведения типов не запустится. То есть ошибки происходят на этапе компиляции, а не на этапе выполнения, буквально.
Далее приведу код по восстановлению потока работ.
Хотел бы разъяснить разницу между двумя видами свойств активности:
В первом случае фактическое значение свойства (это также относится и к OutArgument и Variable ) – участник процесса работы активности, может менять значение в процессе, сохранять и восстанавливать свое состояние в хранилище: элемент таблицы свойств активности в дизайнере – 
, атрибут активности в XAML – 
.
Во втором случае значение является константой – оно не меняется при работе активности. Удобно использовать для сохранения неизменяемых параметров активности в XAML: элемент таблицы свойств активности в дизайнере – 
, атрибут активности в XAML – 
.
Управление запуском дочерних активностей
Далее разберем активность для обновления объектов в хранилище. Здесь может быть масса вариантов. Для примера, реализуем ее в виде композиции из дочерних активностей. Для активностей, которые не требуют данных извне, в базовой библиотеке активностей также реализован специальный базовый класс CodeActivity.
Как видно, родительская активность, загружает объект из БД, запускает все дочерние активности в среде выполнения WF для изменения свойств объекта, а затем сохраняет изменения в хранилище. За счет универсальности типов активностей мы также имеем валидацию типов входных новых значений для свойств объекта в дизайнере.
Так эта активность может выглядеть в дизайнере.
Дизайнер потоков работ
Эта самая “вязкая” часть технологии, то есть, чтобы реализовать что-либо слегка выступающее за рамки, нам нужно «плясать и бить в бубен». 
Дизайнер строится по технологии WPF.
Основными элементом тут является WorkflowDesigner – графическая область в которой происходит конструирование рабочего потока.
Каждой активности можно сопоставить свой design-объект (в VS даже есть специальный тип проекта для разработки дизайна WF-элемента – Activity Designer Library) с помощью атрибута [Designer]. То же касается и свойств активности – атрибут [Editor]. То есть, ничего нового в этой части, фактически.
Код приводить не буду, так как сложно выявить что-то одновременно выделяющееся и достаточно компактное. За то приведу несколько ссылок.
Здесь замечательный пример по реализации дизайнера. Это модель того, как созданные активности, закодированные в XAML, можно сразу же использовать как строительные элементы в новых активностях. Особенность примера в том, что изменение в исходной активности не приводит к изменению алгоритмов всех активностей, где используется исходная. К сожалению, эта “фича” нас не устраивала.
А здесь серия отличных постов по WF с примерами (в частности, можно найти образец по подмене аргументов универсального типа в дизайнере). В случае необходимости, нужно будет меньше «прыгать с бубном», но все равно придется.
Как видим, разработка не очень сложна, система легко расширяется. При желании мы можем реализовать активность, которая управляет доступностью конкретных свойств документа для изменения, например, а в модуле ведения списков документов – поддержку этой функциональности.
Большая работа была в итоге проделана? Большая. Но по зубам ли она для небольшой команды? Да, даже для команды из 3-х — 4-х человек. И в разумные сроки!
Надеюсь, информация изложенная в этом посте будет вам полезна. Если я что-то упустил, изложил недостаточно корректно, или у вас есть вопросы — добро пожаловать в комментарии!
Похожие публикации
Проблемы с кодом? Помогите команде писать лучший код. Советы от Дино Эспозито
Онлайн конференция для .NET разработчиков. 1 марта
Обзор Windows Workflow Foundation на примере построения системы электронного документооборота [Часть 1]
Вакансии компании Luxoft
Комментарии 6
В данный момент, так же, занимаюсь написанием документооборота на WWF (правда начал использовать сразу с 4.0.3, сейчас
мигрировал на 4.5). Из явных отличий (у меня приложение на asp.net mvc):
— Стараюсь код обновления данных выносить за wwf. Например, если запрашиваю какие-нибудь данные от пользователя, то перед
возобновлением рабочего процесса я обновляю эти данные в базе. Встречается не так часто. Но для того, чтобы всё же документ
можно было изменить в рабочем процессе, я в него постоянно передаю новый привязанный к DataContext объект, а по завершению
шага (ждем какое-то действие от пользователя) — сохраняю объект в базу.
— Использую state-machine, которая связана со статусами документа напрямую. В переходе уже так, как более удобнее на данный
момент, но 90% это sequence, так как обычно требуется более сложная логика с параллельными задачами и т. п.
На WWF переложил следующие сложные задачи, которые не так уж и просто решить в лоб:
— параллельные задания (написать, код, который был бы столь прозрачным — очень сложно без специальных библиотек)
— определение текущего состояния документа, например, требования к процессу согласования: пользователь может задавать, как
требуется согласовывать (последовательно или параллельно и даже смешивая), плюс можно указывать группу людей (любой из
группы может обработать задание). Выходит, что пользователь может сделать, что-то типа: руководитель (если согласовал) (согласующий1 параллельно согласующий2) (если согласовали) (группа 2 парраллельно согласующий3). Так же есть делегирование, внутреннее согласование и т. п. При этом при открытии карточки, надо четко понимать, что сейчас назначено и на кого. Да ещё и инициатор может всё это отозвать.
Пару примеров: 
С первого взгляда кажется, что ничего не понятно. Хотя если бы это был код, это была бы не одна тысяча строк (с восстановлением состояния, переходами и т. п.)
Определение текущего состояния — мы в любой момент можем спросить у WWF, какие закладки у него действуют. Закладка — кнопка для определённого пользователя. Хотя это часто не так тривиально, например, когда согласующий инициировал внутреннее согласование, затем какой-то согласующий согласовал и после этого инициировавший вдруг не согласовал. (задания у внутренних согласующий должны быть отозваны, реакция внутреннего согласующего при этом не должна учитываться и т. п.)
Как это было бы в коде — я до сих пор не понимаю
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.