1С:Конвертация данных 2.0. Преимущества и недостатки
Основной акцент в статье будет сделан именно на «Конвертацию данных» второй редакции. Дело в том, что на этой технологии до сих пор основано наибольшее количество типовых обменов между конфигурациями. Кроме того, если вы будете сталкиваться с задачами перехода на новые редакции программ 1С, вам также придется иметь дело с правилами, разработанными в «Конвертации данных» второй редакции.
Итак, какие преимущества и недостатки есть у «Конвертации данных» второй редакции? Начнем с преимуществ:
- «Конвертация данных» второй редакции стала сейчас основным стандартом разработки переносов и обменов. Эта технология существует с 2001 года, и знания в этой области являются популярным требованием при приеме на работу, потому что задачи использования этой технологии очень распространены, и в типовых конфигурациях активно используются.
- У «Конвертации данных» 2.1 есть широкие возможности: вы можете настраивать обмены и переносы данных не только с продуктами 1С (любых редакций – как 8.х, так и 7.7), но и с продуктами других разработчиков.
- А также, что является большим плюсом, для этой технологии есть множество готовых решений. Например, если у вас есть некие нетиповые конфигурации, для которых нужно выполнить перенос данных в другую программу 1С, вы можете взять типовой перенос и его доработать. Или взять готовые обработки в интернете, и, таким образом, существенно сэкономить свое время и силы. Это позволит вам выполнить свою задачу буквально за дни – не тратить на это месяцы.
Какие минусы?
- У Конвертации данных 2.1 нет многопоточности.
- Формат представления данных – это xml, который имеет свои минусы. Об этом мы позже поговорим подробнее.
- Нет защиты от сбоев. Вы можете сутки выполнять выгрузку данных из программы, а она прервется по какой-нибудь битой ссылке в одном из объектов, после чего вам придется исправлять эту ошибку в данных и заново начинать свой перенос.
- Можно сказать, что для нее неудобно выполнять отладку. Я сейчас говорю, в основном, про обработку «Универсальный обмен в формате XML» – у нее есть возможность отладки, но для этого вам придется создавать отдельную обработку, в которую должны быть встроены модули всех используемых правил конвертации, и подключать эту обработку к универсальной обработке обмена. На мой взгляд, это неудобно.
- И нет хорошего контроля переполнения кэша. Например, когда у вас объектов много, они будут копиться, и каждая следующая тысяча объектов будет выгружаться все медленнее и медленнее.
Методические рекомендации. Подготовка базы-источника
Итак, чтобы провести перенос, нужно подготовить информационные базы: и базу – источник данных, и базу – приемник. Допустим, мы сейчас с вами будем говорить про перенос данных из УТ 10.3 в УТ 11.3. Какие действия необходимо совершить заранее и как подготовить исходную информационную базу?
- Во-первых, нужно подготовить свою нормативно-справочную информацию – вычистить справочники от ненужной информации:
- Удалить дубли элементов справочников,
- А также удалить все помеченные на удаление объекты.
- Следующим шагом необходимо выполнить закрытие отчетного периода и прочие регламентированные действия. В частности, рассчитать себестоимость.
- В некоторых случаях вам потребуется сделать изменения настроек учета и перепровести после этого все документы. Например, в старых редакциях таких программ, как УТ10.3, КА1.1, УПП1.3 есть такие настройки параметров учета, при которых вы не сможете после перехода получить себестоимость товаров в разрезе различных складов – она у вас усреднится, поскольку в регистрах не будет необходимой для этого информации.
- Разумеется, нужно будет проверить свои данные в отчетах, чтобы не было нулевых сумм и отрицательных остатков. Например, в УТ10.3, КА1.1 и УПП1.3 вам необходимо следить за тем, чтобы количественные остатки по регистру «Партии товаров на складах» не отличались от остатков по регистру «Товары на складах», потому что остатки берутся из регистра «Товары на складах», а себестоимость берется из партий (в других регистрах ее нет).
- Если информационная база большого размера, то стоит задуматься о том, чтобы очистить те таблицы, которые вы не будете использовать при переносе. Например, почистить такой регистр сведений, как «Версии объектов». При уменьшении размера базы запросы смогут работать быстрее.
Методические рекомендации. Подготовка базы-приемника
Как подготовить базу-приемник? Мы рассмотрим случай, когда переход на новую программу выполняется переносом данных в пустую базу. Что нужно сделать?
- Создать новую базу.
- Установить необходимые настройки учета, включить требуемые функциональные опции: например, использование нескольких валют, нескольких организаций.
- Загрузить или ввести вручную техническую информацию (такую, как адресные классификаторы и курсы валют). Конечно, вы можете перенести их вместе с остальными данными, но такой перенос займет много времени. Поэтому рекомендуется в базе-приемнике все эти классификаторы загрузить предварительно (перед запуском переноса), потому что если они будут пустые, программа может работать некорректно – если при проведении документов по валютным договорам курс доллара окажется равным единице, данные учета исказятся.
- И, если вам известны ошибки типовых релизов, то первоначально необходимо их исправить. Например, в «Управлении торговлей 11» у роли «Полные права» может не оказаться полных прав. Так было в релизе 11.2. А если у вас нет полных прав, то, разумеется, могут возникнуть проблемы при проведении загруженных данных.
Методические рекомендации. Перенос с помощью обработки vs через план обмена
Далее я хочу рассказать вам о том, что есть разница между выполнением синхронизации данных с использованием универсальной обработки обмена и с использованием планов обмена. Это также касается и разработки самих правил конвертации. Например, в правилах выгрузки регистров сведений при использовании планов обмена переменная Объект будет иметь тип значения РегистрСведенийНаборЗаписей, а при переносе с помощью универсальной обработки обмена эта переменная будет иметь тип значения РегистрСведенийЗапись. И если отладку правил вы выполняли с помощью универсальной обработки, а потом встроили эти правила в план обмена, то не исключено, что вы встретитесь с такой ошибкой.
В чем отличия правил конвертации для универсальной обработки обмена и для планов обмена? Какие у них могут быть особенности?
Для универсальной обработки обмена:
- Имеет смысл настроить правила конвертации так, что они будут самостоятельно устанавливать в программе-приемнике настройки параметров учета (в обработчике «Перед загрузкой данных») – например, включать использование нескольких расчетных счетов для организаций и т.д.
- Если размер информационной базы источника значительный, вам нужно соблюдать баланс между использованием кэша при переносе и его отключением. Про это я расскажу далее. Это очень важный параметр.
А какие особенности у правил, написанных для плана обмена, когда мы уже регулярно выполняем свой обмен между программами 1С?
- При регулярном обмене у нас есть таблица регистрации изменений, куда будут попадать только зарегистрированные изменения. Таким образом, как правило, выборка будет меньше, и при регулярном запуске обмена он будет выполняться быстро и с небольшой выборкой.
- Соответственно, имея небольшую выборку, мы можем позволить себе по максимуму кэшировать объекты, на которые есть большое количество ссылок.
- А также в зависимости от своей задачи нужно отслеживать то, что те данные, которые мы переносим (допустим, документы) могут быть изменены пользователями в базе-приемнике. И в зависимости от своих целей нам нужно их либо перезаписывать, либо отказаться от перезаписи. Это можно реализовать различными способами.
Методические рекомендации. Разработка правил конвертации
Какие приемы оптимизации разработки правил конвертации я хочу вам сегодня описать?
- Как я уже говорил, это – правильная настройка кэша правил конвертации;
- Отключение выгрузки свойств «по ссылке» в правилах конвертации (там, где это оправдано);
- Использование собственных таблиц кэша в глобальных параметрах конвертации;
- А также корректное и обдуманное использование глобальных обработчиков конвертации данных.
А теперь давайте каждый из этих приемов разберем подробнее.
Настройка кэша правил конвертации
Объекты малой выборки, на которые есть большое количество ссылок в базе, нужно кэшировать. Например, таким объектом может являться справочник «Организации». Включить использование кэша очень просто – для этого достаточно поставить галочку «Использовать быстрый поиск объекта при выгрузке и загрузке».
А для тех объектов, выборка которых в данной задаче переноса будет большая, а ссылок на них – мало (например, это могут быть элементы справочника «Номенклатура») – кэширование, наоборот, лучше отключить, поставив флажок «Не запоминать выгруженные объекты».
Однако в случае, если вы переносите торговые документы, такой флажок для справочника «Номенклатура» ставить не стоит, потому что здесь, наоборот, ссылок будет много, а поскольку вы их не запоминаете, у вас получится огромный файл выгрузки.
Отключение выгрузки свойств «по ссылке». Оптимизация правил конвертации на примере справочника «Номенклатура»
А теперь давайте на примере справочника «Номенклатура» рассмотрим демонстрацию того, как можно оптимизировать правила конвертации так, чтобы выполнить перенос с хорошей скоростью и соблюсти баланс занимаемой памяти на диске.
В этом примере я также покажу вам, как можно оптимизировать правила типовых переносов из программы УПП в ERP и из УТ10 в УТ11, чтобы не использовался «запрос в цикле».
Во-первых, оптимизация заключается в том, что мы создаем два правила конвертации справочника «Номенклатура»: «НоменклатураНеЗамещатьСвойства» и «НоменклатураСГруппойФинУчета».
В правиле «НоменклатураНеЗамещатьСвойства» мы выгружаем всего шесть основных свойств, которые используются для поиска (для остальных свойств установлен флажок «Отключить»).
Если включить опцию «Показать ссылки на ПКО», в нижней части экрана появится закладка «Ссылки из правил конвертации свойств», где будет видно, что правило «НоменклатураНеЗамещатьСвойства» указано по ссылке в каждом другом правиле конвертации программы.
И есть второе правило «НоменклатураСГруппойФинУчета», где выгружаются все свойства.
Но на него нет ни единой ссылки.
Зато оно используется в правиле выгрузки данных по справочнику «Номенклатура».
Поскольку на правило «НоменклатураСГруппойФинУчета» нет ни одной ссылки, мы отключаем для него кэш.
А в правиле «НоменклатураНеЗамещатьСвойства» мы:
- Во-первых, отключаем выгрузку свойств «по ссылке»;
- А во-вторых, используем обычный кэш (не принудительный). Разумеется, при этом мы должны будем помнить, что это будет таблица и какие-то миллионы записей все равно выгрузиться не смогут – кэш будет слишком большой.
Вы видите, что правило конвертации «НоменклатураСГруппойФинУчета» используется для выгрузки данных по справочнику «Номенклатура». Давайте посмотрим, как выглядит это правило выгрузки данных.
В его обработчике «После обработки» мы запускаем алгоритм «ВыгрузитьНоменклатуруПоСписку».
Вот как выглядит этот алгоритм. Здесь мы выгружаем объекты справочника со всеми свойствами в цикле по списку номенклатуры. Обратите внимание, где мы этот список заполняем.
Параметр «СписокНоменклатуры» мы заполняем в обработчике «Перед выгрузкой» и сразу делаем Отказ – это значит, что, обрабатывая элементы справочника «Номенклатура», мы только заполняем список, а реально выгружаем все данные в обработчике «После обработки» (все вместе за один раз).
При этом мы также можем один раз выполнить запрос по заполнению свойств и характеристик номенклатуры. И один раз выполнить запрос к остаткам номенклатуры для заполнения группы финансового учета и качества номенклатуры.
Свойства «ГруппаФинансовогоУчета» и «Качество» в ERP являются обязательными для заполнения. Таким образом, мы можем выполнить запрос один раз, а не выполнять его в цикле.
Итак, а что же будет, если пользователь возьмет и выключит правило выгрузки данных по справочнику «Номенклатура»?
Мы помним, что по ссылке в правиле «НоменклатураНеЗамещатьСвойства» у нас указано всего шесть свойств. Мы что – получим информационную базу, в которой у номенклатуры заполнено всего шесть свойств? Это же будет некорректно, не устроит наших пользователей.
Нет, такого не будет, потому что в обработчике «После выгрузки» в правиле конвертации «НоменклатураНеЗамещатьСвойства» мы также заполняем список номенклатуры.
И уже в глобальном обработчике конвертации «После выгрузки данных» мы проверяем: если данные по номенклатуре с помощью правила выгрузки данных не выгружались, тогда мы запускаем тот же самый алгоритм «ВыгрузитьНоменклатуруПоСписку», где запрос выполняется один раз по свойствам и один раз к остаткам номенклатуры для определения ее группы финансового учета.
Мы с вами видели, что в алгоритме «ВыгрузитьНоменклатуруПоСписку» производится заполнение свойств и характеристик номенклатуры. Это две проиндексированные таблицы – таблица «СвойстваНоменклатуры» и таблица «ХарактеристикиНоменклатуры». А для чего я их вообще заполняю? Где они используются?
Они используются при переносе свойства «ВидНоменклатуры». Для этого в программе есть алгоритм «СоздатьВидНоменклатуры». То, что вы здесь видите сейчас – это типовой перенос с небольшими доработками. Весь закомментированный код – это запрос в цикле, который в типовом переносе будет выполняться для каждой позиции номенклатуры. А в нашем случае этот «запрос в цикле» вызываться не будет.
Мы переопределили поведение алгоритма «СоздатьВидНоменклатуры», и используем поиск в уже созданных проиндексированных таблицах значений, где у нас хранятся найденные свойства и характеристики всей номенклатуры. При этом запрос мы выполнили один раз (в алгоритме «ЗаполнитьСвойстваИХарактеристикиНоменклатуры»), а для каждой позиции уже просто подставляем найденные характеристики и свойства.
Чуть позже я вам покажу замер производительности, выполненный на типовом коде, не содержащем этой оптимизации – вы увидите, что выполнение этого этапа занимало почти 40% всего времени. Зато теперь каждый из вас, кто встретится с этой задачей, сможет этот этап оптимизировать и значительно ускорить свой перенос. Тем более что базы «Управление производственным предприятием» чаще всего имеют большой размер, а так вы сможете сильно сократить время на переход.
Собственный кэш в глобальных параметрах
КЭШ В ПАРАМЕТРАХ
Событие перед выгрузкой объекта справочника Номенклатура:
Вступайте в нашу телеграмм-группу Инфостарт