Я тоже предвзят, так как являюсь основным автором StonePath .
Я разработал рабочие приложения для Государственного департамента США, Женевского центра по гуманитарному разминированию, нескольких клиентов из состояния 500 и совсем недавно для системы государственных школ Вашингтона. Каждый раз, когда я видел «механизм рабочего процесса», который пытался быть единственным эталоном для бизнес-процессов, я видел, как организация борется сама с собой, пытаясь обойти этот инструмент. Это может быть связано с тем, что эти решения всегда основывались на поставщиках / продуктах, а затем заканчивались тактической командой «консультантов», постоянно поддерживающей приложение ... но из-за этого я склонен реагировать негативно, когда слышу Преимущества инструментов на основе процессов, которые обещают «централизовать определения рабочих процессов в одном месте и сделать их повторяемыми».
Тем не менее, мне очень нравится Ruote - я слежу за этим проектом в течение некоторого времени, и если мне понадобится такое решение, это будет следующий инструмент, который я захочу попробовать. StonePath имеет совсем другое назначение, чем ruote - где Ruote полезен для Ruby в целом, StonePath нацелен на Rails, веб-фреймворк, написанный на Ruby. Если Ruote посвящен долгоживущим бизнес-процессам и связанным с ними определениям, StonePath занимается управлением рабочим процессом и постановкой задач на основе состояния. Откровенно говоря, я думаю, что различие со стороны может быть тонким - во многих случаях одни и те же виды бизнес-процессов могут быть представлены в любом случае - хотя модель, основанная на состоянии и задачах, имеет тенденцию соответствовать моей ментальной модели.
Позвольте мне описать основные моменты рабочего процесса на основе состояний. Короче говоря, представьте себе рабочий процесс, вращающийся вокруг обработки чего-то вроде ипотечной ссуды или продления паспорта. По мере того как документ перемещается «по офису», он перемещается из штата в штат. Представьте, что вы отвечаете за документ, и ваш босс каждые несколько часов спрашивает вас об обновлении статуса и хочет получить краткий ответ ... вы бы сказали что-то вроде «Это во вводе данных» ... «Мы проверяем учетные данные заявителя сейчас «...» мы ожидаем проверки качества »...« Готово »... и так далее. Это состояния в рабочем процессе на основе состояний. Мы переходим из состояния в состояние с помощью переходов, таких как «одобрить», «применить», «откат», «отклонить» и т. Д., Как правило, это глаголы действия.
Следующая часть рабочего процесса на основе состояния / задачи - это создание задач. Задача - это единица работы, обычно со сроком выполнения и инструкциями по обработке, которая связывает рабочий элемент (например, заявку на ссуду или обновление паспорта) с пользователем «в ящике». Задачи могут выполняться параллельно друг с другом или последовательно, и мы можем создавать задачи автоматически, когда мы входим в состояния, создавать задачи вручную, когда люди понимают, что работа должна быть выполнена, и требовать, чтобы задачи были выполнены, прежде чем мы сможем перейти в новое состояние. Такое поведение не является обязательным и является частью определения рабочего процесса.
Кроличья нора может пойти намного глубже, чем эта, и я написал об этом статью для № 4 журнала PragPub, журнала Pragmatic Programmer's Magazine. Перейдите по ссылке выше, чтобы получить обновленный PDF-файл этой статьи.
Работая с StonePath последние несколько месяцев, я обнаружил, что модель на основе состояний очень хорошо отображается на спокойных веб-архитектурах - в частности, задачи и переходы между состояниями хорошо отображаются как вложенные ресурсы. Ожидайте, что в будущем я буду писать по этой теме.