it-swarm.com.ru

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

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

Вопросы:

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

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

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

80
Lance Pollard

Я также пристрастен, так как я являюсь основным автором StonePath .

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

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

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

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

Кроличья нора может пойти намного глубже, чем это, и я написал статью об этом для Выпуска № 4 PragPub, Прагматического Журнала Программиста. Проверьте обновленную ссылку выше для обновленного PDF этой статьи.

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

57
bokmann

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29
jmettraux

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

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

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

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

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

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

4
Ben Dempsey

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

2
Max

Я один из авторов 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 для разработки на персональном компьютере или ноутбуке.

1
Maxim Fateev

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

1
Otávio Décio

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

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

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

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

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

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

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

0
Adam Hošek