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

Question

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

Вопросы:

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

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

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

• Ruote и State Machine! = Рабочий процесс Engine
• StonePath и Документы
• Создание и управление планами задач рабочего списка с Oracle
• Проектирование и внедрение механизма документооборота - тезис
• Что использовать Windows Workflow Foundation Для
• Документы JBoss jBPM

Answer 1

Я тоже пристрастен, так как я главный автор StonePath .

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

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

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

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

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

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

Answer 2

Я пристрастен, я один из авторов ruote .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 3

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

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

Поток образца:

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

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

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

Answer 4

Check rails_workflow gem - Я думаю, это близко к тому, что вы ищете.

Answer 5

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

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

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

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

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

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

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

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

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

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

Answer 6

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

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

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

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

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

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

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

Answer 7

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

Answer 8

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

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

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

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

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

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

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

> Когда было достаточно более простого State Machine / Task Management, такого как система?

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

> Бонус: как вы делали различие между управлением задачами и Workflow Engine?

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