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

Узнайте, как оркестрация и BPMN помогают решать самые распространённые ограничения и проблемы, связанные с внедрением AI-агентов.

Визуализация критической информации

Повышение доверия к результатам

Вовлечение человека в процесс

Ограничение важных выборов

Адаптивное вмешательство человека

Будущее дизайна AI-агентов

Это первая статья из серии BPMN: Beyond the Basics – о скрытых нюансах и подводных камнях BPMN для разработчиков. В отличие от аналитиков, разработчикам надо не просто знать нотацию, но понимать, как реализован тот или иной ее элемент. А тут, как говорится, не все так однозначно.

Для начала возьмем самый простой – шлюз ИЛИ (Exclusive Gateway). На первый взгляд, всё очевидно: ставишь ромбик, рисуешь стрелочки – и вуаля! Но что происходит внутри движка? Как он выбирает путь выполнения? Что делать, если несколько условий срабатывают одновременно? А если ни одно не выполняется? В этой статье мы разберем эти вопросы и рассмотрим особенности реализации и использования этого элемента.

Разбираться будем на примерах в Jmix BPM с движком Flowable, но принципы универсальны – нотация BPMN 2.0 едина, и основные механизмы работы элементов схожи во всех движках, частности в Camunda 7. Об отличиях, если они встретятся, будем говорить особо.

Довольно часто из процесса приходится обращаться по API к различным внешним сервисам. По сути, это стандартный сценарий оркестрации систем или даже микросервисов (пардон за модное слово). На BPMN диаграмме это выглядит просто и логично – постучались куда-то по API, получили ответ и перешли к следующей задаче. Для моделей аналитического уровня это нормально.

Однако, переходя к исполняемой модели, надо учитывать, что внешний сервис может быть недоступен или просто отвечает очень небыстро. Что происходит с процессом в это время?

Сегодня - день Святого Патрика🍀🍀🍀, поэтому уместно будет поговорить о пиве. Не ждать же нам Октоберфеста, чтобы опубликовать эту статью! Тем более, что адресат этих рекомендаций по уверению автора это реальный человек, проживающий в Дублине.

=================================================================

Лето имеет свойство заканчиваться, но здесь, в Германии, мы научились топить это разочарование в пиве. Поэтому, когда сентябрь сменяется октябрём, неизбежно возникает вопрос: «Какое пиво мне выпить?». Большинство традиционных участников Октоберфеста, скорее всего, настаивают на том, что вы должны пить что-то немецкое, соответствующее Reinheitsgebot (Закону о чистоте пива). Но я не настолько догматичен и, напротив, считаю, что каждый должен наслаждаться идеальным пивом для себя, независимо от вкусовых предпочтений и места, где он встречает смену сезонов. Именно поэтому я выделил время из своего очень занятого графика, чтобы создать процесс, который поможет в этом.

Это вторая часть серии из двух статей о BPMN и его применении в новых сценариях использования. Вы можете найти первую часть по ссылке. Особая благодарность Бернду Рюккеру за его помощь в написании обеих публикаций.
 
Добро пожаловать обратно к обсуждению BPMN (Business Process Model and Notation) и его роли в новых сценариях, таких как оркестрация микросервисов. Для понимания материала необязательно читать статьи по порядку, но если вы новичок в BPMN, возможно, будет полезно начать с первой части.

Это не новая, но концептуально важная статья. Из нее вы узнаете про основные паттерны при автоматизации процессов, которые можно реализовать при помощи BPMN и почему это сложно сделать иными средствами.

На момент этой статьи написания движок Camunda Zeebe был еще в пеленках, поэтому о многих его фичах говорится в будущем времени. Но сегодня все реализовано и даже больше.

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

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

В настоящее время большинство организаций задаются вопросом, как эффективно интегрировать AI -агентов. Это боты, которые могут воспринимать запросы на естественном языке и выполнять действия.

Уверен, вы уже сталкивались с различными экспериментами по внедрению этих маленьких помощников в продукты. Результаты могут быть разными: от непонятных дополнений, которые скорее мешают, чем помогают, до гениальных, зачастую едва заметных улучшений, без которых потом трудно представить жизнь.

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

Так как же построить инфраструктуру, которая использует всё, что мы узнали о возможностях AI-агентов, не возлагая на них слишком много или слишком мало ответственности? И смогут ли конечные пользователи когда-либо доверять AI принятие критически важных решений?

Итак, вы смоделировали все процессы, написали бизнес-логику и задеплоили все на сервер. Запускаем наши процессы на проде! Поехали? – Но дальше разложено множество граблей, на которые обычно наступают все, кто только начинает эксплуатировать BPM, в том числе и на движке Camunda 7. Эта статья сэкономит вам много времени и успокоит нервы – потому что ситуации, описанные ниже, могут изрядно их попортить, если вы будете не готовы. 

Интересно, как работают технические транзакции с Camunda и фреймворком Spring? Узнайте больше о транзакционном поведении в этом посте.

Ниже приведен обзор всех нововведений в Camunda в релизе 8.7-alpha3, который вышел в январе 2025 года.

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

Бернд Рюкер рассказывает о о преимуществах использования паттерна external task по сравнению с JavaDelegate и уверяет, что это совсем не больно. А если вы хотите использовать standalone-движок, то в общем-то у вас нет выбора, только external task.

Вам нужно интегрировать несколько компонентов без помощи менеджеров транзакций с поддержкой ACID (атомарность, согласованность, изоляция и долговечность)? Тогда этот пост для вас.

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

Введенный в 2015 году, паттерн внешней задачи (external task pattern) становится всё более популярным. Вместо того чтобы движок процессов активно вызывал какой-либо код (push), паттерн внешней задачи добавляет работу в некую очередь и позволяет воркерам (workers) извлекать их по мере необходимости. Этот метод также известен как публикация/подписка (publish/subscribe). Движок процессов публикует задачи, а воркеры подписываются на их выполнение.

В течение длительного времени мы выступали за архитектуру, в которой BPM-движок Camunda встроен в ваше Java-приложение, предпочтительно через Camunda Spring Boot Starter. Однако со временем мы постепенно отошли от этой рекомендации в сторону удалённого движка. В Zeebe мы и вовсе не поддерживаем использование встроенного движка.

В этом посте я хочу объяснить причины этого перехода и почему мы рекомендуем использовать удалённый движок. Однако сначала давайте разберёмся, почему встроенный движок изначально представлял собой привлекательный выбор, и отметим, что изменилось с течением времени. Если вам не интересна эволюция данного вопроса, вы можете пропустить историческую справку и перейти к сравнению архитектур движков.

Хотите узнать, что такое агент ИИ и как можно использовать ИИ для улучшения бизнес-процессов?

-- Читайте перевод статьи из блога Camunda