Я тоже предвзят, так как являюсь основным автором StonePath .
Я разработал рабочие приложения для Государственного департамента США, Женевского центра по гуманитарному разминированию, нескольких клиентов из состояния 500 и совсем недавно для системы государственных школ Вашингтона. Каждый раз, когда я видел «механизм рабочего процесса», который пытался быть единственным эталоном для бизнес-процессов, я видел, как организация борется сама с собой, пытаясь обойти этот инструмент. Это может быть связано с тем, что эти решения всегда основывались на поставщиках / продуктах, а затем заканчивались тактической командой «консультантов», постоянно поддерживающей приложение ... но из-за этого я склонен реагировать негативно, когда слышу Преимущества инструментов на основе процессов, которые обещают «централизовать определения рабочих процессов в одном месте и сделать их повторяемыми».
Тем не менее, мне очень нравится Ruote - я слежу за этим проектом в течение некоторого времени, и если мне понадобится такое решение, это будет следующий инструмент, который я захочу попробовать. StonePath имеет совсем другое назначение, чем ruote - где Ruote полезен для Ruby в целом, StonePath нацелен на Rails, веб-фреймворк, написанный на Ruby. Если Ruote посвящен долгоживущим бизнес-процессам и связанным с ними определениям, StonePath занимается управлением рабочим процессом и постановкой задач на основе состояния. Откровенно говоря, я думаю, что различие со стороны может быть тонким - во многих случаях одни и те же виды бизнес-процессов могут быть представлены в любом случае - хотя модель, основанная на состоянии и задачах, имеет тенденцию соответствовать моей ментальной модели.
Позвольте мне описать основные моменты рабочего процесса на основе состояний. Короче говоря, представьте себе рабочий процесс, вращающийся вокруг обработки чего-то вроде ипотечной ссуды или продления паспорта. По мере того как документ перемещается «по офису», он перемещается из штата в штат. Представьте, что вы отвечаете за документ, и ваш босс каждые несколько часов спрашивает вас об обновлении статуса и хочет получить краткий ответ ... вы бы сказали что-то вроде «Это во вводе данных» ... «Мы проверяем учетные данные заявителя сейчас «...» мы ожидаем проверки качества »...« Готово »... и так далее. Это состояния в рабочем процессе на основе состояний. Мы переходим из состояния в состояние с помощью переходов, таких как «одобрить», «применить», «откат», «отклонить» и т. Д., Как правило, это глаголы действия.
Следующая часть рабочего процесса на основе состояния / задачи - это создание задач. Задача - это единица работы, обычно со сроком выполнения и инструкциями по обработке, которая связывает рабочий элемент (например, заявку на ссуду или обновление паспорта) с пользователем «в ящике». Задачи могут выполняться параллельно друг с другом или последовательно, и мы можем создавать задачи автоматически, когда мы входим в состояния, создавать задачи вручную, когда люди понимают, что работа должна быть выполнена, и требовать, чтобы задачи были выполнены, прежде чем мы сможем перейти в новое состояние. Такое поведение не является обязательным и является частью определения рабочего процесса.
Кроличья нора может пойти намного глубже, чем эта, и я написал об этом статью для № 4 журнала PragPub, журнала Pragmatic Programmer's Magazine. Перейдите по ссылке выше, чтобы получить обновленный PDF-файл этой статьи.
Работая с StonePath последние несколько месяцев, я обнаружил, что модель на основе состояний очень хорошо отображается на спокойных веб-архитектурах - в частности, задачи и переходы между состояниями хорошо отображаются как вложенные ресурсы. Ожидайте, что в будущем я буду писать по этой теме.
Я пристрастен, я один из авторов руота .
вариант 1) конечный автомат, прикрепленный к ресурсу (документу, заказу, счету, книге, предмету мебели).
вариант 2) конечный автомат, прикрепленный к виртуальному ресурсу, названный задачей
вариант 3) механизм рабочего процесса, интерпретирующий определения рабочего процесса
Теперь ваш вопрос помечен как «BPM», его можно расширить до «Управление бизнес-процессами». Как такое управление происходит в каждом из вариантов?
В варианте 1 бизнес-процесс (или рабочий процесс) разбросан по приложению. Конечный автомат, прикрепленный к ресурсу, обеспечивает выполнение некоторых аспектов рабочего процесса, но только тех, которые связаны с ресурсом. Могут быть и другие ресурсы со своим конечным автоматом, выполняющие тот же бизнес-процесс.
В варианте 2 рабочий процесс может быть сконцентрирован вокруг ресурса задачи и представлен конечным автоматом вокруг этого ресурса.
В варианте 3 рабочий процесс запускается путем интерпретации ресурса, называемого определением рабочего процесса (или определением бизнес-процесса).
Что происходит при изменении бизнес-процесса? Стоит ли иметь механизм рабочего процесса, в котором бизнес-процессы являются управляемыми ресурсами?
Большинство библиотек конечных автоматов имеют 1 набор состояний + переходы. Механизмы рабочих процессов, в большинстве своем, являются интерпретаторами определений рабочих процессов, и они позволяют нескольким различным рабочим процессам работать вместе.
Сколько будет стоить изменение рабочего процесса?
Варианты не исключают друг друга. Я видел много примеров, когда механизм рабочего процесса изменяет состояние нескольких ресурсов, некоторые из которых охраняются конечными автоматами.
Я также часто использую вариант 3 + 2 для человеческих задач: механизм рабочего процесса в некоторые моменты при запуске экземпляра процесса передает задачу (рабочий элемент) участнику-человеку (ресурсная задача создается и помещается в состояние «готово») .
Вы можете пройти долгий путь только с вариантом 2 (вариант диспетчера задач).
Мы могли бы также упомянуть вариант 0), где нет конечного автомата, нет механизма рабочего процесса, а бизнес-процессы разбросаны и / или жестко запрограммированы в приложении.
Вы можете задать много вопросов, но если вы не найдете времени, чтобы прочитать ответы и не потратить время на то, чтобы попробовать и поэкспериментировать, вы не уйдете далеко и никогда не научитесь определять, когда использовать тот или иной инструмент.
источник
В предыдущем проекте, над которым я работал, я добавил некоторые правила типа рабочего процесса в набор правительственных форм в индустрии здравоохранения.
Формы должны быть заполнены конечным пользователем, и в зависимости от некоторых ответов другие формы должны были быть заполнены позднее. Были также внешние события, которые отменяли запланированные формы или планировали новые.
Поток образца:
Пациент принят -> Запланировать первоначальную оценку ФОРМЫ -> Запланировать форму ежеквартального обзора -> Пациент умер -> Отменить рассмотрение -> Запланировать форму оценки выписки
Многие другие правила основывались на таких вещах, как возраст пациента, место приема и т. Д.
Это было приложение ASP.NET, правила представляли собой таблицу в базе данных. Я добавил сценарий, чтобы сценарий запускался при завершении формы, чтобы определить, что делать дальше. Это был ужасный дизайн, и он идеально подошел бы для правильного движка Workflow.
источник
Я один из авторов Cadence Workflow Engine, который мы разработали в Uber. Разница между Cadence и большинством существующих механизмов рабочего процесса заключается в том, что он ориентирован на разработчиков, является чрезвычайно гибким и масштабируемым (до десятков тысяч обновлений в секунду и до миллиардов открытых рабочих процессов). Рабочие процессы написаны как объектно-ориентированные программы, и механизм гарантирует, что состояние объектов рабочего процесса, включая стеки потоков и локальные переменные, полностью сохраняется в случае сбоев хоста.
и многие другие
Другой набор вариантов использования основан на переносе существующих механизмов рабочего процесса для работы на Cadence. Практически любой существующий язык спецификации рабочего процесса движка может быть перенесен для работы на Cadence. Было перенесено несколько внутренних систем Uber. Таким образом, одна серверная служба может поддерживать несколько систем рабочих процессов, зависящих от домена.
Cadence - это автономный сервис, написанный на клиентских библиотеках Go with Go и Java . Единственная внешняя зависимость - это хранилище. Поддерживаются базы данных Cassandra и SQL.
Cadence также поддерживает асинхронную межрегиональную (используя терминологию AWS) репликацию.
В Uber сервисом Cadence управляет наша команда. Таким образом, накладные расходы на создание любого настраиваемого конечного автомата / управления задачами всегда выше, чем при использовании Cadence. Вне компании необходимо настроить сервис и хранилище для него. Если у вас уже есть база данных SQL, развертывание службы с помощью образа докера является тривиальным. Докер также используется для запуска локальной службы Cadence для разработки на персональном компьютере или ноутбуке.
источник
Проверьте гем rails_workflow - я думаю, это похоже на то, что вы ищете.
источник
Я один из авторов Imixs-Workflow . Imixs-Workflow - это движок рабочего процесса с открытым исходным кодом, основанный на BPMN 2.0 и полностью интегрированный в стек технологий Java EE.
Я сам разрабатываю рабочие процессы более 10 лет. Постараюсь кратко ответить на ваш вопрос:
> Для решения каких проблем вы использовали механизмы рабочего процесса?
Когда я начал думать о механизмах рабочего процесса, моей личной целью было избежать жесткого кодирования бизнес-логики в моем приложении. Многие вещи в бизнес-приложении можно использовать повторно, поэтому имеет смысл сохранить их настраиваемыми. Например:
Из этого списка функций вы можете видеть, что я говорю о рабочих процессах, ориентированных на человека. Вкратце: ориентированный на человека механизм рабочего процесса отвечает на вопросы: кто отвечает за задачу и кого нужно проинформировать дальше? И это типичные вопросы бизнес-требований.
> Какие библиотеки / фреймворки вы использовали?
5 лет назад мы начали перерабатывать движок Imixs-Workflow с упором на BPMN 2.0 . BPMN - это общепринятый стандарт моделирования процессов. И меня удивило то, что мы внезапно смогли описать даже очень сложные бизнес-процессы, которые можно было визуализировать и выполнить. Всем рекомендую использовать BPMN для моделирования бизнес-процессов.
> Когда было достаточно более простой системы состояний машины / управления задачами?
Если вы просто хотите отслеживать статус бизнес-объекта, достаточно простого конечного автомата. Это тот случай, когда вы начинаете вводить атрибут «статус» в вашу объектную модель. Но если вам нужны бизнес-процессы с обязанностями, ведением журналов и управлением потоком, то конечного автомата уже недостаточно.
> Бонус: Как вы проводите различие между Task Management и Workflow Engine?
Это как раз та точка, где многие механизмы рабочего процесса, упомянутые здесь, различаются. Для рабочего процесса, ориентированного на человека, вам обычно требуется управление задачами для распределения задач между людьми. Для автоматизации процессов этот момент не так актуален. Достаточно, если двигатель выполняет определенные задачи. Невозможно сравнивать управление задачами и механизмы рабочего процесса, потому что управление задачами всегда является функцией механизма рабочего процесса.
источник
Я развернул свой собственный механизм рабочего процесса для поддержки поэтапной обработки документов - каталогизация, отправка на обработку изображений (мы работаем с редактированием sw), при необходимости отправка на проверку, затем выпуск и, наконец, отправка обратно клиенту. В нашем случае у нас есть масса документов для обработки, поэтому иногда нам нужно запускать каждую службу отдельно, чтобы контролировать доставку и использование ресурсов. Простая концепция, но необходимы высокая производительность и распределенная обработка, и мы не смогли найти ни одного готового продукта, который бы отвечал нашим требованиям.
источник
У меня есть опыт использования движка Activiti BPMN 2.0 для обработки высокопроизводительных и высокопроизводительных процессов передачи данных в инфраструктуре сетевых узлов. Основная задача заключалась в том, чтобы разрешить настройку и мониторинг таких процессов передачи и управлять каждым сетевым узлом (т. Е. Запросить node1 для отправки файла данных на node2 через определенный транспортный уровень).
Одновременно могут выполняться тысячи процессов, а в день - десятки или даже сотни тысяч процессов.
Существовало множество различных определений процессов, но необязательно, чтобы оператор системы мог создавать собственные рабочие процессы. Таким образом, основной вариант использования самого механизма BPM должен был быть надежным, масштабируемым и позволять отслеживать каждый поток процесса.
В конце концов, это в основном сработало, но из этого проекта мы узнали, что платформа BPMN, а точнее, движок Activiti, не лучший вариант для такой высокопроизводительной системы.
Основными проблемами были приоритезация задач, блокировка БД, повторные попытки выполнения, и это лишь некоторые из тех, что касались самого BPM. Поэтому нам пришлось разработать индивидуальную обработку для них, например:
Я не знаю, подойдут ли другие механизмы BPMN для такого сценария, поскольку BPMN в основном предназначена для длительных бизнес-задач, связанных с взаимодействием с пользователем, где производительность, вероятно, не такая же проблема, как в нашем случае.
источник