Продление MCData после команды диспетчера: кто принимает окончательное решение
В MCData запрос продления может обрабатываться по-разному в зависимости от того, кто начал завершение коммуникации. Если release с предварительным уведомлением инициировал уполномоченный участник, окончательное решение по продлению возвращается к нему через сервер. Нельзя автоматически ожидать ту же логику, что при самостоятельном решении сервера по собственной политике.
Как проходит предупреждение
Уполномоченный пользователь направляет запрос завершения с указанием предварительного уведомления инициатора обмена. Сервер проверяет его право и передаёт release intent соответствующему клиенту. При необходимости запрашиваются дополнительные сведения, например оставшийся объём данных.
Ответ с такими сведениями передаётся уполномоченной стороне. Это помогает ей оценить ситуацию, но не является автоматическим согласием продолжить передачу. Предупреждение и сбор информации остаются отдельными этапами решения.
Куда идёт просьба продлить
Если инициатор коммуникации просит продление, сервер пересылает запрос authorized user. Этот пользователь принимает или отклоняет его. Решение проходит обратно через сервер к инициатору; коммуникация продолжается при положительном результате либо завершается при отрицательном.
Поэтому клиентская кнопка «продлить» не должна немедленно означать окончательное разрешение. Между просьбой и решением существует отдельная сторона обработки. Если её интерфейс или связь недоступны, поведение определяется документированной процедурой и настройками, а не предположением приложения.
Как проверить разные роли
В стендовом сценарии используют инициатора обмена и отдельно уполномоченного участника, имеющего нужные права. Второй запускает завершение с предварительным уведомлением. Первый отправляет extension request. Проверяют, что просьба дошла до уполномоченного пользователя и что именно его ответ определил дальнейший результат.
Проводят оба варианта решения. При принятии подтверждают продолжение конкретной коммуникации; при отказе — соответствующее завершение. Если включён запрос дополнительной информации, проверяют его содержимое и передачу на нужную сторону.
В журнале сохраняют роли, идентификатор коммуникации и последовательность сообщений. Сам факт прохождения запроса через сервер не означает, что решение принял автоматический серверный алгоритм. Это важное различие для расследования действий оператора.
Результат приёмки должен объяснять, кто попросил остановку, кто запросил продолжение и кто его разрешил. Такая цепочка делает управление прозрачным и позволяет правильно обучить диспетчеров. Она также предотвращает ошибку интеграции, когда человеческое решение незаметно заменяется локальной положительной индикацией сразу после отправки просьбы.
Запросы отправляются на наш e-mail из вашей почтовой программы.
