Object identifier MCData и conversation identifier: что нужно для получения конкретной архивной записи
В приложении MCData известен идентификатор разговора, но запрос отдельной архивной записи не возвращает ожидаемый объект. Возможная причина — смешение conversation identifier и object identifier. Первый связывает коммуникацию в историю, второй позволяет обратиться к конкретному сохранённому объекту. Эти значения решают разные задачи и не являются взаимозаменяемыми.
Что идентифицирует объект
При сохранении сообщение или файл с метаданными становится объектом message store и получает собственный идентификатор. В описанном запросе получения передаются MCData ID пользователя и object identifier. Это обращение в определённую пользовательскую область к конкретной записи.
Conversation identifier остаётся полезным контекстом, который помогает объединять связанные транзакции. Однако в одном разговоре может быть несколько сообщений и файлов. Поэтому он сам по себе не выбирает единственный архивный объект, если требуется получить именно его.
Как возникает ошибка интеграции
Система сохраняет в локальной базе только идентификатор разговора и видимое название документа. Позднее для операции получения приходится угадывать запись среди нескольких объектов. Название файла не обеспечивает уникальность, а смена порядка отображения делает такую логику ещё менее надёжной.
Полезно сохранять отдельную связь между объектом, разговором и пользовательской областью. Это рекомендация по модели данных. Конкретное представление идентификаторов берут из поддерживаемого интерфейса, не конструируя его из пользовательского текста.
Как проверить адресность
В стендовом разговоре создают несколько различимых сообщений и файлов. После сохранения получают подтверждённые object identifier и по очереди запрашивают каждый объект. Проверяют, что возвращено именно ожидаемое содержимое, а не первая запись с подходящим именем.
Отдельно сравнивают объекты одинакового названия в разных разговорах и в разных тестовых областях. Проверка должна учитывать действующие полномочия, не пытаясь получить рабочие данные посторонних пользователей. Цель — подтвердить правильную адресность разрешённого запроса.
В отчёте сохраняют все связанные значения и их назначение. Если приложение не получило идентификатор сохранённого объекта, нельзя автоматически считать архивный доступ обеспеченным только по факту успешного FD или SDS обмена.
Такой подход делает историю пригодной для точного восстановления и сопровождения. Разговор остаётся единицей контекста, а объект — единицей прямого обращения в message store. Сохранение этой границы позволяет корректно получать нужную запись и избегать ошибок, которые внешне выглядят потерей архивных данных, хотя на самом деле запрос использует идентификатор другого уровня.
Запросы отправляются на наш e-mail из вашей почтовой программы.
