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

Question

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

Вопросы:

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

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

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

• Ruote и State Machine!= Рабочий процесс Engine
• StonePath и Docs
• Создание и управление планами задач рабочего списка с 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. Проверьте обновленную ссылку выше для обновленного PDF этой статьи.

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

Answer 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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

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

Answer 4

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

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

Образец потока:

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

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

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

Answer 5

Я один из авторов 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?

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

Answer 6

Проверьте gem rails_workflow - я думаю, что это близко к тому, что вы ищете.

Answer 7

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

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

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

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

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

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

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

Answer 8

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