BPMN-модель как основа для реализации процессов в СИЭР. Часть 3

#Уголок_профессора

Часть 3. Модель и архитектура решения

Когда для моделей исполняемого уровня техническая архитектура решения диктует определенные ограничения, мы имеем дело уже с не просто стилем, а полноценной философией.

Что касается системы СИЭР, она «заточена» под статусную (реализуется без использования BPM-движка — другой бизнесовой обвязкой), событийную (реализуется BPM-движком) и статусно-событийную философии. BPMN-модели, подготовленные для исполнения в СИЭР, обычно имеют событийную стилистику, однако дополнительная бизнесовая обвязка, которая всегда используется в связке с движком, опирается и на статусную модель, поэтому процессы будет корректно считать статусно-событийными.

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

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

При этом важно не смешивать два разных признака: палитру элементов на схеме и принцип управления процессом. Событийность означает не отказ от задач, а то, что ход экземпляра процесса определяется наступлением значимых событий: получено сообщение, истёк срок, пришёл ответ внешней системы, пользователь принял решение, завершилась обработка данных.

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

Таким образом, наличие задач не делает модель несобытийной, а их отсутствие само по себе не доказывает событийность. Событийный стиль определяется тем, что процесс построен вокруг ожиданий, состояний и реакций на события, а не вокруг запрета на использование задач. Даже user task в событийной модели вполне нормально живут. И СИЭР их поддерживает! Но в основном портал ведёт «задачи пользователя» у себя на фронтовом клиенте, а движку приходит лишь событие «действие выполнено» («документ принят», «решение вынесено», «замечания устранены») — на схеме подразумевать это удобно событием. Поэтому процессы здесь выглядят преимущественно как цепочки реакций на события, сопровождаемые ожиданием этих событий (получения сообщений, сигналов, истечения сроков и проч.).

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

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

Практически это означает, что процессная схема начинает описывать не всю пользовательскую или системную работу «внутри”, а точки ожидания и реакции: чего ждём, от кого ждём, какое сообщение должно прийти, какие данные оно несёт, как соотнести его с нужным экземпляром процесса и что делать, если событие не наступило. Тем самым схема становится ближе не к инструкции для сотрудника, а к карте управления жизненным циклом экземпляра процесса.

Именно в этом месте событийный стиль лучше встраивается в техническую архитектуру. В распределённой системе BPM-движок не обязан владеть каждым действием пользователя или каждой операцией внешнего сервиса. Портал, реестр, платёжная система, ведомственная ИС или интерфейсная обвязка могут выполнять свою часть работы самостоятельно, а процессу передавать уже значимый результат. Движок при этом выполняет роль оркестратора: отправляет запрос, переводит экземпляр в ожидание, принимает сообщение, выбирает дальнейшую ветку, контролирует сроки и исключения.

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

Для аналитической работы это тоже важно. Событийный стиль заставляет раньше и точнее выявлять границы ответственности: что выполняет BPM-движок, что остаётся на стороне портала или бизнесового модуля, какие события они должны передать в процесс, какие данные нужны в payload, какие статусы должны измениться, где нужны таймауты, ретраи, эскалации или альтернативные ветки. Вместо общей формулировки «сотрудник рассмотрел заявление» приходится уточнить: каким действием это завершается для системы, какое сообщение приходит в процесс, какие варианты результата возможны и что происходит при каждом из них.

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

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

Факторы выбора событийной модели

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

Поэтому удобно, когда модель явно показывает, какое сообщение ожидается, что делать при его получении и какие альтернативы предусмотрены при ошибке, таймауте или отсутствии ответа. И событийный стиль органично поддерживает подобные асинхронные сценарии: пользователь, совершая манипуляции в интерфейсе, инициирует событие, а система обработает его, когда будет готова. Это повышает отказоустойчивость и позволяет обрабатывать большое количество параллельных запросов, что особенно важно для высоконагруженных систем, какой является ФГИС ПГС.

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

Хорошо видно это на примере процесса отмены заявления на посещение ООПТ (рис. 1-2). Хоть описательная схема и относительно сложна, это связано с отображением хореографии двух пулов, при этом нижний процесс на ней (непосредственно ПГС, для которого потребуется исполняемая схема) на описательном уровне все равно выглядит достаточно просто: заявитель принимает решение об отмене, система получает соответствующее обращение, после чего заявление либо возвращается, либо заявителю предлагается скорректировать данные и направить исправления (рис. 1). Такая схема удобна для согласования с заказчиком, потому что показывает процесс в человеческой логике: кто инициирует действие, какие варианты выбора есть у заявителя и каким результатом завершается сценарий.

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

На описательной схеме отмена заявления выглядит как пара развилок (рис. 1). В жизни между ними помещается всё, что может пойти не так, и именно это исполняемая модель (рис. 2) берёт на себя. Эффект: заявления перестают зависать — если заявитель не присылает исправления, экземпляр сам закрывается по таймеру или уходит в альтернативную ветку без ручного разбора зависаний. Отмена заявителем и решение ведомства разводятся событийным шлюзом, поэтому разрешение не может оказаться одновременно и отменённым, и выданным. Регламентные сроки — это таймеры прямо на схеме, и их нарушение видно сразу.

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

Преимущества событийной модели

Таким образом, событийная модель даёт несколько преимуществ:

• Лучше соответствует распределённой архитектуре, где разные компоненты выполняют свою часть работы и передают процессу значимые результаты.
• Позволяет явно моделировать ожидания: ответ ведомства, подпись документа, истечение срока, возврат исправлений — здесь в целом более наглядно реализуется работа со временем: таймауты, дедлайны, эскалации, связанные с нарушением сроков («ждать N часов, если не пришло — пойти по ветке M»).
• Событийные шлюзы честно показывают одновременность: реальное дело нередко ждёт сразу несколько фактов — действия заявителя, ответа ведомства и истечения срока — того события, что наступит первым. Процедурная «последовательность» эту гонку прячет за линейностью; событийная схема выносит её на поверхность, заодно делая видимыми риски зависания и места, где нужен контроль срока.
• Событийный стиль делает видимыми точки контроля: где процесс ждёт, где нужны прерывание или альтернативная ветка.
• Упрощает работу с асинхронными сценариями: процесс может отправить запрос, перейти в ожидание и продолжиться после получения сообщения — события позволяют более естественно моделировать процессы, где действия пользователя могут происходить в произвольном порядке или направляются извне.
• Помогает разделить пользовательскую логику, экранные формы, интеграции и собственно процессную оркестрацию.
• Лучше подходит для государственных услуг, где важны регламентные сроки, внешние ответы, статусы заявлений и юридически значимые факты.

Ложка дёгтя

Тем не менее, практический эффект описанного подхода остается двойственным.

Данный стиль может казаться неудобным. Многие привыкли рисовать «последовательность пользовательских задач» — приходится вмешиваться в свои привычки моделирования, думать не только о последовательности пользовательских работ, но и о фактах, которые двигают процесс, данных в сообщениях, точках ожидания и последствиях наступления и ненаступления событий. Событийный стиль требует другого мышления.

Также мы можем лишаться ряда штатных «фич» ради других. Например, у пользовательского действия имеются дополнительные атрибуты (исполнитель, срок), а у события таких атрибутов нет. Иногда подобное приходится компенсировать во внешней «обвязке» процесса, например, специально добавлять атрибуты и (или) скрипты для сборки дашборда активных задач.

Также происходит усложнение наблюдаемости, а именно — поиска мест и причин ошибок исполнения; «точками сохранения» (окончаниями транзакций) у многих BPM-движков выступают элементы ожидания, в том числе события, поэтому даже если ошибка произошла на одной из задач, процесс может откатываться именно до последнего перед ошибкой «сохранения» (то есть события). Это делает неочевидным конкретное место поломки (это не обязательно то событие, на котором стоит токен, вероятна какая-то из задач между ним и следующим событием), если транзакцию, содержащую несколько элементов, не разбили дополнительно на несколько других задач, параметрами можно установить на них дополнительные точки сохранения. Это не критично, но требует внимания, иногда дополнительного логирования.

Повышаются требования к обработке ошибок — например, в случае ошибок в сервисных или скриптовых задачах возможна ситуация, когда процесс не только откатывается к последнему событию, а уходит в цикл: при откате на событие-ожидание при отсутствии нового сохранения возможен ретрай — повторная попытка, снова ошибка и снова возврат к старому сохранению… Наличие массы экземпляров процессов с бесполезными ретраями может перегружать систему. Помимо этого, конкретно в случае СИЭР, где нахождение токена на ожидающем событии-сообщении для интерфейсной обвязки является признаком для отображения кнопок, зависание на них процесса вводит пользователя в заблуждение о том, что он может повлиять на процесс, продвинуть его дальше — что провоцирует дополнительные нажатия и ложные пользовательские ожидания. Приходится предотвращать подобные сценарии, например, прерывать выполнение сервисных задач таймером, ставить дополнительно иные точки сохранения, добавлять альтернативные ветки, эскалации.

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

Тем не менее, событийный стиль в СИЭР стоит понимать не как отказ от задач и не как усложнение схемы ради технологии, а как способ привести исполняемую модель к реальной архитектуре системы. Он делает явными события, статусы, ожидания, внешние зависимости и точки изменения состояния экземпляра процесса. За это приходится платить свою цену, но именно она позволяет использовать BPMN не только как иллюстрацию регламента, но и как рабочий механизм управления процессом в распределённой системе.

Итоги

BPM-движок сам по себе не делает автоматизацию процессов простой. Его ценность раскрывается тогда, когда процесс действительно формализуем, архитектура системы позволяет вынести оркестрацию в отдельный компонент, а команда понимает правила подготовки исполняемых моделей.

На примере СИЭР видно, что BPMN-схема исполняемого уровня — это уже не только способ описать регламент, а событийная (или статусно-событийная) модель управления экземпляром процесса: событиями, статусами, ожиданиями, интеграциями, сроками и негативными сценариями.

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

А ещё BPM-движок продолжает быть практичным и перспективным решением. Он является той деталью конструктора, что повышает его универсальность. Вполне вероятно, что совсем скоро процессы в СИЭР интегрируются с национальным мессенджером и дойдут до оркестрации AI-агентов. А значит, продолжение следует.