Платформа 4.0 + BOX 3.2
События и правила обмена данными
Как отделить результат сценария от конкретной модели и безопасно передать его потребителю.
На этой странице
Формат результата
Потребитель должен получать бизнес-событие, а не внутренний tensor или ответ конкретного детектора. Минимальный состав обычно включает тип, время, источник, атрибуты, медиассылку или доказательство, версию сценария и диагностический контекст.
Транспорт выбирается проектом
API, очередь сообщений, Kafka, файловая выгрузка или специализированный адаптер выбираются по требованиям смежной системы. Публичная документация описывает принципы; адреса, авторизация и схемы конкретной поставки остаются в закрытом комплекте.
Ошибки и повторная доставка
Заранее определите идемпотентность, ключ события, таймауты, повторные попытки, недоступность потребителя и правила изменения статуса после верификации.
Формат результата сценария и внешний API
В Платформе 4.0 структура events в результатах запуска определяется блоком формирования событий. Для BOX 3.x сохранённые события описываются StoredViolationEvent в OpenAPI. Эти форматы данных нельзя подменять друг другом.
| Точка | Описание формата данных | Что проверять |
|---|---|---|
| Выход модели | Протокол модели | Классы и структуры детекций |
| Выход блока сценария | Описание блока | Тип события и обязательные атрибуты |
| Сохранённое событие BOX 3 | OpenAPI: StoredViolationEvent | Поля, типы и статусы целевого контура |
| Внешняя система | Согласованные правила обмена данными | Ключ события, время, медиа и повторы |
Повторное получение события
При опросе API одно событие может попасть в несколько ответов. Храните устойчивый идентификатор и отдельно учитывайте изменение статуса верификации. Номер страницы и позиция в массиве не являются идентификатором события.
Согласуйте обработку отсутствующих медиаданных, удаления событий и изменения схемы ответа. Воспроизведите эти случаи на тестовом контуре перед подключением потребителя.
Интеграционный слой и внешние сигналы · открыть
