Как вызвать мигрировавшего MC-пользователя по его прежнему служебному ID
Старый адрес остаётся полезным
Диспетчер знает основной MC service ID сотрудника, который уже перешёл в партнёрскую систему. Требовать ручного обновления адресной книги перед каждым таким вызовом неудобно. Описанная общая процедура предусматривает достижимость пользователя по прежнему идентификатору через перенаправление основной системой.
Открыть схему в полном размере
Для этого основная система должна знать факт миграции и новый MC service ID, предоставленный партнёром. Поэтому исправность вызова зависит не только от связи вызывающего терминала с сервером, но и от актуального состояния миграции адресата.
Что делает вызывающий клиент
Исходный запрос направляется к основному идентификатору пользователя. Сервер определяет его новое место обслуживания и передаёт вызывающему клиенту информацию перенаправления. Клиент освобождает исходный запрос и инициирует новый вызов с идентификатором, выданным партнёрской системой.
Этот порядок помогает читать журнал. Два связанных запроса не обязательно означают двойное нажатие оператором. Один может относиться к исходному адресу, другой — к продолжению процедуры после перенаправления. Их следует сопоставлять по событиям и идентификаторам, а не считать независимыми попытками.
Практическая проверка адресной книги
Для опыта сохраняют в тестовом клиенте только основной адрес сотрудника. После подтверждённой миграции адресата выполняют личный вызов. Инженер проверяет, что первый запрос использовал сохранённый адрес, сервер сообщил новый идентификатор, а клиент действительно направил последующий запрос по полученному значению.
Затем сопоставляют результат с вызовом напрямую по партнёрскому ID. Если прямой путь работает, а перенаправление нет, это сужает поиск до сведений о миграции и обработки перенаправления. Если не работает ни один путь, преждевременно объявлять причиной именно старую адресную книгу.
Отрицательные сценарии согласуют отдельно: устаревшее состояние миграции, отсутствие разрешения на личную связь, недоступность адресата. Каждый из них должен оставлять различимые диагностические следы. Не все отказы означают ошибку сопоставления адресов.
Безопасность проверяется отдельно
При требовании сквозного шифрования процедура предполагает наличие необходимых сведений безопасности у мигрировавшего пользователя. Успешное получение нового адреса не подтверждает готовность защищённого медиа. Для этого нужен самостоятельный сервисный опыт с согласованной конфигурацией безопасности.
Готовность фиксируют по всей цепочке: старый адрес, перенаправление, новый запрос и результат личной связи. В карточке сопровождения указывают, где виден актуальный статус миграции. Такой подход сохраняет удобство знакомой адресной книги и одновременно позволяет объяснить, почему её наличие не устраняет зависимость от основной системы и корректного состояния пользователя после перехода на площадку партнёра.
