Разработчики мобильных и внешних приложений при интеграции с базами данных «1С:Предприятие» часто сталкиваются с неприятной проблемой: при небольшом объеме данных обмен через Web-сервисы (SOAP) проходит успешно, но стоит объему вырасти, как соединение обрывается по таймауту. При этом явное указание таймаута в коде 1С при создании WSПрокси не приносит желаемого результата.
В этой статье мы подробно разберем, почему возникает эта ошибка, какие скрытые ограничения накладывают веб-серверы и мобильные операционные системы, и как правильно спроектировать надежную систему веб-обмена.
Для начала проанализируем фрагмент кода, представленный автором темы:
ВСОпределение = WSСсылки.WebExchOS.ПолучитьWSОпределения();
ВСПакеты = ВСОпределение.ФабрикаXDTO.Пакеты.Получить("Data");
ДанныеXDTO = Новый ХранилищеЗначения(ЗарегистрироватьВыгрузку(ВСОпределение), Новый СжатиеДанных(9));
ВСПрокси = WSСсылки.WebExchOS.СоздатьWSПрокси("Data", "WebExchOS", "WebExchOSSoap",, 43199);
ВСПрокси.Пользователь = "Тест";
ВСПрокси.Пароль = "Тест";
Ответ = ВСПрокси.Синхронизация(ДанныеXDTO);
Результат = ПолучитьДанныеИзXDTO(Ответ.Получить(), ВСОпределение);
В данном сценарии разработчик пытается решить проблему «в лоб», устанавливая гигантский таймаут соединения в параметрах конструктора СоздатьWSПрокси (43199 секунд, что составляет почти 12 часов). Однако на практике соединение все равно закрывается примерно через 15 минут. Почему так происходит?
Причина кроется в том, что параметр таймаута в WSПрокси определяет исключительно время ожидания ответа самой платформой 1С (клиентской частью). Он не способен повлиять на настройки промежуточного ПО, сетевого оборудования, веб-сервера и операционной системы мобильного устройства. Если любое из этих звеньев разорвет соединение раньше, клиент 1С получит системную ошибку таймаута.
Кроме того, передача больших объемов информации через ХранилищеЗначения внутри SOAP-сообщения крайне неэффективна по двум причинам:
---
Когда запрос от мобильного приложения поступает на веб-сервер, тот перенаправляет его расширению 1С (модулю ISAPI или CGI). Если обработка запроса внутри 1С длится слишком долго, веб-сервер считает, что процесс завис, и принудительно обрывает соединение.
Настройки Microsoft IIS (Internet Information Services):
В веб-сервере IIS по умолчанию установлено жесткое ограничение на время выполнения CGI-приложений, которое составляет ровно 15 минут (900 секунд). Это с точностью до секунды совпадает с симптомами автора темы. Для решения этой проблемы выполним следующие шаги:
Настройки Apache:
Если публикация выполнена на веб-сервере Apache, то за удержание соединения отвечают директивы в конфигурационном файле httpd.conf (или apache2.conf):
TimeOut — задает максимальное время ожидания получения запроса и отправки ответа. По умолчанию часто составляет 60 или 300 секунд. Рекомендуется увеличить его значение.KeepAliveTimeout — время ожидания следующего запроса в рамках одного соединения (по умолчанию 5–15 секунд).RequestReadTimeout (модуль mod_reqtimeout) — если мобильный клиент передает данные по медленному или нестабильному каналу связи, Apache может расценить это как медленную атаку (Slowloris) и закрыть сокет.---
При публикации информационной базы 1С на веб-сервере создается файл настроек default.vrd. В нем можно и нужно явно управлять таймаутами пула соединений. Рассмотрим пример структуры файла с измененными параметрами ожидания сессий: Для комплексного аудита параметров публикации и файла vrd можно использовать инструмент для чек-апа веб-публикаций на IIS.
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/MyDatabase"
ib="Connect="Srvr=server;Ref=db;"">
<ws>
<point name="WebExchOS"
alias="WebExchOS.1c"
enable="true"
timeout="1800" />
</ws>
<connections poolTimeout="60" sessionTimeout="1800" />
</point>
Проанализируем ключевые атрибуты, которые мы добавили или изменили:
timeout="1800" внутри тега <point> (веб-сервиса) явно задает время ожидания выполнения операции веб-сервиса в секундах (в данном примере — 30 минут).sessionTimeout="1800" определяет время жизни неактивного сеанса 1С на сервере. Если длительный процесс подготовки данных "засыпает" или ждет ответа от СУБД, сессия не будет сброшена преждевременно.---
Даже если мы идеально настроим веб-сервер и увеличим все лимиты, мы неизбежно столкнемся со спецификой работы мобильных устройств на iOS и Android.
Мобильные операционные системы жестко контролируют расход энергии и сетевую активность. Если приложение выполняет один непрерывный сетевой запрос дольше 5–10 минут, операционная система с высокой долей вероятности принудительно закроет сетевое соединение или вовсе «прибьет» процесс приложения в фоновом режиме. Бороться с этим программным увеличением таймаутов в 1С невозможно — это системные политики безопасности мобильных платформ.
---
Как справедливо отметили участники обсуждения на форуме, единственным профессиональным и стабильным решением является порционный обмен данными.
Рассмотрим по шагам, как реализовать порционную выгрузку с использованием планов обмена:
Посмотрим на пример реализации метода получения данных порциями на стороне сервера 1С:
Функция ПолучитьПорциюДанных(ИмяУзла, НомерПорции, РазмерПорции) Экспорт
УзелОбмена = ПланыОбмена.МобильныеУстройства.НайтиПоКоду(ИмяУзла);
Если УзелОбмена.Пустая() Тогда
ВызватьИсключение "Узел обмена не найден!";
КонецЕсли;
ВыборкаИзменений = ПланыОбмена.ВыбратьИзменения(УзелОбмена, НомерПорции, РазмерПорции);
// Сериализуем выборку в XML/JSON
ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.УстановитьСтроку();
ЗаписьXML.ЗаписатьОбъявлениеXML();
ЗаписьXML.ЗаписатьНачалоЭлемента("PortionData");
Пока ВыборкаИзменений.Следующий() Цикл
ДанныеОбъекта = ВыборкаИзменений.Получить();
ЗаписатьXML(ЗаписьXML, ДанныеОбъекта);
КонецЦикла;
ЗаписьXML.ЗаписатьКонецЭлемента();
Возврат ЗаписьXML.Закрыть();
КонецФункции
Преимущества данного подхода очевидны:
---
Если разделение данных на мелкие порции по каким-то причинам затруднено, следует отказаться от синхронных вызовов веб-сервиса в пользу асинхронной модели обмена.
Проанализируем схему реализации асинхронного обмена:
---
Использование технологии SOAP (Web-сервисы в 1С) для обмена с мобильными клиентами постепенно уходит в прошлое. На замену им пришли гораздо более гибкие и легковесные HTTP-сервисы. Для их быстрого развертывания можно применить общий модуль с готовым набором функций для организации HTTP-сервиса.
Выясним основные причины, почему для мобильного обмена стоит выбрать именно HTTP-сервисы:
POST напрямую, а сервер 1С примет его как двоичные данные без необходимости перекодирования в Base64.Подводя итог, отметим: попытки увеличить лимиты ожидания веб-серверов до бесконечности — это тупиковый путь интеграции, который неизбежно приведет к нестабильности системы в реальных условиях эксплуатации. Проектирование порционного обмена или переход на легкие HTTP-сервисы гарантируют стабильную и быструю работу мобильного приложения даже при неустойчивом беспроводном соединении.