Это вторая часть серии из двух статей о BPMN и его применении в новых сценариях использования. Вы можете найти первую часть по ссылке. Особая благодарность Бернду Рюккеру за его помощь в написании обеих публикаций.
Добро пожаловать обратно к обсуждению BPMN (Business Process Model and Notation) и его роли в новых сценариях, таких как оркестрация микросервисов. Для понимания материала необязательно читать статьи по порядку, но если вы новичок в BPMN, возможно, будет полезно начать с первой части.
В первой части обсуждалось:
Введение в BPMN.
Почему этот стандарт, успешно применявшийся в прошлом, будет актуален и в будущем.
Типичные паттерны оркестрации, поддерживаемые BPMN.
Текущее состояние и планы развития BPMN в Zeebe.
Во второй части рассматривается:
Примеры, где использование графической модели вместо кода упрощает определение рабочих процессов.
Инструменты для создания графических моделей в BPMN (и другие способы описания рабочих процессов).
Возможность убедиться, что графические модели BPMN не так сложны, как могут показаться, даже если у вас был негативный опыт работы с ними ранее.
Паттерн Saga это просто
Простота графических моделей BPMN иногда скрывает сложность реализации потоков с использованием проприетарного DSL или других кодовых решений вместо BPMN. Итак, начнем с примера, где сравнивается рабочий процесс в BPMN с процессом, определенным на другом языке потоков.
Мы рассмотрим, как реализовать паттерн Saga. Для тех, кто новичок в этой теме, паттерн Saga — это подход к решению задач распределенных транзакций без использования двухфазного коммита. Впервые он обсуждался в исследовательской статье, опубликованной в 1987 году, и становится все более популярными как способ обеспечения согласованности данных, когда организации внедряют распределенные и микросервисные архитектуры.
Чтобы вернуться к классическому примеру саги, мы будем ссылаться на бронирование путешествия, где брони на отель, автомобиль и перелет, обрабатываются разными микросервисами. Все три индивидуальных бронирования должны быть успешными, чтобы общее бронирование поездки было действительным.
Что происходит в случае, когда мы успешно забронировали отель и автомобиль, но бронирование перелета не может быть завершено, например, потому что нет мест на выбранные даты? Мы не можем продолжить оформление поездки, но также должны разобраться с автомобилем и отелем, которые мы уже забронировали.
BPMN предоставляет простое решение в виде компенсации, которая была разработана для отката уже выполненных задач в подобных сценариях. Простой процесс бронирования поездки, реализующий паттерн сага с использованием события компенсации, можно смоделировать в BPMN следующим образом:
Если вы предпочитаете не использовать графическую модель для определения саги, вы можете выбрать подход с использованием API. С помощью Model API от Camunda вы можете определить ту же модель с помощью следующих строк кода (полный пример доступен в репозитории GitHub):
// - flow of activities and compensating actions
flow.startEvent()
.serviceTask("car").name("Reserve car").camundaClass(ReserveCarAdapter.class)
.boundaryEvent().compensateEventDefinition().compensateEventDefinitionDone()
.compensationStart().serviceTask("CancelCar").camundaClass(CancelCarAdapter.class)
.compensationDone()
.serviceTask("hotel").name("Book hotel").camundaClass(BookHotelAdapter.class)
.boundaryEvent().compensateEventDefinition().compensateEventDefinitionDone()
.compensationStart().serviceTask("CancelHotel").camundaClass(CancelHotelAdapter.class)
.compensationDone()
.serviceTask("flight").name("Book flight").camundaClass(BookFlightAdapter.class)
.boundaryEvent().compensateEventDefinition().compensateEventDefinitionDone()
.compensationStart().serviceTask("CancelFlight").camundaClass(CancelFlightAdapter.class)
.compensationDone()
.endEvent();Определение потока — это лишь часть задачи. В паттерне саги также необходимо отслеживать задачи, которые уже выполнены, и иметь возможность ссылаться на это состояние. Многие движки рабочих процессов, исполняющие модели BPMN (включая Camunda и Zeebe), созданы для таких операций с состоянием, что позволяет легко определить, какие действия нужно откатить при выполнении саги.
Конечно, мы не утверждаем, что BPMN в сочетании с движком рабочих процессов — единственный язык потоков, поддерживающий паттерн саги. Однако мы считаем, что BPMN позволяет реализовать паттерн саги гораздо проще, чем другие инструменты.
Этот пост Яна Цуя демонстрирует пример реализации саги с использованием Amazon States Language в AWS Step Functions. В Amazon States Language создание процесса бронирования поездки и отмены требует написания более 80 строк JSON. А визуальное представление, созданное веб-приложением Step Functions на основе кода, не является особенно интуитивным по сравнению с моделью BPMN.
В реальном приложении, где поток неизбежно становится более сложным (с логикой повторных попыток, точками принятия решений, параллельными путями, уведомлениями клиентов на основе различных результатов и другими аспектами), как код на States Language, необходимый для определения потока, так и созданная визуальная модель становятся сложнее для управления и понимания. В BPMN такие изменения остаются относительно простыми для понимания и реализации.
Небольшое уточнение: мы хотим подчеркнуть, что пост Яна написан очень хорошо, и его пример оказался весьма полезным для понимания того, как реализовать сагу в AWS. Наше сравнение BPMN и Amazon States Language / Step Functions ни в коем случае не является критикой его работы!
Сложные BPMN-потоки в реальном мире
Чтобы лучше понять, как BPMN упрощает сложную логику потоков, давайте рассмотрим реальную модель BPMN. Модель ниже была представлена в презентации о оркестрации микросервисов с использованием Camunda BPM от Ливена Вандегаера из бельгийской компании MEDIAGENIX, которая помогает своим глобальным клиентам из медиаиндустрии управлять жизненным циклом контента для вещателей. В своем докладе MEDIAGENIX описывает, как они создали платформу на основе микросервисов для предоставления решения видео по запросу для телекоммуникационной компании, обрабатывая транскодирование, шифрование и публикацию медиафайлов.
Одна из их моделей рабочих процессов показана ниже. Каждая задача в этой модели выполняется отдельным микросервисом, а движок Camunda BPM отвечает за оркестрацию этих сервисов.
Последовательность, содержащая шлюзы "или" и "и/или", два встроенных подпроцесса и более 15 различных задач (некоторые из которых являются задачами с несколькими экземплярами), выражена в BPMN лаконично — и таким образом, что её может понять как технический, так и нетехнический специалист. Огромная сложность становится управляемой благодаря этой графической модели.
Это подводит нас к важному моменту: разработчики, отвечающие за написание логики потоков, — не единственная группа, которая получает выгоду от графических моделей BPMN. BPMN также служит основой для кросс-функционального взаимодействия.
Графические модели как инструмент для сотрудничества (или BizDevOps)
Определение сложных потоков с помощью графических моделей может сэкономить время разработчиков и упростить обеспечение точности выражения логики потока.
Не менее важно, что использование графики расширяет круг людей, которые могут интерпретировать модель рабочего процесса, участвовать в процессе проектирования и предоставлять поддержку и анализ после запуска процесса в эксплуатацию. Мы называем это BizDevOps (Business + Development + Operations), и Бернд Рюккер также писал о важности этой концепции.
Мы уже отмечали, что нетехнический участник, который едва ли смог бы прочитать исходный код логики потока, легко может понять визуальную модель в BPMN, чтобы убедиться, что она соответствует бизнес-требованиям.
Модели BPMN также служат источником информации для бизнес-аналитиков, которым необходимо отслеживать рабочие процессы, понимать производительность процессов и выявлять пути для улучшений. В Camunda это реализовано в виде Optimize — аналитического инструмента, созданного для ответственных за процесс. Optimize предоставляет тепловые карты процессов, наложенные на модели, отчеты, экспорт данных, оповещения и многое другое — всё это основано на данных рабочего процесса, сгенерированных исходной графической моделью.
Движок рабочих процессов BPMN также может предоставлять техническим операционным командам контекст, необходимый для понимания и решения проблем в запущенных процессах. С помощью соответствующих инструментов операторы могут вмешиваться в реальном времени, исправлять неудачные экземпляры процессов или корректировать поврежденные данные, поддерживая систему в рабочем состоянии.
Camunda предоставляет операторам инструменты через Cockpit, который предлагает панель управления со всеми запущенными моделями BPMN и выделяет технические инциденты. Zeebe также будет иметь собственный инструмент для технических операторов.
Этот «жизненный цикл рабочего процесса», обеспечиваемый BPMN и сопутствующим инструментарием, где участники, не входящие в команды разработчиков, могут активно участвовать в итерациях модель->анализ->улучшение, является чрезвычайно мощным, но часто недооцененным. И во многом это становится возможным благодаря тому, что BPMN основан на графических моделях — естественном способе сотрудничества технических и нетехнических участников команды.
Мы бы даже сказали, что кросс-командное сотрудничество, которое становится возможным благодаря BPMN, настолько ценно, что перевешивает любые потенциальные недостатки.
«Вы уверены в этом? Должен же быть какой-то подвох, верно? Разве графические модели не полны скрытых опасностей и подводных камней в панелях свойств?»
Напротив! Мы в Camunda убеждены, что…
Разработчики тоже могут любить инструменты графического моделирования (если они сделаны правильно)
По нашему опыту, большинство разработчиков хотя бы раз сталкивались с негативным опытом работы с графическими моделями. Существует несколько проблем, о которых мы слышим, включая, но не ограничиваясь:
Принуждение к использованию посредственных инструментов моделирования — это может означать очень плохой пользовательский опыт при самом моделировании или что-то более специфическое, например, проблемы с diff и merge при использовании моделера.
Тревога по поводу скрытой сложности, скрывающейся за красивой моделью — так называемая «смерть от панели свойств».
Эти опасения оправданы, но хорошая новость заключается в том, что их можно устранить — и поэтому нет причин отказываться от BPMN и его преимуществ.
В Zeebe мы решаем эти проблемы следующим образом:
Предоставление легковесного инструмента для моделирования с отличным пользовательским опытом. Вы можете скачать его и попробовать, если хотите. Он основан на bpmn.io — открытой JavaScript-, которую вы можете встроить в своё собственное приложение.
Инструмент графического сравнения, который действительно работает — попробуйте демо здесь. Мы можем сказать, что в реальных проектах нам никогда не поступают жалобы на слияние BPMN и XML на уровне файлов.
Поддержка инструментов на основе кода для создания моделей. В настоящее время Zeebe предлагает экспериментальное определение рабочих процессов с использованием YAML и вскоре представит свою версию Model API от Camunda — Java DSL для определения рабочих процессов, на который мы ссылались в примере саги. Другим примером возможностей является Fluent Builder API от Camunda, который позволяет создавать базовые процессы всего за несколько строк кода. С использованием Fluent Builder API следующий код…
BpmnModelInstance modelInstance = Bpmn.createExecutableProcess()
.startEvent()
.userTask()
.parallelGateway()
.scriptTask()
.endEvent()
.moveToLastGateway()
.serviceTask()
.endEvent()
.done();…создаст такую графическую модель:
При всем этом мы действительно верим в силу графики для определения сложных потоков. Для простых последовательностей может быть эффективно использовать Model API. Однако большинство реальных сценариев использования гораздо сложнее, с учетом обработки ошибок, таймаутов, компенсации, корреляции сообщений и других факторов.
В этих сложных потоках графика может сэкономить время, позволить техническим и нетехническим командам сотрудничать и предоставить способ проверки логики модели перед запуском в производство.
Существует и компромиссный подход. Вы можете начать создание модели с использованием Model API, экспортировать модель в XML-файл, который можно использовать в инструменте графического моделирования, а затем продолжить разработку и сотрудничество с использованием графической модели. Подходы на основе API и графики работают вместе, по мере того как модель развивается шаг за шагом.
Подводя итоги
Мы уделили время написанию этих постов, потому что пока не встретили другого языка потоков, который мог бы решать задачи оркестрации микросервисов (и других новых сценариев использования) так же эффективно, как BPMN. Этот стандарт примечателен своей полнотой с точки зрения логики потоков и тем, что он служит точкой взаимодействия для самых разных типов пользователей на протяжении всего жизненного цикла рабочего процесса. Во второй части мы надеемся, что вы убедились в следующем:
Графические модели в BPMN могут значительно упростить определение и проверку сложных логических потоков.
Графические модели — это мощный способ преодолеть разрыв между техническими и нетехническими командами, значительно упрощая определение сложных рабочих процессов.
Графические модели не стоит бояться, если они сделаны правильно, а Zeebe предоставляет удобные инструменты моделирования, которые избавляют вас от "смерти от панели свойств". Но вы всегда можете определять рабочие процессы с помощью кода, если предпочитаете этот подход.
В более широком смысле, мы надеемся, что теперь у вас есть полное представление о том, почему BPMN может (и уже играет) ключевую роль в современных архитектурах. По мере развития Zeebe мы будем предоставлять больше ресурсов о BPMN и его применении для оркестрации микросервисов.
Подписывайтесь на Telegram канал BPM Developers.
Рассказываем про бизнес процессы: новости, гайды, полезная информация и юмор.
