Правила обмена больше не нужны

17.03.21

Интеграция - Файловый обмен (TXT, XML, DBF), FTP

Есть несколько общепринятых подходов к написанию обмена между 1С-системами, каждый из которых упирается в длительное изучение технологии, мучительную отладку правил конвертации и написание большого количества сервисного кода, в котором потом тяжело разобраться. О принципах работы универсального фреймворка liteExchange, который реализует быстрые обмены между 1С и внешними системами, и берет на себя всю техническую обвязку по стандартному преобразованию данных, на INFOSTART MEETUP Saint Petersburg.Online рассказал Николай Крылов.

План выступления:

  • начнем с обзора – какие инструменты и технологии используются для обменов с 1С-системами сейчас;

  • я расскажу, почему я перестал их использовать, и что меня заставило разработать новый фреймворк liteExchange;

  • расскажу, что он мне дает в цифрах и кейсах, и на каких технологиях он основан;

  • бонусом поделюсь ссылками на GitHub, на группу в Telegram, где можно обсуждать продукт – все это находится в открытом доступе.

Немного о себе:

  • в отрасли я 11 лет;

  • за это время прошёл путь от рядового разработчика до руководителя группы – в группе в разное время было до десяти человек;

  • за эти 11 лет я также побывал в ролях разработчика коробочного решения, руководителя направления, побывал в шкуре руководителя проектов или лидирующего разработчика, архитектора – все это происходило в компании-франчайзи.

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

  • кроме прочего, я автор нового фреймворка – liteExchange.

 

Какие есть инструменты для обмена данными с 1С

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

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

  • Очень долгое время практически все обмены в 1С реализовывались при помощи инструмента (фреймворка) «Конвертация данных 2.0», где разрабатывались правила обмена. Сам обмен производился через план обмена или с помощью обработки «Универсальный обмен в формате XML».

  • Позже появилась конфигурация «Конвертация данных 3.0», где можно было описывать правила конвертации по технологии EnterpriseData.

  • Кроме этого, существует обработка по обмену между одинаковыми конфигурациями «Выгрузка и загрузка XML».

Наверное, всем знакомы правила обмена XML – использовать их просто и понятно, все плюсы и минусы этого инструмента известны. Я расскажу, какие минусы не устроили конкретно меня.

  • Конкретно меня не устраивало то, что разобраться в написании правил обмена и самостоятельно их разработать достаточно сложно – надо потратить много времени (несколько дней).

  • В самой обработке обмена 35 тысяч строк кода, если что-то идет не так, приходится это отлаживать.

  • Дальше я подробнее расскажу, почему я не стал пользоваться правилами обмена.

Что касается обработки «Выгрузка загрузка XML», то ее можно использовать только для разовых случаев и для одинаковых конфигураций – для постоянного обмена она тоже не совсем подходит.

Другие инструменты для обмена – я считаю, что они подходят для высоконагруженных систем, с которыми я не сталкивался на практике. Это:

  • разного рода «кролики» – разноцветные RabbitMQ;

  • шина данных DATAREON MQ;

  • Apache Kafka и прочие аналогичные инструменты.

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

На Инфостарте есть миллион решений для обменов данными:

  • через COM-соединение;

  • с использованием HTTP-сервисов;

  • с использованием веб-сервисов;

  • с сохранением данных в файл в формате XML, TXT или CSV – неважно.

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

  • COM – это медленное и платформозависимое решение, с ним часто возникают проблемы

  • веб-сервис – уже лучше, но все-таки там надо знать XDTO, технологию работы с форматом XML – записывать туда данные либо через XDTO, либо вручную. Ключевое слово «Знать», надо очень много знать.

 

Почему существующие инструменты не подходят?

Важно понимать, в какой ситуации я находился, когда принимал решение создать свой инструмент.

Два года назад я занял должность руководителя отдела внедрения в одной из крупных фирм-франчайзи. У нас был молодой отдел, где работало десять сотрудников, которые один-четыре-шесть-десять месяцев назад увидели конфигуратор. При этом у нас было много задач по обмену данными, а времени на то, чтобы изучать десяток инструментов, скачивать какие-то готовые обработки и их изучать – не было. Поэтому пришлось найти и выбрать какое-то одно решение, с которым будем в последствии работать.

Недавно я собрал на Инфостарте всю информацию по решениям, которые перечислял выше, в виде таблички, и выложил все это в публикации //infostart.ru/public/1221657/.

Там я постарался изложить свои личные впечатления, связанные с выбором решения или технологии для решения задачи обмена данными.

В конечном счете победил обмен с использованием формата JSON с передачей данных через HTTP-сервис.

Почему?

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

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

  • Кроме прочего, использование HTTP-сервисов дает очень интересный эффект для бизнеса. За последние пару десятков лет уже все привыкли, что обмен с 1С происходит по расписанию раз в день или раз в час, что это происходит с какими-то задержками, тормозами. После этого демонстрация того, что скорость обмена данными может быть равна скорости переключения двух окон программы 1С, вызывает у бизнеса очень интересный вау-эффект, и они готовы это покупать. А если они готовы это покупать, зачем вам этому мешать?

 

#liteExchange

Несколько слов про liteExchange – что представляет собой этот инструмент?

Я постарался тот код, который чаще всего используется (это передача данных в интернет, конвертация в JSON, получение входящих данных и их распаковка, если они были зазипованы), объединить в готовое решение – в десяток команд, которые достаточно выучить, чтобы решать свои задачи дальше.

Собрал все это в расширение, дал ему название liteExchange и придумал небольшую методологию, как этим пользоваться.

 

Показатели обмена через liteExchange

 

 

Цифры, которые у меня получались при использовании фреймворка liteExchange:

  • Три десятых секунды на обмен из «Комплексной автоматизации 2.4» в «Комплексную автоматизацию 1.1». Максимальная скорость, которая была достигнута в этом кейсе – 176 миллисекунд, а средняя – 0.3 секунды.

  • Обратный обмен выполнялся чуть дольше, но это происходило из-за того, что в более сложной программе КА 2.4 документ дольше записывается и проводится.

  • Интересная особенность у меня возникла при обмене через РИБ – транзакция в 1С длилась дольше, чем сам обмен и иногда еще и откатывалась – приходилось сознательно вносить в код “замедляторы” – функции «пауза» и т.д. Реализовали для этого во фреймворке интересное решение.

  • Очень интересные результаты получались при обмене не между двумя 1С, а между 1С и чем-то сторонним – чаще всего, это мобильное приложение или личный кабинет заказчика на сайте. Это максимально быстрый обмен, потому что там используется очень маленькие пакеты данных.

 

Кейсы обменов

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

 

1С vs 1С

Постепенный переход на новую систему. У одного из наших заказчиков была задача перехода с «Комплексной 1.1» на «Комплексную 2.4». У другого заказчика ситуация была похожая – там был переход с УПП на ERP. Эти два кейса встречаются наиболее часто, и для них имеет смысл использовать мое решение, а не какие-то готовые правила обмена – сейчас объясню, почему.

Стандартный подход к переходу с одной системы на другую такой – мы долго готовимся, пишем ТЗ, потом назначается время X, к которому должно быть все готово. При удачном стечении обстоятельств, когда разработка готова, мы переносим данные, включаем рубильник и все пользователи переезжают на новую систему. В этот момент всплывают все косяки переноса и все, что не было учтено ранее – и иногда мы всей толпой откатываемся на старую систему.

Как это можно обойти? Можно реализовать постоянную бесшовную интеграцию между двумя системами (старой и новой) – это позволяет без особых усилий переходить постепенно, растянуть процесс перехода примерно на год, если это требуется, или на несколько месяцев, переводить компанию по отделам, по чуть-чуть. При этом важно очень быстро передавать данные одной системы в другую, чтобы не возникало коллизий, что один отдел в одной системе продал товар, а другой отдел в новой системе тот же самый товар продал.

Торговля «с колес». Во втором кейсе менеджеры торговали с колес, а складские сотрудники работали в отдельной программе – при этом менеджер видит, что приехала машина, очень хотят торговать этим товаром, но не могут, потому что обмен все еще идет. В том случае три минуты задержки вызывали до пяти звонков в техническую поддержку с вопросом: «Где наш товар? Хотим продавать!» Казалось бы, три минуты вроде бы ни о чем, но в данном случае это было важно.

Централизованная система для НСИ. Еще один кейс, который используется в последнее время, когда появляется необходимость централизовано хранить базу нормативно-справочной информации в виде MDM-системы. Это особенно актуально, если у нас основная система, например, ERP, а информация по ее номенклатуре нужна на сайте или в какой-то сторонней базе WMS, или в учетной системе для дилеров, или в учетной системе для менеджеров на портале (опять же сайт). В этом случае появляется потребность базу НСИ вынести куда-то отдельно, чтобы она выступала источником данных через HTTP, а нам не приходилось всю ERP светить на весь интернет.

Опять же, раз мы вынесли данные в интернет, в отдельную базу для управления НСИ было бы неплохо потом их обратно синхронизировать, если мы вынесли данные в отдельную базу «Управление НСИ», было бы неплохо обратно их синхронизировать с ERP. И тут вопрос уже не в скорости, а в том, что можно написать код один раз и полученное решение в формате API будет применимо для всех получателей информации – нам не нужно писать обмены отдельно для сайта, отдельно для ERP, отдельно для учетных систем дилеров.

Быстрее, чем РИБ. Всего пару раз, но очень показательно – встречались решения на замену платформенного механизма распределенных информационных баз. Поскольку п умолчанию обмен в РИБ работает по расписанию, у него, опять же, может возникнуть ситуация, когда один и тот же товар можно продать из разных учетных систем дважды. Чтобы избежать этой коллизии, надо значительно ускорить обмен вплоть до бесшовной интеграции, позволяющей делать обмен за секунду.

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

 

1С vs Other

Лично мне больше нравится кейс, когда обмен данными производится между двумя базами 1C, а между 1С и сторонними системами.

Обмен между 1С и сайтом. Многие разработчики знают о наличии формата CommerceML, есть готовое решение для этих обменов, но я им не пользуюсь, потому что в моих кейсах размеры данных при обмене в этом формате были достаточно большими, и сайт иногда падал при обмене.

В моих кейсах заказчик хотел, чтобы если заказ появился на сайте, он тут же появлялся в 1С и поступал в обработку – это вполне нормально в современном бизнесе, что, когда клиент сделал заказ на сайте, ему через полминуты перезванивает менеджер, который работает в 1С. При этом он уже видит заказ, он его редактирует вместе с клиентом, клиент это видит на своем сайте.

Обмен между 1С и мобильным приложением. По сути, 1С выступает бэкендом для сайта или для мобильного приложения. Например, в GooglePlay можно найти мобильное приложение «Вместе» для благотворительных фондов. Вся его серверная часть, весь бэкенд, написан на платформе 1С и использует liteExchange для передачи данных или обработки данных в запросах мобильного приложения. Нагрузка при этом создается невысокая.

Кстати, важно понимать, что, если мы говорим о высоконагруженных системах, я даже не пытаюсь применять liteExchange – там нужны все-таки нативные решения со стороны сайта, со стороны мобильного приложения – шины данных что-то такое. А для малых нагрузок – скажем до 100 пользователей 1С, до нескольких сотен документов «Заказ» в день, 10-20 тысяч SKU, две-три тысячи сообщений обмена в день, но не сотни тысяч – в этом случае это решение подходит.

 

Примеры применения

Дальше будут образцы кода, показывающие порядок применения фреймворка liteExchange, но я все-таки чуть-чуть расскажу, как мы решали задачи обмена раньше.

Берем конфигурацию «Конвертация данных 2.0» или «Конвертация данных 3.0», загружаем туда метаданные, запускаем мастера или вручную синхронизируем данные, расставляем галочки. Казалось бы, очень удобно – первый релиз правил обмена можно получить достаточно быстро. Но что делать потом – когда эти правила не работают или надо вносить изменения?

Лично меня не устраивает скорость отладки этих инструментов и скорость выполнения самого обмена.

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

С другой стороны, когда надо отладить код для КД 3.0 – надо сохранить модуль менеджера, переподключить обработку, а она что-то не переподключается, не сохраняется, не отлаживается – было много косяков, возможно они были связаны с моей неопытностью.

Это был достаточно древний травматический опыт, который убедил меня в том, что правила конвертации мне не нравятся.

 

 

Мне было проще написать код на выгрузку данных – на слайде показано порядка 30-40 строчек кода на выгрузку данных в документ «Реализация товаров и услуг».

Естественно, в первый раз этот код писался вручную, а впоследствии я сделал инструмент, который позволяет, описав сопоставление данных на уровне инструмента «Конвертация данных 2.0», сгенерировать нужный код, скопировать, вставить его, и всю последующую отладку вести сразу в обработке.

Именно этот код впоследствии исполняется.

Сама «Конвертация данных» дальше уже не используется, она больше не нужна. Если нужно что-то поправить, я правлю одну-две строчки кода. Обработка сохраняется – на изменение нужно потратить пару секунд. Не пара минут, а именно пара секунд.

Сами данные передается по протоколу HTTP.

Обратите внимание, что в этой функции о передаче данных через интернет вообще ничего не сказано, потому что фреймворк занимается передачей данных самостоятельно, а программист в 1С оперирует простыми, привычными ему типами данных – структура, массив, строка, дата, число. И используя кнопочки Shift+F9 (или «Вычислить выражение»), может визуально увидеть, что он передает.

В базе-источнике программист получает структуру массивов или элементов, в базе-приемнике тоже без каких-либо усилий, без какого-то дополнительного кода – точно такую же структуру, чтобы разобрать ее.

Естественно, код на создание объекта генерируются по правилам конвертации, но, когда потребуется его отладить или изменить правила конвертации, связанные с ними сложности не нужны.

 

 

Я на слайд вывел покрупнее кусочек кода по выгрузке элемента справочника – здесь нужна всего лишь одна строчка.

Фреймворк делает большую часть работы за программиста автоматически.

Функция «ДобавитьСсылкуНаСправочник()» – это полностью автоматическая конвертация. Точно так же, если нас устраивает синхронизация по уникальным идентификаторам, если структура метаданных плюс-минус похожа, то код можно и не писать. Я покажу этот пример чуть дальше, через пару слайдов.

 

 

В случае с обработкой запроса с сайта – вот пример из мобильного приложения «Вместе», про которое я говорил.

Здесь тоже 40 строчек кода, и это обработка одного запроса мобильного приложения. Всего было порядка 20 запросов у мобильного приложения. Соответственно, менее 1000 строчек кода и бэкенд готов.

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

В этом обмене:

  • нет ничего, что связано с передачей данных,

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

  • я абстрагирован от понятия заголовков запросов

  • здесь почти нет ничего по-английски, кроме имен полей

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

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

 

Дальше идет пример по упрощению выгрузки РИБ – это, скорее, частный случай, потому что в целом для РИБ есть готовое решение, которое, если работает, то не трожь.

Чтобы реализовать отмен через РИБ даже не приходится использовать какие-то хитрости с кучей кода. Фактически, я всего лишь вызываю одну функцию (показано на первой картинке), в которую при обработке вставляются служебные параметры для логирования, для удобства.

РИБ работает автоматически со скоростью менее секунды.

 

 

Здесь показано продолжение этого кода. Это работа фонового задания – тут очень много логирования, его тоже можно опускать при желании.

 

 

Вот тоже частный случай. Бывают задачи разового обмена, и чтобы выгрузить данные из одной конфигурации в другую – в данном кейсе перегружались данные из «Бухгалтерии предприятия» в «Бухгалтерию микрофинансовой организации», надо было выгрузить поступления, реализации и платежки.

Технически подкованный специалист может оценить, что тут большая часть кода не относится к обмену данными вообще. Сам обмен здесь происходит в функции леРаботаСJSON.ДанныеВJSON(), где данные преобразуются в JSON.

Обратите внимание, что мы здесь реализовали запись в файл, потому что поднимать веб-сервер для разового обмена смысла не было.

 

 

Гораздо интереснее происходит обработка данных на этапе загрузки. Те же самые данные, что ранее были сохранены, теперь мы загружаем – здесь тоже не так много строчек кода, потому что, когда метаданные похожи фреймворк управляются с работой по переносу автоматически, не приходится кодить.

Если очень надо, то в функции «ЗагрузитьОбъект()» сам объект, который может быть получен, можно модифицировать – дозаполнить какой-то спецификой, преобразовать.

 

Ссылки

По состоянию на 2021 год существует два ресурса, где можно познакомиться со фреймворком:

  • Исходный код фреймворка, про который я рассказывал, доступен на GitHub в репозитории https://github.com/liteappsru/liteExchange. К сожалению, он пока плохо документирован, но со временем документация появится. Исходники заброшены и устарели. Актуальная версия проходит отладку. Подпишитесь, но не скачивайте)

  • Канал в Телеграме https://t.me/liteExchange_group, где можно вести обсуждение, задавать вопросы. Там присутствую я и мои коллеги – порядка двухсот человек. Если прокрутить обсуждение в начало группы – там я выкладывал кейсы, которые мы реализовали летом и осенью 2019 года. Все это можно применять у себя, чтобы понять, а надо ли вообще что-то новое придумывать, или вам подойдет готовое, ранее реализованное решение.

 

Почему правила обмена больше не нужны

Я выбрал именно написание фреймворка, а не готовые решения, чтобы облегчить своим сотрудникам погружение в эту технологию. Один-два часа – и они уже достаточного уровня специалисты, чтобы писать новые обмены.

В моем случае девочка, недавно пришедшая в компанию (на тот момент времени полтора месяца работала в компании) за неделю реализовала обмен с мессенджером Slack на платформе 1С. Конфигурация «1С:CRM» посылала запросы в Slack, создавала там группы на каждую сделку, и в рамках группы велось общение, которое сливалось в 1С. Все это с синхронизацией файлов, с уведомлениями и т.д. И это сделал внедренец, впервые увидевший конфигуратор полтора месяца назад. То, что она смогла легко справиться с этой задачей, во многом связано с тем, что часть кода была написана и шаблонизирована во фреймворке.

Давайте подведем резюме, почему правила обмена данными больше не нужны?

  • Существующие инструменты сложны для изучения, ни один из них за час не выучить.

  • Исполнение самого обмена, процесс выполнения обмена данными – достаточно медленный (за рядом исключений). Я не беру в расчет шины данных, которые более-менее быстро работают, не беру в расчет HTTP-сервисы – они работают быстро, но с ними я универсальных решений не встречал, хотя примеров решений на Инфостарте много.

  • Я не встречал отладку удобнее, чем отладка обычной обработки в конфигураторе. Отлаживать «Конвертацию данных 3» еще более-менее можно, но «Конвертацию данных 2» отлаживать очень неудобно. Самописные решения я не рассматриваю – их можно хорошо отлаживать и работать, но это все-таки отдельные решения под каждую уникальную задачу, никакой универсализации.

Свое универсальное решение я создал, потому что:

  • оно позволяет облегчить жизнь мне как руководителю, потому что я могу быстро передать знания;

  • сотрудникам нужно знать один инструмент – это хорошо;

  • инструмент очень быстро работает, дает эффект «вау» у заказчика и хорошо продается.

Почему бы и нет?

 

Вопросы

  • Ваше решение построено на HTTP-сервисах и обмене в виде JSON-пакетов – сколько времени встраивается этого решение в конфигурацию клиента?

  • Развертывание – это просто установка расширения для тех и конфигураций, которые расширения поддерживают. Где расширения не поддерживаются, модули копируются в конфигурацию. На это нужно, наверное, минут пять. Плюс развертывание на веб-сервере – тут каждый справляется с разной скоростью, может занять от 15 минут до 2 часов в зависимости от поведения системного администратора и ограничений. Грубо говоря, первый обмен можно запустить в течение часа, если это что-то простое – например, передать в мобильное приложение список заказов.

  • Значит, для регистрации изменений у вас используются планы обмена? Если используются планы обмена, то как обрабатывается снятие с регистрации?

  • По-разному работает, в зависимости от задачи. Если мы говорим про обмены не между двумя базами 1С, а между, например, отправка данных из 1С на портал amoCRM, то первая попытка отправки данных производится онлайн прямо в том же потоке. В моем случае скорость была достаточной, чтобы обмениваться данными в том же потоке без фоновых заданий. Если что-то пошло не так, например, сервер, принимающий данные, недоступен, данные складывается в регистр сведений и впоследствии отправляются через минуту еще раз и еще раз – пока не заработает. Если мы говорим про обмен между двумя базами 1С, где можно взять существующие планы обмена (например, план обмена «Полный» для работы с РИБ), то, естественно, он используется – там при обмене между двумя базами 1С реализовано дополнительное фоновое задание, которое и выполняет обмен. Действительно, мы, запуская обмен, считываем изменения, которые успели накопиться за последнюю секунду в плане обмена. Или за последние 10 секунд – смотря сколько времени идет вызов фонового задания. Считываем, отправляем по HTTP, и после этого отменяем регистрацию изменений. Сейчас в продукте не реализована передача события удаления.

  • Вопрос про отправку в одном потоке – вы в момент записи документа производите и его отправку? В транзакции модуля объекта?

  • Это смотря в каком кейсе. Для тех кейсов, где это не страшно – например, регистрация CRM-события с клиентом – можно в том же потоке отправлять. Там откат транзакции произойдет с очень малой вероятностью, зато максимальная скорость. Если мы говорим про работу с учетными системами, где откат транзакции – это важно, там сознательно даже вводится задержка в скорости передачи данных. Она не онлайн идет, а через пять-десять секунд – это вычислено эмпирическим путем, исходя из количества времени, которое нужно, чтобы транзакция точно завершилась. Если уж она не завершилась, и откатилась, то и никакого обмена не будет.

  • Насколько я понимаю, вы не тестировали свой обмен под высоконагруженными системами? Вы тестировали только на обмене, содержащем малый и средний объем данных?

  • Да, мне кажется, что под высоконагруженные системы все-таки уже есть готовые решения, зачем там придумывать что-то новое – я не вижу. А под низконагруженные системы в последние 10 лет существенно ничего не менялось. и я подумал, почему бы не занять эту нишу.

  • Пробовали ли вы реализовывать обмены с сайтом или интернет-магазином на Битрикс?

  • Да, конечно. Веб-разработчики знают, что существует типовая возможность обмена через CommerceML, но как-то и мы используем типовой обмен. Если 3-10 заказов в день, если никто никуда не торопится – то достаточно типовых возможностей. Но как только появляется необходимость модифицировать этот самый обмен, то веб-разработчики и 1С-разработчики начинают плакаться от того инструмента, который есть. Поэтому никто не стесняется переписать этот обмен на что-то более продуктивное, быстрое и понятное для конечного пользователя. С точки зрения 1С-разработчика задача сводится к тому, чтобы договориться с веб-разработчиком о составе передаваемых данных и их именах. Дальше 1С-разработчик создает массив структур, и одной командой передает это куда-то в интернет.

  • В типовых правилах обмена в формате EnterpriseData заложена большая работа – их можно использовать или от этого удовольствия стоит отказаться при применении фреймворка?

  • Очень важный момент – я считаю, если работает – не трожь! EnterpriseData – в целом, хороший инструмент, там тоже есть передача данных через HTTP-сервисы. Единственный минус – EnterpriseData использует XML-пакеты данных, которые передаются чуть дольше, чем JSON. Для работы EnterpriseData используется очень много кода, в котором труднее разобраться. И важно, если у вас работает типовой обмен, куда нужно добавить один реквизит – используйте EnterpriseData. Если вы хотите написать свой обмен – я по пути EnterpriseData ни разу не пытался ходить, ровно потому, что оценил трудоемкость один раз и понял, что я не хочу слишком много копаться.

  • Сколько времени было потрачено на написание фреймворка и над чем он написан?

  • Это нативный код – никаких внешних компонент, написан на платформе 1С. Времени было потрачено немного – первый релиз был сделан под конкурс, где объявили такую задачу. Потом в рамках проекта на одном из крупных автомобильных предприятий мы реализовывали одновременные обмены между четырьмя информационными системами – сайт, CRM-система, Документооборот и БИТ-Финанс. Их надо было очень быстро синхронизировать, и за основу был выбран код, реализованный для конкурса. В общей сложности всю задачу целиком у нас получилось реализовать за 27 дней. Создание фреймворка в ней заняло дней 10, наверное. Потом этот фреймворк год не менялся, потому что был сделан достаточно хорошо. А в прошлом году я выпустил второй релиз и начал накручивать на него функциональность – тогда и появились РИБ, и «Конвертация данных», и поддержка JSON, потому что стандартно не всегда хорошо конвертируется, иногда платформа падает. С датой там проблемы, с передачей данных через HTTP тоже – можно писать пять строчек кода, можно одну. И так повсюду. Суть фреймворка в том, что половина кода уже написано.

  • Можете поделиться планами, какие фичи ожидать в ближайшее время?

  • Там требуется повысить качество, провести рефакторинг, потому что многое наделано. Я сейчас стремлюсь к тому, чтобы перевести все исполняемые модули чуть ближе к ООП. Это мое желание, поэтому весь код выводится в обработке вместо того, чтобы использовать общие модули. Этот подход позволяет менять код без динамического обновления прямо в режиме онлайн. И главное, без перезапуска конфигуратора, а значит ещё и экономить время, потому что при разработке на той же «Комплексной автоматизации» или ERP каждый перезапуск конфигуратора – это хотя бы минута, а если 30 или 50 раз в день, то уже час вылетает просто на ожидание. Поэтому собственный фреймворк помогает повысить скорость разработки. Но концептуально там уже все сделано еще в 2018 году.

  • Работает ли ваше решение на Linux, в частности на Centos?

  • Да, так как там не используется никаких хитростей, связанных с операционной системой.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Saint Petersburg.Online.

 

10 - 12 октября 2024 года состоится конференция INFOSTART TECH EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Приемы, методы разработки и тестирования
  • DevOps-практики, управление инфраструктурой разработки
  • Интеграция и обмен данными
  • Идеи и тренды в разработке 
  • Администрирование серверов 1С и СУБД. HighLoad оптимизация  
  • Развитие технической команды. Личная эффективность разработчика 

INFOSTART TECH EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


См. также

Внешние источники данных Программист Бизнес-аналитик Пользователь Платформа 1С v8.3 Управляемые формы Анализ и прогнозирование Конфигурации 1cv8 Узбекистан Беларусь Кыргызстан Молдова Россия Казахстан Платные (руб)

Готовое решение для автоматической выгрузки данных из 1С 8.3 в базу данных ClickHouse, PostgreSQL или Microsoft SQL для работы с данными 1С в BI-системах. «Экстрактор данных 1С в BI» работает со всеми типовыми и нестандартными конфигурациями 1С 8.3 и упрощает работу бизнес-аналитиков. Благодаря этому решению, специалистам не требуется быть программистами, чтобы легко получать данные из 1С в вашей BI-системе.

15.11.2022    16491    17    SQV0    48    

35

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен и синхронизацию в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

25080 руб.

12.06.2017    138145    761    292    

404

Перенос данных 1C Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) в продаже с 2015 года, постоянно работаем над их развитием | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

45650 руб.

04.08.2015    162787    372    273    

360

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 Бухгалтерский учет Управленческий учет Платные (руб)

Переход и перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:ERP Управление предприятием 2.5 и 1С:Комплексную автоматизацию 2.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.227.x), ERP 2.5 (2.5.16.x), КА 2.5 (2.5.16.x) .

28000 руб.

24.06.2020    62367    51    27    

81

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.228.x) и БП 3.0 (3.0.154.x). Правила подходят для версии ПРОФ и КОРП.

28000 руб.

15.12.2021    21797    144    40    

104

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос данных из ERP в БП 3 | из КА 2 в БП 3 | из УТ 11 в БП 3 | из ЕРП в БП 3 | В продаже с 2019г. | Воспользовались более 176 предприятий! | Сэкономьте время - используйте готовое решение для перехода! | Перенос разработан в формате КД 2 (правила конвертации данных) | Переносятся все возможные виды документов, начальных остатков и нормативно-справочная информация| Можно опционально выгружать каждую пару "номенклатура+характеристика" как отдельную номенклатуру | Есть выгрузка настроек счетов учета и зарплатных данных из ERP / КА 2 | Можно проверить на вашем сервере перед покупкой, обращайтесь!

45650 руб.

15.04.2019    70376    175    146    

117

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3.87.x и УТ 11.5.16.x

28000 руб.

23.07.2020    48438    208    64    

170

Перенос данных 1C Системный администратор Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

В продаже с 2014г. | Воспользовались более 122 предприятий! | Перенос данных из БП 3.0 в УТ 11 | из БП 3.0 в КА 2 | из БП 3.0 в ERP | Сэкономьте свое время - используйте готовое решение для перехода! | Постоянно работаем над развитием переноса данных | Обновляем на новые релизы 1С | Есть фильтр выгрузки по организациям | Переносятся начальные остатки на выбранную дату, документы за период времени и вся возможная справочная информация | Перенос сделан на технологии КД 2 (правила конвертации данных)

45650 руб.

31.10.2014    234136    93    330    

301
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. serg-lom89 76 17.03.21 13:01 Сейчас в теме
Круто..еще бы документацию по ней что бы сразу взять в работу))))
ProstoProgrammist; wowik; cleaner_it; vvv_vit; +4 Ответить
2. RPGrigorev 698 17.03.21 13:28 Сейчас в теме
Присутствовал на вебинаре, около 1.5 года назад, когда работал в этой же фирме-франчайзи. Ожидался выход коробочной версии. Прошло уже довольно много времени, а пока об этом продукте так ничего и не слышно, отзывы, документация, кейсы... Планируется ли это?
3. frkbvfnjh 800 17.03.21 13:49 Сейчас в теме
5. chg 18.03.21 05:08 Сейчас в теме
Добрый день.
Выглядит хорошо, но как у вас по планам выхода в релиз, платно не платно, общее дальнейшее развитие?
cleaner_it; +1 Ответить
6. alexey_kurdyukov 161 18.03.21 14:09 Сейчас в теме
О, нетленка. Мы тоже такую начали писать, но в процессе поняли, что при минимальном усложнении условий у нас очередная Конвертация Данных получается.
the1c; morin; Serg2000mr; VladC#; leonidol; rovenko.n; philya; dnikolaev; GATTUSO; sapervodichka; itoptimum; wowik; SlavaKron; zqzq; Andreeei; pavlov_dv; ellavs; +17 Ответить
7. alexey_kurdyukov 161 18.03.21 14:50 Сейчас в теме
Каким образом у вас реализуются правила, которые больше не нужны (например, перенос одного объекта в два разных, перенос объекта по-разному в зависимости от реквизита в котором он находится)? Ваши правила как КД2, строятся отдельно для каждой конфигурации, или как в КД3 - используют один и тот же формат?
GATTUSO; wowik; Andreeei; cleaner_it; Totoro; MaxS; +6 Ответить
8. Бэнни 207 18.03.21 17:48 Сейчас в теме
(7) Тоже не понял как это работает) Скачал даже, пощелкал, тут не хватает обзора обработки, которая правила формирует
9. ellavs 1038 18.03.21 18:09 Сейчас в теме
Я всё жду, когда зарелизится проанонсированная в прошлом году «Интеграционная шина» (заявленная, как продукт в составе платформы 1С:Предприятие), тогда есть надежда, что не нужно будет ничего изобретать... (есть задача обмена некоторыми данными между очень похожими ИБ (т.е. 1С-1С), пока видится только написание правил, например, на КД2, как наиболее быстрое по реализации решение).
the1c; Andreeei; +2 Ответить
10. MaxS 2899 18.03.21 18:14 Сейчас в теме
И важно, если у вас работает типовой обмен, куда нужно добавить один реквизит – используйте EnterpriseData. Если вы хотите написать свой обмен – я по пути EnterpriseData ни разу не пытался ходить, ровно потому, что оценил трудоемкость один раз и понял, что я не хочу слишком много копаться.
Тоже столкнулся со сложностями обмена между разнородными системами 1С-1С, 1С - Сторонняя программа.Чтобы не изобретать свой велосипед, доработал типовой обмен через EnterpriseData - добавил новый формат обмена.
Как раз вопросы плавного перехода КА 1.1 - КА 2.4, УПП - ERP хорошо решаются через EnterpriseData. Конфигурации КА 2.4, ERP могут обновляться, старые обновлять не требуется, обмен работает.
Вопросы транспорта обмена, регистрации снятия с регистрации остаются типовыми.
11. Yashazz 4762 18.03.21 18:29 Сейчас в теме
Ну понятно всё. Изучить классику и общепринятое времени и желания не было, поэтому накропали свою приблуду, которую сами же через год забудете, а поддерживающим после вас мучиться. Фигня, короче.
VladC#; Xershi; leonidol; Dach; dnikolaev; GATTUSO; EliasShy; NorraSaltolinen; AlekseiAlekseev; wowik; aximo; zqzq; Andreeei; +13 Ответить
12. a_a_burlakov 287 18.03.21 21:01 Сейчас в теме
"Правила обмена больше не нужны"

VladC#; maksa2005; user958974; P1rate; Xershi; homer_; Andreeei; triviumfan; dnikolaev; sapervodichka; EliasShy; DrAku1a; NorraSaltolinen; +13 Ответить
13. pyrkin_vanya 491 18.03.21 22:32 Сейчас в теме
Прочитал, если честно нихрена не понял с этой статьи. Не понял, почему вызвало такую сильную проблему изучение конвертации молодняком. На досуге надо будет вашу работу проанализировать получше. Желательно в код залезть и посмотреть, что же тут уникального.
user1041486; xantif_2000; borman; cleaner_it; +4 1 Ответить
14. makc2k 107 18.03.21 23:23 Сейчас в теме
Похвально, что решились написать новый инструмент переноса. Однако как было сказано при малейшем усложнении переноса получим множество кода описания конвертации. Например перенос перечисления в справочник, или создание документа на основании разнотипного. Кроме того статья сплошная вода с терминами из web дизайна. Сути алгоритма я так и не уловил. Лишь отголоски сериализации в Json и десериализации. Скриншоты вместо кода, это такая авторская особенность? Вы не клиентам комм. предложение пишете, а делитесь опытом с программистами, нам конкретика нужна, а не хвалебные оды.

И да, пробовали в справку КД2 заглянуть? - Там за 10 минут можно разобраться как передать сопутствующие данные, прочитать их, или преобразовать в базе получателе. Что до автоматизации загрузки правил, выгрузки данных, отладки - тоже решается за 20 минут написанием обработки поверх универсальной выгрузки XML.
Mick2iS; leonidol; homer_; Cерый; Andreeei; wowik; krylovim; Sergik_D; chg; cleaner_it; +10 Ответить
15. AlekseiAlekseev 19.03.21 11:28 Сейчас в теме
16. herres 19.03.21 16:39 Сейчас в теме
(14) Так у него и есть КД2 + генерилка кода

Общее с КД2 - сама конфа КД2 и принцип конвертирования не в промежуточный формат как в КД3, а в конечную базу
Общее с КД3 - принцип генерения не правил для интерпретации обработками а кода для интерпретации платформой
17. as.1c.nik 21 20.03.21 11:13 Сейчас в теме
КД это описание преобразования бизнес сущностей. А вы говорит про HTTP, JSON, COM, XML. Т.е. фактически про транспорт данных. Смешано все в кучу.

Как в вашем фреймворка описывается преобразование бизнес сущностей?
sulfur17; xantif_2000; Andreeei; FatPanzer; +4 Ответить
18. wonderboy 384 20.03.21 14:01 Сейчас в теме
Если коротко понял так:
1. В базе-источнике пакуешь данные в массивы/структуры/таблицы значений с полями простых типов.
2. Преобразуешь это в текст (в данном случае в JSON)
3. Сохраняешь в файл / отправляешь через HTTP-сервис
4. В базе-приемнике - разворачиваешь в такую же массивы/структуры/таблицы значений с полями простых типов и пишешь в объекты БД-приемника.

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

На этапе 2 - можно даже с JSON не заморачиваться. Есть олдскульные ЗначениеВСтрокуВнутр / ЗначениеИзСтрокиВнутр :)
Можно даже 2 и 3 совместить - ЗначениеВФайл / ЗначениеИзФайла :)
maksa2005; RustIG; sulfur17; +3 Ответить
19. RSConsulting 167 22.03.21 06:02 Сейчас в теме
Плох тот программист, что не написал свою конвертацию )
fuser; dooD1iez; user937640; rhtr; rovenko.n; FatPanzer; +6 Ответить
35. tendercement 12.04.21 14:00 Сейчас в теме
20. Sykoku 101 22.03.21 08:12 Сейчас в теме
Нигде не увидел задания приоритетов выгрузки или проверки даты изменения сущности.
Новый клиент?
Новый товар?
Смена реквизитов существующей записи? (Адрес, Банковский счет, форма налогообложения, таможенный код товара и т.д.)

Примеры, надеюсь, не нужны?
21. sapervodichka 6865 22.03.21 08:37 Сейчас в теме
может лучше шину 1С скачать и освоить........
24. Ambakollajder 22.03.21 10:18 Сейчас в теме
(21) Где ее скачать ? ) В будущем?
26. sapervodichka 6865 22.03.21 10:26 Сейчас в теме
(24) Назад в будущее )))

Интеграционная шина 1С, почитать здесь

https://wonderland.v8.1c.ru/blog/integratsionnaya-shina/

(Внедрена в Вертолетах РФ на сколько я знаю)

Новость была год назад на Инфостарте https://infostart.ru/journal/news/mir-1s/firma-1s-anonsirovala-novyy-produkt-integratsionnaya-shina_1214491/
27. Ambakollajder 22.03.21 10:42 Сейчас в теме
(26) Так уже попроще, надо попросить ее у вертолетов РФ? )
А если серьезно, то после публикации в зазеркалье ничего больше про нее не слышно
28. sapervodichka 6865 22.03.21 11:00 Сейчас в теме
(27) нет не у Вертолетов, у ИТ Экспертизы, компании, которая там внедряла шину вот сайт https://it-expertise.ru/company/
Прикрепленные файлы:
29. sapervodichka 6865 22.03.21 11:09 Сейчас в теме
(28) Вот страница покупки https://solutions.1c.ru/catalog/integracorp/features
Андрей, но я согласен, что это не конечная шина которую 1С анонсировала (и притихла), но хоть какой-то продукт они дали. Можно потыкать палкой ))) и вроде он живой !! судя по отзывам коллег с Вертолетов.
22. dnikolaev 178 22.03.21 09:31 Сейчас в теме
Если мне попадется новый клиент с таким обменом - даже вникать не буду. снесу все и переделаю на стандартные правила обмена ))
Скажите. после Вас, оно мне надо вникать в это все? ))
kravius12; RustIG; pbahushevich; triviumfan; +4 Ответить
23. Dzenn 879 22.03.21 10:01 Сейчас в теме
Занятный лунапарк, интересный блэкджек ....
25. detsoft@mail.ru 22.03.21 10:24 Сейчас в теме
1. Правила обмена (="конвертации") таки нужны - только они не основаны на машине "КонвертацияДанных". Ну девочка же писала у вас неделю что куда
2. "Обычного франчайзи" интересует только то что он знает - механизм БСП. Т.е. в тираж реально подавать только то что в мастерах БСП, на обычных 1С-правилах конвертации.
Т.е. вы решаете ту же классическую задачу, но более совершенными средствами. Для 1С (фирмы и сообщества) "более совершенными" - как-то не принято ("не надо как лучше, надо как положено...").
----конец скепсиса
На самом деле - здорово и правильно! Ну и фиг с ним что это не "мейнстрим" для 1С-внедренца. Эксклюзив. Супер!
30. Ambakollajder 22.03.21 12:06 Сейчас в теме
#Область ОсновныеПроцедуры
Функция ВыполнитьОбработку(СервисЗапрос, Метод) Экспорт
	
	Ответ = Новый HTTPСервисОтвет(500,,ЗаголовкиОтвета);
	Ответ.УстановитьТелоИзСтроки("Ошибка установки приложения liteExchange или попытка нелицензированного использования", КодировкаТекста.UTF8);	
	
	Возврат Ответ;
	
КонецФункции
#КонецОбласти
Показать

Понял, спасибо )
31. pavelmoskalenko056 23.03.21 12:02 Сейчас в теме
Добрый день! Заинтересовала Ваша разработка, хотелось бы с Вами посотрудничать, как с вами связаться?
32. andryandry 99 26.03.21 12:26 Сейчас в теме
плюсую. Сам использую аналогичный подход
33. dlebedev8 26.03.21 12:31 Сейчас в теме
Судя по гитхабу, проект заброшен уже почти год. Смысл выкатывать тут статью и пиарить мертвый продукт? Я уже молчу про закрытую обработку в макетах конфигурации. Открытый исходный код, называется.
34. G_103359985573713489861 07.04.21 00:08 Сейчас в теме
Здравствуйте ! Напишите пожалуйста почту . Есть задача возможно Вы его сможете решить .
36. programmarket 09.07.21 09:41 Сейчас в теме
Показатели обмена через liteExchange - это время обмена nop-ом?
37. RustIG 1720 14.08.21 13:41 Сейчас в теме
Что касается обработки «Выгрузка загрузка XML», то ее можно использовать только для разовых случаев и для одинаковых конфигураций – для постоянного обмена она тоже не совсем подходит.


Был проект - из рабочей базы в копию каждую неделею руководитель отдела продаж выгружал все документы за прошедшую неделю. Мы таким образом тестировали новые механизмы в 1с, плюс он считал валовую прибыль, игрался с цифрами и анализировал, готовил прайс-лист для разных категорий покупателей...

Короче, иногда Выгрузка - загрузка помогает.
38. RustIG 1720 14.08.21 13:50 Сейчас в теме
Народ, кто не понял, прочитайте простыми словами написано https://zen.me/1wiHa2
39. RustIG 1720 14.08.21 13:55 Сейчас в теме
У парня конечно крутой продукт - много чего нашпиговано, и прежде чем использовать, надо будет окунуться в эти новые технологии - джейсон, шТтп, кД3.0 - я к примеру еще не касался....
Но утверждать, что КД 2 не нужна - это конечно не верно. Мы же не с нуля программируем, иногда нам приходится дорабатывать уже имеющееся - а на КД 2.0 еще много каких обменов работает...
Так что из его концепции может получиться стройная система....
В его концепции есть одно ограничение - которое он упомянул, и которое может перечеркнуть старт проекта по его концепции - у него не реализовано УдалениеОбъектов
Сейчас в продукте не реализована передача события удаления.
Светлый ум; +1 Ответить
40. titanium2008 45 03.11.21 20:26 Сейчас в теме
Шина от 1с это просто транспортный слой. Сообщения передачи готовить самим придется все равно.
41. milanse 38 18.05.23 17:16 Сейчас в теме
Наткнулся на старую статью, решил глянуть гитхаб. Там последние события 3 года назад и ишьюзы, реализация которых сделает из это разработки КД 2/3.

Я так понял, автор топит за то, что json скорее xml. Других отличий после наделения разработки возможностями КД не останется.
Оставьте свое сообщение