Варианты использования Модуля управления технологическим процессом
Я хотел бы знать об определенных проблемах Вас - ТАКИМ ОБРАЗОМ, читатель - решил Модули управления технологическим процессом использования и какие библиотеки/платформы Вы использовали, если Вы не прокрутили свое собственное. Я также хотел бы знать, когда Модуль управления технологическим процессом не был лучшим выбором и если/как Вы выбрали что-то более простое, как приложение типа TaskList/WorkList/Task-Management с помощью конечных автоматов.
Вопросы:
- Какие проблемы Вы использовали модули управления технологическим процессом для решения?
- Какие библиотеки/платформы Вы использовали?
- Когда сделал более простой Конечный автомат/, управление задачами как система достаточны?
- Премия: Как Вы делали различие между управлением задачами и Модулем управления технологическим процессом?
Я ищу собственный опыт.
Некоторые ресурсы я проверил:
4 ответа
Я тоже пристрастен, так как являюсь основным автором StonePath .
Я разработал приложения для рабочего процесса для Государственного департамента США, Женевского центра гуманитарного разминирования, нескольких клиентов из состояния 500 и совсем недавно для системы государственных школ Вашингтона, округ Колумбия. Каждый раз, когда я видел «механизм рабочего процесса», который пытался быть единственным эталоном для бизнес-процессов, я видел, как организация борется сама с собой, пытаясь обойти этот инструмент. Это может быть связано с тем, что эти решения всегда основывались на поставщиках / продуктах, а затем заканчивались тактической командой `` консультантов '', постоянно поддерживающей приложение ... но из-за этого я склонен реагировать негативно, когда слышу Преимущества инструментов, основанных на процессах, которые обещают «централизовать определения рабочих процессов в одном месте и сделать их повторяемыми».
Тем не менее, мне очень нравится Ruote - я слежу за этим проектом в течение некоторого времени, и если мне понадобится такое решение, это будет следующий инструмент, который я захочу попробовать. StonePath имеет совсем другое назначение, чем ruote - где Ruote полезен для Ruby в целом, StonePath нацелен на Rails, веб-фреймворк, написанный на Ruby. Если Ruote посвящен долгоживущим бизнес-процессам и связанным с ними определениям, StonePath занимается управлением рабочим процессом и постановкой задач на основе состояния. Честно говоря, я думаю, что различие со стороны может быть тонким - во многих случаях одни и те же виды бизнес-процессов могут быть представлены в любом случае - хотя модель, основанная на состоянии и задачах, имеет тенденцию соответствовать моей ментальной модели.
Позвольте мне описать основные моменты рабочего процесса на основе состояний.Короче говоря, представьте себе рабочий процесс, вращающийся вокруг обработки чего-то вроде ипотечной ссуды или продления паспорта. По мере того как документ перемещается «по офису», он перемещается из штата в штат. Представьте, что вы отвечаете за документ, и ваш босс каждые несколько часов спрашивает вас об обновлении статуса и хочет получить краткий ответ ... вы бы сказали что-то вроде «Это во вводе данных» ... «Мы проверяем учетные данные заявителя сейчас "..." мы ожидаем проверки качества "..." Готово "... и так далее. Это состояния в рабочем процессе на основе состояний. Мы переходим из состояния в состояние с помощью переходов, таких как «одобрить», «применить», «откат», «отклонить» и т. Д. Это, как правило, глаголы действия. Подобные вещи все время моделируются в программном обеспечении как конечный автомат. .
Следующей частью рабочего процесса на основе состояния / задачи является создание задач. Задача - это единица работы, обычно со сроком выполнения и инструкциями по обработке, которая связывает рабочий элемент (заявку на получение кредита или обновление паспорта). , например), для пользователей «в коробке». Задачи могут выполняться параллельно друг с другом или последовательно, и мы можем создавать задачи автоматически, когда мы входим в состояния, создавать задачи вручную, когда люди понимают, что работа должна быть выполнена, и требовать выполнения задач. быть завершенным, прежде чем мы сможем перейти в новое состояние. Все подобные действия являются необязательными и являются частью определения рабочего процесса.
Кроличья нора может идти намного глубже, чем это, и я написал об этом статью для Issue № 4 PragPub, журнала прагматичных программистов. Перейдите по ссылке выше, чтобы получить обновленный PDF-файл с статья.
Работая с StonePath последние несколько месяцев, я обнаружил, что модель на основе состояний очень хорошо отображается на спокойные веб-архитектуры - в частности, задачи и переходы между состояниями хорошо отображаются как вложенные ресурсы. Ожидайте, что в будущем я буду писать по этому поводу.
В предыдущем проекте, над которым я работал, я добавил некоторые правила типа рабочего процесса в набор правительственных форм в сфере здравоохранения.
Формы должны были быть заполнены конечным пользователем, и в зависимости от некоторых ответов другие формы планировалось заполнить позднее. Были также внешние события, которые отменяли запланированные формы или планировали новые.
Примерный поток:
Пациент принят -> Запланировать форму первичной оценки -> Запланировать форму ежеквартального обзора -> Пациент умер -> Отменить рассмотрение -> Запланировать форму оценки выписки
Многие другие правила были основаны на таких вещах, как Пациент возраст, куда они поступали и т. д.
Это было приложение ASP.NET, правила в основном представляли собой таблицу в базе данных.Я добавил скрипт, чтобы скрипт запускался при завершении формы, чтобы определить, что делать дальше. Это был ужасный дизайн, и он идеально подошел бы для правильного движка Workflow.
Я пристрастен, я один из авторов ruote .
вариант 1) конечный автомат, прикрепленный к ресурсу (документу, заказу, счету, книге, предмету мебели).
вариант 2) конечный автомат, прикрепленный к виртуальному ресурсу с именем задачи
вариант 3) механизм рабочего процесса, интерпретирующий определения рабочего процесса
Теперь ваш вопрос помечен как «BPM», мы можем расширить его до «Управление бизнес-процессами». Как такое управление происходит в каждом из вариантов?
В варианте 1 бизнес-процесс (или рабочий процесс) разбросан по приложению. Конечный автомат, прикрепленный к ресурсу, обеспечивает выполнение некоторых аспектов рабочего процесса, но только тех, которые связаны с ресурсом. Могут существовать и другие ресурсы с собственным конечным автоматом, выполняющие тот же бизнес-процесс.
В варианте 2 рабочий процесс может быть сконцентрирован вокруг ресурса задачи и представлен конечным автоматом вокруг этого ресурса.
В варианте 3 рабочий процесс запускается путем интерпретации ресурса, называемого определением рабочего процесса (или определением бизнес-процесса).
Что происходит при изменении бизнес-процесса? Стоит ли иметь механизм рабочего процесса, в котором бизнес-процессы представляют собой управляемые ресурсы?
Большинство библиотек конечных автоматов имеют 1 набор состояний + переходы. Механизмы рабочих процессов, в большинстве своем, являются интерпретаторами определений рабочих процессов, и они позволяют нескольким различным рабочим процессам работать вместе.
Сколько будет стоить изменение рабочего процесса?
Варианты не исключают друг друга.Я видел много примеров, когда механизм рабочего процесса изменяет состояние нескольких ресурсов, некоторые из которых охраняются конечными автоматами.
Я также часто использую вариант 3 + 2 для человеческих задач: механизм рабочего процесса в некоторые моменты при запуске экземпляра процесса передает задачу (рабочий элемент) участнику-человеку (ресурсная задача создается и помещается в состояние '' готовы').
Вы можете пройти долгий путь только с вариантом 2 (вариант диспетчера задач).
Мы также могли бы упомянуть вариант 0), где нет конечного автомата, нет механизма рабочего процесса, а бизнес-процессы разбросаны и / или жестко запрограммированы в приложении.
Вы можете задать много вопросов, но если вы не найдете время, чтобы прочитать ответы, и не потратите время, чтобы попробовать и поэкспериментировать, вы не уйдете далеко и никогда не научитесь когда использовать тот или иной инструмент.
Я развернул свой собственный механизм рабочего процесса для поддержки поэтапной обработки документов - каталогизация, отправка для обработки изображений (мы работаем с редактированием sw), при необходимости отправка на проверку, затем выпуск и, наконец, отправка обратно клиенту. В нашем случае у нас есть масса документов для обработки, поэтому иногда нам нужно запускать каждую службу отдельно, чтобы контролировать доставку и использование ресурсов. Простая концепция, но необходимы высокая производительность и распределенная обработка, и мы не смогли найти ни одного готового продукта, который бы отвечал нашим требованиям.