Данный инструмент позволяет автоматизировать бизнес-процессы, описанные в нотациях BPMN 2.0.

 

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

 

Так и произошло — команда столкнулась с «FlowableOptimisticLockingException». Эта проблема возникала редко и пропадала при повторном запуске процесса.

 

В поиске ответов, обратились к теории. В обеспечении стабильности Flowable важную роль играет оптимистичная блокировка — если две транзакции одновременно обновляют один и тот же ресурс, то одна из них завершается с ошибкой.

Business Process Model and Notation (BPMN) — это стандартизированный метод отображения блок-схем, для создания и обмена простыми для понимания диаграммами. В нашей BPMN схеме параллельных транзакций не было. В чем же причина появления «FlowableOptimisticLockingException»?

 

Рассмотрим на примере одного шага Flowable. Первым делом мы формировали запрос во внешний источник, далее отправляли его в нужный микросервис. Flowable сохранял текущее состояние и транзакция завершалась. Оставалось дождаться ответа микросервиса. Когда ответ приходил, мы обрабатывали его и переходили на следующий шаг Flowable в новой транзакции.

 

Но иногда ответ от микросервиса поступал моментально. Первая транзакция не успевала завершиться, две транзакции работали параллельно и возникала ошибка. В программировании этот случай называют «состоянием гонки».

 

После того как установили источник проблемы, решение пришло быстро — перенести отправление запроса в микросервис после завершения первой транзакции. Это помогло избавиться от бесконечной гонки.