Кто сейчас исполняет роль MC-связи: два запроса, которые нельзя подменять друг другом
Диспетчер ищет текущего исполнителя роли, а интеграция отправляет запрос по прошлому сотруднику. Ответ «активных псевдонимов нет» выглядит как отсутствие дежурного, хотя роль уже передана другому человеку. Ошибка здесь может находиться в направлении поиска, а не в состоянии самой роли.
ETSI TS 123 280 V19.10.1 описывает два разных запроса. User query получает активные псевдонимы заданных пользователей. Usage query получает пользователей, которые активировали заданные псевдонимы. В первом случае исходной точкой является MC service ID, во втором — functional alias.
Проверка после передачи смены
Возьмём условных сотрудников A и B и роль «дежурный участка». До передачи роль активна у A, после передачи — у B. Запрос по A после смены может корректно вернуть отсутствие активного назначения. Это не отвечает на вопрос, занят ли сам псевдоним.
Для поиска исполнителя интеграция должна использовать предусмотренный запрос по роли. Если политика допускает совместное использование, результат может содержать несколько пользователей. Нельзя молча выбрать первого и представить его единственным дежурным, не проверив смысл возвращённого списка и требования рабочего процесса.
Обратная задача тоже полезна: руководитель проверяет, какие роли сейчас активны у конкретного сотрудника. Здесь исходный пользовательский идентификатор подходит, а запрос одного предполагаемого псевдонима даст лишь частичную картину. Выбор направления определяется вопросом оператора.
Пустой результат и отказ
В информационных таблицах предусмотрен пустой результат, когда у пользователя нет активного псевдонима либо псевдоним не активирован никем. Но получение данных связано с проверкой полномочий. Поэтому интерфейс должен различать подтверждённое отсутствие назначения и невозможность выполнить запрос по доступу.
На стенде проверяют оба направления до и после известной передачи роли. Затем выполняют согласованный запрос от пользователя без необходимых прав. Результаты сохраняют отдельно, чтобы пустой список не стал универсальной маской любого отказа.
Практическое требование к диспетчерской панели формулируется просто: поиск по сотруднику и поиск по роли должны иметь различимый смысл. В отчёте указывают исходный объект запроса, контекст службы и полученный состав. Это помогает восстановить картину после смены, не приписывая старому пользователю новые обязанности и не объявляя незанятой роль, исполнителя которой искали не тем способом.
Такое разделение также полезно при интеграции с внешним рабочим расписанием. Расписание задаёт ожидаемого исполнителя, а запрос MC-службы показывает наблюдаемое активное назначение. Их сравнение может быть отдельной проверкой; одно не следует автоматически выдавать за другое.