Использовать сценарии Workflow Engine

Ответ 1

Я тоже предвзятый, так как я главный автор StonePath.

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

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

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

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

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

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

Ответ 2

Я смещен, я один из авторов ruote.

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

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

вариант 3) машинный интерпретатор документооборота интерпретатора рабочего процесса

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

Пример потока:

Пациент признан → Первоначальная оценка расписания FOrm → Расписание ежеквартальной формы обзора → Умер пациент → Отмена обзора → Форма оценки распределения расходов

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

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

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

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

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

Ответ 7

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

Ответ 8

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

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