При разработке мобильных приложений на платформе 1С:Предприятие разработчики часто сталкиваются с проблемой медленной работы веб-сервисов. Одной из главных причин задержек является процедура инициализации объекта WSПрокси. Каждый раз, когда система обращается к внешнему сервису, она тратит значительное время на загрузку и парсинг WSDL-описания. В мобильных сетях это ожидание может достигать нескольких секунд, что делает интерфейс приложения "отзывчивым" только на бумаге.
В этой статье мы разберем, как избежать постоянного пересоздания объекта WSПрокси, выясним, почему стандартные методы хранения данных здесь не работают, и реализуем эффективный механизм кеширования.
Рассмотрим типичную ситуацию: программист пытается объявить экспортную переменную в модуле управляемого приложения или поместить объект в ПараметрыСеанса. Однако при попытке записи или обращения к такой переменной возникает ошибка. Проанализируем причину этого поведения.
Объект WSПрокси относится к категории несериализуемых объектов. Это означает, что его нельзя преобразовать в поток байтов и сохранить в базу данных или передать между сервером и клиентом вне контекста текущего вызова. Он существует только в оперативной памяти в рамках конкретного серверного вызова или сеанса. Попытки использовать такие методы, как:
ХранилищеЗначения;ПараметрыСеанса;ЗначениеВСтрокуВнутр или ЗначениеВФайл.Все эти способы потерпят неудачу, так как платформа 1С жестко контролирует состав типов, поддерживающих сериализацию. WSПрокси — это "живое" соединение, содержащее дескрипторы сокетов и программные интерфейсы, которые привязаны к конкретному адресному пространству памяти.
Наиболее эффективным и правильным способом "сохранения" объекта WSПрокси является использование механизма платформы — Общих модулей с повторным использованием возвращаемых значений. Этот механизм позволяет платформе запоминать результат выполнения функции и возвращать его мгновенно при последующих вызовах с теми же параметрами.
Разберем по шагам, как это реализовать:
ОбменКешСервер.Теперь напишем функцию, которая будет создавать и возвращать наш прокси-объект. Проанализируем пример кода:
Функция ПолучитьПроксиСервиса(Логин, Пароль) Экспорт
// Определяем параметры подключения
URL_WSDL = "https://api.myservice.com/v1?wsdl";
ПространствоИмен = "http://www.myservice.com/api";
ИмяСервиса = "MyExchangeService";
// Создаем объект определения веб-сервиса
// Именно этот этап самый медленный
Определения = Новый WSОпределения(URL_WSDL, Логин, Пароль);
// Создаем прокси
Прокси = Новый WSПрокси(Определения, ПространствоИмен, ИмяСервиса, ИмяСервиса + "Soap");
Прокси.Пользователь = Логин;
Прокси.Пароль = Пароль;
Возврат Прокси;
КонецФункции
Важный нюанс: Чтобы кеширование работало, параметры функции (в нашем примере Логин и Пароль) должны быть примитивных типов: Строка, Число, Дата или Булево. Если вы передадите в функцию Структуру, платформа не сможет корректно сопоставить вызов с кешем, и функция будет выполняться заново каждый раз.
Как показывает практика и замеры пользователей, использование этого метода дает колоссальный прирост скорости:
Если адрес веб-сервиса заранее известен и не меняется динамически, мы рекомендуем использовать объект конфигурации "WS-ссылка". Рассмотрим, чем это лучше динамического создания через Новый WSПрокси.
Когда вы добавляете WS-ссылку в дерево конфигурации, платформа заранее компилирует схему типов и описание сервиса. В этом случае создание прокси происходит почти мгновенно, так как исключается сетевой запрос за WSDL-файлом. Код при этом упрощается:
Функция ПолучитьПроксиЧерезСсылку() Экспорт
// Имя WS-ссылки из дерева конфигурации
Прокси = WSСсылки.МойСервисОбмена.СоздатьWSПрокси(
"http://www.myservice.com/api",
"MyExchangeService",
"MyExchangeServiceSoap"
);
Возврат Прокси;
КонецФункции
Этот метод еще надежнее, так как он минимизирует риски, связанные с недоступностью файла описания сервиса в момент инициализации приложения.
При работе на мобильной платформе нужно учитывать специфику жизненного цикла приложения. Проанализируем несколько критических моментов:
WSПрокси успешно закеширован в памяти, само сетевое соединение может "протухнуть" при переключении телефона с Wi-Fi на LTE. Всегда оборачивайте вызовы методов прокси в блок Попытка...Исключение.HTTPСоединение). Работа с JSON через HTTP обычно требует меньше вычислительных ресурсов мобильного устройства, чем парсинг тяжелых XML-пакетов SOAP.Мы выяснили, что напрямую поместить WSПрокси в глобальную переменную или параметр сеанса невозможно из-за ограничений сериализации. Однако использование общих модулей с повторным использованием возвращаемых значений позволяет эффективно кешировать этот объект. Комбинируя этот подход с использованием статических WS-ссылок, мы можем добиться мгновенного отклика интерфейса мобильного приложения при работе с внешними информационными системами.