Супер! Коротко и ясно. Больше подобных видео с разбором )

Спасибо! Пойду гляну про токены

Офигенное раскрытие темы. Storm bpmn пользуемся полгода, крутой инструмент

Спасибо! Отлично получилось 👍. Коротко и ясно.

Денис, красава! Коротко и понятно всё объяснил.

Классно! Никогда в нем не работала, но было понятно. Спасибо!

Отличное видео, спасибо

Весь мир: делает видосы за 1 минуту Котов: делает короткое видео с 50 секундным интро

А как показать, что нужно заморозить токен в основном процессе, чтобы лишние ресурсы не тратить (пока уговариваем клиента вернуться)?

а можно как-то скрыть подпроцесс на доске? имею в виду свернуть и при необходимости развернуть

Спасибо за видео. Каким образом сделать уничтожение токенов основного процесса по условию? Допустим отменить процесс (отмена по инициативе клиента) можно только до четвертого действия. Как только токен начинает выполнять четвертое и последующие действия, процесс отменить нельзя, даже если клиент очень хочет. Что приходит на ум: объединить первые три действия в подпроцесс и навешать туда прерывающее сообщение. Есть ли еще способ? И как в последующих процессах показать действия в случае попытки отмены (сообщаем клиенту, что отменить нельзя) - объединением в подпроцесс с непрерывающим событием?

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

Кстати, интересно тогда как бы выглядит процесс, например, в 3-м варианте, когда клиенту предлагаем скидку, но при этом не нужно процесс останавливать, например, достаточно параллельно торговаться и закончить это к моменту завершения основной ветки процесса. Ну или еще сценарий: нужно токен основной ветки не убить, а вернуть немного назад, например, на условный шаг 2. При этом не важно на каком он сейчас шаге, главное не на 1м.

Добрый день! Поясните, пожалуйста, по поводу терминологии. По контексту ролика я понял что это не отмена, а прерывание. Ну т.е. просто убили токен основного процесса и ок. А как отобразить необходимость роллбека основного процесса при срабатывании событийного подпроцесса?

Как я понял тут рассмотрен отказ с позиции клиента, выглядит очень удобно. Вопрос: В ходе рассмотрения кредитной заявки банк может отказать клиенту после каждого из этапов рассмотрения и придётся после каждого блока всё равно ставить exclusive gateway как на первом примере, можно как-то этого избежать?

Насколько важно рисовать пул клиента и поток сообщений от него в событие во встроенном подпроцессе-обработчике? Какие риски отсутствия пула клиента и потока сообщений?

Ссылки не работают

Не увидел особого преимущества 3-го варианта над 2-м вариантом

Всё отлично, но сервис не дает предоставить доступ к просмотру диаграммы для всех пользователей. Надеюсь скоро баг пофиксят

Ребята из OMG, конечно, молодцы, но тот, кто придумал Событийный шлюз, будет гореть в аду.

Все видео смотрю в глаза пёселя.🙄

не во всех системах автоматизации работает это очень слабо сказано) я как программист могу точно сказать что верхний процесс успеет засрать доменный слой так сильно что без сложного Event sourcing. или конкретных событий бизнес слоя оставленных этим процессом можно тупо засрать себе домен до состояния инвалидности, особенно если в процессе были подпроцессы порождавшие сообщения. например клиент зарезервировал товар, потом отменил весь бизнес процесс, мы сорвали все токены, кто домен чистить будет от всего этого хлама, которое в нем отобразилось за время работы процесса?