Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
В предыдущем обзоре я рассказывал о способах интеграции 1С с внешним миром. Моей целью было дать по возможности полную картину, но без лишних подробностей. Так, чтобы можно было быстро сориентироваться в многообразии вариантов и сделать выбор. Теперь я постараюсь сделать то же самое для ситуации, когда надо организовать обмен данными между базами 1С, как однотипными, так и разнотипными
КД2
В случае внутренней интеграции (база 1С - база 1С), выбор инструментов не столь уж большой. И первый из них это продукт под названием Конвертация данных, редакция 2, сокращенно КД2.
Он представляет собой отдельную конфигурацию и для того, чтобы им воспользоваться вы разворачиваете отдельную базу. Затем вы идете в базу-источник, в пользовательский режим. Запускаете там обработку, которая прочитает конфигурацию базы и сохранит ее в файл. Потом идете в базу-приемник. В ней проделываете то же самое. Далее идете собственно в базу КД2. Загружаете из файлов, полученных на предыдущих шагах две конфигурации. Вы еще не устали? Ничего, скоро нас ждет награда. Еще несколько нажатий на кнопки. Говорим, что у нас будет источником, что приемником и, наконец, даем команду создать нечто, называемое правилами обмена. Теперь, когда у нас есть эти самые правила, мы можем запустить внешнюю обработку под названием "Универсальная выгрузка, загрузка данных xml", указать файл правил и заняться собственно выгрузкой, а затем загрузкой данных. И данные (о чудо!) действительно попадут из одной базы в другую.
В чем плюс КД2? Вы не вникаете досконально в структуру данных. В чем минус? ... вы не вникаете досконально в структуру данных. Изначальная идея была вполне себе годной. Создать low code инструмент. Но сделать это оказалось не так-то просто. Вот несколько цитат со знаком "+" и со знаком "-".
Как-то видел человека, который долго и дорого писал правила ЗУП-ЗУП. Вроде бы из четырех баз ЗУП надо было положить в одну - что там такого, да? Но месяц правила писались, были написаны на половину, отлажены вообще не были. Я за три дня написал код, который делал вот только это и ничего больше. Потом оказалось, что есть совместители, которые уже в одной из этих баз на постоянке. При том совместитель устроился раньше, чем на постоянку. Потом внешние и внутренние, а нельзя быть одновременно тем и этим. Ну и дальше множество нюансов, которые на КД2 я вообще не представляю, как пришлось бы делать, ибо пакеты приезжают одновременно из четырех баз в одну, и они друг с другом связаны.
Обмен между идентичными базами пилится минут за 10:1) Формируется описание конфигурации.2) Загружается в КД21.3) Создаём правила, где источник и приёмник - одна и та же конфа. Отвечаем "да" на вопрос об автоматическом создании ПКО.Ровно ноль строк кода.Я думаю, ни в 25, ни в других постах противоречий нет - писать код там, где можно обойтись без кода - это глупо, но всегда возможно.
У меня клиенты малые и очень. И типовые решения 1с (базовые версии) используются ими процентов на 10-20. Железо не новое. Когда начал настраивать типовой обмен Розница и БП3, время и громоздкость первоначальной настройки (сопоставление объектов и проч.) разочаровала. А нужна была только выгрузка базы товаров, установки цен, поступлений (возвратов) и продаж. Сделал свое. Публикация здесь на ИС. Работает. Есть у меня знакомые бухгалтера-аутсорсеры я им сделал удаленный доступ к базам клиентов, 2 обработки, выгрузка и загрузка. Никаких настроек. Выгружают, загружают раз в месяц/квартал, чтобы посчитать налогооблагаемую базу. Время на основную идею потратил 2 дня по 4-5 час, я не чистый программист, бывает месяцами ничего не программирую. Тут в новостях узнаю, что вместо Розницы 2 будет 3, у кого штатный обмен - опять придется планы обмена настраивать. А я потрачу 1-2 часа на доработку, и далее будет работать
Между идентичными конфигурациями за рабочий день я нарисую столько правил, сколько позволит по времени выгрузить\загрузить метаданные. Как писали ниже, просто берешь нужные объекты и автоматически создаешь ПКО, КД всё делает корректно. Между УТ-БП БП-УТ естественно дольше.
Я без труда наберу вам еще с десяток и в ту, и в другую группу. Похоже, что мнения специалистов разделились примерно поровну. И это верный признак, что что-то пошло не так.
Когда у вас идентичные конфигурации и документы переносятся один к одному, то тут, да, возникает магия low code. Но если ситуация хоть чуть сложнее, например, документ одного типа в источнике превращается в документ другого типа в приемнике, тогда код писать все равно придется. Этот ваш код попадет в тот самый xml файл правил обмена (и это прелестно!), но прежде вам предстоит усвоить целый ряд новых понятий: правило конвертации объекта, правило конвертации свойства и т.д. А после этого вам надо будет придумать способ отлаживать код, который оказался в xml файле. И все это непонятно ради чего.
Ситуации с обменом бывают всякие. Но очень редко когда это что-то совсем простое или что-то по настоящему сложное. Чаще всего надо запрограммировать какую-нибудь ерунду. Это-то и раздражает специалиста, который посреди процесса вдруг осознает, что если бы он не пытался в low code, а пошел обычным путем, то он бы уже давно все сделал.
КД3
Конвертация данных редакция 3 подается как отдельный продукт, который не заменяет, а дополняет КД2. Оно и понятно. Натерпевшись с КД2, люди не спешат от нее отказываться. Только научились отлаживать код внутри xml, а тут оказывается, что нет ничего ценного в этом навыке. Так не пойдет!
Действительно, результатом работы КД3 является не файл каких-то правил, а код. Этот код вставляется в определенный модуль типовой (или нетиповой, но с подключенной библиотекой стандартных подсистем) конфигурации. И после этого его можно менять и отлаживать обычным порядком.
Кроме этого, процесс обмена разделен. Выгрузка отдельно, загрузка отдельно. И это, кстати, тоже правильно. Далее, в КД3 решили пусть будет некий единый формат данных для обмена под названием ED (Enterprise Data). В этом есть свои плюсы. Выгрузка отделяется от загрузки во всех смыслах. Их могут вообще две независимые команды делать. Если что-то поменялось в конфигурации источника(приемника), то переделываем не все, как это было с КД2, а только часть. Кроме того, и базой-источником и базой-приемником теперь может быть не только база 1С, а какая-нибудь другая база. Т.е. КД3 можно рассматривать как универсальный инструмент. Он подойдет как для внутренней, так и для внешней интеграции.
Все было бы замечательно, но... XDTO. Именно это используется для создания Enterprise Data. XDTO (XML Data Transfer Objects) это еще одна концепция, рожденная в недрах 1С. С целью покорить если не весь мир, то хотя бы сердца 1С-ников. Но, как и в случае с low code, создать удачный формат не так-то просто. Вот формат скобка фигурная, скобка квадратная (JSON) он действительно покорил мир. Потому что решает реальную проблему минимально необходимыми средствами. А с XDTO проблема даже не в том, что сложно. А в том, что непонятно - ради чего. Ради того, чтобы оперировать не узлами и атрибутами, а свойствами объектов? Ну спасибо! Но если дело дошло до дела, и я начал кодировать, то мне, в принципе, все равно. Сложность работы нисколько не уменьшается. Только появляется дополнительное нечто, во что надо въезжать
Простой способ
Если вдуматься, то от инструмента, помогающего нам организовать обмен данными, надо не так уж и много. Освободить нас от монотонного переписывания:
ИмяРеквизита1ВПриемнике = ИмяРеквизита1ВИсточнике
ИмяРеквизита2ВПриемнике = ИмяРеквизита2ВИсточнике ...
В типовых конфигурациях сейчас реквизитов ну очень много. И табличных частей тоже. Надо ничего важного не пропустить при переносе данных. Настоящий low code, это когда мы без изучения каких-либо дополнительных понятий и концепций получаем заготовку кода для выгрузки(загрузки) в базе источнике(приемнике), в которой будут все отмеченные нами объекты, реквизиты, табличные части. В этой заготовке должен быть минимум необходимого для обмена. Выборка из плана обмена, сериализация в JSON или XML в правильном порядке (группы раньше элементов) для выгрузки. Для загрузки это будет поиск объектов, чтобы изменять существующие и создавать не существующие. Минимальная заготовка будет легко читаться и столь же легко дополняться. Такого рода инструменты имеют хождение среди специалистов.
Заключение
Что использовать? Зависит от ситуации. Стоит обзавестись некоторым минимумом знаний и по КД2 и по КД3. Возможно, что ваш обмен будет частью чего-то большего. И в этом большем уже основательно завязались на XDTO. Но если перед вами не поставили жесткого требования делать обмен по КД2 или КД3, тогда лучшим решением будет воспользоваться инструментом для получения заготовки кода. Исключением может быть случай, когда действительно все совсем просто. Конфигурации однотипные и обмен один в один. Тогда КД2 сэкономит вам время.
Ну и в завершение хочу порекомендовать вам бесплатный вебинар, на котором вы научитесь создавать проект EDT и подключать его к стандартной конфигурации 1С. Увидите подводные камни и научитесь их обходить. Посмотрите в процесс разработки. Увидите принципиально новые подходы, упрощающие и ускоряющие разработку. Обсудите с экспертами тему производительности EDT. Увидите всё на конкретных примерах и замерах.
Зарегистрироваться на бесплатный вебинар
