Ситуация, когда информационные базы 1С работают на разных версиях платформ и разных серверах SQL, является стандартной для крупных распределенных систем. Однако обновление платформы даже на одном из узлов может привести к внезапной остановке обмена данными, который до этого работал стабильно. Особенно часто это проявляется в схемах, где используется файловый обмен через текстовые документы, XML или JSON с помощью регламентных заданий.
В данной статье мы разберем, почему после перехода с версии 8.3.9 на 8.3.13 (или аналогичные более свежие релизы) обмен может перестать работать в одну сторону, и как правильно диагностировать эту проблему, если Журнал регистрации не показывает явных ошибок.
Рассмотрим основной механизм работы регламентных заданий. Любой код, исполняемый в рамках регламентного задания, выполняется на стороне сервера под учетной записью, от имени которой запущена служба Агент сервера 1С:Предприятия. Разберем по шагам, что происходит при обновлении платформы:
8.3.9 на 8.3.13) инсталлятор часто создает новую службу в операционной системе.DOMAIN\1c_service), то новая служба по умолчанию может установиться с запуском от имени локального системного пользователя (LocalService или USR1CV8).USR1CV8, создаваемый при установке, не имеет прав доступа к сетевым ресурсам (UNC-путям), таким как \\Server-Exchange\Import\.В результате мы получаем ситуацию: код обмена успешно инициализируется, но при попытке записать файл в сетевой каталог операционная система блокирует действие. При этом, если код обмена обернут в конструкцию Попытка ... Исключение без должного логирования ошибки, в Журнале регистрации мы увидим статус "Выполнено", хотя физически файл не был создан.
Проанализируем ситуацию с правами более глубоко. Начиная с версии платформы 8.3.10, механизмы безопасности 1С стали значительно строже. Выясним, на что стоит обратить внимание в первую очередь:
1. Доступ к каталогам временных файлов. Процесс rphost.exe активно использует временные папки для формирования текстовых файлов перед их отправкой в целевой каталог. Если у пользователя, под которым запущен сервер, нет полных прав на запись в системную папку Temp, обмен может прерваться на этапе формирования данных.
2. Профили безопасности. Проверим, не включены ли в кластере новой платформы Профили безопасности. Если профиль настроен, он может запрещать доступ к любым файловым ресурсам вне разрешенного списка, даже если у пользователя ОС права есть. Это механизм самой платформы 1С, который блокирует "опасные" действия серверного кода.
3. Сетевые порты и брандмауэр. При обновлении платформы меняются исполняемые файлы (путь к rphost.exe теперь ведет в папку с новой версией, например, C:\Program Files\1cv8\8.3.13.XXXX\bin\). Антивирус или брандмауэр может не знать о новом приложении и блокировать его сетевую активность, даже если старая версия 8.3.9 была в исключениях.
Посмотрим на ситуацию со стороны форматов данных. Даже если обмен называется "текстовым", внутри него обычно скрыта структура XML или JSON, обрабатываемая через механизмы XDTO или СериализаторXDTO. Между версиями 8.3.9 и 8.3.13 произошли существенные изменения в том, как платформа записывает типы данных.
Если база на новой платформе выгружает файл, используя новые возможности сериализации, база на старой платформе может просто "не понять" структуру файла. Это часто приводит к тому, что чтение файла завершается без ошибки, но и без загрузки объектов. Разберем пример кода, который может вести себя по-разному:
Чтение = Новый ЧтениеТекста;
Чтение.Открыть(ПутьКФайлу, КодировкаТекста.UTF8);
СтрокаДанных = Чтение.Прочитать();
// Если на 8.3.13 файл записался с меткой BOM,
// а 8.3.9 ожидает чистый UTF-8, первая строка может
// содержать невидимый спецсимвол, ломающий дальнейшую логику.
Хотя в рассматриваемом случае обмен файловый, важно понимать ограничения взаимодействия разных платформ. Если в процессе обмена используется COM-соединение для проверки каких-то данных в соседней базе, мы столкнемся с конфликтом библиотек. Разберем, почему это происходит:
Для работы COM-соединения требуется библиотека comcntr.dll. Если на сервере установлены обе платформы, и процесс одной версии пытается вызвать библиотеку другой версии, возникает конфликт, так как в один процесс rphost.exe нельзя загрузить две разные версии одной и той же системной библиотеки 1С. Это часто проявляется именно при обновлении одного из серверов в цепочке обмена.
Рассмотрим алгоритм действий, который поможет восстановить работу обмена:
services.msc и убедитесь, что служба "Агент сервера 1С:Предприятия 8.3" (версии 8.3.13) запущена под той же учетной записью, что и старая служба версии 8.3.9. Если там указан LocalSystem, смените на нужного доменного пользователя.srvinfo (кроме файлов конфигурации кластера).\\ServerName\Exchange\) вместо логических дисков (например, Z:\Exchange\), так как логические диски не видны серверной службе.Подведем итог: В большинстве случаев проблема "внезапной" остановки обмена при обновлении платформы кроется не в коде 1С, а в системных настройках среды исполнения. Тщательная проверка прав учетной записи USR1CV8 и настроек безопасности новой платформы позволяет решить проблему без изменения логики самих правил обмена.