История MCData после off-network работы: локальные записи нужно загрузить в message store
Во время off-network работы MCData коммуникации сохранились на устройстве, но после возвращения в сеть их нет в серверной истории. Само восстановление подключения не доказывает завершённую загрузку локальных объектов. Стандарт предусматривает отдельную операцию upload objects из локального message store в пользовательскую серверную область.
Открыть схему в полном размере
Где находится исходная история
В описанном сценарии пользователь с учётной записью message store сохраняет off-network коммуникацию как объекты в определённой папке устройства. Когда он снова подключён к сети с MCData услугой, эти объекты могут быть загружены в его серверный аккаунт.
Поэтому наличие записей в локальном интерфейсе и наличие в сетевом хранилище являются разными фактами. Другой клиент пользователя может не увидеть историю, пока предусмотренная загрузка не завершена и последующее получение не выполнено.
Что делает операция
Запрос содержит загружаемые объекты и идентификатор целевой папки. Message store сохраняет их в выбранном месте; если целевая папка отсутствует, в описанной процедуре она создаётся. Затем возвращается результат upload objects.
Нельзя подменять эту операцию обычной файловой загрузкой на content server: у неё другое назначение и другой объект обслуживания. Также не следует считать выбранное локальное имя папки доказательством правильного серверного назначения без проверки идентификатора.
Сценарий приёмки
На тестовом устройстве создают различимую off-network историю. После восстановления поддерживаемого сетевого обслуживания подтверждают учётную запись, авторизацию и запуск upload objects. Сохраняют состав запроса, целевую папку и результат хранилища.
Затем получают созданные записи предусмотренным способом с сервера и сравнивают содержимое и контекст. Если проект включает просмотр на другом устройстве, его проверяют отдельным последующим действием. Один успешный ответ загрузки не показывает автоматически, что второй клиент уже синхронизирован.
Отдельно испытывают документированное поведение при прерывании операции. Правила повторов, предотвращения дубликатов и сохранения локальной копии требуют реализации; их нельзя вывести из общей схемы. Для контроля используют специально подготовленные объекты, не удаляя рабочую историю ради теста.
В отчёте разделяют локальное сохранение, серверную загрузку и дальнейшую синхронизацию. Это позволяет понять, где именно отсутствует ожидаемая запись.
Такой подход делает переход из off-network режима в обычную работу проверяемым. История не переносится в сознании пользователя только потому, что появился сетевой значок: нужно подтвердить предназначенную операцию и реальный объект в серверной области. После этого можно обоснованно принимать доступность материалов на других клиентах.
