Варианты использования Workflow Engine

Question

Я хотел бы знать о конкретных проблемах, которые вы, читатель SO, решили с помощью Workflow Engines, а также о том, какие библиотеки/фреймворки вы использовали, если не создали свои собственные.Я также хотел бы знать, когда Workflow Engine не был лучшим выбором и выбрали ли вы что-то более простое, например приложение типа TaskList/WorkList/Task-Management, использующее конечные автоматы.

Вопросы:

• Для решения каких проблем вы использовали механизмы рабочих процессов?
• Какие библиотеки/фреймворки вы использовали?
• Когда было достаточно более простой системы, подобной конечному автомату/управлению задачами?
• Бонус:Как вы сделали/проводите различие между Управление задачами и Механизм рабочего процесса?

Я ищу опыт из первых рук.

Некоторые из ресурсов, которые я проверил:

• Руоте и Конечный автомат != Механизм рабочего процесса
• Каменный путь и Документы
• Создание планов задач рабочих списков и управление ими с помощью Oracle
• Проектирование и реализация механизма рабочего процесса - дипломная работа
• Для чего использовать Windows Workflow Foundation
• JBoss Документация по jBPM

Answer 1

Я тоже предвзят, так как являюсь основным автором Каменный путь.

Я разработал приложения рабочего процесса для США.Государственный департамент, Женевский центр гуманитарного разминирования, несколько клиентов из списка Fortune 500 и совсем недавно система государственных школ Вашингтона.Каждый раз, когда я видел «механизм рабочего процесса», который пытался стать единым эталоном для бизнес-процессов, я видел, как организация боролась за то, чтобы обойти этот инструмент.Это может быть связано с тем, что эти решения всегда определялись поставщиками/продуктами, а затем в конечном итоге тактическая команда «консультантов» постоянно снабжает приложение...но из-за этого я склонен негативно реагировать, когда слышу о преимуществах инструментов, основанных на процессах, которые обещают «централизовать определения рабочих процессов в одном месте и сделать их повторяемыми».

Тем не менее, мне очень нравится Ruote — я слежу за этим проектом уже некоторое время, и если мне понадобится такое решение, это будет следующий инструмент, который я захочу попробовать.StonePath имеет совсем другую цель, чем ruote: если Ruote полезен для Ruby в целом, то StonePath нацелен на Rails, веб-фреймворк, написанный на Ruby.Если Ruote посвящен долгоживущим бизнес-процессам и связанным с ними определениям, то StonePath — управлению рабочими процессами и задачами на основе состояния.Честно говоря, я думаю, что различие при внешнем взгляде может быть тонким - часто одни и те же виды бизнес-процессов могут быть представлены в любом случае - хотя модель, основанная на состояниях и задачах, имеет тенденцию соответствовать моей ментальной модели.

Позвольте мне описать основные моменты рабочего процесса на основе состояний.Короче говоря, представьте себе рабочий процесс, вращающийся вокруг обработки чего-то вроде ипотечного кредита или продления паспорта.По мере того, как документ перемещается «по офису», он путешествует из штата в штат.Представьте себе, что вы отвечаете за документ, а ваш начальник каждые несколько часов просит вас обновить статус и хочет получить краткий ответ...вы бы сказали что-то вроде: «Это находится в вводе данных»...«Сейчас мы проверяем полномочия заявителя»…"ждём проверки качества"..."Мы сделали"...и так далее.Это состояния в рабочем процессе на основе состояний.Из состояния в состояние переходим через переходы — типа «одобрить», «применить», «откат», «отказать» и так далее.это, как правило, глаголы действия.Подобные вещи постоянно моделируются в программном обеспечении как конечный автомат.

Следующей частью рабочего процесса на основе состояния/задачи является создание задач.Задача — это единица работы, обычно со сроком выполнения и инструкциями по обработке, которая связывает рабочий элемент (например, заявку на получение кредита или продление паспорта) с пользователем «в ящике».Задачи могут выполняться параллельно друг другу или последовательно, и мы можем создавать задачи автоматически при входе в состояния, создавать задачи вручную, когда люди понимают, что работа должна быть выполнена, и требовать завершения задач, прежде чем мы сможем перейти в новое состояние.Все подобные действия не являются обязательными и являются частью определения рабочего процесса.

Кроличья нора может оказаться гораздо глубже, и я написал об этом статью для №4 журнала PragPub, журнала Pragmatic Programmer's Magazine.Перейдите по ссылке reo выше, чтобы получить обновленный PDF-файл этой статьи.

Работая с StonePath последние несколько месяцев, я обнаружил, что модель, основанная на состояниях, очень хорошо сопоставляется с спокойной веб-архитектурой — в частности, задачи и переходы между состояниями прекрасно отображаются как вложенные ресурсы.Ожидайте увидеть от меня дальнейшие статьи на эту тему.

Answer 2

Я предвзят, я один из авторов руотировать.

вариант 1) конечный автомат, прикрепленный к ресурсу (документ, заказ, счет-фактура, книга, предмет мебели).

вариант 2) конечный автомат, прикрепленный к виртуальному ресурсу с именем задача

вариант 3) механизм рабочего процесса, интерпретирующий определения рабочего процесса

Теперь ваш вопрос помечен тегом «BPM», и мы можем расширить его до «Управление бизнес-процессами».Как происходит такое управление в каждом из вариантов?

В варианте 1 бизнес-процесс (или рабочий процесс) разбросан по приложению.Конечный автомат, прикрепленный к ресурсу, обеспечивает соблюдение некоторых аспектов рабочего процесса, но только тех, которые связаны с ресурсом.Могут существовать и другие ресурсы со своим конечным автоматом, выполняющие тот же бизнес-процесс.

В варианте 2 рабочий процесс может быть сконцентрирован вокруг ресурса задачи и представлен конечным автоматом вокруг этого ресурса.

В варианте 3 рабочий процесс реализуется путем интерпретации ресурса, называемого определением рабочего процесса (или определением бизнес-процесса).

Что произойдет, если бизнес-процесс изменится?Стоит ли иметь систему рабочих процессов, в которой бизнес-процессы являются управляемыми ресурсами?

Большинство библиотек конечных автоматов имеют 1 набор состояний + переходы.Механизмы рабочих процессов в большинстве своем являются интерпретаторами определений рабочих процессов и позволяют одновременно выполнять несколько различных рабочих процессов.

Какова будет стоимость изменения рабочего процесса?

Варианты не являются взаимоисключающими.Я видел много примеров, когда механизм рабочего процесса изменяет состояние нескольких ресурсов, некоторые из которых охраняются конечными автоматами.

Я также часто использую вариант 3 + 2 для человеческих задач:механизм рабочего процесса в некоторые моменты запуска экземпляра процесса передает задачу (рабочий элемент) участнику-человеку (задача ресурса создается и помещается в состояние «готово»).

Вы можете пройти долгий путь, используя только вариант 2 (вариант диспетчера задач).

Можно также упомянуть вариант 0), где нет конечного автомата, механизма рабочего процесса, а бизнес-процессы разбросаны и/или жестко запрограммированы в приложении.

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

Answer 3

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

Формы должны были быть заполнены конечным пользователем, и в зависимости от некоторых ответов другие формы планировалось заполнить позднее.Были также внешние события, которые отменяли запланированные формы или планировали новые.

Пример потока:

Пациент принят -> Запланируйте форму первоначальной оценки -> Запланируйте форму ежеквартальной проверки -> Пациент умер -> Отменить проверку -> Запланируйте форму оценки выписки

Многие другие правила основывались на таких факторах, как возраст пациентов, место их госпитализации и т. д.

Это было приложение ASP.NET, правила которого представляли собой таблицу в базе данных.Я добавил скрипты, чтобы скрипт запускался при заполнении формы и определял, что делать дальше.Это был ужасный дизайн, и он идеально подходил бы для полноценного движка Workflow.

Answer 4

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

Answer 5

Я один из авторов Механизм рабочего процесса Cadence мы разработали в Uber.Разница между Cadence и большинством существующих механизмов рабочих процессов заключается в том, что она ориентирована на разработчиков, чрезвычайно гибка и масштабируема (до десятков тысяч обновлений в секунду и до миллиардов открытых рабочих процессов).Рабочие процессы написаны как объектно-ориентированные программы, и механизм гарантирует, что состояние объектов рабочих процессов, включая стеки потоков и локальные переменные, полностью сохраняется в случае сбоев хоста.

Для решения каких проблем вы использовали механизмы рабочих процессов?Cadence используется практически для любого серверного приложения, которое работает за пределами одного ответа на запрос.Примеры использования:

• Распределенные задания CRON
• Управление конвейерами машинного обучения/данных
• Реагирование на деловые события.Например, поездки в Uber.Рабочий процесс может накапливать состояние на основе полученных событий и выполнять действия при необходимости.
• Развертывание сервисов в Mesos/Kubernetes
• Реализация CI-конвейера
• Обеспечение завершения нескольких сервисных вызовов при получении запроса.Включая САГА реализация шаблона
• Управление задачами сотрудников (аналогично Amazon MTurk)
• Обработка медиа
• Маршрутизация заявок в службу поддержки клиентов
• Обработка заказа
• Сервис тестирования, аналогичный ХаосОбезьяна

и многие другие

Другой набор вариантов использования основан на переносе существующих механизмов рабочих процессов для работы на Cadence.Практически любой существующий язык спецификации рабочих процессов движка можно портировать для работы на Cadence.Было перенесено несколько внутренних систем Uber.Таким образом, одна серверная служба может обеспечивать работу нескольких систем рабочих процессов, специфичных для конкретной области.

Какие библиотеки/фреймворки вы использовали?

Cadence — это автономный сервис, написанный на Go с Идти и Джава клиентские библиотеки.Единственная внешняя зависимость — это хранилище.Поддерживаются базы данных Cassandra и SQL.

Cadence также поддерживает асинхронную репликацию между регионами (используя терминологию AWS).

Когда было достаточно более простой системы, подобной конечному автомату/управлению задачами?

Внутри Uber сервисом Cadence управляет наша команда.Таким образом, накладные расходы на создание любого собственного конечного автомата/управления задачами всегда выше, чем при использовании Cadence.За пределами компании необходимо настроить сервис и хранилище для него.Если у вас уже есть база данных SQL, развертывание службы тривиально с помощью образа Docker.Докер также используется для запуска локального сервиса Cadence для разработки на персональном компьютере или ноутбуке.

Answer 6

Я накатил свой собственный движок рабочего процесса для поддержки поэтапной обработки документов - каталогизация, отправка на обработку изображений (мы работаем с ПО редактирования), при необходимости отправка на валидацию, затем выпуск и, наконец, отправка обратно клиенту.В нашем случае нам нужно обработать массу документов, поэтому иногда нам нужно запускать каждую службу отдельно, чтобы контролировать доставку и использование ресурсов.Простая по концепции, но необходима высокая производительность и распределенная обработка, и мы не смогли найти ни одного готового продукта, который подходил бы нам.

Answer 7

У меня есть опыт использования Деятельность Механизм BPMN 2.0 для управления высокопроизводительными и высокопроизводительными процессами передачи данных в инфраструктуре сетевых узлов.Основная задача заключалась в том, чтобы обеспечить настройку и мониторинг таких процессов передачи, а также контроль над каждым узлом сети (т.запросить узел 1 отправить файл данных узлу 2 через определенный транспортный уровень).

Одновременно могут выполняться тысячи процессов, а в общей сложности — десятки или сотни тысяч процессов в день.

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

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

Основными проблемами были расстановка приоритетов выполнения задач, блокировка БД, повторные попытки выполнения, и это лишь немногие, касающиеся самого BPM.Поэтому нам пришлось разработать специальную обработку для них, например:

• Обработка повторных попыток в BPM для случаев, когда на узле не было свободного работника для данной задачи или когда узел вообще не работал.
• Выполнение задач параллельного переноса в одном процессе и синхронизация результатов (успех/неуспех).

Я не знаю, подойдут ли другие механизмы BPMN для такого сценария, поскольку BPMN в основном предназначена для долгосрочных бизнес-задач, включающих взаимодействие с пользователем, где производительность, вероятно, не является такой же проблемой, как в нашем случае.

Answer 8

Я один из авторов Imixs-Рабочий процесс.Imixs-Workflow — это механизм рабочих процессов с открытым исходным кодом, основанный на BPMN 2.0 и полностью интегрированный в стек технологий Java EE.
Я сам разрабатываю механизмы рабочих процессов более 10 лет.Постараюсь коротко ответить на ваш вопрос:

> Для решения каких проблем вы использовали механизмы рабочих процессов?

Моей личной целью, когда я начал думать о механизмах рабочих процессов, было избежать жесткого кодирования бизнес-логики в моем приложении.Многие вещи в бизнес-приложении можно использовать повторно, поэтому имеет смысл оставить их настраиваемыми.Например:

• отправка уведомления
• просмотреть открытые задачи
• поставил задачу человеку
• описание текущей задачи

Из этого списка функций вы можете видеть, что я говорю о рабочих процессах, ориентированных на человека.Суммируя:Человеко-ориентированный механизм рабочего процесса отвечает на вопросы:Кто несет ответственность за задачу и кого необходимо проинформировать следующим?И это типичные вопросы в бизнес-требованиях.

>Какие библиотеки/фреймворки вы использовали?

5 лет назад мы начали перерабатывать движок Imixs-Workflow, уделяя особое внимание БПМН 2.0.BPMN — это общий стандарт моделирования процессов.И самым удивительным для меня было то, что мы внезапно смогли описывать даже очень сложные бизнес-процессы, которые можно было визуализировать и выполнить.Я рекомендую всем использовать BPMN для моделирования бизнес-процессов.

> Когда было достаточно более простой системы, подобной конечному автомату/управлению задачами?

Простого конечного автомата достаточно, если вы просто хотите отслеживать состояние бизнес-объекта.Это тот случай, когда вы начинаете вводить атрибут «статус» в свою объектную модель.Но если вам нужны бизнес-процессы с обязанностями, журналированием и контролем потоков, то конечного автомата уже недостаточно.

> Бонус:Как вы провели/проводите различие между управлением задачами и механизмом рабочих процессов?

Именно этим отличаются многие упомянутые здесь механизмы рабочих процессов.Для рабочего процесса, ориентированного на человека, обычно требуется управление задачами для распределения задач между людьми.Для автоматизации процессов этот момент не столь актуален.Достаточно, если двигатель выполняет определенные задачи.Управление задачами и механизмы рабочих процессов нельзя сравнивать, поскольку управление задачами всегда является функцией механизма рабочих процессов.