Затеял я переход своей РИБ (самописная конфигурация на базе одной из старых версий Управления Торговлей 10.3) на новую платформу 1С с 8.3.12.1685 на 8.3.15.1565. Новая платформа была установлена во всех узлах, базы нормально и без ошибок загрузились и все казалось бы закончилось удачно. Но при попытке произвести обмен с одной из периферийных баз выскочила ошибка "Конфигурация узла распределенной ИБ не соответствует ожидаемой". Ошибка встречалась мне и ранее и решалась выгрузкой конфигурации из главного узла с последующей загрузкой в периферийную. Эта же процедура была проделана и в этот раз, однако к восстановлению обмена не привела. Был произведен для проверки обмен и с другими узлами. Результат — обмен не идет ни с одним из периферийных узлов РИБ. После отката на старую версию платформы я приступил к решению возникшей проблемы.
Поиски решения на просторах интернета в целом ничего не дали. Основной способ был известен мне и уже опробован. Подмена содержимого тега v8de:Digest2, как и ожидалось работает только один раз для измененного файла с данными. Внесение незначительных изменений в конфигурацию главного узла и последующий перенос изменений в периферийный узел тоже ни к чему не привели. Некоторым помогла выгрузка конфигурации из периферийной базы с последующей загрузкой в главную, но тут возник вопрос, а из какой периферийной базы выгружать? Ключики то везде разные…
Выгрузка из главной базы платформа 8.3.12.1685:
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 Extensions="0000000000000000000000000000000000000000" v2="0acf333b4a9b71e12b7a700523f78324">d41d8cd98f00b204e9800998ecf8427e</v8de:Digest2>
</v8de:Config>
Выгрузка из периферийной базы 1 платформа 8.3.12.1685:
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 Extensions="0000000000000000000000000000000000000000" v2="f031ca95ff7c7c605797876924a6756e">d41d8cd98f00b204e9800998ecf8427e</v8de:Digest2>
</v8de:Config>
Выгрузка из периферийной базы 2 платформа 8.3.12.1685:
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 Extensions="0000000000000000000000000000000000000000" v2="b4de455a6868c21ac38b1df13cb1e01f">d41d8cd98f00b204e9800998ecf8427e</v8de:Digest2>
</v8de:Config>
Остальные периферийные базы не приведены, однако там ситуация такая же: Атрибут V2 в ключе v8de:Digest2 отличается во всех базах, само же значение ключа на платформе 8.3.12.1685 одинаково. Обмен на платформе 8.3.12.1685 идет нормально. Вывод: для нормального обмена на 8.3.12.1685 требуется равенство значения ключа v8de:Digest2, равенство значения атрибута V2 необязательно. При попытке сделать обмен на под управлением платформы 8.3.15.1565 ситуация следующая:
Выгрузка из главной базы платформа 8.3.15.1565:
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 Extensions="0000000000000000000000000000000000000000" v2="a95fe017232e121ab1ba6ea487df1159">9e53a3505803f5c8d6308556676851bb</v8de:Digest2>
</v8de:Config>
Выгрузка из периферийной базы 1 платформа 8.3.15.1565:
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 Extensions="0000000000000000000000000000000000000000" v2="f7a858d651be406f8db57105a0fe8226">f80d570770ddb1c186e70e4bd5266c41</v8de:Digest2>
</v8de:Config>
Выгрузка из периферийной базы 2 платформа 8.3.15.1565:
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 Extensions="0000000000000000000000000000000000000000" v2="07b705fe58126f57d4a5f3cec00a9f2d">9e53a3505803f5c8d6308556676851bb</v8de:Digest2>
</v8de:Config>
Из проведенного эксперимента следует сразу несколько выводов: Первое, ключи для сравнения в базе приемнике формируются динамически либо при открытии базы под той или иной платформой, либо перед процедурой загрузки выгрузки. Второе, для нормального обмена данными под управлением платформы 8.3.15.1565 требуется равенство не только значения ключа v8de:Digest2, но и атрибута V2, так как обмен не шел как с периферийной базой 1, так и с периферийной базой 2. Заметим, что именно в периферийной базе 1 была произведена загрузка конфигурации, выгруженной из главной базы, однако там отличаются оба ключа.
Так как ключи формируются динамически, условием восстановления обмена может быть только приведение в полное соответствие конфигураций главной и периферийных баз данных. Почему же загрузка конфигурации из главного узла и загрузка в периферийный узел не помогает? Базы у меня работают в режиме совместимости 8.2. В этом режиме многие возможности современной платформы 1С отключаются и доступа к ним нет. Было сделано предположение, что в файл конфигурации cf не попадают эти отключенные области, однако они участвуют в расчете ключей при обмене. Тут я вспомнил про возможность выгрузить конфигурацию в файлы и потом загрузить ее из этого набора файлов обратно. Понятно, что для обычных форм это бинарные файлы, но сравнить то мы их можем, и подменить отличающиеся. После выгрузки в файлы конфигураций главной и периферийной базы 1 и попытке сравнения файлов результат обескуражил: отличались по содержимому не только многие бинарные файлы, но и содержимое такого вполне читаемого файла как ConfigDumpInfo.xml.
Периферийная база 1 была "отвязана" от главного узла и в неё были загружены файлы конфигурации из главной базы (конфигурация — Загрузить конфигурацию из файлов). Проведенное затем сравнение конфигурации периферийной базы и файла конфигурации, выгруженного из главной базы показало различие в некоторых элементах метаданных (некоторые картинки, макеты, помощь и т.п.).
Причины непонятны, скорее всего зарытые ошибки в конфигурации главной базы некорректно были выгружены в файлы. Для устранения этого в периферийную базу была опять загружена конфигурация из главного узла. После проведенных манипуляций обмен не восстановился:
Выгрузка из главной базы не изменилась и приведена выше.
Выгрузка из периферийной базы 1 платформа 8.3.15.1565:
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 Extensions="0000000000000000000000000000000000000000" v2="b4de455a6868c21ac38b1df13cb1e01f">2ddd865649c831a87a4853bdad69bb3f</v8de:Digest2>
</v8de:Config>
Вспомнив о том, что многим помогала операция загрузки файла конфигурации из периферийной базы в главную, проделал абсолютно идиотскую операцию: загрузил в главную базу файл конфигурации, который был из нее же выгружен (ведь этот файл был только что загружен в периферийную базу). При анализе файла выгрузки из главной базы я с удивлением увидел появившийся блок с метаданными, т.е. произошло реальное изменение метаданных конфигурации (могу только предположить, что это наслоения багов старых динамических обновлений).
Этот файл выгрузки был уже нормально принят моей периферийной базой, причем обновления конфигурации периферийной базы не потребовалось, блок метаданных был молча принят периферийной базой.
После этого двухсторонний обмен восстановился:
Выгрузка из главной базы платформа 8.3.15.1565:
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 Extensions="0000000000000000000000000000000000000000" v2="b4de455a6868c21ac38b1df13cb1e01f">2ddd865649c831a87a4853bdad69bb3f</v8de:Digest2>
</v8de:Config>
Выгрузка из периферийной базы 1 платформа 8.3.15.1565:
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 Extensions="0000000000000000000000000000000000000000" v2="b4de455a6868c21ac38b1df13cb1e01f">2ddd865649c831a87a4853bdad69bb3f</v8de:Digest2>
</v8de:Config>
При восстановлении обмена с другими периферийными базами ( с теми у которых один ключ совпадал) я сделал попытку избавиться от этапа загрузки конфигурации из файлов, решив, что это лишнее. К сожалению ничего не получилось. Очевидно, первоначальная идея, что в этом наборе файлов содержится информация, не попадающая в файл конфигурации cf оказалась верной. На просторах интернета предлагается для восстановления обмена в РИБ вносить изменения в конфигурацию, приводящие к реконфигурации базы данных. Реконфигурация, конечно, очень полезна, а иногда даже необходима при смене платформы, но в данном случае она оказалась абсолютно бесполезной, на генерацию ключей и восстановление обмена она никакого влияния не оказала, это было проверено.
Итак окончательная последовательность действий при возникновении ошибки обмена данными в РИБ при переходе на другую, более свежую платформу 1С следующая:
- Снимаем резервные копии всех баз данных
- Устанавливаем новую платформу и далее все манипуляции производим, загружая базы данных под новой платформой
- Из главной базы РИБ выгружаем файл конфигурации cf. Это у нас будет эталонный файл конфигурации.
- Из главной базы выгружаем файлы конфигурации. Так как в системе есть ограничения на длину наименования файлов, папку для выгрузки выбираем как можно с коротким именем (у меня было C:1). Эта папочка тоже будет эталонной.
- Отвязываем периферийную базу от главной базы. Обработку не привожу, она тривиальна и содержит 5 строк кода. Кто не сможет написать на коленке, в интернете полно предложений по этому вопросу.
- В режиме конфигуратора в периферийную базу загружаются файлы конфигурации из главного узла (конфигурация — загрузить конфигурацию из файлов). Конфигурацию НЕ сохраняем, конфигурацию базы данных НЕ обновляем.
- Загружаем конфигурацию (cf файл) в периферийную базу (конфигурация — загрузить конфигурацию из файла).
- Сохраняем основную конфигурацию и обновляем конфигурацию базы данных периферийной базы данных.
- Привязываем периферийную базу к главной базе данных, предварительно закрыв конфигуратор.
- Повторяем пункты 5 — 9 для всех периферийных баз.
- Загружаем файл конфигурации главного узла в главный узел, ДА ВОТ ТАК ВОТ.
- Сохраняем основную конфигурацию и обновляем конфигурацию базы данных главной базы данных.
Далее, скрестив на всякий случай пальцы (с продуктами от 1С возможно все), пробуем сделать обмен в РИБ.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Плюсанул из-за знакомой ситуации. Один месяц ну прям хронически было на базе.
Может это какая-то ошибка баг платформы? Не обращались в техническую поддержку 1С?
Плюсанул за компанию с Кучмой.
(2) С самописной конфигурацией? на базе старой УТ 10.3? Вы определенно шутите… :))
Мы так же «влетели» с переводом дописанной УПП с 8.3.12.1685 на 8.3.13.1690. Помогла загрузка cf из периферийной в головную.
Спасибо за глубокое исследование Очень не типового случая и за краткие 12 пунктов «Что делать»!
У меня сейчас как раз такая же ситуация.
Решил сервак обновить. Была версия платформы 8.3.9.2033, думаю, дай ка я обновлю ее до 8.3.15.1700.
Ну вот, напоролся на проблему, моя новая платформа не очень-то захотела дружить с PostgreSQL 9.5
Протрахался пол ночи, пока вспомнил, как под CentOS обновить 1С.
И утром меня ждал сюрприз.
После того как, зашли более 7-10 чел на сервак, база тупа стала подвисать на каждом тычке мыши в программе.
В итоге еще пол дня, что бы откатиться назад на платформу 8.3.9.2033
Но при этом, в одном магазине я успел обновить на компе клиента так же на 8.3.15.1700.
И вот из 11 РИБ узлов, этот как раз обновленный клиент не принимает файл выгрузки обмена.
Все ему не так.
А вот обратно обмен идет от клиента в ЦБ нормально.
База ЦБ затягивает файл как родной.
Спасибо за статью, буду пробовать ваши танцы с бубном.
Ха, прочитав, вашу статью, подумал, что бы ло бы неплохо, на клиентском компе в списке баз, для базы указать загрузку ее под платформой 8.3.9.2033.
И о боги, обмен завелся.
Я второй день голову ломаю, дайжесты в файле подмениваю, пытаюсь что-то сделать. Конфигурацию перезагружал в РИБ узел из центра.
Ничего не помогало.
Это жесть. Издевательство со стороны Москвы.
Не навижу, получать опыт через такие сложности. Опыт появился, а толку от него в жизни НОЛЬ.
В общем завелось.
Что будет, когда я все же обновлю везде платформу, пока не знаю.
Но однозначно, моя база Управление торговлей 10.3 к этому не готова.
Низкий поклон!!!
В структуре БД 1с есть служебная таблица «Config» — где хранятся изменения конфигурации (когда нажимаем на кнопку применить изменения), по-видимому она принимает участие в расчете ключа, это объясняет пункт «11. Загружаем файл конфигурации главного узла в главный узел, ДА ВОТ ТАК ВОТ.» Чтобы последние записи были идентичны в узлах.