Добро пожаловать в четвёртую и заключительную часть серии о новом Flowable Async Executor. До этого момента путь был довольно насыщенным:

Однако остаётся один важный вопрос: как мы пришли к текущей реализации? Что подтолкнуло нас к этим изменениям и почему? Как мы нашли узкие места и использовали эти данные для создания лучшего подхода? И, учитывая, что первая версия появилась более десяти лет назад, как Async Executor эволюционировал, сохраняя обратную совместимость?

Именно этому посвящена эта часть. Мы воспользуемся возможностью оглянуться назад и вспомнить различные реализации, которые появлялись за это время. Мы выделили четыре поколения Async Executor и кратко рассмотрим каждое из них. Поскольку Flowable является форком Activiti, история начинается с первой версии Activiti (5.0.0).

На дворе лето, середина года уже позади. Самое время оглянуться назад и критически взглянуть на прогнозы, которые делались в декабре-январе. Итак, давайте посмотрим, что обещали нам по части BPM в 2025 году и что из этого сбылось, а что осталось лишь в фантазиях авторов этих прогнозов. В принципе все писали более-менее одно и то же, поэтому для разбора взял один рандомный прогноз «BPM Solution for 2025: Trends and Updates».

Когда речь заходит о производительности BPM-ldb;rf, главным показателем является пропускная способность заданий и таймеров. Проще говоря: чем больше заданий или таймеров выполняется за определённый промежуток времени, тем быстрее смогут продолжать выполнение процессы или кейсы, которые их используют.

Как получить прозрачность в бизнес-процессах, если архитектура строится на микросервисах и событийных потоках? В своей статье Бернд Рюкер, сооснователь Camunda, делится практическими подходами к отслеживанию и управлению процессами в распределённых системах. Он объясняет, как переход от простого мониторинга событий к полноценной оркестрации помогает лучше понимать происходящее, своевременно реагировать на инциденты и сохранять контроль над сложными бизнес-операциями. В статье разбираются плюсы и минусы различных подходов — от Elastic-подобного мониторинга до использования движков рабочих процессов, а также рассматривается важность баланса между оркестрацией и хореографией.

Добро пожаловать во второй пост серии о Flowable Async Executor. В первой части мы рассмотрели базовые понятия: что такое асинхронные задания и таймеры, и почему они полезны при построении BPMN- и CMMN-моделей. В последнем разделе мы также показали общую схему новой архитектуры Async Executor.

Исключения являются частью любого процесса. Разработчики, создающие бизнес-процессы, должны уметь обрабатывать исключения в бизнес-кейсе, чтобы гарантировать, что сам процесс устойчив и может продолжаться после возникновения сбоев. Логика обработки исключений различается в зависимости от вашей задачи и инструментов, которые у вас есть в распоряжении. В этой заметке я попытался определить различные методы обработки исключений, используя язык паттернов. Каждый паттерн следует определённой структуре, называемой Контекст (общая ситуация, в которой проблема повторяется), Проблема (формулировка), Условия (условия, при которых можно рекомендовать предложенные решения) и Решение. Итак, давайте приступим.

Flowable Async Executor (также известный как Job Executor) — это ключевой компонент Flowable. По сути, это многократно используемый, автономный компонент, работающий внутри различных движков Flowable и обеспечивающий асинхронное выполнение логики.

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

Я много общаюсь о микросервисных архитектурах с «не-Java-людьми» — будь то разработчики на C#, энтузиасты Node.JS/JavaScript или GoLang. Все они сталкиваются с необходимостью оркестрации в микросервисной архитектуре — или просто хотят использовать workflow, упорядочивание действий, обработку таймаутов, Saga и компенсации, а также другие полезные возможности.

Open Source BPM-платформа Camunda отлично подходит для этих задач. Ориентированность на разработчиков — один из ключевых принципов продукта, но при изучении документации может показаться, что она рассчитана в основном на Java-разработчиков. Платформа предоставляет множество точек расширения и интеграции, но всё это реализуется на Java. Значит ли это, что другим разработчикам путь закрыт?

Нет! На самом деле, запустить Camunda и работать с ней без знания Java очень просто — архитектуру можно выстроить так, чтобы писать код на любом удобном языке. В этом посте:

Low code стремительно ворвался в корпоративный ландшафт, чего от него никто не ожидал. Мы думали — ну, да, занятная вещица, пусть пользователи поиграют в программистов, лишь бы работать не мешали. А сегодня куда ни глянь, все хотят, чтоб даже у серьезных энтерпрайз-решений обязательно были какие-то хотя бы элементы лоукода. Но зачем?

Не знаю, как у вас, но моя жизнь состоит из хаотичных «воркфлоу» и «процессов», полных сюрпризов и неожиданных ошибок, которые не работают так, как ожидается, потому что я сама немного сумасшедшая, забывчивая и непредсказуемая. Однако в бизнесе такой хаос недопустим, и именно поэтому компании стремятся автоматизировать свои процессы и обращаются к разработчикам, чтобы мы нашли решение. К счастью, существует множество платформ, позволяющих создавать надёжные, масштабируемые и управляемые воркфлоу, которые можно визуализировать так, чтобы любой заинтересованный (с техническими знаниями или без) мог видеть, что происходит в процессе. Эта статья — краткое введение в платформы автоматизации воркфлоу Camunda и Flowable, демонстрация примера автоматизации, лучшие практики и основные сложности при использовании этих платформ.

Как перейти от первых проектов к успешной автоматизации сотен процессов с помощью гибкого пошагового подхода.

Нам часто задают такие вопросы:

— Как масштабировать внедрение Camunda в рамках всей компании?

— Как создать корпоративную платформу для управления процессами?

Мы видим, как масштабно Camunda используется в таких компаниях, как Goldman Sachs (3000 процессов, 8000 пользователей в день), Societe Generale (600 процессов, 60 000 завершённых задач в месяц, 7500 активных пользователей) или 24Hour Fitness (800 процессов, 230 миллионов выполнений активностей в день). Как нам достичь такого уровня?

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

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

Кстати, такая же ситуация в архитектуре. Если вы видите на улицах какие-то уродливые дома, они появились не потому, что архитекторы были криворукие. Решение о том, каким будет дом, принимает заказчик. И предполагать у него наличие художественного вкуса было бы большой натяжкой. Потому и появляется вот такое:

Вы начали свой первый проект, используя автоматизацию бизнес-процессов как сервис с Camunda Cloud? Одной из первых задач будет набросать базовую архитектуру вашего решения. Этот блог-пост поможет вам ответить на важные начальные вопросы: как подключить движок выполнения процессов Zeebe к вашему приложению или к внешним системам? Что такое job worker, какую роль он играет и сколько их вообще нужно?

«Могу ли я выполнять 10, 100 или 1000 экземпляров процессов в секунду на этом кластере Camunda 8?»

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

Эта статья продолжает цикл BPMN: Beyond the Basics – о скрытых нюансах и подводных камнях BPMN для разработчиков. Сегодня поговорим о процессных переменных — для чего они используются в процессе, чем отличаются от переменных в языках программирования и как работают области видимости. Казалось бы, что тут обсуждать? — Однако, если погрузиться на уровень поглубже аналитического, то обнаруживается много интересного. Поэтому в одну статью даже не поместилось, пришлось делить на две части.

Это вторая часть. Первую часть читайте здесь.

Эта статья продолжает цикл BPMN: Beyond the Basics – о скрытых нюансах и подводных камнях BPMN для разработчиков. Сегодня поговорим о процессных переменных — для чего они используются в процессе, чем отличаются от переменных в языках программирования и как работают области видимости. Казалось бы, что тут обсуждать? — Однако, если погрузиться на уровень поглубже аналитического, то обнаруживается много интересного. Поэтому в одну статью даже не поместилось, пришлось делить на две части.

Мы все видели, как такие инструменты, как ChatGPT, справляются с множеством бизнес-задач, автоматизируя практически всё.

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

Что такое коннектор? Как выглядит код коннектора? И как коннекторы могут использоваться в различных сценариях?

Когда в этом году была выпущена Camunda Platform 8, мы анонсировали коннекторы и предоставили несколько предварительных версий коннекторов в нашем SaaS-решении, например, отправка email через SendGrid, вызов REST API или отправка сообщения в Slack.

С тех пор многие задавались вопросом, что такое коннектор, как он разрабатывается и как его можно использовать в Self-Managed-окружении. Мы пока не публиковали много информации о технической архитектуре коннекторов, поскольку она всё ещё находится в разработке. Тем не менее, я отлично понимаю, что вам может быть интересно узнать больше, чтобы вдохновиться коннекторами так же, как и я.

Pro-code — наше сердце и душа, но люди и процессы бывают разными. Наши необязательные low-code-функции расширяют спектр применений, не мешая разработчикам.
 
Разработчики часто спрашивают меня о стратегии развития продуктов Camunda. Особенно во время запуска Camunda 8 они выражали обеспокоенность тем, что мы якобы «забыли свои корни» или «отказались от удобства для разработчиков» — именно те качества, за которые нас любят. Появилось мнение, что мы «прыгнули в поезд low-code», потому что у нас теперь есть финансирование и мы хотим «гнаться за большими деньгами». Как разработчик в душе, я могу вас уверить — это совсем не так. Позвольте объяснить нашу стратегию в этом посте.
 
TL;DR: Мы остаёмся на 100% дружелюбными к разработчикам, и pro-code — это наше всё (можно сказать, наш хлеб с маслом). Но люди, создающие процессные решения, бывают разными — как и сами процессы, которые нужно автоматизировать. Для некоторых сценариев low-code действительно имеет смысл, и здорово, что мы можем их поддерживать. Но low-code-функции в Camunda являются необязательными и никак не мешают pro-code-разработке.