Node Red Dashboard помогает оператору видеть состояние потоков Node-RED, разбирать исключения ИИ-сценария и подтверждать дальнейшее действие через панель. Для новой установки выбирайте поддерживаемый FlowFuse Dashboard: исходный пакет `node-red-dashboard` помечен как устаревший. Панель показывает рабочие события, а сервер проверяет права сотрудника и фиксирует его решение по каждому спорному случаю.
Выбор панели
Исходный пакет `node-red-dashboard` официально выведен из активной поддержки. Для нового интерфейса документация рекомендует `@flowfuse/node-red-dashboard`, а права операторов задаются отдельным механизмом приложения.
Путаница начинается с названия: поисковый запрос ведёт к двум разным пакетам. В карточке исходного Dashboard прямо указано прекращение поддержки и предложена замена. Документация FlowFuse Dashboard показывает актуальный пакет для Node-RED и базовые элементы интерфейса. Для новой панели выбирайте поддерживаемую ветку, а существующий старый экран рассматривайте как отдельную задачу миграции с проверкой виджетов и прав.
Предмет этой статьи — операторский экран поверх уже работающего потока. Сам поток получает входное событие, вызывает ИИ-сценарий и передаёт результат дальше. Панель получает отдельные события о состоянии обработки и показывает, где оператору требуется вмешательство. Так карточка исключения связывает исходную заявку, шаг потока, причину остановки и владельца решения. Рабочую логику вызовов модели проектируют отдельно; здесь речь идёт о том, что видит сотрудник и как он завершает спорную задачу. До создания интерфейса договоритесь о названиях состояний с операторами. Статус «ожидает решения» должен вести к карточке, где видны основание остановки и доступный владельцу шаг.
Для первого экрана достаточно списка активных исключений, статуса последней обработки и карточки выбранного события. На панели оставляйте причину, источник и действие для оператора. Подробный технический журнал доступен разработчику в отдельном представлении. Это различие помогает сохранить ясный экран и ограничить показ чувствительных данных. Общее устройство рабочих сценариев разбирается в материале о сценариях автоматизации; здесь фокус именно на контроле потока Node-RED.
Карточка события
Задайте единую структуру события до настройки виджетов. Каждая запись содержит идентификатор операции, имя потока, текущий этап, итог проверки, источник данных, причину исключения и ссылку на исходную запись. Отдельно храните состояние решения: ожидает оператора, отправлено владельцу данных, подтверждено или возвращено в поток. Панель читает эту запись из серверного хранилища, чтобы обновление страницы сохраняло историю и показывало согласованное состояние всем участникам. Поле причины заполняйте коротким кодом для фильтрации и понятным текстом для человека. Ссылка на исходную запись помогает сверить содержание без копирования всего документа на экран.
| Событие | Что видит оператор | Следующее действие |
|---|---|---|
| Поток завершён | Итог и ссылка на запись | Просмотреть при необходимости |
| Входные данные спорны | Поле, значение и источник | Передать владельцу данных |
| Ответ модели сомнителен | Фрагмент и основание проверки | Сверить с исходным материалом |
| Подтверждение ожидается | Проект действия и ответственный | Одобрить либо отклонить |
Для отображения подойдут текст, таблица и индикатор состояния; FlowFuse Dashboard документирует набор виджетов для таких интерфейсов. Выбор конкретного виджета зависит от смысла данных. Цвет служит дополнительным сигналом, а текст статуса и причина остаются читаемыми сами по себе. В карточке обязательно показывайте, кто подтвердил изменение статуса и на каком основании. Если исходная запись изменилась, оператор видит новую редакцию перед решением.
Числа по полной выгрузке и расчёт показателей поручайте скрипту или парсеру. Языковая модель может объяснить необычный всплеск исключений и предложить гипотезы, но оператор сверяет их с журналом и исходными записями. Такой раздел ответственности сохраняет панель инструментом контроля с выводами, подтверждёнными исходными данными.
Права операторов
Разделите право видеть событие и право менять его состояние. Оператор может просматривать назначенные ему исключения, владелец данных — подтверждать исправление источника, руководитель — видеть сводку. Приложение проверяет роль пользователя на сервере при чтении карточки и при отправке действия. Скрытая кнопка в браузере подходит для удобства интерфейса, но права определяются серверной проверкой. Отдельный промпт с запретом действий тоже остаётся лишь напоминанием. Для наблюдателя подготовьте обезличенную сводку. Сервер ограничивает доступ к отдельной карточке и общей таблице; фильтр интерфейса помогает сотруднику ориентироваться.
Особое внимание уделите рассылке данных на открытые панели. Руководство FlowFuse по нескольким пользователям говорит, что данные для виджета по умолчанию получают все подключённые клиенты. Для персонального отображения нужен отдельный маршрут с достоверной аутентификацией; идентификатор браузера служит техническим признаком клиента, а право доступа определяет сервер. Если карточка содержит сведения о клиенте или внутреннем решении, сервер передаёт её только адресату с нужной ролью.
- Получите событие потока и свяжите его с записью в серверном хранилище.
- Проверьте роль сотрудника и выдайте ему только разрешённые карточки.
- Покажите причину исключения, ссылку на источник и допустимые действия.
- Перед подтверждением повторно прочитайте состояние записи и проверьте право сотрудника.
- Сохраните решение с владельцем, основанием и новым состоянием; сообщите результат потоку.
Если несколько сотрудников открыли одну карточку, сервер принимает решение по актуальной версии записи и сообщает второму участнику об изменении. Это защищает от двойного исполнения. Общую схему границ доступа и подтверждений поясняет разбор безопасности ИИ-агентов.
Разбор исключений
Панель приносит пользу, когда исключение заканчивается понятным решением. Если входной документ неполон, оператор возвращает заявку владельцу данных. Если ответ модели расходится с источником, он сохраняет фрагмент и направляет его специалисту. Если всё подтверждено, сервер разрешает продолжение потока по утверждённому маршруту. Каждый переход должен оставлять запись: что было получено, кто выбрал действие и какой результат пришёл обратно. При отклонении решения покажите оператору, какой владелец получит задачу дальше. Иначе исключение останется видимым на панели без реального маршрута исправления.
Сделайте отдельный вид для зависших и повторно открытых случаев. Причина задержки может быть технической, а может требовать содержательной сверки. Оператору полезна короткая формулировка и ссылка на детали; разработчик изучает журнал потока. При ошибке модели повторный вызов допустим лишь по правилам очереди. Внешняя отправка или изменение карточки выполняется после подтверждения на сервере. Сервер отделяет повтор анализа от исполнения и сохраняет однократность действия.
Предложите пилот на одном потоке с известными исключениями. Подготовьте контрольные события: успешное завершение, спорные входные данные и запрос подтверждения. Проверьте, что оператор видит причину и источник, а сервер сохраняет решение и возвращает событие в нужную ветку.
Для связки панели, очереди и ИИ-сценария полезен разбор автоматизации бизнес-процессов. Состав работ зависит от числа потоков, качества журналов, ролей сотрудников и требований к доступу. Напишите нам, посчитаем под вашу задачу после разбора события и маршрута исключения. Панель проектируйте вокруг решения оператора, которое можно объяснить по сохранённой записи.
Хотите показать исключения вашего потока на панели?
Проверка внедрения
Перед расширением панели проверьте её на контрольном наборе событий. Для каждого заранее запишите ожидаемый статус, видимость по ролям и допустимое действие. Откройте один и тот же случай от имени оператора, владельца данных и наблюдателя. Сверьте экран с серверной записью, затем попытайтесь выполнить действие из роли без права подтверждения. Запрет должен сработать на сервере и остаться в журнале независимо от состояния кнопки в браузере.
Отдельно проверьте доставку обновлений. Два открытых экрана должны показывать согласованное состояние события после решения одного сотрудника; устаревший экран получает сигнал перечитать карточку. При потере соединения панель показывает последний известный статус и предлагает обновить данные перед действием. Так оператор отличает текущую задачу от старого снимка, а сервер принимает решение только по актуальной версии записи. Правила повторного выполнения потока согласуйте с владельцем процесса. В журнале отмечайте версию события, которую видел оператор перед нажатием. Это помогает объяснить конфликт, если коллега успел изменить карточку на другом экране.
Если организация уже использует исходный `node-red-dashboard`, миграцию планируйте по перечню существующих виджетов и пользовательских шаблонов. Документация FlowFuse предупреждает о необходимости проверки совместимости: часть элементов требует ручной переработки. Для нового проекта сразу берите поддерживаемый пакет и отдельно настройте доступ пользователей. Более широкий подход к регулярному контролю разбирается в статье о контроле аналитических процессов. Здесь критерий уже: оператор видит исключение, может проверить источник и завершает задачу в пределах своей роли.