Приклади використання механізму робочого циклу


90

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

Запитання:

  • Які проблеми ви вирішували за допомогою механізмів робочого циклу?
  • Які бібліотеки / фреймворки ви використовували?
  • Коли вистачило більш простої державної машини / управління завданнями, як система?
  • Бонус: Як ви / зробили різницю між управлінням завданнями та робочим процесом ?

Я шукаю досвід із перших вуст.

Деякі ресурси, які я перевірив:

Відповіді:


61

Я теж упереджений, оскільки є головним автором StonePath .

Я розробив додатки робочого циклу для Державного департаменту США, Женевського центру гуманітарного розмінування, кількох клієнтів із стану 500 та нещодавно системи державних шкіл у Вашингтоні, округ Колумбія. Кожного разу, коли я бачив "механізм робочого процесу", який намагався стати головним посиланням на бізнес-процеси, я бачив, як організація бореться за те, щоб обійти цей інструмент. Це може бути пов’язано з тим, що ці рішення завжди керувалися постачальником / продуктом, а потім у підсумку тактична команда «консультантів», яка постійно годує додаток ... але через це я схильна негативно реагувати, коли чую переваги заснованих на процесах інструментів, які обіцяють "централізувати визначення робочого процесу в одному місці і зробити їх повторюваними".

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

Дозвольте мені описати основні моменти державного робочого процесу. Коротше, уявіть робочий процес, який обертається навколо обробки чогось на зразок іпотечного кредиту чи поновлення паспорта. Коли документ рухається „по офісу”, він переходить від штату до штату. Уявіть, якщо ви несете відповідальність за документ, і ваш начальник просив вас кожні кілька годин про оновлення статусу і хотів коротку відповідь ... ви сказали б такі речі, як "Це введення даних" ... "Ми перевіряємо повноваження заявника зараз "..." ми чекаємо перевірки якості "..." Ми закінчили "... тощо. Це стани в державному робочому процесі. Ми переходимо від стану до стану шляхом переходів - наприклад, "схвалити", "застосувати", відкат "," відмовити "тощо. Це, як правило, дієслова дії.

Наступною частиною робочого циклу на основі стану / завдання є створення завдань. Завдання - це одиниця роботи, як правило, із датою закінчення строку та інструкціями щодо обробки, яка пов'язує робочий предмет (наприклад, заявку на позику або поновлення паспорта) до користувачів "у вікні". Завдання можуть виконуватися паралельно один з одним або послідовно, і ми можемо створювати завдання автоматично, коли ми входимо у стан, створювати завдання вручну, коли люди усвідомлюють, що потрібно виконати роботу, і вимагати виконання завдань, перш ніж ми можемо перейти до нового стану. Весь такий спосіб поведінки є необов’язковим і є частиною визначення робочого процесу.

Кроляча нора може зайти набагато глибше, ніж це, і я написав про це статтю для випуску No4 PragPub, журналу прагматичного програміста. Перегляньте посилання на повторне повторне оновлення PDF для цієї статті.

Працюючи з StonePath протягом останніх кількох місяців, я виявив, що модель, заснована на державі, дуже добре відповідає спокійним веб-архітектурам - зокрема, завдання та переходи стану добре відображаються як вкладені ресурси. Очікуйте побачити в майбутньому від мене написання на цю тему.


2
чудово! дуже сподіваюся дізнатись більше про тонкі відмінності між движками робочого циклу, такими як ruote, та механізмами стану / завдань, такими як stonepath, тому що, не пройшовши це раніше, важко зрозуміти, з чого почати. Я прочитав усе, що міг знайти про stonepath і ruote, і мільйон інших довідок про BPM та робочі процеси, тому деякі подібні знання, подібні до цього, ДІЙСНО зменшать криву початку роботи. знову дякую.
Ленс Поллард

31

Я упереджений, я є одним із авторів руоте .

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

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

варіант 3) механізм робочого процесу, що інтерпретує визначення робочого процесу

Тепер ваше запитання позначено тегом "BPM", ми можемо розширити його на "Управління бізнес-процесами". Як відбувається таке управління в кожному з варіантів?

У варіанті 1 бізнес-процес (або робочий процес) розподілений у програмі. Державна машина, приєднана до ресурсу, забезпечує виконання деяких аспектів робочого процесу, але лише тих, що стосуються ресурсу. Можуть існувати й інші ресурси із власною державною машиною після того самого бізнес-процесу.

У варіанті 2 робочий процес може бути зосереджений навколо ресурсу завдання і представлений машиною стану навколо цього ресурсу.

У варіанті 3 робочий процес здійснюється шляхом інтерпретації ресурсу, який називається визначенням робочого процесу (або визначенням бізнес-процесу).

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

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

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

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

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

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

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

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


велике спасибі за цю відповідь, це трохи прояснює ситуацію. для новачків недостатньо відмінностей, щоб пристойно зрозуміти формальне моделювання робочого процесу, щоб почати грати з кодом; здається, це всі Java-шпалери кінця 90-х. ви з Девідом із кам'яної доріжки дуже багато починаєте руйнувати цей бар'єр. одного дня це може бути так само просто, як навчання рейок. Я збираюся почати грати з варіантом диспетчера завдань через кілька днів. Дякую.
Ленс Поллард

посилання здається мертвим?
rogerdpack

проект нині мертвий
Jeshan Babooa

4

Над попереднім проектом, над яким я працював, я додав деякі правила робочого циклу до набору державних форм у галузі охорони здоров'я.

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

Зразок:

Пацієнт прийнятий -> Заплануйте попередню оцінку FOrm -> Заплануйте форму щоквартальної перевірки -> Померлий пацієнт -> Скасувати огляд -> Заплануйте форму оцінки виписки

Багато інших правил базувалося на таких речах, як вік пацієнта, де їх приймали тощо.

Це була програма ASP.NET, правила в основному були таблицею в базі даних. Я додав сценарії, щоб сценарій запускався після заповнення форми, щоб визначити, що робити далі. Це був жахливий дизайн, який був би ідеальним для належного механізму робочого процесу.


3

Я є одним із авторів Cadence Workflow Engine, який ми розробили в Uber. Різниця між Cadence та більшістю існуючих механізмів робочого циклу полягає в тому, що він орієнтований на розробника, надзвичайно гнучкий та масштабований (до десятків тисяч оновлень в секунду та до мільярдів відкритих робочих процесів). Робочі процеси записуються як об'єктно-орієнтовані програми, і механізм гарантує, що стан об'єктів робочого циклу, включаючи стеки потоків та локальні змінні, повністю зберігається у випадку відмов хоста.

Які проблеми ви вирішували за допомогою механізмів робочого циклу? Каденс використовується практично для будь-якої серверної програми, яка живе за рамками однієї відповіді на запит. Прикладами використання є:

  • Розподілені завдання CRON
  • Управління конвеєрами ML / даних
  • Реагування на ділові події. Наприклад, поїздки на Uber. Робочий процес може накопичувати стан на основі отриманих подій та виконувати дії, коли це необхідно.
  • Розгортання послуг у Mesos / Kubernetes
  • Впровадження трубопроводу CI
  • Забезпечення завершення кількох сервісних дзвінків під час отримання запиту. Включаючи реалізацію шаблону SAGA
  • Управління завданнями працівника (аналогічно Amazon MTurk )
  • Обробка медіа
  • Маршрутизація квитків служби підтримки
  • Обробка замовлень
  • Сервіс тестування схожий на ChaosMonkey

та багато інших

Інший набір випадків використання базується на перенесенні існуючих механізмів робочого циклу для роботи на Cadence. Практично будь-яку існуючу мову специфікації робочого процесу двигуна можна перенести для запуску на Cadence. Існує кілька внутрішніх систем Uber, які були перенесені. Таким чином, одна серверна сервісна служба може забезпечувати роботу декількох доменних систем робочого циклу.

Які бібліотеки / фреймворки ви використовували?

Cadence - це автономний сервіс, написаний в Go with Go та на клієнтській бібліотеці Java . Єдина зовнішня залежність - це сховище. Бази даних Cassandra та SQL підтримуються.

Каденс також підтримує реплікацію асинхронних поперечних областей (з використанням термінології AWS).

Коли вистачило більш простої державної машини / управління завданнями, як система?

Усередині Uber службою Cadence керує наша команда. Отже, накладні витрати на створення будь-якого спеціального автомата / управління завданнями завжди вищі, ніж використання Cadence. Поза компанією потрібно створити службу та сховище для неї. Якщо у вас вже є база даних SQL, розгортання служби є тривіальним через образ докера. Докер також використовується для запуску локальної служби Cadence для розробки на персональному комп’ютері чи ноутбуці.



2

Я є одним із авторів Imixs-Workflow . Imixs-Workflow - це механізм робочого циклу з відкритим кодом, заснований на BPMN 2.0 і повністю інтегрований у стек технологій Java EE.
Я розробляю двигуни робочого циклу самостійно більше 10 років. Я спробую коротко відповісти на ваше запитання:

> Які проблеми ви вирішували за допомогою механізмів робочого циклу?

Моєю особистою метою, коли я почав думати про механізми робочого циклу, було уникати жорсткого кодування бізнес-логіки в моїй програмі. Багато речей у бізнес-програмі можна використовувати повторно, тому має сенс тримати їх налаштованими. Наприклад:

  • розсилання повідомлення
  • переглянути відкриті завдання
  • доручив людині завдання
  • опису поточного завдання

З цього списку функцій ви бачите, що я говорю про робочі процеси, орієнтовані на людину. Коротше: орієнтований на людину механізм робочого процесу відповідає на запитання: Хто відповідає за завдання, а кого потрібно інформувати далі? І це типові запитання у вимогах бізнесу.

> Які бібліотеки / фреймворки ви використовували?

5 років тому ми розпочали реалізацію двигуна Imixs-Workflow, зосередившись на BPMN 2.0 . BPMN є загальним стандартом для моделювання процесів. І що мене дивувало, ми раптом змогли описати навіть дуже складні бізнес-процеси, які можна було візуалізувати та виконати. Я рекомендую всім використовувати BPMN для моделювання бізнес-процесів.

> Коли вистачило більш простої державної машини / управління завданнями, як система?

Простого автомата достатньо, якщо ви просто хочете відстежити стан бізнес-об’єкта. Це той випадок, коли ви починаєте вводити атрибут 'status' у свою об'єктну модель. Але якщо вам потрібні бізнес-процеси з відповідальністю, реєстрацією та контролем потоку, тоді державна машина вже недостатня.

> Бонус: Як ви / зробили різницю між управлінням завданнями та робочим процесом?

Це саме той момент, коли багато згаданих тут механізмів робочого процесу відрізняються. Для орієнтованого на людину робочого процесу, як правило, потрібне управління завданнями для розподілу завдань між акторами. Для автоматизації процесу цей момент не є настільки актуальним. Досить, якщо двигун виконує певні завдання. Управління завданнями та механізми робочого циклу не можна порівнювати, оскільки управління завданнями завжди є функцією механізму робочого процесу.


1

Я застосував власний механізм робочого циклу для підтримки поетапної обробки документів - каталогізації, відправки на обробку зображень (ми працюємо з редакцією sw), якщо потрібно відправка на перевірку, потім випуск і, нарешті, доставка назад клієнту. У нашому випадку у нас є вантажівка документів для обробки, тому іноді нам потрібно запускати кожну службу окремо, щоб контролювати доставку та використання ресурсів. Концепція проста, але потрібна висока продуктивність та розподілена обробка, і ми не змогли знайти жодного готового товару, який би відповідав нашим вимогам.


1

Я маю досвід використання движка Activiti BPMN 2.0 для обробки високопродуктивних та високопродуктивних процесів передачі даних в інфраструктурі мережевих вузлів. Основним завданням було дозволити конфігурацію та моніторинг таких процесів передачі та керувати кожним вузлом мережі (тобто. Запитувати node1 надсилати файл даних на node2 через конкретний транспортний рівень).

Одночасно можуть виконуватися тисячі процесів і загалом десятки або низькі сотні тисяч процесів на день.

Існувала купа різних визначень процесів, але необов’язково вимагалося, щоб оператор системи міг створювати власні робочі процеси. Отже, основний випадок використання самого механізму BPM повинен бути надійним, масштабованим і дозволяти контролювати кожен процес.

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

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

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.