Подключение к Единому хранилищу конфигурации информационных баз с разной историей доработок

«Никогда такого не было, и вот опять.» © ЧВС

Однажды, подключая базу данных к хранилищу конфигурации, мы столкнулись со странным обстоятельством. Конфигуратор удалил и вновь создал измерение Файл регистра сведений Двоичные данные файлов. Из-за чего все записи регистра стали не уникальными, так как все данные этого единственного измерения просто исчезли при пересоздании.

При сравнении основной конфигурации с конфигурацией базы данных обнаружилось, что помимо этого конфигуратор пересоздаёт ещё несколько справочников присоединённых файлов. И вот это уже совсем плохо. Потому что файлы можно перенести из регистра в тома хранения, и они не потеряются. А вот информация о том, к какому документу какой файл присоединён, будет утеряна полностью. Были пересозданы и другие объекты конфигурации, их реквизиты/измерения/ресурсы, табличные части и даже отдельные значения перечислений.

Полагая, что что-то не так с исходной конфигурацией базы данных, мы выгрузили конфигурацию хранилища. С помощью сравнения/объединения с файлом конфигурации добились того, чтобы между конфигурацией базы данных и конфигурацией хранилища не было никаких различий. И снова подключили его к хранилищу.

Эффект тот же. Различий, конечно же, стало меньше, но все те же объекты конфигурации всё так же пересоздавались.

Мы перебрали все варианты расстановки галочек в параметрах сравнения/объединения — ничего не изменилось.

Возникло предположение, что вся проблема кроется в различии внутренних идентификаторов физических таблиц и их полей в СУБД. Появилась идея: «А не перенумеровать ли нам таблицы и их поля средствами СУБД?». Пообщавшись с экспертом по технологическим вопросам, мы получили добрый совет: «Не перенумеровать», — поскольку при этом могут нарушиться связи между таблицами. Но главное, ссылки в полях составного типа, помимо уникального идентификатора, содержат ещё и номер таблицы объекта, на который они ссылаются. Нужно будет как минимум исправить номера таблиц в ссылках. И всё это уже выглядит как задача с непрогнозируемой трудоёмкостью и не прогнозируемым результатом.

Готовясь к написанию этой статьи, я решил всё-таки сравнить структуру хранения данных тестовой базы, которую нужно было подключить к хранилищу, и структуру хранения какой-нибудь другой базы, уже подключённой к хранилищу. К своему разочарованию я обнаружил, что у них различаются внутренние идентификаторы практически всех физических таблиц. Я сравнил структуру хранения двух баз, уже подключённых к хранилищу и не являющихся копиями одной и той же базы. То же самое — номера практически всех таблиц различаются.

То есть конфигуратор не просто так пересоздаёт все таблицы с различающимися внутренними идентификаторам, а сам пытается как-то перенумеровать их. Но это получается у него не всегда. И нет смысла делать то же самое, что пытался сделать конфигуратор и чуть-чуть не доделал. Спасибо ему и за то, что он сделал почти всё и оставил нам не так много работы. )))

Естественно, у нас возник ещё один вопрос: почему мы за четверть века ни разу не сталкивались ни с чем подобным? Тут остаётся только гадать. Наши предположения такие: если в конфигурацию добавляется нетиповой объект данных, то он занимает какой-то очередной номер. В тоже время 1С добавляет свои объекты в типовую конфигурацию. И при обновлении на новый релиз типовой конфигурации конфигуратор вынужден смещать номера типовых объектов. Если же нетиповой объект добавляется уже после обновления релиза, то типовые объекты сохраняют свои номера, а нетиповой получает следующий номер. Таким образом, если разные базы дорабатываются и обновляются в разной последовательности, номера объектов в них неизбежно будут различаться.

И это как раз наш случай. У заказчика было головное и более десятка дочерних предприятий, каждое со своей бухгалтерской базой. И каждая база со своей многолетней историей доработок и обновлений.

Обновлять и дорабатывать полтора десятка баз по отдельности — это великий и изнурительный труд. Поэтому перед нами и встала задача: сначала разработать Единую конфигурацию, удовлетворяющую требованиям всех предприятий, а потом и подключить их базы к Единому хранилищу. С первой задачей мы успешно справились, благо деятельность предприятий была приблизительно одинаковой — различались регионы. А вот со второй задачей вышла накладочка. Но это в любом случае нужно было сделать.

А как?

В принципе всё совершенно очевидно:

1. Очистить неуникальные регистры сведений, чтобы удалось обновиться.

2. Загрузить все потерянные данные из копии Выгрузкой/загрузкой XML.

Но на этом несложном пути возникли серьёзные затруднения:

1. Список различий достаточно велик, и работать с ним крайне неудобно. Поэтому мы сформировали краткий отчёт о сравнении конфигураций и обработали его с помощью Excel, чтобы получить краткие списки пересоздаваемых объектов и их полей. Затруднение же выражалось в том, что Excel не слишком хорошо приспособлен к парсингу текста. На десятке тысяч строк сначала повисает на 20-30 минут при начальной обработке текста, а потом повисает на 3-5 минут при каждом переключении фильтров, необходимом для копирования списков пересоздаваемых объектов.

2. Мало знать, какие объекты пересоздаются, нужно ещё выяснить, какие реквизиты на них ссылаются. Ведь после реструктуризации в них будут битые ссылки, даже если мы загрузим все потерянные данные. Потому что в этих ссылках будут указаны или уже несуществующие номера таблиц или номера не тех таблиц. Но сравнение/объединение этого не показывает. Поэтому пришлось написать отдельную обработку, которая «обходит» все метаданные и выясняет, в каких реквизитах могут появиться битые ссылки. Тут особых затруднений не было, кроме того, что это оказалось не элементарно просто.

3. Внезапно оказалось, что с помощью Выгрузки/загрузки XML нужно перегрузить огромные объёмы данных и даже в 3-5 потоков это занимает очень много часов кропотливого труда. А у нас не так много времени: с позднего вечера пятницы до раннего утра понедельника. И перегрузка данных из копии — далеко не всё, что нужно успеть за выходные. Нужно ещё правильно настроить учёт на новой конфигурации. Для ускорения мы решили перегружать через XML только те объекты, которые пересоздаются целиком и у которых целиком пересоздаются табличные части. А перегружать значения отдельных реквизитов «научили» обработку из пункта 2.

В общем, мы справились. В 4 подхода всё подключили. В зависимости от объема баз данных за одни выходные успевали подключать и настраивать от одной до четырёх баз.

Эпопея с подключением закончилась.

А проблемы остались.

Правда, уже не такие значительные. И не при подключении рабочих баз к рабочему хранилищу, что очень критично, а при подключении их копий к тестовому хранилищу. Периодически что-то пересоздаётся. Как правило, ненужное для тестирования, и мы смиряемся с потерей этих данных. Ведь тратить по двое суток для того, чтобы на всякий случай ничего не потерять - это слишком неэкономно.

И ещё одна неприятная деталь, которая гложила  и в итоге побудила написать эту статью: риск потери компетенций. Слишком всё было запутано в Excel`е и в этой отдельной обработке: что и куда копировать, в какой последовательности нажимать на кнопки, включать и выключать фильтры и что ещё нужно проверить вручную. В итоге 4 раза все эти операции проделывал один и тот же человек. 

Однако прежде чем начинать рассказывать о сложных вещах, стоит хотя бы попытаться их немного упростить. Особенно если речь о том, что не так часто встречается в жизни. Приблизительно всего один раз.

Поэтому, приступая к этой статье, я решил «научить» отдельную обработку не только тому, что могла бы сделать Выгрузка/загрузка XML, но и вообще всему, что она делала. И всему, что делал Excel. Когда нет никакого дедлайна, можно позаниматься и оптимизацией.

И вот что у меня получилось

Сначала нужно с помощью сравнения/объединения привести подключаемую базу к конфигурации хранилища. Это может получиться не быстро и не с первого раза. Но в этом моя обновлённая обработка ничем не поможет. Тем более, что все мы постоянно занимаемся обновлением и сравнением/объединением конфигураций и имеем в этом огромный опыт.

Я бы посоветовал не делать как мы. Не подключать базу данных к Единому хранилищу сразу после перехода на Единую конфигурацию. Дать пользователям немного поработать без подключения к хранилищу, чтобы убедиться в том, что сам переход на Единую конфигурацию выполнен успешно. Тогда на всю работу времени будет больше, чем одни выходные.

1) И вот после этого впервые в дело вступает моя обработка:

a. подключите базу к хранилищу;

b. сравните основную конфигурацию с конфигурацией базу данных;

c. сохраните краткий отчёт о сравнении конфигураций в текстовый файл;

d. запустите базу данных в пользовательском режиме без обновления конфигурации;

e. откройте обработку;

f. выберите фай с Отчётом о сравнении.

Теперь мы готовы начать обработку данных перед реструктуризацией:

2) Второй шаг простой: достаточно нажать на кнопку «Выбрать изменения данных» в верхнем правом углу.

И вот обработка сделала всё, что делал Excel, да к тому же ещё сделала грубый подсчёт количества данных:

Особо приятно то, что она справилась с этим всего за 5 секунд. Иначе я бы потратил на её разработку и отладку непростительно много времени. И это ещё раз доказывает, что для каждого дела свой инструмент.

Справа для контроля выводится текст запроса, с помощью которого выполнялся подсчёт количества данных.

В принципе, пустые таблицы можно было бы выбросить из рассмотрения, но я решил их оставить, чтобы была возможность убедиться, что мы ничего не упустили. Для этого лучше, конечно, использовать не отчёт, а окно сравнения объединения: там всё очень красиво разукрашено привычными цветами.

Сопоставляя Отчёт о сравнении с данными Дерева сравнения, мы видим, что в дереве отображены только объекты данных. Всякие подсистемы, формы, обработки и отчёты в дерево сравнения не заносятся. Удаление и добавление в отчёте и в окне сравнения/объединения отображаются в разных строках, а в Дереве сравнения — в одной. И они должны быть парными. Если какие-то объекты только удаляются или только добавляются, то обработка выведет их перечень на отдельной вкладке и не предложит продолжения работы, пока вы не приведёте конфигурацию базы данных к конфигурации хранилища. Про это я говорил в первом абзаце этого параграфа.

Вот как выглядела отдельная вкладка, когда я сравнил не подготовленную базу с хранилищем:

3) Для продолжения работы нажмите на кнопку «Проверить изменения типов» в левом верхнем углу на вкладке «Дерево сравнения».

Это уже то, что делала отдельная обработка, но теперь она делает это лучше. Отображает визуальную информацию, позволявшую всё детально проверить. Во время разработки и отладки это очень помогает:

Проверка типов всех реквизитов по метаданным и точный подсчёт количества данных, в которых в результате реструктуризации появятся битые ссылки, занимает больше времени. Но 20 секунд все ещё приемлемо.

В дерево Сравнения типов данных мы не вносим пустые таблицы и реквизиты, поскольку их не с чем сравнивать. Остаётся только полагаться на то, что обработка ничего не упустила.

Способ подсчёта так же, как и на предыдущей вкладке, отображается справа. Две галочки «Удаляется» и «Добавляется» слились в одну — «Пересоздаётся». Если мы дошли до этого шага, то они уже точно были парным.

Кроме того, добавляется страница с перечнем регистров, содержащих неуникальные записи. Без их удаления выполнить реструктуризацию не удастся:

В моей тестовой базе такой регистр всего один. И поскольку в нём вообще нет уникальных записей, потому что единственное его измерение пересоздано целиком, его можно полностью очистить. Если же у регистра несколько измерений или пересоздаются только отдельные типы, входящие в составной тип измерения, или только отдельные значения перечисления, то может сложиться такая ситуация, когда только некоторые записи становятся не уникальными. И достаточно удалить только их.

Ну и, как водится, справа отображается запрос, с помощью которого выполнялся поиск и подсчёт количества не уникальных записей.

4) Возвращаемся на вкладку «Сравнение типов данных» и нажимаем на кнопку «Подготовить запросы» в левом верхнем углу.

Это уже мгновенно, ведь мы больше не обходим все метаданные и не подсчитываем все объекты. Справа появляется дополнительная вкладка с запросом данных для выгрузки, слева — колонка с иконкой, изображающей разнокалиберные полоски в строках, соответствующих таблицам, из которых мы берём данные:

Хотя кое-что мы всё-таки подсчитываем. Но немного.

Появляется вкладка «Записи, у которых пересоздаётся измерение»:

На ней и наш старый знакомец РегистрСведений.ДвоичныеДанныеФайлов и ещё некоторые регистры, у которых, несмотря на пересоздание объектов, указанных в их измерениях, никакие записи не становятся не уникальными. Просто нам проще сразу удалить их и загрузить вновь, чем потом думать, как найти. Запрос, позволяющий определить, какие записи нужно удалять, как всегда, на своём месте справа.

5) И наконец-то у нас появляется вкладка «Выгрузка данных перед реструктуризацией», позволяющая перейти к решительным действиям.

Тут я позволил себе существенно сократить скриншот по вертикали, потому что на этой вкладке практически ничего нет. Только имя файла, в который нужно выгрузить данные, и кнопка «Выгрузить данные»:

6) После выгрузки данных появляется длинная розовая кнопка «Удалить записи регистров сведений, у которых пересоздаются измерения». На моей тестовой базе это было быстро, потому что у нас не так много подобных записей:

И после удаления неуникальных записей и записей, у которых пересоздаются измерения, появляется сообщение о том, что можно обновлять базу.

Хотя на самом деле это не совсем так.

Вы, наверно, уже заметили галочку в левом верхнем углу и выделенную зелёным надпись: «Режим тестирования: Все изменения выполняются в транзакции, после чего она отменяется. Не выполняйте реструктуризацию!!!». Во время разработки режим отладки сэкономил мне уйму времени, потому что тестовая база двухлетней давности с пропуском десятка регулярно поставляемых 1С релизов очень плохо обновлялась на последнюю версию конфигурации хранилища. Последний раз я бился с ней целый день. Но даже если никто не добавил в хранилище новых объектов данных, пока я занимался обработкой, на то, чтобы загрузить даже такую маленькую базу из dt-шника, подключить её к хранилищу далеко не самой маленькой конфигурации Бухгалтерия предприятия (чем больше конфигурация, тем дольше формируется снимок хранилища), а потом ещё сравнить эти две не самые маленькие конфигурации, уходит довольно много времени. Да и запускается Бухгалтерия предприятия не мгновенно.

Раз уж нам ещё не время обновлять базу и скучать, ожидая окончания реструктуризации, давайте посмотрим, что на вкладке «Загрузка данных ПОСЛЕ реструктуризации».

7) Загрузка данных ещё менее многословна, чем выгрузка. Помимо файла загрузки (он же и файл выгрузки) у нас есть только файл проверки. Указав его, можно нажимать на кнопку «Загрузить данные»:

Вполне ожидаемо, это самая длительная операция.

И если у вас нет срочных дел, пока идёт загрузка, рекомендую посмотреть журнал регистрации в конфигураторе. Иногда это бывает весьма полезно. В моём случае какая-то не типовая подписка записывала в регистр сведений сообщения об изменении каждого элемента каждого справочника. А их тысячи. И это несмотря на то, что я — извините за каламбур — выполняю загрузку в режиме загрузки. Конечно, 5 или 10 минут - это не существенно. Но я выбрал для тестирования самую маленькую базу из ~дюжины. При реальном подключении у нас такое тоже случалось, только в другом месте. Тогда потери времени были катастрофическими. И при реальном подключении нам тоже приходилось отменять лишние записи, чтобы уложиться в срок.

8) Ну и последнее, что я вам настоятельно рекомендую сделать — сравнить эти файлы:

У меня они идентичны, но это получилось не сразу. Я отловил с помощью этого сравнения одну досадную ошибку. А даже одна вовремя устранённая ошибка стоит того, чтобы устроить хоть какую-нибудь проверку.

Признаюсь честно: данные выгружаются в файл функцией ЗначениеВФайл. И если в файлах обнаружатся какие-нибудь различия, то их сравнение будет практически нечитаемым. Если обработка будет востребована впредь, я придумаю более информативный отчет.

9) Теперь, когда мы прошли все этапы в режиме тестирования, давайте уберём галочку и пройдём их в рабочем режиме:

При снятой галочке надпись о том, что теперь используется рабочий режим и транзакция уже не отменяется, будет выделена розовым цветом. Чтобы не приедалась.

Хотя этот режим влияет только на удаление записей регистров сведений, у которых пересоздаются измерения, и на загрузку, без их удаления (как минимум без удаления не уникальных записей) невозможно провести обновление или реструктуризацию. А чтобы их удалить, придётся пройти всё с начала.

10) Закрываем пользовательское окно, выполняем обновление/реструктуризацию и снова запускаем базу в пользовательском режиме.

11) И снова открываем нашу обработку. Снимаем галочку, чтобы перейти в рабочий режим. И запускаем загрузку на вкладке «Загрузка данных ПОСЛЕ реструктуризации»:

То, что я сначала проверил всё в тестовом режиме не уберегло меня от ошибок в рабочем. Дело в том, что я выгружаю данные в виде таблиц, скопированных с таблиц, полученных запросом с сохранением исходных типов колонок. При копировании я только лишь добавил тип структура, чтобы была возможность разложить ссылки на пересоздаваемые объекты, на полное имя объекта в метаданных и строковое представление уникального идентификатора; а перечисление — на полное имя и имя значения перечисления. И потом на основе этих данных восстановить правильные ссылки. Но после реструктуризации, при чтении таблицы значений из перечня типов колонок, выбрасываются типы всех пересозданных объектов, потому что теперь у них новые идентификаторы. И остаются только типы Структура и Null. Ссылку я восстанавливаю, но записать её обратно в таблицу не могу, вместо неё записывается Неопределенно. Можно было переписать код и записывать ссылки прямо в объект, но от этого он стал бы очень громоздким. Поэтому я просто перестал выгружать типизированные таблицы. Привычка создавать типизированные таблицы сформировалась у меня для использования их в качестве параметров запросов, а при загрузке они не используются, и типизация ни к чему.

Если я правильно помню события дня — это была последняя ошибка, из-за которой потребовалось восстанавливать тестовую базу из dt-шника. Подключение завершилось успешно. Но даже одна непредвиденная ошибка стоит того, чтобы запастись резервной копией — мы помним об этом всегда.

Какие же выводы можно сделать из всего этого?

Будет ли теперь счастье?

В общем-то, и несчастье такое постигло нас всего один раз в жизни. В 4-х экземплярах.

Но в действительности есть и другие причины проявить бдительность, а не верить в него слепо. Дело в том, что не все возможные превратности судьбы встречались нам на этом нелёгком пути. Не всё, что могло бы произойти с этой ~дюжиной баз, произошло в реальной жизни:

1) Мы ни разу не сталкивались с тем, чтобы пересоздавались объекты, на которые ссылаются регистры бухгалтерии и субконто. Я всегда это проверял. Возможно, 1С особо бережно к ним относится и пересоздаёт что угодно, но только не то, что нужно для ведения бухгалтерского учёта. Так или иначе, раз нет возможности протестировать, я даже не стал писать специализированный код выгрузки/загрузки данных регистров бухгалтерии. Вы прекрасно знаете, что создавать записи в регистр бухгалтерии заметно сложнее. Так к чему тратить на это время, если всё равно ни разу не потребовалось. Если такое всё же произойдёт, обработка выльется в ошибку уже на этапе выгрузки и не подведёт вас.

2) Мы ни разу не сталкивались с тем, чтобы пересоздавались документы, являющиеся регистраторами, или объекты, являвшиеся владельцами справочников или планов видов характеристик.

3) Ни разу не пересоздавались документы, входящие в Журналы документов. 

4) У нас есть один замечательный регистр, в котором очень много полей типа «Хранилище значений». Само хранилище значений перегружается легко, но вот что в нём хранится — неизвестно. Если там есть ссылки на пересоздаваемые объекты, они, конечно, испортятся. Но в моей тестовой базе все поля были пустыми. Когда создавалась её резервная копия, регистр был совсем скуден. Я кое-что добавил в пустые хранилища значений, и всё прекрасно перегрузилось. Никаких испорченных ссылок. В общем, на такие поля нужно обращать особое внимание.

5) В Бухгалтерии предприятия нет Планов видов расчётов и Регистров расчётов, а в моей тестовой базе не было Бизнес-процессов и Задач.

Я, конечно, написал код для обработки этих объектов по аналогии. Но он не протестирован. Поэтому запаситесь резервной копией и обращайте внимание на эти моменты.

Станем ли мы работать быстрее, вооружившись это обработкой?

Да, станем. Я посмотрел журналы подключения, в которых мы отмечали выполнение всех работ и время, потраченное на это. Конкретно при подключении этой базы мы потратили: 

27 мин. на обработку отчёта Excel`ем; 

11 мин. на сравнение типов данных и выгрузку ссылок на пересоздаваемые объекты отдельной обработкой; 

17 мин. на загрузку; 

11 мин. на Выгрузку/загрузку XML. 

Итого 66 мин.

Новая обработка потратила на это меньше 6-ти минут! То есть в 10,5 раз меньше времени.

При этом, надо признать, что в масштабах всех работ по переходу на Единую конфигурацию и подключению к Единому хранилищу, на которые мы тогда потратили 9 часов 22 минуты, экономия не такая существенная - 10,6%. Но наша работа стала более понятной.

Стоило ли нам сразу написать такую годную доработку?

И не тратить столько времени на использование разных не столь удобных инструментов. Ответ отрицательный: Не стоило. Во-первых, понимание, что и как нужно делать, какие подводные камни, как обходить, пришло не сразу, а сформировалось с опытом. Во-вторых, в условиях ограничений по срокам и бюджету работ для заказчика мы просто не могли этого сделать раньше. Сделали сейчас для совершенствования будущих подключений.

Обработку прилагаю.

И да, по идее, она должна работать на любой конфигурации, потому что я не применял никаких БСП — только методы платформы. Зачастую не слишком современные. Но если вдруг подвернётся какая-нибудь ещё менее современная платформа, мы наверняка с этим справимся.