При организации обмена данными между информационными базами, работающими на разных версиях платформы 1С (например, 8.3.10 и 8.3.14), специалисты часто сталкиваются с критической проблемой. Веб-сервисы или HTTP-сервисы начинают возвращать ошибку 500 (Internal Server Error), причем это происходит не постоянно, а «плавающим» образом: то одна база перестает отвечать, то другая. Особенно ярко это проявляется в момент создания объекта WSОпределения или при попытке получить WSDL-схему через браузер.
В этой статье мы подробно разберем, почему возникает этот конфликт, как веб-сервер обрабатывает запросы к разным версиям платформы и какими способами можно обеспечить их мирное сосуществование.
Рассмотрим ситуацию глубже. Когда вы публикуете информационную базу на веб-сервере (например, Apache), платформа прописывает в конфигурационных файлах путь к своей библиотеке расширения. Для Apache это модуль _1cws_module, который загружается из файла wsap22.dll или wsap24.dll. Проблема заключается в том, что веб-сервер не рассчитан на одновременную загрузку двух разных модулей с одинаковым внутренним идентификатором, но из разных путей.
Проанализируем типичный сценарий: вы опубликовали базу на версии 8.3.10, и в файле httpd.conf появилась строка, указывающая на bin-директорию этой версии. Затем вы публикуете базу на 8.3.14. Помощник публикации 1С пытается обновить настройки, и в итоге веб-сервер «запутывается». При попытке обращения к базе 8.3.10 он может попытаться использовать библиотеку от 8.3.14, и наоборот. Поскольку внутренняя структура объектов и механизмы сериализации данных в версиях 8.3.10 и 8.3.14 существенно различаются, процесс падает с ошибкой 500.
Если вы используете Apache, то простое исправление строки LoadModule в конфигурационном файле поможет лишь временно — до первой попытки работы со второй базой. Разберем наиболее надежный метод решения этой проблемы.
Запуск нескольких экземпляров Apache как отдельных служб
Самым стабильным решением будет установка двух независимых экземпляров Apache. Мы настроим их следующим образом:
8.3.10. В его файле httpd.conf будет жестко прописан путь к библиотеке этой версии:
LoadModule _1cws_module "C:/Program Files/1cv8/8.3.10.XXXX/bin/wsap24.dll"
8.3.14. Его конфигурация будет ссылаться на свою DLL:
LoadModule _1cws_module "C:/Program Files/1cv8/8.3.14.XXXX/bin/wsap24.dll"
В этом случае процессы будут полностью изолированы друг от друга на уровне операционной системы, и конфликт библиотек станет невозможен. При обращении из одной базы в другую в строке соединения необходимо будет просто указывать соответствующий порт.
Если ваша инфраструктура базируется на Microsoft IIS, ситуация обстоит несколько проще, но требует внимательной ручной настройки. В IIS за изоляцию отвечают «Пулы приложений» (Application Pools). Посмотрим, как настроить их правильно.
Шаг 1. Создание раздельных пулов приложений
Для каждой версии платформы необходимо создать свой пул приложений. Назовем их, к примеру, 1C_AppPool_8310 и 1C_AppPool_8314. Убедитесь, что в настройках пулов указана правильная разрядность (Enable 32-Bit Applications), соответствующая установленной платформе 1С.
Шаг 2. Настройка обработчиков (Handler Mappings)
Это критический момент. Ошибка 500 часто возникает из-за того, что обработчик расширений .1cws или .1csr настроен глобально для всего сервера. Нам же нужно зайти в настройки каждого конкретного виртуального каталога (вашей опубликованной базы) и проверить путь к isapi_1c8.dll.
Проанализируем файл web.config в каталоге публикации. Он должен содержать корректный путь:
<add name="1C_Web_Service_Handler"
path="*.1cws"
verb="*"
modules="IsapiModule"
scriptProcessor="C:\Program Files\1cv8\8.3.14.XXXX\bin\isapi_1c8.dll"
resourceType="Unspecified" />
Важно: Никогда не используйте один и тот же пул приложений для баз на разных версиях платформы 1С. Это приведет к тому, что первый загруженный в память рабочий процесс «захватит» библиотеку одной версии, и все остальные базы в этом пуле будут пытаться работать через нее.
Если вы не хотите заставлять пользователей или внешние системы вводить номера портов в URL, рассмотрим вариант с использованием Nginx. Он будет выступать «входными воротами» (Front-end), принимая все запросы на стандартный 80-й порт.
Алгоритм работы будет следующим:
/base_8310/ или /base_8314/).localhost:8080 (где слушает Apache с 8.3.10).localhost:8081 (где слушает Apache с 8.3.14).Это самый профессиональный способ, который позволяет полностью скрыть техническую сложность «зоопарка» платформ от конечных потребителей веб-сервисов.
Выясним еще одну важную деталь. Версия 8.3.14 принесла много изменений в механизмы безопасности. Если ваша база на 8.3.10 обращается к 8.3.14, и вы получаете 500 ошибку даже после разделения веб-серверов, проверьте настройки SSL/TLS. Платформа 8.3.14 может по умолчанию требовать более современные протоколы шифрования, которые 8.3.10 не поддерживает «из коробки» без дополнительных настроек ОС.
Также обратите внимание на файл default.vrd. В нем содержится параметр connectString. Убедитесь, что при переопубликации баз вручную вы не скопировали содержимое vrd-файла от одной версии в другую без правок, так как структура параметров может незначительно меняться.
Подводя итог, можно сказать, что ошибка 500 в данной ситуации — это почти всегда конфликт isapi_1c8.dll (для IIS) или wsap24.dll (для Apache). Для успешного решения задачи придерживайтесь следующих правил:
httpd.conf, web.config), так как автоматическая публикация из конфигуратора 1С часто затирает настройки «чужой» версии.Соблюдение этих архитектурных принципов позволит вашим системам на платформе 1С:Предприятие работать стабильно, даже если ими управляют разные версии программного обеспечения.