BPMN-модель процессов приложения и событийно-ориентированная оркестрация симулятора

Производственная спецификация сквозных конвейеров в нотации BPMN 2.0 для смешанных сред

Author

Core Infrastructure & Simulation Framework Documentation

Published

June 11, 2026

1 Введение: Теоретические основы и назначение нотации BPMN 2.0

В процессе проектирования, развертывания и масштабирования распределенных программных комплексов, а также платформ Цифровых симуляторов бизнес-процессов, ключевой задачей бизнес анализа становится стандартизированное описание операционной логики. Для решения этой задачи применяется международный стандарт BPMN 2.0 (Business Process Model and Notation) [BPMN 2.0 Specification].

BPMN 2.0 представляет собой графический язык и систему декларативных правил, предназначенных для моделирования сквозных процессов. В ИТ-документации нотация выполняет роль универсального интерфейса (контракта) между бизнес-аналитиками (BA), системными аналитиками (SA), архитекторами данных и менеджментом продукта (Product Owners).

1.1 Ключевые аналитические задачи, решаемые внедрением BPMN-спецификации:

  • Формализация сквозных регламентов: Перевод абстрактных пользовательских сценариев на строгий язык процессных шагов, контрольных точек и условных развилок.
  • Декомпозиция зон ответственности: Четкое графическое разграничение действий, выполняемых на стороне интерфейса мобильного приложения (Flutter), оркестрации на стороне внутренних сервисов бэкенда и проверок во внешних государственных системах.
  • Прозрачность для смешанных сред (Люди и Симуляторы): Проектирование единых процессных рельсов. Когда реальный сотрудник выполняет операцию на экране смартфона, система инициирует те же цепочки событий, какие генерируют автоматизированные агенты (цифровые двойники) в рамках ускоренной эмуляции поведения. Это гарантирует абсолютную идентичность структуры собираемых данных.

2 Концепция пулов (Pools) и дорожек (Lanes) как архитектурных границ

Моделирование процессов в нотации BPMN базируется на разделении операционного ландшафта на независимые контексты выполнения, визуализируемые в виде пулов и дорожек.

2.1 1. Структурные Пулы (Pools) как границы участников

Пул в BPMN обозначает наивысший уровень абстракции и представляет собой независимого участника процесса (изолированную программную систему или контур окружения). Взаимодействие между пулами в BPMN осуществляется строго асинхронно посредством потоков сообщений (Message Flows). В архитектуре платформы выделяется три ключевых пула:

  • Пул клиентского окружения (Client-Side Pool): Включает активность на внешнем периметре (действия людей в приложении, генерацию пакетов и оффлайн-буферизацию телеметрии при деградации сети и эмуляционные алгоритмы ботов-симуляторов).
  • Пул бэкенд-инфраструктуры (Backend Infrastructure Pool): Инкапсулирует внутреннюю логику обработки, валидации, распознавания и персистентного (постоянного) сохранения данных.
  • Пул внешних государственных сервисов (External Government Registry Pool): Изолированная государственная информационная система (E-Gov / Сервис цифровых досье сотрудников). Взаимодействует с пулом бэкенда по защищенному протоколу SOAP 1.1, выполняя обязательную внешнюю верификацию легитимности субъектов (проверка SSN, паспортов, статусов электронных цифровых подписей и прочих документов основанных на местном законодательстве).

2.2 2. Дорожки (Lanes) как зоны функциональной ответственности

Внутри пула бэкенда процесс детализируется с помощью дорожек (Lanes), разграничивающих зоны ответственности конкретных сервисов и функциональных узлов. Внутри одного пула элементы могут связываться напрямую с помощью потоков управления (Sequence Flows):

  • Дорожка шлюза доступа (Gateway Lane): Фиксирует процессы первичного приема трафика, маршрутизации и распределения потоков сообщений.
  • Дорожка асинхронного ядра (Core Backend Lane): Закрепляет за собой логику оркестрации, маппинга данных, координирования внешних SOAP-вызовов к госсервису, генерации Push-уведомлений и управления состояниями сессий.
  • Дорожка аналитических ИИ-вычислений (AI Compute Lane): Отвечает за процессы высокотехнологичного распознавания (Whisper-транскрипция речи, OCR-парсинг чеков, фитосанитарный анализ изображений болезней растений).
  • Дорожка брокера сообщений (Apache Kafka Lane): Очередь сообщений, функционирующая в KRaft-режиме, выступающая буфером между контуром приема данных и аналитическими модулями.
  • Дорожка персистентного хранения (Database Lane): Фиксирует этапы записи данных в реляционные таблицы PostgreSQL (auth_db и business_db).
  • Дорожка аналитики Process Mining (bupaR Lane): Выделенный контур на языке R, считывающий стрим событий из Kafka для восстановления реальных графов процессов.

3 BPMN-модель контура на примере агротехнического мониторинга (AgroLaborApp)

Операционная деятельность на объектах агропромышленного комплекса автоматизирована в виде двух последовательных декомпозированных процессов. Это позволяет аналитикам изолировать этап административной проверки прав доступа от этапа выполнения непосредственных технологических операций.

WarningВажное примечание

Парадигма Docs-as-Code (Документация как код) Настоящий документ и все содержащиеся в нем схемы процессов разрабатываются строго в рамках концепции Docs-as-Code. Схемы и диаграммы не являются бинарными файлами (картинками, отчужденными от текста). Вместо этого применяется текстовая нотация Mermaid (State Diagrams / Flowcharts), стилизованная под логику BPMN. Они описываются декларативным текстовым кодом, версионируются в Git совместно с исходным кодом системы и автоматически рендерятся при сборке документации.

3.1 Подпроцесс 1: Инициализация сессии и внешняя SOAP-верификация досье

Данный процесс описывает регламент входа субъекта (работника агропромышленного комплекса или цифрового двойника симулятора) в операционный контур. Ключевым бизнес-правилом является обязательное сквозное подтверждение легитимности исполнителя во внешнем государственном реестре (либо внутренняя проверка досье) до момента активации сессии в локальной СУБД.

WarningВажное примечание

В настоящей публичной документации отображены не все шаги и сценарии для приложения в частности и для системы цифровых симуляторв бизнес-процессов в общем.

Ниже представлена схема взаимодействия пулов и дорожек при верификации профиля:

flowchart TB
    %% ==========================================
    %% POOL 1: CLIENT SIDE
    %% ==========================================
    subgraph Pool_Client ["📱 ПУЛ: КЛИЕНТСКОЕ ОКРУЖЕНИЕ И СИМУЛЯЦИЯ"]
        direction LR
        subgraph Lane_App ["Дорожка интерфейса и эмуляции"]
            Start_Auth((Старт авторизации)) --> Task_Login[Задача: Ввод учетных данных и SSN]
            Task_Login --> Dispatch_Auth[Отправить запрос на аутентификацию]
            
            Catch_Push_Revoke((Перехват Push: Отзыв прав)) --> Action_Force_Logout[Задача: Принудительный Force Logout]
            Action_Force_Logout --> End_Auth_Fail((Сессия аннулирована))
        end
    end

    %% ==========================================
    %% POOL 2: BACKEND INFRASTRUCTURE
    %% ==========================================
    subgraph Pool_Backend ["⚙️ ПУЛ: БЭКЕНД-ИНФРАСТРУКТУРА ПЛАТФОРМЫ"]
        
        subgraph Lane_Nginx ["🌐 Дорожка шлюза Nginx Proxy"]
            Inbound_Auth_Proxy{Прокси авторизации}
        end

        subgraph Lane_FastAPI ["⚙️ Дорожка асинхронного ядра FastAPI"]
            Task_Validate_Local[Задача: Проверка локального хэша пароля]
            Task_Build_SOAP[Задача: Формирование XML-пакета SOAP 1.1]
            Task_Evaluate_Gov[Задача: Оценка ответа государственного реестра]
            
            Gateway_Gov_Check{"Шлюз: Профиль валиден?"}
            
            Task_Revocation_Pipeline[Задача: Запуск каскадного отзыва сессий]
        end

        subgraph Lane_Postgres ["🐘 Дорожка базы данных PostgreSQL"]
            DB_Auth_Read[("Таблица: users")]
            DB_Auth_Write[("Таблица: refresh_tokens / digital_employees")]
        end
    end

    %% ==========================================
    %% POOL 3: EXTERNAL GOV REGISTRY
    %% ==========================================
    subgraph Pool_Gov ["🏛️ ПУЛ: ВНЕШНИЙ ГОСУДАРСТВЕННЫЙ РЕЕСТР (E-GOV)"]
        Service_SOAP_Endpoint{SOAP WSDL: fetch_secure_employee_data}
    end

    %% МЕЖПУЛОВЫЕ ПОТОКИ СООБЩЕНИЙ (Message Flows)
    Dispatch_Auth -.->|HTTP POST: Credentials| Inbound_Auth_Proxy
    Inbound_Auth_Proxy --> Task_Validate_Local
    
    Task_Validate_Local --> DB_Auth_Read
    DB_Auth_Read --> Task_Build_SOAP
    
    %% SOAP-взаимодействие с внешним контуром
    Task_Build_SOAP -.->|SOAP Request: XML Payload| Service_SOAP_Endpoint
    Service_SOAP_Endpoint -.->|SOAP Response: GovEmployeeProfile| Task_Evaluate_Gov
    
    Task_Evaluate_Gov --> Gateway_GovCheck
    
    %% Ветвление шлюза верификации
    Gateway_Gov_Check -- Да: Успешно --> DB_Auth_Write
    DB_Auth_Write --> End_Success((Сессия успешно активирована))
    
    Gateway_Gov_Check -- Нет: КОМПРОМЕТАЦИЯ --> Task_Revocation_Pipeline
    Task_Revocation_Pipeline --> DB_Auth_Write
    
    %% Обратный Push-поток изоляции клиента
    Task_Revocation_Pipeline -.->|Асинхронный Push-уведомление| Catch_Push_Revoke

    %% Стилизация элементов нотации BPMN
    style Start_Auth fill:#d4edda,stroke:#28a745,stroke-width:2px
    style End_Success fill:#d4edda,stroke:#28a745,stroke-width:2px
    style End_Auth_Fail fill:#f8d7da,stroke:#dc3545,stroke-width:2px
    style Gateway_Gov_Check fill:#fff3cd,stroke:#ffc107,stroke-width:2px
    style Inbound_Auth_Proxy fill:#d1ecf1,stroke:#0c5460,stroke-width:2px
    style Service_SOAP_Endpoint fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    
    style Pool_Client fill:#f8f9fa,stroke:#b8daff,stroke-width:1px
    style Pool_Backend fill:#fffdfd,stroke:#f5c6cb,stroke-width:1px
    style Pool_Gov fill:#fcfcfc,stroke:#ced4da,stroke-width:1px

3.2 Бизнес-логика и регламент подпроцесса верификации

С точки зрения системного анализа, данный регламент жестко координирует правила допуска субъектов к инфраструктуре:

  1. Catching-событие и локальная проверка: Процесс инициализируется стартовым событием ввода учетных данных. Сообщение через Nginx-шлюз поступает на дорожку FastAPI, где сервисная задача выполняет сверку хэша пароля с таблицей users в СУБД.
  2. Сквозная SOAP-валидация во внешнем пуле: После успешной локальной проверки ядро FastAPI формирует структурированный XML-пакет в соответствии со строгой WSDL-схемой gov.service.m4. Поток управления покидает пул бэкенда и передается во внешний пул государственного реестра (либо внутренний реестр досье). Сервис fetch_secure_employee_data производит сверку SSN, прочая документация и проверяет, не отозвана ли электронная цифровая подпись сотрудника.
  3. Эксклюзивный шлюз бизнес-исключений: Возвращенный XML-профиль GovEmployeeProfile анализируется на дорожке бэкенда эксклюзивным шлюзом развилки:
    • Штатное ветвление: Если данные гос-сервиса (либо внутреннего реестра досье) валидны, FastAPI осуществляет запись сессионных токенов в refresh_tokens, обновляет статус в digital_employees и переводит процесс в успешное конечное событие.
    • Ветвление компрометации (Revocation Pipeline): Если гос-сервис (либо внутренний реестр досье) возвращает маркер уязвимости, шлюз направляет процесс по маршруту исключения. Задача Task_Revocation_Pipeline аннулирует любые локальные сессионные записи в PostgreSQL, а система генерирует асинхронный обратный поток сообщений (Push-уведомление). Клиентское приложение перехватывает этот сигнал, стирает локальный кэш токенов и осуществляет принудительный сброс сессии (Force Logout).

3.3 Подпроцесс 2: Операционный трекинг полевых работ и фитосанитарный контроль

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

Ниже представлена схема оркестрации операционного конвейера:

flowchart TB
    %% ==========================================
    %% POOL 1: CLIENT SIDE
    %% ==========================================
    subgraph Pool_Client ["📱 ПУЛ: КЛИЕНТСКОЕ ОКРУЖЕНИЕ И СИМУЛЯЦИЯ"]
        direction LR
        subgraph Lane_App_Ops ["Дорожка интерфейса и эмуляции"]
            Start_Ops((Вход на поле)) --> Task_Init_Session[Задача: Запуск таймера и сессии трекинга]
            
            %% Активные действия субъекта
            Task_Init_Session --> Action_GPS[Задача: Потоковая генерация GPS-координат]
            Task_Init_Session --> Action_Photo[Задача: Фотофиксация листа растения]
            Task_Init_Session --> Action_Voice[Задача: Запись Х-секунд голосового отчета]

            %% Потоки отправки
            Action_GPS --> Dispatch_GPS[Отправить пакет телеметрии]
            Action_Photo --> Dispatch_Photo[Отправить снимок на фитосанитарный анализ]
            Action_Voice --> Dispatch_Voice[Отправить аудиозапись WAV]
            
            %% Обратный поток корректировки данных
            Catch_Push_VTT((Перехват Push: Корректировка рапорта)) --> Action_Manual_Fix[Задача: Ручная правка текста в приложении]
            Action_Manual_Fix --> Dispatch_VTT_Confirm[Отправить подтвержденный текст]
        end
    end

    %% ==========================================
    %% POOL 2: BACKEND INFRASTRUCTURE
    %% ==========================================
    subgraph Pool_Backend ["⚙️ ПУЛ: БЭКЕНД-ИНФРАСТРУКТУРА ПЛАТФОРМЫ"]
        
        subgraph Lane_Nginx ["🌐 Дорожка шлюза Nginx Proxy"]
            Inbound_Ops_Proxy{Прокси телеметрии}
        end

        subgraph Lane_Kafka ["⚡ Дорожка брокера Apache Kafka (KRaft)"]
            Topic_GPS[[Топик: tracking.gps.stream]]
            Topic_Photo[[Топик: tracking.photo.analysis]]
            Topic_Voice[[Топик: tracking.voice.vtt]]
        end

        subgraph Lane_FastAPI ["⚙️ Дорожка асинхронного ядра FastAPI"]
            Task_Log_GPS[Задача: Асинхронный маппинг пространственных логов]
            Task_Route_AI[Задача: Оркестрация gRPC вызовов ИИ]
            Task_Process_NLP[Задача: Семантический NLP-парсинг текста и триггеров]
            
            Gateway_VTT_Check{"Шлюз: Достоверность >= Х?"}
            Task_Generate_Push[Задача: Формирование Push-уведомления и черновика]
        end

        subgraph Lane_AI ["🧠 Дорожка аналитических ИИ-вычислений"]
            Service_CNN_Plant{gRPC AI: Фитосанитарный CNN-анализ болезней}
            Service_Whisper{gRPC AI: Whisper Voice-to-Text}
        end

        subgraph Lane_Postgres ["🐘 Дорожка базы данных PostgreSQL"]
            DB_GPS_Write[("Таблица: tracking_event_log (JSONB payload)")]
            DB_Biz_Write[("Таблица: tracking_sessions / voice_transcripts")]
        end
    end

    %% МЕЖПУЛОВЫЕ ПОТОКИ И МАРШРУТИЗАЦИЯ (Message Flows & Routing)
    Dispatch_GPS -.->|HTTP POST: Telemetry JSON| Inbound_Ops_Proxy
    Dispatch_Photo -.->|HTTP POST: Multipart Photo| Inbound_Ops_Proxy
    Dispatch_Voice -.->|HTTP POST: Binary WAV| Inbound_Ops_Proxy
    Dispatch_VTT_Confirm -.->|HTTP POST: Verified Text| Inbound_Ops_Proxy

    Inbound_Ops_Proxy -->|Пуш в стрим| Topic_GPS
    Inbound_Ops_Proxy -->|Пуш в стрим| Topic_Photo
    Inbound_Ops_Proxy -->|Пуш в стрим| Topic_Voice

    %% Конвейер 1: Сбор пространственной телеметрии
    Topic_GPS --> Task_Log_GPS
    Task_Log_GPS --> DB_GPS_Write

    %% Конвейер 2: Фитосанитарный визуальный контроль
    Topic_Photo --> Task_Route_AI
    Task_Route_AI -.->|gRPC: CheckPlantPhoto| Service_CNN_Plant
    Service_Plant_CNN -.->|ImageResponse: Disease Detected| Task_Route_AI
    Task_Route_AI --> DB_Biz_Write

    %% Конвейер 3: Голосовой отчет и обработка ИИ-исключений (VTT)
    Topic_Voice --> Task_Route_AI
    Task_Route_AI -.->|gRPC: RecognizeSpeech| Service_Whisper
    Service_Whisper -.->|SpeechResponse: recognized_text| Task_Route_AI
    Task_Route_AI --> Gateway_VTT_Check
    
    %% Ветвление эксклюзивного шлюза достоверности ИИ
    Gateway_VTT_Check -- Да --> Task_Process_NLP
    Task_Process_NLP --> DB_Biz_Write
    DB_Biz_Write --> End_Session_Success((Операция успешно зафиксирована))

    Gateway_VTT_Check -- Нет --> Task_Generate_Push
    Task_Generate_Push --> DB_Biz_Write
    Task_Generate_Push -.->|Асинхронный Push обратной связи| Catch_Push_VTT

    %% Замыкание петли ручного подтверждения черновика
    Inbound_Ops_Proxy --> Task_Process_NLP

    %% Стилизация элементов нотации BPMN
    style Start_Ops fill:#d4edda,stroke:#28a745,stroke-width:2px
    style End_Session_Success fill:#d4edda,stroke:#28a745,stroke-width:2px
    style Gateway_VTT_Check fill:#fff3cd,stroke:#ffc107,stroke-width:2px
    style Inbound_Ops_Proxy fill:#d1ecf1,stroke:#0c5460,stroke-width:2px
    style Service_CNN_Plant fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    style Service_Whisper fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    
    style Pool_Client fill:#f8f9fa,stroke:#b8daff,stroke-width:1px
    style Pool_Backend fill:#fffdfd,stroke:#f5c6cb,stroke-width:1px

3.4 Бизнес-логика и регламент подпроцесса операционного трекинга

Спецификация описывает параллельное выполнение задач нахождения на объекте и асинхронную обработку неструктурированных медиапотоков:

  1. Конвейер непрерывного сбора пространственных логов: При активации сессии клиентское приложение или симулятор начинают циклическую генерацию пакетов GPS-координат. Сообщения амортизируются в топике Kafka tracking.gps.stream. Сервисная задача Task_Log_GPS осуществляет их денормализованную потоковую запись в tracking_event_log. Использование формата JSONB payload позволяет сохранять массивы координат без изменения физической структуры таблиц СУБД.
  2. Контур фитосанитарного визуального контроля: При обнаружении поражения культуры (как один из примеров предметной области для ИИ аналитики) работник отправляет снимок листа. FastAPI Backend по бинарному gRPC-каналу вызывает нейросетевой метод Service_CNN_Plant. Распознанный тип угрозы (болезнь, сорняк, вредитель и прочее) и уровень уверенности модели фиксируются в реляционной таблице tracking_sessions для автоматической корректировки агротехнического плана.
  3. Контур голосовых отчетов и петля обратной связи (Feedback Loop): Голосовой отчет в формате WAV передается через Kafka на дорожку ИИ для Whisper-транскрипции (Service_Whisper). Полученный текст оценивается эксклюзивным шлюзом развилки процесса:
    • Штатный маршрут: При уверенном распознавании (Достоверность \(\ge Х\)) запускается семантический NLP-парсер, вычленяющий ключевые слова-триггеры (например, объем расхода воды или тип операции). Данные сохраняются в базу, и процесс завершается успешным событием.
    • Маршрут ручной корректировки (Бизнес-исключение): Если ИИ не уверен в расшифровке текста, шлюз направляет процесс по ветке «Нет». Задача Task_Generate_Push создает временный черновик в таблице voice_transcripts со статусом PROCESSING и отправляет асинхронный Push-сигнал на мобильное устройство. Работник получает интерактивный экран, выполняет ручную правку текста отчета (зона ответственности работника за отчет) и подтверждает транзакцию. Повторный входящий запрос замыкает петлю, отправляя скорректированные данные напрямую в NLP-парсер бэкенда для финальной записи.

4 BPMN-модель контура на примере учета ресурсов и жизненного цикла продуктов (FoodLifecycleApp)

Управление движением материальных ценностей и теневой экономикой ресурсов (только режим для домашнего использования) декомпозировано на два самостоятельных подпроцесса. Это позволяет изолировать этап контроля ввода Master Data от операционного контура расхода ресурсов.

4.1 Подпроцесс 1: Импорт ресурсов, OCR-распознавание чеков и петля верификации черновиков

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

WarningВажное примечание

В настоящей публичной документации отображены не все шаги и сценарии для приложения в частности и для системы цифровых симуляторв бизнес-процессов в общем.

Ниже представлена схема оркестрации процесса импорта корзины:

flowchart TB
    %% ==========================================
    %% POOL 1: CLIENT SIDE
    %% ==========================================
    subgraph Pool_Client ["📱 ПУЛ - КЛИЕНТСКОЕ ОКРУЖЕНИЕ И СИМУЛЯЦИЯ"]
        direction LR
        subgraph Lane_App_Food1 ["Дорожка интерфейса и эмуляции"]
            Start_Receipt((Покупка совершена)) --> Action_Scan["Задача - Съемка и отправка фото чека"]
            Action_Scan --> Dispatch_Receipt["Отправить снимок чека"]
            
            %% Обратный поток верификации
            Catch_Push_Receipt((Перехват Push - Чек готов)) --> Action_Review_Draft["Задача - Ручная правка ошибок распознавания на экране"]
            Action_Review_Draft --> Dispatch_Confirm_Draft["Отправить подтвержденный черновик"]
        end
    end

    %% ==========================================
    %% POOL 2: BACKEND INFRASTRUCTURE
    %% ==========================================
    subgraph Pool_Backend ["⚙️ ПУЛ - БЭКЕНД-ИНФРАСТРУКТУРА ПЛАТФОРМЫ"]
        
        subgraph Lane_Nginx ["🌐 Дорожка шлюза Nginx Proxy"]
            Inbound_Receipt_Proxy{"Прокси импорта чеков"}
        end

        subgraph Lane_Kafka ["⚡ Дорожка брокера Apache Kafka (KRaft)"]
            Topic_Receipt_In[["Топик - fridge.events.add"]]
            Topic_Receipt_Confirmed[["Топик - fridge.events.unpacked"]]
        end

        subgraph Lane_FastAPI ["⚙️ Дорожка асинхронного ядра FastAPI"]
            Task_Persist_S3["Задача - Асинхронное сохранение файла в MinIO S3"]
            Task_Call_OCR["Задача - Оркестрация gRPC-вызова OCR-модели"]
            Task_Create_Buffer["Задача - Запись сырого JSON во временный буфер"]
            Task_Unpack_Inventory["Задача - Финальная распаковка позиций в инвентарь"]
        end

        subgraph Lane_AI ["🧠 Дорожка аналитических ИИ-вычислений"]
            Service_OCR_Engine{"gRPC AI - OCR-парсер табличных данных чека"}
        end

        subgraph Lane_Postgres ["🐘 Дорожка базы данных PostgreSQL"]
            DB_Receipt_Buffer[("Таблица - pending_receipts_buffer")]
            DB_Inventory_Write[("Таблица - fact_inventory")]
        end
    end

    %% МЕЖПУЛОВЫЕ ПОТОКИ И ВНУТРЕННЯЯ МАРШРУТИЗАЦИЯ
    Dispatch_Receipt -.->|HTTP POST Request| Inbound_Receipt_Proxy
    Dispatch_Confirm_Draft -.->|HTTP POST Request| Inbound_Receipt_Proxy

    Inbound_Receipt_Proxy -->|Пуш первичного события| Topic_Receipt_In
    
    %% Конвейер асинхронного распознавания ИИ
    Topic_Receipt_In --> Task_Persist_S3
    Task_Persist_S3 --> Task_Call_OCR
    Task_Call_OCR -.-> Service_OCR_Engine
    Service_OCR_Engine -.-> Task_Call_OCR
    
    %% Буферизация черновика
    Task_Call_OCR --> Task_Create_Buffer
    Task_Create_Buffer --> DB_Receipt_Buffer
    
    %% Асинхронное уведомление пользователя
    Task_Create_Buffer -.->|Асинхронный Push| Catch_Push_Receipt

    %% Замыкание петли ручной корректировки пользователем
    Inbound_Receipt_Proxy --> Task_Unpack_Inventory
    Task_Unpack_Inventory --> Topic_Receipt_Confirmed
    Topic_Receipt_Confirmed --> DB_Inventory_Write
    DB_Inventory_Write --> End_Unpack_Success((Ресурсы успешно оприходованы))

    %% Управление состоянием буфера при подтверждении
    Task_Unpack_Inventory -.-> DB_Receipt_Buffer

    %% Стилизация элементов нотации BPMN
    style Start_Receipt fill:#d4edda,stroke:#28a745,stroke-width:2px
    style End_Unpack_Success fill:#d4edda,stroke:#28a745,stroke-width:2px
    style Inbound_Receipt_Proxy fill:#d1ecf1,stroke:#0c5460,stroke-width:2px
    style Service_OCR_Engine fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    
    style Pool_Client fill:#f8f9fa,stroke:#b8daff,stroke-width:1px
    style Pool_Backend fill:#fffdfd,stroke:#f5c6cb,stroke-width:1px

4.2 Бизнес-логика и регламент подпроцесса импорта ресурсов

Данная спецификация описывает процесс преодоления нечеткости данных ИИ за счет внедрения транзакционных буферов и человеческого контроля:

  1. Неблокирующий конвейер распознавания чеков: Пользователь осуществляет фотофиксацию чека. Поток данных амортизируется топиком Kafka fridge.events.add. Асинхронное ядро FastAPI перехватывает событие, сохраняет файл в бакет MinIO S3 и по бинарному gRPC-каналу передает ссылку (s3_key) в OCR-движок ИИ. Модель парсит текстовые строки чека в структурированный JSON-массив SKU позиций.
  2. Изоляция черновика в персистентном (постоянном) слое: Полученный от ИИ массив товаров не пишется в мастер-таблицы инвентаря, так как может содержать ошибки (например, некорректное считывание символов). Сервисная задача Task_Create_Buffer осуществляет запись сырого JSON-пакета в промежуточную таблицу pending_receipts_buffer со статусом PROCESSING.
  3. Обратная связь и ручная корректировка (Feedback Loop): Момент фиксации черновика триггерит отправку асинхронного push-уведомления на устройство. Реальный человек открывает экран «Черновики», видит распознанный список и выполняет ручную правку (исправляет опечатки, сопоставляет искаженные названия с эталонным каталогом products_catalog). При нажатии кнопки «Подтвердить» скорректированный и чистый JSON-массив отправляется обратно на бэкенд. Задача Task_Unpack_Inventory обновляет статус черновика, отправляет очищенный DTO-пакет в топик fridge.events.unpacked и производит финальную распаковку позиций в мастер-таблицу инвентаря fact_inventory.

4.3 Подпроцесс 2: Контур приготовления нового блюда (Cook), потребления и утилизации отходов (Waste)

Данный процесс описывает регламент внутреннего движения, изменения состояний и списания ресурсов, находящихся в условном “цифровом холодильнике” fact_inventory [Project 2 Documentation]. Сценарий охватывает как штатное расходование запасов продуктов, так и регистрацию прямых потерь (списание испорченного в мусорку с фиксацией причин в топике waste.add), поддерживая альтернативный канал голосового ввода через gRPC-ноду Whisper.

WarningВажное примечание

В настоящей публичной документации отображены не все шаги и сценарии для приложения в частности и для системы цифровых симуляторв бизнес-процессов в общем.

Ниже представлена схема оркестрации внутреннего жизненного цикла ресурсов:

flowchart TB
    %% ==========================================
    %% POOL 1: CLIENT SIDE
    %% ==========================================
    subgraph Pool_Client ["📱 ПУЛ: КЛИЕНТСКОЕ ОКРУЖЕНИЕ И СИМУЛЯЦИЯ"]
        direction LR
        subgraph Lane_App_Food2 ["Дорожка интерфейса и эмуляции"]
            Start_Lifecycle((Ресурсы на балансе)) --> Task_Hub[Задача: Выбор операционного сценария]
            
            %% Выбор веток
            Task_Hub --> Action_Cook[Задача: Запуск рецепта приготовления]
            Task_Hub --> Action_Consume[Задача: Регистрация факта потребления]
            Task_Hub --> Action_Voice_Waste[Задача: Голосовой рапорт утилизации]

            %% Потоки отправки
            Action_Cook --> Dispatch_Cook[Отправить команду трансформации]
            Action_Consume --> Dispatch_Consume[Отправить объем расхода]
            Action_Voice_Waste --> Dispatch_Voice_Waste[Отправить аудиозапись WAV]
        end
    end

    %% ==========================================
    %% POOL 2: BACKEND INFRASTRUCTURE
    %% ==========================================
    subgraph Pool_Backend ["⚙️ ПУЛ: БЭКЕНД-ИНФРАСТРУКТУРА ПЛАТФОРМЫ"]
        
        subgraph Lane_Nginx ["🌐 Дорожка шлюза Nginx Proxy"]
            Inbound_Food_Proxy{Прокси ресурсов}
        end

        subgraph Lane_Kafka ["⚡ Дорожка брокера Apache Kafka (KRaft)"]
            Topic_Cook[[Топик: bupar.fridge.events.cooked]]
            Topic_Waste[[Топик: bupar.analytics.waste]]
        end

        subgraph Lane_FastAPI ["⚙️ Дорожка асинхронного ядра FastAPI"]
            Task_Execute_Cook[Задача: Рецептурное списание сырья и апдейт инвентаря]
            Task_Sub_Qty[Задача: Вычитание объема ТМЦ из баланса]
            Task_Call_Whisper[Задача: Вызов gRPC-ноды транскрипции]
            Task_NLP_Trigger[Задача: Семантический парсинг триггера ВЫБРОСИЛ]
        end

        subgraph Lane_AI ["🧠 Дорожка аналитических ИИ-вычислений"]
            Service_Whisper_Food{gRPC AI: Whisper Voice-to-Text}
        end

        subgraph Lane_Postgres ["🐘 Дорожка базы данных PostgreSQL"]
            DB_Inv_Update[("Таблица: fact_inventory")]
            DB_Dataset_Write[("Таблица: raw_audio_dataset / waste_log")]
        end
    end

    %% МЕЖПУЛОВЫЕ ПОТОКИ И МАРШРУТИЗАЦИЯ (Message Flows & Internal Routing)
    Dispatch_Cook -.-> Inbound_Food_Proxy
    Dispatch_Consume -.-> Inbound_Food_Proxy
    Dispatch_Voice_Waste -.-> Inbound_Food_Proxy

    Inbound_Food_Proxy --> Task_Execute_Cook
    Inbound_Food_Proxy --> Task_Sub_Qty
    Inbound_Food_Proxy --> Task_Call_Whisper

    %% Конвейер 1: Кулинарная трансформация (Cook)
    Task_Execute_Cook --> DB_Inv_Update
    Task_Execute_Cook --> Topic_Cook
    Topic_Cook --> End_Cook_Done((Блюдо добавлено в инвентарь))

    %% Конвейер 2: Прямое ручное потребление (Consume)
    Task_Sub_Qty --> DB_Inv_Update
    DB_Inv_Update --> End_Consume_Done((Баланс успешно уменьшен))

    %% Конвейер 3: Теневое голосовое списание потерь (Waste)
    Task_Call_Whisper -.-> Service_Whisper_Food
    Service_Whisper_Food -.-> Task_Call_Whisper
    Task_Call_Whisper --> DB_Dataset_Write
    
    %% NLP анализ триггеров
    Task_Call_Whisper --> Task_NLP_Trigger
    Task_NLP_Trigger -->|Обнаружен интент порчи| Topic_Waste
    Topic_Waste --> DB_Inv_Update
    DB_Inv_Update --> End_Waste_Done((Факт порчи зафиксирован))

    %% Стилизация элементов нотации BPMN
    style Start_Lifecycle fill:#d4edda,stroke:#28a745,stroke-width:2px
    style End_Cook_Done fill:#d4edda,stroke:#28a745,stroke-width:2px
    style End_Consume_Done fill:#d4edda,stroke:#28a745,stroke-width:2px
    style End_Waste_Done fill:#f8d7da,stroke:#dc3545,stroke-width:2px
    style Inbound_Food_Proxy fill:#d1ecf1,stroke:#0c5460,stroke-width:2px
    style Service_Whisper_Food fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    
    style Pool_Client fill:#f8f9fa,stroke:#b8daff,stroke-width:1px
    style Pool_Backend fill:#fffdfd,stroke:#f5c6cb,stroke-width:1px

4.4 Бизнес-логика и регламент подпроцесса движения и утилизации ресурсов

Спецификация фиксирует правила внутреннего изменения (мутации) состояния ресурсов на складе/кухне и регистрацию операционных потерь:

  1. Контур рецептурной трансформации (Cook): При запуске сценария приготовления блюда асинхронное ядро FastAPI выполняет каскадную сервисную задачу Task_Execute_Cook. На основе встроенных технологических карт из таблицы fact_inventory списываются сырьевые компоненты (сокращается их current_quantity), а взамен создается новая реляционная строка с готовым блюдом, получающая признак is_cooked = TRUE. Команда дублируется в топик bupar.fridge.events.cooked для смежных сервисов уведомлений.
  2. Контур прямого потребления (Consume): При фиксации факта съедания продукта в ручном режиме или готового блюда из мобильного интерфейса, бэкенд минует ИИ-контуры (впрочем некотрая проверка сохраняется). Выполняется атомарная задача Task_Sub_Qty, которая производит прямое вычитание указанного объема ТМЦ из мастер-таблицы инвентаря, переводя процесс в конечное штатное событие.
  3. Контур голосовой утилизации отходов (Waste): Чтобы избавить пользователя от ручного поиска испорченной номенклатуры в каталоге, применяется теневой голосовой ввод. Субъект записывает WAV-аудио (например, “Выбросил испорченные томаты две штуки”). На дорожке FastAPI задача Task_Call_Whisper передает файл по gRPC-каналу на ИИ-ноду Service_Whisper_Food.
    • Накопление датасета: Полученный текстовый лог транскрипции незамедлительно персистируется в raw_audio_dataset для последующего Fine-Tuning моделей машинного обучения.
    • Семантический парсинг и регистрация потерь: Текст параллельно передается в NLP-обработчик Task_NLP_Trigger. При обнаружении лингвистических триггеров порчи («выбросил», «пропало», «истек срок»), интент упаковывается в DTO и пушится в топик bupar.analytics.waste. Это событие инициирует автоматическое списание единиц товара из fact_inventory, фиксирует финансовый ущерб в waste_log и служит входящим сигналом для аналитических дашбордов.

5 Аналитический контур интеллектуального анализа процессов (bupaR)

Событийно-ориентированная оркестрация сквозных конвейеров, зафиксированная в предыдущих подпроцессах, решает важнейшую аналитическую задачу: накопление консистентных массивов данных в единой таблице event_log. Этот контур полностью абстрагирован от операционной рутины и предназначен для восстановления реальной топологии процессов (Process Mining).

WarningВажное примечание

В настоящей публичной документации отображены не все шаги и сценарии для приложения в частности и для системы цифровых симуляторв бизнес-процессов в общем.

Ниже представлена схема оркестрации аналитического конвейера:

flowchart TB
    %% ==========================================
    %% POOL 1: ANALYTICAL CORE
    %% ==========================================
    subgraph Pool_Analytics ["📊 ПУЛ - АНАЛИТИЧЕСКИЙ КОНТУР"]
        direction LR
        subgraph Lane_Analyst ["Дорожка операционного аналитика"]
            Start_Analysis((Инициализация аудита)) --> Task_Request_Map["Задача - Запуск построения карты процессов"]
            Task_Request_Map --> Action_Visualize["Задача - Анализ графа и поиск зацикливаний"]
            Action_Visualize --> End_Analysis((Оптимизация регламентов завершена))
        end
    end

    %% ==========================================
    %% POOL 2: BACKEND INFRASTRUCTURE
    %% ==========================================
    subgraph Pool_Backend_An ["⚙️ ПУЛ - БЭКЕНД-ИНФРАСТРУКТУРА ПЛАТФОРМЫ"]
        
        subgraph Lane_Kafka_An ["⚡ Дорожка брокера Apache Kafka"]
            Topic_Stream_An[[Топик - bupar.events.stream]]
        end

        subgraph Lane_FastAPI_An ["⚙️ Дорожка асинхронного ядра FastAPI"]
            Task_Aggregate_Logs["Задача - Пакетное агрегирование транзакционных логов"]
        end

        subgraph Lane_Postgres_An ["🐘 Дорожка базы данных PostgreSQL"]
            DB_Event_Log[("Таблица - bupar_event_log")]
        end

        subgraph Lane_bupaR ["📊 Дорожка аналитики Process Mining bupaR"]
            Task_Consumer_Polling["Задача - Фоновый опрос топиков Kafka консьюмером R"]
            Task_Import_Dataframe["Задача - Импорт реляционного лога событий"]
            Task_Reconstruct_Map["Задача - Восстановление топологии процессов bupaR"]
        end
    end

    %% ВНУТРЕННЯЯ МАРШРУТИЗАЦИЯ И АНАЛИТИЧЕСКИЕ ПОТОКИ
    Task_Request_Map -.->|Запрос выгрузки лога событий| Task_Import_Dataframe
    
    %% Реактивный поток стриминга из Kafka в R
    Topic_Stream_An --> Task_Consumer_Polling
    Task_Consumer_Polling --> Task_Aggregate_Logs
    Task_Aggregate_Logs --> DB_Event_Log

    %% Проактивный поток Process Mining
    DB_Event_Log --> Task_Import_Dataframe
    Task_Import_Dataframe --> Task_Reconstruct_Map
    Task_Reconstruct_Map -.->|Отрисовка интерактивного графа Process Tree| Action_Visualize

    %% Стилизация элементов нотации BPMN
    style Start_Analysis fill:#d4edda,stroke:#28a745,stroke-width:2px
    style End_Analysis fill:#d4edda,stroke:#28a745,stroke-width:2px
    style Topic_Stream_An fill:#fff3cd,stroke:#ffc107,stroke-width:2px
    
    style Pool_Analytics fill:#f8f9fa,stroke:#b8daff,stroke-width:1px
    style Pool_Backend_An fill:#fffdfd,stroke:#f5c6cb,stroke-width:1px

5.1 Бизнес-логика и аналитический регламент контура Process Mining

Спецификация описывает, как собранная история действий людей и симуляторов превращается в инструмент управленческих решений:

  1. Формирование неизменяемого лога событий: В процессе выполнения операционных задач на дорожке FastAPI, все подтвержденные транзакции (будь то закрытие сессии трекинга активности работника агропромышленной сферы или финальное оприходование чека из магазина) параллельно транслируются в топик Kafka bupar.events.stream. Выделенный консьюмер на дорожке R осуществляет пакетное агрегирование логов и фиксирует их в Append-Only таблицу bupar_event_log. Каждая запись содержит обязательные аналитические маркеры: case_id (инстанс процесса/двойник), activity (название шага), timestamp (время фиксации) и resource (исполнитель).
  2. Математическое восстановление топологии процессов: Когда операционный аналитик инициирует аудит эффективности систем, запускается сервисная задача Task_Import_Dataframe. Функция выгружает накопленный массив событий из PostgreSQL по индексу сессии. Специализированный микросервис на базе пакета bupaR обрабатывает этот датафрейм встроенными алгоритмами (вызовы activity_frequency() и trace_coverage()), автоматически восстанавливая реальный граф процессов (Process Tree) со всеми девиациями.
  3. Выявление инфраструктурных заторов и зацикливаний: Полученный граф визуализируется на аналитических панелях. Менеджеры продукта наглядно видят «бутылочные горлышки» — этапы, на которых сессии оперирования необоснованно затягиваются, или контуры, где пользователи и боты циклически застревают на ручной правке черновиков ИИ. Это позволяет оптимизировать регламенты автоматизации до их масштабного развертывания.

6 Заключение

Применение событийно-ориентированного топологического дизайна при проектировании сквозных процессов в нотации BPMN 2.0 позволило сформировать инвариантную шину оркестрации платформы симуляторов. Моделирование операционной деятельности в виде декомпозированных изолированных подпроцессов для различных прикладных доменов (агротехнического мониторинга AgroLaborApp и управления ресурсами FoodLifeCycleApp) доказало свою высокую аналитическую эффективность.

Разделение платформы на независимые пулы клиентского окружения, бэкенд-инфраструктуры и внешних государственных ведомств зафиксировало строгие границы системной ответственности. Использование промежуточных буферных таблиц, шлюзов валидации ИИ-предикатов (SES-247) и петель обратной связи (Feedback Loop) с push-уведомлениями обеспечило надежную защиту контура персистентного (постонянного) хранения от недостоверных данных. Разработанная BPMN-спецификация процессов является законченным аналитическим контрактом. Она обеспечивает полную прозрачность логики функционирования ИТ-архитектуры и гарантирует накопление консистентных данных для последующего интеллектуального анализа и оптимизации бизнес-систем.